Skill 和 MCP，到底有什么不一样？

摘要：MCP 给 AI 接外部工具，让它能操作浏览器、读文件；Skill 给 AI 定做事方法，让它按流程来。两者一外一内，配合使用效果最好。

1. 从一件小事说起

你对着 AI 说：“帮我打开百度，搜一下今天北京的天气。”

AI 回答：“抱歉，我没法打开浏览器。”

你又说：“那你帮我改一下电脑桌面上那个 Word 文档。”

AI 说：“我访问不了你电脑上的文件。”

这不是 AI 笨，是 AI 出厂时自带的能力就这么多。它会聊天、会写代码、会翻译，但它碰不到你电脑上的东西，也操作不了外部的系统。

为了让 AI 能做更多事，行业里出现了两条路子：MCP 和 Skill。

两条路都能让 AI 变得更好用，但走的方向完全不同。

2. 先给结论

• MCP = 给 AI 接外部工具——让 AI 的手能够到它本来碰不到的东西（浏览器、文件、数据库）。
• Skill = 给 AI 定做事方法——让 AI 知道遇到什么情况该按什么步骤来（怎么写代码、怎么沟通、怎么管任务）。

一个往外伸手，一个往内定规矩。就这么简单。

3. MCP：给 AI 接外部工具

3.1 MCP 是什么

MCP 的全称是 Model Context Protocol，是 Anthropic 推出的一套通信标准。

你可以把它理解成"行业通用合同模板"——甲方和乙方都按这个模板说话，双方就能合作。没有这套模板，各说各的，根本聊不到一块儿去。

3.2 MCP 里有三个角色

很多人一说 MCP 就只想到"那个服务器程序"，其实 MCP 是一整套体系，三个角色缺一不可：

角色	干什么的	类比
MCP 协议	规定了双方怎么说话、怎么传数据、怎么返回结果	行业合同模板
MCP Client	AI 工具本身（比如 TRAE、Claude Code），负责判断什么时候需要外部能力，然后发起调用	甲方公司
MCP Server	独立运行的程序，自己实现了某项具体能力，等着被调用	乙方服务商

3.3 一个类比：走廊里的工具柜

MCP Server 就像公司走廊里放的一间自助工具柜。

柜子里有电钻、扳手、螺丝刀、测距仪……各种工具。柜子门上贴着一张清单，写着"里面有什么、每种怎么用"。

你（Client）走过去，看清单，找到需要的工具，刷卡取用，用完还回去。

工具柜自己不会来找你。它就在那儿放着，你需要就去拿。

3.4 完整的工作流程

用一个实际场景串起来：

你对 AI 说：“帮我打开京东，搜一下 iPhone 16，把前三个商品价格列出来。”

然后发生了这些事：

1. AI 分析你的需求，判断"这个需要操作浏览器"
2. AI 通过 MCP 协议给浏览器 Server 发请求：“打开京东，搜 iPhone 16”
3. Server 真的启动了一个浏览器，访问京东，输入关键词，点搜索
4. Server 把页面上的价格信息抓下来，返回给 AI
5. AI 把结果整理成表格，拿给你看

整个过程中，真正操作浏览器的是 MCP Server，不是 AI 本身。AI 只是发号施令的那个。

3.5 MCP 的独立性

MCP Server 最大的特点是——它自己独立运行。

它是一个单独的程序，在后台跑着，有自己的代码和逻辑。它不依附于某个特定的 AI 工具。

你装了一个"浏览器操控"的 MCP Server，TRAE 能用，TRAE IDE 能用，换个别的支持 MCP 的工具也能用。工具柜放在走廊里，哪个部门的人都能去借。

4. Skill：给 AI 定做事方法

4.1 Skill 是什么

Skill 本质上是一套预写好的指令，告诉 AI 遇到某类任务时，应该按什么流程走、用什么方法、达到什么标准。

Skill 不调用任何外部服务。它不改变 AI"能做什么"，它改变的是 AI"怎么做"。

4.2 一个类比：岗位操作手册

Skill 就像一本岗位操作手册。

新员工入职，主管递给他一本手册，上面写着：

• “遇到客户投诉，先安抚情绪，再记录问题，然后分类处理，最后回访确认。”
• “写代码之前，先写需求文档，确认后再动手，每完成一个功能跑一遍测试。”

手册本身不会替员工干活。手册只是告诉员工"遇到 X 情况，按 Y 流程做"。

4.3 Skill 是怎么发挥作用的

Skill 文件就是一段结构化的文本，通常包含这几部分：

• 这个 Skill 解决什么问题（什么时候触发）
• 处理这类问题的标准流程（步骤）
• 每个步骤的具体要求（规范）
• 输出应该符合什么标准（验收）

当 AI 检测到你的请求匹配上了某个 Skill 的触发条件，它就把这段指令加载到自己的"脑子里"，然后按照 Skill 规定的流程来思考和行动。

还是用写代码举例子：

你对 AI 说：“帮我写一个登录功能。”

如果 AI 加载了"代码开发协作"的 Skill，它不会上来就写代码，而是会：

1. 先问清楚你的具体需求
2. 写一份需求规格文档，给你确认
3. 你说"可以"了，它才开始写代码
4. 写完一个功能就跑一遍测试
5. 全部做完了再跟你一起验收

AI 写代码的能力没有变，但它做事的方式变了——从"想到哪儿写到哪儿"变成了"按流程一步步来"。

4.4 Skill 的依赖性

Skill 必须依赖 AI 才能生效。Skill 文件本身不会运行任何东西，它就是一段文本。得 AI 读它、理解它、执行它，它才有用。

而且 Skill 通常和特定的 AI 工具绑定。你在 TRAE 里用的 Skill，拿到别的 AI 工具里不一定能用，因为不同工具的触发机制、上下文格式可能不一样。

5. 摆一块儿比一比

对比维度	MCP	Skill
本质	通信协议 + 独立服务程序	预写的指令/提示词文本
核心类比	乙方服务商 / 自助工具柜	岗位操作手册 / 工作流程规范
扩展的是什么	AI 的外部能力——能操作本来不会的东西	AI 的内部行为——知道遇到什么情况按什么流程来
独立运行吗	MCP Server 是独立进程，自己在后台跑	不运行任何东西，就是个文本文件
能力来源	Server 自己实现的（比如浏览器操作是 Server 的代码写的）	借用 AI 本身的能力（只是告诉它"该怎么做"）
通信方式	Client 和 Server 之间有标准协议通信，发请求等响应	没有"通信"，就是 AI 读文本然后自己理解执行
可移植性	任何支持 MCP 协议的 Client 都能调用同一个 Server	通常只能在对应的 AI 工具里用
实际例子	浏览器操控、文件系统访问、数据库查询	协作框架 Skill、代码规范 Skill、写作风格 Skill
谁在真正干活	Server 真正在执行操作（浏览器真的在点、文件真的在读）	AI 自己在思考和行动

6. 什么时候用哪个？

一张表说清楚：

你遇到的问题	该用什么	为什么
AI 本来不会的事（操作浏览器、读数据库、调外部接口）	MCP	接外部能力
AI 本来会做但做法不对（写代码不规范、沟通乱、流程乱）	Skill	定行为规范
既要新能力又要好流程	MCP + Skill 配合	实际干活儿的常态

举个具体的例子：你想让 AI 帮你写一篇公众号文章，然后发布到公众号后台。

• "写文章"这件事——AI 本来就会，但你可以用一个"公众号写作"的 Skill，让它按你的风格、按你的结构来写
• "发布到公众号后台"这件事——AI 自己做不到，你需要一个 MCP Server 来操作网页、登录后台、点发布按钮

两者配合，活儿才能干漂亮。

7. 几个容易搞混的问题

问题一：MCP Server 完全独立，不需要别的东西？

不对。MCP Server 确实自己独立运行，但它得有 Client 调用它才有意义。没有 AI 工具找它，它就一直闲着。工具柜放在走廊里没人用，它就是一堆废铁。

问题二：Skill 能给 AI 增加新能力？

不能。AI 本来就会写代码，Skill 只是让它写代码的流程更规范。AI 本来就会说话，Skill 只是让它说话的方式更得体。

你给一个厨师一本菜谱，厨师的厨艺没有变，但他做出来的菜更符合你要的口味了。

问题三：MCP 和 Skill 是竞争关系，只能选一个？

不是。两者互补。MCP 扩展"能做什么"，Skill 规范"怎么做"。实际用的时候往往是两者配合——手够得着，脑子也清楚，才能把活儿干好。

问题四：MCP 比 Skill 高级？

这个问题本身就不对。两者解决的是不同层面的问题，没有高下之分。

电钻和施工规范，你说哪个更高级？电钻让你能钻墙，规范让你钻对位置。缺了哪个都不行。

8. 最后说两句

记住两句话就够了：

• MCP 让 AI 的手变长——能碰到它本来碰不到的东西。
• Skill 让 AI 的脑子更清楚——知道遇到什么事该按什么路子来。

一个往外伸手，一个往内定规矩。两条路一起走，AI 才真的好用。