夜雨聆风Anthropic 从去年10月份提出 Agent Skill 这个行业标准以来，已经过去大半年了。这段时间，我收藏并使用过各种大神写的 Skill，每一个单独看都觉得很不错，但始终没办法把它们很好地整合进自己的工作流程里，而且自己动手写的 Skill，也总觉得差了点意思。最近看了 Matt Pocock 的一段关于如何写好 Agent Skill 的视频，很受启发。
一、什么是 Skill Hell
所谓 Skill Hell，本质上是一种"学得很多、用得很差"的循环。表现出来就是：不断收藏、积累各种 Skill，却始终没有真正理解它们内部是怎么运作的，更谈不上把它们有效整合起来，发挥出应有的价值。
这不是一件新鲜事。软件工程史上已经出现过类似的循环，比如"教程 hell"和"框架 hell"。这一次，只是同样的模式换了个场景，出现在了 AI Skill 这件事上。表现也很相似：Skill 层出不穷，每天都在努力学习，投入了大量时间和精力，但收效甚微，始终没能从"不断吸收新东西"走到"真正掌握和运用"这一步。
二、为什么会出现 Skill Hell
作者 Matt Pocock 认为，这是一种必然的结果：AI 智能体生态系统正处在爆发式增长阶段，而缺乏行业标准和工程上的严谨性，就必然会出现这样一种失效模式。具体可以从三个层面来理解。
第一，缺乏统一的评价标准。目前行业里还没有一套公认的准则，可以用来判断一个 Skill 到底写得好不好。因为缺乏客观的评估框架，企业很难把已有的标准作业流程（SOP）可靠地转化成 Agent 可以执行的具体步骤；对个人开发者来说，也很难在众多 Skill 里分辨出哪些是臃肿的、误导性的，或者效率低下的，从而做出明智的取舍。
第二，碎片化集成带来的不确定性。开发者往往习惯不断安装、尝试各种新的 Skill，但每个 Skill 都被当成一个孤立的黑盒来看待，缺乏系统性的思考。这种堆砌方式，导致 Skill 之间没办法有效协作。开发者既不清楚这些 Skill 内部到底是怎么运作的，也说不清楚为什么某些 Skill 在关键时刻会触发失败。
第三，认知负荷和性能成本之间的失衡。很多 Skill 采用"模型调用"的方式，也就是它的描述会始终占据在 Agent 的上下文里。当同时挂载几十甚至上百个这样的 Skill 时，Agent 的上下文窗口就会被大量描述信息填满，带来不小的认知噪声和 token 成本。与此同时，模型本身在决策时也存在不确定性，这两者叠加起来，就容易出现该被触发的 Skill，到了真正需要的时候却没有被触发的情况。
除了这些外部因素，Skill 内部也会随着时间产生问题，比如过时、冲突或者已经不再必要的内容不断堆积，让 Skill 变得越来越臃肿、越来越难维护。
正是这几方面的原因交织在一起，才让 Skill Hell 成了当下这个生态里一种普遍存在的现象。这也是作者做这次分享的目的：提供一份检查清单，让人可以据此审视一个 Skill 内部的各个方面，确认它是否达到了预期效果，以及如何改进它。
三、检查清单总览
作者给出的检查清单包含四个部分：
触发（Trigger）：决定一个 Skill 在什么时候、以什么方式被激活。 结构（Structure）：决定一个 Skill 内部是怎么搭建和组织起来的。 引导（Steering）：让 Agent 真正有效地用起这个 Skill，按照预期去执行。 精简（Pruning）：确保这个 Skill 随着时间推移，始终保持精悍、不臃肿、不过时。。
这四个部分大致对应了写一个Skill的先后阶段：先决定Skill怎么被触发，再搭建内部结构，然后想办法让Skill真正起作用，最后再做一轮瘦身。
四、触发：用户调用还是模型调用
Skill 可以分为"用户调用"（user invoked）和"模型调用"（model invoked）两种方式。这两者的核心区别在于，究竟是谁来发起触发这个动作，以及由此带来的资源消耗和确定性上的差异。
任何一个 Skill，都可以由用户手动调用：Skill 文件放在文件系统里，只要用户告诉 Agent 去用这个 Skill，Agent 就能读取里面的内容。这种情况下，Skill 平时不会占用任何 token，只有在真正被调用的时候，内容才会进入上下文。
另一种方式是由模型自己决定是否调用。这依赖于 Skill 的"描述"（description）。这段描述会始终出现在 Agent 的上下文里，也就是说，无论这个 Skill 有没有被用到，它的描述都要一直占据一部分 token。Agent 会根据这段描述自行判断，是否需要进一步读取 Skill 对应的 skill.md 文件，把里面的具体内容加载进自己的工作上下文。作者把这段描述称为"上下文指针"（context pointer）：它本身占据一小部分上下文，指向另一个包含更多细节的文件。
如果这个指针（也就是描述）不出现在 Agent 的上下文里，只对用户可见，那这个 Skill 就只能由用户手动调用，这就是"用户调用型"Skill。是否让描述进入 Agent 上下文，是一个可以配置的选项。
两种方式在几个维度上表现不同：
模型调用型 Skill 看起来更灵活，因为无论是模型自己判断需要，还是用户明确要求，它都能被触发。但每增加一个模型调用型 Skill，都会给 Agent 带来"上下文负载"（context load）：如果同时挂载了一百个模型调用型 Skill，Agent 的上下文里就会同时存在一百段描述，这会占用不少 token，也会增加 Agent 需要处理和判断的信息量。
看起来似乎应该尽量减少模型调用型 Skill 的数量，或者干脆全部改成用户调用型。但用户调用型 Skill 也有代价，叫做"认知负载"（cognitive load）：用户调用的 Skill 越多，用户自己需要记住的东西就越多，对使用者本身的熟练程度要求也就越高。
作者提到，自己的 Skill 库更偏向用户调用型，这意味着 Agent 的上下文负载更小，但对作者本人的要求更高，需要深入理解每个 Skill 才能真正用好。
这两种模式的取舍，本质上是在自主性、可预测性和成本这三者之间做权衡。作者自己更偏好用户调用型，原因在于：每一个模型调用型 Skill，都会带来一种"不可预测性"的代价。因为上下文指针只是一个建议，模型完全可能选择不去跟随这个指针，即便这个 Skill 非常适合当前任务。作者更愿意主动承担一些认知负担，来换取行为的可预测性，避免出现"Skill 明明适用，但模型没有调用它"这种情况——这也意味着不需要专门去做评测，验证 Skill 是否在正确的时机被调用，作者认为这件事本身就很麻烦，希望直接避免掉这类问题。
总结来说：用户调用是用人的勤劳换取 Agent 的稳定；而模型调用则是用昂贵的 token 和不确定性换取无感的自动化。这也是写 Skill 的第一条建议
先决定skill是用户调用型还是模型调用型。
五、结构：步骤与参考资料
讲完触发方式，作者转向Skill的内部结构。他把一个Skill拆分成两个基本组成部分：步骤（Steps）和参考资料（Reference）。
步骤是Skill要执行的一系列具体流程；参考资料则是支撑这些步骤所需要的额外信息。有些Skill可能完全没有步骤，只包含参考资料；也有些Skill只有简单的步骤，不需要任何参考资料。但把Skill拆分成这两类单元，有助于把一个Skill的内容想清楚、理顺。
作者用自己的一个Skill"2PRD"举例。这个Skill的作用是根据当前上下文生成一份产品需求文档，它包含三个步骤：找到相关上下文、和用户确认测试边界（test seam）、撰写产品需求文档。对应这三个步骤，需要用到两份参考资料：一份说明"什么是测试边界"，另一份是产品需求文档的模板。
写一个新 Skill 时，先确定需要哪些步骤，再确定这些步骤各自需要什么参考资料，把参考资料单独放在 Skill 的对应位置。
每个Skill由三部分组成：描述、skill.md 主文件，以及从主文件延伸出去的各种参考资料。如果能把 skill.md 主文件做得足够小，会带来多方面的好处：更容易维护、更容易审查、需要阅读和思考的内容更少，而且每减少一个词，就相应减少了Skill调用时的 token 成本。
尽可能让主文件（skill.md）保持精简。
一种让Skill变小的有效方法，是思考Skill的"分支"（branch），也就是这个Skill可能被使用的不同场景。如果某份参考资料只在某一种使用场景下才会用到，那么这份资料就可以从主文件中移出去。
作者以"2PRD"和"domain modelling"两个Skill做对比。"2PRD"这个Skill每次都会用到同样的参考资料（测试边界说明和 PRD 模板），因为它只有一种使用场景，所以这些资料适合直接放在主文件里。而"domain modelling"这个Skill会做两件不同的事情：更新一份本地术语表（context.md），或者创建架构决策记录（ADR）。也就是说，它至少有两到三种不同的使用场景，每种场景所需要的模板并不相同。这种情况下，就不需要把 ADR 模板或 context.md 模板都放进主文件里，而是可以把它们分别移到独立的文件中。
具体做法是：在主文件里放一个指向该资料的"外部引用"（external reference），也就是一句话告诉 Agent，如果需要某个模板或需要更新某个文件，去某个具体文件里找。这个引用文件和Skill打包在一起，Agent 可以很方便地读取。
如果一个 Skill 可能被用于多种不同场景，就把只对应特定场景的参考资料，用外部引用的方式移出主文件，从而让主文件保持精简。
六、引导：如何让 Agent 按照预期行事
第三个维度是引导（Steering），也就是如何让 Agent 真正按照 Skill 里写的去做，而不是"看起来说清楚了，但 Agent 还是没照做"。这个维度主要针对两种场景：一种是 Agent 的行为方向跑偏，做得不够精准；另一种是 Agent 为了赶进度、尽快完成任务，而对某个前置步骤敷衍了事。这两种场景对应两种不同的应对方法。
第一种场景：用引导词校正行为方向
作者给出的核心技巧是"引导词"（leading words）。这类词的特点是：用很短的篇幅，承载了比较丰富的含义。把这类词写进 Skill 的文本里之后，它们会作为推理过程中的一部分文字，进入 Agent 的思维链。当 Agent 在推理中反复用到这些词时，这些词背后关联的知识和固定的行为模式就会被调动起来，从而影响最终的输出。
作者用一个具体例子来说明。一个常见的问题是，Agent 在处理一个较大的任务时，倾向于"按层"来实现：先把数据库层全部写完，再写所有的接口，再写前端，而不是像人类通常做的那样，先做一个能跑通的小范围功能，尽早获得反馈，再逐步扩展。
要解决这个问题，可以直接告诉 Agent"不要按层写代码，先做一个小的切片"，但作者提出了另一种做法：用"垂直切片"（vertical slice）这个词作为引导词。这是软件开发中一个已经存在的、有共识含义的术语，用它可以触发 Agent 已有的知识背景，让 Agent 更容易理解具体想要的是什么。作者强调，重点不是简单地写两个字"垂直切片"就完事，而是把这个短语所承载的含义，在 Skill 全文中反复使用。
判断这个技巧是否奏效的方法很直接：只要在 Skill 里使用了"垂直切片"这个词，就可以去看 Agent 的推理过程，如果里面出现了"我们要做一个薄的垂直切片"这类表述，说明这个词真的被 Agent 接收并使用了，随之而来的实现方案通常也会更好。
这种方法适合用在这样的场景：Agent 的表现偏通用、偏平庸，没办法精准地按照某种特定风格或工程规范去做事。这时候就需要去找一个更有力的引导词。
作者提到，很多人在听到这个技巧后，会觉得自己其实早就在这么做了——用一些简短的短语去引导 Agent。作者的建议是：把这种做法系统化、一致地使用在 Skill 全文中，并且持续观察推理轨迹里 Agent 是否真的采纳了这些引导词。如果 Agent 没有按预期行事，就需要让引导词更一致、更有力，或者尝试寻找别的候选词。作者认为英语本身提供了非常丰富的选择空间，而且 Agent 本身也能帮忙想出合适的候选词。
当 Agent 的行为方向不对、表现过于通用时，去找一个已有共识含义的词作为引导词，并在 Skill 全文中反复、一致地使用它，同时观察 Agent 的推理过程，确认这个词真的被采纳了。
第二种场景：拆分技能，隐藏后续步骤
第二个引导相关的技巧，处理的是另一种问题：Agent 在某个步骤上投入的功课（legwork）不够。这种情况通常发生在 Agent 能看到后面还有一个更重要的目标时——它会为了尽快抵达那个目标，而在当前这个前置步骤上草草了事。
作者举了一个非常普遍的例子，"plan mode"（规划模式）。这种模式通常包含两个步骤：先提出澄清性问题，再制定计划。作者观察到，几乎所有实现了 plan mode 的系统都存在同一个问题：提问澄清这一步总是敷衍了事。因为 Agent 把"制定计划"当作最终目标，所以它在提问阶段只是简单问几个问题，就急着去生成计划了。
作者的解决办法是：不使用一体化的 plan mode，而是把"提问澄清"单独拆分成一个 Skill，叫做"grill with docs"。这个 Skill 只负责提问澄清这一件事，Agent 在执行这个 Skill 时，只能看到这一部分的内容，看不到后面"生成计划"这一步。等这个 Skill 执行完，再进入另一个独立的 Skill"2PRD"去生成计划。也就是说，虽然逻辑上是两个先后的步骤，但 Agent 在执行每一步时，只看得到当前这一步，看不到后面还有什么。
这种做法能让 Agent 在当前步骤上投入更多精力，也就是花更多的思考时间和 token，因为它看不到后面的目标，也就不会急着往后跳。作者提醒，这种拆分不是每个场景都需要，只有在某个前置步骤容易被忽略或草率对待时才有必要，但在需要的场景下，这个方法非常有效。
如果发现 Agent 总是在某个前置步骤上敷衍了事，可以把这个步骤单独拆成一个 Skill，让 Agent 在执行这一步时看不到后面的步骤和最终目标，强制它把注意力和精力都放在当前这一步上。
总的来看，这两种引导方式解决的是不同层面的问题：引导词解决的是"做得对不对"，也就是让 Agent 的行为方向和风格更精准；拆分技能、隐藏后续步骤解决的是"做得深不深"，也就是防止 Agent 为了赶进度而在某个环节上偷工减料。
七、精简：把Skill修剪得尽可能小
第四个部分是精简（Pruning）。作者把这一部分定义为一系列常见问题的快速排查。
第一个明显的问题是Skill体积过大。作者指出，庞大的Skill通常是其他问题的外在表现，也就是说，Skill太大往往是别的毛病造成的结果，而不是原因本身。
第一种常见毛病是内容重复。作者建议，每一份参考材料都应该只有一个"唯一来源"（single source of truth）。比如一个 PRD 模板，或者更小的一个概念，比如"什么是测试边界"，都不应该在多个地方被重复描述，也不应该让多个步骤各自单独重复覆盖同一块内容。
检查 Skill 里是否有内容被重复描述，确保每一份参考材料、每一个概念都只在一个地方出现，不在多个步骤里各自重复覆盖。
第二种毛病，作者称之为"沉积物"（sediment）。这种情况常见于多人共同维护同一份文档的场景：每个人都往里添加自己的内容，但没人敢删除或修改别人写的东西，久而久之，文档里堆积了大量往往和Skill本身已经无关的内容，尤其是那些没有被妥善组织进结构里的内容。遇到这种情况，作者建议首先检查结构：看新添加的内容是不是和某个具体分支相关，如果是，就把它移动到对应的分支里；如果完全无关，就直接删除；如果内容已经过时，也应该直接删掉。
定期检查 Skill 里是否堆积了"沉积物"，把和具体分支相关的内容归位，把无关或过时的内容直接删掉。
第三种毛病是"空操作"（no-ops），也就是那些看起来在起作用，但实际上并不真正影响 Agent 行为的内容。作者举了一个例子：假设一个"实现代码"的Skill里有一整段话，要求 Agent 撰写详细的提交信息（commit message）。如果把这段话删掉会怎样？作者认为，即便删掉，Agent 大概率仍然会写出一条相当不错的提交信息。这说明这段话其实并没有真正改变 Agent 的行为，属于可以删除的内容。
对 Skill 里每一段看起来"应该有用"的内容做删除测试——删掉它，观察 Agent 的行为是否真的发生变化。如果没有变化，说明这段内容是空操作，可以直接删掉。
总的来看，精简这一步要处理的是三类不同的问题：内容重复，需要确保每个信息只有一个来源；沉积物，需要定期清理堆积但已经无关或过时的内容；空操作，需要靠删除测试来识别那些看似有用、实则不影响 Agent 行为的内容。做完这一轮排查，Skill 才能真正保持精悍，而不是随着时间推移越变越臃肿。
最后
把前面几章提到的建议重新梳理一遍，可以整理成这样一份清单：
第一条，写 Skill 时，先决定它是用户调用型还是模型调用型，想清楚自己愿意承担的是上下文负载，还是认知负载。
第二条，确定 Skill 需要哪些步骤，再确定这些步骤各自需要什么参考资料，把参考资料放在对应的位置。
第三条，尽可能让主文件（skill.md）保持精简，减少维护、审查和 token 上的成本。
第四条，如果一个 Skill 可能被用于多种不同场景，把只对应特定场景的参考资料，用外部引用的方式移出主文件。
第五条，当 Agent 的行为方向不对、表现过于通用时，找一个已有共识含义的词作为引导词，在 Skill 全文中反复、一致地使用，并观察 Agent 的推理过程，确认这个词真的被采纳了。
第六条，如果发现 Agent 总是在某个前置步骤上敷衍了事，把这个步骤单独拆成一个 Skill，让 Agent 执行这一步时看不到后面的步骤和最终目标。
第七条，检查 Skill 里是否有内容被重复描述，确保每一份参考材料、每一个概念都只在一个地方出现。
第八条，定期检查 Skill 里是否堆积了"沉积物"，把和具体分支相关的内容归位，把无关或过时的内容删掉。
第九条，对 Skill 里每一段看起来"应该有用"的内容做删除测试，如果删掉之后 Agent 的行为没有变化，就把这段内容删掉。
这九条建议大致对应了写一个 Skill 的完整过程：先决定它怎么被触发，再搭建内部结构，然后想办法让它真正按预期起作用，最后再做一轮精简。
把这份清单放在手边，写 Skill 或者审查别人写的 Skill 时，都可以拿出来逐条对照。
───────── END ────────
AI在加速世界，但你可以选择慢下来思考
关注我，一起思考AI
👇👇👇
