夜雨聆风前两周刷到一份学术综述， 72 篇论文的系统分析。结论就一句话： AI 生成的代码里， 78% 存在功能缺陷， 42% 有语法问题。
说实话不意外。
但我不是来骂 AI 写代码不行的。我是想说一个更具体的麻烦：AI 写代码之后， Code Review 这件事的底层逻辑断了。
以前是你写代码、同事审。现在是你和 AI 一起写代码，然后——谁审？
让 AI 审？它能找出 92-96% 的安全漏洞——但说实话， AI 审代码这件事本身就挺离谱的。它审自己写的东西，自信得像刚喝完三杯咖啡，鬼知道它哪来的底气。让同事审？ AI 代码量大得离谱，一天十几个 PR ，谁看得过来。
我过去半年一直在折腾这条线。踩了不少坑——噪音大到同事关通知、漏过线上故障级别的逻辑 Bug 、也被 AI 的"自信幻觉"坑过。后来慢慢摸出一套流程，现在团队 PR 审查时间少了大概一半， Bug 率也没涨。
这套流程就 4 条规则。
规则一：别让 AI 审自己的代码
这是最容易踩的坑。也是最多人踩的。
逻辑简单到不需要论证：同一个模型对「自己生成的输出」天然缺少批判性。你让它写的代码，再让它去审——它大概率会说「看起来不错，没什么大问题」。不是它在敷衍，是它真的看不出。
有个数据很直接：据信通院 2026 年报告，纯 AI 审查的代码质量评分，比「 AI + 人工」混合模式低 15%。反过来，混合模式比纯人工高 22%。也就是说——AI 可以提升 Review 质量，但前提是不能让它独裁。
我的做法是分两层。
第一层，确定性问题用确定性工具。 ESLint 、 Prettier 、 SonarQube 、 Semgrep——格式、复杂度、已知漏洞模式。它们零误报、毫秒级响应。别把 AI 的 Token 浪费在这些东西上。
第二层，语义问题才交给 AI 。 但前提是：不用生成代码的那个 AI 。如果我用 Claude Code 写， Code Review 就用 Cursor 的 Agent 。反之亦然。不同模型、不同上下文窗口，至少能打破「自己审自己」的回音壁。
这不是什么高深理论。就是「你别自己检查自己的作业」。
规则二：把 Review 塞进 IDE ，别等 PR
传统 Code Review 是滞后环节——代码写完、提交 PR 、等同事看。 AI 时代这个流程可以且应该反过来。
阿里内部的 AI Code Review 团队有个概念叫「 CR 左移」——评审不是在 PR 提交后才发生的，而是 IDE 里、在每次提交前、随时随地。我觉得这是 AI 时代 Code Review 最值钱的一个思路。
我的做法是用 Cursor Rules 搭一个本地审查流程。一个 .cursor/rules/code-review.mdc 文件，每次让 AI 审查代码时它都走这套标准：
搭配 Git 提交前自动审查——commit 之前扫一遍硬编码密钥、大文件提交、未格式化的代码。
好处很简单：问题在 IDE 里就发现了，成本比在 PR 阶段发现低一个数量级。
规则三：给 AI 的意见设置信度门槛
这条是我被 AI 噪音折磨了三个月之后才想通的。
一开始接入 AI Code Review （用的 CodeRabbit ）， PR 下面密密麻麻全是评论。「这里可以加个类型注解」「变量名建议改成 xxx 」——每一条都正确，但没有一条值得打断我的工作。就是那种「你说得都对但我真不想听」的烦。
同事开始无视 AI 评论，甚至直接关掉通知。这就完全违背初衷了。
后来我在 Pipeline 里加了一个硬约束：置信度低于 0.7 的建议不发布为行内评论，只汇总成 PR Summary 里的一条「参考意见」。
同时分级：
- Critical：安全漏洞、密钥泄露 → 红色行内评论，阻断合并
- Warning：性能退化、逻辑可疑 → 黄色折叠
- Suggestion：风格、命名 → 汇总到 Summary ，不逐行骚扰
这个操作效果怎么样？ AI 评论数量少了 60%，但 acceptance rate （开发者接受并修改的比例）从 30% 涨到了接近 70%。
信通院报告里还有个数据： AI 代码风格一致性准确率接近 99%。也就是说风格类建议 AI 几乎不出错，但也最容易让人烦。不让风格建议占用行内评论，是保护开发者对 AI 信任的最简单方法。
少说话。但说对的话。
就这么简单的道理，我感觉很多 AI Review 工具到现在也没整明白。
规则四：人类只盯 20% 的关键决策
纯 AI 审查比混合模式低 15%。差在哪儿？
不是语法。不是安全（ AI 检出率 92-96%）。是业务逻辑正确性和架构合理性。
AI 能告诉你「这段代码不会崩」，但它不知道「这段代码做的是不是用户真正需要的」。
我现在的分工很简单：
| AI 负责啥 | 人负责啥 |
|---|---|
| 安全漏洞（ SQL 注入、 XSS 、硬编码密钥） | 业务逻辑是否正确 |
| 代码风格和规范一致性 | 架构设计是否合理 |
| 性能退化（ N+1 查询、内存泄漏） | 这个 PR 有没有「做对的事」 |
| 依赖风险检测 | 非常规但优秀的实现（ AI 可能当异常） |
实际操作下来， AI 覆盖了大概 80% 的检查项。审查总时间能缩短 70%，缺陷逃逸率降低 35%。剩下那 20%，是人要花脑子的地方。
换个角度想：以前 Code Review 是「人花 45 分钟看 1000 行代码找 Bug 」。现在是「 AI 花 15 秒扫一遍，人花 10 分钟判断业务逻辑和架构」。
不是人被取代了。是人终于能干该干的事了。
写到这，有个东西觉得必须讲清楚。
上面说的「缺陷逃逸率降低 35%」——不是「消灭了 35% 的缺陷」。还是有 Bug 会漏到线上。而且 AI 会引入一种全新的风险：你开始过于信任它，然后不再仔细读代码。
我见过最危险的一个案例：同事的 PR 里有一段 AI 生成的代码，调了一个已经 deprecated 的 API 。 AI Code Review 没发现——因为模型训练的时候那个 API 还活着。人类也跳过了——因为「 AI 已经审过了」。
代码发到线上，直接崩了。
AI Review 最大的风险不是它会犯错。是它会让你以为不需要自己看了。
所以这条不叫规则，叫习惯：每当你发现自己想说「 AI 审过了，应该没问题」的时候——停，别躺。强迫自己读至少两段代码。不是扫一眼，是像以前没有 AI 工具时那样——一行一行看。
这套流程用了半年， PR 审查时间少了大概一半，没出过大的线上事故。但说它完美吗？扯淡。有些东西到现在我也没解决——AI 跨语言代码库（ React + Go ）的 Review 质量直接摆烂，某些业务逻辑连我自己都说不清该怎么审，更别提 AI 。
但至少 PR 质量没有因为 AI 的加入而失控。反过来，因为加了门槛， AI 变成了一块还不错的安全网——该挡住的挡住了，不该骚扰的闭嘴了。
说真的，可能三个月后又得改。
但这就是此时此刻，我觉得最靠谱的做法。