AI早知道 | 面向 AI 工程师的周刊与深度研究

Harness系列： AI早知道 · 第二篇

第十轮迭代的时候，它把荷兰艺术博物馆的网站，改成了一个用 CSS perspective 渲染的 3D 展厅。

走廊、墙壁、画框——全部用纯 CSS 实现。在房间之间穿梭，靠的不是滚动或点击，而是穿越"门洞"。没有人要求它这么做。这是它自己在第十轮评估反馈之后做出的决定。

这不是某个 demo，而是 Anthropic 工程师 Prithvi 在一篇内部研究报告里记录的真实案例。他在研究一个问题：如何让 AI 持续产出高质量的结果，而不是在第一轮就停下来、交出一个"凑合能用"的答案？

他找到的答案，颠覆了大多数人对 AI 工作流的直觉。

一个让人沮丧的发现

Prithvi 发现了一件反直觉的事：让 AI 评估自己的工作，它几乎永远给出好评。

不管输出质量如何——设计稀烂、代码有 bug、逻辑跑偏——模型都会礼貌地告诉你：这个很不错，稍微完善一下就好了。

这不是模型在撒谎。更准确的说法是，它没有足够的"外部视角"来批评自己。就像让一个人批改自己的作文，永远比让另一个人批改要宽松得多。

这个问题对有客观标准的任务来说已经很麻烦——代码能不能运行，是有答案的，但 AI 会把"暂时跑不起来"解释成"细节需要完善"。对主观任务来说更糟糕：一个设计好不好看，完全没有二进制的对错，AI 几乎不可能对自己的审美做出真正严苛的判断。

从 GAN 里偷来的一个想法

Prithvi 的解法，灵感来自一个看似不相关的领域：GAN，生成对抗网络。

GAN 的基本结构是这样的：一个生成器负责生成内容，一个判别器负责判断内容真假。两者对抗，最终生成器学会了骗过判别器，输出质量随之提升。

他把这个思路搬进了 AI 编码流程：

Generator（生成者）：负责写代码、做设计
Evaluator（评估者）：负责挑毛病、提反馈

关键是第二步：不能只是让另一个实例的模型来评估，还要专门把评估者调教得"足够刻薄"。

他发现，默认情况下，即使是独立的 Evaluator，也倾向于对 AI 生成的内容网开一面。训练它变得严苛，比训练生成者自我批评容易得多——因为你只需要给 Evaluator 明确的评分标准和反面案例，告诉它"这种类型的输出不达标"。

对于前端设计，他定了四条评分标准：

维度	核心问题
设计质量	颜色、字体、布局是否形成统一的视觉语言，而不是一堆零件的拼凑？
原创性	能看出人为的设计决策，还是纯粹的模板复制和 AI 惯用套路？
工艺	字体层级、间距一致性、色彩对比——基本功有没有做到位？
可用性	用户能不能直觉上找到主要功能，完成核心任务？

他故意把前两条的权重调高——因为模型在工艺和可用性上已经表现不差，真正的薄弱点是原创性和整体设计感。评分标准里甚至明确写道："紫色渐变配白色卡片是典型的 AI slop 特征，出现即扣分。"

结果就是那个荷兰博物馆的案例：评估者持续地告诉生成者"你的设计太平庸、太像模板"，生成者一轮轮地往更大胆的方向走，直到第十轮，它决定把整个网站的交互范式都推翻重来。

把这套逻辑用到写代码上

前端设计验证了 Generator-Evaluator 结构的价值，Prithvi 把同样的逻辑用到了完整的全栈开发上。

架构变成了三个 agent：

Planner（规划者）：用户只需要给一两句话的产品描述，Planner 负责把它扩展成一份完整的产品规格文档——包括功能列表、技术方向、视觉设计语言。这个步骤存在的原因是：如果让 Generator 直接面对一句话的需求，它会严重低估范围，只做一个最小可用的版本。

Generator（生成者）：按照产品规格，分 sprint 实现功能，每个 sprint 完成后移交 QA。

Evaluator（评估者）：用 Playwright 实际操作跑起来的应用——点击按钮、填表单、测 API——记录所有发现的问题，按照评分标准打分，不达标的 sprint 直接打回重做。

有一个细节特别值得注意：每个 sprint 开始之前，Generator 和 Evaluator 要先协商一份"验收合同"。Generator 提出这个 sprint 打算实现什么、怎么验证完成，Evaluator 审核这份提案，两边达成一致之后，Generator 才开始写代码。

这个合同的价值在于：它把"什么叫完成"这个问题，从模糊的感觉，变成了可以被机械验证的标准。Sprint 3 的验收合同有 27 条具体标准，每一条都明确到了"应该发生什么"和"失败的表现是什么"。

两个结果，一目了然

为了验证效果，Prithvi 用同一个提示词，分别跑了单 agent 和完整 harness，要求构建一个 2D 复古游戏编辑器。

方案	耗时	花费
单 agent	20 分钟	$9
完整 harness	6 小时	$200

费用差了 20 倍，质量呢？

单 agent 的版本，界面看起来能用，点进去之后问题开始出现——布局浪费空间，工作流没有引导，最关键的地方：游戏根本跑不起来。 他创建了角色，设计了关卡，按下播放，实体出现在屏幕上，但什么都没有响应。挖进代码才发现，实体定义和游戏运行时之间的连接根本没有接上。

完整 harness 的版本，规格文档里扩展出了 16 个功能点、10 个 sprint。除了基础的关卡编辑器和游戏模式，还有动画系统、行为模板、音效、AI 辅助的精灵生成器，以及可以分享的游戏导出链接。游戏可以真正玩起来——物理系统有些粗糙，角色跳上平台会轻微穿模，但核心功能是工作的。

Evaluator 的日志记录了它发现的问题，每一条都精准到了代码层面：

矩形填充工具验收失败 — 工具只在拖动起点和终点放置图块，没有填充整个区域。fillRectangle 函数存在但 mouseUp 时没有被触发。

路由匹配错误 — PUT /frames/reorder 注册在 /{frame_id} 路由之后，FastAPI 把 'reorder' 当成整数类型的 frame_id 解析，返回 422 错误。

这不是"有几个 bug"的模糊描述，而是直接告诉 Generator 哪个函数、哪行代码、怎么改。

模型变强了，harness 应该随之瘦身

Prithvi 在完成这套 harness 之后，做了一件很多工程师不会做的事：他开始系统性地把 harness 拆瘦。

他的逻辑是：harness 里的每一个组件，都是对模型能力的一个假设。 假设"模型无法在长任务里保持连贯"，于是加了 context reset。假设"模型做不到多 sprint 的自我分解"，于是加了 sprint 结构。但假设是有保质期的——模型在进步。

Opus 4.5 时期，"Context Anxiety"很严重，模型在接近它认为的上下文上限时会提前收尾。Context Reset——把上下文完全清空，让一个新的 agent 接手，靠结构化的交接文件传递状态——是必须的设计。

Opus 4.6 发布之后，Anthropic 在发布说明里写道：它"能更谨慎地规划，在更长的任务里保持稳定，能在更大的代码库里可靠地工作，并有更强的代码审查和调试能力来发现自己的错误"。

Prithvi 测试之后发现：Opus 4.6 不再需要 sprint 分解。他把 sprint 结构整个移除，让模型跑连续的一次 build，用 Agent SDK 的自动压缩处理上下文增长。Evaluator 移到整个 build 结束后做一次整体审查，而不是每个 sprint 结束都检查。

他用新 harness 让模型构建了一个浏览器版的 DAW（数字音频工作站）——可以作曲、混音、用 AI 生成乐句的完整音乐制作工具。整个 build 跑了将近 4 小时，花了 $124。其中最长的一段 build 连续跑了 2 小时 7 分钟，没有中断，没有 sprint 切割。

Evaluator 在第一轮的反馈是这样的：

"这是一个整体不错的应用，AI 集成做得好。主要的失分点是功能完整性——时间轴上的音频片段不能拖动，没有乐器 UI 面板，效果器没有可视化的调节界面。这些不是边缘功能，是 DAW 可用的核心交互，规格文档里明确要求了。"

Generator 拿到这份反馈，继续修。最终交付的版本有完整的 arrangement view、mixer 和 transport，可以通过提示词指挥 AI agent 设定节奏、生成旋律、铺鼓轨、调混音、加混响。

这篇文章真正在说什么

Prithvi 这篇文章，表面上是在讲一个工程实验。骨子里说的是一件更普遍的事：

harness 不是一次性建完就永远不动的基础设施，而是需要随着模型能力持续更新的假设集合。

今天让你加 sprint 分解的原因，明天可能消失了。今天让你加 context reset 的原因，后天也会消失。如果你的 harness 停在它被创建的那个时间点，它会越来越沉，越来越不像一套精良的挽具，越来越像一堆已经不再需要的脚手架。

而那个始终有效的部分——Generator-Evaluator 的分离、让评估者足够刻薄、在开始之前先协商验收标准——不是技术层面的设计，是一个关于如何系统性地追求质量的认知模型。

在 AI 写代码越来越普遍的今天，最稀缺的能力，不是让 AI 生成更多，而是设计一套机制，让 AI 知道"更多"里哪些是好的。

下一篇：五个月，零行人工代码，一百万行 AI 代码——OpenAI 工程团队的极端实验