AI 代码审查有多准（2026）：我们埋了 9 个缺陷——四个工具找到、漏掉和编造了什么
AI 代码审查到底有多准？2026-07-11 我们用唯一能产出可查数字的方式测了一次：在一个真实感的 pull request 里埋九个已知缺陷加两个诱饵，在任何工具运行之前写好标准答案台账，然后让四个 CLI 评审工具在只读模式下接收完全相同的 prompt。结果把准确率问题拆成了三种不同的风险。检出：Claude Code、Codex、Cursor 各找到 8/9；GitHub Copilot CLI 找到 4/9。编造：较强的三个工具零编造；Copilot CLI 报告了两个代码里不存在的缺陷。还有一个共同盲区：最隐蔽的种子——混用时区的日期过滤——四个工具全部漏掉。而人人担心的那种吹毛求疵式误报，几乎没有出现。
方法：先写标准答案，再跑工具
fixture 是一个 TypeScript 用户服务；PR 添加用户搜索和 CSV 导出。九个种子横跨安全、正确性、错误处理、隐私，以及一个刻意隐蔽的语义案例。两个诱饵是看起来有问题但注释写明有意为之的代码——一个是分页稳定性要求的顺序 await 循环，一个是防御性整数强转——专门用来测误报。评分规则在运行前就冻结在台账里：定位正确且归因正确才算发现；标记诱饵计一次误报，除非工具给出的是实质性正确性论证而非风格抱怨；工具在种子之外报告的任何问题都做人工复核，属实则记为额外发现，而不是事后改动 9 这个分母。评审工具：Claude Code 2.1.117、codex-cli 0.144.1、cursor-agent 2026.07.09、GitHub Copilot CLI 1.0.70——各一次运行、同一 prompt、只读。
分工具结果
| 评审工具（版本） | 种子缺陷检出 | 高危命中（共 3） | 幻觉发现 | 复核为真的额外缺陷 | 评审耗时 |
|---|---|---|---|---|---|
| Claude Code 2.1.117 | 8/9 | 3/3 | 0 | 2 | 71 秒 |
| codex-cli 0.144.1 | 8/9 | 3/3 | 0 | 6 | 595 秒 |
| cursor-agent 2026.07.09 | 8/9 | 3/3 | 0 | 3 | 43 秒 |
| GitHub Copilot CLI 1.0.70 | 4/9 | 3/3 | 2 | 0 | 41 秒 |
两条幻觉，具体看
两条编造的发现来自同一次运行，而且都显得很严谨。第一条声称搜索查询会因为没有传参数数组而运行时失败——实际上查询能正常运行，因为值是直接拼进 SQL 字符串的，而这恰恰就是同一个工具早一条发现里（正确地）报告过的注入缺陷。归因错误、位置重复、以事实口吻陈述。第二条声称某个模板字符串未闭合、文件无法解析；那个文件是合法的 TypeScript，其他三个工具都正常读完没有异议——该评审工具看起来是把 diff 的渲染看错了。这就是幻觉发现这种失效模式的签名：具体的行号、自信的严重度标签、貌似合理的机理、不存在的缺陷。它比含糊的警告更危险，因为它经得起粗读。防御是流程性的，不是技术性的：任何发现在有人对照代码复现之前，不得进入修复。
四个工具都漏掉的那个缺陷
日期过滤种子混用了两种解析行为：纯日期字符串按 UTC 零点解析，而记录的时间戳字符串按本地时区解析，边界附近的行会被静默错分。没有工具标记它——花了几分钟读仓库的两个没有，一分钟内答完的两个也没有。这个模式可以推广：四个工具全部命中的每个种子，都能从改动行本身看出来；无一命中的那个种子，需要知道某个 API 在一条 diff 从不标记的边界两侧的隐式行为。如果你维护的代码里日期、金额或权限会跨边界，这类缺陷仍然归你。台账另一侧的两条诚实备注：我们的诱饵没骗到任何工具（它们引来的标记是实质性正确性论证，按规则不计误报）；而四个工具中有三个独立发现了一个我们并未刻意埋设的真实分页语义 bug——经我们复核为真，作为第十个、被发现的缺陷记录在案。AI 审查能找到作者自己都不知道的真问题，同时漏掉资深评审会用红笔圈出的那一个。
范围与限制
这份数据是什么：一次受控的、标准答案先行的测量，对象是四个充当 PR 评审器的 CLI 编程 Agent，所有原始输出公开。它不是什么：代码审查产品排名。我们没有测活在 pull request 流程里的 SaaS 审查机器人；同一工具的 CLI 形态和 PR 集成产品可能行为不同；这里每个数字都是一次运行——重跑可能改变任何一格。我们公开 fixture 设计、prompt 和台账，正是为了让这些数字可以被挑战；而它既已公开，本 fixture 即从后续轮次退役。
常见问题
AI 代码审查有多准？
在我们 2026-07-11 的种子实测中：最强的三个 CLI 评审工具检出 8/9，最弱的 4/9；高危缺陷四个工具都是 3/3；最隐蔽的语义种子 0/4。准确率不是一个数字——检出、编造和盲区是独立变化的。
AI 代码审查里的幻觉发现是什么？
一条被自信报告但并不存在的缺陷——我们这轮里是：声称合法文件有语法错误、声称会发生一个不可能发生的运行时失败。它和吹毛求疵式误报不同：不是对真实代码的过度反应，而是对想象代码的描述。修复之前先复现。
AI 评审最擅长抓哪类 bug？
改动行里可见的机械性缺陷：SQL 注入、硬编码凭证、丢失 await、口径不一致的分页计算、被吞掉的错误。我们三个高危种子被四个工具全部命中。漏检模式正好相反：横跨隐式边界的语义。
怎么减少 AI 代码审查的误报？
把意图写进代码：我们的两个诱饵都带着解释「为什么这个可疑写法是有意的」的注释，结果没有工具对它们提出风格抱怨。然后对每条发现执行「先复现再修复」——在分诊阶段过滤幻觉，而不是在你的 diff 里。
结论：准确率的真相比怀疑者说的好，比 demo 暗示的差。在一个种子 PR 上，强工具几乎抓全了机械性缺陷、零编造，甚至挖出了一个我们没埋的真 bug——而最弱的那次运行漏掉了超过一半的种子还编造了两条发现，且所有工具都从同一个语义缺陷旁边走了过去。用这样的数据选评审工具，然后把它放进一个假设这两种失效都存在的工作流里。