anthropics-skills | 02 - Skill 解决的核心问题：把隐性经验变成显性流程

系列：《把经验封装成能力：Agent Skills 设计与落地》

本文是系列第二篇。上一篇我们回答了 Skill 是什么；这一篇继续往下走：为什么 Skill 最重要的价值，不只是复用提示词，而是把个人和团队的隐性经验变成 Agent 可以稳定执行的显性流程。

1. 从上一篇的实践任务说起

上一篇结尾留了一个练习：从最近一周反复让 Agent 做过的任务里挑一个，写下四句话。

例如：

任务名称：中文技术文章大纲生成 触发方式：用户说“帮我把这个主题整理成文章大纲” 期望输出：Markdown 格式的大纲，包含目标读者、核心问题、分节标题和实践任务 重复规则：面向工程师，结构要清晰，不要营销腔，每篇都要有一个可执行练习

这四句话看起来很简单，但它们已经触碰到 Skill 设计里最核心的问题：你脑子里那些“每次都会默认这么做”的经验，怎样才能被 Agent 稳定理解并复用？

很多时候，Agent 表现不稳定，并不是因为模型完全不会做，而是因为我们没有把任务里的隐性规则讲清楚。

比如你说“帮我写个大纲”，Agent 可能会给你一个通用大纲；你说“帮我写一份技术方案”，Agent 可能会漏掉备选方案；你说“帮我 review 这段代码”，Agent 可能会先纠结命名风格，而不是先看正确性和并发风险。

这些问题背后都有同一个根因：任务经验没有显性化。

2. 什么是隐性经验

隐性经验不是玄学，它只是那些你已经习惯了、但没有写成明确规则的判断。

在团队协作里，隐性经验通常以这些形态存在：

1. 老同学知道的排障顺序。
2. 代码审查时默认优先看的风险点。
3. 文档评审时大家心照不宣的结构要求。
4. 某类 API 接入时必须先确认的兼容性问题。
5. 处理线上问题时不能跳过的观测指标。
6. 生成周报、复盘、方案时反复强调的表达风格。
7. 某些脚本的使用方式，以及失败后应该怎么处理。

这些经验在熟手之间传递得很快，因为大家有共同背景。但 Agent 没有这个背景。它只看到当前对话、当前文件和当前可用工具。

如果经验没有被写下来，Agent 就只能猜。

而一旦进入团队场景，隐性经验还会带来三个额外问题。

2.1 经验难以复制

同一个任务，A 同学知道要先看错误日志，B 同学知道要先查配置，C 同学知道某个字段不能随便改。每个人掌握的经验碎片不同，最终输出质量就会不稳定。

这也是很多团队使用 Agent 时的第一层困扰：不是 Agent 不能做，而是只有少数会写提示词、熟悉背景的人才能让它做得好。

2.2 经验容易漂移

如果经验只靠口头传播，它会随着人、时间和场景发生漂移。

例如团队原本约定技术方案必须包含“备选方案”，但几个月后新同学不知道这件事；原本代码审查要重点看兼容性，但后来大家开始只看格式和命名；原本事故复盘要有 owner 和截止日期，后来变成了泛泛总结。

流程没有被固定下来，执行就会慢慢变形。

2.3 经验无法评估

如果经验没有显性化，就很难判断它是否有效。

你可能觉得“这样写文档更清楚”，但清楚在哪里？是标题层级更稳定，还是读者更容易找到结论？你可能觉得“这样 review 更专业”，但专业在哪里？是先看正确性，还是能覆盖并发、资源泄漏、异常处理？

一旦经验被拆成明确步骤和检查项，才有可能被评估、复盘和改进。

3. Agent 为什么尤其需要显性流程

人类协作可以依赖默契，但 Agent 协作更依赖显性流程。

原因很简单：Agent 的工作方式决定了它需要被提供清晰的任务边界、上下文和成功标准。

3.1 Agent 不拥有团队默认上下文

团队成员可能知道“我们这里的周报格式”“我们项目里的兼容性约束”“我们对外文档的表达风格”，但 Agent 不天然知道。

如果你没有告诉它，它可能会根据通用互联网语料生成一个看起来合理、但不符合团队习惯的结果。

3.2 Agent 容易被当前局部信息牵引

当上下文不完整时，Agent 会优先根据当前用户输入和附近文件做判断。

这在简单任务里通常没问题，但在复杂任务里会带来偏差。

例如你让它 review 一个函数，如果没有明确说明“先看行为正确性，再看边界条件，最后看风格”，它可能会被最显眼的命名、注释、格式问题吸引，而不是先检查真正高风险的逻辑。

3.3 Agent 需要明确的停止条件

很多任务不是“生成一段文字”就结束了，而是要满足某些完成标准。

比如：

1. 文档是否覆盖背景、方案、风险和下一步？
2. 测试是否真的运行过？
3. 输出是否符合指定格式？
4. 脚本失败时是否给出可行动的错误信息？
5. 是否需要向用户确认高风险决策？

这些停止条件如果不写清楚，Agent 很容易停在“看起来完成”的状态。

Skill 的价值，就是把这些默认上下文、执行顺序和停止条件显性化。

4. 从隐性经验到显性流程的拆解框架

把经验写成 Skill，不是把脑子里的想法一股脑写进SKILL.md。更好的方式是先把任务拆成八个部分。

4.1 触发：什么情况下该使用这套经验

触发条件回答的是：用户怎样表达时，Agent 应该想到这个 Skill？

触发可以来自关键词，也可以来自任务意图。

例如：

1. 用户说“帮我写技术文章大纲”。
2. 用户说“把这些素材整理成博客结构”。
3. 用户说“这个主题适合怎么展开成系列文章”。
4. 用户打开了某个文章草稿，并要求继续写。

这些表达不完全一样，但背后的任务意图相同。

4.2 输入：完成任务需要哪些信息

输入不是指用户当前说了什么，而是指任务真正需要哪些信息。

以技术文章大纲生成为例，至少需要：

1. 文章主题。
2. 目标读者。
3. 文章目标。
4. 读者已有背景。
5. 是否有指定风格或平台限制。
6. 是否需要代码、图表或案例。

如果这些信息缺失，Agent 应该知道是先做合理假设，还是停下来询问。

4.3 上下文：有哪些背景规则不能丢

上下文包含团队规范、业务约束、历史决策、术语习惯、风格要求。

这些内容未必每次都出现在用户输入里，但会影响最终结果。

例如：

1. 技术文章要面向工程师，不要营销腔。
2. 代码示例超过 20 行时要考虑抽象。
3. 注释要解释为什么，而不是重复代码做什么。
4. 输出 Markdown，标题层级要清晰。
5. 如果涉及变更总结，要使用中文变更主题和有序列表。

这些都是典型的可沉淀规则。

4.4 流程：先做什么，再做什么

流程是 Skill 的骨架。

一个稳定流程通常包含：

1. 识别任务类型。
2. 收集必要上下文。
3. 判断是否需要调用脚本或读取参考资料。
4. 生成初版结果。
5. 自查输出是否满足格式和质量要求。
6. 对不确定或高风险内容向用户确认。

如果没有流程，Skill 就容易退化成一堆原则。

4.5 工具：哪些工作交给脚本或外部工具

不是所有事情都应该让模型直接做。

适合交给工具的任务通常有几个特征：

1. 规则稳定。
2. 结果可验证。
3. 重复执行。
4. 出错成本较高。
5. 不需要复杂语义判断。

比如格式校验、文件转换、目录扫描、测试运行、字段检查，都更适合脚本或外部工具。

Skill 应该写清楚：什么时候用工具、怎么传参、失败时怎么处理。

4.6 输出：结果应该长什么样

输出格式越明确，Agent 越容易稳定。

“帮我整理一下”是模糊的；“输出 Markdown，包含背景、核心问题、解决方案、风险、实践任务”就清楚得多。

输出格式不仅包括结构，还包括语言风格、粒度、是否需要列表、是否需要代码块、是否需要引用来源。

4.7 校验：怎样判断任务真的完成

校验是很多 Skill 缺失的一环。

一个任务完成，不应该只看 Agent 是否生成了内容，还应该看它是否满足成功标准。

例如技术文章大纲可以校验：

1. 是否有目标读者。
2. 是否有核心问题。
3. 是否有分节结构。
4. 是否有实践任务。
5. 是否避免空泛口号。
6. 是否与系列标题和前文承接。

如果任务涉及文件或代码，还可以通过脚本校验。

4.8 边界：什么时候不该使用这套经验

好的 Skill 不仅知道什么时候该用，也知道什么时候不该用。

例如“技术文章写作 Skill”不应该接管所有 Markdown 任务；“文档处理 Skill”不应该接管数据库脚本；“Claude API Skill”在用户明确使用 OpenAI、Gemini 或其他模型供应商时，也不应该强行介入。

边界清楚，才能减少误触发。

5. 哪些知识适合沉淀进 Skill

并不是所有知识都适合写进 Skill。我们可以把可沉淀内容分成五类。

5.1 稳定流程

稳定流程是最值得沉淀的内容。

例如：

1. 写技术方案的步骤。
2. 做代码审查的检查顺序。
3. 处理 PDF 表单的操作流程。
4. 测试 Web 页面时的启动、等待、截图和日志检查流程。
5. 创建 MCP Server 时的调研、实现、测试和评估流程。

流程越稳定，Skill 的收益越高。

5.2 格式规范

格式规范也很适合沉淀。

例如：

1. 周报结构。
2. 事故复盘模板。
3. 代码评审输出格式。
4. 提交说明格式。
5. 技术文章大纲格式。

格式规范沉淀之后，团队输出会更一致。

5.3 判断准则

判断准则是隐性经验里最有价值的一类。

例如：

1. 什么时候需要向用户确认。
2. 什么时候应该优先读取源码，而不是直接猜。
3. 什么时候应该运行测试。
4. 什么时候应该拒绝执行高风险操作。
5. 什么时候该把参考资料拆分，而不是继续堆在主文件里。

这些准则能明显改变 Agent 的行为质量。

5.4 工具使用方式

很多团队都有脚本，但脚本不一定容易被 Agent 正确使用。

Skill 可以把工具的使用方式写清楚：

1. 先运行--help还是先读源码。
2. 参数怎么传。
3. 输出怎么看。
4. 失败时优先检查什么。
5. 哪些命令有副作用，需要先确认。

这类内容尤其适合放进开发工具类 Skill。

5.5 典型示例和反例

示例能帮助 Agent 对齐风格。

尤其是写作、设计、代码审查、方案评审这类主观性较强的任务，仅靠抽象规则往往不够。几个好的示例和反例，可以让 Agent 更快理解你要的效果。

但示例也要控制数量。过多示例会增加上下文负担，也可能让 Agent 过度模仿某个具体案例。

6. 哪些内容不适合直接写进 Skill

Skill 是长期复用资产，所以也要克制。下面几类内容不适合直接写进去。

6.1 密钥和敏感信息

任何 token、密码、私钥、内部账号、生产环境地址，都不应该写进 Skill。

如果确实需要访问外部服务，应通过环境变量、权限系统或 MCP 工具完成，而不是把敏感信息固化在仓库里。

6.2 高频变化的信息

如果某个规则每天都变，不适合写死在 Skill 里。

更好的方式是让 Skill 指向权威来源，要求 Agent 在执行前读取最新文档或配置。

6.3 只适用于个人偏好的细枝末节

团队 Skill 应该优先沉淀共识，而不是某个人非常个人化的偏好。

例如“我喜欢某种标题风格”可以放在个人写作 Skill；但如果是团队公共 Skill，就应该只保留团队一致认可的要求。

6.4 无法执行的口号

例如：

1. 输出要高级。
2. 代码要优雅。
3. 文档要专业。
4. 分析要深入。

这些话本身没有错，但太抽象。Skill 里更需要可执行规则：

1. 先给结论，再解释原因。
2. 每个风险项必须包含影响和缓解方式。
3. 代码审查发现问题时必须给出文件位置、风险和修复建议。
4. 文档结尾必须包含下一步行动。

可执行，才可复用。

7. 如何判断一个流程值得 Skill 化

可以用一个简单的判断表。

如果一个任务在大多数维度上都偏左，就很适合 Skill 化。

如果它只满足“高频”，但流程不稳定、边界不清、无法验证，那最好先不要急着写 Skill，而是先整理任务本身。

8. 从提示词片段到能力包

很多 Skill 不是一开始就设计得很完整，而是从一段反复复制的提示词演进出来的。

可以把这个过程分成五个阶段。

8.1 阶段一：临时提示词

这是最早期的形态。

你发现某段 prompt 很有用，于是每次复制粘贴。

例如：

请面向工程师写作，结构清晰，不要营销腔。先说明问题，再解释原理，最后给实践建议。

这个阶段成本低，但不可维护。

8.2 阶段二：提示词模板

当你发现每次都要填不同主题，就会把它变成模板。

例如：

主题：[填写主题] 目标读者：[填写读者] 输出格式：[填写格式] 写作要求：面向工程师，结构清晰，不要营销腔。

模板比临时 prompt 稳定，但仍然依赖人工复制和填写。

8.3 阶段三：结构化流程

接下来，你会发现光有模板还不够，还需要流程。

例如：

1. 先确认目标读者。
2. 再判断读者已有背景。
3. 然后列出核心问题。
4. 再设计分节标题。
5. 最后检查是否有实践任务。

这时，它已经开始接近 Skill。

8.4 阶段四：Skill 雏形

当你把触发条件、输入要求、流程、输出格式和约束写进SKILL.md，它就成为了一个 Skill 雏形。

这一步的关键变化是：经验不再散落在聊天记录里，而是进入一个可版本管理、可审查、可共享的文件。

8.5 阶段五：完整能力包

随着任务复杂度增加，你可能继续增加：

1. references/：风格指南、案例、术语表。
2. scripts/：格式检查、标题层级检查、文件转换。
3. assets/：模板、示例输入、示例输出。
4. evals/：测试 prompt 和期望结果。

这时，它就从提示词片段演进成了完整能力包。

9. 一个具体例子：技术文章大纲生成

我们用一个贯穿式例子来说明。

一开始，用户可能只是反复对 Agent 说：

帮我把这个主题整理成一篇技术文章大纲，面向工程师，别写得太营销。

这句话背后其实包含很多隐性经验：

1. 目标读者是工程师。
2. 文章应该问题导向，而不是功能宣传。
3. 结构应该有层次。
4. 每节标题要能表达明确问题。
5. 最后最好有实践任务。
6. 如果主题太大，应该拆成系列。
7. 如果涉及代码，要控制示例长度。

把这些经验显性化后，可以整理成一个任务卡片。

这张表就是写 Skill 的前置材料。

到第三篇，我们就可以把它进一步转换成SKILL.md。

10. 团队场景中的收益

把隐性经验显性化，不只是为了让个人少写几次 prompt。真正的收益在团队场景里更明显。

10.1 降低 onboarding 成本

新同学不需要靠口口相传学习所有流程。

只要 Skill 写得足够清楚，Agent 就可以在执行任务时带出团队默认规范。新同学通过使用 Skill，也能反过来理解团队是怎么工作的。

10.2 降低输出差异

同一类任务由不同人发起时，Agent 可以使用同一套流程和输出格式。

这对周报、方案、复盘、代码审查、对外文档尤其重要。统一不是为了限制表达，而是为了减少不必要的格式和流程差异。

10.3 降低流程漂移

流程写进 Skill 后，变更就可以被 review。

如果有人想调整代码审查优先级、文档结构或测试流程，可以通过修改 Skill 来完成，而不是在每个人的聊天习惯里悄悄漂移。

10.4 积累团队资产

一个成熟团队会沉淀代码库、组件库、脚本库、文档库。Skill 则是另一种资产：Agent 工作流库。

它沉淀的不是某个函数，而是“面对某类任务，Agent 应该怎么做”。

这类资产会随着团队使用而变得更稳定。

11. 常见误区

11.1 只沉淀结论，不沉淀判断过程

比如只写“代码审查要专业”，不写先看什么、后看什么、发现问题怎么输出。

这样的经验没有真正显性化，只是换了一种方式表达口号。

11.2 只沉淀格式，不沉淀质量标准

有些 Skill 只规定输出必须包含哪些标题，但没有说明每个部分要达到什么质量。

例如技术方案里有“风险”标题，不代表真的分析了风险。更好的写法是要求每个风险项包含影响、概率、缓解方式和 owner。

11.3 把所有经验一次性塞进去

经验显性化不等于越多越好。

如果一个 Skill 同时想覆盖写作、代码审查、测试、部署、排障，它很可能边界过大。更好的方式是拆成多个职责清晰的 Skill。

11.4 忽略异常路径

很多流程在顺利时很好写，但真实任务经常有缺失信息、工具失败、权限不足、需求冲突。

Skill 应该写清楚这些情况如何处理：

1. 缺少关键信息时是否询问。
2. 工具失败时是否重试。
3. 结果不确定时是否标注假设。
4. 高风险操作前是否暂停确认。

异常路径越清楚，Agent 越不容易乱猜。

12. 小结

Skill 的核心价值，不是把提示词写得更长，而是把隐性经验变成显性流程。

隐性经验包括任务触发方式、输入要求、背景规则、执行顺序、工具用法、输出格式、校验标准和边界条件。只有这些内容被结构化之后，Agent 才能稳定复用它们。

可以记住这句话：

一个值得 Skill 化的任务，通常是高频、稳定、可描述、可验证，并且有清晰边界的任务。

下一篇我们会开始进入文件结构本身，具体拆解一个 Skill 的最小形态：SKILL.md、frontmatter、name、description和正文说明应该怎么写。

13. 实践任务

请选一个你希望 Skill 化的任务，填写下面这张表。

填完这张表后，你就已经完成了写SKILL.md前最重要的一步：把经验从脑子里拿出来，变成可以被讨论、审查和迭代的流程。