如何设计一个好 Skill
好 Skill 的三个特征、四类结构要素、从团队流程找机会的方法，以及最常见的失败模式。
好 Skill 的三个特征
写一个 Skill 很容易——本质上就是写文档；写一个好 Skill 很难，因为它考验的是你对自己业务流程的理解深度。我们在实践中总结出好 Skill 的三个核心特征：
- 渐进披露（Progressive Disclosure）：Skill 的入口部分只保留触发条件和概览，详细流程、脚本、参考资料按需分层加载。这样既不浪费上下文窗口，又保证深度信息触手可及。类比一个设计良好的官网首页：首屏给方向，详情页给细节。
- 边界清晰：明确写出”这个 Skill 什么时候该用、什么时候不该用”。边界模糊的 Skill 会被 Agent 在错误的场景里调用，比没有 Skill 更糟。
- 可验证：包含验收标准或校验步骤，让 Agent（和人）能判断”这件事做完了没有、做对了没有”。没有验证闭环的 Skill，输出质量只能靠运气。
这三个特征背后是同一个原则：Skill 不是写给人看的散文，而是写给一个”聪明但没有常识的新员工”看的可执行程序。
结构要素：触发条件、步骤、示例、反例
一个结构完整的 Skill 通常包含四类要素：
- 触发条件：什么任务、什么关键词、什么上下文状态下应该激活这个 Skill。写得越具体，误触发越少。
- 流程步骤：把任务拆成有顺序、可执行的步骤，每一步说清楚输入、动作和输出。步骤之间允许有判断分支，但不要用”视情况灵活处理”这类含糊表述——那是把难题踢回给模型。
- 示例：至少一个完整的输入—输出对。示例的信息密度远高于抽象描述，模型从示例中学到的模式往往比从规则中学到的更可靠。
- 反例：明确指出常见的错误做法和”看起来对但其实错”的输出。反例是团队踩坑经验的直接沉淀，也是好 Skill 与平庸 Skill 的分水岭。
这四要素与 Anthropic 的 Agent Skills 规范（SKILL.md 格式）是一致的：元数据负责触发，正文负责流程与示例，附属资源（脚本、模板）负责重活。如果对背景概念不熟，可以先读《Skills：把程序性知识交给 AI》。
从哪里找 Skill 机会：高频重复的团队流程
不要凭空设计 Skill，去团队的日常流程里找。一个值得写成 Skill 的流程通常满足三个条件：高频（每周都在发生）、重复（每次步骤大致相同）、有成熟的最佳实践（团队里已经有人做得明显更好）。
典型例子包括：发布检查清单、客户咨询的标准应答流程、代码评审的关注点清单、周报的生成与汇总、新员工的入职引导。这些流程的共同点是：老手做得好、新手做不好、而两者的差距恰恰是可以写下来的经验。判断方法很简单——如果一件事你已经给同事口头讲过三遍以上，它就值得变成一个 Skill。
反过来说，一年只做一次、或者每次做法都截然不同的流程，不适合做 Skill——前者 ROI 太低，后者说明流程本身还没有沉淀出稳定模式。
常见失败模式与小结
实践中最常见的四种失败：
- 过长：把所有细节塞进一份文档，上下文被占满，关键指令反而被稀释。解法是渐进披露，把内容分层。
- 含糊：充满”适当""合理""注意质量”这类无法执行的表述。解法是每条指令都问一句”照字面执行能做到吗”。
- 无验证：没有验收标准，做完即结束。解法是强制加一节”完成前检查”。
- 边界漂移：一个 Skill 试图覆盖太多场景，最后哪个都覆盖不好。解法是拆分，让每个 Skill 只做一件事。
小结一下：Skill 设计的本质是把隐性经验写成显性程序。你写的不只是文档，而是把”老师傅脑子里的操作直觉”翻译成机器可执行的明确指令——这个翻译过程本身就是对团队知识的一次梳理，它的价值甚至超出 Skill 本身。