当 AI 开始帮开源项目找 Bug，第一个被压垮的可能不是代码，而是人。
发生了什么
据 Hacker News 上的讨论，Postgres 19 的发布被推迟。原因并非某个致命缺陷，而是 AI 审查工具在代码库中标记出的问题数量，已经超过了人类维护者能够及时核实和修复的节奏。换句话说，瓶颈从"发现 Bug"转移到了"处理 Bug"。
Postgres 是全球最重要的开源关系型数据库之一，其发布节奏一向以稳健著称。此次延期说明，即便是流程成熟、审查严格的项目，也会被 AI 带来的问题洪流打乱节奏。
为什么重要
过去几年，AI 代码审查被当作提效工具大力推广：它能不知疲倦地扫描 diff、指出潜在的空指针、并发问题和边界条件。但 Postgres 的案例揭示了一个被忽视的副作用——AI 的"发现能力"远高于人类的"消化能力"。
这背后有两层原因。其一，AI 审查工具倾向于宁滥勿缺，误报和低优先级问题会稀释维护者的注意力。其二，开源项目的核心维护者本就是稀缺资源，多数靠业余时间投入，无法像企业团队那样按需扩容。当 AI 把待办列表拉长数倍，项目只能选择延期，而不是降低审查标准。
这也让人重新审视"AI 提升生产力"的叙事：在发现环节，AI 确实在放大产能；但在决策和修复环节，人类仍是不可绕过的关卡。
影响与看点
对开发者而言，短期内可能感受到 Postgres 19 新特性落地变慢，依赖新版本的项目需要调整升级计划。对开源维护者而言，这是一个警示信号：引入 AI 审查工具前，需要先设计好优先级过滤和分流机制，否则工具本身会成为负担。
更值得关注的是行业层面的连锁反应。如果头部项目都开始被 AI 审查的产出压垮，那么"AI 生成代码 + AI 审查代码"的闭环可能会制造出远超人类处理能力的变更量。未来的竞争点，或许不在于谁能发现更多问题，而在于谁能更聪明地判断哪些问题值得修。
一个克制的判断是：AI 审查不会消失，但"全量采纳 AI 建议"的做法大概率会被淘汰，取而代之的是分级、可配置、带置信度的审查流程。Postgres 的延期，可能只是这场调整的开始。
