「译」如何让 AI 自主写代码 6 小时不翻车

过去几个月，我一直在研究两个相互关联的问题：让 Claude 生成高质量的前端设计，以及让它在没有人工干预的情况下构建完整的应用程序。

这项工作源于我们早期在前端设计技能和长时间运行编码 Agent 框架上的探索。通过提示工程和框架设计，我和同事们成功地将 Claude 的表现提升到远超基线的水平——但两者最终都撞上了天花板。

为了突破瓶颈，我开始寻找能够跨越两个截然不同领域的 AI 工程方法：一个由主观品味定义，另一个由可验证的正确性和可用性定义。受生成对抗网络（GAN）的启发，我设计了一个包含生成器和评估器的多 Agent 架构。要构建一个能可靠评分的评估器——而且要有品味——首先需要开发一套标准，将「这个设计好不好？」这样的主观判断转化为具体、可评分的条款。

然后我将这些技术应用到长时间自主编码上，延续了早期框架工作的两个经验：将构建任务分解为可处理的小块，以及使用结构化产物在会话之间传递上下文。最终成果是一个三 Agent 架构——规划器、生成器和评估器——能够在数小时的自主编码会话中产出功能丰富的全栈应用。

为什么简单实现行不通

我们之前已经证明，框架设计对长时间运行的 Agent 编码效果有显著影响。在早期实验中，我们使用初始化 Agent 将产品规格分解为任务列表，然后用编码 Agent 逐个功能实现，并通过产物传递来跨会话保持上下文。更广泛的开发者社区也得出了类似的见解，比如「Ralph Wiggum」方法就是用钩子或脚本让 Agent 保持持续迭代。

但有些问题始终存在。对于更复杂的任务，Agent 仍然会随时间推移而跑偏。在分析这个问题时，我们观察到两种常见的失败模式。

第一个是上下文窗口填满后模型会失去连贯性。 有些模型还会表现出「上下文焦虑」——当它们认为快要达到上下文限制时，会提前开始收尾工作。上下文重置——完全清空上下文窗口并启动新 Agent，同时通过结构化交接传递前一个 Agent 的状态和后续步骤——可以解决这两个问题。

这与压缩不同。压缩是将对话早期部分就地总结，让同一个 Agent 在缩短的历史记录上继续工作。虽然压缩保持了连续性，但它没有给 Agent 一个干净的起点，所以上下文焦虑仍然可能持续。重置提供了干净的起点，代价是交接产物需要包含足够的状态让下一个 Agent 能顺利接手。

在早期测试中，我们发现 Claude Sonnet 4.5 的上下文焦虑非常明显，仅靠压缩不足以支撑长任务的良好表现，所以上下文重置成为框架设计的关键。这解决了核心问题，但给每次运行增加了编排复杂性、token 开销和延迟。

第二个问题是自我评估。 当被要求评估自己产出的工作时，Agent 倾向于自信满满地夸奖自己的作品——即使在人类观察者看来质量明显平庸。这个问题在设计这类主观任务上尤其突出，因为没有像可验证的软件测试那样的二元检查。一个布局是精致还是普通是主观判断，而 Agent 在给自己打分时总是偏向正面。

即使在有可验证结果的任务上，Agent 有时也会表现出糟糕的判断力，影响它们完成任务的表现。将做工作的 Agent 和评判工作的 Agent 分开，是解决这个问题的有力杠杆。 这种分离本身并不能立即消除宽容倾向——评估器仍然是一个倾向于对 LLM 生成的输出宽容的 LLM。但调整一个独立的评估器使其保持怀疑态度，比让生成器自我批评要容易得多，一旦这种外部反馈存在，生成器就有了可以迭代改进的具体目标。

前端设计：让主观质量变得可评分

我从前端设计开始实验，因为自我评估问题在这里最明显。在没有任何干预的情况下，Claude 通常会倾向于安全、可预测的布局——技术上功能正常，但视觉上平淡无奇。

两个洞察塑造了我为前端设计构建的框架。

第一，虽然美学不能完全简化为分数——个人品味总会有差异——但可以通过编码设计原则和偏好的评分标准来改进。「这个设计美吗？」很难一致地回答，但「这是否遵循了我们的优秀设计原则？」给了 Claude 可以评分的具体标准。

第二，通过将前端生成与前端评分分开，我们可以创建一个反馈循环，推动生成器产出更强的输出。

基于此，我写了四个评分标准，同时提供给生成器和评估器：

• 设计质量：设计是否感觉像一个连贯的整体，而不是零件的拼凑？颜色、排版、布局、图像和其他细节是否结合起来创造出独特的氛围和身份？
• 原创性：是否有自定义决策的证据，还是只是模板布局、库默认值和 AI 生成模式？人类设计师应该能识别出刻意的创意选择。未修改的素材组件——或 AI 生成的明显特征如紫色渐变配白色卡片——在这里会失分。
• 工艺：技术执行：排版层次、间距一致性、色彩和谐、对比度。这是能力检查而非创意检查。大多数合理的实现默认就能做好；失分意味着基础出了问题。
• 功能性：独立于美学的可用性。用户能否理解界面的功能，找到主要操作，完成任务而不需要猜测？

我强调设计质量和原创性高于工艺和功能性。Claude 在工艺和功能性上默认就得分很高，因为所需的技术能力对模型来说很自然。但在设计和原创性上，Claude 经常产出最多只能说是乏味的输出。这些标准明确惩罚高度通用的「AI 废话」模式，通过更重视设计和原创性来推动模型进行更多美学冒险。

我使用带有详细分数细分的少样本示例来校准评估器。这确保了评估器的判断与我的偏好一致，并减少了迭代过程中的分数漂移。

我在 Claude Agent SDK 上构建了这个循环，保持编排简单。生成器 Agent 首先根据用户提示创建 HTML/CSS/JS 前端。我给评估器配备了 Playwright MCP，让它可以在评分和写详细评论之前直接与页面交互。实际上，评估器会自己导航页面，截图并仔细研究实现，然后给出评估。这些反馈作为下一轮迭代的输入流回生成器。

每次生成我运行 5 到 15 轮迭代，每轮迭代通常会推动生成器向更独特的方向发展，因为它在响应评估器的批评。因为评估器是主动导航页面而不是给静态截图打分，每个周期都需要真实的时间。完整运行可能长达四个小时。

我还指示生成器在每次评估后做出战略决策：如果分数趋势良好就继续优化当前方向，如果方法不奏效就转向完全不同的美学。

一个值得注意的例子：我让模型为一个荷兰艺术博物馆创建网站。到第九次迭代，它已经产出了一个干净的深色主题着陆页。页面视觉上很精致，但基本符合我的预期。然后，在第十个周期，它完全放弃了之前的方案，将网站重新构想为一个空间体验：一个用 CSS 透视渲染的棋盘格地板的 3D 房间，画作以自由形式悬挂在墙上，用门廊式导航在画廊房间之间切换，而不是滚动或点击。这是一种我从未在单次生成中见过的创意飞跃。

扩展到全栈编码

有了这些发现，我将这种 GAN 启发的模式应用到全栈开发中。生成器-评估器循环自然地映射到软件开发生命周期，其中代码审查和 QA 扮演着与设计评估器相同的结构角色。

架构

基于原始框架的基础，我构建了一个三 Agent 系统，每个 Agent 解决我在之前运行中观察到的特定缺口：

规划器（Planner）：我们之前的长时间运行框架需要用户预先提供详细规格。我想自动化这一步，所以创建了一个规划器 Agent，它接受简单的 1-4 句提示并扩展成完整的产品规格。我提示它要有雄心壮志，专注于产品上下文和高层技术设计，而不是详细的技术实现。

生成器（Generator）：早期框架的逐功能实现方法在范围管理上效果很好。我在这里应用了类似的模型，指示生成器以冲刺方式工作，从规格中逐个挑选功能。每个冲刺使用 React、Vite、FastAPI 和 SQLite（后来是 PostgreSQL）栈实现应用。

评估器（Evaluator）：早期框架的应用看起来往往很impressive，但当你真正尝试使用时仍有真实的 bug。为了捕获这些问题，评估器使用 Playwright MCP 像用户一样点击运行中的应用，测试 UI 功能、API 端点和数据库状态。

在每个冲刺之前，生成器和评估器协商一个冲刺合约：在写任何代码之前就「完成」是什么样子达成一致。

通信通过文件处理：一个 Agent 写文件，另一个 Agent 读取并在该文件内或用新文件响应。

运行框架

我写了以下提示来生成一个复古视频游戏制作器：

创建一个 2D 复古游戏制作器，包含关卡编辑器、精灵编辑器、实体行为和可玩测试模式。

框架贵了 20 多倍，但输出质量的差异立竿见影。

单 Agent 运行的输出：初始应用看起来符合预期。但当我点击时，问题开始出现。布局浪费空间，固定高度的面板让大部分视口空着。工作流程死板。尝试填充关卡时提示我先创建精灵和实体，但 UI 中没有任何东西引导我这个顺序。更重要的是，实际游戏是坏的。我的实体出现在屏幕上但什么都不响应输入。

完整框架运行的输出：从同一个一句话提示开始，规划器步骤将其扩展为跨十个冲刺的 16 功能规格。它远超单 Agent 运行的尝试。除了核心编辑器和游戏模式，规格还要求精灵动画系统、行为模板、音效和音乐、AI 辅助的精灵生成器和关卡设计器，以及带可分享链接的游戏导出。

应用立即展现出比单 Agent 运行更多的打磨和流畅。画布使用整个视口，面板大小合理，界面有一致的视觉身份。

最大的差异在游戏模式。我实际上能够移动我的实体并玩游戏。 物理有些粗糙边缘，但核心功能是工作的——单 Agent 运行做不到这点。

迭代框架

第一组框架结果令人鼓舞，但也笨重、慢且昂贵。下一步逻辑是找到简化框架而不降低性能的方法。

在我进行这些迭代周期时，我们也发布了 Opus 4.6，这进一步推动了减少框架复杂性。从发布博客：「Opus 4.6 规划更仔细，能更长时间维持 Agent 任务，在更大的代码库中更可靠地运行，并有更好的代码审查和调试技能来发现自己的错误。」

我开始完全移除冲刺结构。 鉴于 Opus 4.6 的改进，有充分理由相信模型可以原生处理工作而不需要这种分解。

更新后的框架结果

为了测试更新后的框架，我使用以下提示生成一个数字音频工作站（DAW）：

使用 Web Audio API 在浏览器中构建一个功能齐全的 DAW。

大部分时间都花在构建器上，它连贯地运行了超过两个小时，不需要 Opus 4.5 所需的冲刺分解。

QA Agent 仍然捕获了真实的缺口。在第一轮反馈中它指出：

这是一个强大的应用，设计保真度出色，AI Agent 扎实，后端良好。主要失败点是功能完整性——虽然应用看起来impressive且 AI 集成工作良好，但几个核心 DAW 功能只是展示而没有交互深度：片段无法在时间线上拖动/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），没有可视化效果编辑器（EQ 曲线、压缩器仪表）。这些不是边缘情况——它们是让 DAW 可用的核心交互。

最终应用拥有功能音乐制作程序的所有核心部分：在浏览器中运行的工作编排视图、混音器和传输控制。我能够完全通过提示组装一个短歌曲片段：Agent 设置了节奏和调性，铺设了旋律，构建了鼓轨，调整了混音器电平，添加了混响。

下一步是什么

随着模型继续改进，我们大致可以预期它们能够工作更长时间，处理更复杂的任务。在某些情况下，这意味着围绕模型的脚手架随时间推移会变得不那么重要，开发者可以等待下一个模型，看着某些问题自行解决。另一方面，模型越好，开发能够实现超越模型基线的复杂任务的框架的空间就越大。

基于此，有几个值得延续的经验：

1. 实验模型表现：始终是好的实践，在真实问题上读取它的跟踪记录，调整其性能以达到你期望的结果。
2. 任务分解：在处理更复杂的任务时，有时可以通过分解任务并将专门的 Agent 应用于问题的各个方面来获得提升空间。
3. 重新审视框架：当新模型发布时，通常应该重新审视框架，剥离不再对性能起关键作用的部分，并添加新部分以实现之前不可能的更大能力。

我的信念是：有趣的框架组合空间不会随着模型改进而缩小。相反，它在移动，AI 工程师有趣的工作是不断找到下一个新颖的组合。