AI 写的代码，你敢直接合并吗？代码评审从看 diff 到看证据

AI 写代码越来越快，难点换了位置：代码生成出来之后，敢不敢把它合进主分支。能跑通和能上线是两回事，中间隔着的就是代码评审。这篇讲为什么只看 git diff 撑不起这一关，以及把评审改成"先收证据、再下结论"之后，流程上具体变了什么。

改动不大，不等于影响不大

评审会上最常听到的一句话是："我看了这几个文件，改动不大，应该没问题。"

问题在于，文件的改动范围和它实际产生的行为影响往往不一致。diff 只告诉你哪几行变了，不告诉你这几行会被谁调用、在什么条件下执行。几类常见情况：

• 一处改动，多个入口。 被改的是一个公共方法，调用它的接口、定时任务、消息消费者都会受影响，而这些调用方一个都不在 diff 里。
• 新增参数，旧行为变了。 给函数加一个带默认值的参数，新调用方用得很好，老调用方的默认行为却被悄悄改掉了。
• 异常分支平时不出现。 超时、重试、幂等、部分失败，这些路径只在特定条件下才走到，正常的手工验证覆盖不到。
• 有测试文件，不等于改动被测到。 项目里有 test 目录，但这次改动的生产代码未必真有用例覆盖。

AI 生成的代码会放大这些问题：写得快、改得多，评审者更容易只扫一眼 diff 就放行。

从看 diff 到看证据

证据化评审的思路是：先把判断需要的事实收齐，再让人或 Agent 下结论。事实不是"这几行改了什么"，而是：

1. 改到了哪些符号和行为：方法、类、接口，而不只是文件。
2. 哪些入口会被波及：顺着调用链往上找到接口、页面、任务。
3. 老调用方会不会出问题：参数、返回值、默认行为是否变化。
4. 非功能风险：关键链路有没有超时处理和重试，幂等是否成立，有没有部分失败或回滚风险。
5. 测试是否真的覆盖：被改的生产符号有没有测试用例打到，而不是 test 目录下跑过一些东西就算数。

最后把发现分成两类：必须修复的问题，和风格层面的建议。前者阻断合并，后者可以留到之后。

codexqa-code-reviewer 是怎么做的

codexqa-code-reviewer 是 OpenQA 开源技能包里的证据化代码评审技能，可以在 Cursor、Claude Code、Codex、OpenClaw 这类 Agent 编程环境里使用。它的流程围绕代码符号图展开，而不是文本对比：

1. 根据分支或 PR 建立代码符号图，弄清谁定义、谁调用。
2. 生成评审证据包：变更的符号、调用方、入口路径、影响面和测试边界。
3. 让 Agent 基于证据包做语义判断，比如业务逻辑对不对、并发和韧性够不够。Semgrep、Bandit、gosec、gitleaks、OSV-Scanner 这类确定性工具可以作为辅助信号，但不当最终裁决。
4. 输出一份可以直接打开、转发、存档的双语 REVIEW-REPORT.html，以及一份结构化的结论文件，方便其他系统校验和后续处理。

报告不是一个总分。每条发现都写明失败场景、证据所在的行号、调用链、风险等级、修复建议，以及回归时必须跑的路径。

安装：

npx skills add openqa-cn/codexqa --skill codexqa-code-reviewer

运行环境需要 Node.js 18+、bash、jq 和 Python 3.10+。

证据不全，就不出报告

这个技能有一条硬规则：生成报告之前，先封存所有结论并做一次完整校验；如果证据链不完整，就直接报错，不生成报告。代码身份无法确认、没有 diff、证据包缺项，都属于这种情况。

它也不给项目打分。分析不了的地方标成"未知"，而不是用一个看起来很确定的等级掩盖过去。宁可阻塞，也不给一份不可靠的结论。

它不做什么

• 不自动合并。 上线决策仍然由人来做。
• 不替代测试执行。 它收集的是测试覆盖的证据，不是跑测试本身。
• 不是 SAST 扫描器。 漏洞和密钥扫描交给专门的技能，比如 codexqa-defect-analyzer。
• 动态调用看不准。 反射、动态分发、跨语言 FFI 这类情况，调用图无法做到精确。

怎么开始

找一个比较小的真实 PR，装上技能跑一遍，打开生成的 REVIEW-REPORT.html，看它梳理出的调用链和测试缺口，再和你自己的人工评审意见对照。差异最大的地方，通常就是平时评审最容易漏掉的地方。

AI 参与写代码之后，评审这件事要有证据、有流程、有工具把关。流程是强制的：先收集证据再判断，先搞清影响范围再看具体改动，先确认测试覆盖再说没问题。