这几天开源圈出了件挺罕见的事：全球用得最多的开源数据库 PostgreSQL，把原定 10 月 29 日发布的 19 大版本推迟到了 11 月 19 日，还罕见地在 11 月 12 日加塞了一个 RC2 候选版。延期原因不是代码写烂了，恰恰相反——AI 代码审查干得太好，几周内翻出了过去可能要五年才会陆续暴露的问题。人类维护者面前堆着大约 40 份缺陷报告，修不完，只能延期。36氪
如果你也在用 Claude Code、Codex、Cursor 这类工具干活，这事值得细看。因为同样的剧情，大概率正在你的团队里上演，只是没有 PostgreSQL 这么显眼。
先把事实说清楚
PostgreSQL 核心提交者、EDB 副总裁 Peter Eisentraut 专门撰文解释了这次异常。几个关键数字：
正常情况下，一个大版本周期回滚 1 项重要功能算常见；这次 Beta 阶段撤了 8~10 项，明显超出惯例。36氪
撤下的功能里最出名的是 SQL/PGQ（属性图查询，SQL 标准的新玩法，能直接在关系表上做图查询），同批被撤的还有 GROUP BY ALL、分区合并拆分、在线数据校验和。知乎专栏
留下来的也不弱：REPACK CONCURRENTLY（不锁表重建膨胀表，补上了 VACUUM FULL 锁表多年的短板）、序列的逻辑复制、pg_plan_advice 查询规划器提示。
时间线：RC1 已按计划 10 月 15 日放出，正式版推迟三周到 11 月 19 日，中间加一轮 RC2 让社区验证近期堆积的大量修复。
有个细节特别有意思：今年 8 月，社区成员 Robert Haas 就让 Claude 对 PG19 的补丁做过风险评估，SQL/PGQ 被 AI 列为高风险功能——当时它已经修了 17 轮。资深贡献者 Tom Lane 早就放过话：硬塞进这个版本，大概率出现发布后才发现、又修不动、只能等下下版的深层缺陷。结果一语成谶，SQL/PGQ 真被撤了。AI 不只是聊天式代码评论员，它已经参与真实开源项目的风险筛查了。36氪知乎专栏
为什么 AI 越强，发布反而越慢
Eisentraut 先泼了盆冷水否定了一个流行猜测：这不是 vibe coding 闯的祸。被撤的那些功能，几乎都写于 LLM 辅助编程普及之前。问题不出在"生成侧"，而出在"验收侧"——代码是按当年的标准通过的，然后被今年的新尺子重新审判。
数据库又特别容易中招，因为 PostgreSQL 的功能讲究自由组合：domain 套复合类型、分区表 detach 再 attach、外面裹一层视图、视图又被触发器里的 security-definer 函数调用——人类根本枚举不完这些组合，AI 却可以不知疲倦地构造输入、观察异常、顺着炸点继续挖。这些边缘缺陷，过去会在发布后的五年里被真实用户零星撞上、再慢慢修掉，没人着急；现在 AI 审查和 LLM 辅助模糊测试几周内把它们全扫出来了。
然后是那笔扎心的账：面前摆着大约 40 份缺陷报告，就算平均每份只改 3 行代码，每份也压着复现、写测试、评审往返、记录讨论这些固定开销。知乎有作者按每份 80 分钟示意性估算，40 份就是约 53 个人时；一个提交者每周能挤出 6 小时处理这类事，就是将近九周。而发布窗口只有三周。36氪
一句话总结这个拧巴局面：发现是并发的、近乎免费的；修复是串行的、按人天计费的。两个速率一旦倒挂，再硬的质量文化也会被"好问题清单"拖垮。知乎专栏
Eisentraut 把这叫"有效质量门槛被抬高了"——这是整件事最反直觉的结论：AI 提升了软件质量，却实实在在拖慢了发布速度。36氪
但也别急着把锅全甩给 AI
Eisentraut 自己强调了：AI 不是唯一原因。今年 4 月到 8 月，PostgreSQL 社区经历了一轮密集的安全问题处理，大量资深开发者被抽走，Beta 前期该做的评审和测试受了影响；再加上 PG 自身复杂度逐年上涨，很多问题是到了发布周期后段才集中暴露。社区里那句自嘲的玩笑话还被 LWN 做进了标题：“回滚会持续到士气恢复为止”。知乎专栏
更值得注意的是，这件事根本不是 PostgreSQL 一家的孤例。Tessl 博客最近引用了 Jellyfish 2026 年 9 月的行业数据：中位数公司里，22% 合并进主干的代码已经由自主编程 Agent 写出，跑得最快的前 10% 公司这个比例高达 53%。但由 Agent 自己评审并合并的 PR，中位数只有可怜的 0.6%，最激进的前 10% 公司也才爬到 9%。写代码的水龙头彻底拧开了，审代码的下水道还是原来那么粗。Tessl官方博客知乎专栏
知乎上这几天的讨论簇也是同一个味道：“AI 写了 60% 的代码，为什么企业研发效率还是没飞起来”（81 万浏览）、“团队都用上 AI 编码了，为什么交付没有变快”、“代码让 AI 写了一半，最后背锅的还是那个熬夜审代码的人”。PG19 只是第一个把这件事摆上台面的高知名度"受害者"。
普通人能带走什么
就算你不维护数据库，只要你在用 AI 工具，这套逻辑都适用。PostgreSQL 社区趟出来的经验，至少有三条可以直接抄。知乎专栏
盯两个独立指标：发现速率和修复速率。前者持续高于后者时，吃掉的是你的排期，而不是"质量在变好"。个人用 AI 也一样——AI 一晚上给你提了 30 条优化建议，你先问自己消化得动几条。
提前定好"回滚预算"：哪些问题宁可带病上线、哪些必须卡发布，事先说清楚。PG 社区这次没有选择"延到修完为止"（那样永远修不完），而是分流处理：架构级修不动的整块回滚，边角问题按"日历内能否闭环"逐条裁决。
给审查端降载：限定 AI 审查轮数、只重审新增 diff、让 AI 先自己做一遍分诊排序，人只看最严重的头部问题。开发者社区现在的共识是，下一个瓶颈正在从"发现 Bug"转移到"给 Bug 分类"。36氪
还有个时序错位的提醒：你的存量代码、老自动化脚本，"当年能跑"不等于今天还能过审。用新工具把老项目扫一遍大概率会冒出一堆历史告警——记得分批消化，别指望一个周末修完。
接下来值得盯的信号
11 月 12 日 RC2、11 月 19 日 PG19 正式版能否如期落地；
SQL/PGQ 这批"接近完成"的功能会不会在 PG20 回归——原本社区以为 PG20 会是个纯修 Bug 的版本，现在反而攒下了一批候选功能；
Eisentraut 判断 AI 辅助模糊测试未来要直接进入功能开发流程、而不是 Beta 后期才用，这个流程改造会不会被其他大型开源项目跟进。
短期看，PostgreSQL 19 难产了；长期看，它可能是第一个被 AI 抬高质量线的"昂贵教训"——学费是全体开源社区凑的，经验却归所有用 AI 干活的人。AI 把发现问题变得近乎免费之后，真正稀缺的从来都是人的注意力。这笔账，早晚每个人都要算一遍。
