当 LLM 生成代码不再被阅读：AI 生成软件的发布、责任与工程学

关于软件工程、认识论，以及当代码由 LLM 生成时的责任问题。

Robert C. Martin 最近的一条推文引起了广泛关注：

“我目前的策略是不读我的智能体写的任何代码。这是我利用它们生产力的唯一方式。我做的反而是给智能体设置极端的约束。单元测试、gherkin 测试、QA 流程、质量指标、变异测试、测试覆盖率，以及一大堆其他东西。最终，我对它们产出的代码非常有信心，因为它们必须通过我所有约束和测试的严苛考验。”

Clean Code 的作者不再读代码了？这对软件工程意味着什么？

需要说明的是，如今思想领袖与 LLM 的互动方式变化如此之快，以至于某人几个月前写的东西可能已经不再适用。事实上，Robert C. Martin 最近收回了关于他使用 harness 的说法。

然而，本文的目的并不是对 Robert C. Martin 的推文进行解读，而是思考其对软件工程的影响。

看代码从来都不是万无一失的 #

我对甚至不看 LLM 生成代码这一想法的第一反应是：如果你不再读代码，那你怎么知道它是否正确？

一秒钟后，我意识到那只是一个老程序员的本能反应。我完全清楚，看代码从来都不是万无一失的。

所有程序员都会犯错。我们写代码时以为它做一件事，但结果它的行为略有不同。它可能表现出边缘行为，比如抛出空引用异常、存在差一错误、执行了被忽视的状态变更，或者干脆就是完全错误的。

一些研究似乎表明，代码审查是发现 bug 较为有效的方法之一（参见例如 Code Complete, 2nd ed，第 21 章）。即便如此，这些技术也无法检测出所有缺陷。有些错误会溜过去，即使经过了批判性和系统性的检查。

换句话说，人类看代码并不是一种万无一失的软件工程技术。

一种新的软件工程概念？ #

Dave Farley 的书 Modern Software Engineering 提出了一种与我自己的观点一致的软件工程观。归根结底，软件工程归结为对关于软件的可证伪预测的快速反馈。

即使我们放弃编写和审查源代码的想法，我们仍然可以执行一些检查。有些人尝试使用智能体“团队”，每个智能体都有特定的角色：你可以让一个智能体编写自动化测试，另一个执行代码审查，等等。虽然我之前对这种看似无限递归的做法持怀疑态度，但我最近开始明白，我们以前以人为中心的实践也并非万无一失。

尽管我相信测试驱动开发（TDD）是我所知的最科学的软件开发方法，你仍然可能犯错。TDD中最常见的错误类型是你没有编写的测试。缺失的测试用例会让被测系统规格不完整，但你甚至可能没有意识到这一点。

大型语言模型似乎使用其他启发式方法来生成代码，甚至是自动化测试代码。使用智能体“团队”的人报告了良好的结果。

归根结底，要求基于大型语言模型的软件工程做到完美，设定了一个我们人类程序员从未达到的标准。相反，我们似乎得出了与自动驾驶汽车相关的常见论点相同的结论：系统不必完美：它只需要优于以人为中心的系统。

我的主张并不是我们已经达到了那种状态。关键在于，对于完全由大型语言模型驱动的软件工程流程，似乎不存在固有的障碍。

责任落在何处？#

那么，你可以想象一个完全由大型语言模型驱动的软件发布流程。也许有人类参与，但不是作为程序员，也不是作为代码审查者。想象一下，没有人查看代码，而是依赖其他质量保证技术来决定是否部署。甚至，为了论证起见，想象一下缺陷的频率低于任何可比的人类驱动流程。

更低。但不是零。

错误仍然会进入生产环境。其中大多数可能属于良性性质：按钮对齐有偏差。文本以错误的语言显示。消息到达两次，或顺序错乱。也许比这更严重一些：购物篮折扣应用错误。你的手机上播放了错误的歌曲。交通信号灯卡在红灯。

在这个粗略的分类中，良性错误是那些在某种程度上可以纠正的错误。一旦你发现了它，你就可以修复问题。也许你需要向人们道歉，或者如果折扣计算错误对卖家有利，你可以向用户提供某种补偿。

然而，其他类型的错误会更严重：你损失了一艘价值百万美元的航天器。你的汽车在你踩刹车时加速。你因为竞态条件而受到致命的辐射过量。

这类错误甚至不必那么严重。可能“仅仅”是人们错过了航班，被拒绝入住已经预订的酒店房间，收到错误的税单，或失去保险覆盖。

当软件缺陷足够严重时，可能会产生后果。责任落在何处？

后果#

首先考虑那些“仅仅”让所有者损失大量资金的错误。火星气候轨道器惨败就属于这一类。没有违反任何法律。唯一的问题是3.276亿（纳税人）美元被浪费了。

如果这样的错误没有给某人带来后果，那将是一个非凡的软件组织。当人们还在通过将代码输入计算机来编写代码时，很容易指着说：戴夫写了那段代码。

并不是说这种简单的归咎方式就是公平的，甚至谈不上有成效，但它们确实会发生。总有人要承担后果，哪怕他或她只是个替罪羊。

只要问题基本上是组织内部的，如果你是替罪羊，最坏的结果可能就是被解雇。

另一方面，如果这个错误引发了法律责任，那么负责的软件组织可能不得不走上法庭。正如我们在例如柴油门事件中所见，个别软件开发者可能不得不背锅。同样，这是否公平，或者是否反映了事情的真实情况，并非我的重点。重点在于，世界各地的司法部门对责任归属的看法，很可能与软件实际是如何生产出来的脱节。

——但是，法官大人，这个 bug 是大语言模型写的。

——你是这么说的，孩子，但发布是你签字批准的，不是吗？

——是的……

——我没法把大语言模型送进监狱，但我可以判你的刑。

任何考虑走向“全面 AI 化”的软件组织，都需要认真思考这在责任方面意味着什么。

人们会赌概率#

让我们看看另一个领域最近的一项进展，以说明我认为将会发生什么：2026 年 6 月，丹麦交通管理局 Færdselsstyrelsen 批准了 Tesla FSD（自动驾驶），但附带条件是方向盘后的人最终对车辆负责。驾驶员应当关注交通状况，并在出现危险情况时接管方向盘。

我认为将会发生的是，驾驶员会因系统的高效而变得越来越麻木。它表现得越好，驾驶员就越会走神。几周或几个月后，驾驶员在大部分行程中都会玩手机，几乎完全不关注交通。大多数情况下都会平安无事。

然后，偶尔地，事故会发生。按照丹麦现行法律，如果事故涉及人员死亡，驾驶员将面临过失杀人罪的判决。这通常意味着监禁。

事故的“真正”原因是不是软件错误，这并不重要。在法律上，责任在别处。通常，根本原因是立法落后于技术现实。

我认为，大语言模型驱动的软件工程也会发生同样的情况。人们会赌概率，因为它们看起来太有吸引力了。

你在防护措施和各种质量保证技术上投入多少可能并不重要。你可以建立最精密的验证体系，却仍然要为任何错误承担责任。对于发布大语言模型生成的软件，你怎么看？你准备好为 AI 去坐牢了吗？

结论#

软件工程可能并非我们以为的那样。或者更确切地说，它可能并不局限于围绕人类程序员和测试人员的一套特定方法论。

可以想象，未来会出现完全自动化的软件工程流程，其安全性至少不亚于我们目前所知的那些流程。即便如此，人类关于法律责任和责任的观念可能也跟不上。

当事情出错时，组织会将错误归咎于无人负责吗？法院会将严重缺陷视为本质上又一场意外吗？还是必须有人承担责任？如果没有人编写任何代码，那会是谁呢？