AI编码时代如何维持代码质量

这是 为什么软件工厂会失败 的第二部分。该文章的演讲版本已在 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 的人，并与他们一起（异步地通过文档评论，或者直接在 GitHub/Notion/Plannotator 等工具中）过一遍产品/技术规范。

系统架构

产品评审完成后，我们进行系统架构。这并不特别新颖，即使是 Vibe 程序员也开始推崇它。

如果你想在审查时节省时间，你可以选择审查 PR 的人，并在进入编码部分之前与他们一起过一遍产品/技术规范。

在这个阶段，我们要对齐服务、端点、模式、队列和存储如何相互通信，而不涉及 程序设计 的细节。为了最大化人机通信带宽，我们在此大量使用可视化工具——例如序列图：

契约/端点形状：

数据模型和转换：

这里用 Mermaid 没问题，但有时可能过于繁琐，有时可能诱使你产生一种虚假的对齐感。架构是比较高杠杆的，你可以在这个阶段避免许多潜在的不良模型特征。但这不足以产生高质量的代码。为此，我们需要程序设计。

程序设计

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

大多数人认为一旦架构正确，模型就可以直接输出了。你可以这样做，但结果可能并不理想。

但我看到效果不错的是，在任何人（人或 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

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