这是第二部分，摘自为什么软件工厂会失败
本文的演讲版本已在 YouTube 上线：https://www.youtube.com/watch?v=Ib5GBkD555M
重新点亮灯光
在第一部分中，我深入探讨了为什么模型无法长期保持代码库质量，为什么再多的工程化或 token 优化也无法解决模型训练和基准测试问题，以及为什么“以模型为裁判”来评估代码质量并不像某些人想让你相信的那样有效。
目前，裁判还是你——所以我们要把代码审查重新拿回来。
我们要拥抱自 AI 出现之前就一直做的事情——那就是在前期做一点规划，以降低漫长而艰难的审查概率。
我们要找到杠杆，并利用 AI 来协助，分四个阶段进行：
- 产品需求
- 系统架构
- 程序设计
- 垂直切片
产品评审
一切从产品评审开始：一份简短的文档，确定我们要构建的内容和原因。目标是能够将两句话或一段冗长的语音笔记，转化为某种半结构化的形式。
首先，我们对齐要解决的问题——用户的实际痛点，用用户的语言描述。其次，成功的标准是什么——发布后我们可以阅读什么来判断这个功能值得构建。理想情况下，这是一个用户成果，比如“能在更短时间内完成 XYZ 工作流”或“更早达到里程碑 ABC”。有时是更底层的指标，如错误率或延迟数字，有时只是“关于 X 的工单停止了”。
我们尽量将这一点保持在产品领域，而非技术领域。作为一名既在产品领域又涉足技术的人，我经常发现自己在这里陷入技术细节。当这种情况发生时，我会尽量先记下来，留到后续阶段，然后回到用户实际体验上。如果技术决策阻碍了产品决策，我们就先提交已有的内容，进入架构阶段，或者进行更多关于可行性的原型研究。
既然这主要关乎用户所见，我就不描述它了——我会直接做原型。一个粗糙的 HTML 原型就能解决三个段落只会拖延的争论。
这是一个正在进行的真实案例——文档用 JSON 提纲确定了功能，然后是两个粗糙的 HTML 屏幕原型：
https://x.com/dexhorthy/status/2078592010852982977
当然，并非所有内容都需要产品评审。一个文案调整、一个一次性脚本、一个明显可复现的 bug——我们仍然会直接一次性交由 Agent 处理。这种方法适用于那些 Agent 误解意图会导致高成本变更的场景。
对于本系列中的所有文档，我们都采用作者主动选择审查的方式。如果你想在审查过程中节省时间，就选择会审查 PR 的那个人，并通过文档评论（我们内部使用 HumanLayer 进行，但你也可以在 GitHub/Notion/Plannotator 等工具中轻松完成）异步地与他们一起过一遍产品/技术规格。
系统架构
一旦产品评审确定，我们就进行系统架构。这没什么特别的，即使是那些“氛围编码”者也开始认同这一点。
如果你想在审查过程中节省时间，就选择会审查 PR 的那个人，并在进入编码阶段之前，与他一起过一遍产品/技术规格。
在这个阶段，我们对齐服务、端点、模式、队列和存储之间如何通信，而不涉及程序设计的细节。为了最大化人机通信带宽，我们大量使用可视化工具——例如序列图：
合约/端点形状：
数据模型和转换：
Mermaid 在这里是不错的，但有时可能过于繁琐，甚至让你误以为已经对齐了。架构的杠杆作用相当高，而且你可以在这个阶段阻止许多潜在的不良模型倾向。但单靠架构还不足以产生高质量代码。为此，我们需要程序设计。
程序设计
架构完成后，我们会做一件我认为在 AI 编码中被严重低估的事情：程序设计。
大多数人认为，架构正确后，模型就能直接输出。你可以这样做，但结果可能不会让你满意。
但我发现效果好的做法是：在任何人（人类或 Agent）开始编写实现之前，我们从架构往下再深入一层，关注代码的形状：类型、方法签名、程序布局和调用栈。
我们程序设计的第一个版本很糟糕。它难以阅读，令人疲惫。我们尝试过 Mermaid，它有用武之地，但我们真正喜欢的是用伪代码进行轻量可视化：
调用栈树，适用于任何协调或控制流变更。当有趣的部分是变化时，使用 diff 语法：
Dillon Mulroy 提到在规划过程中使用调用图，我认为这完全正确。
文件树差异——这样你就能随时了解代码库的布局以及文件的位置：
关键新函数的类型和方法签名——这些内容对于架构文档来说过于内部，但 Agent 仍可能搞错：
这些都不需要花很长时间来制作（模型起草，你与它争论），而且每一个都是你在代码审查中本会隐式做出的决定——而那时正是改变主意成本最高的时刻。
垂直切片
接下来，我们喜欢做我称之为“垂直切片”的东西——Matt Pocock 和我在2026 年 1 月的直播中讨论过垂直切片或“追踪弹” ——这也被称为追踪弹。
模型喜欢我称之为“水平计划”的东西——按堆叠顺序进行：
- 数据库迁移
- 服务层
- API
- 前端
实际上，这意味着没有真正的方法可以在进行过程中“触摸”到解决方案。你可以用代码测试，但对于我构建过的几乎所有功能，阅读测试只是一个开始，在浏览器中拉起页面或用 curl 测试是我工作流程中经常出现的一部分。
在 AI 出现之前，很少有人会在不检查某些东西的情况下编写 2000 多行甚至 500 行代码。
我花了一段时间才注意到与我习惯的差异——在 AI 出现之前，我写代码时总是从中间开始，向外扩展。大致如下：
- 创建 API 合约并提供模拟数据，用 curl 测试
- 创建前端来消费模拟数据，在浏览器中迭代和打磨
- 将 API 连接到服务层（服务层提供模拟数据/行为）
- 添加数据库迁移，将服务连接到数据库
- 添加大量业务逻辑
- 添加大量错误处理
并且我在每一步都进行测试/迭代/打磨。
如果我对代码非常在意，或者怀疑模型在这部分代码库中能否做好工作，我会在每一步都审查代码。检查 100-200 行代码并重新调整方向，比处理大堆问题要便宜得多。
大多数前沿模型在没有人类引导的情况下不会设计出这样的计划，而且很难针对每个代码库甚至每个任务进行泛化，所以我更倾向于在这个环节保持参与。相信我。如果我能把思考外包出去，我也会这么做。
30 分钟的规划能节省数小时的审查时间
因此，我认为，如果你希望保持接近人类的代码质量，而不必在事后费力清理大量劣质代码（也就是说，你实际上想快起来），那么有几个步骤人类需要参与其中：
- 产品设计
- 系统架构
- 程序设计
- 垂直切片
显然，我们不会为所有交付的内容都执行整个流程（参见下面的支线任务）。我猜测分布大致如下：
- 约 40% 的任务一次性完成，或一次性完成并附带 1-2 轮轻量反馈
- 对于中等任务，我们将产品/系统设计合并到一个计划文档中，不将工作分解为阶段
- 对于大型任务，我们会执行所有步骤。对于大型重构等不适用的情况，我们会跳过产品部分。
在大多数情况下，我会让模型一次处理 1-3 个切片，并边进行边审查代码。无论是内部逻辑还是实际功能，早期重新调整方向要比在 2000 多行代码的另一端不知道哪里出了问题容易得多。
你可能觉得你的 Pull Request 太多了
你没有太多 PR。你只是有太多糟糕的 PR。
在 AI 出现之前，我们早就审查过许多需要返工的 PR。
但一个好的 PR 是审查的乐趣。你浏览每个文件，代码整洁，遵循了你所有关于软件应该如何构建的决策、讨论和来之不易的观点。
另一方面，如果一个 Pull Request 需要 20% 的返工（这已经很慷慨了，我认为大多数 AI 一次性 PR 的返工率接近 50%），那对提交者和审查者来说既是智力负担也是情感负担。（即使提交者是 AI，可能也有人启动了这项工作，或者对 AI 结果进行了打磨，或者至少关心最终结果。）
为了节省你的时间（我们快结束了），我在一个支线任务中对此进行了更多讨论：
约束理论（2026 版）
核心论点很容易让人有点沮丧：“目前我们还得阅读代码。”
我曾对这样一个世界充满期待：我们可以直接提出需求，让模型自行处理，无需阅读代码，就能获得美丽的生产级软件，随着时间推移不断演进，而不会变得一团糟。
但我在这里尽力阐述的不过是一些约束。模型擅长某些事情，而不擅长其他事情。你如何在这些约束下优化你的流程？
模型擅长某些事情，而不擅长其他事情。你如何在这些约束下优化你的流程？
你可能太忙于追求 10-100 倍的速度，并试图说服自己代码质量不再重要，而实际上你可以拥抱这些约束，安全地实现 2-3 倍的速度提升。
我最后的建议大致如下：
- 深入了解约束，通过大量使用模型来培养直觉
- 在这些约束的范围内优化系统
- 寻找杠杆
- 阅读该死的代码
就是这样。如果你想留下来听个宣传，那就继续往下看吧。希望这能帮助你避免灾难，或者至少你在看那些可爱的小动画时玩得开心。
感谢阅读
-dex
附言：我们对此无比投入
我们正在构建 humanlayer.com，一个 Agentic 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 Engineer World's Fair 2026
- StrongDM 的关灯软件工厂
- OpenAI：工程化（2026 年 2 月）
- Ryan Lopopolo 谈 Symphony（演讲，2026 年 4 月）
- Mario 在 AI Engineer Europe 上：“在劣质代码世界中构建 Pi”
- FT：亚马逊因编码 Agent 失误导致宕机
- Matt Pocock：代码库分崩离析
- Faros AI：AI 加速鞭打效应报告
- 面向编码 Agent 的高级上下文工程（演讲 8/25）
- 不允许氛围（演讲 11/25）
- 我们在 RPI 上犯的所有错误（演讲 3/26）
- Awesome-RLVR - 强化学习资源
- 面向编码 Agent 的高级上下文工程（文章）
- 12 因子 Agent
- Addy Osmani 谈氛围编码与维护
- NATO 软件工程会议，1968 年
- DoD 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 多语言（数据集）
- AIE Worlds Fair 2026 - 大循环辩论（“炒作已超越纪律”）
- SWE-Marathon（Abundant AI）
- DeepSWE（Datacurve）
- Frontier Code（Cognition）
- 变异测试（Wikipedia）
- Dillon Mulroy 谈规划中的调用图
- Dex × Matt Pocock：垂直切片 / 追踪弹（直播，2026 年 1 月）
- “思考的艰苦工作无法外包”（Jake Nations）
