或者：仅靠工具是不够的
更新 - 本文的演讲视频已上线 YouTube：https://www.youtube.com/watch?v=Ib5GBkD555M
看来我们得开始搞循环了
我们都在争相将 AI 编程投入生产。关于循环工程已经有了很多讨论，主流观点是我们应该编写更多的循环。
StrongDM 写下了他们的无灯软件工厂，在那里没有人阅读代码，也没有人编写代码。
这个叙事大致是这样的：
- 你是瓶颈。
- 模型已经足够好了。
- 代码是免费的。
- 只管交付更多东西。
OpenAI 的 Ryan Lopopolo 在二月写过关于此事的文章，并在四月发表演讲介绍了 OpenAI 的软件工厂 Symphony。
这些人确实非常聪明，我也非常尊重他们。但这里最愤世嫉俗的看法是，这不过是又一个将更多风投资金投入劣质内容的借口。
嗯……它正在运行
我们的朋友 Mario 在 AI Engineer Europe 大会上站起来，恳求我们放慢脚步——因为那些本不该因编码代理事故而宕机的公司，现在却……确实因编码代理事故而宕机了。
正如 Matt Pocock 所说，代码库的崩溃速度比以往任何时候都快。
我还没能找到 StrongDM 关于那个无灯工厂进展的明确数据或发现。他们的天气报告在今年二月到六月之间只有几条稀疏的更新。编辑 - 7 月 23 日他们在 Hacker News 上有一番讨论 - 听起来我们可能很快就会得到更正式的更新！
Faros AI 的团队发布了一份报告：自从我们2 在 1 月和 2 月都开始使用这些 AI 编程工具以来，拉取请求的审查质量大幅下降。
- 更多评论、更长的评论，以及大量 PR 未经任何审查就被合并。
- 事故数量大幅上升。
- 每位开发者的漏洞数量也大幅上升。
这份报告更像是一个相关性信号，而非确凿证据（没错，我故意选择了这个词，别让我开始吐槽 Claude 的散文风格），而本文的要点正是要警惕劣质数据，但根据我所见，它感觉上方向上是正确的。
“你用的方式不对”（其实不是）
很多人会告诉你这是个技术问题——如果你没有得到好的结果，那是你自己的错。
但无论你选择……嗯……怎么用，我保证你会被告知，如果 token 最大化对你不起作用，那是技术问题。你只需要花更多 token。放手不去阅读代码。如果你还没到那一步，我保证这是必经之路。去年夏天我也是这么想的。
不幸的是，为了我的自尊心，我决定说的一些关于“如何更好地使用它”的蠢话被录了下来，现在在 YouTube 上累计有大约一百万次观看。我不是在吹嘘，我分享这些只是为了说明我已经在探索使用编码代理的最佳方法上投入了很长时间，并且发现了一些对许多其他人来说真正有用的东西。
不管怎样，我们在网上被迫忍受的所有这些“只管多花 token”的废话，其承诺简而言之就是：通过足够的工具工程，我们可以两全其美：
- 速度快 10 到 100 倍，
- 质量高，并且
- 再也没人需要做我们都讨厌的代码审查
我们只需要配置更多的 linter，并在足够多的 PR 审查机器人上撒上一些像“对抗性审查”这样的魔法词，我们的软件就能愉快地自行构建，不会出任何问题。
这不是技术问题
我要试图说服你的是，无论多少工具工程或循环最大化，都无法解决根本上是模型训练的问题。
要理解这一点，我必须深入探究编码模型实际上是如何训练和评估的——包括 RLVR 方面和基准测试方面。
在这篇文章中，我将介绍：
- 软件工厂的历史可以追溯到 1968 年，它们是如何演变的，AI 又是如何改变它们的
- 为什么模型在基准测试（甚至是全新的“前沿”基准测试）中表现出色，却仍然能生成大量劣质内容
- 尽管如此，你还是可以在不烧毁代码库的情况下快速前进
我将尝试戳破每天涌现的技能插件和 AI 致幻 token 最大化建议热潮的 hype，并以一般性术语讨论哪些类型的方法有效，而不引用任何特定的技能或框架。
视频版本： 本文基于（并扩展了）我在 AI Engineer World's Fair 2026 上的主题演讲。
感谢 @addyosmani、@CyrusNewDay、@HamelHusain、@zeeg、@dillon_mulroy、@nayshins 和 @jeffreyhuber 对本文的反馈。
顺便说一句：这与 vibe coding 无关
Addy Osmani 梳理了这一点，值得强调：
一个开发者用 vibe coding 方式做一个最多只有十几个人会运行的 side project，和一个团队为了再维持一个季度而维护一个运行了十年的企业系统，它们几乎没有任何值得一提的共同约束，而目前流传的大多数建议，其实都是这两类人中的一个人在告诉另一个人该如何生活。
如果你喜欢 vibe coding，请继续 vibe。我仍然在很多事情上使用 vibe coding，只是我同时也在维护大量生产软件（并通过 HumanLayer 帮助其他数千名工程师做同样的事情），所以本文的其余部分针对的是那些在复杂代码库中解决难题的人。
我经常听到 brownfield 这个词来形容这种分裂。从历史上看，它指的是某个运行了十年的 Java 项目，但以我们现在交付的速度，感觉一个由代理构建的代码库在大约三到六个月后就开始出现问题——你会开始变慢，添加新功能的方式也必须改变。
软件工厂简史
我整个职业生涯都在构建和研究软件工厂，但直到最近我才知道：这个词可以追溯到 1968 年的一次北约会议——正是那次会议给了我们“软件工程”这个词。
此后，我发现唯一超级有趣的事情是，美国国防部撰写了一份 31 页的 PDF，内容是关于国防部需要如何更好地使用 Jenkins 之类的。
2022 年的软件工厂
让我们将“软件工厂”的定义锚定在 2022 年左右，也就是 AI 爆发之前。在一个典型的软件工厂中：
- 人们决定构建什么——工程师、产品经理、领导层推动愿景
- 它被放入跟踪系统——Linear、Jira 等：一个状态机，记录需要发生的事情
- 有人领取工单并构建它——可能同时进行一些手动/自动化测试
- 拉取请求——自动化检查，人工审查代码，也许有人会拉下来测试
- 发现问题？ 回到“有人构建它”的步骤
- 发布到生产环境——与用户接触
- 添加监控——整个行业都建立在凌晨 3 点因故障而呼叫工程师的基础上
- 用户抱怨——提出需求、发现漏洞、提交功能请求 → 回到团队，添加到跟踪系统中
如此循环往复。我们甚至还没提到 AI，图中就已经有了好几个循环。
前置对齐
团队在几十年前就发现了一件事：构建需要数小时或数天，审查也是如此。
所以我们前置工作——规划、架构提案、冲刺计划——作为一个团队一起进行。这意味着：
- 更少的返工，因为我们在任何人编写代码之前就已经对齐了
- 审查每行代码的时间更少，如果你曾经读过一份长但做得好的 PR，你就会知道当它接近完美时，审查速度有多快
我们稍后会回到这一点——先来看看当你将代理式编码引入画面时会发生什么。
代理式软件工厂
现在，每家公司及其母公司——
今年大部分时间都在解释他们如何构建了一个代理工厂，能够交付大约 75% 的代码。
代理式工厂看起来主要是将 “有人构建它” → “一个代理构建它” 进行了替换——这里还有一些东西，比如编排、工具、沙箱、模型、计算机使用等。我不会深入这些细节，因为老实说，我已经厌倦了阅读这些内容，我相信你也是。
当代理构建东西时：
- 构建时间从数小时或数天缩短到几分钟或几小时。
- 审查仍然需要数小时或数天。仍然需要人工阅读代码并测试更改。所以审查现在成了瓶颈。
所以你也加快审查速度：
- 代理式代码审查，用于捕获风格、漏洞、安全问题。
- 代理式回归测试，通过浏览器和计算机使用从外部进行测试，完成后可能还会给你发一个可爱的小视频
审查现在更快了，但它可能仍然是瓶颈。但我们可以做更多的循环。
接下来，你可能会将事故路由到工厂中。不再是凌晨 3 点呼叫某人，他们醒来时可能会看到一个可能已经修复了问题的 PR。
我们也可以将用户反馈路由到工厂中。人们提出需求，它就会被构建。
此时，工作就变成了两个问题：你能往队列里塞多少东西？以及你能多快审查和测试输出的内容？
这就引出了无灯软件工厂。
无灯软件工厂
Dan Shapiro 创造了这个术语，Simon Willison 撰写了关于 StrongDM 实现的文章——我们不再阅读代码了。
你看着你漂亮的软件工厂。它被那个烦人的代码审查步骤毁了，然后你说：你知道吗，那个需要人工阅读每个更改的步骤？算了吧。
所以你放弃了它，并把精力放在其他地方：
- 投资于测试，让代理测试自己的工作
- 投资于沙箱和编排
- 投资于自动化审查
- 投资于监控
- 投资于发布
- 投资于收集用户反馈信号
现在工作真的只有一个问题了：我们可以让代理构建多少东西？我们想煮沸多少海洋？
这会很顺利的（其实不会）
我将提出一个可能具有争议性的观点：无灯工厂行不通。
让我们深入探讨软件工厂为何会失败。
我们试过这个
2025 年 7 月，我们完全进入了无灯模式。只阅读规范和工单，所有中小型任务都由后台代理处理，全套流程。
如果你认真尝试过几个月，你已经知道结局了。你会发现至少有一个足够棘手的问题，代理无法解决——即使你使用了最先进的提示词和工作流程。
- 你进行深度上下文感知的研究，将所有正确的部分整理到智能区域供模型分析
- 你让代理尝试用 10 种不同的方式重现
最终，你不得不硬着头皮，深入你三个月前就不再阅读的代码库，试图找出问题所在。
而与此同时：
- 你的网站宕机了。
- 你的用户很生气。
- 而你，如果你像我一样，则感到痛苦——阅读着所有被你放任流入系统的劣质代码。
第一次发生这种情况时，我甩掉了它。尽管我刚刚花了将近两周时间翻阅 Claude 的 spaghetti 代码，“下行风险是值得的，因为速度更快了”。到了十一月大约第三次发生的时候，我们决定从头重写更容易，我的联合创始人花了整整两周时间在 VS Code 里（甚至不是 Cursor），手动梳理出所有模式。
模型会随着时间的推移降低代码库质量
我想说的是：模型有一个缺点。它们无法长期维护和提升代码库质量——没有相当程度的人工引导是不行的。4
当我说可维护性时，我指的是那种具体的情况：修改代码库的一部分变得极其困难，而不会破坏另一部分。这就是 Martin Fowler 所说的“散弹式修改”。
关于可维护性，我不会说太多。有很多书你可以去读：
那么，为什么模型不能做软件可维护性工作呢？
“但自那以后，模型肯定变得更强大了”
此时你可能很想说：但是 Dex，自 7 月以来，模型肯定已经变得强大很多了
它们在某些方面确实变得更强了。在其他方面，它们差不多是一样的。
- 解决一次性问题，或者用 vibe coding 做一个新的营销网站？是的，强大多了。
- 长期提升代码库质量？据我所知，并没有好多少。
我无法证明这一点。你也无法证明。目前没有好的基准测试来衡量模型维护代码库质量的能力。（稍后会介绍这方面的进展。）
目前没有好的基准测试来衡量模型维护代码库质量的能力
但如果你和编码代理一起工作过一段时间——而且很多人都在发布关于此事的帖子——你可能已经有了这种感觉：它们往往会随着时间的推移让事情变得更糟，让代码库更难操作。
所以，为了弄清楚为什么会这样，我想把镜头拉远，看看第一个伟大的编码代理。
Claude Code 的成功归功于工具内部的强化学习
Claude Code 在不到一年的时间里，营收从零增长到约 40 亿美元——现在大约是 90 亿美元。
这有点令人惊讶，因为已经存在很棒的 CLI 代理了。aider、cline、codebuff——所有这些都早于 Claude Code，都内置了真正出色的上下文工程，并且都有你可能会归功于 Claude Code 的相同工具集：读取、写入、编辑、grep、bash。我用过它们。它们很好。但有时，工具的使用就是会……失败——你会看着它在同一个编辑上徒劳三次，然后重新打开你的编辑器自己动手。
2024 年的 SWE-Agent 论文概述了工具形状的微小变化如何带来显著的差异，例如在 ReadFile 结果中包含行号，或将 Edit 工具从查找/替换改为行范围编辑。
然后 Claude Code 发布并迅速崛起。你可以将其归因于分发渠道，但公认的解释是 Claude Code 之所以胜出，是因为它更好，而它更好是因为 Anthropic 在工具内部对模型进行了强化学习——这是第一次有实验室在模型将要发布时使用的确切工具集上训练模型。它变得非常非常擅长在代理循环中调用这些工具。
调整工具定义和评估，直到找到模型最喜欢的形状，这是一回事——我为了各种用例已经在这上面花了数周时间。当你拥有模型权重，可以修改模型本身以使其更擅长特定工具集时，那就是另一回事了。
OpenAI 团队在 11 月发表了一次演讲，很好地阐述了这一点：如果你构建了一个工具，但你不拥有权重，并且无法在工具内部对模型进行强化学习，那么你相对于一个同时拥有两者的团队来说，将始终处于劣势。
60 秒了解编码代理的强化学习
我对此话题做了大量研究，并制作了许多可视化图表来试图解释重要的部分，但我发现 Calvin French-Owen（Codex 团队的 MTS，Segment 创始人）在 AI Council 上的演讲做得更好、更清晰，所以我就在这里放一个受他幻灯片启发的动画：
要让模型更擅长编码，你需要：
- 生成一些编码代理轨迹来解决一个问题（例如，修复我的测试）
- 根据某些标准（验证器）对轨迹进行评分
- 更新模型权重，使好的轨迹更有可能出现，坏的轨迹更不可能出现
然后你会在数周或数月内重复数百万次这个过程。
然而，这些过程中的“评分”部分往往可能有点过于简单。
不良设计没有惩罚
以 SWE-bench Multilingual 为例。任务很小——每个大约十五分钟的工作量——从像 Redis、jq 和 Django 这样的开源仓库中抓取。奖励是 1 或 0，基于：
- FAIL_TO_PASS - 你是否修复了要求你修复的问题？
- PASS_TO_PASS - 你是否在修复时没有破坏其他任何东西？
这是一个真实的例子，fastlane__fastlane-19304，来自 fastlane——一个 Ruby 项目。它的 zip 操作获取两个可选参数，并立即对它们调用 .empty? 方法，所以一旦你省略了 include 和 exclude，它就会崩溃：
关闭这个特定 issue 的人工修复是两行代码（将 nil 默认值设为空数组）：
在评估过程中，模型
- 从一个基础提交开始——仓库被检出到该修复落地之前的那一刻
- bug 报告——在这个例子中是 'zip_command'：未定义方法 'empty?' for nil:NilClass
代理根据 issue 编写一些代码。它看不到 golden patch 或作为评分器的测试补丁：
然后：
- 我们保留它产生的任何补丁，然后
- 丢弃它对测试文件所做的任何编辑（我们已经发现模型悄悄注释掉失败的测试或插入一个 mock 使测试无效）
- 在顶部应用基准测试的测试补丁，然后
- 运行整个测试套件：现有的 zip 测试（PASS_TO_PASS）加上新的测试（FAIL_TO_PASS），看看它们是否都通过
顺便说一句 - 基准测试不是验证器——事实上，它们必须彼此隔离（不要在测试上训练，等等）——我主要是想传达“判断编码代理轨迹质量”的形状及其局限性。
模型如何得出正确答案并不重要。如果测试通过，我们就赢了，但是对于侵蚀代码库可维护性没有惩罚。
没有惩罚
这就是你到处都能看到 try catch 的原因：
验证质量比“测试通过了吗”要困难得多
运行测试可以在几秒钟内得到通过或失败的结果。这就是为什么强化学习可以运行数百万次循环来优化每个模型生成。
但是不良架构的成本函数是用数周、数月甚至数年来衡量的。它发生在第一次有人打开那个文件进行一行更改，却意识到他们无法在一行内完成时——有人把这个文件 vibe 得太厉害了，现在我们不得不在十一个地方做同样的编辑，并希望没有东西会悄悄破坏三个文件之外的内容。
测试在几秒钟内给你反馈，但不良架构的成本函数是用数周、数月甚至数年来衡量的
不良设计是当今基准测试无法评估的唯一一件事。我知道，我知道，RL != 基准测试，但如果这在 RL 中已经解决了，我相当确定它也会开始出现在我们的基准测试设计中。
无论如何，我个人不相信当今基准测试上的任何改进可以作为模型突然擅长不搞乱你代码库的指标。
前沿正在缓慢进步
当然，很多聪明人正在努力解决这个问题。我的观点不是这不可能做到，而是 hype 超过了纪律。
我认为方向正确的几个努力：
- SWE-Marathon（Abundant AI）：大约 400 小时的任务，比如“克隆整个 Excel，所有功能”——使用复合奖励通道，而不是单个通过/失败位
- DeepSWE（Datacurve）：在开源仓库上的大任务，这些任务在现实世界中从未被实际构建过，所以从构造上讲，它们不可能已经存在于训练集中（解决了数据污染问题，但没有解决质量问题）
- Frontier Code（Cognition）：多 PR 任务，以及一个巧妙的方法，即确定性评估质量——它惩罚模型编写那些在补丁前代码上不会失败的测试（如果你从未听说过突变测试，你会觉得很有趣5）。它还运行一个评判模型，对 diff 进行代码质量规则检查。
但是，让模型来判断质量，能做的也有限。
事实上，不难想象，如果一个模型能够可靠地分辨代码的好坏，它一开始就可能写出好代码。但强化学习需要一个快速且可靠的评判标准，而针对可维护性，我们目前还没有这样的标准。
如果一个模型能可靠地分辨代码好坏，它一开始就可能写出好代码，但可维护性缺乏快速的评判标准，因此我们无法在强化学习过程中为其提供奖励。
当然，更多的审查 Agent 和更多的 token 确实有帮助——它们能提高下限，捕捉那些低级错误。
但它们无法提高上限，因为上限取决于我们通过强化学习教会模型的东西，而优秀的设计恰恰是我们仍然不知道如何教给它的东西。
所以我仍然不会把我的代码库押注在任何这些方法上。但这是我所见过的第一个尝试评估可维护性、而非仅仅停留在通过/失败层面的评测。
补充说明 也许未来的模型能直接理解这一点，我们就不用操心了。如果你想在 GPT-7 问世之前随意尝试各种提示词，悉听尊便——但管他什么痛苦教训，我们现在就有问题要解决，我会一步步说明我们是如何做到的。
重新点亮灯光
今天我发现 Twitter 文章有“媒体限制”，所以剩下的内容会放到第二部分——敬请期待。
