AI 审查员把 PostgreSQL 19 拖延期了？committer 拆完 12 个撤回，故事没那么简单

💡 一句话总结：Postgres 19 确实延期了（推到 11 月 19 日），也确实撤了 8-10 个特性（常态 1 个）------但 committer 逐一拆账后发现，12 个被撤特性只有 4 个源于 AI 审查，8 个是资深人类审查的传统战果；AI 真正的影响是把全行业的「质量水位线」抬高了一截，还顺手带来了一年 5 个变 44 个的 CVE 报告雪崩。AI 审查的瓶颈已经从「发现 bug」转移到了「处置 bug 报告」。

导语：一条 HN 爆款标题，和它没告诉你的部分

先看这条 10 月 16 日冲上 Hacker News 热榜第一的标题：

「Postgres 19 delayed after AI reviewers find more bugs than humans can fix」------AI 审查员发现的 bug 多到人类修不完，Postgres 19 因此延期。

222 分，93 条评论。做数据库的、写代码的、搞 AI 的全涌进来了：有人惊呼「AI 终于连 Postgres 都审得动了」，有人已经开始写「AI 毁掉开源软件」的小作文。

先说结论：Postgres 19 延期是真的，撤特性是真的，但「AI 修不完」这个因果链，被 PostgreSQL committer Tomas Vondra 逐条拆完之后，只剩下三分之一还站着。

而这个「剩下的三分之一」，恰恰比标题有意思得多。

想追一手的，链接在这：

📰 The Register 原报道：Postgres 19 delayed after AI reviewers find more bugs than humans can fix

✍️ 当事人博客：Peter Eisentraut：The reverts will continue until morale improves

💬 HN 讨论（93 条）：news.ycombinator.com

🔍 committer 拆账：Vondra 分析全部 12 个撤回

事情是怎么一步步走到延期的

把时间线捋清楚，你会发现这场延期像一部三幕剧：

第一幕（8 月 25 日）：资深 committer Robert Haas 在 pgsql-hackers 邮件列表发了个半玩笑的帖子，标题叫「scary patch contest」（吓人补丁大赛）------他让 Claude 按「代码冻结后修了多少 bug」给 v19 的补丁排了个吓人榜，选出 6 个。三周之内，榜单上 4 个补丁被撤出 Postgres 19。玩笑变成了预言；
第二幕（9 月） ：beta 期开始大规模撤回特性。10 月 9 日，core member Peter Eisentraut 发表博客《The reverts will continue until morale improves》（撤到士气改善为止------标题就很摆烂幽默），承认这届撤了 8 到 10 个重要特性，而正常的发布周期只撤 1 个。被撤的包括 SQL/PGQ 属性图查询这样的重量级功能；
第三幕（10 月）：RC1 于 10 月 15 日发布，GA 定档 11 月 19 日（原定 9 月底）。次日 The Register 的报道出炉，标题把「AI 审查」钉在了延期原因的位置上，然后就是 HN 爆款。

故事如果停在这里，就是一个标准的「AI 冲击传统软件工程」叙事。但 Vondra 干了一件标题党作者没干的事：把 5 月 20 日到 9 月 16 日之间的 12 个 major revert 的邮件列表线程，一个一个翻出来核对归因。

拆账结果：AI 只领走了三分之一的锅

Vondra 的核对结论相当打脸（对标题而言）：

12 个被撤特性里，只有 4 个的问题由 AI 辅助审查发现；
8 个是 Andres Freund、Noah Misch 这些资深贡献者用传统人工审查揪出来的------人类审查一直是 Postgres 质量的中坚，这次也没缺席；
再拉 git 历史跟 PG 14 以来对比：这届撤回的数量和规模，并非史无前例；
那 AI 到底多干了什么？Vondra 给出的答案出乎意料：CVE 安全通报雪崩------2026 年 44 个，上一年大概 5 个。这些通报的处理吃掉了审查者的时间，才是延期里 AI 相关的真正大头。

那「AI 审查发现的 bug 修不完」这个说法哪来的？源自 Eisentraut 博客里的「triage 数学」：现在一轮 LLM 辅助审查能产出约 40 份缺陷报告，每份报告无论多小------看报告、复现、判定、写修复或者写不修的理由------都有固定处理开销。beta 时间窗就那么大，装不下这一波「发现洪水」。

注意他还有一句更关键的话：「AI 写的代码不是原因」。被撤的代码大多写于 AI 审查能力到位之前------bug 一直都在，只是以前没人看得见。用 HN 高赞评论的话说：AI 不是制造了 bug，是给存量代码做了个「免费全身 CT」，扫出来的结节总得有人管。

官方是怎么「用 AI」的？比你想的更硬核

这场争议里容易被忽略的一个事实：Postgres 社区不是 AI 审查的受害者，而是积极使用者。

committer Noah Misch 在邮件列表公开过一份完整报告，标题直白得可爱------「Trying to break online checksums with LLMs」（用 LLM 搞垮在线校验和的尝试）：他让 Claude 和 GPT 对 online checksums 特性做破坏性审查，产出完整的问题清单。结论大多落在文档瑕疵和极端重启窗口的边角案例，没有数据损坏级的大问题------但这种「官方把 LLM 当 fuzzer 用」的姿态，本身就是社区对 AI 审查的官方背书。

Haas 的「吓人补丁大赛」更是一次原型级的实验：用 Claude 读代码冻结后的修复记录、给补丁排风险。三周后榜单 4/6 被撤的命中率说明------AI 审查不是「能不能用」的问题，是「怎么消化它的产出」的问题。

HN 评论区：一线开发者的 doom loop 实录

如果说邮件列表是官方视角，HN 的 93 条评论就是一线的实战复盘，几个高频痛点值得每个用 AI 写码的团队对号入座：

doom loop（厄运循环）：审查 agent 找到 bug → 编码 agent 用过度工程化的方式修复 → 引入新 bug → 审查 agent 又找到 → 循环到疯狂。有评论者分享的团队经历更扎心：生产缺陷激增，追查发现大部分来自「修 bug 修出来的」；
审查模型不是越聪明越好：有人实测发现太强的模型做 review 会「过拟合」，反而在编码侧用旗舰、审查侧用轻模型更稳；
AI 会给不该测的东西写测试：测试看似变多、覆盖看似变好，但不少测试在保护「不该存在的实现细节」；
最清醒的一条：「LLM 当审查者，Zero Defect 之路会更长------除非也让 LLM 当码农。」发现问题比修复问题便宜太多，这个不对称正是 triage 危机的根源。

行业数据：瓶颈已经换位置了

把 Postgres 这一个案例放大到行业，Generative Labs 的调研给了两个扎眼的数字：

调研 718 家企业：AI code review 已经无处不在，但人类的 review 时间反而上升了 49%；
Anthropic 内部数据：自家 reviewer 59% 的时间在重报旧问题。

两个数字指向同一个结论：AI 把「发现 bug」的边际成本打到接近零之后，瓶颈整体挪到了「处置」------每个 finding 都需要一个人类做决定。Postgres 社区的应对其实是一份标准答案：分优先级、敢撤回（被撤特性大概率进 PG 20）、保发布纪律。宁可将好特性推迟一个月，不给主干留一颗雷。

这事和你的关系：三份可以直接抄的作业

不管你在写数据库还是写 CRUD，这场风波的启示都很具体：

引入 AI 审查 ≠ 加个工具，而是给全部存量代码提高了标准。你的老代码也要过这道新水位线，排期时把「AI 审查的存量清欠」当正式工作量算；
先设计 triage 流程，再开审查水龙头。每个 finding 配「负责人 + 处置预算 + 处理记录」，否则 40 份报告的固定开销能吃掉一个发布窗口------Anthropic 那个 59% 重报率就是没有处置闭环的下场；
发布纪律优先于修复完备。Postgres 用撤回答「修不完怎么办」：大问题修，小问题撤或推迟，主干永远可发布。这个取舍思路对所有团队都适用。

最后说回那个标题。「AI reviewers find more bugs than humans can fix」错在把工具说成了元凶，但它歪打正着点破了一个真趋势：软件质量的瓶颈正在从「写得出来」转移到「审得过来」。Postgres 社区这次用一个月的延期和一摞邮件列表线程，给全行业做了一次公开教学------学费不贵，值不值得，看你什么时候用得上。

参考来源

注：归因数字（4/12、8-10 个撤回、CVE 44 vs ~5）均来自当事人邮件列表与博客口径，媒体转述可能有出入；「8 到 10 个」的精确边界原作者明确说取决于统计口径。