Skill 写得越长，Agent 为什么反而越不听话

一份 Skill 第一次跑偏，最自然的反应是在末尾补一句规则。第二次格式错了，再补一个示例。第三次漏掉检查，就加一句“绝对不能跳过”。

几个月后，几十行的说明长成几百行。每句话单独看都有道理，Agent 却越来越不稳定。

问题通常不在模型突然变笨，而在 Skill 已经从一套方法变成了事故补丁仓库。

Skill 不是记事本

Skill 的作用，是让 Agent 在同类任务里遵循稳定、可检查的过程。结果可以因输入而变化，过程不能每次临场猜测。

规则持续追加，会产生三种直接后果。第一，同一个要求被写在多个位置，修改时很难保证全部同步。第二，新方案已经启用，旧参数和旧示例仍留在文件里，模型只能自行选择。第三，单个任务被迫读取大量无关分支，真正的主流程反而被淹没。

这时继续强调“请认真执行”没有用。Agent 缺的不是态度，是没有冲突的路径和可以观察的完成条件。

八种常见失效

先给故障分类，再修改唯一该改的位置。

检查一份开始失控的 Skill，可以从八个方向入手。

过早完成，是任务还没做完，Agent 已经准备总结。“抽查几条，确认无误”就属于无法验收的完成标准。

重复，是同一规则散落在开头、正文、示例和检查清单里。重要内容出现得越多，不一定越安全，也可能被过度放大。

沉积，是旧参数、旧路径和旧示例没有随着方案迁移一起删除。

蔓延，是主文件塞入所有分支的知识，任何任务都要先读一遍整本手册。

空操作，是“确保质量”“不要遗漏”这类删除后不会改变行为的话。

否定式引导，是反复强调错误选项，却没有简洁写明目标行为。

样本过拟合，是把一次任务中的目录、文件名和偶然步骤误写成通用方法。

分支串线，是压缩、裁切、发布等不同功能的规则被同时加载，正确要求用到了错误场景。

修 Skill，先给故障命名

下一次运行失败时，不要立刻追加规则。先判断它属于哪类问题。

步骤没有做完，就收紧完成标准；同一句话出现多次，就建立单一事实来源；新旧方案冲突，就做一次完整迁移；只有某个分支需要的资料，就移到对应参考文件，并写清什么时候读取。

修改后还要用两组样本回归：一组是刚才失败的任务，另一组是原本正常的任务。只验证故障消失，不检查其他分支，很容易用一个新补丁换来下一次故障。

一份可以直接执行的体检

维护 Skill 时，可以逐项回答下面的问题：

• 每个关键步骤是否有明确输入、可观察输出和完成条件？
• 同一个意思是否在多个位置换着说？
• 旧术语、旧参数、旧路径和旧示例是否还在？
• 当前任务是否加载了大量无关内容？
• 哪些句子删除后不会改变 Agent 的行为？
• 是否一直描述错误选项，却没有直接定义目标？
• 换一个同类输入，这套方法还能不能工作？
• 两个功能组合使用时，规则会不会串线？
• 修复以后，旧案例和其他分支是否都回归过？

一份 Skill 维护后变短，不代表能力下降。很多时候，删掉的是重复、历史和无法执行的提醒，留下的才是方法。

Agent 不需要知道作者经历过多少次失败。它需要在正确的时机，读到唯一、清楚、能够验收的现行规则。