终于不再等nikita修文章了——第一部分在此，第二部分即将发布。https://t.co/8aS4vN6LK3

为什么软件工厂会失败

或者说：光有框架是不够的

更新：本文的演讲版已在YouTube上线：https://www.youtube.com/watch?v=Ib5GBkD555M

看来我们又回到循环了

所有人都在竞相把AI编码投入生产。关于循环工程已经说了很多，目前的共识似乎是：我们最好多写一些循环。

StrongDM 写过他们的“无人工厂“，也就是没有人读代码、也没有人写代码的软件工厂。

主流的叙事大概是这样的：

• 你是瓶颈。

• 模型已经足够好了。

• 代码是免费的。

• 只管多出货。

OpenAI 的 Ryan Lopopolo 二月份写了篇文章，四月份又做了个关于 OpenAI 软件工厂 Symphony 的演讲。

这些人真的都非常聪明，我非常尊重他们。但最悲观的理解是：这不过是又一种为把更多风投资金投入劣质内容机器找的借口。

呃……事情正在发生

我们的朋友 Mario 在 AI Engineer Europe 上恳求我们慢下来——因为那些根本不应该因为编码代理事故而宕机的公司，正在……嗯……因为编码代理事故而宕机。

正如 Matt Pocock 所说，代码库正在以前所未有的速度崩溃。

关于 StrongDM 的那个暗工厂到底怎么样，我一直没能找到确切的数据或结论。他们的“天气报告”从今年二月到六月只有零星几条更新。编辑——7月23日在黑客新闻上有一场与该团队的讨论，听上去我们可能很快会看到更正式的更新！

Faros AI 的人发布了一份报告：自从我们在1月和2月全面采用这些AI编码工具以来，PR审查质量大幅下降。

• 更多评论、更长的评论，大量 PR 未经任何审查就合入。

• 事故数量大幅上升。

• 每个开发者的 bug 数量大幅上升。

这份报告更像是一个关联信号，而不是确凿的铁证（是的，我故意选了这个词，别让我吐槽Claude的用词），而本文的重点正是要对劣质数据保持警惕，但根据我的所见所闻，方向上是合理的。

“你拿错了”（你没有）

很多人会告诉你，这是技能问题——如果你得不到好结果，那是你自己的错。

但无论你选择……嗯……怎么拿，我保证你会被告知：如果 Token 最大化对你不好使，那是技能问题。你只需要花更多 Token。别再去读代码了。而且如果你还没达到那个程度，我保证这只是个过程。去年夏天我也是这么想的。

可惜我的自尊心受不了，我当时说的一些关于“怎么拿更好“的蠢话被录了下来，现在在 YouTube 上累计约有100万播放量。我不是在炫耀，我分享这个只是为了证明，我在寻找编码代理的最佳用法上已经深耕了很长时间，并且发现了一些被很多人认为确实有用的东西。

• 编码代理的高级上下文工程

• 拒绝感觉——在复杂代码库中解决难题

• 关于RPI我们全都搞错了

无论如何，我们被迫忍受的所有这些“只管加大 Token“的网上闲聊的承诺，简洁地说就是：只要有足够好的框架工程，我们就能两全其美：

• 快10到100倍，
• 高质量，
• 并且再也没人需要做我们都不喜欢的代码审查了。

我们只需要配置更多的 linter，并在足够多的 PR 审查机器人上撒一些像是“对抗性审查“之类的魔法词，我们的软件就能愉快地自我构建，不出任何事故。

这不是技能问题

我要试图说服你的是：无论多少框架工程或循环最大化，都无法解决根本上是一个模型训练问题的问题。

要搞懂这个，我不得不深入挖掘编码模型实际是如何训练和评估的——包括 RLVR 和基准测试两个方面。

在这篇文章中，我将介绍：

• 软件工厂可以追溯到1968年，它们是如何演变的，AI又给它们带来了什么变化
• 为什么模型虽然在基准测试（即使是全新的“前沿“基准测试）中表现出色，却仍能生成堆积如山的劣质内容
• 尽管如此，你可以不烧掉代码库，也能相当快地推进

我会试着穿透每天冒出来的技能插件以及AI-精神病-Token最大化建议大流行带来的炒作，泛泛地谈谈哪些类型的事情是有效的，而不特意引用任何特定的技能或框架。

视频版本： 本文基于（并扩展了）我在AI Engineer World’s Fair 2026上的主题演讲。

感谢 @addyosmani、@CyrusNewDay、@HamelHusain、@zeeg、@dillon_mulroy、@nayshins 和 @jeffreyhuber 对本文的反馈。

附带说明：这与氛围编码无关

Addy Osmani 厘清了一个值得强调的事情：

一个开发者用氛围编码打造一个最多十几个人会用到的副项目，和一个团队为了让一个已有十年历史的企业系统再撑一个季度，他们几乎没有任何共通的约束值得提及，而市面上大部分建议，其实是其中一个人告诉另一个人怎么过日子。

如果你喜欢氛围编码，请继续。我仍然会用氛围编码做很多事情，但我同时也维护着大量的生产软件（并且通过 HumanLayer，帮助上千名工程师做同样的事），所以接下来的部分主要是针对那些在复杂代码库中解决难题的人。

我经常听到棕地这个词来形容这种分裂。从历史上看，那指的是某个有十年历史的 Java 项目，但以我们现在能出货的速度来看，感觉一个由代理构建的代码库大概在三到六个月后就开始吃力了——你会开始变慢，添加新东西的方式也必须改变。

软件工厂简史

我的整个职业生涯都在构建和研究软件工厂，但我最近才知道：这个术语可以一直追溯到1968年的一次北约会议——也就是提出“软件工程“的那次会议。

从那以后，我觉得唯一特别有趣的事情是，美国国防部写过一份31页的PDF，内容大概是国防部需要更好地使用 Jenkins 之类的。

2022年的软件工厂

让我们把“软件工厂“的定义锚定在2022年左右，也就是AI出现之前。在一个典型的软件工厂中：

• 人们决定要构建什么——工程师、PM、领导层推动愿景
• 放到跟踪器里——Linear、Jira 之类的：一个关于需要做什么的状态机
• 有人拿个工单然后去构建——可能边做边跑一些手动/自动化测试
• 拉取请求——自动化检查，一个人审查代码，也许还有人拉下来测试
• 有什么问题？ 回到“有人构建东西“的循环
• 发布到生产——接触用户
• 添加监控——整个行业都围绕着当东西坏了时凌晨3点呼工程师
• 用户抱怨——提需求、找bug、提交功能请求→回到团队，添加到跟踪器

如此循环。我们还没到AI阶段呢，这张图里就已经有好几个循环了。

前置对齐

团队几十年前就搞清楚了一件事：构建需要几小时或几天，审查也一样。

所以我们把工作前置——计划、架构提案、冲刺规划——一起作为一个团队来做。这意味着：

• 更少的返工，因为我们在任何人写代码之前就达成了一致
• 更少的时间逐行审查，如果你曾经读过一份很长但写得好的PR，你就会知道当它接近完美时，审查有多快

我们稍后会回到这个问题——先来看看当你引入编码代理时会怎么样。

编码代理软件工厂

现在每家公司，甚至他们亲戚——

• Ramp
• Stripe
• WorkOS
• Brex

今年差不多都在解释他们是如何打造了一个能产出约75%代码的代理工厂。

代理工厂的样子主要是把**“有人构建东西”→“代理构建东西”**替换掉——这里还有一些编排、框架、沙箱、模型、电脑使用等东西。我不想深入那些细节，因为说实话我已经烦透了看这些，相信你也是。

当代理构建东西时：

• 构建从几小时或几天降到几分钟或几小时。
• 审查仍然需要几小时或几天。人还是要读代码、测试变更。所以审查成了瓶颈。

于是你也加快了审查：

• 代理代码审查，检查样式、bug、安全。
• 代理回归测试，用浏览器和电脑使用从外部戳它，完成后可能发给你一个小视频

审查更快了，但它可能仍然是瓶颈。不过我们可以做更多循环。

接下来你可能把事故路由到工厂里。与其凌晨3点呼人，他们醒来时可能已经有一个可能修好了问题的PR了。

我们也可以把用户反馈路由到工厂。人们提需求，然后需求就被构建好了。

这时候，工作就剩下两个问题：你能往队列里塞多少东西，以及你能多快审查和测试从里面出来的东西？

这就引出了无人工厂。

无人工厂

Dan Shapiro 创造了这个术语，Simon Willison 写过 StrongDM 的实现——我们不再读代码了。

你看着你的漂亮软件工厂。它被那个烦人的代码审查步骤给毁了，你说：你知道吗，那个让人读每个变更的步骤？不了，谢谢。

于是你把它去掉，把精力放到别的地方：

• 投资测试，让代理测试自己的工作
• 投资沙箱和编排
• 投资自动化审查
• 投资监控
• 投资发布
• 投资从用户那里收集反馈信号

现在工作真的就剩一个问题：我们能要求代理构建多少东西？我们想烧开多少大海？

这会很顺利的（并不是）

我要提出一个可能有争议的观点：无人工厂并不可行。

让我们来聊聊为什么软件工厂会失败。

我们试过了

2025年7月，我们全面进入了无人工厂状态。只读规范和工单，所有中小型东西都用后台代理。

如果你认真试过几个月，你早就知道结局如何了。你会发现至少有一个足够棘手的问题，代理无法解决——即使你用上了最先进的提示和工作流程。

• 你做深入的上下文感知研究，把所有正确的部分整理到智能区域供模型分析
• 你让代理尝试用10种不同方式复现

最终你不得不妥协，去你三个月前就不读了的那堆代码里翻，试图搞清楚什么东西坏了。

而在这期间：

• 你的网站宕机了。
• 你的用户很生气。
• 而你呢，如果你跟我一样，就会非常痛苦——读着你放任溜进系统的所有劣质代码。

第一次发生这种事时，我没当回事。哪怕我刚花了几乎两周时间翻Claude的面条代码，“下行风险也值得换取速度”。到了11月的第三次，我们决定从头重写会更容易，我的联合创始人花了整整两周在VS Code里（甚至不是Cursor）手动敲出所有模式。

模型会随着时间的推移降低代码库质量

我想表达的是：模型有一个缺陷。它们无法长期维护和提升代码库质量——没有足够的人工引导的话。

我说的可维护性，是指那种改动代码库某一部分而不破坏另一部分变得非常非常困难的特定情况。这就是 Martin Fowler 的“散弹枪修改“。

关于可维护性我不打算多说。有好多书你可以去读：

• John Ousterhout 的《软件设计哲学》
• Robert C. Martin 的《整洁代码》
• Martin Fowler 的《重构》

那么，为什么模型不能做软件可维护性呢？

“但是模型从那以后肯定已经好多了”

这时候你可能很想说：但 Dex，模型从7月以来肯定已经好多了

在某些方面确实是的。在其他方面，它们差不多还是一样。

• 解决一次性问题，或者氛围编码一个新的营销网站？是的，好多了。
• 随着时间的推移改善代码库质量？据我所知，没有好太多。

我无法证明这个。你也无法证明。没有一个好的基准测试能衡量模型维护代码库质量的能力。（关于这个走向，后面会更多。）

没有好的基准测试能衡量模型维护代码库质量的能力

但如果你做过编码代理工作一段时间——而且很多人正好在发帖说这个——你可能已经有了感觉：它们倾向于让事情越来越糟，让代码库更难工作。

所以为了弄清楚为什么会这样，我想把视野拉回到第一个伟大的编码代理。

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 在框架内对模型进行了 RL 训练——这是第一次有实验室针对他们将要发布的确切工具来训练模型。而且它在代理循环中调用这些工具变得非常、非常擅长。

摆弄工具定义和评估直到找到模型最喜欢的形状是一回事——我曾为各种用例花了几周时间做这个。但当你拥有权重并且可以修改模型本身使其更擅长特定工具集时，那就完全是另一回事了。

OpenAI 团队在11月的演讲中很好地说明了这一点：如果你构建了一个框架，但不拥有权重且不能在框架内对模型进行RL训练，你将永远处于劣势，相对于那些两者都拥有的团队。

60秒了解编码代理强化学习

我做了很多关于这个主题的研究，制作了一堆可视化想解释清楚关键部分，但我发现 Calvin French-Owen（codex团队MTS，Segment创始人）在AI Council的演讲做得更好更清晰，所以我准备下面这个受他幻灯片启发的动画：

要让一个模型更擅长编码，你需要：

• 生成一些编码代理跟踪，用来解决一个问题（例如修复我的测试）
• 根据某些标准对跟踪进行评分（验证器）
• 更新模型权重，使好的跟踪更可能出现，坏的跟踪更可能出现

然后你在几周或几个月内重复这个过程数百万次。

不过，这些“评分“部分往往可能是一维的。

糟糕的设计没有惩罚

以 SWE-bench Multilingual 为例。任务都很小——大约十五分钟的