PostgreSQL 19 发不出来？AI“找茬”太快，人类修Bug的速度跟不上了

近日，PostgreSQL 19 的发布出现罕见波折。PostgreSQL 团队宣布，原计划于 10 月 29 日正式发布的 PostgreSQL 19，将推迟至 11 月 19 日。在此之前，项目还将额外增加一个 RC2 候选版本，于 11 月 12 日发布。官方给出的原因是，近期被加入各维护分支的修复数量较多，希望先通过 RC2 将这些修复交给社区验证，再进入正式发布。

与此同时，在 Beta 阶段开始后，大约有 8～10 项重要功能被从 PostgreSQL 19 中撤回，其中部分功能是在相当靠后的阶段才被移除。正常情况下，一个 PostgreSQL 大版本周期出现一项重要功能回滚并不罕见，但一次撤回接近 10 项，已经明显超出了惯例。

PostgreSQL 核心提交者、EDB 副总裁 Peter Eisentraut 随后专门撰文解释了这次异常，其中一个关键变量，正是迅速成熟起来的大模型辅助代码审查和模糊测试。

AI 把以前 5 年才能发现的问题提前翻了出来 

Peter Eisentraut 否定了一个很容易出现的猜测：这些问题大体上并不是 vibe coding 造成的。

他解释道，大多数受到影响并最终被撤回的功能，早在 LLM 辅助编程和代码审查成熟之前就已经完成。也就是说，并不是开发者让 Claude、Codex 等模型大量生成了质量不佳的 PostgreSQL 代码，然后在 Beta 阶段集中爆雷；相反，是后来越来越强的 AI 审查工具，开始重新检查此前按照传统流程开发出来的代码。

Peter 将被发现的问题大致分为两类。第一类确实比较严重，一些被撤回功能存在架构层面的缺陷，在 Beta 阶段短时间内很难彻底修正。但除此之外，还出现了一系列长尾问题：大量单独看并不严重、只会在特定边缘条件下触发的问题。

过去，这类问题可能不会在发布前被发现。PostgreSQL 会先正常发布，然后在未来几年里随着真实用户撞上各种罕见组合，再一点点补丁修复。Peter 估计，其中不少问题原本可能要在接下来的 5 年内逐渐浮现。

LLM 改变了这个过程。借助 AI 辅助代码审查，过去分散在数年时间里的边缘缺陷，现在可能在几天或几周内被集中扫出来。

Peter 举例道，开发者突然面对大约 40 份缺陷报告，即便每个问题平均只需要改 3 行代码，但处理每一个问题仍然需要固定成本，于是代码本身可能只改几分钟，但几十个问题叠加起来，人类的时间很快就被耗尽。

这也导致了一个非常反直觉的结果：AI 提高了软件质量，却可能在短期内降低软件发布速度。

Peter 将这种现象概括为“有效质量门槛被抬高了”。这些功能当初被开发和提交时，行业还没有如今这样的 LLM 审查能力；等到 PostgreSQL 19 准备发布时，新的工具已经可以发现过去难以发现的问题。原本可能符合发布标准的代码，在新的审查能力下突然“不够好了”。

AI 辅助模糊测试或可直接进入功能开发 

数据库尤其容易遭遇这种问题。

PostgreSQL 的一个重要特点是，开发者往往期待不同功能能够自由组合。一个 SQL 功能不仅需要在最普通的情况下运行，还可能被放进 domain、复合类型、分区表、视图、安全定义函数、触发器等各种环境里，并且这些能力还能继续互相嵌套。

Peter 举例称，一个 SQL 层面的新功能可能需要面对这样的组合：domain 套在复合类型上，复合类型里的字段本身又是 domain；domain 带有非空约束；列曾被删除又重新添加；表分区被 detach 后又按照不同列顺序 attach；最终这一切又出现在一个视图里，而这个视图从触发器中的 security-definer 函数被调用。

理论上，开发者希望这些东西全部正常工作，问题在于人类甚至很难枚举出所有组合，更不用说逐个手工测试。

LLM 辅助模糊测试恰好非常擅长这一类工作。模型可以不断生成边缘组合、构造测试输入、观察异常，再继续沿着异常路径扩展。Peter 因此判断，这类 AI 辅助模糊测试未来很可能需要直接进入 PostgreSQL 的功能开发流程，而不能等到 Beta 后期才集中使用。

实际开发过程已经出现类似迹象。今年 8 月，PostgreSQL 社区成员 Robert Haas 曾让 Claude 根据 feature freeze 之后修复的 Bug 数量和类型，对 PostgreSQL 19 的补丁进行风险评估。其中 SQL 属性图查询被列为高风险功能之一，当时已经经历 17 次修复。

核心开发者 Tom Lane 随后表示，如果 SQL/PGQ 按当时状态进入 PostgreSQL 19，他甚至愿意“赌一顿晚饭”，认为发布后还会发现只能等到 PostgreSQL 20 才能彻底解决的问题。最终，SQL/PGQ 确实从 PostgreSQL 19 被撤回。

另一名 PostgreSQL 社区成员随后也提到，对该功能启动 AI 审查之后，又发现了一些严重问题，并进行了人工确认。这意味着在这次发布周期中，AI 并不仅仅充当“聊天式代码评论员”，而是已经开始参与真实开源项目的风险筛查。

不过，Peter 也强调，AI 并不是这次大规模撤回的唯一原因。部分代码自身质量和架构设计确实存在问题，今年 PostgreSQL 社区还经历了一轮密集安全问题处理，大量资深开发者从 4 月到 8 月都在忙于修复安全问题，导致 Beta 前期原本应该进行的额外评审和测试受到影响。等这些开发者重新投入 PostgreSQL 19 时，许多问题已经到了发布周期后段才暴露出来。此外，PostgreSQL 自身持续增长的复杂性也是根本问题之一。

大量问题最终迫使 PostgreSQL 社区做出了相当保守的决定。

Peter 称，根据统计方式不同，大约有 8～10 项重要功能已经从 PostgreSQL 19 分支撤回，其中不少预计将在修正后重新进入 PostgreSQL 20。其中一个代表性功能就是 SQL/PGQ，它用于按照 SQL 标准查询由节点和边组成的属性图数据，但由于仍存在未解决的问题，最终未能进入 PostgreSQL 19。

值得注意的是，PostgreSQL 社区此前甚至一度认为 PostgreSQL 20 可能主要用于修 Bug，不会有太多新功能；现在情况反了过来：PostgreSQL 19 撤下的一批功能，反而已经为 PostgreSQL 20 留下了一批接近完成的候选功能。

PostgreSQL 19 本身也并非因此变成一个“小版本”。Peter 提到，其中仍将包括 REPACK CONCURRENTLY、序列的逻辑复制，以及通过 pg_plan_advice 实现的查询规划器提示等重要能力。在经历这轮额外审查之后，他反而预计 PostgreSQL 19 会成为一个更加稳健的版本。

RC1 已按计划于 10 月 15 日推进，但正式版从原定 10 月 29 日推迟至 11 月 19 日。发布团队还新增了 11 月 12 日的 RC2，希望让近期积累的大量修复再经历一轮验证。官方将今年称为一个“不寻常的大版本发布周期”，并强调最终目标仍然是保证 PostgreSQL 的稳定性和可靠性。

AI 无限发现问题，那人类该修到什么程度？ 

这件事随后在开发者社区迅速发酵，不少开发者认为，软件开发新的瓶颈可能正在从“发现 Bug”转移到“给 Bug 分类”。

“这种情况不会很快消失，下一步真正需要解决的是如何对 AI 找出来的问题进行分类，只把最严重的问题优先送到人工审查。”另一些开发者也指出，当找漏洞和构造异常输入的成本突然下降之后，“发现问题”和“修复问题”的速度已经不再匹配。以前安全研究者找到一个复杂缺陷可能需要几天甚至几周，而 AI 可以同时探索大量路径，人类维护者却仍然只能一个一个确认。

但另一派开发者担心的是，AI 会造成“真假 Bug 泛滥”。

有开发者表示，自己的经验是 AI 会报告大量从局部代码看似合理、放到整个系统语境中却并不成立的问题。如果开发团队机械修复每一个 AI 建议，最终可能得到一个过度设计、效率更差的系统。真正费时间的地方是人类必须逐项判断究竟是真 Bug、极端但可以接受的边缘情况，还是纯粹的误报。

一名从事数据工程的开发者称，在其内部 AI 代码审查系统中，即便模型能够访问代码仓库、Confluence 和 JIRA 等上下文，大约也只有八分之一的报告最终被认为有效；对于更通用的审查机器人，这一比例甚至可能进一步下降。另一名熟悉静态分析工具的开发者则表示，大量误报一直都是自动化分析的老问题，一旦积累到十万级缺陷报告，要求人工做到 100% 确认几乎不现实。

不过，有用户也以自身经历为例证明了，即便对误报不满仍然不愿意放弃 AI 审查，因为它确实能够把隐藏多年的技术债翻出来。他们曾让 AI 对一个已经稳定运行约 10 年的客户系统中的脚本、任务和配置进行集中代码审查，最终发现 39 个问题，其中 30 个被确认是真实 Bug，只不过此前从未被触发。

类似事情并不仅仅发生在 PostgreSQL 这样的开源项目中。一些闭源软件里，开发多年的功能同样开始因为 LLM 新发现的问题而无法按原计划发布。过去的做法可能是先上线，再在未来版本逐步补丁；但一旦开发团队已经明确知道某个 Bug 或理论漏洞存在，继续把它带进正式版本，在安全和责任层面都会变得越来越难解释。

有开发者指出，数据库这类复杂基础软件中的很多问题，并不是把 Bug 报告重新扔给 LLM，然后点击“自动修复”就能解决。一些缺陷实际上对应的是架构和产品语义上的取舍：某一种行为在使用场景 A 下可能是 Bug，在场景 B 下可能是合理设计，换到场景 C 又可能意味着一年前的基础设计本身需要重做。AI 可以非常便宜地把这种矛盾找出来，但决定“正确行为究竟是什么”依然需要经验丰富的维护者。

甚至已经有人担忧出现另一种极端：“发布瘫痪”。如果 AI 可以不断从任何复杂代码库里继续挖出新的边缘问题，那么理论上永远存在下一个 Bug。项目究竟应该修到什么程度才允许发布，未来可能成为比“AI 能找到多少 Bug”更困难的问题。有开发者建议，与其追求在单个版本里消灭所有 AI 找出的缺陷，不如把它们系统化登记、分级，纳入后续开发路线，否则没有任何大型软件能够达到真正意义上的“零缺陷”。

结束语 

Claude Code、Codex 等工具的编码能力越来越强后，AI 写代码已经不是问题，而 PostgreSQL 19 事件展现出了，当 AI 同样能够大规模审查、测试和攻击代码之后，“发现问题”也不再是问题。

接下来真正稀缺的，可能变成人类的判断力：哪些问题必须修，哪些问题可以接受；一个三行代码能够修复的边缘缺陷，是否值得为它推迟一个重要功能；AI 给出的几十个问题里，哪几个意味着架构本身需要重新设计；以及当机器可以无休止地寻找异常时，一款软件究竟要达到什么程度，才算“足够好，可以发布”。

本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：褚杏娟，36氪经授权发布。