当 AI 找出了更多 bug，产品反而更难发布了？

最近读到 Robert Haas 的一篇文章，标题很直接：《Postgres 19 is late, and it's AI's fault》。

只看标题，我以为又是 AI 写代码惹出了麻烦。读完才发现，事情朝另一个方向发展了：AI 找出了太多 bug，维护者忙不过来了。

按照 Haas 的解释，LLM 大幅提高了发现缺陷的效率，但修复、审查和验证仍然需要人。维护者投入更多时间处理旧版本的问题，新版本的审查受到影响，一些功能直到测试后期才被撤回，PostgreSQL 19 的发布时间也因此推迟。

他在文章里比较了连续两年同一时间段的提交量：

数据来自 Haas 的文章，增幅按原始数字计算。主分支提交也包含回补到稳定分支的修改，这几行不能相加；提交数量也不等于缺陷数量，更不能把全部增长都归因于 AI。

尽管如此，稳定分支上的工作量变化还是很明显。准备新版本的同时，维护者需要处理更多旧版本问题。

这让我冒出了一个疑问：

如果其中一些缺陷并不影响大多数人的使用，我们会不会因为终于发现了它们，反而失去了发布产品的能力？

一个产品昨天还在正常运行，今天 AI 指出了某个极端条件下的问题，它就突然不适合发布了吗？

被发现的问题，会立刻变成工作

我先想到的是一个假设。

某段代码已经运行了十年，只有在罕见配置和特定调用顺序下才会出错。过去没有人报告过，现在 AI 把它找了出来。

代码没有在今天突然变坏，但维护团队的工作确实增加了：确认能否复现，判断影响范围，寻找修复方案，审核补丁，再检查有没有引入新的回归。

即使最后确认它只是一个低优先级问题，前面的判断也已经消耗了时间。

过去，发现问题本身需要投入不少精力。报告数量受到发现成本的限制。现在，一次自动扫描就可能产生一批看起来值得检查的问题，验证这些问题的人却没有同步增加。

我开始觉得，发布可能在这里受到伤害：团队还没有来得及判断哪些问题应该阻止发布，处理报告的工作就已经挤占了发布准备。

如果再把“有已知缺陷”直接当作“不能发布”，情况会更糟。修完一批，扫描又找到一批；修复后的代码还可以继续扫描。版本质量不断提高，发布的终点却不断往后移动。

而延期并不免费。已经完成的功能和修复无法交到用户手里，用户继续使用旧版本，维护者也需要更长时间维持多个分支。

我去看了其他项目，它们的选择很不一样

带着这个疑问继续查，我发现 PostgreSQL 面临的压力已经出现在多个项目中，但各自的处理方式并不相同。

表中数据分别来自 Haas 的文章、curl 公告、Canonical 说明及 Mozilla 的修复报告和发布流程说明。这些指标口径不同，只能观察各项目承受的压力和应对方式，不能直接比较产品质量。

curl 的应对尤其值得注意。

今年 10 月，Daniel Stenberg 写道，持续涌入的漏洞报告已经让核心维护者接近承受极限。项目随后调整规则：低、中严重程度的问题转到公开 GitHub，只有高危和严重问题继续通过私密渠道处理。公开之后，更多人可以参与判断、修复和验证。

我从这个调整里读到的是：不同风险的问题，需要承担不同的流程成本。让每一份报告都经过少数人的私密处理，未必能够持续。

Ubuntu 则选择改变交付节奏。

Canonical 在 9 月的说明中，把 AI 推动的漏洞发现增长，以及 Linux 内核 CVE 编号方式的变化，都列为维护压力的来源。它宣布采用相互交错的两周内核更新周期，实现每周交付，同时保留认证测试。

这与“问题多了，所以再等等”形成了很有意思的对照。问题持续出现时，缩短每批修复的等待时间，也是一种选择。

Firefox 的经历又让我对自己的最初判断谨慎了一些。

Mozilla 披露，Firefox 150 修复了 271 个由 Claude Mythos Preview 发现的缺陷。其中，180 个被评为高风险，80 个为中风险，11 个为低风险。4 月交付的 423 个安全缺陷修复，还包括其他模型、外部报告和传统测试等途径发现的问题，不能全部算作该模型的成果。Mozilla 的技术说明

它还公开了一部分案例，包括复杂的内存安全问题和潜在的沙箱逃逸路径。

这些材料提醒我，不能把维护压力全部归因于误报或者流程僵化。AI 确实可能找到了大量值得修复的问题。报告越准确，团队面临的挑战反而越实在：这些工作很难直接丢弃。

“以前不影响使用”，也需要重新判断

最开始，我的想法是：一个缺陷长期没有造成明显影响，新发现它，应该不会立即改变产品的实际风险。

后来读到 Mozilla 关于补丁发布的另一篇文章，我意识到这个想法漏掉了攻击者。

AI 帮助维护者发现缺陷，也可能帮助攻击者发现和利用缺陷。Mozilla 在 10 月指出，攻击者可以从公开修复中反推旧版本的问题，AI 正在降低这项工作的门槛。为此，Firefox 已经提高更新交付频率，并调整部分测试的公开时间。Mozilla 关于补丁窗口的说明

所以，“普通用户很难碰到”并不足以证明一个安全问题可以放心搁置。用户不会主动构造那些条件，攻击者会。

这也让我修正了最初的看法：有些延期确实可能来自过度流程，但另一些延期是在应对已经变化的风险。只看缺陷存在了多少年，很难区分两者。

我更担心的是，团队没有时间判断

看完这些案例，我仍然认为，AI 找出更多缺陷可能损害产品交付。但现在，我更关心的是维护团队有没有足够的时间和能力，决定什么应该修、什么时候修，以及什么必须阻止发布。

发布总要接受一定的剩余风险。过去，我们接受的很多风险藏在未知里；现在，其中一部分被写成了具体报告，有了复现步骤、负责人和待办事项。

接受一个明确写在列表里的问题，比接受一个尚未被发现的问题，需要更多解释。团队也容易因此倾向于继续等待。

但一个产品是否值得发布，最终仍然要回答具体的问题：这次发布给用户增加了多少风险，又减少了多少风险？现在修复的回归风险有多大？继续延期，用户会失去哪些已经完成的改进？

我不觉得缺陷数量能够替代这些判断。

对低风险问题，团队需要能够明确记录、安排后续版本；对高风险问题，需要有权阻止发布；对已经完成的修复，则要尽量减少无谓的等待。AI 发现能力提高之后，这些决定会比以前更频繁，也更难做。

读 Haas 的文章时，我最初在想：AI 找到了这么多 bug，为什么反而成了坏消息？

现在我觉得，好消息能不能真正落到用户身上，还取决于发现之后的整段工作。有人得判断，有人得修复，有人得验证，最后还得有人决定：这个版本已经可以交付了。

我希望 AI 让我们更了解软件的缺陷之后，也能让我们更有把握地发布它。