用更少的指令让模型执行效果更好，这种反直觉的经验在实测中反而更常见

想提升 Agent 的技能，大多数人的直觉是往 Prompt 里塞更多约束和步骤，但实测结论往往相反：当模型能力升级后，过多的指令反而会变成限制。通过对比一个 228 行的基准指令集和精简到 165 行的优化版，在通过相同质量门禁的前提下，精简版能降低约 18% 的 Token 消耗。

为什么指令越多不一定越强

我在实测中发现，很多为了补齐弱模型短板而设计的“技巧性指令”在强模型面前是冗余的。比如在处理执行计划（execplan）时，如果要求模型必须严格遵守某种复杂的固定结构，强模型可能会因为在尝试满足这个结构而分散了对核心逻辑的注意力，甚至导致不必要的工具调用。

这种现象在 Google Research 的 WikiSkill 研究中也有体现，即低层级的临时解决方案（workarounds）在模型迁移到更强版本时，往往无法通用。这就产生了一个矛盾：你为了让模型在 V1 版本稳定而写的指令，可能成了 V2 版本的枷锁。

实操精简指令集的具体路径

我尝试对 implement-execplan 这个技能进行“进化”，操作逻辑不是增加规则，而是剔除冗余。具体做法如下：

1. 删除强制性的结构要求：去掉那些要求模型必须在输出中包含的固定章节，改为仅在必要时提供条件信息。
2. 减少例行公事的记录：删掉那些要求模型不断更新状态、进行重复性 bookkeeping 的指令。
3. 将指令转化为确定性检查：如果某个环节可以通过静态检查或 Hook 拦截，就直接把逻辑移出 Prompt，交给代码层的测试集。

在这个过程中，我对比了两个版本的表现：

• 基准版本：228 行指令，强制要求详细计划结构。
• 精简版本：165 行指令，依赖模型自身的推理能力。

结果是两者都通过了同样的质量门禁，但精简版在输入和输出端的 Token 消耗降低了 18%。虽然这只是单次观察，不能证明普适性，但它验证了一个观点：模型能力的提升可以让部分 Prompt 变得过时。

经验、知识与指令的解耦

这里有个关键的认知差异：模型经历的失败案例 ≠ 必须写进指令的规则。

在实际构建 Agent 技能时，我建议将流程分为三个层级，而不是全部堆在 Prompt 里：

• 原始经验：记录模型在某个任务上失败了，原因是什么。
• 持久化知识：将经验总结为知识点，但此时还不一定需要变成指令。
• 可执行技能：只有当这个知识点能显著提升成功率，且不干扰其他路径时，才将其转化为 Prompt 指令。

这种分层能避免 Prompt 变得臃肿。很多时候，一个失败案例值得被记录在知识库里，但并不值得变成一条强制指令。

建议的技能构建工作流

与其一开始就写一套详尽的「操作手册」，我更倾向于先手动跑通。

具体的实操建议是：先在手动模式下与模型协作，通过不断的试错调整 Workflow，直到找到一个能稳定跑通的最小路径。在这个过程中，记录下所有导致失败的临界点。最后，只把那些「模型无法通过自省解决，且必须由外部干预」的约束写进指令集。

如果你发现模型升级后，原本生效的指令开始导致奇怪的报错或冗余输出，试着删掉那些约束，给模型留出推理空间，结果往往会出乎意料地好。