一、发生了什么
PostgreSQL 19 原定 9 月底或 10 月初发布，现在推迟到 11 月 19 日前后，8 到 10 个重要特性被回退到明年的 PostgreSQL 20。核心 committer、EDB 副总裁 Peter Eisentraut 在 10 月 9 日的博客《The reverts will continue until morale improves》里给出归因：至少部分因为社区普遍用上了 LLM 辅助代码审查------它找出缺陷的速度，超过了团队修复的速度（来源：Eisentraut 博客；The Register 10 月 16 日报道）。最大的牺牲品是本该作为 19 版头牌的 SQL/PGQ 图查询，Tom Lane 九月就警告过：现在上，会带来「到 v20 都修不完」的发布后缺陷。
二、技术拆解
先看清楚发生了什么。Eisentraut 把回退的发现分成两类：少数是架构级缺陷 ，beta 期内修不完只能砍；大量是长尾边缘缺陷，单看每个都「相对无害」，在过去的人工审查节奏下，这类问题会在发布后五年里慢慢冒出来、慢慢修。
LLM 审查做的事，是把这条五年的发现曲线压缩进了几周的 beta 期。他举的算术例子很直观：一个特性积累出约 40 份缺陷报告，平均每份只要改三行------但每份都有固定开销：复现、写测试、评审、讨论。注意这是说明用的举例，不是官方统计口径（来源：The Register 引述）。
更关键的是时间差：这些特性是在 LLM 审查还没这么能打的时候写好并提交的 ，到了 beta 后期审查能力上来，等于拿新尺子量旧代码。Eisentraut 原话是「有效的质量标准在特性提交之后被抬高了」。他也排除了偷懒的解释：代码写的时候 AI 编码工具还没普及，写的人没问题，是审查变强了。
被砍的和保住的，一张表看明白：
| 状态 | 特性 | 说明 |
|---|---|---|
| ❌ 回退到 PG20 | SQL/PGQ 图查询 | SQL:2023 标准特性，本版头牌，Tom Lane 九月预警 |
| ❌ 回退到 PG20 | GROUP BY ALL | 语法糖类，边缘缺陷多 |
| ❌ 回退到 PG20 | MERGE/SPLIT PARTITION | 分区操作，与多领域交互复杂 |
| ❌ 回退到 PG20 | UPDATE/DELETE FOR PORTION OF | 时间区间操作 |
| ❌ 回退到 PG20 | 在线数据校验和 | 未解决缺陷 |
| ✅ 保留 | REPACK CONCURRENTLY | 无长锁重建膨胀表，替代 VACUUM FULL |
节奏上：RC1 已于 10 月 15 日发布，RC2 计划 11 月 12 日，GA 目标 11 月 19 日前后（来源：CodeYourCraft 汇总官方发布计划）。
这里要说句诚实话：官方发布通告里没提 AI。归因于 LLM 审查是 Eisentraut 个人博客的判断，他自己并列了三个候选原因：4 到 8 月核心开发者被一波安全修复占住、beta 评审人手变薄；特性贪多；以及 Postgres「everything works with everything」的组合复杂度让穷举测试不现实。AI 审查是放大器，不是唯一原因。Snowflake 工程博客的统计也说明这点：PG19 周期 beta 以来 revert 约 53 次，PG18 约 44 次------差距存在，但没有标题暗示的那么戏剧化。
这个「审查跑赢修复」的错位，我在 10 月 11 日的满分代码没编译过也判过里写过镜像的一面------那篇讲「验证在测什么」，Postgres 讲「验证发现了问题之后谁来兜底」，拼起来才完整：AI 把验证做得又快又狠，但裁决和修复的产能还是人工的 。10 月 7 日写OpenAI 放出 722 份数学手稿时的结论「AI 时代最贵的不是产出，是验证」，现在要改半句------最贵的正在变成「处置验证结果」。
三、我的判断
第一，约束位移了。 老瓶颈是「发现缺陷难」，现在它正快速消失，新瓶颈是「处置缺陷」：发现是机器的、近乎免费；修复、验证修复、决定修不修，是人的、按小时计费。两边增速不匹配就会撞上------Postgres 只是第一个把撞墙过程完整公开的旗舰项目。
第二，这不只是数据库圈子的事。 「质量标准在代码提交之后被抬高」对所有存量代码都成立：给三年没动过的老仓库开 AI 审查，等价于换一套更严的规范再追溯执行。选型 AI 审查工具时，它的价值要和团队的「triage 产能」一起评估，单看召回率会被反噬。
第三，因果要拿捏分寸。 「AI 审查导致延期」是好标题，但官方通告没这么说，当事人也列了并列原因。更准确的说法：AI 审查显著放大了本已存在的质量债，把原本五年慢慢还的债一次性摆上桌。
第四，「会自愈」要打折听。 只要 LLM 审查能力还在涨，「新尺子量旧代码」的错位就会重复出现。把它当常态化工程约束排期，比指望消失靠谱。
四、对开发者的启示
- 给 AI 审查配「裁决预算」：开审查前按「每份报告 30 分钟起」估 triage 工作量，写进排期。发现免费了，处置没有。
- 分批跑，别攒着：按 PR / 每周节奏跑审查，不要攒到 release freeze 前一次性引爆。
- 对存量代码先抽样：全量开闸前先拿一个模块试跑，看长尾报告密度，再定节奏和范围。
- 选型看闭环：召回率高只是及格线，能不能按严重度分级、能不能批量裁决，才决定你会不会被 40 份三行修复淹死。
一个可以直接拿走的审修缺口计算器，用你的真实数据估一估 AI 审查带来的处置压力：
python
# review_gap.py -- 审修缺口计算器
import argparse
def main():
p = argparse.ArgumentParser(description="AI 代码审查的审修缺口估算")
p.add_argument("--reports", type=int, required=True, help="预计缺陷报告数")
p.add_argument("--avg-min", type=int, default=30, help="每份平均处置分钟")
p.add_argument("--window-days", type=int, default=14, help="处置窗口天数")
p.add_argument("--reviewers", type=int, default=1, help="处置人数")
p.add_argument("--daily-cap-min", type=int, default=180, help="每人每天处置分钟")
a = p.parse_args()
need = a.reports * a.avg_min / 60
cap = a.window_days * a.reviewers * a.daily_cap_min / 60
print(f"处置需求: {need:.1f} 人时 / 产能: {cap:.1f} 人时")
if need > cap:
extra = (need - cap) / (a.window_days * a.daily_cap_min / 60)
print(f"缺口 {need - cap:.1f} 人时 -> 要么延期, 要么再加 {extra:.1f} 个人")
else:
print(f"无缺口 (富余 {cap - need:.1f} 人时), 这个窗口装得下")
if __name__ == "__main__":
main()FAQ
Q：官方说延期是因为 AI 吗？
A：没有。官方通告未提 AI，归因来自核心 committer 的个人博客，他还并列了安全修复挤占人手、特性贪多、组合复杂度三个原因。
Q：40 份缺陷报告是实数吗？
A：不是，那是 Eisentraut 解释算术用的举例，不是官方统计口径。
Q：被砍的特性怎么办？
A：预计进 PostgreSQL 20。几个月前社区本来预期 PG20 是纯修 bug 的版本，现在它要接住一整批新特性。
上周写《Meta 开源 816B》时说过，看到「最强」先找限定词；今天换成流程侧------AI 改变的先是工具层（10 月 14 日那篇《git 假设你是人类》），现在轮到发布流程和质量管理了。这个专栏每天一篇 AI 解读，关注不迷路。你们仓库现在开 AI 代码审查了吗？发现的问题量，修复速度跟得上吗？
专注 AI 工程化实践与出海外贸技术