AI审查员揪出大量Bug，Postgres 19被迫延期

AI 审查工具把 Bug 挖了个底朝天

数据库圈最近出了一件颇为讽刺的事：Postgres 19 的发布被推迟了，原因不是没人测试，而是 AI 代码审查工具找出来的 bug 太多，人类开发者修不过来。

这条消息在 Hacker News 上引发了讨论。核心矛盾非常直接——AI 审查的吞吐量远超人类修复的速度，导致 bug 队列越积越长，最终只能选择延期发布。

这听起来像是个"幸福的烦恼"，但它暴露的问题远比表面复杂。

为什么 AI 能找出人类漏掉的 Bug

传统开源项目的代码审查依赖志愿者和核心维护者的时间。Postgres 作为最活跃的开源数据库之一，代码库庞大、逻辑分支极多，人类审查者的注意力天然有限。

AI 审查工具的优势在于：

• 不知疲倦：可以对每一行改动进行全量扫描，不会因为 review 疲劳而跳过细节
• 模式匹配能力强：能从历史 bug 模式中学习，识别出相似的潜在问题
• 覆盖率高：人类审查者往往聚焦于核心逻辑，AI 则能兼顾边界条件和冷门代码路径

问题在于，AI 找出来的 bug 并不全是"真 bug"——其中夹杂着误报和低优先级问题。但即便如此，有效发现的绝对数量仍然超出了人类团队的修复能力。

Postgres 的代码规模与审查文化：Postgres 已有超过 30 年历史，核心代码库包含数百万行 C 代码，且遵循极为严格的提交规范——每个补丁都必须经过社区邮件列表的公开讨论和至少一位 committer 的批准。这种人工审查流程保证了极高的代码质量，但也意味着审查带宽长期处于瓶颈状态。Postgres 的提交者（committer）全球仅数十人，他们大多有全职工作，靠业余时间处理补丁。当 AI 工具将潜在问题的发现量放大数倍后，这条原本就狭窄的审查通道迅速被淹没，这正是延期决策的直接背景。

AI 代码审查的技术原理：当前主流的 AI 代码审查工具（如基于大语言模型的 CodeRabbit、Cursor Bugbot 等）通常采用两种技术路线：一是训练模型识别历史 CVE 和 bug 修复提交中的代码模式，二是用静态分析辅助 LLM 进行语义推理。它们的强项是发现资源泄漏、空指针解引用、并发竞态、边界条件错误等常见缺陷模式。但由于训练数据中的噪声和代码上下文的复杂性，误报率往往在 30%–70% 之间。这意味着 AI 报出的每三条问题中可能只有一条是真实缺陷，人类开发者仍需逐条筛查，这是修复瓶颈难以绕开的根源之一。

修复瓶颈才是真正的瓶颈

这件事的关键洞察不是"AI 很厉害"，而是发现问题和修复问题之间存在巨大的速度差。

AI 可以在几分钟内扫描完一个大型 PR 并生成几十条审查意见，但每一条意见都需要人类开发者去：

1. 判断是否真的是 bug
2. 理解 bug 的上下文和影响范围
3. 编写修复代码
4. 确保修复不引入新问题
5. 走完审查和合并流程

这个流程的时间成本是刚性的。AI 把漏斗的入口撑大了十倍，但出口没变——结果就是积压。

对于 Postgres 这种对稳定性要求极高的基础设施项目，维护者不会为了赶进度而合并未充分验证的修复。延期发布是负责任的选择。

对开源协作模式的冲击

Postgres 的遭遇可能是一个信号：当 AI 审查成为标配后，开源项目的运作方式需要调整。

几个值得关注的方向：

分级处理机制。不是所有 AI 发现的问题都需要同等对待。高严重度的安全漏洞和崩溃风险优先修复，代码风格和边缘场景可以排队。

AI 辅助修复。如果 AI 能发现问题，是否也能生成修复补丁？目前 AI 生成的修复代码仍然需要严格审查，但至少可以分担一部分机械性工作。

审查质量的校准。AI 审查工具的误报率直接决定了人类的工作负担。降低误报、提高精确度，比单纯提高召回率更有实际价值。

维护者角色的转变。当 AI 承担了初筛工作，人类维护者的核心价值会更多地体现在架构决策、优先级判断和社区协调上，而非逐行审查。

这不是 Postgres 独有的问题

任何中大型开源项目引入 AI 审查后，大概率都会遇到类似情况。Linux 内核、Chromium、各种语言的核心库——代码量越大、审查越严格的项目，越容易触发这个瓶颈。

短期来看，这意味着发布节奏可能放缓。长期来看，整个工具链需要进化：从"AI 发现 → 人类修复"的单向流程，走向"AI 发现 → AI 初步修复 → 人类审核"的协作模式。

Postgres 19 的延期不是一个失败故事。它说明 AI 审查确实在发挥作用——只是配套的修复能力还没跟上。这个缺口，本身就是下一个值得解决的问题。

背景补充

基于严重度的分流实践：业界已有一些项目尝试用 CVSS（通用漏洞评分系统）或自定义的 P0–P3 分级标准来对 AI 报出的问题做自动分类。高严重度（如远程代码执行、数据损坏）的问题进入快速通道，低严重度（如变量命名、注释缺失）的则合并为批量任务或直接忽略。这种分流的核心挑战在于：AI 对严重度的判断本身也不够准确，往往倾向于高估，因此仍需要人工校准阈值。

自动化分流的技术手段：一个可行的做法是将 AI 审查的输出接入 CI 流水线，并配置规则引擎：只有当问题触发了特定的代码模式（如内存分配后无释放、锁未释放路径）时才阻断合并；其余问题以注释形式记录但不阻塞流程。这样可以在不牺牲安全性的前提下，将发现量与修复量解耦，避免因低优先级问题堆积而拖慢发布节奏。