发布AI生成的软件（8分钟阅读）

# 发布 AI 生成的软件 来源：https://blog.ploeh.dk/2026/10/12/releasing-ai-generated-software/ *当代码由 LLM 生成时，关于软件工程、认识论与责任归属的思考。\* Robert C\. Martin 最近的一条推文引发了广泛关注： > "我目前的策略是，不读我的智能体（agent）写的任何代码。这是我能利用它们生产力的唯一方式。我做的是用极端约束来包围这些智能体——单元测试、Gherkin 测试、QA 流程、质量指标、变异测试、测试覆盖率，以及大量的其他手段。最终，我对它们产出的代码有很高的信心，因为它们必须经受住我所有约束和测试的考验。" 《Clean Code》(https://blog.ploeh.dk/ref/clean-code) 的作者不再读代码了？这对软件工程意味着什么？ 需要澄清的是，如今思想领袖们 (https://twitter.com/hillelogram/status/1445435617047990273) 与 LLM 互动的方式变化极快，某人几个月前写的文字可能已经不再适用。事实上，Robert C\. Martin 最近已经收回了他对工具链使用的看法 (https://x.com/unclebobmartin/status/2098432570887217520)。 然而，本文的重点并不是对 Robert C\. Martin 的推文进行诠释，而是思考这对软件工程的启示。 ### 看代码从来就不是万无一失的\# (https://blog.ploeh.dk/2026/10/12/releasing-ai-generated-software/#5b34aef318e3492eb56085923dfdb9f7) 我最初对"甚至不看 LLM 生成的代码"这个想法的反应是：*如果你不再读代码，那你怎么知道它是对是错？* 但一秒钟后我意识到，这不过是老程序员的条件反射罢了。我完全清楚，看代码从来就不是万无一失的。 所有程序员都会犯错。我们写代码时以为它做的是某件事，结果发现它的工作方式略有不同。它可能表现出一些边缘行为——抛出空引用异常、存在差一错误、执行了被忽略的状态变更，或者干脆就是错的。 一些研究 (https://blog.ploeh.dk/2020/05/25/wheres-the-science) 似乎表明，代码审查是发现缺陷最有效的方法之一（参见《Code Complete》第二版 (https://blog.ploeh.dk/ref/code-complete) 第 21 章）。即便如此，这些技术也无法检测出所有缺陷。有些错误会漏网，即使经过了严格而系统的审查。 换句话说，人类看代码并非万无一失的软件工程手段。 ### 一种全新的软件工程理念？\# (https://blog.ploeh.dk/2026/10/12/releasing-ai-generated-software/#ef1e62f2055347669ee0740438417caa) Dave Farley 的著作《Modern Software Engineering》(https://blog.ploeh.dk/ref/modern-software-engineering) 呈现的软件工程观点与我自己的观点 (https://blog.ploeh.dk/2025/10/20/epistemology-of-software) 一致。归根结底，软件工程可以归结为：围绕关于软件的可证伪 (https://en.wikipedia.org/wiki/Falsifiability) 预测，获得快速反馈。 即使我们放弃了编写和审查源代码的想法，我们仍然可以执行一些检查。有人在试验由多个智能体组成的"团队"，每个智能体扮演特定角色：你可以让一个智能体编写自动化测试，另一个执行代码审查，等等。虽然我之前对这种看似无限递归的做法持怀疑态度 (https://blog.ploeh.dk/2026/01/26/ai-generated-tests-as-ceremony)，但我最近意识到，我们之前以人为中心的实践同样不是万无一失的。 尽管我相信测试驱动开发（TDD）是我所知的最科学的软件开发方法 (https://blog.ploeh.dk/2025/10/20/epistemology-of-software)，你仍然可能犯错。TDD 中最常见的错误是你没有编写的那些测试。遗漏的测试用例会导致被测系统规格不完整，而你可能根本意识不到这一点。 LLM 似乎使用另一套启发式规则来生成代码，包括自动化测试代码。使用"智能体团队"的人报告说效果不错。 最终，要求基于 LLM 的软件工程做到完美，其实是设立了一道人类程序员从未跨越过的门槛。相反，我们似乎得出了一个在自动驾驶汽车领域经常遇到的论点：系统不必完美，它只需要*比*以人为中心的系统*更好*就行。 我的主张并不是说我们已经达到了那个状态。关键在于，似乎不存在阻碍全面 LLM 驱动的软件工程流程的根本障碍。 ### 责任落在何处？\# (https://blog.ploeh.dk/2026/10/12/releasing-ai-generated-software/#899c925f4b41488d9982c5167d00bfda) 那么，你可以想象一个完全由 LLM 驱动的软件发布流程。也许人类会参与其中，但不是作为程序员，也不是作为代码审查员。想象一下，没有人看代码，而是依靠其他质量保证技术来决定是否部署。甚至，为了论证方便，假设缺陷频率低于任何可比的人工驱动流程。 更低，但不是零。 错误仍然会进入生产环境。其中大多数可能是良性性质的：一个按钮没有对齐。文本显示了错误的语言。一条消息重复到达，或者乱序到达。也许稍微严重一点：购物车折扣计算错误。你的手机上播放了错误的歌曲。一个交通信号灯卡在红灯上。 在这个粗略的分类中，良性错误是指那些可以补救的错误。一旦发现，你可以修复问题。也许你需要向人们道歉，或者如果折扣错误地有利于卖家，你可能需要向用户提供某种补偿。 然而，另一些类型的错误会更加严重：你损失了一架价值百万美元的航天器 (https://en.wikipedia.org/wiki/Mars_Climate_Orbiter)。你的汽车在踩刹车时反而加速了 (https://safetyresearch.net/toyota-unintended-acceleration-and-the-big-bowl-of-spaghetti-code/)。由于竞态条件，你遭受了致命的辐射剂量 (https://en.wikipedia.org/wiki/Therac-25)。 这类错误甚至不必那么严重。可能"仅仅"是人们错过航班、被拒绝入住已预订的酒店房间、收到错误的税单，或者失去保险保障。 当软件缺陷足够严重时，可能会产生严重后果。那么，责任归咎于谁？ ### 后果\# (https://blog.ploeh.dk/2026/10/12/releasing-ai-generated-software/#9da01c9e2db2400792e3195a7c6fed37) 先考虑那些"仅仅"让其所有者损失大量资金的 bug。火星气候探测器事件 (https://en.wikipedia.org/wiki/Mars_Climate_Orbiter) 就属于此类。没有违反任何法律。唯一的问题是 3\.276 亿（纳税人的）美元打了水漂。 如果这样一个错误没有给任何人带来后果，那这家软件组织就太了不起了。当人们还在把代码手动输入计算机时，很容易指着某人惊呼：*那段代码是 Dave 写的！* 这样说简单归咎的方式并不公平，甚至毫无建设性，但确实会发生。有人要承担后果，哪怕他或她只是一个替罪羊。 只要问题主要局限在组织内部，如果你是替罪羊，最坏的结果可能就是被解雇。 另一方面，如果错误导致了法律责任，那么负责的软件组织可能不得不上法庭。正如我们在大众排放门 (https://en.wikipedia.org/wiki/Volkswagen_emissions_scandal) 等案例中所见，个别软件开发者可能不得不当替罪羊。同样，这是否公平、是否反映了实际发生的事情，不是我的重点。重点在于，世界各地的司法机构很可能对责任归属有自己的看法，而这种看法与软件实际的生产方式是脱节的。 \- 但是，法官大人，bug 是 LLM 写的。 \- 你是这么说的，年轻人，但发布是你签的字，对吧？ \- 是的…… \- 我不能把 LLM 关进监狱，但我*可以*判你的刑。 任何考虑"全面 AI 化"的软件组织都需要认真思考，这在责任归属方面意味着什么。 ### 人们会赌概率\# (https://blog.ploeh.dk/2026/10/12/releasing-ai-generated-software/#082580676b864e36a2c58a7cca3e1b4d) 让我们考虑另一个领域最近的一个发展，来说明我认为将会发生的事情：2026 年 6 月，丹麦交通管理局 Færdselsstyrelsen 批准了 Tesla FSD (https://www.fstyr.dk/nyheder/2026/jun/teslas-foererassistentsystem-fsd-supervised-er-foreloebigt-godkendt-i-danmark)（全自动驾驶），前提是方向盘后面的那个人对车辆承担最终责任。驾驶员应当关注交通状况，并在危险情况出现时接管方向盘。 我认为将会发生的事情是，驾驶员会越来越被系统的有效性所麻痹。系统表现越好，驾驶员就越会走神。几周或几个月之后，驾驶员在大部分行程中都在玩手机，对交通状况几乎或完全没有关注。大多数情况下一切顺利。 然后，在极少数情况下，事故会发生。按照丹麦现行法律，如果事故涉及人员死亡，驾驶员将面临过失杀人罪的指控。这通常意味着入狱。 即使事故的"真正"原因是一个软件错误，这也不重要。在法律上，责任在别处。根本原因往往是立法滞后于技术现实。 我认为 LLM 驱动的软件工程也会发生同样的事情。人们会赌概率，因为赌注看起来太诱人了。 你在安全措施和各种质量保证技术上投入多少可能无关紧要。你可以建立最复杂的验证系统，但仍然要为任何错误负责。你对发布 LLM 生成的软件有什么看法？你愿意为 AI 坐牢吗 (https://blog.ploeh.dk/2026/03/23/will-you-go-to-prison-for-an-ai)？ ### 结论\# (https://blog.ploeh.dk/2026/10/12/releasing-ai-generated-software/#67481017c646464e8caa662faf0d5d72) 软件工程可能不是我们以为的那样。或者更准确地说，它可能不限于围绕人类程序员和测试人员的某一套特定方法论。 可以设想，未来会出现全自动化的软件工程流程，其安全性至少与我们目前所知的流程相当。即便如此，人类关于责任和归属的观念可能跟不上步伐。 当事情出错时，组织会将错误归结为无人之过吗？法院会将严重缺陷视为本质上是另一场意外事故吗？还是说总得有人来背锅？如果没有人写过任何代码，那会是谁？