别把IDE能抓的错扔给Reviewer

PR 量暴涨、DORA 稳定性下滑——20% AI 幻觉可在本地消灭，别浪费 reviewer 带宽

如果你读过《Generated Code is Real Code》，那篇讲的是 merge 责任永远在人手里。

JetBrains 2026 年 5 月又发了一篇更「刺」的续篇：

Stop Sending IDE-Catchable AI Code Errors to Review（别把 IDE 能抓的错误扔给 reviewer）

核心论点一句话：reviewer 的判断力是有限资源。 每一个本该在 IDE 里消灭的结构错误，到了 PR 里都在消耗它。

AI 把写码速度抬上去了，但 review 带宽没跟着涨。这篇按 JetBrains 博文 与多篇 2025–2026 实证研究，拆三件事：

1. 为什么 PR 洪水正在压垮 review

2. AI 代码带来了什么新缺陷画像

3. 个人和团队该怎么把错误拦在 PR 之前

一、产量上去了，review 的人还是同一批

1. 治理现状：各用各的，上面不管

JetBrains 2025 开发者生态调查（样本 24,000+ 开发者）显示：多数团队对 AI 工具的使用仍是 ad hoc——开发者按自己习惯用，组织层治理很少。

这意味着：PR 变多、变大的趋势，往往先于流程改造发生。

2. 数据：重度 AI 用户 merge 更多 PR

翻译成人话：同样一班 reviewer，每天要做的决策更多了。

3. 老问题被重新点亮：赶工 = 漏检

早在 AI 写码流行之前，PSP 研究数据 就表明：review 速率 是影响缺陷检出率的显著因素——控制开发者能力之后，每行 review 时间越少，检出的缺陷越少。

技能再好，也补不了「赶」。

AI 工具理论上该帮忙缩小「reviewer 看到什么」和「reviewer 需要知道什么」之间的鸿沟——但多项 2024–2025 研究显示：鸿沟还在，甚至变宽了。

二、Code Review 是决策过程，AI 只是加了更多决策

Review 工具有用，但负担未必减轻

几个常被引用的反直觉数据：

AI review bot 能扫掉一部分低垂果实，但 「评论多了」≠「负担轻了」。

人类 reviewer 仍然要回答：这段改动在整库上下文里意味着什么？ 这是 AI 辅助写码放大、而非自动解决的问题。

三、AI 送来的是另一种代码

1. 缺陷画像变了

2025 年 50 万+ 代码样本分析 指出，AI 生成代码的错误分布与人类不同：

• 未使用构造 更常见

• 硬编码值 更常见

• 高风险安全漏洞 出现频率更高

另一项 2025 研究 还识别出 人类代码里几乎没有对应类别 的缺陷类型——不是「多一点 typo」，而是 新的错误模式。

2. 更糟的是：reviewer 对 AI PR 更「宽容」

2026 年 1 月研究 发现一个盲点：AI 生成的 PR 含有 近两倍代码冗余，reviewer 的 负面反应反而更少。

表面看起来「像那么回事」，就会降低批判性审视——体积更大、 scrutiny 更少，是危险的组合。

3. DORA：采纳率上去，稳定性下来

DORA 2025 Gen AI 报告 给出趋势信号：

AI 采纳率每增加 25%，交付稳定性约下降 7.2%。

部分归因于 更大的 changeset：生成更多代码 → 单次 PR 更大 → 历史上「大批量」一直预测更高不稳定性。

Size 是信号；缺陷画像和审查松懈，解释了信号背后可能是什么。

四、机器能抓的，就让机器在本地抓

约 20%–25% 的 AI 幻觉，静态分析可拦截

同一批 hallucination 研究 估计：大约 20%–25% 的 AI 代码幻觉，可通过 自动化结构与静态分析 在写码环境中检出——开 PR 之前。

不需要新治理框架，不需要多一层流程会议。IDE 里跑起来就行。

反过来看：研究还指出约 44% 的幻觉 没有任何自动化检查能可靠发现——这已经足够占满 reviewer 的注意力了。

结论很硬：把机器能拦的拦掉，把人的带宽留给机器拦不住的。

大厂怎么做：组织级前置验证

个人 IDE 检查之外，成熟团队会在 pipeline 上游 做制度化投入：

共同点：不是指望 reviewer 硬扛产量，而是把可自动化的筛选前移。

五、IDE 是质量变量，不是个人偏好

1. 人均 3.6 个开发环境

2025 Stack Overflow 调查 显示开发者平均使用 3.6 个 开发环境——通常由个人按语言和习惯自选。

对个人来说，单一语言 + 配置良好的近似检查可能「感觉够用」。

对组织来说：团队检查质量的上限 = 最弱的那套环境。 多人、多语言、多 AI 工具并行时，「语言级近似」和「全库深度结构模型」的差距会被放大。

2. 「No-excuses」结构分析放哪一层？

JetBrains 的划分值得记：

写码时（IDE 深度结构模型）

↓ 同一套规则

CI/CD（如 Qodana 等静态分析）

↓

人类 Reviewer（架构、业务、安全、可维护性）

IDE 层：任何进入编辑器的代码——无论哪个 AI 工具生成——都对齐全库结构模型检查。

Pipeline 层：把同一深度延伸到 merge 门禁，防止「我本地没开检查」的漏网之鱼。

这和《Generated Code is Real Code》里的 四层责任链 第 2 层完全对齐：

Agent 生成 → IDE 检查/静态分析 → 本地测试 → 再开 PR

merge 负责人不是垃圾回收站。

六、可复现：开 PR 前的 6 步门禁

不绑定特定厂商，任何团队都能落地的最小流程：

Step 1：Agent 产出后先 diff，不急着 push

git diff --stat

git diff

目标：确认 改了什么、改了多少文件——巨型 AI dump PR 直接拆小。

Step 2：IDE / 语言服务器清红线

• 类型错误、未解析引用、未使用 import

• 明显 dead code、不可达分支

原则：带着红线不开 PR。

Step 3：跑项目级静态分析

按栈选工具（示例）：

IDE 检查 + SpotBugs / Qodana

Step 4：跑最小相关测试

npm test -- --testPathPattern=changed-module

pytest tests/path/to/related/

Addy Osmani 的铁律在这里生效：你没亲眼看到它做对，就不算 work。

Step 5：PR 描述写清 Proof + AI role

沿用 PR Contract 四要素（详见 merge 责任文）：

1. What/Why

2. Proof it works（命令、日志、截图）

3. Risk + 哪些行是 AI 生成

4. 希望 reviewer 重点看什么

Step 6：自检「这类错 reviewer 该不该看？」

开 PR 前问自己：

凡是左列的，别扔给右列。

七、给 Tech Lead 的三条组织规则

个人习惯解决不了产量问题，需要团队共识：

1. PR 尺寸门禁

• 单 PR 行数上限（如 400 行，AI 辅助场景宜更严）

• 超限必须拆分或写 例外说明

2. 「No red code」合入标准

与 JetBrains「真实代码」标准一致：合入前主分支构建 不应处于损坏状态——包括 IDE 可抓的结构错误。

3. Reviewer 时间预算可见化

跟踪 每周人均 review 时长 vs merge PR 数。若 PR 数 +60% 而 review 时长不变，漏检率上升是数学必然，不是态度问题。

八、和本系列怎么衔接

一句话收束：

AI 提高了代码产量；IDE 和静态分析负责把低价值错误挡在 PR 外；reviewer 的判断力，只留给真正需要人的问题。

Generated code is real code——所以 real code 的红线，也请在 real IDE 里先清掉。

参考与延伸阅读

• JetBrains：Stop Sending IDE-Catchable AI Code Errors to Review（2026-05）

• JetBrains：Generated Code is Real Code — 合入责任链

• DORA：Gen AI Report

• DX：AI-Assisted Engineering Q4 Impact Report

• Addy Osmani：Code Review in the Age of AI

• 本号已发：《Generated Code is Real Code：AI 代码谁负责 merge？》

数字均标注来源与样本背景，宜作趋势参考；具体阈值请按团队栈与风险等级调整。