给 AI 套上一根缰绳
它才不会"跑着跑着就跑偏"

作者要解决两个看似无关的难题：让 Claude 做出有审美的前端设计，以及让它无人干预地写完整个应用。两者都先用提示词和 harness 优化冲到了远超基线的水平，但都撞到了天花板。他观察到两个顽固的失败模式：

作者借鉴了 生成对抗网络（GAN） 的思路：与其让一个 AI 又当运动员又当裁判，不如把"干活的"和"评判的"彻底分开。

关键洞察：把"这个设计好不好看？"这种没法回答的问题，翻译成"它符不符合我们这套设计原则？"——给 AI 一个能打分的具体标准。他写了 4 条评分准则（设计质量、原创性、工艺、功能性），并刻意给"设计质量"和"原创性"加权，专门惩罚那种紫色渐变+白卡片的"AI 套路味"。

把"裁判"调教得挑剔，远比让"运动员"自我批判要容易。一旦有了外部反馈，生成器就有了可以对着死磕的目标。— 原文核心方法

一个惊艳的例子：让 AI 做荷兰艺术博物馆网站，第 9 轮还只是普通的深色落地页，第 10 轮它突然推翻重来——用 CSS 透视做了一个 3D 展厅，画作挂在墙上，靠"穿过门"在展厅间导航。这种创造性飞跃，单次生成根本做不到。

把这套"对抗"模式搬到写完整应用上，就形成了三角色架构——这恰好对应软件开发里"规划 → 开发 → 测试"的天然分工：

规划 ➜ 生成 ⇄ 评判（不达标就带着具体 bug 反馈打回）

两个 agent 还会在动工前"签合同"（sprint contract）：先就"这一块做到什么程度算完成、怎么验证"达成一致，再写代码。沟通全程用文件传递——一个写文件，另一个读了再回。

同一句提示"做一个 2D 复古游戏制作器"，单 agent vs 完整 harness 的对比非常直白：

完整 harness 贵了 20 多倍，但差距一目了然。更重要的是评判器抓到的 bug 极其具体，精确到代码行——比如：删除键处理在 LevelEditor.tsx:892 的判断条件写错了 /frames/reorder 路由定义在 /{frame_id} 之后，被误判成整数 → 422 报错。这种反馈，生成器拿到就能直接改，不用再排查。

第一版 harness 笨重、慢、贵。作者于是做了件反直觉的事——主动做减法。他提出一个值得记住的原则：

harness 里每一个组件，都编码了一条"模型自己做不到"的假设。而这些假设会随模型变强迅速过期，所以值得反复压力测试。— 原文金句

当 Opus 4.5 升级到 Opus 4.6，"上下文焦虑"基本自愈了，于是他直接删掉了"上下文重置"和"sprint 拆分"——模型现在能自己连续写两个多小时不跑偏。但 Planner 和 Evaluator 保留了：去掉 Planner，生成器会偷懒少做功能；Evaluator 则变成"按需使用"——

评判器不是非黑即白的开关。只有当任务超出当前模型独立能可靠完成的边界时，它才值得那份成本。— 关于何时该用评判器

最终用新 harness 做了个浏览器里的数字音频工作站（DAW）：约 4 小时、$124，能编曲、混音，还能用自然语言指挥 AI 谱一小段曲子。虽然远不专业（毕竟 Claude "听不见"声音），但核心都能跑。