为什么软件工厂会失败

或者：纯工程化是不够的

[!NOTE] 我经营一家公司（HumanLayer），构建人机协作领域的工具，所以下面我说的可能有点偏。也许尽管如此，我还是希望你觉得这个话题有用，或者至少像我一样觉得它有趣。-Dex

我想我们现在要开始循环了

我们都在争先恐后地将 AI 编码投入生产。关于循环工程，已经说了很多，主流的观点是，我们大概应该写更多的循环。[^1]

StrongDM 写了关于他们的无灯软件工厂，在那里没有人类阅读代码，也没有人类编写代码。

这个叙事故大致是这样的：

1. 你是瓶颈。
2. 模型已经足够好了。
3. 代码是免费的。
4. 只管交付更多东西。

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

这些人都是非常聪明的，我非常尊重他们。但这里最愤世嫉俗的看法是，这不过是又一个借口，用来把更多的风险投资注入到垃圾代码大炮中。

嗯……它正在运行

我们的朋友 Mario 在 AI Engineer Europe 上站起来恳求我们慢下来——因为那些本不应该因为编码Agent事故而导致宕机的公司，确实……正在因为编码Agent事故而宕机。

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

我还没能找到 StrongDM 关于那个全自动工厂究竟如何的明确数据/发现。天气报告从今年二月到六月只有寥寥几次更新。编辑 - 7月23日在 Hacker News 上与团队有一些讨论 - 听起来我们很快会得到更正式的更新！

Faros AI 的团队发布了一份报告：自从我们[^1b]在一月和二月开始使用这些 AI 编码工具以来，PR的审查质量大幅下降。

• 更多评论，更长的评论，以及大量 PR 完全没有审查就被合并。
• 事故大幅增加。
• 每个开发者的 bug 数量大幅增加。

这份报告更像是一个相关性信号，而不是一个可验证的确凿证据[^6]，这篇文章的全部意义就是要警惕垃圾数据，但根据我所看到的，它在方向上是感觉成立的。

"你拿的方式不对"（其实不是）

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

但无论你选择……呃……怎么拿它，我保证你会被告知，如果 token-maxxing 对你不起作用，那是技能问题。你只需要花更多的 token。放弃阅读代码。如果你还没达到那个阶段，我保证这是进步的一部分。去年夏天我也是这么想的。

不幸的是，为了我的自尊，我关于"如何更好地拿它"说的一些蠢话被录了下来，现在在 YouTube 上有大约一百万的累计观看量。我不是在这里炫耀，我分享这个只是为了说明，我已经在很长一段时间里深入研究了使用编码Agent的最佳方法，并发现了一些很多人认为真正有用的东西。

编码Agent的高级上下文工程	禁止凭感觉——在复杂代码库中解决难题	我们对 RPI 理解错了的一切

无论如何，所有这些我们被迫忍受的网上"只管用更多 token"的喋喋不休的承诺，概括来说就是：通过足够的工程化，我们可以两全其美：

• 快 10 到 100 倍，
• 高质量，并且
• 没有人再需要做我们都讨厌的事情——代码审查

我们所要做的就是配置更多的 linter，并在足够的 PR 审查 bot 上撒上一些像"对抗性审查"这样的魔法词汇，我们的软件就会快乐地自建，没有事故。

这不是一个技能问题

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

为了应对这个问题，我必须深入研究编码模型实际是如何训练和评估的——涉及到 RLVR 和基准测试两方面。

在这篇文章中，我将梳理：

1. 软件工厂最早可以追溯到 1968 年，它们是如何演变的，AI 又是如何改变它们的
2. 为什么模型可以在基准测试（即使是全新的"前沿"基准测试）上表现优异的同时，却生成大量的垃圾代码
3. 尽管如此，你仍然可以快速前进，而不必把你的代码库搞得一团糟

我将尝试穿透每一个每天涌现的技能插件和 AI 精神病 token-maxxing 建议大流行，并泛泛地讨论哪些类型的事情是有效的，而不引用任何特定的技能或框架。

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

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

顺便提一下：这与凭感觉编码无关

Addy Osmani 理清了一件值得强调的事情：

一个开发者为最多十几个用户凭感觉编码一个副项目，和一个团队为了再维持一个季度而维护一个十年历史的企业系统，它们几乎没有可值得提及的共同约束，而且流传的大部分建议实际上都是这两种人中某一个人在告诉另一个人如何生活。

如果你喜欢凭感觉编码，请继续凭感觉。我仍然凭感觉编码很多东西，只是我也维护很多生产软件（并通过 HumanLayer 帮助数千名其他工程师做同样的事情），所以剩下的内容针对的是那些在复杂代码库中解决难题的人。

我经常听到 brownfield 这个词来讨论这种分裂。历史上它意味着某个十年历史的 Java 东西，但以我们现在的交付速度，感觉一个由代理构建的代码库可能在三到六个月后就开始出现问题——你开始变慢，你添加新东西的方式也必须改变。

软件工厂简史

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

从那以后，我唯一觉得非常有趣的是，美国国防部写了一份 31 页的 PDF，关于国防部需要开始更好地使用 Jenkins 之类的东西。

2022 年的软件工厂

让我们把"软件工厂"的定义定在 2022 年，就在 AI 之前。在一个典型的软件工厂中：

• 人们决定构建什么——工程师、PM、领导层驱动愿景
• 它进入追踪器——Linear、Jira 之类：一个关于需要做什么的状态机
• 有人拿了一个工单并构建它——可能同时还做一些手动/自动测试
• PR——自动化检查，一个人审查代码，也许有人拉下来测试
• 有什么问题吗？ 循环回到"有人构建东西"
• 发布到生产环境——然后与用户接触
• 添加监控——整个行业都围绕着一件事：当出问题时，在凌晨 3 点呼叫工程师
• 用户抱怨——要求功能，发现 bug，提交功能请求 → 回到团队添加到追踪器

https://github.com/user-attachments/assets/7bf8f42d-f13b-40c3-a8a2-7dca509f2d38

如此循环。我们甚至还没有涉及到 AI，这个画面里已经有好几个循环了。

前加载对齐

团队几十年前就弄明白的事情：构建需要数小时或数天，审查也是如此。

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

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

我们稍后会回到这一点——让我们看看当引入代理编码时会发生什么。

代理驱动的软件工厂

现在每个公司及其母亲——

• Ramp
• Stripe
• WorkOS
• Brex

今年大部分时间都在解释他们如何构建了一个代理工厂，交付了大约 75% 的代码。

代理驱动的工厂看起来主要是把 "有人构建东西" → "一个代理构建东西"——这里有一些东西，比如编排、工程化、沙箱、模型、计算机使用等。我不会深入这些细节，因为老实说，我已经厌倦了读这些，我相信你也是。

当代理构建东西时：

• 构建从数小时或数天下降到数分钟或数小时。
• 审查仍然需要数小时或数天。人类仍然需要阅读代码并测试更改。所以审查现在是瓶颈。

所以你也加快审查速度：

• 代理代码审查，以捕捉风格、bug、安全。
• 代理回归测试，通过浏览器和计算机使用从外部进行测试，完成后可能给你发一个小视频。

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

接下来，你可能将事故路由到工厂。不再在凌晨 3 点呼叫某人，他们醒来时看到一个可能已经修复了问题的 PR。

我们也可以将用户反馈路由到工厂。人们要求东西，它就被构建。

至此，工作变成两个问题：你能往队列里塞多少东西，以及你能多快审查和测试产出的东西？

这就引出了无灯软件工厂。

无灯软件工厂

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

你看着你漂亮的软件工厂。它被那个烦人的小代码审查步骤毁了，然后你说：你知道吗，那个让人类阅读每次更改的事情？不了谢谢。

所以你放弃它，然后把精力放在别处：

• 投入到测试中，让代理测试自己的工作
• 投入到沙箱和编排中
• 投入到自动化审查中
• 投入到监控中
• 投入到上线中
• 投入到从用户收集反馈信号

现在工作真的只剩下一个问题：我们可以让代理构建多少东西？我们想要煮掉多少海洋？

这会进展顺利的（其实不会）

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

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

我们试过这个

2025 年 7 月，我们全面转向无灯。只读规范和工单，后台代理处理所有中小型任务，整套流程。

如果你严肃地尝试过几个月，你已经知道结局如何了。你会发现至少有一个足够棘手的问题，代理无法解决——即使使用了你最先进的提示词和工作流。

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

最终，你不得不硬着头皮，去挖开你已经三个月没读过的代码库，试图找出哪里出了问题。

与此同时：

• 你的网站挂了。
• 你的用户很生气。
• 而你，如果你像我一样，很痛苦——阅读所有你让滑入系统的垃圾代码。

第一次发生这种情况时，我甩开了它。尽管我刚刚花了将近两周的时间翻遍 Claude 的意大利面条式代码，"下行风险值得这种速度"。到 11 月的第三次时，我们决定从头重写更容易，我的联合创始人在 VS Code（甚至不是 Cursor）里花了整整两周，手工梳理出所有模式。

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

我想说的是：模型有一个缺陷。它们无法随着时间的推移维护和改进代码库质量——没有相当程度的人工引导是不行的。[^3]

当我提到可维护性时，我指的是这样一种特定情况：改变代码库的一个部分而不破坏另一个部分变得非常非常困难。这就是 Martin Fowler 所说的"霰弹式修改"。

我不会再说更多关于可维护性了。有很多书你可以去读：

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

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

"但是自那以后模型肯定变得更好了"

此刻你可能很想说：但是 Dex，自七月以来模型肯定好多了

确实如此——在某些方面。在其他方面，它们差不多。

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

我无法证明这一点。你也无法证明。目前没有好的基准测试来衡量模型维护代码库质量的能力。（稍后会更多谈到这一点。）

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

但是如果你已经和编码Agent一起工作了一段时间——而且很多人正在发布关于这个的确切内容——你可能已经有了这种感觉：它们倾向于随着时间的推移把事情弄得更糟，使代码库更难工作。

所以为了弄清楚为什么会发生这种情况，我想放大到第一个伟大的编码Agent。

Claude Code 获胜是因为工程化内部的强化学习

Claude Code 在不到一年的时间里，从零增长到大约 400 亿美元——现在大概是 900 亿美元——的收入。

这有点疯狂，因为已经有很棒的 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 秒了解编码Agent强化学习

我对此做了很多研究，并制作了大量可视化图表来尝试解释重要的部分，但我发现 Calvin French-Owen（codex 团队的成员，Segment 的创始人）在 AI Council 上做了一次演讲，做得更好更清晰，所以我将在这里展示受他幻灯片启发的这个动画：

https://github.com/user-attachments/assets/25c45e29-ebf7-4ce7-9b57-969cdf305e2e

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

1. 生成一些编码Agent轨迹来解决一个问题（例如修复我的测试）
2. 根据某些标准（验证器）对轨迹进行评分
3. 更新模型权重，使好的轨迹更可能发生，坏的轨迹更不可能发生

然后你在数周或数月的时间里重复数百万次。

这些"评分"部分可能倾向于单维度，有点异想天开。

糟糕的设计没有惩罚

以 SWE-bench Multilingual 为例。任务很小——每个大约十五分钟的工作——从像 Redis、jq 和 Django 这样的开源仓库中抓取出来。奖励是基于以下条件的一或零：

• FAIL_TO_PASS - 你是否修复了要求你修复的问题？
• PASS_TO_PASS - 你是否在不破坏其他任何东西的情况下做到了？

这是一个真实的例子，fastlane__fastlane-19304，来自 fastlane——一个 Ruby 项目。它的 zip action 获取两个可选参数，并立即调用 .empty? 方法，所以一旦你省略了 include 和 exclude，它就会崩溃：

'zip_command': undefined method 'empty?' for nil:NilClass

解决这个特定问题的人工修复是两行（将 nil 默认设置为空数组）：

## fastlane/lib/fastlane/actions/zip.rb
-      @include = params[:include]
-      @exclude = params[:exclude]
+      @include = params[:include] || []
+      @exclude = params[:exclude] || []

在评估期间，模型

1. 从一个基础提交开始——仓库被检出到那个修复落地之前的那一刻
2. bug 报告——在这个例子中是 'zip_command': undefined method 'empty?' for nil:NilClass

代理根据问题去写一些代码。它看不到作为评分的金补丁或测试补丁：

## fastlane/spec/actions_specs/zip_spec.rb
+  it "sets default values for optional include and exclude parameters" do
+    params = { path: "Test.app" }
+    action = Fastlane::Actions::ZipAction::Runner.new(params)
+    expect(action.include).to eq([])
+    expect(action.exclude).to eq([])
+  end

然后：

1. 我们保留它产生的任何补丁，然后
2. 丢弃它对测试文件所做的任何编辑（我们发现过模型悄悄注释掉失败的测试或拼接一个 mock 使测试无效）
3. 在上面应用基准测试的测试补丁，并且
4. 运行整个套件：现有的 zip 测试（PASS_TO_PASS）加上新的测试（FAIL_TO_PASS）来检查它们是否都通过

顺便提一下 - 基准测试不是验证器——实际上它们必须相互隔离（不要在测试上训练，等等）——我主要想以此传达"判断编码Agent轨迹的质量"及其局限性。

模型如何得到正确答案并不重要。如果测试通过了，我们就赢了，但是侵蚀代码库可维护性没有惩罚。

侵蚀代码库可维护性没有惩罚

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

以及那些从一开始就破坏了类型系统好处的惰性类型转换：

验证质量比"测试是否通过"要难几个数量级

运行测试能在几秒钟内得到一个明确的通过或失败。这就是为什么 RL 可以运行数百万次循环来优化每个模型生成。

但是糟糕架构的成本函数是以周、月甚至年来衡量的。它发生在第一次有人打开那个文件进行一行更改，并意识到他们无法在一行中完成——有人把这个代码"凭感觉"得太厉害了，现在我们不得不在十一个地方做同样的编辑，并希望不会有什么东西悄悄地破坏三个文件。

测试在几秒钟内给你反馈，但糟糕架构的成本函数是以周、月甚至年来衡量的。

糟糕的设计是今天的基准测试无法评估的一件事。我知道，我知道，RL != 基准测试，但如果这在 RL 中解决了，我很确定它也会开始在我们设计基准测试的方式中显现出来。

无论如何，我个人不认为今天基准测试上的任何改进是表明模型突然擅长不把垃圾代码弄到你代码库中的指标。

前沿正在缓慢进步

当然，很多聪明人正在研究这个问题。我的观点不是说这做不到，而是说炒作正在超越纪律。

一些我认为方向正确的努力：

• SWE-Marathon（Abundant AI）：大约 400 小时的任务，比如"克隆整个 Excel，所有功能"——使用复合奖励通道而不是单一的通过/失败位。
• DeepSWE（Datacurve）：在开源仓库上的大型任务，这些任务在现实世界中从未实际构建过，所以通过构造，它们不可能已经存在于训练集中（解决了污染问题，但没有解决质量问题）。
• Frontier Code（Cognition）：多 PR 任务，以及一个巧妙的举措，即确定性地评估质量——它会惩罚模型编写那些在补丁前代码上不会失败的测试（如果你从未听说过突变测试，你将迎来一段有趣的旅程[^5]）。它还会在 diff 上运行一个评判模型来检查代码质量规则。

但是一个模型来判断质量只能走这么远。

事实上，不难想象，如果一个模型能够可靠地区分好代码和坏代码，它可能一开始就会写出好版本。RL 需要一个快速且可靠的判断标准，而我们还没有一个用于可维护性的。

如果一个模型能够可靠地区分好代码和坏代码，它可能一开始就会写出好版本，但可维护性没有快速的判断标准，所以我们不能在 RL 期间为此给予奖励。

当然，更多的审查代理和更多的 token 确实有帮助——它们提高了下限，抓住了愚蠢的错误。

但它们没有提高上限，因为上限是我们在 RL 中设法教给模型的东西，而好的设计是我们仍然不知道如何教给它的事情。

所以我仍然不会把我的代码库押在任何这些方法上。但它们是第一个我看到的甚至尝试评分可维护性，而不是止步于通过/失败的评估。

顺便提一下 也许未来的模型会直接理解这一点，我们就不用操心了。如果你想冒险用提示词等到 GPT-7 发布并看看结果，请便——但苦涩的教训去他的，我们现在有要解决的问题，我将讲解我们如何做到这一点。

重新打开灯

目前，评判者是你——所以我们要把代码审查放回来：

我们将拥抱自 AI 出现之前我们一直在做的事情，那就是做一点前期规划，以减少漫长且困难的审查的可能性。

我们将找到杠杆点，并使用 AI 来帮助这一点，跨越 4 个阶段：

• 产品需求
• 系统架构
• 程序设计
• 垂直切片

产品审查

一切从产品审查开始：一份简短的文档，确定我们构建什么以及为什么。目标是能够将两句话或一段长的语音笔记闲聊转化为某种半结构化的内容。

首先，我们确定要解决的问题——用户实际痛点，用用户的语言表达。其次，成功的表现是什么——发布后我们可以阅读什么来决定这个东西值得构建。理想情况下，这是一个用户成果，比如"能够在更短时间内完成 XYZ 工作流"或"更早到达入门里程碑 ABC"。有时是更底层的指标，如错误率或延迟数字，有时只是"关于 X 的支持工单停止了"。

我们尽量让这个保持在产品领域，而不是技术领域。作为一个一只脚在产品世界、一只脚在技术世界的人，我经常发现自己在这里漂移到技术细节。当这种情况发生时，我试着记下来留给后面的阶段，然后回到用户实际体验的内容。如果技术决策阻碍了产品决策，那么我们确定已有的内容，进入架构阶段，或者做更多的原型研究来确定什么是可行的。

由于这大部分是关于用户看到什么，我不描述它——我制作原型。一个粗糙的 HTML 原型展示实际屏幕，可以解决一段描述只会延续的争论。

这里有一个进行中的真实例子——文档用一个 JSON 概要确定了功能，然后是实际屏幕的两个粗略 HTML 原型：

当然，不是所有东西都需要产品审查。文案调整、一次性脚本、有明显重现步骤的 bug——我们仍然直接一次性扔给代理。对于那些代理误解意图代价高昂的更改，才需要这个。

对于这个系列的所有文档，我们采用作者自愿的审查。如果你想在审查期间节省时间，你会选出本应审查 PR 的人，和他们一起过一遍产品/技术规范，通过异步文档评论（我们用 HumanLayer 自家狗粮，但你在 github/notion/plannotator 等也很容易做到）。

系统架构

产品审查确定后，我们做系统架构。这并不特别新颖，即使是凭感觉编码的人也开始信奉这一点。

如果你想在审查期间节省时间，在进入编码部分之前，选出本应审查 PR 的人，和他们一起过一遍产品/技术规范。

在这个阶段，我们确定服务、端点、模式、队列和存储之间如何通信，而不深入程序设计的细节。为了最大化人与代理之间的通信带宽，我们在这里大量使用可视化——例如序列图：

sequenceDiagram
  participant UI
  participant API
  participant ResourceService
  participant Store
  UI->>API: PUT /resources/:slug
  API->>ResourceService: create(input)
  ResourceService->>Store: insert resource
  ResourceService-->>UI: 201 resource

契约/端点形状：

PUT /api/resources/:slug
  request:  { destination: string }
  response: { resource: Resource }

数据模型和转换：

-- 新表
CREATE TABLE resource (
  slug         TEXT PRIMARY KEY,
  destination  TEXT NOT NULL,
  created_at   TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- 新查询形状
-- SELECT ... FROM ...

Mermaid 在这里没问题，但有时可能过度，有时会让你产生一种虚假的共识感。架构是比较高杠杆的，有很多潜在的不良模型习惯你可以在这个阶段预防。但它不足以产生高质量代码。为此我们需要程序设计。

程序设计

架构之后，我们做这个我认为在代理编码中被严重低估的事情：程序设计。

大多数人认为一旦架构对了，模型就可以自由发挥了。你可以这样做，但你可能会不喜欢得到的结果。

但我看到效果很好的是，在任何人（人类或代理）编写实现之前，我们从架构向下深入到代码的形状：类型、方法签名、程序布局和调用栈。

我们程序设计技能的第一个版本很糟糕。难以阅读，令人精疲力竭。我们试过 Mermaid，它有它的用处，但我们真正喜欢的是伪代码中的轻量可视化：

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

 entrypoint
   runCommand
+    handleCreateResource
+      ResourceClient.create(input)
+        POST /resources
+      renderResult
-    legacyCreateFlow

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

文件树 diff - 这样你可以保持对代码库布局以及东西位置的了解：

 src
 └── resource
+    ├── resource-client.ts      # 新增 - 封装 API 契约调用
+    ├── resource-client.test.ts # 新增 - 覆盖请求/响应映射
~    └── resource-route.ts       # 修改 - 将创建 action 接入 UI

类型和方法签名，用于关键的新函数——那些对于架构文档来说太内部，但代理仍然可能出错的东西：

interface Item {
  id: ItemId
  parentId: ItemId | null
  // ...
}

interface Cursor {
  position: ItemId
  direction: 'up' | 'down'
  // ...
}

resolveTarget(items: Item[], cursor: Cursor) -> ItemId | null

这些都不需要很长时间来生成（模型起草，你和它争论），而且每一个都是你否则会在代码审查期间——在你最不可能改变主意的时候——隐式做出的决定。

垂直切片

接下来，我们喜欢做我称之为"垂直切片"的事情——Matt Pocock 和我在 2026 年 1 月的一次直播中聊过垂直切片或"示踪弹"——这也被称为示踪弹。

模型喜欢我称之为"水平计划"的东西——按栈顺序做事情：

1. 数据库迁移
2. 服务层
3. API
4. 前端

https://github.com/user-attachments/assets/f9cf7cb7-3baf-48e2-a5dc-59b5fffab614

在实践中，这意味着在过程中没有真正的方法来"接触"解决方案。你可以用代码测试，但对于我构建过的几乎所有功能，阅读测试只是一个开始，在工作时拉出浏览器或使用 curl 测试一直是我工作中频繁的一部分。

在 AI 之前，很少有人会在不沿途检查某些东西的情况下写 2000 多行代码，甚至 500 行代码。

我花了一些时间才注意到与我习惯的差异——在我用 AI 之前写代码时，我总是从中间开始，向外扩展。大致是：

1. 创建 API 契约并提供 mock 数据，用 curl 测试
2. 创建前端以消费 mock 数据，在浏览器中迭代+优化
3. 将 API 连接到服务层（服务提供 mock 数据/行为）
4. 添加数据库迁移，将服务连接到数据库
5. 添加一堆业务逻辑
6. 添加一堆错误处理

并且我在每一步都进行测试/迭代/优化。

https://github.com/user-attachments/assets/62e73eb1-1298-4684-8308-12ab87c21654

如果我非常关心代码，或者对模型在这部分代码库中做好的工作能力持怀疑态度，我会在每一步也审查代码。检查 100-200 行代码并重新引导比最终得到 2000 多行代码却不知道哪里出问题要便宜得多。

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

30 分钟的规划节省数小时的审查

所以我们有了一些步骤，我认为如果你希望保持接近人类的水平，而不在事后费力清理堆积如山的垃圾代码（即你真的想快速前进），人类需要在其中参与：

1. 产品设计
2. 系统架构
3. 程序设计
4. 垂直切片

显然，我们不会为我们交付的所有东西都做这整个流程（见下面的80/20 法则）。我猜测分布大致是：

• 大约 40% 的任务一次性完成或一次性完成加 1-2 轮轻反馈
• 对于中等任务，我们将产品/系统设计放在一个规划文档中，不费心将工作分成阶段
• 对于大型事物，我们做所有步骤。对于没有意义的事情，比如大型重构，我们会跳过产品部分。

在大多数情况下，我会让模型一次做 1-3 个切片，并随着进展审查代码。早期重新引导，无论是内部实现还是实际功能，都容易得多，而不是最终面对 2000 多行代码却不知道什么坏了。

你可能觉得你有太多PR

你没有太多 PR。你有太多糟糕的 PR。

早在 AI 出现之前，我们所有人都审查过很多需要返工的 PR。

但是一个好的 PR 是审查的乐趣。你滚动浏览每个文件，代码很干净，它遵循了所有你关于软件应该如何的决策/讨论/来之不易的意见。

另一方面，如果一个PR需要甚至 20% 的返工（这已经很大方了，我会说大多数 AI 一次性 PR 更接近 50%），那对提交者和审查者来说都是一个智力负担和情感负担。（即使提交者是一个 AI，可能有人启动了这项工作，或者凭感觉优化了 AI 的结果，或者至少对结果关心。）

为了节省你的时间（我们快结束了），我在一次支线任务中更多地唠叨了这一点：“时间都去哪儿了”

约束理论（2026 版）

很容易对这个核心论点感到有点沮丧："目前我们还得读代码"。

我曾对一个世界感到非常兴奋，在那里我们可以只要求东西，让模型自由发挥，不读代码，就能得到随时间演变的美丽生产软件，而不会变糟。

但我尽力在这里阐述的只是约束。模型擅长某些事情，在其他事情上不那么擅长。在考虑到这些约束的情况下，你如何优化你的流程？

模型擅长某些事情，在其他事情上不那么擅长。在考虑到这些约束的情况下，你如何优化你的流程？

有可能你太忙于试图移动 10-100 倍快，并试图说服自己代码质量不再重要，而你可以拥抱约束，以 2-3 倍的速度安全地移动。

我最后的建议基本上是：

1. 很好地了解约束，通过大量使用模型来培养直觉
2. 在这些约束的领域内优化系统
3. 寻找杠杆点
4. 读那该死的代码

就是这样。如果你想留下来听推销，那就继续往下翻吧。我希望这能帮助你避免灾难，或者至少你看着一些可爱的动画玩得开心。

感谢阅读

🫡 -dex

PPS 其他资源

播客和文章：

• Dex 和 Gergely 在《务实工程师》上讨论上下文工程和软件工厂 - 2026 年 7 月
• Dex 和 Matt Pocock 讨论常青的 AI 编码建议（以及 Ralph 循环）- 2026 年 1 月

AI That Works 剧集：

• 基准测试证明不了什么
• AI 编码的产品规范
• 用于更好背压的学习测试
• 将 12 因素代理原则应用于 AI 编码

本文链接：

• 软件工厂为何失败主题演讲 — AI Engineer World's Fair 2026
• StrongDM 的无灯软件工厂
• OpenAI：工程化（2026 年 2 月）
• Ryan Lopopolo 谈 Symphony（演讲，2026 年 4 月）
• Mario 在 AI Engineer Europe："在垃圾的世界里构建圆周率"
• FT：亚马逊因编码Agent事故宕机
• Matt Pocock：代码库正在崩溃
• Faros AI：AI 加速鞭打报告
• 编码Agent的高级上下文工程（演讲 2025 年 8 月）
• 禁止凭感觉（演讲 2025 年 11 月）
• 我们对 RPI 理解错了的一切（演讲 2026 年 3 月）
• Awesome-RLVR - 强化学习资源
• 编码Agent的高级上下文工程（文章）
• 12 因素代理
• Addy Osmani 谈凭感觉编码 vs. 维护
• 北约软件工程会议，1968
• 国防部 DevSecOps 参考设计 (PDF)
• Ramp 的编码Agent平台
• Stripe：Minions，一次性端到端编码Agent
• WorkOS：Project Horizon
• Brex (Latent Space)
• Dan Shapiro：通往软件工厂的五个层次
• Simon Willison 谈 StrongDM 的软件工厂
• "煮掉海洋"
• 霰弹式修改 (refactoring.guru)
• John Ousterhout — 软件设计的哲学
• Robert C. Martin — 代码整洁之道
• Martin Fowler — 重构
• 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)

[^1]: 循环，作为一种 AI 技术，或多或少是由一位据称是山羊农场主在澳大利亚海岸的一个偏远岛屿上发现的。 [^1b]: 我做这个感觉已经太久了，但普遍认为大幅增长是在 2025 年 12 月进入新年的时候。 [^3]: 是的，当然你可以让 gpt-5.5 xhigh 做出色的重构。但你必须告诉它去做。而告诉它去做，你需要充分理解你的代码库，知道它需要被做。我们在这里讨论的是为什么无灯行不通。 [^5]: 大约在 2013 年，在 Sprout Social，我的老板告诉我他喜欢玩的一个游戏，就是看看你从 Python 单体中删除了多少行代码而没有导致数千个单元测试中的任何一个失败。 [^6]: 是的，我选择了那个词，并且一个字符一个字符地打出来，因为在这里它很合适。如果你觉得代码已经够糟了，别提那些垃圾代理散文了。

• 原文链接： github.com/humanlayer/ad...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～