事件与背景

PostgreSQL 19 要迟到了。这不是又一次「AI 写代码写出事故」的故事，而是一次关于验证成本的公开复盘。

10 月 21 日，PostgreSQL 核心开发者 Robert Haas 在自己的博客发文，解释为什么 19 版大概率要等到 11 月才能发布：按过去十年的惯例，PostgreSQL 大版本总在 9 月中到 10 月中之间发布，而今年不仅整体推迟，还有三个相当大的特性在 beta 期被临时回退——UPDATE/DELETE FOR PORTION OF、SQL Property Graph Queries（SQL/PGQ）、ALTER TABLE … MERGE PARTITION/SPLIT PARTITION，回退时间集中在 8 月 27 日到 9 月 15 日之间，远晚于 4 月 8 日的特性冻结日。

Haas 给出的数字很直接：2025 年 4 月 8 日到 9 月 25 日，master 分支有 1037 个提交、REL_18_STABLE 有 724 个；2026 年同一时间窗口，master 是 1443 个，REL_19_STABLE 是 1169 个。两组数字里，Haas 强调的重点不是 master（1037 → 1443），而是回补到稳定分支的提交涨了六成以上；再往前一个版本看，2025 年同期 REL_17_STABLE 是 248 个提交，2026 年 REL_18_STABLE 是 433 个，涨幅超过 74%。他的解释是：代码库还是那个代码库，但「找到 bug」这件事被 LLM 变得极其便宜，而修 bug、评审补丁仍然要由同一小群提交者完成。

这篇复盘在 10 月 31 日冲上 Hacker News 首页，抓取时约 787 分、465 条讨论。排在最前的评论把问题说得很准：「真正的挑战是如何扩展验证，发现已经不是瓶颈了。」

但故事还有另一半。10 月 1 日，另一位 PostgreSQL 提交者 Tomas Vondra 写了篇针锋相对的分析：他把 12 个被回退的特性逐个翻邮件列表，结论是只有 4 个的成因是「AI」或「可能由 AI」，其余多数来自常规的人工 review——有的问题作者自己就在注释里写了 workaround，有的在 PG17、PG18 周期就已经被指出过。他同时用 git 历史统计了从 PG14 以来的回退数量与时间分布，认为今年的回退总量并不异常，异常的是时间点：往年回退高峰出现在特性冻结后不久（开发周期的第 300 天左右），而 PG19 的曲线在前 430 天几乎是一条平线，直到 9 月初才突然爆发。

Vondra 认为真正的原因是注意力被抽走了：去年 PostgreSQL 一年大约 5 个 CVE，今年到现在已经 44 个（官方安全页面上确实列着 44 条 CVE-2026-* 记录），其中相当一部分由 AI 辅助发现。资深贡献者的时间被安全报告处理占满，稳定期的评审自然停摆。

来源（均已 curl 验证返回 200）：

• Robert Haas：Postgres 19 is late, and it’s AI’s fault（Neon 博客的全文转载；原文在 rhaas.blogspot.com，本机直连超时返回 000，故引用可访问的转载全文，署名为 Robert Haas，页面标注 2026-10-21）
• Tomas Vondra：Are we reverting patches because of bugs found by AI?（2026-10-01，逐条核对 12 个回退）
• PostgreSQL Roadmap（19 版计划 2026 年 10 月发布；页面顶部公告 2026 年 10 月 15 日已发 RC 1）
• PostgreSQL Security Information（2026 年 CVE 列表，可数出 44 条）
• Hacker News 讨论（787 分 / 465 评论）

为什么现在重要

1. 发现成本崩塌，但判断成本没变，两者之差就是发布延迟。 LLM 可以把「找 bug」的边际成本压到接近零，一天扫完几十年的 C 代码；但每一条报告仍然要有人确认是否真实、是否影响受支持版本、修复是否引入回归。Haas 的原话是：LLM 能起草修复，但「那些修复并不总是正确或符合 PostgreSQL 的规范」，而「这些人在 2025 到 2026 之间并没有变聪明」。影响：把 review 容量当成和 GPU 一样需要预算的稀缺资源，而不是免费的后台活动。

2. 安全报告正在变成一种新的拒绝服务攻击面。 从约 5 个 CVE 到 44 个，意味着同一个小团队要多处理近九倍的安全流程——复现、评估严重性、协调披露、回补多个稳定分支、写公告。Vondra 的判断是，这才是稳定期无人 review 的主因。影响：上游项目的「CVE 密度」应当进入你的依赖风险评估表，和 star 数、发布频率并列。

3. 归因错了，优化就会反着来。 Haas 的框架是「LLM 让 bug 更容易被发现」，Vondra 的反驳是「12 个回退里只有 4 个和 AI 有关」。两种说法都承认 AI 改变了流程，但对应的动作完全不同：如果相信前者，你会给团队加更多扫描器和 agent；如果相信后者，你该做的是给分流和复现加人手。影响：在没有分类统计的情况下，先量自己队列里 AI 报告的确认成本，再决定扩哪一端。

4. 大版本的「可预测性」本身在贬值。 PostgreSQL 是过去十年里发布节奏最稳的基础设施项目之一，今年第一次明显滑期，说明连最保守的 C 项目也无法把 AI 带来的额外负载挡在发布流程之外。影响：把「上游按计划发版」从默认假设降级为需要复核的依赖——升级窗口、驱动兼容性测试、托管服务的版本跟进，都该留一个月缓冲。

5. 这件事对闭源团队的版本只是换了个名词：合并队列。 内部代码库没有 CVE 公告流程，但有 PR 队列。当 coding agent 把提交量提高两三成，而资深评审人数不变时，结果不会是「交付变快」，而是队列变长、单条 PR 的等待时间变长、以及为了赶进度而降低 review 标准。影响：用「每条 PR 的验证工时」而不是「代码行数」来做产能规划，否则你只是在给队列灌水。

工程师/产品人今天能做什么

1. 给 AI 生成的 bug 报告设准入门槛（本周）。 要求最小可复现用例、精确版本号、完整日志、影响面判断；缺一项就进「待补全」而不是 backlog。这一步不减少真实缺陷，只减少确认成本——正是 PostgreSQL 现在最缺的东西。

2. 做一次「只读」代码审计，不自动修。 选一个核心模块，用 LLM 扫一遍，人工逐条判定真/假阳性，记录每条的平均确认分钟数。一周内你就能得到自己团队的「发现→确认」转化率，这比任何 benchmark 都更能决定要不要扩大规模。

3. 检查你的 Postgres 版本与补丁窗口。 19 版尚未 GA（RC 1 于 10 月 15 日发布，roadmap 仍写着 10 月），不要把新特性排进近两周的里程碑；同时确认生产环境已跟到最新 minor 版本，年内 44 个 CVE 的修复大多落在 minor release 里。官方下一次 minor release 计划在 11 月 12 日。

4. 把「验证预算」写进排期表。 给每个 AI 辅助的 PR 预留明确的 review 时间，并在看板上单列一栏「等待验证」。当这一栏开始堆积，就是该停下生成、转去消化的时候。

5. 对关键依赖做一次「维护者负载」评估。 看它最近半年的 CVE 数量、回退频率、以及发布是否按期。对负载已经饱和的上游，提前准备 pin 版本与自建补丁的预案，而不是等公告出来再反应。

待观察

• PostgreSQL 19 的 GA 日期。 roadmap 仍写「planned for October 2026」，但截至 11 月 3 日尚未发布，RC 1 之后是否还有 RC 2、最终是否落到 11 月中下旬，是目前最直接的观察点。
• 44 个 CVE 里由 AI 辅助发现的占比。 官方没有分类统计，Vondra 的说法是「相当一部分」，属于判断而非硬数据；如果社区后续公布来源分布，会直接决定「安全报告洪水」这个论断的分量。
• PostgreSQL 是否会出台正式的 AI 贡献政策。 Vondra 文中提到目前没有官方政策、但预计很快会有。这类政策（是否要求披露 AI 使用、AI 生成的报告走什么流程）会成为其他大型开源项目的模板。