在前面的章节中，我们分别学习了 MCP（Model Context Protocol） 和 Skills（技能）。你可能会有一个疑问：“既然通过 MCP 已经能让 AI 调用各种外部工具了，为什么还需要再搞一个 Skills 出来？它们俩到底是什么关系？”

这其实是 AI 编程从“玩具阶段”进入“工程化交付阶段”的核心难点：如何把散落的“原子能力”组合成可靠的“标准流程”。

本篇我们就来彻底理清 MCP（工具）与 Skills（技能）的分层关系，用最通俗的话讲透它们是如何打配合的。

---

1. 核心概念辨析：工具 vs 技能

要理解它们的关系，我们先用一个现实生活中的例子：做一盘西红柿炒鸡蛋。

• MCP（工具）：就像厨房里的菜刀、燃气灶、炒锅、微波炉。它们只负责提供基础的物理能力（切断、加热），不管你今天是要做宫保鸡丁还是西红柿炒鸡蛋。
• Skills（技能）：就像是菜谱和厨师的经验（SOP）。它规定了先放油还是先放鸡蛋，火候多大，万一火太大了烧糊了怎么补救。

对应到 AI 编程中，两者的分工极其明确：

🛠️ 工具（MCP/Tools）负责“能做什么”

工具是原子化的、无状态的底层能力。它只负责干活，不负责思考。

• 特征：只接收输入，返回输出，完全不关心业务逻辑。
• 例子：read_file（读取文件）、execute_sql（执行 SQL）、send_http_request（发送 HTTP 请求）、browser_action（操作浏览器）。
• 致命弱点：如果你只给 AI 提供工具，AI 就需要每次都“临场发挥”，自己思考先用哪个工具、后用哪个工具。这就非常容易出错（产生幻觉）或者走弯路。比如它可能会先修改文件，再读取文件，顺序完全反了。

🧠 技能（Skills）负责“怎么做、何时做、怎么停”

技能是流程化的、带有业务经验的高级指导。它就像给 AI 配备了一个“监工”和一本“操作手册”。

• 特征：包含 SOP（标准作业程序）、检查清单（Checklist）、失败处理逻辑。
• 例子：排查前端报错技能、自动化测试回归技能、新项目初始化技能。
• 核心作用：技能告诉 AI：“当你遇到 A 情况时，第一步必须调用工具 X，第二步调用工具 Y；如果工具 Y 报错了，就调用工具 Z 来回滚，然后立刻停止运行并报告给人类。”

---

2. MCP × Skills 分层架构：为什么不能混为一谈？

为了让 AI Agent 既强大又可控，我们在工程上通常采用分层架构。这种架构可以有效防止 AI “胡作非为”。

层级	谁来负责	核心职责	对应现实世界
意图层	用户 / Prompt	提出业务目标（例如：“帮我修复一下登录页面的白屏 Bug”）	老板提需求
技能层	Skills (SOP)	拆解任务，决定调用工具的顺序，处理失败、重试和回滚逻辑	项目经理排期与把控
能力层	MCP (Tools)	具体的动作执行（读代码、搜日志、改文件）	程序员敲代码
系统层	操作系统 / API	最终的系统底层交互	电脑系统本身

为什么必须做这样的分层设计？

1. 防篡改与安全隔离：如果把复杂的逻辑全写在一次长长的提示词（Prompt）里，很容易被 AI 遗忘或忽略。通过分层，我们可以把高危操作（如删除数据库、提交代码）锁死在特定的 Skill 流程中，并在 Skill 层加上人类审批逻辑。
2. 能力可复用，降低开发成本：read_file（读取文件）这个 MCP 工具，可以在“写代码”技能里用，也可以在“写文档”技能里用。底层工具写一次，上层技能到处复用。
3. 用确定性兜底不确定性：AI 大模型本质上是概率模型，每次回答可能不同。但工程落地需要的是绝对的确定性。Skill 就是用严谨的规则把 AI 的概率行为“框住”，让它必须按既定步骤走。

---

3. 核心机制设计：流程知识的三大要素

在一个优秀的 Skill 设计中，必须明确规定 AI 对 MCP 工具的使用纪律。这也就是连接能力与流程知识的核心：

1. 怎么做（Execution SOP）：

   • 规定工具调用的严格顺序和依赖关系。
   • 例如：“第一步必须先调用 read_file 了解现状，绝对不允许上来就直接 edit_file 盲改代码”。

2. 何时做（Trigger Conditions）：

   • 规定触发特定工具的条件。
   • 例如：“只有在运行测试代码并发现报错日志包含 Timeout 关键字时，才允许调用 network_diagnose 工具去排查网络”。

3. 怎么停（Stop & Rollback）：

   • 这是区分“玩具”和“工业级产品”的最关键指标。
   • 终止条件：如果连续重试 3 次依然失败，必须强制停止并抛出错误，防止陷入死循环白白消耗 Token。
   • 回滚策略：如果修改文件后测试不通过，必须调用 git_restore 工具恢复原状，保持代码库的整洁。

---

4. 本篇产出：端到端示例流程图（任务 → 工具 → 回滚）

下面我们通过一个真实的日常开发场景：“AI 自动修复 Bug”，来看看 Skills 和 MCP 工具是如何完美配合的。

这是一个标准的端到端（End-to-End）执行流程图，清晰地展示了从任务下达到失败回滚的全过程：

流程深度解析：

1. 任务下达：用户只需做高层决策，说一句“修复报错”，不需要告诉 AI 具体该怎么查日志、怎么用工具。
2. 技能接管（大脑发号施令）：Bug 修复 Skill 被激活。它就像一个严厉的监工，拿着标准化的 SOP 一步步指导 AI。
3. 工具执行（手脚干活）：AI 在 Skill 的约束下，依次准确地调用 read_file、edit_file、run_test 这三个底层的 MCP 工具。
4. 失败回滚（安全底线）：当测试连续失败达到 3 次时，Skill 强制要求 AI 停止尝试，并调用 git_restore 工具把代码恢复成修改前的样子。这就彻底避免了 AI 把代码越改越乱的风险。

---

5. 总结与复盘

• MCP 工具解决的是 “能不能” 的问题，它打破了 AI 与外部真实世界（文件、网络、数据库）的隔离墙。
• Skills 技能解决的是 “稳不稳” 的问题，它把人类宝贵的最佳实践（SOP）传授给 AI，防止 AI 滥用工具或陷入幻觉。
• 组合威力：当标准化的 MCP 生态（海量现成工具）遇上可移植的 Skills（专家经验流程），AI 就从一个“什么都懂一点但经常出错的实习生”，真正蜕变成了一个“自带丰富工具箱和严谨操作手册的高级工程师”。

下一步路线提示：
在理解了工具与技能的分层关系后，随着技能越写越多，我们如何把这些技能在团队中沉淀下来、管理好它们的版本？如果一个技能有 Bug 怎么快速禁用？下一篇，我们将进入《技能治理：安装、版本、禁用回滚、团队共享》。