为什么软件工厂会失败

为什么软件工厂会失败 2026 年 7 月 24 日 · 19 分钟阅读 · 查看原文 ↗ AI YouTube Claude 营销 或者：光有 harness 还不够 更新——本文的演讲版本已经在 youtube 上线：https://www.youtube.com/watch?v=Ib5GBkD555M 系列的第 1 部分。第 2 部分在这里：https://x.com/dexhorthy/status/2081058573556306030 我猜我们现在都要玩循环了 我们都在竞相把 AI 编码投入生产。关于循环工程已经说了很多，主流智慧是我们大概应该写更多循环。 StrongDM 写了他们那个"熄灯软件工厂"，在那里没有人读代码，也没有人写代码。 叙事大概是这样的： 你是瓶颈。 模型已经够好了。 代码是免费的。 只管发更多东西。 OpenAI 的 Ryan Lopopolo 在二月份写了这个，并在四月份做了一个关于 OpenAI 软件工厂 Symphony 的演讲。 这些人都极其聪明，我对他们怀有极大的敬意。但最犬儒的解读，会把这叫做又一个往垃圾大炮里泵更多 VC 钱的借口。 呃……事情在推进 我们的朋友 Mario 在 AI Engineer Europe 站起来求我们慢下来——因为那些根本不该因为编码 agent 的事故而停机的公司，嗯……正在因为编码 agent 的事故停机。 正如 Matt Pocock 所说，代码库正在以比以往任何时候都快的速度分崩离析。 我一直没能从 StrongDM 那里挖到关于那整个黑暗工厂进展的任何确定性数据/发现。天气报告在今年二月到六月之间有零星的几次更新。编辑补充——7 月 23 日在 hacker news 上有一些与团队的对话——听起来我们可能很快会得到一次更正式的更新！ Faros AI 的人出了一份报告：自从我们 2 在一、二月份都拿起这些 AI 编码工具以来，拉取请求的审查质量大幅下降。 评论更多了、评论更长了，还有大量的 PR 在完全没有审查的情况下被合并。 事故大幅上升。 每个开发者的 bug 大幅上升。 这份报告更多是一个相关性信号，而不是可验证的铁证（是的，我是故意选那个词的，别让我展开讲 claude 的散文），而这篇帖子的全部意义就在于对垃圾数据保持警惕，但根据我所看到的，它在方向上感觉是成立的。 "是你拿的方式不对"（你没有） 很多人会告诉你这是技能问题——如果你没得到好结果，那是你的错。 但无论你选择怎么……呃……拿它，我保证你正在被灌输：如果 token 最大化对你不管用，那就是技能问题。你只需要烧更多 token。别再读代码了。而如果你正在到达那里，我保证这是进阶的一部分。我去年夏天也这么想过。 不幸的是，对我的自尊来说，我说过的一些关于"如何拿得更好"的蠢话被录了下来，现在在 YouTube 上有大约一百万累计观看。我不是想在这里炫耀，我分享这个只是为了表明，我已经在深入研究使用编码 agent 的最佳方式上钻了很久，并且发现了一些很多人都觉得真正有用的东西。 面向编码 agent 的高级上下文工程 不要氛围——在复杂代码库里解决难题 关于 RPI 我们都搞错了什么 总之，我们被迫忍受的所有这些网上的"只要烧更多 token"的聒噪，其承诺简明地说就是：只要有足够的 harness 工程，我们就能鱼与熊掌兼得： 快 10 到 100 倍， 高质量，而且 没有人再需要做那件我们都恨的事——代码审查 我们所要做的就是配置更多的 linter，并在足够多的 PR 审查 bot 上撒一些像"对抗式审查"这样的魔法词，我们的软件就会开心地自我构建而不出事故。 这不是技能问题 我要试图说服你的是：无论多少 harness 工程或循环最大化，都无法解决一个根本上是模型训练问题的问题。 为了应对这个，我不得不去深挖编码模型到底是如何被训练和评估的——就 RLVR 和基准这两方面而言。 在这篇帖子里我会过一遍： 软件工厂可以追溯到 1968 年，它们是如何演化的，AI 又是如何改变它们的 为什么模型能一边在基准上拿满分，一边产出堆积如山的垃圾（即便是全新的"前沿"基准） 尽管如此，你仍然可以快速推进，而不把你的代码库点着 我会试着穿透每天涌现的技能插件的炒作，以及那种 AI 精神错乱式 token 最大化建议的疫情，用不引用任何特定技能或框架的方式来泛泛地谈一谈哪些事情是有效的。 视频版本：这篇帖子基于（并扩展了）我在 AI Engineer World's Fair 2026 的主旨演讲。 感谢 @addyosmani、@CyrusNewDay、@HamelHusain、@zeeg、@dillon_mulroy、@nayshins 和 @jeffreyhuber 对这篇帖子的反馈。 旁白：这和 vibe coding 无关 Addy Osmani 理清了这个值得强调的点： > 一个给十几个会跑它的人做副业项目、用 vibe coding 的开发者，和一个让一个十年老企业系统再活一个季度的团队，几乎没有任何值得一提的共同约束，而流传中的大部分建议，其实是这两个人中的一个在告诉另一个该怎么活。 如果你喜欢 vibe coding，请继续 vibe。我仍然 vibe code 很多东西，我只是也维护很多生产软件（并且通过 HumanLayer 帮助成千上万其他工程师做同样的事），所以本文其余部分针对的是那些在复杂代码库里解决难题的人。 我经常听到 brownfield 这个词被用来谈这种分裂。历史上那意味着某个十年的 Java 老东西，但以我们现在发布的速度，感觉一个 agent 构建的代码库大约三到六个月后就开始挣扎了——你开始变慢，而你添加新东西的方式必须改变。 软件工厂简史 我一辈子都在构建和研究软件工厂，但我是最近才学到这个的：这个词可以一路追溯到 1968 年的一场北约会议——就是那场给了我们"软件工程"这个词的会议。 那之后我发现唯一超级有意思的一点是，美国国防部写了一篇 31 页的 pdf，讲的是国防部需要开始更好地使用 jenkins 之类的东西。 2022 年的软件工厂 让我们把"软件工厂"的定义锚定在 2022 年左右，就在 AI 之前。在一个典型的软件工厂里： 人们决定构建什么——工程师、PM、领导层驱动愿景 它进到一个跟踪器里——Linear、Jira、随便什么：一个关于需要发生什么的状态机 有人抓一张工单去构建它——可能顺带做一些手动/自动化测试 拉取请求——自动化检查，一个人类审查代码，也许有人把它拉下来测试 有什么不对？回到"某人构建这个东西" 发布到生产——它开始接触用户 加监控——有一整个行业是围绕在凌晨 3 点给工程师发告警而建立的 用户抱怨——提需求、找 bug、提功能请求 → 回到团队那里加进跟踪器 如此循环往复。我们甚至还没到 AI，这张图里就已经有好几个循环了。 前置对齐 团队几十年前就想明白了一件事：构建要花几小时或几天，审查也一样。 所以我们把工作前置——规划、架构提案、冲刺规划——作为一个团队一起做。这意味着： 更少的返工，因为我们在任何人写代码之前就对齐了 更少花在逐行审查上的时间，如果你读过一份长但做得好的 PR，你就知道当它接近完美时，审查过得有多快 我们稍后会回到这里——先看看当你把 agentic 编码带进画面里会发生什么。 agentic 软件工厂 现在每一家公司和他妈妈—— Ramp Stripe WorkOS Brex 都花了今年的大半时间来解释他们如何构建了一个 agent 工厂，发布了大约 75% 的代码。 agentic 工厂看起来主要是把"某人构建这个东西"换成"一个 agent 构建这个东西"——这里有一些东西像编排、harness、沙箱、模型、computer use 等等。我不会深入这些细节，因为坦率地说我读腻了，我相信你也读腻了。 当 agent 构建这个东西时： 构建从几小时或几天降到几分钟或几小时。 审查仍然要几小时或几天。一个人类仍然得读代码、测试改动。所以审查现在是瓶颈。 于是你也加速审查： agentic 代码审查，去抓风格、bug、安全问题。 agentic 回归测试，从外部用浏览器和 computer use 去戳它，做完之后也许还给你发一个可爱的小视频 审查现在更快了，但它很可能仍然是瓶颈。但我们可以做更多循环。 接下来你可能会把事故路由进工厂。不再是凌晨 3 点给某人发告警，而是他们醒来时看到一条也许已经修好它的 PR。 我们也可以把用户反馈路由进工厂。人们要东西，它就被构建出来。 到那时，这份工作就是两个问题：你能往队列里塞多少东西，以及你能多快审查和测试出来的东西？ 这就把我们带到熄灯软件工厂。 熄灯软件工厂 Dan Shapiro 造了这个词，Simon Willison 写了 StrongDM 对它的实现——在那里我们不再读代码。 你看着你美丽的软件工厂。它被那个烦人的小代码审查步骤毁了，于是你说：你知道吗，那个人类读每一处改动的事？不了，谢谢。 于是你丢掉它，把精力放到别处： 投资测试，让 agent 测试它自己的工作 投资沙箱和编排 投资自动化审查 投资监控 投资发布 投资从用户那里收集反馈信号 而现在这份工作真的只剩一个问题：我们能要求 agent 构建多少东西？我们想煮干多少海水？ 这会很顺利的（并不会） 我要提出一个可能有争议的观点：熄灯工厂行不通。 让我们进入为什么软件工厂会失败。 我们试过这个 2025 年 7 月我们彻底熄灯了。只读规格和工单，用后台 agent 处理所有小/中任务，整套全上。 如果你认真地试过几个月，你就已经知道它怎么收场了。你会发现至少一个足够棘手的问题，agent 解决不了——即便用上你最先进的提示词和工作流。 你做深入的、上下文感知的研究，把所有正确的部分整理进智能区让模型去分析 你让 agent 用 10 种不同的方式复现 最终你不得不硬着头皮，钻回那个你三个月前就不再读的代码库，试图搞明白什么坏了。 而与此同时： 你的网站挂了。 你的用户怒了。 而你，如果你像我一样，很痛苦——读着你放进系统里的所有那些垃圾代码。 第一次发生在我们身上时，我甩了甩头不当回事。尽管我刚花了差不多两周时间钻 claude 意大利面，"下行风险值得这个速度"。到十一月第三次左右，我们决定从头重写会更容易，而我的联合创始人花了整整两周泡在 VS Code 里（连 cursor 都不是）手工把所有的模式捋出来。 模型会随着时间降低代码库质量 我想说的是这个：模型有一个短板。它们无法随着时间维护和提升代码库质量——不在相当多人类引导的情况下不行。4 当我说可维护性时，我指的是那件具体的事：不破坏另一部分就无法改动代码库某一部分，这变得非常非常难。这就是 Martin Fowler 的霰弹式手术（shotgun surgery）。 关于可维护性我不打算多说了。有一堆书你可以去读 John Ousterhout 的《软件设计的哲学》 Robert C. Martin 的《代码整洁之道》 Martin Fowler 的《重构》 所以，为什么模型做不了软件可维护性？ "但模型肯定在那之后变好了吧" 到这时你可能忍不住想说：但 Dex，模型从七月起肯定已经好很多了 它们确实——在某些方面。在其他方面它们差不多。 解决一次性问题，或 vibe code 一个营销站？是的。好多了。 随着时间提升代码库质量？据我所知，没好多少。 我证明不了这个。你也证明不了。对于模型维护代码库质量的能力，没有好的基准。（关于这个要走向何方，稍后再谈。） > 对于模型维护代码库质量的能力，没有好的基准 但如果你用编码 agent 用了一阵子——而且很多人在发帖说的正是这件事——你大概已经有那个感觉了：它们往往会让事情随着时间变糟，让代码库更难工作。 所以要搞清为什么会这样，我想把镜头拉到第一个伟大的编码 agent 上。 Claude Code 赢在 harness 内部的强化学习 Claude Code 在不到一年里从零涨到大约 40 亿美元——现在是大概 90 亿美元——的收入。 这有点疯狂，因为早就已经有很棒的 CLI agent 了。aider、cline、codebuff——都早于 Claude Code，都内置了真正出色的上下文工程，都拥有你可能归给 claude code 的同一套工具：read、write、edit、grep、bash。我用过它们。它们很好。但工具使用有时就是会……失败——你会看着它在同一个 edit 上挣扎三次，然后打开你自己的编辑器自己来。 2024 年的 SWE-Agent 论文概述了工具形状的小改动如何产生明显差异，比如在 ReadFile 结果里包含行号，或把 Edit 工具从查找/替换改成行区间编辑。 然后 Claude Code 发布了，迅速垂直起飞。你可以把这含糊地归为分发，但被普遍接受的解释是，claude code 赢是因为它更好，而它更好是因为 Anthropic 在 harness 内部对模型做了 RL——这是第一次有实验室针对他们即将随模型一起交付的确切工具来训练模型。而它变得非常非常擅长在一个 agentic 循环里调用那些工具。 摆弄工具定义和评估、直到找到模型最喜欢的形状，是一回事——我为各种用例烧掉过数周。当你拥有权重、能修改模型本身让它对某一组工具更擅长时，那就是另一场游戏了。 OpenAI 团队在十一月做的一场演讲把这点说得很到位：如果你构建了一个 harness，但你不拥有权重、不能在里面 RL 模型，你将永远处于那些两者都拥有的团队的下风。 编码 agent RL 六十秒 我围绕这个主题做了一堆研究，炮制了一堆可视化来试着解释重要的部分，但我发现 Calvin French-Owen（codex 团队的 MTS，Segment 的创始人）在 AI Council 做了一场做得更好更干净的演讲，所以我就直接把这段受他幻灯片启发的动画放在这里： 要让一个模型更擅长编码，你要： 生成一些编码 agent 轨迹来解决一个问题（例如修好我的测试） 基于某些标准给轨迹打分（验证器） 更新模型权重，让好轨迹更可能、坏轨迹更不可能 然后你在数周或数月里做这件事数百万次。 不过，这些事里的"打分"部分，往往会趋于任性地一维。 坏设计没有惩罚 拿 SWE-bench Multilingual 来说。任务很小——每个大约十五分钟的工作量——从 Redis、jq、Django 这样的开源仓库里扒出来的。奖励是 1 或 0，基于： FAIL_TO_PASS——你修好被要求修的东西了吗？ PASS_TO_PASS——你有没有在不弄坏其他东西的情况下做到？ 这里有一个真实的，fastlane__fastlane-19304，来自 fastlane——一个 Ruby 项目。它的 zip action 抓两个可选参数，并且立刻对它们调用 .empty?，所以一旦你把 include 和 exclude 留空，它就崩了： 关闭这个 issue 的人类修复是两行（把 nil 默认成空数组）： 在评估期间，模型 从一个 base commit 开始——仓库被检出到那个修复落地前一刻 拿到 bug 报告——在这个例子里是 'zip_command': undefined method 'empty?' for nil:NilClass agent 根据 issue 去写一些代码。它看不到黄金补丁，也看不到充当评分器的测试补丁： 然后： 我们保留它产出的任何补丁，然后 丢掉它对测试文件做的任何改动（我们抓到过一个模型悄悄把失败的测试注释掉，或拼接进一个让测试无用的 mock） 在上面应用基准的测试补丁，然后 跑整个测试套件：现有的 zip 测试（PASS_TO_PASS）加上新的那个（FAIL_TO_PASS），看看它们是否都通过 旁白——基准不是验证器——事实上它们必须彼此隔离（别在测试集上训练，云云）——我说这个主要想传达的是"判断一个编码 agent 轨迹质量"这件事的形状，以及它的局限。 模型如何得到正确答案不重要。如果测试通过，我们就赢了，但侵蚀代码库可维护性没有惩罚。 侵蚀代码库可维护性没有惩罚 这就是为什么你会到处看到 try catch 包一切： 验证质量比"测试通过了吗"难上好几个数量级 跑测试能在几秒内给你一个干净的通过或失败。这就是为什么 RL 能跑数百万个循环来优化每一次模型生成。 但坏架构的成本函数是以周、月、也许甚至年计的。它发生在第一次有人为了一个一行改动打开那个文件，却意识到自己没法一行改完——有人 vibe 得有点过头了，现在我们必须在一处做同一个改动，并指望不会悄悄弄坏三个文件之外的东西。 测试在几秒内给你反馈，但坏架构的成本函数是以周、月、也许甚至年计的 坏设计是今天基准无法评估的一件事。而且我知道，我知道，RL != 基准，但如果这在 RL 里被解决了，我相当肯定它会开始体现在我们设计基准的方式里。 无论如何，我个人不信任今天基准上的任何改进，作为模型突然擅长不把你代码库搞烂的指标。 前沿在缓慢变好 当然很多聪明人在做这个。我的观点不是它做不到，而是炒作跑在了纪律前面。 我认为方向对头的一些努力： SWE-Marathon（Abundant AI）：约 400 小时的任务，像"克隆整个 Excel，每一个功能"——带一个复合奖励通道，而不是单一的通过/失败位 DeepSWE（Datacurve）：在从未在现实世界里真正构建过的 OSS 仓库上做大任务，所以按构造它们不可能已经躺在训练集里（解决了污染问题，但不解决质量） Frontier Code（Cognition）：多 PR 任务，以及一个聪明之举——用确定性的方式评估质量——它惩罚模型写那些在补丁前代码上不会失败的测试（如果你从没听过变异测试，你将会有一段好玩的旅程 5）。它还跑一个评判模型检查 diff 的代码质量规则。 但一个评判质量的模型能走的路是有限的。 事实上，不难想象，如果一个模型能可靠地区分好代码和坏代码，它也许一开始就把好版本写出来了。RL 需要一个快速+可靠的 oracle，而我们对可维护性还没有一个 如果一个模型能可靠地区分好代码和坏代码，它也许一开始就把好版本写出来了，但可维护性没有快速 oracle，所以我们没法在 RL 里为它给奖励 当然，更多的审查 agent 和更多 token 确实有帮助——它们抬高了地板，抓住那些愚蠢的东西。 但它们不移动天花板，因为天花板是我们在 RL 里设法教给模型的任何东西，而好的设计是我们还不知道怎么教它的东西。 所以我还是不会把我的代码库押在任何一个上面。但它们是我见过的第一批真正尝试给可维护性打分、而不是止步于通过/失败的评估。 旁白 也许未来某个模型直接就会这个，我们就可以收工了。如果你想 yolo 提示词直到 GPT-7 发布看看结果，请便——但见鬼的苦涩教训，我们现在就有问题要解决，而我要讲讲我们是怎么做的。 把灯重新打开 今天我得知 Twitter Articles 有一个"媒体上限"，这意味着本文其余部分会进入一篇第 II 部分帖子——敬请期待 标签：# X # AI # YouTube # Claude # 营销 # 增长 # 自动化 # 循环 # 指南 相关文章 我如何用 CLAUDE AI 建立一个无脸 YouTube 频道做到每月 $41k 每月 41,000 美元。 YouTube Claude AI 营销