发布于 2026 年 8 月 16 日，作者 Nolan Lawson，分类于软件工程。标签：AI。

AI 编程有一个古怪的方面，我一直试图弄清楚，我想就是这个：现在你基本上可以直接决定你想让你的软件有多少个 bug。

我们最初是在安全领域发现这一点的，因为安全漏洞当然是最不容妥协的。但我认为一旦漏洞末日过去，我们会开始把注意力转向其他类型的 bug：正确性、性能、可访问性、可靠性等等。

我们中的一些人已经在这么做了。例如，我发现自己这些天花了大量时间在代码审查上，使用诸如我的 triple-agent code review skill 以及 Geoffrey Litt 的 explain-diff skill 之类的工具。

我的经验是，在一个复杂系统中，你基本上可以向智能体要求多少 bug，就能找到多少 bug。如果你厌倦了在 PR 本身中处理 bug，别担心：智能体还会为你找到大量预先存在的 bug 供你花时间处理。问题只是你想在什么时候停下来，称之为“完成”。

当然，修复 bug 并非没有代价。仍然有许多权衡需要考虑：代码行数与 bug 实际发生的可能性、在复杂解决方案中引入新 bug 的风险、使代码对未来审查者或智能体更难理解的代价，等等。但发现 bug 已经变得几乎免费，而且 AI 智能体也能够发现非常微妙、复杂的 bug，这些 bug 否则可能会在雷达下飞行多年。我们如何应对这种情况才是有趣的问题。

正如许多人指出的那样，自从 AI 编程成为现实以来，软件的整体打磨程度似乎并没有提高。如果说有什么变化，那就是市面上只是多了更多垃圾和铲子软件，质量可疑。我认为这表明，尽管我们发现新 bug 的能力飙升，但我们对 bug 的整体容忍度并没有改变。仍然有许多相反方向的风在吹：

• 可预防问题悖论：如果发生事故，你冲进去修复它，你就是英雄。如果你从一开始就防止问题发生，那么没人知道你做了一切。

• 相关：许多软件组织内部的压力是持续交付可见成果，而不是微调已经“能用”的东西。在 AI 编程中，这一点被放大了：管理层通常假设 10 倍生产力意味着 10 倍更多可见的功能和应用。

• 懒惰：程序员经典美德之一，这次却对我们不利。在艰难处理完第无数个 AI 生成的 bug 报告后，我发现自己精神疲惫，这要求我仔细思考系统的复杂方面，并权衡修复它的利弊。我想象业内许多同行已经对 AI 代码审查充耳不闻，或者只关注最关键的发现。

避免本轮

不过，有几种方法可以解决这个问题，而不需要无尽的辛劳。一种方法是让智能体循环运行，例如“做一次代码审查，修复所有关键/高/中等问题，然后重复。”我发现这可以奏效，但它有产生大量本轮（epicycles）的倾向。

如果你不熟悉这个概念：在前哥白尼 1 的太阳系模型中，古代天文学家通过简单地给行星运动添加更多圆圈来“修正”行星轨道的计算错误。这提高了预测的准确性，但代价是使整体模型更加复杂。显然，只说“地球绕太阳转”大大简化了整个事情，但首先你需要有洞察力才能使这种简化成为可能。

我发现 AI 智能体非常不擅长这种戏剧性的简化（换句话说，“LLM（大语言模型） 不能跳跃”）。它们会乐于为每个 bug 构建一个本轮，直到代码变成一团意大利面。因此，AI 代码审查的一个有价值的部分仍然是提出诸如“我们如何能让这更简单？”和“代码库是否存在根本缺陷，我们应该在解决这类 bug 之前修复它？”之类的问题。

另一个行之有效的技巧是拥有良好的测试。（说起来容易做起来难！）例如，当我在用 vibe coding 方式开发 W3C IndexedDB API（应用程序编程接口） 时，我很清楚地意识到，一个智能体可以直接跑完整个测试套件，如果它能接近 100% 通过，那我就可以相当确信实现是没有 bug 的。但这之所以可行，唯一的原因是 Web Platform Tests 是一个极其出色的测试套件，经过多年来自不同浏览器实现者的打磨，他们发现了各种奇怪的 bug，并为你所能想到的每一个不太可能出现的场景添加了测试用例。大多数公司在其第一方代码库中，只能梦想拥有这样的测试套件。

不过我可以想象，如果你是从零开始构建一个系统，尤其是如果你的目标是复现一个现有系统的输出，那么你可以通过把全部精力投入到测试套件中，然后让智能体在其余部分尽情发挥，从而取得相当大的进展。PGRust 似乎在这方面取得了一些成功。

第三种技巧是简化你的系统设计，使整类 bug 变得不可能出现。例如，我一直倡导多页应用（MPA）优于单页应用（SPA），原因就在于，使用 MPA 时，整类 bug 根本不存在：破坏后退按钮、丢失滚动状态、泄漏客户端内存、页面导航期间的可访问性问题等等。

当然，与复杂系统相比，更简单的系统会损失一些能力，也许一个合理的答案是刻意选择一个更复杂的系统，同时把所有 bug 都修掉。但我觉得这仍然会有一种倾向于不断打补丁（epicycles）的趋势，我更愿意阅读（或调试！）一个基于更简单原则构建的代码库，而不是一个基于复杂原则构建的代码库，即使它们整体的 bug 状况相同。

结论

说我们正处于前所未有的时代，说每个人都在摸索当机器人能够完成过去所谓“工作”的很大一部分时，软件工程究竟应该是什么样子——这已经成了老生常谈。然而，它仍然值得一说。我在这篇博客文章中写的任何内容都可能在几个月内过时，而你在 Hacker News 上读到的接下来 5 篇与 AI 相关的文章可能会提出 5 种不同的观点。这是一片嘈杂的混乱，我对自己已经找到了所有答案信心很低。

我默认的做法是关注短期：即智能体今天擅长什么，以及人类仍然可以在哪里提供价值。有些人抱着这样的假设在行动：所有关于代码质量、复杂性和可维护性的担忧，总有一天会被智能体一扫而空，它们可以轻松管理交给它们的任何巴洛克式遗留系统。这最终可能会成真，但我不会押注于此，因为我还没有看到。就目前而言，我仍然关心 DRY 和 KISS 原则之类的事情，在脑海中保持对代码的有效理论（就像 Peter Naur 那样），并试图引导智能体走向更好的代码质量。

不过，我确实觉得有趣的是，我们现在比以往任何时候都有更强的能力去解决越来越多微妙的 bug。也许这会带来一场可靠性复兴，也许它会导致整体上同样多的 bug，只是应用更多、每个应用的功能更多。我知道我个人的偏好是追求更高的软件工艺水平，但整个软件行业将如何迎接这一挑战，仍有待观察。

脚注

1. 严格来说，哥白尼的体系仍然有本轮（epicycles），只有开普勒设法摆脱了它们。我认为在某些方面，这使这个类比更有力：在软件中，重新架构有时不会立刻显现出明显的优势，只有随着时间的推移才会体现其价值。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：Nolan Lawson

原创地址：https://nolanlawson.com/2026/08/16/you-can-just-choose-how-many-bugs-you-want-now/