代码评审才是 AI 时代真正的瓶颈：但你们团队根本没在 review
5x 编码速度的真账单 2026 Q3 开始还。如果你团队 review 流程没改，那笔账走的不是"代码出 bug"，是"团队信任崩"。
12 个团队的真实数据
过去一个月做了 12 场 1:1，覆盖 100-2000 人规模的工程组织。统一问三个问题：PR 平均行数、平均 review 用时、最近一次拒 merge 是什么时候。
| 维度 | 2024-Q4 | 2026-Q1 | 变化 |
|---|---|---|---|
| 平均 PR 行数 | 220 | 810 | +268% |
| 平均 review 用时（min） | 35 | 21 | -40% |
| 平均评论数 | 6.4 | 2.1 | -67% |
| "Approved without comments" 占比 | 18% | 61% | +239% |
| 平均 reviewer 数 | 1.9 | 1.4 | -26% |
如果只看 throughput，这数据牛逼。看深一层就明白——编码段被 AI 卷成了 PR 工厂，但人对 PR 的认知能力没扩容。
reviewer 在干嘛
我让几个 reviewer 边 review 边录屏，看出几个共同模式：
- 只看 PR 描述（如果是 AI 生成的，那等于看 AI 的总结看 AI 写的代码）
- 跳到测试文件，看测试通过就 approve
- 抽样看 1-2 个核心文件，其他 diff 折叠不展开
- 配合 AI Reviewer（如 Greptile、Bito），但只看高严重 finding，中低被 ignore
第 4 点最危险：AI 评审工具默认信号高于 95% 才报，剩下的全过。人类 + AI 形成了一个共谋盲区。
真账还要等多久才暴雷
我做了一个简单的回归：用 12 家公司的 review 质量指标 vs 6 个月后的 P0/P1 事故数量。滞后期是 2-3 个季度。
也就是说 2026 Q1 的 review 质量决定了 2026 Q3/Q4 的事故频率。等你被 Pager 叫起来的时候，已经堆了一个季度的烂账。
真正能修的几个动作
不要再说"我们要加强 review 文化"。这话在过去 15 年没修过任何团队。真正修的动作只有三个：
1. 强制 PR 拆分 PR 上限就设为 300 行（含测试），超出强制拆。AI 写得快不是不拆的理由，是必须拆的理由。
2. Reviewer 也用 AI，但用「不同的 AI」 作者用 Claude 写代码，reviewer 强制用 Codex（或反之）批判性读。用同一个模型 review 等于自我背书——它会觉得自己写的"很合理"。
3. 把 review 时间从「平均」改成「下限」 PR > 100 行必须 review ≥ 15 分钟、＞500 行必须 ≥ 45 分钟。给 reviewer 留时间是工程领导的事，不是 reviewer 的事。
这是经理岗位最容易翻车的地方
「编码效率 5x」可以发 OKR 写报告。「PR 质量没下降」是凭感觉。前者升职，后者背锅。你猜大家在选哪头。
但翻车点在下个 OKR 周期，而下个周期你可能正好在新岗位上。换岗的人把烂摊子留给接班人，是这一轮 AI Coding 普及里最常见的隐形操作。
如果你是接班人，入职前两周 grep 一下最近 6 个月的 PR commit message：里面如果反复出现"refactor: handle edge case"、"fix: missing null check"、"hotfix: revert XX"，你正在接的就是一团 AI 写出来没 review 的代码。