多数团队引入 AI 审查时想的是同一件事：把人看不过来的部分交给机器，问题会变少。PostgreSQL 社区这两周遇到的情形正好相反——问题变多了，而且多到排期装不下，一个已经跑了几十年的发布流程被迫推迟一个多月。
一次公开的分诊事故
PostgreSQL 19 原定 9 月底到 10 月初发布。The Register 在 10 月 16 日报道，正式版推迟到约 11 月 19 日，RC1 已于 10 月 15 日发出，RC2 定在 11 月 12 日。核心开发者 Peter Eisentraut（EDB 副总裁）在 10 月 9 日的文章里给出账目：这一周期回退了约 8 到 10 个重要特性，而正常预期是每个周期约一个；PostgreSQL 19 现在带的主要功能，大约只有几个月前预期的一半。Percona 在 10 月 15 日发了一篇《Apologies for delaying Postgres 19》，承认上报的问题里有相当一部分来自 AI 审查。
被回退的特性里，受关注最多的是 SQL/PGQ 属性图查询，也就是 SQL:2023 标准里加入的图查询语法。核心开发者 Tom Lane 在 9 月就说过，如果 19 版带着它出去，发布后会出现只能等 20 版才能修的问题。留下来的是 REPACK CONCURRENTLY（回收磁盘空间而不锁表）和 pg_plan_advice。
关键之处在于，这不是 AI 写了坏代码。Eisentraut 明确排除了这一点：被回退的代码写于 AI 编码工具普及之前。变的是审查那一端的能力。
四十条缺陷报告，每条三行
Eisentraut 给了一个具体的算术。某一个特性在 beta 期累积了大约 40 条缺陷报告，平均修复三行。三行听起来不算什么，但每一条都要走完整的固定流程：复现、写测试、评审、讨论。用他的话说，“即使每个平均只要三行的修改，处理每一条都有固定成本，然后你的时间就用完了”。
这些缺陷本身不严重，报告里称之为“涉及各种边缘情况的相对无害的问题”。在没有 LLM 辅助审查的年代，它们会以每年几条的速度在发布之后陆续被生产环境发现，被下一个版本消化。现在它们在一个下午被列成一张清单。
这里真正的启发不是“AI 审查很厉害”，而是一条产能关系：检测的边际成本已经接近零，处置的边际成本没有变。当一个工具能在一下午翻出原本要五年才能碰到的边缘情况，瓶颈就从“找不找得到”变成“谁能处理、什么时候处理”。PostgreSQL 的排期是按旧瓶颈排的，所以撞上了。
还有一层更少被提到的：标准会追溯。Eisentraut 说，功能是按当时的审查能力写的，现在拿今天这把尺子量，就不合格了。这意味着审查能力的提升本身就是一次变更——它不只是发现问题，它会重新定义什么算合格。
延期有多少该算在工具头上
Eisentraut 没有把账全记在审查工具上。他另外列了三条：4 月到 8 月资深开发者被一批安全修复占住，beta 评审的人手比往年薄；社区可能在特性上承诺过多；特性与域、复合类型、分区、视图、触发器交织，项目一贯要求“一切都与一切配合”，穷举测试不现实，而社区讨论过让特性先以实验状态合入再成熟，至今没有机制。
把这三条和四十条缺陷放在一起看，AI 审查更像一根压在已有裂缝上的杠杆：流程本来就紧，检测能力突然抬升之后，缓冲没有了。这也给出搬回去之前要先做的一件事——分清拥堵是检测变快造成的，还是本来就没有冗余。两种情况的处方不同：前者加处置产能，后者先减承诺。
把这件事搬到施工方案审查
建筑业的技术评审几乎是同一结构的放大版。一份深基坑或高支模的专项施工方案要过编制、内部审核、专家论证、监理审批几道关；图纸会审要在一两周内处理各专业提出的意见；竣工资料要在归档前核对成千上万个字段。过去的做法是有经验的工程师抽查，加上规范条文对照，漏掉的问题大多在施工过程中以变更、返工或验收整改的形式陆续暴露。
把智能体放进来之后，形态和 PostgreSQL 那四十条报告很像：它不会只挑出两三个大问题，它会一次列出几十条——这条措施引用的规范条款版本与项目执行的标准目录不一致；这张工程量表第 3 项与清单汇总差了 2.4 吨；这份应急预案里的联系人与项目部通讯录对不上；这个节点图的工序顺序与总进度计划里的关键线路冲突。单看每一条都不致命，但每条都要有人去核、去改、去重新报审。
如果企业的评审流程是按“一次评审发现五到十条问题”设计的，那么当它一次面对四十条时，剩下的路只有两条：要么压住不放，要么整批判回重做。PostgreSQL 选了后者。
可复用的关系有三条。第一条是给处置定价：先算清楚一个专业工程师一天能闭环多少条意见，再决定这轮开几个检测器、扫多少份资料，而不是先把检测能力拉满。第二条是把分诊前置：评审会的功能从“找问题”改成“分类”，收到的意见先分成本轮必改、进下一版、仅记录进风险台账三类，只有第一类占用本轮工时。第三条是给判定规则标版本号和生效日期——规范条文有编号和版本，AI 的判定规则也该有；某次规则升级只适用于生效之后提交的版本，否则已经通过论证的方案会在下一次扫描时集体变成不合格，而那种追溯性失效比漏检更伤流程。
成立条件也说清楚。这套东西依赖结构化的底稿：方案的措施要能对应到具体规范条目，工程量要有一份可交叉核验的台账，工序要能连到总进度计划。底稿是扫描件和自由文本时，智能体给出的多半是无法核对的意见，分诊也就无从谈起。还有一个必须重做的部分：建筑业的特性耦合比数据库更紧——改一条支护措施可能牵动造价、工期和相邻工序，所以分级阈值不能照抄软件项目的严重性定义，得由总工与质量部门共同签字，并且随项目类型调整。
两个可以马上做的小试验
第一个试验不写任何代码。取三十份历史退审意见和专家论证意见，按“本轮必改／下一版处理／仅记录”重新分一遍，统计三类的比例和每一类的实际闭环工时。这个数就是处置产能的量级，也是决定下一轮开多少检测的依据；它比任何模型评分都更贴近自己的排期。
第二个试验是给判定规则编号。把现在散落在提示词里的审查要求整理成一份带版本号和生效日期的清单，像规范一样管理，每次修改留痕。跑三个月之后，就能回答一个此前无法回答的问题：某份方案当年通过，是因为它当时合格，还是因为当时的尺子还量不出来。
两处外部校准
一处来自 Mercor 10 月 16 日发布的 Benchmark Map。它把 29 个公开的智能体基准映射到美国劳工部 O*NET 的 923 个职业、18797 条任务上，把“某条任务至少被 5 条基准提示命中”算作覆盖；结果是 208 个职业至少有一条任务达标，22 个职业大类里有 6 个一个都没有，按任务时长加权约 90% 的美国工作时长落在覆盖稀薄或没有覆盖的任务上。覆盖还不随机：AI 暴露度高的任务被覆盖的概率约为未暴露任务的 6 倍，律师的任务被密集覆盖，同样暴露在法律工作流里的法律秘书与法院书记员几乎没有覆盖。对企业来说这意味着公开榜单说明不了自己那份工作——没有题库的地方既不能说模型能干，也不能说它干不了，题得自己出。
另一处来自 Anthropic 10 月 16 日公布的内部用工报告。到 2026 年 8 月，交互式智能体工时已经是员工的 6 倍；约 80% 的交互式会话时间里智能体是在等人类输入；按 token 与词数换算并假定一个阅读速度，非技术员工要把自己智能体的产出读完需要半个以上的工作周。作为应对，员工转向建看板、监控管道、给智能体写指令这类“元工作”，占平均员工交互会话的比例从 2025 年秋季的 10% 升到 2026 年春季的 22%。这份报告是一家公司的自我报告，口径由自己定义，但 80% 空转这个数字指向同一件事：产出端的扩张没有配上处置端的扩张，人的注意力成了限量供应。
放到施工企业的语境里，这两处校准合起来是一句操作性的话：把处置产能当成一种要登记的资源，就像塔吊台班和试验室档期一样，先知道它有多少，再决定让机器看多少。
来源与说明
[1]: Postgres 19 delayed to November as AI review surfaces more bugs —— The Register（经 Renascence 转述） / 2026-10-16 (https://www.renascence.io/news/114840/postgres-19-delayed-to-november-as-ai-review-surfaces-more-bugs) [2]: Postgres 19 Delayed to Nov 19: AI Review Caused 8-10 Reverts —— ExplainX（逐段拆解 Eisentraut 原文） / 2026-10-17 (https://www.explainx.ai/blog/postgres-19-delayed-ai-code-review-bugs-reverted-features-2026) [3]: PostgreSQL 19 Slips to November as AI Code Review Finds Bugs Faster Than Humans Can Fix Them —— DEV Community / 2026-10-17 (https://dev.to/techpulse01239/postgresql-19-slips-to-november-as-ai-code-review-finds-bugs-faster-than-humans-can-fix-them-191l) [4]: Postgres 19 Slips to November: AI Code Review Found More Bugs Than Humans Could Fix —— Get AI Book（含 Percona 致歉与 RC 时间线） / 2026-10-16 (https://getaibook.com/news/postgres-19-delayed-ai-code-review-found-too-many-bugs) [5]: A benchmark map of the US economy —— Mercor / 2026-10-16 (https://www.mercor.com/research/labor-index/benchmark-map/) [6]: Mercor Benchmark Map: 90% of US working hours are barely measured by AI benchmarks —— ExplainX / 2026-10-16 (https://explainx.ai/blog/mercor-benchmark-map-90-percent-us-working-hours-not-covered-ai-benchmarks-2026) [7]: How employment is changing at Anthropic —— Anthropic Research / 2026-10-16 (https://www.anthropic.com/research/employment-at-anthropic) [8]: Anthropic report says AI is reshaping hiring, work and output —— DevEvil News / 2026-10-16 (https://news.devevil.com/anthropic-report-says-ai-is-reshaping-hiring-work-and-output-1555821.html) [9]: Hacker News 当日热帖汇总（10-17，PostgreSQL 延期 199 分、基准覆盖地图 521 分） —— Hacker News Highlights / 2026-10-17 (https://podfollow.com/hacker-news-highlights/episode/f61c4ab3a3f08f4a7016ae4fd0b36c77a3423dd2/view)
检索截止：2026-10-18 05:45（Asia/Shanghai）。Anthropic 与 Mercor 的数字分别为公司自报与自估，已在正文标注口径；施工场景的估算为本文设想，未实施。