AI审查泛滥成灾：PostgreSQL 19延期揭示的新瓶颈

PostgreSQL 19 的发布时间被推迟到了11月19日前后。核心提交者 Peter Eisentraut 透露了一个信号：LLM 辅助代码审查发现缺陷的速度，已经超过了团队修复它们的速度。大约 8 到 10 个重要功能在 beta 阶段后被从 19 分支中回滚。The Register 的报道标题是「AI 审查拖慢了 Postgres」，不过项目本身给出的理由更微妙一些——但其中的模式值得所有做 AI 辅助开发的团队留意。

发现问题变得前所未有地便宜

一年前，稀缺资源是一个仔细的审查者。现在你可以把同一处改动丢给好几个模型，几分钟内收获一张长长的关注点清单。这听起来很美，直到清单的长度超过你一周的工作量。

真正的难点已经转移了：

• 哪些发现是真实的，哪些只是模型自信地胡说？
• 哪些问题真正阻塞发布，哪些可以再等等？
• 这个判断由谁来做、由谁签字负责？

PostgreSQL 的案例里，问题不是审查不够，而是审查产生的信息量超出了维护者的处理带宽。8 到 10 个功能被回滚，并不是因为这些功能本身有致命缺陷，而是在 beta 之后缺陷报告的洪流让团队无法对每一个都做出充分的判断——于是只能保守地砍掉。

PostgreSQL 的发布流程采用「功能冻结 + beta 期」的模式：在 beta 阶段，新功能已经合入主分支并进入公开测试，此时若发现严重缺陷，修复成本远高于开发期，因为要同时兼顾向后兼容、升级路径和已有用户的预期。因此在 beta 后回滚功能是一项代价高昂的保守决策，通常只在缺陷无法在发布窗口内稳妥解决时才会采用。

所谓「回滚」并不等于功能有致命错误，而是维护者无法在有限时间内对功能相关的所有缺陷报告完成充分评估与修复，只能选择将其移出当前大版本、留待后续版本重新提交。这一机制正是理解本次延期逻辑的关键背景。

多源交叉验证：究竟是什么拖慢了 Postgres

关于这次延期的原因，不同来源的叙述存在细微分歧，值得并置来看。

The Register 的框架偏向「AI 审查者导致延期」——把 LLM 工具直接放在因果链条的起点，这个叙事更抓眼球，也更容易被概括成一句话。而据 Peter Eisentraut 本人的说明，项目自身的理由更复杂：LLM 辅助审查确实加速了缺陷的暴露，但延期还牵涉到 beta 周期中功能回滚带来的连锁调整。换句话说，AI 审查是加速器，不是唯一原因。

两个来源的共识在于：缺陷发现速度的提升，确实让「决定哪些缺陷值得修」成为了新的稀缺环节。分歧在于对该环节权重的评估——一方视其为直接原因，另一方视其为放大器。对做工程的团队来说，后一种理解更可操作：工具本身不制造延期，信息处理的瓶颈才制造延期。

Peter Eisentraut 是 PostgreSQL 的核心提交者之一，长期负责发布管理与提交权限，其公开说明通常比媒体报道更贴近项目内部的决策过程。在开源数据库项目中，「核心提交者」拥有将补丁合入主分支的最终权限，也是发布节奏的实际把关人。

因此，在评估延期原因时，Eisentraut 的表述应被视为一手信息，而 The Register 的报道属于二手概括。二者的差异并非事实冲突，而是叙事框架不同：媒体倾向于归因于单一显眼因素，项目方则描述多重因素叠加的决策链条。

单人开发者的一种朴素解法

原文作者在开发一个叫 Brainstorm 的 Linux 应用（1.0.1），允许多个 AI 就同一目标进行讨论。他最终采用的工作流刻意保持「无聊」：

1. 让多个模型先就方案争论，把分歧提前暴露在规划阶段，而不是留到 review 阶段。
2. 把检查环节与写代码的 agent 分开，避免「跑通了」被误认为「做对了」。
3. 任何内容进入主分支前必须由人类批准。

这套流程的重点不是产生更多发现，而是留下一条可追溯的记录：谁提出了异议、什么被检查过、谁签了字。作者还强调，模型账号由用户自带，他不转售模型额度——这既是商业模式的选择，也间接说明了他对「工具中立性」的定位。

对于正在被 AI 审查洪水淹没的团队，这套做法的借鉴价值在于它把「判断」显式化为流程中的一个独立环节，而不是默认由工具或某个人顺手完成。

Brainstorm 是一个 Linux 桌面应用，其设计思路是让多个大语言模型围绕同一目标进行结构化讨论，从而在方案阶段暴露分歧。作者采用的「自带模型账号」（BYO key）模式，意味着用户自行提供 API 密钥与额度，应用本身不转售模型调用。

这种模式在 AI 工具中越来越常见：它降低了开发者的运营成本与合规风险，也让工具在模型选择上保持中立——用户可以对同一任务切换不同模型，而不被锁定在单一供应商的审查偏好上。这与文中强调的「多模型交叉验证」思路是同一设计哲学的两个侧面。

判断力成为新的工程瓶颈

PostgreSQL 的延期不是孤例，而是一个行业信号。当发现问题的成本趋近于零，整条流水线的约束点就会自动后移到「决定什么重要」这一步。这带来几个需要提前准备的现实问题：

审查带宽需要被当作资源来管理。 如果一次改动能瞬间生成 50 条评论，那么团队的审查容量就是 50 条之外的那个数字。忽略这个上限，工具带来的效率增益会被消化在无效的讨论里。

责任归属必须明确。 「这个缺陷可以不修」是一个需要有人签字的决定，模型无法承担这个责任。PostgreSQL 团队的做法——在 beta 后回滚功能——本质上是一种保守的责任兜底：判断不了就砍掉。

工具链的设计要承认人类的判断是最终环节。 无论是多模型辩论还是独立检查环节，目的都是让判断发生得更早、更有依据，而不是把判断自动化掉。

对单人开发者和大型开源项目来说，这个瓶颈的形态不同，但本质相同：AI 让问题清单变长了，而决定清单上哪些条目值得行动的能力，仍然稀缺。