PostgreSQL 19 为何难产：AI 挑错的速度超过了人类修错的速度

PostgreSQL 19 发不出来？AI“找茬”太快，人类修Bug的速度跟不上了 — infoq.cn · 5 小时前 · ⚙️ 工程

PostgreSQL 19 版本的发布进程遇到了一个前所未有的瓶颈：社区引入的 AI 工具能够以前所未有的效率扫描代码、发现潜在缺陷和边界问题，导致待修复的 Bug 积压量急剧上升，而人类开发者审查和修复这些问题的人力速度却保持不变，供需之间的剪刀差越拉越大，最终拖慢了整个版本的发布节奏。传统开源社区的发布流程建立在「发现问题的速度」与「修复问题的速度」大体平衡的假设之上，测试者报告缺陷、维护者评估修复、提交补丁、再走审查流程，各环节人力配置是按历史节奏设计的。AI 辅助代码分析的加入打破了这一平衡：机器可以在短时间内产出大量高密度的缺陷报告，其中不乏真实有效的深层次问题，但每一个报告仍需要资深维护者花时间验证真伪、评估影响范围、设计修复方案并通过社区审查。文章指出，这并不是 AI 不好用，恰恰相反，AI 找出来的许多问题是过去靠人工评审很难触及的盲区，真正的矛盾在于开源项目的维护人力是刚性瓶颈，社区没有足够多的资深贡献者来消化这波审查洪峰。作者的核心结论是，AI 提升了缺陷发现的吞吐量，却没有同步提升缺陷修复的吞吐量，当整个链条中最慢的一环仍是人类时，工具越强大，瓶颈反而越突出，开源社区需要重新设计工作流来适应这种新的生产节奏。

核心信息

PostgreSQL 19 的发布被显著拖延，原因并非代码质量恶化或重大架构问题，而是社区采用了 AI 辅助工具后，缺陷发现效率大幅提升，短期内涌入的问题报告远超维护者团队的消化能力，形成严重的积压。
传统开源协作流程隐含着一个前提：发现缺陷与修复缺陷的速度大体匹配，人力配置按这个节奏设计。AI 的引入打破了这个平衡——机器扫描代码发现边界条件和潜在缺陷的速度可以是人工的许多倍，但每个报告仍需资深开发者逐一验证、评估并写出补丁。
问题的关键细节在于质量与数量的矛盾：AI 产出的报告里既有真实有效的深层缺陷，也有误报和低优先级问题，人类审查者无法跳过任何一条，因为漏掉一个真 Bug 的代价比多看十条误报高得多，这使得审查洪峰无法用「粗筛」来缓解。
这一事件揭示了开源软件工程的新结构性矛盾：AI 放大了发现端的吞吐量，却没有改变修复端的瓶颈——而修复端依赖的是社区里数量有限、经验丰富的核心维护者，这类人力在短期内无法快速扩张，成为整个发布链条上最慢也最贵的一环。

💡 为什么值得读: 它用 PostgreSQL 这个最成熟的社区样本，提前演示了 AI 时代软件工程最真实的瓶颈——不是发现问题，而是人类的修复与判断带宽。

✍️ 小编看法: 这件事的价值远超一个版本跳票本身，它几乎是整个软件行业未来几年的一面镜子。过去我们谈 AI 写代码，焦虑点都集中在「程序员会不会被替代」，而 PostgreSQL 的案例给出了一个更微妙的答案：AI 没有替代维护者，反而让维护者变成了更稀缺的资源。当一个工具把发现问题的成本压到接近零，真正值钱的就变成了判断力——哪些是真问题、值不值得修、怎么修不会引入新风险，这些恰恰是资深工程师的核心能力。这对开源社区的冲击尤其现实：核心维护者本来就在超负荷运转，Burnout 是老问题，如今审查队列又膨胀了几倍，如果不改变流程设计，可能加速社区骨干的流失。我觉得被忽略的一个机会是分级处理机制——既然 AI 能发现问题，理论上也应该能用 AI 做第一道过滤：自动复现、评估严重性、甚至起草修复补丁供人审阅，把人类精力留给真正需要判断的部分，这可能是「AI 报告、AI 预审、人类定夺」的新工作流。值得观察的是，其他大型开源项目会不会更早遇到同样的问题，以及 PostgreSQL 社区最终会采取什么对策——如果他们摸索出一条可行的人机协作审查流程，那这个「跳票」换来的经验，价值会比按时发布大得多。

🏷️ PostgreSQL, open source, AI code review, maintenance