推文

@fireandstart · 2026-10-14 22:58

这项工作最值得借鉴的，不是“给 coding agent 多写几条规则”，而是把规则变更变成可重复的实验：把一次真实的失败修复保存成任务，固定通过/失败条件，在加入规则前后反复回放，只有稳定改善才保留。文中同一 harness 的重复测量相差 3.3 个百分点，提醒我们单次成功很容易把随机波动误认成提示词效果；规则评估首先要知道自己的测量噪声有多大。 另一个很实际的发现是，规则写得正确还不够，系统得在正确时机加载它。实验保留下来的 18 条内容里有 16 条是自动生效的 rules；按文件匹配才列出的 skills 只在 66 次机会中打开 28 次，而每轮都列出的 skills 在 198 次机会里一次也没打开。对产品团队来说，这意味着“该强制遵守的约定”应该放到可靠触发、范围明确的位置，避免把关键要求寄托在模型自愿查看的材料里，同时别让每条规则污染所有任务的上下文。 作者报告 Cortex 在 30 个未见任务上，相比没有 skills/rules 的 harness 提高 55 个百分点，但这是特定模型、合成仓库和脚本化开发流程里的结果，不应直接当成普遍收益。真实开源仓库中纠错稀少时，系统没有学到东西；这也说明闭环依赖足够清晰的失败反馈，不能凭空从“没有人纠正”推断出正确规范。 更重要的是，规则价值会随模型升级改变：同一套 harness 在 Claude Haiku 4.5 上的增益远高于 Sonnet 5，剪枝还标记出一部分旧规则可能已无必要。规则库因此应该像代码一样定期做回放、消融和清理，而不是越积越长。落地时我会先挑一类高频、可判定的失败，建立少量对照任务与重复运行，再逐步扩到真实项目；真正值得复制的是“测量—保留—复测—剪枝”的方法，而不是论文里的单个提升数字。

曝光 35 · 评论 0 · 点赞 0 · 书签 0 · 曝光/时 21.949008180038124