# Skill 的本质：可复用的专业知识封装 如果你用过 Claude Code，你可能注意到它有一个 `/skills` 命令，可以列出已安装的"技能"。写作规范、架构设计方法、TDD 流程、代码审查策略——听起来像一个插件市场。 **Skill 不是插件。** 这是理解 Skill 系统的第一条，也是最重要的一条。插件是代码——它扩展了程序的功能。Skill 是提示词——它扩展了模型的专业知识。 插件让 Agent **能做新的事**（比如连数据库、调 API）。Skill 让 Agent **把已知的事做得更好**（比如按特定风格写作、按特定方法论设计架构）。 ## Skill 是什么 一个 Skill 本质上是一个结构化的 Markdown 文件，里面包含了某个专业领域的知识、流程和规范。它可能长这样： ```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 渐进式披露的文章](mcp-claude-skills-progressive-disclosure)，你会注意到 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](https://github.com/ByronFinn/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 官方源码](https://github.com/anthropics/claude-code)项目进行架构分析，聚焦设计思想而非代码实现。