第 1 章｜为什么需要 Skill：从 Mahesh 到 Barry

本章尝试回答一个最基础的问题：**Skill 到底在解决什么？**

>

有两个答案。一个是 Anthropic 给的——"让 Agent 从通才变成专家"。这个答案是对的，但只说了一半。

>

另一个答案藏在 **2026 年 3 月** 那个数据拐点里——格式化的压力比能力的不足更早形成。这一章会同时讲这两个。

---

1.1 一个让所有人停下来的类比

先讲 Anthropic 官方那篇 [*Stop Building Agents, Build Skills*](https://www.anthropic.com/engineering/agent-skills) 里的开场类比。原文很短，我用中文复述——

假设你开了一家税务事务所，要雇一个会计。

>

候选人 A 叫 **Mahesh**。他是 MIT 数学博士，智商 150，记忆力极强，任何公式给他一眼他就能推导出来。他刚毕业，没做过一天会计。

>

候选人 B 叫 **Barry**。他是社区大学学历，30 年税务经验，见过所有你能想到的客户场景：奇葩发票、跨国税务、政府稽查。他智商不算突出，但每个他遇到过的坑都记得。

>

**你会雇谁？**

答案几乎所有人都一样：**Barry**。

不是因为 Mahesh 不够聪明。是因为一家事务所需要的是"做过同类事一千次的人"，不是"理论上应该能做的人"。

今天的大语言模型——Claude、GPT、Gemini——**都是 Mahesh**。它们能在 10 秒内理解你公司的整个税务代码，能推导出任何公式。但它们每次对话都从零开始——上一个客户的案例不会帮它们做好下一个客户。

**Skill 就是给 Mahesh 配 Barry 的那本小本子。**

每次开会前翻一下"30 年经验"——这个客户是 S-corp 要注意什么、上个月 IRS 发的通知怎么回、客户送的那张模糊发票可能是什么税种。Mahesh 还是那个 Mahesh，但他现在手里有 Barry 的 30 年。

---

1.2 Anthropic 这个类比的隐含假设

Anthropic 这个类比讲得很美，但它藏了一个假设——**"经验"可以被写成文字，传给下一个 Mahesh**。

这个假设对吗？一部分对。

**能被写的那部分**：

• "这类发票一律按 Schedule C 处理"——可以写
• "IRS 的 Letter 2205 是稽查通知"——可以写
• "客户说 'basis' 的时候通常指成本基准"——可以写

**不能被写的那部分**：

• "这个客户说话吞吞吐吐，肯定有事瞒着"——很难写
• "这张发票金额不对，我闻得出来"——基本不可写
• "这种案子你得先陪客户喝杯咖啡再谈业务"——完全写不了

Barry 30 年经验里，**大约 60-70% 是可写的**，剩下的是直觉、人情、氛围判断。

但这不是问题。因为现在的 Mahesh（也就是大模型），**连那 60-70% 可写的经验都没有**。把能写的部分先写出来传给它，已经能让它的表现从"天才实习生"变成"合格中级"。

这就是 Skill 的第一个目标：**把 60-70% 的显式经验，以最小摩擦传给下一个 Agent**。

最小摩擦的意思是——

• 不是让每个人都去训练自己的模型（成本太高）
• 不是让每个人都写一个完整的 Agent framework（复杂度太高）
• 而是**写一个文件夹**，扔进 `~/.claude/skills/`，Claude 自己会读

这就是为什么 Skill 的形式极简——只需要一个 `SKILL.md`，带 description 和 instructions。其他都是可选的附件。

**Skill 的定义**：一个装着"可写的经验"的文件夹，格式简单到任何人有电脑就能创建，但标准统一到 Claude 能自己读懂、自己决定什么时候用。

---

1.3 为什么 2026 年 Q1 才爆发

类比写于 2024 年。形式（文件夹 + SKILL.md）也不是新东西。但 Skill 生态**真正爆发是在 2026 年 Q1**——单月创建 27,720 个（第 3 章数据）。

为什么早不爆发、晚不爆发、偏偏是 2026 年 1-3 月？

答案不在 Skill 本身，在 **Runtime 的成熟度**。

时间线回放

| 时间 | 事件 | 对 Skill 生态的影响 |

|------|------|---------------------|

| 2023 Q4 | ChatGPT Plugin 发布 | 第一次尝试"让模型调用外部能力"，但生态死于无法分发 |

| 2024 Q2 | Claude Tool Use / OpenAI Function Calling | 工具调用规范化，但 function 还是绑在 Agent 代码里 |

| 2024 Q4 | **Anthropic 推出 MCP 协议** | 第一次出现"跨 Agent 的能力协议"，但部署复杂（每个 MCP 是一个独立进程）|

| 2025 Q3 | Claude Code 1.0 发布 | 把 skill loading 做成一等公民，**"写一个文件夹"这件事有了官方 runtime** |

| 2025 Q4 | Cursor / Windsurf / Codex 陆续支持 skill 格式 | Skill 格式从 Claude 专用 → 事实上的 AI 编码工具标准 |

| **2026 Q1** | **Skill 生态爆炸** | 供给端 27,720/月 |

你会发现，每一次之前的"能力扩展"尝试——插件、function、MCP——都是**技术上行得通，但分发行不通**。

MCP 尤其痛——它是个好协议，但要让你装一个 MCP server，你得：

1. 下载源码
2. 配置环境
3. 启动一个独立进程
4. 把端口或 stdio 配到你的 IDE 里
5. 重启 IDE
6. 运气好的话，工作了

Skill 的设计是反过来的：

1. 把 `SKILL.md` 扔进 `~/.claude/skills/`
2. 就完了

这个差异看起来微小，实际上决定了生态规模。**"装一个 MCP server 要 6 步，装一个 Skill 要 1 步"**——门槛低 6 倍，用户基数就大 10 倍以上。

真正的触发点

2025 年 Q4 Claude Code 把 skill loading 做成一等公民之后，**写一个 skill 和装一个 skill 的摩擦同时被压到 0**。

然后 Cursor、Codex、Windsurf 陆续支持同一个格式——**格式化压力**形成了。所谓格式化压力，是指"不管你原本用什么工具，你的产出都要能在这个格式里跑"这种隐性约束。

类似的事情在别的行业发生过：

• **npm 之于 Node**：2010 年后写 JS 的人必须生产 npm 包
• **Docker Hub 之于容器**：2015 年后做基础设施的必须出 Docker image
• **Chrome 扩展规范之于浏览器**：2012 年后浏览器插件的事实标准

Skill 现在在走同一条路。**2026 Q1 的爆发不是偶然，是 15 个月积累之后的相变**。

这也解释了为什么这本蓝皮书写在今天——再早，生态太小，数据不具代表性；再晚，市场已经分化、赢家已定，讨论没价值。**现在是 Skill 市场最可以被定义的窗口**。

---

1.4 Skill 跟其他扩展机制的区别

先澄清一个常见混淆。一提到"让 AI 更聪明"，市面上有 5 种方案：

| 方案 | 本质 | 加载方式 | 典型使用 |

|------|------|---------|---------|

| **System Prompt** | 对话开头的长指令 | 始终加载 | "你是一个专业的会计师……" |

| **RAG** | 检索相关文档 | 每次对话按相似度召回 | 问答系统、企业知识库 |

| **Tool Use / Function** | 模型调用外部函数 | 永久定义，按需调用 | 查天气、发邮件、调 API |

| **MCP Server** | 独立进程提供工具集 | 永久运行，协议对接 | 数据库连接、浏览器控制 |

| **Skill** | 文件夹里的 description + 指令 + 资源 | **三层按需加载** | 领域任务（"审一段合同"）|

这 5 种不是替代关系，是**互相补位**。

Skill 跟其他几个最大的差异是——**它承载的是"怎么做"的知识，不是"能做什么"的能力**。

• Tool 告诉你"能调 weather API"。Skill 告诉你**"遇到旅行计划问题，你应该先问用户日期，再查天气，再组合建议"**。
• MCP 给你一堆数据库连接。Skill 告诉你**"查这类客户数据，用 customer_id 而不是 user_id，因为前者是业务唯一键"**。
• System Prompt 能让模型记住一个角色。Skill 能在**每次用到特定场景时**加载特定指令，其他场景不浪费 token。

**一句话：Tool/MCP 是四肢，Skill 是教练笔记。**

为什么不把所有东西塞进 System Prompt

听到这里有人会问：既然 Skill 是指令集，为什么不全部塞进 System Prompt？

答案是：**上下文窗口是有限的**。

Claude 4.5 的上下文窗口是 200K tokens。如果你把 50 个领域的指令都塞进 System Prompt，大概消耗 30-50K。问题还不只是数量——

• 每一次用户对话，这 30-50K 都会被**重复发送**
• 模型在每一次推理时，都要"想着"这些指令（即使当前问题跟法律无关，它还在浪费注意力 cycle 去考虑法律指令）
• 成本是线性叠加的：你塞越多，每个 token 都在付费

**Skill 用"三层按需加载"解决了这个问题**：默认只加载**极轻的元数据**（description，几十字），需要用到某个 Skill 时才展开它的完整指令和附件。

这一点是第 2 章的核心。

---

1.5 为什么不用 RAG

另一个常问的问题：RAG 不也是"按需加载知识"吗？跟 Skill 有什么区别？

区别很大：

**RAG 是 pull-based**——用户提问 → 向量化 → 检索相似文档 → 把文档原文拼进 prompt 给模型看。

**Skill 是 push-based + agent-driven**——模型自己在启动时看到所有 Skill 的 description → 根据当前任务主动决定"我要激活哪个 Skill" → 加载那个 Skill 的指令。

两个差异：

1. **谁决定用什么**：RAG 是系统决定（向量相似度）。Skill 是模型决定（语义理解）。**模型决定通常更准**，因为模型知道自己真正需要什么。
2. **加载的是什么**：RAG 加载"事实知识"（原文段落）。Skill 加载"程序性指令"（步骤、约束、规则）。前者是"是什么"，后者是"怎么做"。

打个比方——

• RAG 像让员工随时查百科全书
• Skill 像让员工带一本工作手册

做复杂任务的时候，手册比百科全书更有用。因为手册告诉你**先做什么、然后做什么、遇到 X 情况怎么处理**。

这也是为什么 Skill 特别适合 Agent——Agent 的本质是"在开放任务里自主决策的程序"，它需要手册多于需要百科。

二者可以组合

最强的配置是 **Skill + RAG 组合**：

• Skill 告诉 Agent"审合同时要检查 12 个关键条款"
• 其中某条款需要参考公司历史合同时，Agent 激活 RAG 去检索相似合同
• Agent 把 RAG 的检索结果代入 Skill 的决策框架

这不是假设。花叔的 `huashu-design`（1,416 stars）里就有这种设计——Skill 提供设计方法论 + MCP 调向量数据库查历史作品。一静一动。

---

1.6 Skill 的"文件夹"隐喻

Anthropic 反复强调一件事：**Skill 就是一个文件夹**。不是服务、不是 API、不是数据库——是一个你能用 Finder 打开的文件夹。

这个设计决定是刻意的。文件夹的好处：

1. **Git 能管**——版本、diff、回滚、协作全部现成
2. **Google Drive / iCloud 能同步**——跨设备共享零成本
3. **Zip 能打包**——给同事或客户零成本
4. **任何人都能创建**——不需要懂编程，打开文本编辑器就行
5. **AI 能读**——SKILL.md 是 Markdown，模型天生懂

对比其他技术形式——

| 形式 | 需要什么 | 摩擦 |

|------|---------|------|

| MCP Server | Node/Python 环境、端口管理、进程管理 | 高 |

| Chrome 扩展 | manifest.json、permissions、review process | 中 |

| npm 包 | package.json、发布流程、版本依赖 | 中 |

| **Skill** | **一个 Markdown 文件** | **几乎为 0** |

这不是"让 Skill 更简单"。是**让 Skill 生态能规模化**。

复杂度每上一档，能生产的作者数下降一个量级：

• 会写 Markdown 的人：数亿
• 会写 JS 并发 npm 包的：千万级
• 会写完整 AI Agent 的：百万级
• 会写 MCP Server 的：十万级

Skill 选择站在"数亿级"那一档。这是为什么 `Anthropic/skills` 一个官方 repo 能涨到 12 万 stars——因为"我也能写一个"这件事是真的，不是营销词。

但文件夹也有成本

文件夹的缺点是——**没有强制结构**。

你想在 SKILL.md 里写什么都可以：

• 写得太长，模型读不完
• description 写得太笼统，模型不知道什么时候用它
• 指令之间互相冲突，模型左右为难
• 脚本没测过，Agent 执行时报错

这就是为什么有"5 种设计模式"（第 3 章会讲）、"Agent 视角设计"（第 4 章）、"评估驱动开发"（第 5 章）——**简单的载体需要复杂的工艺来填**。

**Skill 生态的残酷长尾（第 3 章数据：54% 0 star），本质上就是"文件夹门槛低，内容门槛高"的直接体现。**

---

1.7 Skill 的野心是什么

如果只是"让 Mahesh 变成 Barry"，Skill 只是 Agent 能力的一个补丁。

但 Skill 的野心远不止此。

野心一：让 Claude 自己创建 Skills

Anthropic 官方文章里有一句话，被很多人忽略——

"当 Claude 自己开始创建 Skills 的时候，系统会真正转起来。"

现在 Skill 还是人在写。人看到 Agent 反复犯同一个错，人写一个 Skill 教它。

**但想象一下**：如果 Claude 自己能检测"这类任务我反复出错"，然后自己总结出一个 Skill，下次遇到就激活——那就形成了真正的**经验积累闭环**。

Mahesh 变成了自己训练自己的 Barry。

这不是科幻。已经有 skill 在做这件事（比如花叔的 `darwin-skill`，宝玉提到的"Agent 自我优化"机制）。只是现在还很早。

野心二：经验的可迁移性

Skill 另一个未被充分讨论的价值——**经验可以在不同 Agent 之间迁移**。

你今天给 Claude Code 写的 `git-workflow.skill`，**理论上** Cursor、Codex、Windsurf 都能用（只要它们都按 Claude Code Skills 规范实现）。

"理论上"是现在。但随着格式标准化（2026 Q1 已经基本完成），**实际上**也会成立。这意味着：

• 你团队 30 年沉淀的"怎么审代码"，不再绑死在某个工具里
• 换 IDE 不再损失"调教好的助手"
• 一个员工离职，他的 Skill 库可以留在公司

这是**企业级价值**——也是第 11 章"Enterprise Skill Directory"要解决的。

野心三：知识的新形态

这个稍微远一点，但值得提。

人类历史上的知识形态经历过几次重大变迁：

| 时代 | 形态 | 特征 |

|------|------|------|

| 口传 | 故事、谚语、师徒 | 高上下文、低扩散 |

| 书籍 | 系统化论述 | 高保真、低互动 |

| 互联网 | 网页、wiki、论坛 | 高互动、低结构 |

| **Skill** | **"可执行的指令包"** | **高结构、Agent 自执行** |

Skill 是第一种"被设计给非人类读者的知识形态"。它不是给人看的（虽然人也能看），是给 Agent 看的——Agent 读完能直接做事。

这个定位如果成立，Skill 会成为**下一代"知识单位"**——类似于 PDF 之于论文、wiki entry 之于百科。

不是所有 Skill 都能走到这一步。但 Top 1%（第 3 章数据里 617 个占了 83% stars 的那批）里面，有一部分会。

---

1.8 自我反省：Skill 不是银弹

前面都在讲 Skill 的好处。但在本章结尾，要提醒几个现实限制——

限制 1：Skill 不是能力替代

Skill 只能把"已有的能力"组织得更好。如果模型本身不会写 Rust，给它 100 个 Rust Skill 也没用。

Skill 让 Mahesh 变成 Barry，但前提是 Mahesh 是 Mahesh。给一个智商 80 的人再多 Barry 的笔记也不行。

这对产品选型的含义是：**Skill 生态和大模型能力是互补的，不是替代**。Anthropic、OpenAI 的模型持续升级，Skill 的价值上限才会升级。反过来，如果底层模型退步，Skill 也会失效。

限制 2：Skill 不解决 alignment 问题

Skill 告诉 Agent "怎么做"，但**做得对不对**还要看模型的价值判断。

一个 Skill 可以写"遇到客户请求违规操作，婉拒并报告"。但这个指令能否被 Agent 真正遵守，取决于模型的 alignment 水平，不取决于指令写得多清楚。

**Skill 不是安全机制。** 需要硬约束的地方还是要靠 guard rails、policy engines、human-in-the-loop——不能只靠 Skill 里的一句"不要做 X"。

限制 3：Skill 会过时

Skill 是文本指令。当它依赖的外部工具、API、数据格式变化时，Skill 不会自动更新。

第 3 章的"僵尸王图鉴"已经证明了——一个 2 万 star 的 Skill，停更 188 天，你依然能装、依然能用，但它产出的结果可能是**过时甚至错误的**。

这是 Agent Skills 生态比普通软件包**更危险**的地方——普通软件包废弃了用户会收到警告；Skill 废弃了用户悄无声息继续用。

这是第 10 章"Verified Creator"要解决的问题之一——**把"持续维护"做成一个可被观察的信号**。

---

1.9 本章要记住的一句话

**Skill 的本质是"把 Barry 的 30 年经验中可写的 60-70%，以最小摩擦传给下一个 Mahesh"。这件事在 2024 年是想法，在 2026 年 Q1 变成了事实上的工业标准——因为格式化压力终于到了。**

接下来几章的所有讨论，都建立在这个前提之上——Skill 已经赢了其他扩展机制，不是因为它更强，而是因为它门槛最低，所以规模最大。规模之后的问题是：**怎么在几万个 Skill 里筛出能用的？怎么让写 Skill 的人持续活下去？这些问题的答案，就是接下来 11 章的内容。**

---

**下一章**：[第 2 章 · 三层渐进加载：Skill 的真正魔法](ch02-three-layer-loading.md)