21CTO导读：人类辛辛苦苦写了大半年、准备发版的 PostgreSQL 19，被进化后的 AI 代码审查员直接干延期了。

AI在软件开发中生成的代码有时被称为“AI Slop”，即AI泔水，有一些项目如BSD、Zig语言等严格明确不允许使用AI生成的代码。但是AI在代码质量管理与测试流程中正在发挥积极作用。

比如有Linux内核、cURL等开源项目，被AI的Bug报告弄得焦头烂额，在最近的发布周期，因为修改代码量和尺寸加大，多个开源项目出现了延期。

而近日，知名的PostgreSQL数据库，也因为AI捕获错误的速度太快，团队不堪重负，对外宣布最新版本的PostgreSQL 19将延迟发布。

从正常发布到紧急回滚

在过去的十多年里，PostgreSQL 主要版本的发布时间就像瑞士手表一样非常有规律：每年都会在9月或10月份发布一个大的更新版本。

而2026年的计划是在9月份就推出PostgreSQL 19，最晚不晚于 10 月中旬。但目前看情况发生了变化。PostgreSQL 19 很可能要到 11 月才会发布，而且项目组也不排除会进一步推迟发布。

另外，2026年的测试阶段后期，一些相当重要的功能均被撤销：UPDATE/DELETE FOR PARTION OF、SQL属性图查询 (SQL/PGQ) 以及ALTER TABLE … MERGE PARTITION/SPLIT PARTITION 等功能均在 8 月 27 日至 9 月 15 日期间被撤销或回滚。

核心开发者的解释

核心开发人员 Robert Haas 在一篇博文中指出，PostgreSQL 19 的开发进度落后于计划，而 AI 正是罪魁祸首。开发人员不仅要应对来自 AI/LLM 代理的大量 bug 报告，还要处理安全漏洞和 bug 向后移植到早期 PostgreSQL 版本的问题。Haas评论说：

“我认为这也是我们后期回滚如此之多，以及最终版本发布延迟的原因。这里有两个因素在起作用。

首先，由于现在发现的 bug 数量更多，修复它们需要更多时间。LLM（生命周期管理）可以起草修复方案，但这些方案并不总是正确或符合 PostgreSQL 标准。因此，它们仍然需要人工审核和提交，而这些人工审核人员在 2025 年到 2026 年之间并没有变得更聪明。

其次，原本用于审核发布版本的时间被转移到了解决安全问题和回退分支中的其他 bug，因此在发布 v19 之前，确定哪些内容需要回滚需要花费更多时间。”

AI模型揭穿开源更多死角

核心提交者在工程长文中披露了物理真相。并非模型编写的新代码带来了污染，而是大模型让全行业寻找深层隐患的门槛降到了极低水平。

全球研究人员开始把海量分析任务分配给推理模型。那些在四十年前手写写入、历经数千位人类专家肉眼审查都未曾暴露的边缘暗病，在大模型的全量扫描下很快现形。

深层事务隔离下的序列化异常、复杂外键完整性约束的极端死锁，以及查询优化器对特定表达式的估算偏差，被大批量具象化提取出来。

根据维护者披露的统计数据，被挖出的缺陷中有九成以上深埋在两年前甚至数十年前的历史底层资产中。大模型像无休止的探针，将老系统赖以运行的健壮假象击得粉碎。

这场危机暴露了传统软件工程在智能时代的物理瓶颈。

找到潜在漏洞的边际成本正在趋近于零，但验证漏洞、编写回归测试与评估补丁兼容性的成本依然牢牢守恒。当成百上千份报告同时涌向仅有十余位核心专家的审查团队时，人类有限的大脑带宽迅速遭遇了不可逆的过载熔断。

面向海量缺陷的三层自动化验证流水线图

基础软件的开发范式需要在验证环节完成彻底重构。

生产级流水线应当在问题入口处建立前置的自动化沙盒重现机制。对于未经可复现测试断言的模糊提报，系统必须即刻触发提前终止，坚决不让低价值的噪音报告挤占有限的人工审查带宽。

审查任务应当解耦为独立的自动化测试探针。将复杂的边缘异常交由无状态的微执行流水线独立处理，能够有效打破把所有验证包袱堆叠在单一维护者身上的脆弱结构。

结语

PostgreSQL 19 的发布延期，不是 AI 的“胜利”或“失败”的，而是软件工程进入新阶段的一个清晰信号。

当机器找 Bug 的能力远超人类修 Bug 的速度时，开发者们该如何重新设计开发流程、审查机制和发布节奏？

这或许比任何单一功能的得失都更值得技术社区认真思考。

作者：聆听世界的鱼