同一类任务不断出现，而且每次都要重新解释做法。
Skill：把经验封装成可复用能力
约 830 字大约 3 分钟
2026-05-25
Skill 是把一套可复用做事方式封装起来，让 Agent 在合适任务中按稳定流程工作。
SKILL SYSTEM
Skill 不是更长的 prompt，而是把一套稳定做法封装成可复用能力。
它最适合处理那些“反复出现、流程固定、做错代价高、团队还会继续复用”的任务。没有这几个前提，沉淀出来的通常不是 skill，而是一段很快过期的说明。步骤、输入、输出和检查点已经比较固定，不是每次都换思路。
做错会带来明显返工、误删文件、越权操作或质量回退。
不仅你自己会反复用，团队里的其他人和其他任务也会用到。
SKILL SHAPE
一个能长期复用的 skill，至少要把这四块讲清楚。
- 触发条件什么时候应该启用，什么任务不要启用。
- 执行步骤先读什么、再做什么、做到哪里停止。
- 脚本 / 模板 / 资料把可复用资产跟流程一起打包，而不是只留一句提示词。
- 验证与退出条件怎么判断做完，失败时该如何回退或交还给人。
ANTI-PATTERNS
- 把一次性任务也做成 skill，结果只有自己看得懂，几天后就失效。
- 把项目事实写进 skill，而不是写在 README、规则文件或源码里。
- 把 skill 当成万能插件，什么都想让它包办。
- skill 已经沉淀了流程，却不补验证和退出条件。
为什么需要 Skill
复杂任务往往不只是一个 prompt。它还包含触发条件、步骤、检查清单、参考资料、脚本、模板和输出规范。只靠每次临时解释，很难保证不同人、不同任务、不同轮次里都保持稳定。
Skill 的价值就在这里：它把“团队希望 Agent 怎么做这类事”封装起来，让这套做法可以被重复触发，而不是每次都从零开始讲。
Skill 不是什么
| 不是 | 为什么 |
|---|---|
| 普通提示词 | Skill 往往包含资源、脚本、模板和多步骤流程 |
| 万能插件 | Skill 只适合稳定、可重复、边界清楚的任务 |
| 项目文档替代品 | 项目事实仍应在代码、README、spec 和规则文件中 |
| 自动正确保证 | Skill 只是提高流程稳定性，仍要验证输出 |
这也是最容易误解的地方：你可以把一条 prompt 写得很长，但那不一定就是 skill。只有当它把“何时触发、怎么做、做到哪里停、出了问题怎么办”这些元素组织清楚，它才更接近真正可复用的能力。
Skill 结构
一个能长期复用的 skill，通常至少要讲清四件事：
触发条件什么时候应该启用，什么时候不该启用。执行步骤先读什么、再做什么、按什么顺序推进。可复用资产脚本、模板、资料、参考文件、组件、提示词框架。验证与退出条件什么叫完成，失败时怎么处理，何时交还给人。
如果缺少最后一块，skill 很容易变成“看起来有流程，实际上没人知道什么时候该停”。
什么时候值得沉淀
不是所有经验都值得变成 skill。更适合沉淀的通常有四类信号：
重复出现同一类任务反复出现，每次都要重新解释。流程稳定步骤已经比较明确，不需要每次都换做法。代价较高做错会带来明显返工、越权或质量回退。多人复用不只是你自己会用，团队里其他人和其他任务也会用到。
满足得越多，就越值得做成 skill。
什么不适合做成 Skill
下面这些东西更容易做成“过度包装”而不是 skill：
- 一次性任务
- 仍在频繁变化的流程
- 明显依赖人工判断、没有稳定输入输出的工作
- 已经能直接写在 README、规则文件或代码里的项目事实
如果一个流程本身还不稳定，先把它做顺，再考虑沉淀，不要过早封装。
核心判断
Skill 解决的不是“让 Agent 自动变对”，而是“把一套已经证明有效的做事方式稳定复用”。
如果一个流程还在不断变化，先把它做顺；如果一个流程已经反复出现、边界清楚、代价不低，再考虑把它沉淀成 skill。
