当 AI 写完所有代码

Mark Phelps' Blog 2026-10-28T16:06:15.267692

最近在讨论 AI 编程代理时，你可能常看到“软件工厂”这个说法。它的目标是：把一份规格说明自动变成可运行的软件，实现和验证都交给机器完成。

我喜欢做软件。如今代理写的代码越来越多，我原以为自己会更舍不得放手，但实际上，我并不怎么怀念逐行敲代码的感觉。

我依然喜欢思考要做什么、梳理架构、决定各个部分怎么拼在一起。当代理做出一个像样的功能时，我想亲自用一用，看看整个应用的行为是否符合预期。

至于每一个小改动，我不需要亲自去验证。对我来说，关键在于：我能把多少实现工作交出去，同时还能对正在构建的东西保持有用的理解，并且继续参与我真正喜欢的部分。

软件工厂自动化了什么

人的参与程度各不相同。有些流程仍然让人审查每一处改动，另一些则想彻底去掉人工代码审查。

Dan Shapiro 提出的框架把自动化分成 0 到 5 级：

一个倒金字塔，展示从第 0 级手动编码到第 5 级黑暗工厂的六个等级，越往下人在实现中的参与越少。

Shapiro 的等级划分，体现人在实现中的参与逐步减少。色带宽度仅作示意。

等级	人的参与
0	你自己写代码，可能用 AI 做搜索或偶尔自动补全。
1	你委托一些独立任务，比如写单元测试或补文档。
2	你和 AI 结对，交互式地完成实现。
3	代理写代码，你把时间花在审查它们的改动上。
4	你编写和打磨规格说明，审查计划，让代理执行，然后再检查结果。
5	整个过程变成黑箱，把规格说明直接变成软件。

Shapiro 把第 5 级称为“黑灯工厂”：一个把需求规格变成软件的黑盒。这描述的是实现怎么发生，并不意味着人们必须放弃决定要构建什么、或不再设定架构约束。

StrongDM 描述了一种“软件工厂”——规格和场景驱动智能体写代码、验证代码，全程不做人工代码审查。他们的方案包括把验证场景存在代码库之外，这样智能体就更难为了通过测试而重写测试。在介绍这种做法时，他们说：“内部结构被视为不透明的。”他们通过外部可观察的行为来评估正确性。

这是检查实现方式上的一个有意义的变化。不过，构建验证系统仍然属于工程工作。团队可以在自动完成实现和验证的同时，定义需求、设定约束、决定什么才算有用的结果。我自己的流程里也有许多相同的要素。

我喜欢琢磨需求。我喜欢思考架构、挑选依赖、弄清楚各个部分该怎么拼在一起。这些决定是我享受构建软件的重要原因。

我希望能够解释自己为什么选择某种方案，以及我期望它做到什么。对于交付给客户的软件，我还想了解它依赖什么、依赖失效时会发生什么、有什么证据能支撑放心把客户数据交给它。一个能跑的演示或者一整套全绿的测试，回答不了我所有这些问题。

逐行读代码并不是建立这种理解的唯一方式。规划、文档、测试、实际使用应用，都有帮助。它们也各有局限。我仍然需要一种办法来检查：实现是否和我以为要交付的设计一致。

Vibe coding 很好玩。我一直在做。写这段文字的时候，我手头有五个个人项目在跑，大多是 vibe coding 出来的。我在不懂 Swift 的情况下做了两个 macOS 应用，第三个正在做。我还在写一个 Obsidian 插件，它的代码我一行都没读过。

上面最后一个例子说明了我能保证的范围有限。我可以验证插件的行为是否符合预期，但这本身并不能说明它的实现是否安全、是否好维护。在个人项目上，我愿意这样试验。但如果软件是要交付给别人的，我不会认为同样的检查就够了。

下面是我实际用的流程：

想清楚要解决什么问题。 我会先想明白这个应用或插件要实现什么、做成什么样才有用。
过一遍架构。 考虑用什么语言、什么技术栈、依赖哪些东西，各部分怎么拼在一起。平台会限制一部分选择，但仍有需要自己决定的地方。
把需求磨清楚。 写一份产品需求文档（PRD），再和不同的模型来回讨论几轮，直到方案清晰到可以动手实现。我会花不少时间在这里和模型提出的方案「较劲」。
给智能体立规矩。 配好项目规则、代码检查（linting）、防止生成低质代码的钩子、测试框架和持续集成（CI），让智能体有约束、有反馈。
重要功能自己验。 我会确认测试通过，但也会亲自跑起应用、试一些较大的功能。我要整体看一遍，判断它是否按我预期的方式工作。测试也是智能体写的，所以我不会把「测试通过」当成最终结论。
实现之后继续盯。 视情况补上错误上报、日志、性能测试和其他可观测性手段。

这套流程有些地方像 Shapiro 所说的第 4 级，有些则可能算第 5 级的「工厂」。我不觉得选定某一级能说明什么——关键是我能不能从这个流程里拿到想要的结果。小改动我可以放心交给自动化检查；重要功能，我愿意花时间去亲自体验成果。

自动化测试检查的是我们事先定义好的场景。而亲手用一遍较大的功能，还能帮我判断这些场景是否真的覆盖了我想要的东西。

一个功能可能满足规格说明，用起来却仍然别扭（我经常碰到这种情况）。两个功能单独跑都没问题，凑到一起却格格不入。也可能是我发现，自己提的需求并没有像预期那样解决问题。这种事发生的频率，比我自己愿意承认的还高。遇到这些情况，需求就得再过一遍，哪怕代码确实按需求实现了。

工厂也可以有办法评估这些东西。我不认为亲自测试是第 4 级独有的做法，也不认为自动化就把产品判断排除在外了。我想亲自参与这种判断，尤其是当改动会改变应用行为的时候。

这并不意味着我的评估就有保证。把应用跑一遍，不会发现所有 bug，也不能证明实现是安全的。这些问题得靠别的检查。但我确实想知道，用自己正在做的东西是什么感觉。

随着工具变好，我预计会把更多工作交出去。今天我还想仔细检查的改动，以后可能就放心让它自动完成了。如果是个人实验，我可能接受更多不确定性，继续往前走。如果是客户依赖的东西，我就想要更硬的证据，以及失败时能诊断、能恢复的清晰路径。

做这些决定，我不需要承诺一直停在第 4 级。我需要的是一个流程，帮我搞清楚哪些已经检查过、哪些还不确定、哪里值得我亲自关注。

省下的实现时间，让我有更多余地想清楚设计、用一用这个应用。我可以试不同的做法，发挥自己的品味，做出有点个人风格的软件。这些是我做软件时想一直保留的部分。大功能做完后，我想试一试，看它和产品其他部分合不合得来，再决定它是不是我想要的样子。

也许最后我会用上那种可以叫「软件工厂」的东西。但我仍然想知道自己在交付什么，也仍然享受做它的过程。