为什么软件工厂会失败

我们都急着把 AI 编码投入生产。关于循环工程已经讨论了很多，主流看法是我们大概应该多写循环。1

— 循环工程 —— 多写循环就好了

StrongDM 分享了他们的无人值守软件工厂，人类既不读代码也不写代码。

这类说法大致是这样的：

1. 你才是瓶颈。

2. 模型已经够好了。

3. 代码是免费的。

4. 只管多出货就行了。

OpenAI 的 Ryan Lopopolo 在二月份写了相关文章，四月份又做了一个演讲介绍 OpenAI 的软件工厂 Symphony。

— OpenAI 的 Ryan Lopopolo 谈harness engineering

这些人都非常聪明，我由衷地尊重他们。但最刻薄的说法是：这不过是又找了个借口往低质量内容的洪流里灌更多 VC 的钱。

我们的老朋友 Mario 在 AI Engineer Europe 上恳请大家慢下来——因为那些根本不该因为编码智能体事故而宕机的公司，确实因为编码智能体事故宕机了。

正如 Matt Pocock 所说，代码库分崩离析的速度前所未有。

我一直没找到 StrongDM 关于那个熄灯工厂最终结果的任何可靠数据或总结。天气报告在今年的二月到六月之间只有寥寥几条更新。补充——Hacker News 上 7 月 23 日有一个与团队的讨论——听起来可能很快会有更正式的更新！

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

· 评论更多了、篇幅更长了，还有大量 PR 完全不经过审查就合入了。

· 事故大幅增加。

· 每人平均故障数量大幅增加。

这份报告更多是相关性信号而非可验证的确凿证据5，而这篇文章的核心论点是让我们警惕低质量数据，不过它和我观察到的情况在方向上是一致的。

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

但无论你怎么使用这件工具，我可以肯定地告诉你，一定有人在说：如果增加 token 用量不管用，那是你的技术问题。你只需要再花更多 token。别再读代码了。如果你才刚刚开始尝试，不用担心，这是必经阶段。我去年夏天也是这么想的。

不幸的是，为了满足我的虚荣心，我说的一些关于“怎么用得更好”的蠢话被录了下来，目前在 YouTube 上累积了大约一百万次观看。我不是在炫耀，我说这些只是为了表明，我已经花了相当长的时间深入研究如何最好地使用编码智能体，并且发现了一些很多人觉得确实有用的东西。

— 为编码智能体设计上下文工程

— 拒绝随意——在复杂代码库中解决难题

— 我们在 RPI 上犯的所有错误

总之，网上那些“只需增加 token 用量”的言论向我们所承诺的是：只要harness engineering做得足够好，两者可以兼得：

· 快 10 到 100 倍，

· 质量还高，

· 而且再也不用干我们都痛恨的那件事——代码审查

我们要做的不过是多配几个 linter，往足够多的 PR 审查机器人身上撒几句“对抗性审查”之类的咒语，然后软件就会自己高高兴兴地把自己构造出来，一切太平。

我要说服你的是：无论做多少harness engineering、叠加多少轮循环，都解决不了一个本质上是模型训练层面的问题。

为了理解这个问题，我不得不深入研究了编码模型到底是怎么训练和评估的——既涉及 RLVR 方面，也涉及基准测试方面。

这篇文章我会逐一说明：

1. 软件工厂这个说法可以追溯到 1968 年，它们如何演进，AI 又如何改变了它们

2. 为什么模型能生成大量低质量代码，即使它们在基准测试上拿满分（包括最新的所谓“前沿”基准）

3. 尽管如此，你仍然可以快速推进，而不必让代码库变得难以维护

我会尽量穿透那些每天都在涌现的 skills 插件和全民 AI 焦虑式增加 token 用量的所谓建议，只从一般原则上讨论哪些东西确实有效，不涉及任何具体的 skill 或框架。

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

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

Addy Osmani 帮我理清了一个值得强调的东西：

如果你喜欢 vibe coding，请继续。我现在仍然以 vibe 方式写许多项目，我只是同时维护着大量生产环境软件（并且通过 HumanLayer 帮助成千上万的工程师做同样的事），所以本文的剩余部分主要面向在复杂代码库中解决难题的人。

我听到很多人用既有项目（brownfield）这个词来谈这种分化。过去这个词指的是某个十年前的 Java 项目，但以我们现在交付代码的速度，一个由智能体构建的代码库可能三到六个月就开始变得难用了——你开始慢下来，添加新东西的方式也不得不改变。

我做了一辈子的软件工厂建设和研究，但直到最近才了解到：这个词可以追溯到 1968 年的 NATO 会议——正是那次会议给了我们“软件工程”这个词。

除此之外，另一件我觉得特别有意思的事是 美国国防部写了一篇 31 页的 PDF，讲国防部需要更好地使用 Jenkins 之类的东西。

让我们把“软件工厂”的定义锚定在 2022 年前后，也就是 AI 之前。在一个典型的软件工厂里：

· 人决定要建什么——工程师、产品经理、领导层推动愿景

· 放进任务跟踪器——Linear、Jira 之类：管理工作流程的状态机

· 有人领了任务然后实现它——过程中可能做一些手动或自动化测试

· Pull Request——自动化检查、人审查代码、可能有人拉下来测试一下

· 有问题？回到“有人实现”这一步

· 发布到生产环境——代码和用户接触了

· 加上监控——有整个行业专门做一件事：凌晨三点打来电话告诉你服务出了故障

· 用户反馈——提需求、找 bug、提交功能请求 → 回到团队，写进任务跟踪器

如此循环往复。AI 还没进入这个图景，流程中就已经存在多个循环了。

团队几十年前就意识到了一件事：写代码需要几小时甚至几天，审查也一样。

— 写代码和审查都需要几小时甚至几天

所以我们在真正写代码之前做前置工作——计划、架构提案、sprint 规划——作为团队一起做完。这样意味着：

· 少返工，因为在任何人写代码之前我们就对齐了

· 审查时间缩短，如果你读过那种长但质量上乘的 PR，你就知道那些几乎完美的代码审起来有多快

— 前置计划：~1 小时的前置投入减少返工，并将审查从 6 小时缩短到 20 分钟

我们稍后会回到这个话题——先看看把智能体编码引入这个流程后会发生什么。

现在，每家公司都出来了——

· Ramp

· Stripe

· WorkOS

· Brex

今年都在讲述自己如何构建智能体工厂，并表示大约 75% 的代码都是智能体提交的。

智能体工厂大致就是把“有人实现”换成“智能体实现”——中间还有一些 orchestration、harness、沙箱、模型、计算机操作之类的东西。我不会太深入这些细节，因为说实话我已经看腻了，相信你也是。

— 智能体软件工厂——智能体来实现

当智能体来实现时：

· 写代码从几小时甚至几天缩短到几分钟到几小时。

· 但审查仍然需要几小时甚至几天。仍然需要有一个人读代码、测试变更。所以审查现在成了瓶颈。

— 写代码现在只需要几分钟到几小时；审查仍然是几小时甚至几天

于是你就加速审查：

· 智能体代码审查，用来抓风格问题、bug、安全问题。

· 智能体回归测试，从外部通过浏览器和计算机操作来测试它，做完了可能还给你发个可爱的小视频

— 智能体审查和回归测试——变快了，但仍然可能是瓶颈

审查现在更快了，但大概率仍然是瓶颈。不过我们可以做更多循环。

接着你可以把线上事故也接入工厂。不用凌晨三点给人打电话了，他们醒来时已经有一份也许能解决问题的 PR 在等着了。

— 把线上事故接入工厂

还可以把用户反馈也接入工厂。人们提需求，然后它被实现。

— 把用户反馈接入工厂

到这一步，工作的本质只剩下两个问题：你能往队列中放入多少任务，以及你能审核和测试多少出来的结果？

— 你能往队列中放入多少任务，以及你能多快地审查出来的变更

这就引出了无人值守软件工厂。

Dan Shapiro 发明了这个词，Simon Willison 写了 StrongDM 的实践——就是不再读代码了。

你看着自己精心打造的软件工厂，被代码审查这个讨厌的步骤给毁了，然后你说：不如这样：每个变更都要人去读？算了。

— 无人值守软件工厂——人类审查被打上了叉

于是你把它拿掉，把精力放在别的地方：

· 投入到测试上，让智能体自己测试自己的工作

· 投入到沙箱和 harness 上

· 投入到自动化审查上

· 投入到监控上

· 投入到发布策略上

· 投入到收集用户反馈信号上

— 改为投入到测试、监控和发布策略上

现在，这份工作的确只剩下一个问题：我们能往队列里扔多少任务？我们想承担多大的工作量？

— 现在工作只剩下一个问题——你能往队列中放入多少任务

我要提出的观点可能会引起争议：无人值守工厂根本不工作。

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

2025 年 7 月，我们全面走上了无人值守的道路。只管看规格说明书和任务单，用后台智能体处理所有中小型工作，全盘转型。

如果你也认真试过几个月，你已经知道结果会是什么。你总会碰到至少一个棘手到智能体无法解决的问题——哪怕你有再高级的提示词和工作流。

· 你做了深度的上下文感知研究，把所有相关部分整理进智能区域让模型分析

· 你让智能体试了十种不同的方式来复现

最后你还得咬咬牙，钻进那个你已经三个月没读过的代码库，试着搞清楚什么坏了。

而在此期间：

· 你的网站挂了。

· 你的用户气炸了。

· 而你，像我一样，非常痛苦——去读那些你默许溜进系统的低质量代码。

第一次发生这种事的时候，我还不在意。虽然我花了将近两周挖 claude 生成的结构混乱的代码，但“速度带来的收益压过了风险”。到十一月的第三次，我们决定不如从头重写更容易，于是我的联合创始人花了整整两周在 VS Code（甚至不是 Cursor）里手工理顺了所有的模式。

我想说的是：模型有一个短板。它们不能随时间推移维护和改进代码库质量——至少在没有足够人类指导的情况下不行。3

我说的可维护性，特指那种你改一部分代码、另一部分就很容易被破坏的状况。这就是 Martin Fowler 说的散弹式改动（shotgun surgery）。

我不打算再展开讲可维护性了。有的是好书可以看：

· John Ousterhout 的《A Philosophy of Software Design》

· Robert C. Martin 的《Clean Code》

· Martin Fowler 的《Refactoring》

那为什么模型做不到软件可维护性？

这会儿你肯定憋不住想说：可是 Dex，模型应该比七月那会儿强很多了吧

确实——在某些方面。另一些方面差不多一样。

· 解决一件独立的难题，或者快速搭建一个新的营销站？是的，强得多。

· 随时间推移改善代码库质量？据我所知，没什么太大进步。

— 解决一次性问题的能力从 2025 到 2026 年大幅提升；改善代码库质量的能力几乎没有变化

我证明不了这一点。你也证明不了。衡量模型维护代码库质量的能力，根本就没有好的基准测试。（后面会讲这方面的进展。）

但如果你和编码智能体一起工作了一段时间——现在很多人都在发这种内容——你多半已经有了这种感觉：它们往往会让代码库越来越糟，越来越难用。

所以为了理解为什么会这样，我想回退一步，看看第一个伟大的编码智能体。

Claude Code 在不到一年里，收入从零涨到大约 40 亿美元——现在大概到了 90 亿。

— Claude Code 收入增长曲线

这有点令人惊讶，因为那时候早已有优秀的 CLI 智能体。aider、cline、codebuff——都比 Claude Code 更早，都内置了真正高质量的上下文工程，都有你可能会归功于 Claude Code 的同一套工具：读取、写入、编辑、grep、bash。我全都用过。它们很不错。但工具的可靠性也会时不时出问题——你会看到它在同一个编辑操作上反复失败三次，然后你只能重新打开编辑器手动完成。

2024 年的 SWE-Agent 论文指出，工具形态上的小改变会带来显著的差异，比如说在 ReadFile 的结果里包含行号，或者把编辑工具从查找替换改成行区间编辑。

随后 Claude Code 发布，增长迅速。你可以把这归功于发行渠道，但最被广泛接受的解释是 Claude Code 赢了，因为它更厉害，而它更厉害是因为 Anthropic 在 harness 内对模型做了强化学习——这是第一家训练模型时直接用上了他们即将一起交付的确切工具的研究实验室。结果是模型变得非常非常擅长在智能体循环里调用这些工具。

如果你只做工具定义和评估上的调校，直到找出模型表现最佳的形态——我在这方面针对不同用例投入了好几周的时间——那是另一回事。但如果你掌握模型权重，能够修改模型本身让它更擅长特定的工具集合，那就完全是另一个层次的游戏了。

OpenAI 团队在十一月的演讲里说得挺到位：如果你只搭建了 harness 但没有掌握模型权重，不能在 harness 内对模型做 RL，你始终会处于相对劣势。

在这个话题上我研究了一大堆资料，制作了大量可视化，但后来发现 Calvin French-Owen（Codex 团队的 MTS，Segment 创始人）在 AI Council 上的演讲讲得更清楚更好，所以我直接借用他幻灯片的灵感做下面这个动画：

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

1. 生成一些编码智能体的执行轨迹来解决一个问题（比如“修好我的测试”）

2. 根据某些标准对轨迹打分（验证器）

3. 更新模型权重，让好的轨迹更可能出现，坏的轨迹更不容易出现

然后你在几周甚至几个月的时间里重复这个过程数百万次。

不过，这些流程中的“打分”环节，往往只是过于简单的一维判断。

以 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 默认改成空数组）：

在评估时，模型：

1. 从一个基础提交开始——代码库正好是那个修复提交之前的版本

2. 拿到 bug 报告——在这个例子里是 'zip_command': undefined method 'empty?' for nil:NilClass

智能体根据问题写一些代码。它看不到正确答案的补丁，也看不到用来评分的测试补丁：

然后：

1. 保留智能体生成的补丁

2. 丢弃它对测试文件做的任何编辑（之前碰到过模型悄悄把失败的测试注释掉，或者拼接一个让测试无效的 mock）

3. 在上面加上基准测试自己的测试补丁

4. 跑完整的测试套件：既有的 zip 测试（PASS_TO_PASS）加上新增的测试（FAIL_TO_PASS），看两者是否都通过

旁注——基准测试不是验证器——事实上它们必须互相隔离（不要在测试集上训练，等等）——我说这个主要是为传达“评判编码智能体轨迹质量”的形态及其局限性。

模型是用什么方法得出正确答案的，不重要。只要测试通过，我们就赢了，但对侵蚀代码库可维护性的行为，没有任何惩罚。

这就是为什么你会看到到处是 try catch：

— json parse 外面包了 try catch

以及懒惰的类型转换，直接让类型系统的所有好处都白费了：

— 懒惰的类型转换

跑测试能在几秒钟内给出明确的通过或失败。这就是 RL 能够跑数百万个循环来优化每次模型生成的原因。

但糟糕架构的成本函数是以周、月甚至年为单位来衡量的。这发生在第一次有人打开那个文件准备做一行修改的时候——然后发现不能一行改完——因为之前的实现缺乏充分的考量，现在同样一个修改要在十一个地方做，还得祈祷三个文件之外没有东西静悄悄地坏掉。

— 一个糟糕的决策导致随机的低质量代码，几周或几个月后导致 bug/事故——而没有办法将事故反向传播到那个导致它的决策

糟糕的设计是当今基准测试评估不了的东西。我知道，RL 不等于基准测试，但如果这在 RL 里已经被解决了，我觉得它应该已经开始体现在我们的基准测试设计了。

无论如何，我个人不相信当今基准测试上的任何改进可以作为模型突然不会把你的代码库搞成一团乱麻的信号。

当然，很多聪明人正在解决这个问题。我不是说做不到，而是说炒作跑在了工程严谨性的前头。

有几个我认为方向正确的努力：

· SWE-Marathon（Abundant AI）：大约 400 小时的任务，比如“克隆整个 Excel 的所有功能”——使用复合奖励通道而非单一通过/失败比特

· DeepSWE（Datacurve）：在现实世界中从未真正被构建过的开源仓库上的大任务，所以按照构造本身它们不可能已经在训练集里（解决了训练污染问题，但不解决质量问题）

· Frontier Code（Cognition）：多 PR 任务，并且有一个巧妙的确定性质量评估——它惩罚那些在补丁前的代码上不会失败的测试（如果你没听说过变异测试，那可有的好玩了4）。它还运行一个法官模型在 diff 上检查代码质量规则。

但用模型来判断质量能做到的程度是有限的。

事实上不难想象，如果一个模型能可靠地区分好代码和坏代码，那它一开始可能就写出来了好版本。RL 需要一个快速且可靠的判定器，而可维护性这方面我们还没有这样的判定器。

当然，更多的审查智能体和更多的 token 确实有帮助——它们能抬高底线，捕获那些低级问题。

但它们无法提升天花板，因为天花板就是我们在 RL 里设法教会模型的东西，而好的设计正是那个我们仍然不知道该怎么教给它的东西。

所以我仍然不会把代码库押注在这些上面。但它们是我看到的第一批真的试图给可维护性打分、而不是停在通过/失败上的评估。

旁注 也许未来的某个模型直接解决这个问题，我们就无需再讨论了。如果你想不断随意更换提示词直到 GPT-7 发布看看结果，请便——但尽管苦涩的教训摆在那里，我们现在就要解决问题，而我要讲的就是我们怎么做的。

目前，判断者仍然是你——所以我们要把代码审查放回去：

— 重新打开灯的智能体流程

我们要重拾 AI 时代之前就在做的那些事：在动手之前做一点计划，来减少漫长而困难的审查的几率。

我们要找到杠杆，并且用 AI 来帮忙，涵盖四个阶段：

· 产品需求

· 系统架构

· 程序设计

· 垂直切片

一切从产品审查开始：一份简短的文档，确定我们要构建什么、为什么构建。目标是拿到两句话或一大段语音笔记，然后把它变成半结构化的东西。

首先，我们对齐要解决的问题——真正的用户痛点，用用户自己的话来说。第二，成功是什么样子——上线后我们能读到什么来决定这件事值得建。理想情况下，这是一个用户结果，比如“能更快完成 XYZ 流程”或者“更早达到 ABC 接入里程碑”。有时候它更底层，比如一个错误率或一个延迟数字，有时候只是“关于 X 的支持工单停了”。

我们尽量保持它在产品空间里，而不是技术层面。作为一个横跨产品与技术两个领域的人，我经常发现自己不知不觉滑向技术细节。当这种情况发生时，我会试着记下来留给后面的阶段，然后回到用户实际体验上来。如果技术决策真的阻碍到产品决策，那我们就先确认已有的部分，然后进入架构阶段，或者做更多关于可行性的原型探索。

而且既然大部分内容是关于用户看到的东西，我不描述它——我直接做原型。一个粗糙的 HTML 原型往往比三页文档更快地终结争论。

下面是一个正在进行中的真实例子——文档用 JSON 大纲敲定功能，然后用两个粗粒度的 HTML 原型展示实际界面（点击可放大）：

— 产品审查文档：一个定义步骤和导出条件的 JSON 工作流大纲

— HTML 原型：带工作流步骤图形预览的新建任务界面

— HTML 原型：智能体停止时在聊天中的移交建议

当然，不是所有东西都需要产品审查。改个文案、写一个一次性脚本、有明显复现路径的 bug——我们仍然是直接丢给智能体。审查是为那些让智能体误解我们意图的代价很高昂的场景准备的。

对于这个流程里的所有文档，我们做的是作者选择参与式的审查。如果你想在审查时省时间，你选好本来要审这个 PR 的人，在写代码之前先和他们把产品和技术规格过一遍，可以通过异步文档评论（我们自己用 HumanLayer 来实现，但你完全可以在 GitHub、Notion 或其它协作工具中完成）。

产品审查确定后，我们做系统架构。这不算什么新鲜事，现在即使是采用 vibe coding 方式工作的人也开始重视这一点了。

在这个阶段，我们对齐服务、端点、数据模型、消息队列和存储之间怎么互通，但不用深入到程序设计的细节。为了最大化人和智能体之间的沟通带宽，我们大量使用可视化——比如序列图：

协议/端点形状：

数据模型和转换：

Mermaid 画图在这里不错，但有时过于繁琐，有时还会让你产生一种已对齐的错觉。架构这一步杠杆效应相当高，你能在这个阶段预先排除很多模型可能搞出来的坏习惯。但它还不足以产生高质量代码。要做到那个，我们需要程序设计。

在架构之后，我们做一件我认为在智能体编码领域被严重低估的事情：程序设计。

大多数人以为，只要架构搞对了，模型就可以自己自行生成代码。你可以这样做，但得到的结果未必理想。

而我看到真正起作用的做法是：在任何人（人或智能体）开始写实现代码之前，从架构深入一个层级，规划代码的形状：类型、方法签名、程序布局和调用栈。

我们第一版的程序设计 skill 质量很差——难以阅读，令人疲惫。我们尝试过 Mermaid，它适合特定场景，但我们真正喜欢的是用伪代码做轻度可视化：

调用栈树，用于任何编排或控制流变更。当有趣的部分是变化的地方时，使用 diff 语法：

Dillon Mulroy 提到在规划过程中使用调用图，我认为完全正确。

— Dillon Mulroy 谈在规划中使用调用图

文件树 diff——让你始终清楚代码库的布局以及各模块的位置：

关键新函数的类型和方法签名——那些对架构文档来说太细节、但智能体仍然可能搞错的东西：

这些都不需要花多长时间（模型起草，你和它争论），而每一个都是你本来在代码审查中隐含做出的决定——在修改成本最高的时点。

接下来我们推崇一种我称之为“垂直切片”的事情——Matt Pocock 和我在 2026 年一月的直播中聊过垂直切片或叫“追踪弹”的概念——这也被称为追踪弹。

模型偏爱“水平计划”——按栈分层来做：

1. 数据库迁移

2. 服务层

3. API

4. 前端

实际上这意味着，在整个过程中你没有办法真正“触碰”到逐步成型的方案。你可以用代码测试，但对我构建过的几乎所有功能来说，读测试只是一个开始；而在浏览器中实际查看效果，或者在我工作的同时用 curl 发送请求测试，始终是工作流程中频繁的一部分。

在 AI 之前，很少有人会写完 2000 多行甚至 500 多行代码而不在中途检查点什么的。

我花了一段时间才注意到我习惯的差别——在 AI 之前我写代码时，总是从中间层开始，逐步向两端扩展。大致是：

1. 创建 API 协议并返回 mock 数据，用 curl 测试

2. 创建前端来消费 mock 数据，在浏览器迭代打磨

3. 把 API 接到服务层（服务提供 mock 数据/行为）

4. 添加数据库迁移，把服务接到数据库上

5. 添加一堆业务逻辑

6. 添加一堆错误处理

而我每做一步都在测试/迭代/打磨。

如果我对代码很在意，或者对模型在这个部分代码库中做好工作的能力持怀疑态度，我会在每一步也审查代码。检查 100-200 行然后纠正方向，代价要低得多。

大多数前沿模型不会在没有人类引导的情况下设计这样的计划，而且这很难针对每个代码库甚至每个任务泛化，所以我更喜欢保持自己在这个流程里。相信我。如果我能把思考工作外包出去，我早就去做了。

所以我的结论是，如果你真的想保持接近人类水平的代码质量，而不想事后被大量低质量代码所困扰——即真正实现快速交付——，下面这些步骤我认为人必须参与进来：

1. 产品设计

2. 系统架构

3. 程序设计

4. 垂直切片

显然，我们不是对所有提交的东西都走这个完整流程（见下方的 80/20 法则）。我估计分布大致是：

· ~40% 的任务直接交给智能体，或一次交出去再加一两轮轻反馈

· 中型任务，我们把产品和系统设计合并到一个计划文档里，不再将工作拆分为多阶段

· 大型功能，我们走全部步骤。像大型重构这类产品层面不相关的事，就跳过产品部分。

而大多数情况下，我一次丢给模型 1-3 个切片让它做，然后边做边审。不管是内部实现还是实际功能，在早期纠正方向比产出 2000 多行代码后完全无法定位问题所在要容易得多。

你不是 PR 太多。你是有太多低质量 PR。

早在 AI 之前，我们所有人都审查过大量需要返工的 PR。

但一份出色的 PR 是让人愉快的。你一个文件一个文件地往下翻，代码简洁干净，完全遵循你们所有的决策、讨论和经过反复推敲形成的关于软件编写方式的共识。

另一方面，如果一份 PR 需要哪怕 20% 的返工（这已经是保守估计了，我见过的大多数 AI 一次性提交的 PR 趋近于 50%），这对提交方和审查方都是一种智力负担和情绪负担。（即使是 AI 提交的，最初也是有人启动了这项工作、或者对 AI 的结果做了一番打磨，或至少关心这件事的结果。）

为了节省你的时间（我们快到结尾了），我在一篇旁支文章里多聊了一些这方面内容：“时间去哪了”

读了这篇文章的核心论点——“目前我们还得继续读代码”——你可能有点沮丧。

我也曾经很兴奋地期待一个世界：我们只管开口要东西，模型自己搞定一切，不用读代码，然后得到随着时间推移持续演进、不会沦为技术债的优雅生产环境软件。

但我在这篇文章里尽力铺陈的，无非就是一些约束条件。模型在某些方面很擅长，在另一些方面则不尽如人意。面对这些约束条件，你如何优化自己的工作流程？

可能你正忙于追求 10 到 100 倍的速度提升，同时试图说服自己代码质量已经不再重要。但如果你愿意接受这些约束，你完全可以在安全的前提下实现 2 到 3 倍的速度提升。

我最后的建议大致是：

1. 充分了解这些约束，通过大量和模型一起工作来培养直觉

2. 在这些约束构成的竞技场内优化系统

3. 寻找杠杆

4. 认真读代码。

就这些。如果你想看产品介绍就继续往下阅读。希望这篇文章能帮你避开灾难，或者至少让那些小动画让你看得开心。

感谢阅读

🫡 —dex

·

我们正在构建 humanlayer.com，一个智能体 IDE 和协作平台，帮助你以 2-3 倍的速度前进，同时保持人类级别（或者说相当接近人类级别）的代码质量。

我们在追踪两个方向：“你的软件工厂的积木块”和“更好的软件可维护性验证器”（甚至可能是更好的模型）。

HumanLayer 对 3 人及以下的小团队免费开放，如果你想找人帮你上手，可以来我们的 discord 聊聊，或者给 founders@humanlayer.dev 发封邮件。

感谢 @calvinfo 的启发、我的联合创始人 @0xBlacklight、@swyx 和 @aiDotEngineer 团队提供的舞台，以及所有为我们加油的各位客户、投资者、朋友和家人们。

如果你想了解更多，我一直在这个话题上持续产出内容。你可以在下方找到本文所有提及链接，以及同一话题的播客、长视频白板等形式的内容延伸。

播客与文章：

· Dex 和 Gergely 在 The Pragmatic Engineer 上聊上下文工程与软件工厂——2026 年 7 月

· Dex 和 Matt Pocock 聊长青 AI 编码建议（以及 Ralph 循环）——2026 年 1 月

AI That Works 系列：

· 基准测试什么都证明不了

· AI 编码的产品规格说明

· 用学习测试做更好的反压

· 将十二要素智能体原则应用到 AI 编码中

本文中提到的链接：

· 为什么软件工厂会失败——AI Engineer World’s Fair 2026 主题演讲

· StrongDM 的无人值守软件工厂

· OpenAI：harness engineering（2026 年 2 月）

· Ryan Lopopolo 谈 Symphony（演讲，2026 年 4 月）

· Mario 在 AI Engineer Europe：在充斥低质量代码的世界中追求精密

· FT：亚马逊因编码智能体事故导致宕机

· Matt Pocock：代码库正在分崩离析

· Faros AI：AI 加速的反噬报告

· 为编码智能体设计上下文工程（演讲 8/25）

· 拒绝随意：在复杂代码库中解决难题（演讲 2025 年 11 月）

· 我们在 RPI 上犯的所有错误（演讲 3/26）

· Awesome-RLVR——强化学习资源

· 为编码智能体设计上下文工程（文章）

· 十二要素智能体

· Addy Osmani 论vibe coding vs. 维护

· NATO 软件工程会议，1968 年

· 美国国防部 DevSecOps 参考设计（PDF）

· Ramp 的编码智能体平台

· Stripe：Minions，一次性端到端编码智能体

· WorkOS：Project Horizon

· Brex（Latent Space）

· Dan Shapiro：通向软件工厂的五个层级

· Simon Willison 谈 StrongDM 的软件工厂

· 煮海

· 散弹式改动（refactoring.guru）

· John Ousterhout——《A Philosophy of Software Design》

· Robert C. Martin——《Clean Code》

· Martin Fowler——《Refactoring》

· aider

· cline

· codebuff

· SWE-Agent 论文（2024）

· OpenAI Codex 演讲（11 月）

· Calvin French-Owen——AI Council 演讲

· SWE-bench Multilingual（数据集）

· AIE Worlds Fair 2026——大循环辩论（“炒作跑在了工程严谨性前头”）

· SWE-Marathon（Abundant AI）

· DeepSWE（Datacurve）

· Frontier Code（Cognition）

· 变异测试（Wikipedia）

· Dillon Mulroy 谈规划中使用调用图

· Dex × Matt Pocock：垂直切片/追踪弹（直播，2026 年 1 月）

· 思考这项艰苦工作无法外包（Jake Nations）