让AI互相审查：一个烧钱但真管用的工程方案

有梦就有缘

【让AI互相审查：一个烧钱但真管用的工程方案】

快速阅读： Anthropic工程师发现Claude在长时间编程时有两个顽固问题：越写越焦虑、评估自己的代码时睁眼说瞎话。解决方案是让多个Claude互相制衡，代价是时间和钱都多花了好几倍。

---

Claude写代码有两个让人抓狂的毛病。

第一个叫“context anxiety”——上下文窗口快满了，它就开始慌，草草收工，交出半成品。第二个更经典：让它评审自己的代码，它总夸得特别起劲，即便那代码用起来根本跑不起来。

Anthropic工程师的解决思路借鉴了GAN（生成对抗网络）——让一个Claude负责生成，另一个Claude专门挑刺。不让同一个模型又当运动员又当裁判。

结果是一套三角架构：Planner把一句话需求扩展成完整产品规格，Generator按规格一个功能一个功能地写，Evaluator用Playwright真实点击运行中的应用，找出实际能复现的bug，再给出明确的失败报告。

实测对比同样的游戏开发需求：单个Claude跑了20分钟花了$9，生成的游戏核心功能是坏的，控制角色毫无响应；完整harness跑了6小时花了$200，游戏能玩，还顺手集成了AI辅助设计关卡的功能。

有网友一针见血：“卖铲子的告诉你，解决铲子问题的方法是买一堆更小的铲子。”这个批评不是没道理。整个方案的前提是你愿意承担额度消耗速度提升三到五倍的代价。

有经验的开发者提到，其实很多人早就在用类似的多智能体流水线，只是没有“harness”这个正式叫法。还有观点认为，与其堆更多Agent，不如把任务定义本身做得更精确——大多数情况下烂结果的根源在需求模糊，不在缺少监工。

文章也诚实地说：随着模型变强，harness里的某些组件会变成不必要的负担，应该及时拆掉。Opus 4.6出来后，他们就去掉了“每次sprint之间重置context”这个之前必须依赖的步骤。

一个值得记住的判断：评估器有没有价值，取决于任务是否超出了当前模型单独能可靠完成的边界。模型在边界内，评估器是浪费；在边界外，它就是关键防线。

这条边界会随着模型更新持续移动。今天必要的脚手架，下个版本可能就该拆了。

ref: www.anthropic.com/engineering/harness-design-long-running-apps

##