Skill 的本质：可复用的专业知识封装
如果你用过 Claude Code，你可能注意到它有一个 /skills 命令，可以列出已安装的"技能"。写作规范、架构设计方法、TDD 流程、代码审查策略——听起来像一个插件市场。
Skill 不是插件。
这是理解 Skill 系统的第一条，也是最重要的一条。插件是代码——它扩展了程序的功能。Skill 是提示词——它扩展了模型的专业知识。
插件让 Agent 能做新的事（比如连数据库、调 API）。Skill 让 Agent 把已知的事做得更好（比如按特定风格写作、按特定方法论设计架构）。
Skill 是什么
一个 Skill 本质上是一个结构化的 Markdown 文件，里面包含了某个专业领域的知识、流程和规范。它可能长这样：
# 代码审查 Skill
## 激活条件
当用户请求代码审查、PR 审查或类似任务时激活。
## 审查流程
1. 先通读整个变更，理解意图
2. 检查功能正确性
3. 检查代码风格和可维护性
4. 检查安全性
5. 检查测试覆盖
6. 给出结构化反馈
## 反馈格式
- 【严重】需要立即修复的问题
- 【建议】改进建议
- 【可选】风格偏好当这个 Skill 被激活时，它的内容被注入到 system prompt 的"Skill 层"。模型看到了这些专业指导，就能按照更结构化的方式执行代码审查。
Skill 没有执行代码，没有注册回调函数，没有扩展 CLI 命令。它就是一段精心组织的提示词，在需要的时候被塞进 prompt 里。
为什么叫 Skill 而不是 Plugin
命名揭示了设计意图。
Plugin（插件）的隐含意思是"功能扩展"——它给系统增加了新的能力。VS Code 的 Python 插件给了编辑器语法高亮、调试、linting 能力。浏览器的 AdBlock 插件给了浏览器过滤广告的能力。
Skill（技能）的隐含意思是"专业知识"——它让已有的能力更专业。一个会编程的程序员和一个既会编程又懂 TDD 的程序员，“能力"都是编程，但"技能"不同。后者写代码时会自然地写测试、遵循红绿重构流程。
Claude Code 的模型已经会编程。Skill 不教它"怎么编程”，它教模型"按什么方法论编程"。
按需加载 vs. 全量注入
Skill 面临和工具系统一样的问题：上下文预算。
如果用户装了 10 个 Skill，每个 Skill 平均 500 token，全量注入就是 5000 token——占了 200K 窗口的 2.5%。看起来不多，但如果 Skill 内容更长（一个完整的架构设计方法论可能 2000+ token），或者 Skill 数量更多，这个开销就不容忽视。
Claude Code 的策略是按需加载：Skill 的描述（一句话摘要）始终在 system prompt 里，但完整内容只在激活时注入。
激活的条件由模型判断。当模型理解当前任务与某个 Skill 相关时，它会"激活"那个 Skill——实际上是通过一个特殊的工具调用请求加载 Skill 内容，系统把 Skill 的完整内容注入 prompt，模型在下一轮循环中"获得"了那项专业技能。
这和我们之前聊过的工具系统的渐进式披露是同一个思路：不用不着急加载，用了再加载也不迟。 区别是工具的描述是结构化 schema，Skill 的描述是自然语言摘要。
Skill 与 MCP 的关系
如果你读过我之前写的 MCP 渐进式披露的文章，你会注意到 Skill 和 MCP 工具在"按需加载"上有相似之处。但它们解决的是不同层面的问题：
- MCP 工具扩展的是 Agent 的行动能力——它能连什么服务、调什么 API、操作什么外部系统。
- Skill扩展的是 Agent 的认知能力——它懂什么方法论、遵循什么规范、用什么框架思考。
一个形象的类比：MCP 工具给 Agent 增加了新的"肢体"（手、脚、眼睛），Skill 给 Agent 增加了新的"知识"（经验、方法论、最佳实践）。
两者都可以按需加载，两者都受上下文预算约束，但它们的本质不同。工具是动词（做什么），Skill 是副词（怎么做）。
Skill 的可复用性
Skill 最有价值的特性不是"专业知识封装"，而是可复用性。
一个写好的 Skill 可以在不同项目、不同用户之间共享。“TDD 流程"Skill 在 React 项目和 Rust 项目里都适用。“代码审查"Skill 对任何代码库都有用。
Claude Code 的 Skill 存储在 .claude/skills/ 目录下，可以被 Git 版本化、随项目分发。团队可以共享一套 Skill 集合，确保每个成员使用的 Agent 都有相同的专业知识。
这意味着 Skill 不仅是"个人助手的能力扩展”，它还是团队知识的形式化载体。一个资深工程师的代码审查经验可以被写成一个 Skill，让团队里每个人的 AI Agent 都具备同样的审查能力。
这和 CLAUDE.md 有微妙区别：
- CLAUDE.md 是项目特定的约定（“我们这个项目用 Redux”）
- Skill 是跨项目的通用方法论（“做代码审查时遵循这个流程”）
CLAUDE.md 回答"这个项目怎么干”，Skill 回答"这类事怎么干"。
Skill 的局限性
Skill 不是银弹。它有明显的局限性：
它依赖模型的理解力。 Skill 是提示词，不是代码。模型可能"读了"Skill 内容但没有真正"遵循"。特别是当 Skill 的指导和模型的默认行为冲突时，模型可能忽略 Skill 而按照自己的习惯行事。
它不能强制执行。 Skill 说"先写测试再写代码"，模型可能反过来。Skill 说"用结构化反馈"，模型可能给出自由文本。Skill 是软约束，靠模型的合作意愿执行。
它的质量参差不齐。 Skill 的效果取决于写作质量。一段模糊的 Skill 描述导致模糊的行为，一段矛盾的 Skill 描述导致混乱的行为。Skill 需要像代码一样被审查和维护。
这些局限性的根源是同一个事实：Skill 是自然语言，不是形式化规范。 自然语言灵活但不精确，适合表达意图但不适合强制执行。
Skill 系统的哲学
Claude Code 的 Skill 系统背后有一条设计哲学：
专业知识应该被封装、复用、共享——不仅在人之间，也在 AI 之间。
这个理念比 Skill 本身更重要。它暗示了一个未来：专业知识不再只存在于人的大脑或文档里，它被编码为 AI 可以理解的格式，在需要时被激活、被应用、被迭代。
Skill 是这个未来的粗糙原型。它不完美——它是提示词而不是代码，是软约束而不是硬规则。但它指向了一个方向：知识的形式化与自动化传播。
延伸阅读：BYF 的 Skill 渐进式披露与 update-config 实践
BYF 在 Skill 系统上做了两件值得关注的事。
1. 更彻底的渐进式披露。 BYF 的 ADR 0009 明确将 Skill 列为"只注入名称 + 一行描述，完整内容通过 Skill 工具按需加载"。它的上下文最小化审查发现，技能列表全量注入会消耗 500-1500 token——在当前场景下不致命，但累积起来影响缓存效率。BYF 的策略和 Claude Code 一致：描述始终在 system prompt 里，完整内容只在激活时注入。
2. update-config 作为一个内置 Skill。 这是 BYF 最有创意的 Skill 应用。BYF 有一个 /skill:update-config 命令，代理读取 ~/.byf/config.toml，应用 Skill 本身嵌入的治理规则（废弃字段表、default_thinking 迁移、raw-passthrough 清理）以及 schema 和运行时 provider 的代码事实，审计配置并自动修复。规则随 BYF 发布，每个版本演进。
这意味着什么？Skill 不再是"辅助性的提示词"，它变成了可编程的运维工具。 update-config 不是一个说明文件告诉用户"请手动改配置"，它是一个主动行动的 Agent，读取真实文件、对比最新规则、执行修改。Skill 的边界从"告诉模型怎么做"延伸到了"告诉模型做什么——并且在它做之前注入知识"。
这个实践突破了 Skill 作为"提示词模块"的原始定位，指向了一个有趣的未来：Skill 可以是嵌入在 Agent 运行时的"领域专家"，随时准备被唤醒、被调用、被授权执行操作。
下一篇
Skill 让单个 Agent 更专业。但有些任务太复杂，一个 Agent 搞不定——即使它有所有 Skill。下一篇文章我们要拆解 Claude Code 的多代理架构：为什么一个 AI 干不过三个 AI？explore、plan、general 三种角色的分工逻辑，以及分叉-汇聚模式如何在实践中协作。
本系列基于 Claude Code 官方源码项目进行架构分析，聚焦设计思想而非代码实现。
