为什么黑灯软件工厂会失败

我经营着一家叫作 HumanLayer 的公司，致力于研发人类与智能体协作的工具。因此，我下面要说的内容可能会带点主观色彩。不过，即便如此，我还是希望你能觉得这个话题对你有所帮助，或者至少和我一样对它感兴趣。我猜我们都在循环工程的路上了我们都在争先恐后地将 AI 编码投入生产。关于循环工程（Loop Engineering），人们已讨论了很多，目前普遍的看法是：我们或许应该多构建一些循环流程。StrongDM 曾撰文介绍他们的“黑灯”软件工厂：在那里，没有人阅读代码，也没有人编写代码。大致的说法是这样的：你就是瓶颈。模型已经足够好。代码是免费的。抓紧交付就好。OpenAI 的 Ryan Lopopolo 曾在 2 月份撰文探讨了这一话题，并于 4 月份就 OpenAI 的软件工厂项目 Symphony 发表了演讲。这些人个个都聪明绝顶，我由衷地敬佩他们。但若从最刻薄的角度解读，这不过又是一种说辞，好让风险投资家们往这个烂摊子里再砸钱。它正在……我们的朋友 Mario 在 AI 工程师欧洲大会上登台呼吁大家放缓脚步——因为那些本不该因编码智能体失误而出现故障的公司，偏偏因为编码智能体的失误遭遇故障。正如 Matt Pocock 所言，代码库崩坏的速度达到了前所未有的水平。我没能找到 StrongDM 针对这套黑灯工厂项目进展发布任何确切的数据与结论。他们的项目气象报告从今年 2 月份到 6 月份仅有零星更新。不过，7 月 23 日团队在 Hacker News 参与了讨论，听上去我们很快有望看到一份更为正式的进展通报！Faros AI 团队发布了一份报告：自今年一二月份大家陆续用上各类 AI 编码工具以来，PR 的评审质量大幅下滑。评审留言变多、篇幅变长，还有大量 PR 在没有评审的情况下就被合并。线上故障数量大幅上升。每位开发人员的缺陷数量也显著增加。这份报告更像是一种相关性信号，而不是确凿的铁证。这篇文章的核心目的在于提醒大家警惕垃圾数据，不过结合我自身观察来看，报告反映的趋势还是可靠的。“是你使用方式不对”（事实并非如此）很多人会跟你说，问题出在使用者技能不足——如果你没能获得理想的效果，那是你自己的问题。但无论你选择怎样去用它，我敢肯定一定会有人对你说：如果极致消耗词元这条路行不通，那就是你的技能问题。你只需要消耗更多词元，不要再纠结于读懂代码了。而且，如果你刚开始走到这个阶段，我可以保证，这正是成长过程的一部分。去年夏天，我也曾这样想过。遗憾的是，因为我的虚荣心，我之前随口说了些关于“如何更好地驾驭它”的傻话，结果居然被录了下来，如今在 YouTube 上的累计观看量已接近百万。我并非想炫耀，只是想借此说明，我早已深入研究如何最有效地利用编码智能体，并且发现了一些对许多人来说确实很有用的见解。网上铺天盖地、让人不胜其烦的这套论调——“使劲堆词元就行了”，它的核心逻辑就是：只要做好充分的 harness 工程设计，我们便能鱼与熊掌兼得：10 到 100 倍效率提升；高质量；再也不用做所有人都头疼的代码评审。我们所要做的，无非是配置更多代码检查工具，再给足够多的 PR 评审机器人加上一些“对抗性评审”之类的神奇词汇，然后软件就能顺顺利利自动构建，不会出错。这不是技能问题我要努力说服你的是，无论怎样优化硬件设计或提升循环峰值性能，都无法从根本上解决一个本质上属于模型训练的问题。为把这件事讲清楚，我深入研究了代码模型实际的训练与评估机制，包括可验证奖励强化学习（RLVR）及基准评测方面的内容。在这篇文章中，我会依次讲解：软件工厂的历史可追溯到 1968 年，它们经历了怎样的演变？AI 又是如何改变了它们？为什么模型即使在各项基准测试中表现优异（甚至包括全新的“前沿”基准测试），仍能生成大量垃圾内容？尽管存在上述问题，我们依旧可以高效推进开发，同时不至于把代码库搞得一团糟。我打算抛开每天层出不穷的 Skill 插件以及 AI 狂热与过度追求极致性能的炒作建议，以更宏观的视角来谈谈那些真正有效的方法，不会提及任何特定的 Skill 或框架。软件工厂简史我的整个职业生涯都在构建和研究软件工厂，但直到最近才了解到：这一术语最早可追溯到 1968 年的一次北约会议——正是那次大会提出了“软件工程”这一概念。自那以后，我唯一觉得特别有趣的一点是，美国国防部写了一篇长达 31 页的 PDF 文件，内容大致是关于国防部需要更好地使用 Jenkins 之类的事项。2022 年的软件工厂让我们以 2022 年——即 AI 出现之前——为基准来界定我们的“软件工厂”概念。在典型的软件工厂里：人们决定要构建什么——工程师、项目经理和引领愿景的领导层共同推动。它会进入一个跟踪器——Linear、Jira 或者其他的什么东西：一个描述所需完成事项的状态机。有人领取工单，然后开始构建——很可能在构建过程中还会做一些手动或自动测试。拉取请求——自动检查，由人工审查代码，或许还有人将代码拉下来做测试。发现问题？回到开发环节。发布到生产环境——正式面向用户。添加监控——整个行业都围绕着在凌晨 3 点某个地方出问题时给工程师发寻呼而建立起来的。用户反馈——提出需求、发现漏洞、提交功能请求，流转回团队，录入任务追踪系统。如此循环往复。我们甚至还没触及 AI，这张图里就已经出现了好几个循环了。对齐前置数十年前的团队就已明白：开发需要数小时或数天，代码评审也是如此。因此，团队会把工作前置——包括规划、架构方案和冲刺迭代计划。这意味着：更少的返工，因为我们是在写代码之前就已达成一致。减少逐行评审的时间。我们稍后再回过头来讨论这个——现在我们来看看引入编码智能体时会发生什么。智能体软件工厂现如今几乎所有公司都在跟风RampStripeWorkOSBrex今年的大部分时间，他们都在宣扬自己如何打造了一个智能体工厂，产出的代码占比高达 75%。智能体工厂看起来基本上就是将“人工开发某个功能”替换为“智能体开发某个功能”——这里面涉及一些内容，比如编排、工具箱、沙盒、模型、计算机使用等等。我就不深入探讨这些细节了，因为说实话，这类内容我已经看得审美疲劳，而且我敢肯定，你们也一样。当由智能体开发功能时：开发耗时从数小时乃至数天缩短至几分钟或几小时。但代码评审依旧要耗费数小时、甚至数日。仍然需要人工通读代码、验证改动。于是，评审环节成了新的瓶颈。于是你也加快评审速度：用智能体评审代码，检查代码规范、发现缺陷与安全漏洞。用智能体进行回归测试，通过浏览器、计算机操作能力对系统进行探测；完成后说不定还会给你发一段可爱的小视频。现在评审速度更快了，但可能仍然存在瓶颈。不过，我们可以增加更多循环。接下来，你可能还会将线上故障直接转接到工厂。这样一来，他们不必在凌晨 3 点被叫醒去处理，而是在一觉醒来时看到一个已经完成修复的 PR。我们还可以将用户反馈直接接入到工厂。用户提出需求，产品就会被制造出来。此时，这里只剩下两个问题：你能往任务队列里塞多少需求，以及你能以多快的速度完成评审和测试？这就引出了黑灯软件工厂。黑灯软件工厂Dan Shapiro 发明了这个术语，而 Simon Willison 则撰文介绍了 StrongDM 的落地实现——在这个实现中，人类不再阅读代码了。你看着自己精心搭建的软件工厂，却被那个烦人的代码评审环节给毁了。于是你心想：那个由人来逐行审阅每处改动的流程？算了吧，我才不要呢。于是你舍弃人工代码评审，把精力放到其他地方：测试，让智能体自行验证自己的产出；沙箱和编排；自动化代码评审；监控；发布；收集用户反馈。至此，问题就只剩一个：我们能让智能体开发多少东西？我们打算多大程度上“竭泽而渔”？看起来很棒（事实并不会）我要提出一个可能颇具争议的观点：黑灯软件工厂行不通。让我们来探讨一下黑灯软件工厂为何会失败。我们尝试过了2025 年 7 月，我们全面进入黑灯工厂模式：智能体只需要阅读需求规范和工单，中小型开发任务全部交由后台智能体处理，整个流程就搞定啦。如果你认真尝试几个月，就知道结局会怎样。你一定会碰到至少一个极度棘手的难题，即使你使用了最前沿的提示词和工作流，智能体依旧束手无策。你进行深度的上下文感知排查，将所有相关的要素整合起来供模型分析。你让智能体尝试以 10 种不同的方式重现。最终，你不得不硬着头皮去翻阅那个三个月前就不再看的代码库，试图弄清楚哪里出了问题。与此同时：你的网站瘫痪了。你的用户生气了。而你呢，如果你和我一样，一定会痛苦不堪——读着那些你不小心引入系统的垃圾代码。第一次遇到这种情况时，我毫不在意地把它抛诸脑后。尽管我花了近两周时间梳理那些乱七八糟的代码，但依然觉得“潜在风险换来开发速度是值得的”。到了 11 月，这类问题第三次出现，我们干脆决定从头开始重写，我的联合创始人甚至整整花了两周时间使用 VS Code（连 Cursor 都没用）纯靠手写把所有模式都梳理了一遍。随着时间推移，大模型会拉低代码库质量我想强调的是：模型存在一个缺陷——它们无法长期持续提升代码库的质量，除非有相当程度的人工干预。我所说的可维护性，指的是这样一种情况：想要修改代码库中的某一处代码，极大概率会引发其他地方报错。这正是 Martin Fowler 所说的“霰弹式手术”。我就不多谈可维护性了。关于这方面的书有很多，可以去读一读。John Ousterhout 的《软件设计哲学》Robert C. Martin 的《代码整洁之道》Martin Fowler 的《重构》那么，为什么大模型无法实现软件可维护性呢？但毫无疑问，大模型变得越来越好了此时，你可能迫不及待地想说：自 7 月份以来，这些模型可已经进步