2026 用 AI 审查代码：一套用九个种子缺陷检验过的 PR 工作流
怎么用 AI 审查代码，诚实的一句话版本：把 AI 当作 diff 的第一道过滤器，对每条发现先对照代码核实再行动，把 AI 稳定漏掉的语义层留给人工审查。这个定位不是为谨慎而谨慎——是我们自己的实测逼着我们这样写的。2026-07-11，我们造了一个埋着九个种子缺陷的 pull request（SQL 注入、硬编码密钥、丢失 await、差一错误、吞掉的异常等等），外加两个诱饵，然后用同一条 prompt 让四个 CLI 编程 Agent 评审。三个找到 9 中之 8 且零编造；一个只找到 9 中之 4，还言之凿凿地报告了两个代码里不存在的缺陷；四个全部漏掉了同一个隐蔽的时区 bug。AI 审查真有用——但它不是合并门。
我们怎么测的（以及你如何复核我们）
fixture 是一个小型 TypeScript 用户服务；PR 的叙事很真实——给它加用户搜索和 CSV 导出。我们在这个 diff 里埋了九个种子缺陷，横跨安全（字符串拼接 SQL、硬编码的仿真实 API 密钥）、正确性（不等待的异步通知、分页差一、未转义的 CSV）、错误处理（吞掉的 catch、泄漏的文件句柄）、隐私（每次搜索都把 PII 打进日志），以及一个刻意隐蔽的案例：混用 UTC 解析和本地时区解析的日期过滤。我们加了两个诱饵——看起来可疑但注释写明是有意为之的代码——用来测误报，然后让四个 CLI 评审工具（Claude Code 2.1.117、codex-cli 0.144.1、cursor-agent 2026.07.09、GitHub Copilot CLI 1.0.70）以只读模式对照一份工具运行前就写好的标准答案台账评分。台账、prompt 和四份原始输出都公开在我们的仓库里；本文每个主张都能追溯到它们。
第 1 步：给评审工具 diff，也给仓库
配置里杠杆最大的一个决定是上下文。只给 diff 会藏住这次改动违反的惯例：我们 fixture 里的分页种子缺陷之所以明显是错的，是因为同一文件里已有函数用了不同的偏移算法——能读整个文件的评审工具会抓住这种不一致，只看见十行 diff 的工具抓不住。把工具指向分支，而不是贴一段代码，并且说明 PR 声称要做什么（我们的是：本 PR 添加用户搜索和 CSV 导出），因为有几类缺陷只有相对这个意图才成立。实测中四个工具在有机会时都读了 diff 之外的代码，最强的三个都用周边代码来支撑自己的发现。
第 2 步：分诊——发现是候选，不是结论
在修任何 AI 报告的问题之前，先打开文件确认主张为真。这条规则来自我们观察到的事实：实测中有一个评审工具报告某个模板字符串未闭合、代码无法解析——那个文件完全合法；它还声称某个查询会因缺参数而运行时失败，而真实问题恰恰相反：查询能正常运行，并且可以被注入。两条发现听起来都具体而自信。一条幻觉发现让你付两次成本——追查它一次，再加上你从此不再给工具真实发现的那份信任。有效的分诊顺序：先核实高危主张（那也是 AI 最准的地方——四个工具全部命中我们全部三个高危种子），机械性修复批量处理，工具对运行行为的任何断言先写个测试验证再相信。
第 3 步：认识共同盲区
实测里最重要的阴性结果：时区缺陷被四个工具中的零个发现。这个种子 bug 混用了 `new Date` 对纯日期字符串的解析（按 UTC）和对时间戳字符串的解析（按本地时区），边界附近的记录会被静默错分。它一点也不冷门——正是那种上线几周后以工单形式浮出水面的 bug。它躲过了所有评审工具，因为发现它需要同时想着两种解析器行为，而这条边界 diff 上没有任何标记。把这一类——横跨隐式边界的隐蔽语义——当作人类领地，并且在 AI 接管机械性检查之后，让你的人工审查把注意力花在这里。
| 审查场景 | 怎么做 | 依据（来自实测） |
|---|---|---|
| 提 PR 前自查 | 请求人工审查前先让 AI 跑你的分支 | 廉价抓住机械性多数——最强工具 9 中之 8 |
| 安全敏感 diff | AI 先过一遍，之后无论报告多干净都做人工安全审查 | 高危是 AI 最强项——但 4/9 的覆盖率也真实存在 |
| 日期、金额、边界逻辑 | 假设 AI 漏了；自己写边界测试 | 时区种子 0/4 全漏 |
| 无法复现的发现 | 修复前要求一个失败用例；它可能是幻觉 | 实测中有两条自信的发现描述的是不存在的代码 |
这套工作流在哪里失效
三条失效边界，直说。第一，不要仅凭一份干净的 AI 审查报告就合并：我们测到的最弱覆盖率是 4/9，意味着一份全绿报告可以和五个活着的缺陷共存，包括那个工具漏掉的整个隐私和错误处理类别。第二，失效模式在语义层的代码——定价规则、日期运算、权限检查——不要让 AI 当唯一评审，因为所有工具都漏掉的那类缺陷恰好住在这里。第三，别把本文当排名：我们测的是 CLI Agent 充当评审器，各跑一次，在一个种子 fixture 上。活在 PR 流程里的 SaaS 审查产品是另一个我们尚未测量的形态，而单次运行没有统计效力。我们的数字有日期、有来源、可复现——但每个仍然只是一次观察。
常见问题
AI 能可靠地审查代码吗？
机械性缺陷可以（但要核实）：我们的种子实测中，最强的三个 CLI 评审工具找到 9 个种子缺陷中的 8 个且零编造，四个工具全部命中三个高危种子。隐蔽语义缺陷不行：我们埋的时区 bug 所有工具都漏了。把 AI 当第一遍，别当唯一一遍。
AI 代码审查会漏什么？
我们的实测里，共同漏检是跨边界语义：混用 UTC 与本地时区解析的日期过滤，四个工具全漏。覆盖较弱的工具还漏掉了 PII 日志、吞错、资源泄漏和 CSV 转义。它们抓得最好的是机械性高危项：注入、硬编码凭证、丢失 await。
AI 审查会编造 bug 吗？
我们这轮里有一个工具编了——两次：报告了一个完全合法文件里的语法错误，和一个不可能发生的运行时失败。较强的三个工具零编造。所以幻觉发现是真实存在但因工具而异的；防御方法都一样——行动前对照代码确认每条发现。
AI 审查应该取代人工审查吗？
不应该——它应该改变人工审查的对象。让 AI 做机械性扫描（它快，而且在高危缺陷上最强），把省下来的人工注意力转投到意图、架构和边界语义——我们实测里 AI 检出率为 0/4 的那一层。
结论：AI 代码审查作为第一道过滤器，值得在 PR 工作流里占一个永久位置——它又快又便宜地抓住了我们埋的大多数缺陷。但它还没赢得不经核实就合并的权利，因为证明其价值的同一场测试，也产出了两条自信的幻觉、4/9 的覆盖率下限，和一个击败所有工具的隐蔽 bug。先让它跑，逐条核实，把人工审查花在机器 0/4 的地方。