PostgreSQL 19 推迟到 11 月中：八到十个特性被撤，有人说 LLM 代码评审要负责

PostgreSQL 19 的发布窗口被推到了 11 月 19 日前后，开发者已经撤下 8 到 10 个重要特性。EDB 的 Peter Eisentraut 说了一句话，让这件事从版本延误变成了行业话题：这些回滚至少有一部分可以归因于 LLM 代码评审。

数据库项目的容错空间

PostgreSQL 是全球部署最广的开源数据库之一，它的补丁流程以慢著称：设计讨论、多轮评审、回归测试，一个中等改动的周期以月计。慢是有理由的——数据格式、索引结构、WAL 协议一旦定下来，改回去的代价可能是十年。

这类项目对「看起来没问题」的容忍度最低。评审不是形式，是唯一的质量闸门。

如果提交由模型写、评审也由模型做，问题就出现了：模型看不出模型错在哪，人又被一份措辞完整、格式漂亮的评审意见说服。

LLM 评审的典型特征是「说得很像那么回事」——它会指出命名不规范、缺少边界检查、建议加个注释，同时漏掉真正的语义错误：并发场景下的可见性、极端输入下的溢出、和既有行为的不兼容。这些恰恰是数据库补丁最容易翻车的地方。

撤下不等于删代码。文档要改、兼容性说明要改、下游扩展的适配要重排、已经基于它开发的应用要等下一版。8 到 10 个特性被撤，意味着有一批等这些功能上线的团队要重新排期。

今年已经有不少开源项目在提高 AI 生成代码的门槛：要求贡献者声明 AI 参与程度、要求提供可复现的测试、要求有人对每一行负责。Linux 内核那边反复讨论过 AI 生成代码的署名与责任问题，态度是「可以提交，但你要为它负责」。

PostgreSQL 的体量和「一旦错了十年不改」的属性，让它成了最敏感的那一类项目。它的一举一动会被其他项目当成参照。

而是流程设计。代码评审这道闸门的价值，来自评审者的判断力。如果闸门本身换成了模型，闸门的意义就变了——它变成了一次格式检查。

对照一下 Anthropic 自己公开的做法会更有意思：Claude Code 团队用多个智能体交叉投票验证结论，再按风险分级决定一个改动需要 0、1 还是 2 个人类批准。六月到九月，合并的 PR 数量翻倍多，被回滚的比例降了四成多。

他们的结论不是「让人少参与」，而是「让人参与在更少但更关键的地方」。PostgreSQL 这次踩的坑，恰好是这条原则的反面案例。更宏观的一层看，有研究已经指出 AI 编码智能体写出的代码更多，但交付的软件并没有变多——多出来的部分，最后都变成了评审和回滚的工作量。