软件工厂为何失败（二）：把灯重新打开——四阶段前置规划换回代码评审

这是“软件工厂为何失败”系列的第二篇。

第三篇在此 - x.com/dexhorthy/status/2081797628552270027

本篇演讲版已上线 YouTube（AI Engineer World’s Fair 2026 主题演讲）。

把灯重新打开

第一篇我深入讲了为什么模型不能被信任长期维护代码库质量。为什么再多 harness 工程或 tokenmaxxing 都解决不了模型训练与基准问题。为什么“模型当法官”评代码质量不如某些人想让你相信的那么有效。

就目前而言，法官是你——所以我们要把代码评审放回来。

我们要拥抱 AI 之前我们一直在做的事：提前做一点规划，降低长而艰难评审的概率。

我们要找到杠杆，并用 AI 辅助这件事，横跨四个阶段：

• 产品需求（Product Requirements）
• 系统架构（System Architecture）
• 程序设计（Program Design）
• 垂直切片（Vertical Slices）

产品评审

一切始于产品评审：一份钉死“我们在建什么、为什么建”的短文档。目标是把两句话或一段长长的语音备忘转成半结构化的东西。

首先对齐要解决的问题——用用户的话说，真实的用户痛点。其次，成功长什么样——发货后我们能读到什么来判断这东西值得建。理想情况是用户结果，比如“能更快完成 XYZ 工作流”或“更早到达 onboarding 里程碑 ABC”。有时更低层，比如错误率或延迟数字，有时就是“关于 X 的客服工单消失了”。

我们尽量把这个阶段锚在产品空间，不是技术空间。作为一只脚在产品世界一只脚在技术世界的人，我经常发现自己在这里漂进技术细节。发生时，我就先记下来留给后面的阶段，回到用户真正体验到什么。如果技术决策卡住了产品决策，那就先提交现有的，进入架构或做更多可行性原型研究。

由于这里大部分是关于用户看到什么，我不描述——我 mock 出来。一张实际屏幕的粗糙 HTML mockup 能解决三段文字只会拖延的争论。

这是一个进行中的真实例子——文档用 JSON 大纲钉死功能，然后是实际屏幕的两张粗糙 HTML mockup：

x.com/dexhorthy/status/2078592010852982977

当然，不是所有东西都需要产品评审。一处文案微调、一个一次性脚本、一个有明确复现的 bug——这些我们仍然直接 oneshot 给 agent。这个流程是为那些“agent 误解我们意图代价很高”的变更准备的。

对本文及系列中的所有文档，我们做作者自愿评审。如果你想在评审时省时间，就挑那个本来会评审这个 PR 的人，在进入编码之前跟他过一遍产品/技术 spec，可以异步通过文档评论（我们用 humanlayer 内测，但你完全可以在 github/notion/plan annotator 里做同样的事）。

系统架构

产品评审定下来后，我们做系统架构。这没什么特别新颖的，连 vibe coder 都开始奉为圭臬了。

如果想在评审时省时间，就挑那个本来会评审 PR 的人，在写代码之前跟他过一遍产品/技术 spec。

这个阶段我们只对齐服务、端点、schema、队列和存储之间怎么对话，不进入程序设计细节。为了最大化人类与 agent 的沟通带宽，我们在这里大量使用可视化——比如时序图：

契约/端点形态：

数据模型与变换：

Mermaid 没问题，但有时是杀鸡用牛刀，有时会让你陷入“已对齐”的虚假安全感。架构杠杆率相当高，很多潜在坏模型习惯可以在这个阶段提前掐掉。但它不足以产出高质量代码。为此我们需要程序设计。

程序设计

架构之后我们做这件我认为在 agentic coding 里被严重低估的事：程序设计。

多数人假设架构对了，模型就能直接开 cook。你可以这么干，但结果可能不合你意。

实际有效的是：在任何人（人类或 agent）写实现之前，从架构再往下一层进入代码的形态：类型、方法签名、程序布局和调用栈。

我们程序设计技能的第一个版本很糟。难读，累人。我们试过 mermaid，它有它的位置，但我们真正爱的是轻量伪代码可视化：

调用栈树，用于任何编排或控制流变更。当有趣的部分是“什么在变”时用 diff 语法：

Dillon Mulroy 谈过在他的规划流程里用调用图，我认为完全正确。

文件树 diff——让你保持对代码库布局和东西住在哪里的感知

关键新函数的类型与方法签名——那些太内部进不了架构文档、但 agent 仍可能搞错的东西

这些产出都不费时（模型起草，你跟它吵），而其中每一个都是你原本会在代码评审时隐式做出的决策——在改主意最贵的时刻。

垂直切片

接下来我们爱做我称之为“垂直切片”的东西——Matt Pocock 和我在 2026 年 1 月的直播里聊过垂直切片或“tracer bullets（曳光弹）”。

模型热爱我称之为“水平计划”的东西——按栈顺序干活：

• 数据库迁移
• 服务层
• API
• 前端

实践中，这意味着推进过程中你没有任何办法“摸到”解决方案。你可以用代码测试，但对我建过的几乎任何功能，读测试只是起点，干活时把东西拉到浏览器里、或用 curl 打一下，始终是工作流的高频部分。

AI 之前，很少有人不沿途检查任何东西就写 2000+ 行甚至 500 行代码。

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

• 建 API 契约并返回 mock 数据，用 curl 测试

• 建前端消费 mock 数据，在浏览器里迭代打磨

• 把 API 接到服务层（服务返回 mock 数据/行为）

• 加数据库迁移，把服务接到数据库

• 加一堆业务逻辑

• 加一堆错误处理

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

如果我很在乎这段代码，或怀疑模型在这部分代码库干活的能力，我在每一步也评审代码。在这里检查 100-200 行再重新引导，便宜得多。

在这一点上……多数前沿模型不会在没有人类引导的情况下设计出这样的计划，而且这难以按代码库甚至按任务泛化，所以我偏好留在这里盯着。相信我。如果我能外包思考就好了。

30 分钟规划省下数小时评审

于是我们有一些步骤，我认为人类必须留在环里，如果你想在不大规模当 slop 代码清洁工的前提下维持接近人类的质量（也就是说你真的想快）：

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

显然我们不是对发货的每个东西都走全套（见下方 sidequest）。我猜分布大致是：

• 约 40% 的任务直接 oneshot 或 oneshot 加 1-2 轮轻反馈
• 中型任务，产品/系统设计合并进一份计划文档，不拆阶段
• 大型任务，全套。对不适用的场景跳过产品部分，比如大型重构

多数情况下，我一次派模型做 1-3 个切片，边做边评审代码。早期重新引导——不管是内部实现还是实际功能——都比置身 2000+ 行代码另一端、不知什么坏了要容易得多。

你大概觉得 PR 太多了

你不是 PR 太多。你是烂 PR 太多。

AI 之前很久，我们就评审过大量需要返工的 PR。

但一个伟大的 PR 是评审的享受。你滚过每个文件，代码干净，它遵循你们所有关于软件该怎么建的决策/讨论/来之不易的观点。

另一方面，如果一个 PR 需要哪怕 20% 返工（这算客气的，我说多数 AI oneshot PR 更接近 50%），这对提交者和评审者都是智力负担和情感负担。（哪怕提交者是 AI，大概率有人启动了这项工作，或 vibe 打磨过 AI 结果，或至少在乎结果）。

给你省点时间（我们快到结尾了），我在一个 sidequest 里聊过更多：

“时间都去哪了”

约束理论（2026 版）

对本文核心论点——“就目前而言我们还得读代码”——有点沮丧是正常的。

我曾相当兴奋地期待一个我们只要提需求、让模型 cook、不读代码、就能得到随时间演进且不崩坏的漂亮生产软件的世界。

但我在这里尽力铺陈的，无一不是约束。模型擅长一些事，不擅长另一些。在这些约束下你如何优化你的流程？

模型擅长一些事，不擅长另一些。在这些约束下你如何优化你的流程？

你有可能正忙着尝试 10-100 倍提速、说服自己代码质量不再重要，而其实你可以拥抱约束、安全地 2-3 倍提速。

我的收尾建议基本是：

• 充分了解约束，通过大量与模型工作培养直觉

• 在这些约束的竞技场内优化系统

• 寻找杠杆

• 读那该死的代码

就是这样。如果你想留下来听 pitch，继续滚吧。希望这些帮你避开了灾难，或至少你看可爱小动画看得开心。

感谢阅读

-dex

-这是“软件工厂为何失败”第二篇。

第三篇在此 - x.com/dexhorthy/status/2081797628552270027

PS 我们痴迷于此

我们在建 humanlayer.com，一个 agentic IDE 与协作平台，帮你在维持人类（或相当接近人类）代码质量的同时 2-3 倍提速。

我们朝两个想法前进：“软件工厂的积木”和“软件可维护性的更好验证器”（或许还有更好的模型）。

HumanLayer 对 3 人以内小团队免费，需要起步帮助可以来 Discord 玩或给 写信。

快速感谢 @calvinfo 的启发、联创 @0xBlacklight、@swyx 和 @aiDotEngineer 团队给我舞台探索这些想法，以及所有为我们加油的出色客户、投资人、朋友和家人。

原文信息

• 作者：Dex Horthy（@dexhorthy），HumanLayer 创始人
• 原文发布日期：2026-07-25 原文地址：