一、Skill 文档不是越厚越好
我写 Agent Skill（就是给 AI 的指令文档）有一段时间了。一开始的逻辑很简单：Agent 没按预期做，就加一条规则；写作不像人，就加一段风格描述；流程跑偏了，就补一份步骤说明。
几轮下来，最常用的一份 Skill 长到了 800 多行。看起来面面俱到，但实际效果呢？Agent 有时照做，有时跳过，有时读了也没变。我也不敢删——每行当时加的时候都觉得有用，删了怕出问题。
后来读到 Matt Pocock 在 AI Engineer 大会上的演讲《Building Great Agent Skills》，里面提到一个概念叫 Skill Hell：规则越堆越多，但没人知道哪句真的在起作用。
我对着自己的 Skill 逐条审查，发现确实中了。今天把这五个方法结合我的实践整理出来。
二、方法一：主文件留入口，参考材料放到旁边
我以前习惯把所有东西塞进一个文件——步骤、模板、配置、术语表，全在同一个 markdown 里。今天有人加一段，明天有人补一条，文件越来越长，但真正告诉 Agent「下一步做什么」的有效内容没有变多。
Pocock 的建议很简单：主文件只放公共入口——什么时机触发、按什么顺序执行、遇到分支去哪里取材料。模板、样例、配置细节，全部拆到单独的文件，Agent 需要时才去读。
我试了一下，把内嵌的配置表格（账号的字数范围、平台格式要求）全部替换成一行 cat 指令，把一段 50 行的架构参考挪到单独文件中，把一份伪代码速查也拆了出去。
改动后主文件从 831 行减到 636 行，瘦了将近四分之一。关键步骤的执行逻辑没有减少，只是换了一种组织方式：文件短了，Agent 每次加载的无关内容少了，我也敢改了。
三、方法二：一个短词，比一段规则管用
Pocock 讲到另一个很实用的点：找 leading words——少数几个短词，锚定一整套做法。
他举的例子是 vertical slice。Agent 做大型需求时，习惯横着铺（先写数据库层、再写 schema、再写 API），这个词能把做法拉回「先做一个能跑通的小切片，早验证再外扩」。
我发现我自己的 Skill 里写了很多长句规则，比如「未经核实的数据不要使用，必须附上来源链接」。换成 verified 一个词就够了——和团队约定好这个标签的含义，Agent 看到它就自动执行核实流程。短词的好处是 Agent 容易记住，也容易在输出中检查它有没有照做。
这其实和软件工程里的小团队黑话是一个道理——你说「红绿重构」，熟手就知道先失败、再通过、再整理。Skill 里的短词也一样，把一整套动作压进一个稳定入口，Agent 反而执行得更一致。
四、方法三：拆开流程，不让 Agent 看到终点
Agent 有一个很隐蔽的行为模式：只要它知道最终目标，就会省略前置步骤。
比如一个写作 Skill，要求 Agent 先调研主题、再确认角度、再撰写初稿。但只要最终目标是「写出一篇文章」，Agent 就会匆匆问两句就动笔，调研经常被挤掉。
Pocock 的做法是把调研拆成单独的 Skill，Agent 在当前阶段只看到一件事，做完再交给下一个。
我的流水线其实已经拆成了写作→优化→配图→审核四个阶段，但写作内部仍然是把调研和撰写放在一起。这一步可以继续拆——先让 Agent 只做素材收集和调研，交付确认后再启动写作稿。不是什么场景都适合拆，但优先级高、容易出错的阶段值得单独抽出来。
五、方法四：删掉不会改变结果的句子
这是整场演讲里我最受触动的一条。Pocock 给出的删除测试很简单：删掉一句话，再看 Agent 的输出有没有变化。没变化，就别留。
我对着自己的 Skill 逐行审，发现了三类可以删的内容：
重复内容——同一个表格出现在两处（复制粘贴的 bug），同一个约束条件在同一段中出现两次。删掉后 Agent 的行为没有任何变化，但每次少背了一行。
归档参考——一段从其他模块继承来的架构说明，标注了「已归档」。当时留着没删是怕以后参考，但 Agent 每次都要读。把它挪到单独文件后，主文件瘦身 50 行。
内嵌数据——把配置文件中已有的字数范围、平台格式写在 Skill 里。Agent 读到两份冲突的数据时不会自动选择对的那份，只会造成混乱。改用 cat 指令实时读取后，Source of Truth 归一了。
Pocock 说人读文档时会自动跳过废话，Agent 不会。它会把每一句都当成可能有用的上下文，哪怕那句话只是过去某次调整留下的礼貌性提醒。
六、方法五：分入口，别让 Agent 自己判断该不该用
Skill 的触发方式有两种：用户手动调用和模型自动发现。很多人喜欢自动触发，因为少一步操作。
但每多一个「模型可触发的 Skill」，Agent 每次请求就要多背一条描述，也要多做一个选择——该不该用这个 Skill。几十个以后，模型的注意力已经被入口拖住了。
Pocock 的建议很实用：高频、低风险、边界清楚的，让模型自动发现；低频、影响大、需要人判断时机的，手动触发。
我检查了自己的 Skill 配置。大部分技能是手动触发的——用户说「开始写文章」才启动流水线，这个设计是对的。但有些触发词的边界不够清晰，后续可以把 trigger 字段做一次清理，让每个技能的触发条件更窄、更明确。
七、改完之后的变化
这次改造最大的感受不是 Skill 变短了，而是我敢删了。
以前加规则很容易——发现一次问题就补一条——但删规则很难，因为每行都有心理账：「万一以后用得上呢」。Pocock 的删除测试给了我很具体的验证方法：删了跑一次，输出没变化就说明这段规则在沉默地消耗上下文，但没有产生价值。
这个验证标准也可以倒过来用：下次加规则之前，先想一想这句规则在未来某次运行中，会不会改变 Agent 的行为。如果大概率不会，就别加。
Skill 不是越厚越专业，能让 Agent 稳定做对事才算数。