面试官：什么时候用 MCP？什么时候用 Skill？

小马不会过河

13人浏览 · 2026-09-28 21:06:37

小马不会过河 · 2026-09-28 21:06:37 发布

面试现场，面试官喝了口茶，抛出一个看似简单的问题：“MCP 和 Skill，什么时候用哪个？” 你心里一紧——两个词都用过，MCP 连过数据库，Skill 写过 SKILL.md。但让你说清楚"什么时候用哪个"，你只能挤出一句"MCP 连工具，Skill 写指令"。面试官微微摇头：“太浅了。”

这句话刺中了一个真问题：**大多数人把 MCP 和 Skill 当成"同维度的替代品"在比较，但它们根本不在同一个轴上。**这就像问"什么时候用手、什么时候用大脑"——手和脑不是二选一，你真正需要搞清楚的是：每件事到底需要手还是脑，还是两者配合。

这道题不是在考你"选 A 还是选 B"，而是在考你能不能看破：**A 和 B 根本不在同一道选择题里。**能看破这层的人，面试官会眼前一亮。

一句话结论

MCP 给 AI 装"手"，Skill 给 AI 装"脑"。手负责"做到"，脑负责"知道怎么做"。你不会问"什么时候用手、什么时候用脑"——你需要的是搞清楚每件事要手还是要脑，还是都要。

这不是比喻，是架构事实。一张表看清两者的本质差异：

维度	MCP	Skill
本质	通信协议（Protocol）	知识包（Knowledge Pack）
作用层	运行时能力层	上下文知识层
解决的问题	“AI 能不能做到”	“AI 知不知道怎么做”
生命周期	实时连接，动态发现	按需加载，注入上下文
有没有状态	有（服务端持续运行）	无（静态文本文件）
类比	API 网关	操作手册

什么是 MCP？——协议层的"手"

MCP（Model Context Protocol）是 Anthropic 在 2024 年底开源的标准通信协议，解决一个核心问题：AI 模型怎么标准化地连接外部世界？

在 MCP 之前，每个 AI 应用要接外部工具，都得自己写一套对接逻辑。接 GitHub 写一套，接数据库写一套，接文件系统再写一套。N 个 AI 客户端 × M 个外部工具 = N×M 套适配代码。 MCP 的做法是定义一个标准协议：工具端实现一次（MCP Server），所有支持 MCP 的 AI 客户端都能用。N×M 变成 N+M。

MCP Server 暴露三类能力：

Tools：可执行的函数（查数据库、发邮件、建工单）
Resources：可读取的数据（文件内容、API 响应）
Prompts：预定义的提示模板

关键特征：运行时实时连接。 AI 在对话过程中动态发现"有哪些工具可用"，然后决定调用哪个。数据是实时的，操作是真实执行的，连接是按需建立的。

一句话：MCP 解决的是"AI 能不能做到"的问题。 它给 AI 装上了伸向外部世界的手。

什么是 Skill？——知识层的"脑"

Skill 的本质是一个打包好的知识包——把"某件事该怎么做"的完整方法论，用结构化文本（通常是 SKILL.md）封装起来，在需要时注入 AI 的上下文。

一个 Skill 通常包含：

触发条件：什么情况下该用这个 Skill
工作流程：按什么步骤做
领域知识：有哪些注意事项、最佳实践
边界约束：什么不能做、什么要人工确认
示例和反例：什么是对的，什么是错的

关键特征：静态知识，按需加载。 Skill 不在运行时执行任何操作——它只是"告诉 AI 该怎么想、怎么做"。AI 拿到这些知识后，还是用自己的能力去执行（可能调用 MCP 提供的工具来执行）。

一句话：Skill 解决的是"AI 知不知道怎么做"的问题。 它给 AI 装上了领域专家的脑。

看到这里你可能有感觉了：MCP 和 Skill 不是"谁替代谁"，而是"手+脑"的配合。面试官就是看你能不能把这层想明白。

什么时候用 MCP？——5 个典型场景

#	场景	为什么必须用 MCP
1	需要实时数据查订单状态、查库存	数据在数据库里，是实时的。Skill 写不了这些数据——写了也马上过时。
2	需要执行外部操作创建 PR、发邮件	真实 API 调用，需要认证、网络请求、处理返回。Skill 只能告诉你步骤，按按钮的必须是 MCP。
3	需要连接有状态的服务查 Pod 状态、监控指标	有状态服务每次查询结果不同。Skill 是无状态静态文本，处理不了。
4	需要标准化多工具接入 10 个内部系统全接入	写 10 个 MCP Server，任何支持 MCP 的 AI 客户端自动发现和使用。不需要为每个平台单独适配。
5	需要跨平台复用能力 Claude/GPT/自研都能用	MCP 是开放协议，写一次 Server 多平台通用。它就是 AI 工具生态的"USB 接口"。

什么时候用 Skill？——5 个典型场景

#	场景	为什么用 Skill 就够了
1	编码领域方法论 SEO 审计、代码审查	"怎么做"的指导，不是"能做到"的能力。把方法论打包，AI 加载后知道按什么步骤做。
2	约束 AI 行为边界排版规范、禁止事项	行为约束不需要运行时连接外部系统，只需要在上下文里注入规则。
3	复用工作流模板部署流程、发布流程	流程本身是静态知识，打包成 Skill 让 AI 按流程执行。执行中可能调用 MCP 工具来真正操作。
4	传递团队约定代码规范、命名约定	静态知识适合 Skill 承载。比每次对话手动贴规范高效得多。
5	补充专家视角安全审查视角、性能优化视角	把人的经验打包成 AI 可读的知识。本质是知识注入，不需要任何运行时能力。

最常见的坑：把 Skill 当"轻量版 MCP"

这是面试中最容易翻车的地方，也是实际项目中最常见的误用。

误区 1：用 Skill 去做 MCP 该做的事。

有人把数据库连接信息写进 Skill，让 AI 用文本方式"查询"数据。致命问题：数据写入 Skill 那一刻就过时了；AI 无法真正执行 SQL，只能"编造"结果；没有连接管理、认证、错误处理。

误区 2：用 MCP 去做 Skill 该做的事。

有人写 MCP Server 只为了返回一段固定文档。完全没必要——静态知识用 Skill 就行，MCP Server 还要维护运行状态、管理进程，成本远高于一个 SKILL.md 文件。

判断标准——问自己一个问题：

这件事需要"实时连接外部系统并执行操作"吗？

需要 → MCP
不需要，只是"告诉 AI 怎么做" → Skill
两者都需要 → MCP + Skill 配合

Java/Spring AI 实战：MCP + Skill 配合使用

来看一个真实场景：用 Spring AI 构建一个"代码审查 Agent"，它需要：① 从 GitHub 拉取 PR 代码变更（需要 MCP——实时数据 + 外部操作）；② 按照团队安全审查规范来审查（需要 Skill——方法论 + 约束）。

Step 1：MCP Server——提供 GitHub 操作能力（“手”）

// MCP Server：暴露 GitHub 工具能力// 这一层只管"做到"——拉数据、发评论，不管"怎么做"@McpServerpublic class GitHubMcpServer {    private final GitHubClient githubClient;    @Tool(name = "get_pull_request_files",          description = "获取指定 PR 的所有变更文件")    public List<PRFile> getPullRequestFiles(            @ToolParam("repo") String repo,            @ToolParam("prNumber") int prNumber) {        return githubClient.getPullRequestFiles(repo, prNumber);    }    @Tool(name = "post_review_comment",          description = "在 PR 上提交审查评论")    public void postReviewComment(            @ToolParam("repo") String repo,            @ToolParam("prNumber") int prNumber,            @ToolParam("body") String comment) {        githubClient.createReviewComment(repo, prNumber, comment);    }}

MCP Server 提供了"手"——能拉代码、能发评论。但它不知道"什么代码有问题"。

Step 2：Skill——定义审查方法论（“脑”）

# SKILL.md: security-code-review## 触发条件当用户请求"审查 PR"或"code review"时激活## 审查清单1. SQL 注入：检查所有数据库查询是否使用参数化2. XSS：检查用户输入是否经过转义3. 权限绕过：检查接口是否缺少鉴权注解4. 敏感信息泄露：检查日志是否打印了密码/Token5. 依赖漏洞：检查是否引入了已知有漏洞的依赖## 严重级别定义- P0：可直接利用的安全漏洞 -> 阻断合并- P1：潜在安全问题 -> 需修复后合并- P2：安全建议 -> 建议修复## 输出格式对每个问题输出：文件路径+行号、问题描述、严重级别、修复建议## 禁止事项- 不要审查测试代码- 不要对风格问题提意见- 不要直接修改代码，只提建议

Skill 提供了"脑"——知道查什么、怎么查、怎么报告。但它没有"手"——拉不了代码、发不了评论。

Step 3：Agent 整合——手脑配合

@Servicepublic class CodeReviewAgent {    private final ChatClient chatClient;    private final McpClient githubMcpClient;    public String reviewPullRequest(String repo, int prNumber) {        // 1. 通过 MCP（手）拉取 PR 变更——运行时能力        List<PRFile> changedFiles = githubMcpClient            .callTool("get_pull_request_files",                Map.of("repo", repo, "prNumber", prNumber));        // 2. 构建上下文：代码变更 + Skill 方法论        String codeDiff = changedFiles.stream()            .map(f -> f.getFilename() + "\n" + f.getPatch())            .collect(Collectors.joining("\n\n"));        // 3. AI 用 Skill（脑）审查代码        //    system prompt 携带 Skill 的审查清单和约束        String reviewResult = chatClient.prompt()            .system("""                你是安全审查专家。按以下清单逐项检查：                1. SQL注入 2. XSS 3. 权限绕过                4. 敏感信息泄露 5. 依赖漏洞                输出：文件路径+行号、问题描述、严重级别、修复建议。                禁止：审查测试代码、提风格意见、直接改代码。                """)            .user(codeDiff)            .call()            .content();        // 4. 通过 MCP（手）把审查结果发到 PR 上——运行时操作        githubMcpClient.callTool("post_review_comment",            Map.of("repo", repo, "prNumber", prNumber,                   "body", reviewResult));        return reviewResult;    }}

这套架构的精妙之处：

MCP 负责"做到"：拉代码、发评论，都是真实操作
Skill 负责"做好"：审查清单、严重级别、输出格式，都是方法论
Agent 负责"协调"：决定什么时候拉数据、什么时候审查、什么时候提交

如果只有 MCP 没有 Skill，AI 能拉到代码但不知道该怎么审——有手无脑。如果只有 Skill 没有 MCP，AI 知道审查方法但拉不到代码也发不了评论——有脑无手。两者缺一不可。

踩坑指南：4 个高频翻车点

#	坑	正确做法
1	MCP Server 越界写业务逻辑	MCP 只管数据存取和能力暴露，业务逻辑交给 AI + Skill。和数据访问层不写业务逻辑一个道理。
2	Skill 不定义触发条件	每个 Skill 必须有明确的触发条件。没写触发条件 = AI 永远不会加载它。
3	用 MCP 传静态知识	返回内容不需要实时计算 → 用 Skill。一个 SKILL.md 比一个常驻进程便宜得多。
4	Skill 和 MCP 职责重叠	MCP 管"怎么连"，Skill 管"怎么用"。Skill 里写"调用 MCP 的 xxx 工具"，不写 API 细节。

面试模板：30 秒拿下这道题

"MCP 和 Skill 解决的是不同层面的问题。

MCP 是协议层，解决 AI 怎么标准化连接外部系统——它是运行时能力，让 AI 能真正执行操作：查数据库、调 API、发消息。

Skill 是知识层，解决 AI 怎么知道该做什么——它是上下文注入，把领域方法论、工作流程、行为约束打包给 AI。

一句话：MCP 给 AI 装’手’，Skill 给 AI 装’脑’。

实际项目中两者配合使用：MCP 提供工具能力，Skill 提供方法论指导，Agent 协调两者完成复杂任务。

判断标准：需要实时连接外部系统就 MCP，需要传递方法论和约束就 Skill，两者都需要就配合。"

面试官追问

Q：有了 MCP，还需要 Skill 吗？MCP 不是也能返回 Prompts 吗？

A：MCP 的 Prompts 是预定义提示模板，解决"怎么问"，不是"怎么做"。Skill 承载的是完整方法论——工作流、边界约束、验收标准、示例反例。前者轻量，后者完整。复杂场景下，Skill 定义"做什么、怎么做"，MCP 提供"用什么做"，两者互补。
Q：Skill 和 system prompt 有什么区别？直接写 system prompt 不就行了？

A：区别在于封装和复用。system prompt 是一次性的——每次对话都得手动写，换项目又得重写。Skill 是打包的知识包，有触发条件、有版本管理、可以跨项目复用。类比：system prompt 是每次手写 SQL，Skill 是封装好的存储过程。
Q：MCP Server 挂了怎么办？

A：MCP Server 本质是运行的服务，和微服务一样需要高可用。做法：① 多实例 + 负载均衡；② Agent 侧降级——工具不可用时回退到纯知识模式（用 Skill 指导 AI 告诉用户手动操作步骤）；③ 关键操作做重试 + 超时控制。和微服务容错是同一套思路。

写在最后

这道题表面考的是"工具选择"，实际考的是 AI 系统架构思维。

面试官想听到的不是"MCP 连工具、Skill 写指令"这种字典式回答。他想听到的是你对 AI 系统分层架构的理解——能力层和知识层的分离，运行时和上下文的区别。

更深一层，这其实是一个**关注点分离（Separation of Concerns）**的问题。MCP 和 Skill 的分工，和软件工程里"接口与实现分离""数据与逻辑分离"是同一个思想：

不把业务逻辑写进数据访问层 → 不把方法论写进 MCP
不把数据查询写进业务逻辑层 → 不用 Skill 做实时查询
各层各司其职，通过 Agent 编排 → MCP 管连、Skill 管用、Agent 管协调

这个思想你如果真懂了，不光能答好这道题，设计任何 AI 系统都不会跑偏。

最后提醒一句：面试官问"什么时候用 MCP、什么时候用 Skill"，最高分的回答不是给出一个非此即彼的选择，而是指出这个问题本身就有个隐藏前提——它们不是替代关系，而是协作关系。能看破这层的人，面试官会眼前一亮。

MCP 给 AI 装手，Skill 给 AI 装脑。手负责"做到"，脑负责"知道怎么做"。它们不是选择题的两个选项，而是配合使用的两个层次。判断标准：需要实时连接外部系统 → MCP；需要传递方法论和约束 → Skill；两者都需要 → 配合。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

在这里插入图片描述

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～