你现在可以任意选择想要的bug数量了

# 现在你可以随意选择想要多少个Bug 来源：https://nolanlawson.com/2026/08/16/you-can-just-choose-how-many-bugs-you-want-now/ 我一直在琢磨AI编码中一个奇怪的现象，我想大概是这个：现在你基本上可以随意决定自己的软件要有多少Bug了。 我们最初是在安全领域发现这一点的，因为安全Bug当然是最没有商量余地的。但我认为，当“漏洞末日”（https://en.wiktionary.org/wiki/vulnpocalypse）过去之后，我们就会开始关注其他类型的Bug：正确性、性能、可访问性、可靠性等等。 我们中的一些人已经在这样做了。例如，我发现自己最近花了大量时间在代码审查上，使用了诸如我的“三重代理代码审查技能”（https://gist.github.com/nolanlawson/4150b0ca9640654c256b324fac0d5253）以及Geoffrey Litt的“解释差异技能”（https://www.geoffreylitt.com/2026/07/02/understanding-is-the-new-bottleneck）等工具。 我的经验是，在一个复杂系统中，你基本上能发现多少Bug，取决于你要求代理程序去查找多少。如果你厌倦了处理PR（拉取请求）本身的Bug，别担心：代理程序还会找出大量已存在的、值得你花时间去处理的Bug。问题只在于你何时想停下来，并称之为“完成”。 当然，修复这些Bug并非没有代价。仍然有许多权衡需要考虑：代码行数与Bug实际发生可能性之间的权衡，在复杂解决方案中引入新Bug的风险，以及让代码更难被未来的审查者或代理程序理解的代价等等。但*发现*Bug的成本已经接近零，而AI代理程序也能发现非常隐蔽、复杂的Bug，否则这些Bug可能潜伏多年。如何处理这种情况，才是有趣的问题。 正如许多人指出的，自从AI编码出现以来，软件的总体精致度似乎并未提高。如果说有什么变化的话，那就是质量存疑的垃圾软件和仓促完成的产品更多了。我认为这表明，尽管我们发现新Bug的能力飙升，但我们对Bug的总体容忍度并未改变。仍然有许多因素在起反作用： - “可避免问题悖论”（https://medium.com/@shreyashere/why-our-leaders-fail-us-and-then-save-us-the-preventable-problem-paradox-872614ec3293）：如果一个事故发生，你出手修复，你就是英雄。如果你从一开始就防止了问题的发生，那么没人知道你做了什么。 - 相关的一点是：许多软件组织的内部压力在于不断交付可见的成果，而不是去微调某个已经“能用”的东西。在AI编码下，这一点被放大了：管理层通常假设10倍的生产力意味着10倍多的可见功能和应用程序。 - 懒惰：这是程序员的经典美德（https://threevirtues.dev/）之一，这次却对我们不利。在处理了无数份AI生成的Bug报告后，我发现自己在精神上感到疲惫，这需要我仔细思考系统的复杂方面，并权衡修复它的利弊。我想象业界的许多同行已经对AI代码审查充耳不闻，或者只关注最关键的发现。 ## 避免本轮修饰（本轮解释） 不过，有几种方法可以让我们在无需无尽劳作的情况下解决这个问题。一种方法是让代理程序循环工作，例如“进行一次代码审查，修复所有关键/高/中等级的问题，然后重复。”我发现这有时有效，但它往往会产生许多“本轮修饰”（https://en.wikipedia.org/wiki/Deferent_and_epicycle）。 如果你不熟悉这个概念：在前哥白尼¹（https://nolanlawson.com/2026/08/16/you-can-just-choose-how-many-bugs-you-want-now/#footnote-1）的太阳系模型中，古代天文学家通过为行星运动添加更多圆圈来“修正”轨道计算中的错误。这提高了预测的准确性，但代价是使整个模型更加复杂。显然，说“地球围绕太阳转”极大地简化了整个体系，但首先你需要有洞察力才能实现这种简化。 我发现AI代理程序不太擅长这种戏剧性的简化（换句话说，“LLM无法实现跳跃”（https://openreview.net/forum?id=klU4737opt））。它们会乐此不疲地为每个Bug添加一个本轮修饰，直到代码变成一团乱麻。因此，AI代码审查中仍然有价值的部分，是去问诸如“我们怎样才能让它更简单？”以及“在我们处理这类Bug之前，代码库是否存在根本性缺陷需要修复？”这样的问题。 另一种有效的技术是拥有良好的测试。（说起来容易做起来难！）例如，当我尝试用“氛围编程”（vibe coding）的方式实现W3C IndexedDB API（https://nolanlawson.com/2026/01/31/building-a-browser-api-in-one-shot/）时，我清楚地意识到，代理程序可以通过不断运行测试套件来推进，如果它接近100%的通过率，我就可以合理地确信实现是无Bug的。但这之所以有效，唯一的原因是Web平台测试（https://github.com/web-platform-tests/wpt）是一个极其出色的测试套件，经过独立浏览器实现者多年发现古怪Bug并为每个你能想到的不可能场景添加测试用例而打磨而成。大多数公司的私有代码库，只能梦想拥有这样的测试套件。 不过我可以想象，如果你是从头构建一个系统，尤其是当你的目标是复制一个现有系统的输出时，那么你可以通过将所有精力投入到测试套件中，然后让代理程序在其余部分放手去做，从而取得很大进展。PGRust似乎在这方面取得了一些成功（https://malisper.me/postgres-in-rust-regression-suite/）。 第三种技术是简化你的系统设计，使得整个类别的Bug变得不可能发生。例如，我一直是多页应用（MPA）优于单页应用（SPA）的倡导者（https://nolanlawson.com/2022/05/21/the-balance-has-shifted-away-from-spas/），仅仅因为MPA使得整类Bug根本不存在：破坏后退按钮、丢失滚动状态、泄漏客户端内存、页面导航期间的可访问性不当等。 当然，与复杂系统相比，你失去了一些能力，一个合理的答案可能是故意选择更复杂的系统，同时修复所有Bug。但我仍然觉得这会倾向于产生本轮修饰，我宁愿阅读（或调试！）基于更简单原则构建的代码库，而不是基于复杂原则构建的，即使它们总体上的Bug情况相同。 ## 结论 指出我们正处于前所未有的时代，每个人都在摸索当机器人能够承担曾经“工作”中很大一部分时，软件工程究竟应该是什么样子，这已经成了陈词滥调。然而，它仍然值得说。我在这篇博客文章中写的任何内容，可能几个月内就会过时，而你在Hacker News上读到的下5篇AI相关文章，可能会提出5种不同的观点。这是一个喧嚣混乱的局面，我对自己已经找到了所有答案并没有太大把握。 我目前采取的立场是专注于短期：即代理程序今天擅长什么，人类在哪里还能提供价值。有些人基于这样的假设行事：所有关于代码质量、复杂性和可维护性的担忧，终有一天会被能够轻松处理任何交给它们的繁琐遗留系统的代理程序所扫除。这最终可能是对的，但我不会押注于此，因为我还没有看到。目前，我仍然关心诸如DRY（不要重复自己）（https://en.wikipedia.org/wiki/Don%27t_repeat_yourself）和KISS（保持简单）（https://en.wikipedia.org/wiki/KISS_principle）原则之类的事情，在脑海中保持对代码的理解理论（就像Peter Naur（https://pages.cs.wisc.edu/~remzi/Naur.pdf）那样），并试图引导代理程序提升代码质量。 不过，我认为有趣的是，我们现在比以往任何时候都有更强的能力去处理越来越多的微妙Bug。也许这会引领一个可靠性复兴，或者也许会导致整体相同的Bug水平，只是应用程序更多、每个应用程序的功能更多了。我知道我个人更偏好更高的软件工艺水平，但整个软件行业将如何应对这一挑战，仍有待观察。 ## 脚注 1.（https://nolanlawson.com/2026/08/16/you-can-just-choose-how-many-bugs-you-want-now/#footnote-1）严格来说，哥白尼的系统（https://en.wikipedia.org/wiki/Deferent_and_epicycle#As_an_example_of_bad_science）仍然有本轮修饰，只有开普勒成功地摆脱了它们。我认为在某些方面，这个类比更强了：在软件中，重新架构有时并不会立竿见影地显示出优势，其价值会随着时间的推移才显现出来。