AI 审查代码，先验依据再改代码

AI 审查把一条问题写得很肯定，甚至标上高优先级，也不代表它真的找到了缺陷。作者给出的判断标准是：先看证据能否复现，再看审查覆盖了哪些代码，最后决定是否修改。只有模型推断的结论，在验证之前都只是待查线索。

这套方法值得程序员花几分钟了解，因为它把「相信 AI 还是不相信 AI」变成了具体操作：重跑检查、核对上下文、记录误报原因。原文没有提供效果对照数据，重点是一套审查流程，而非准确率承诺。

先看证据，再看问题写得有多严重

作者建议先辨认每条发现的证据类别，也就是它到底凭什么成立。

如果依据只有模型的推理，即使描述具体到文件和某一行，也只能当作假设。如果它指出类型检查失败，应该重新执行类型检查；如果声称某个测试失败，就运行那个测试。此时，检查是否失败由工具执行结果决定，不需要模型再投票。

优先级决定先查哪条，证据决定这条是否成立。

这里还有一层区别：检查失败是可观察的事实，但模型对失败原因的解释仍可能需要核实。不能因为它引用了一个真实错误，就连带接受整段推理和修改建议。

原文最后提倡依靠可重复执行的静态检查、动态检查和契约检查。对日常开发而言，可以理解为分别检查代码结构与类型、实际运行行为，以及接口之间约定的输入输出是否一致。

重跑原命令，才能排除过期结论

作者描述的证据项包含可复现命令和进程原始输出。它们让开发者有机会直接检查问题，而不必只读一段自然语言摘要。

具体操作有三步：

1. 执行证据中给出的完整命令。
2. 将本次输出与记录中的原始输出比较。
3. 如果结果不一致，调查上下文变化，并重新运行审查。

为什么强调原命令？因为换一个执行范围或运行条件，得到的可能已经是另一个问题。复现的第一步，是尽量对齐原来的检查方式。

结果不一致，也不能简单认定某一边错了。代码可能在审查后改过，环境也可能不同。作者要求保留这条发现，直到能解释差异。

无法复现的发现，还不能算已确认缺陷，也不能直接判定无害。

原文没有给出具体命令，也没有解释不同项目怎样保证环境一致。因此，这是一条验证原则，具体如何记录依赖、环境与代码状态，还得由团队补齐。

查不到引用，为什么仍不能删文件

另一类容易让人误判的发现，是「没有调用方」或者「这两段代码一样，可以合并」。

作者提醒，审查的判断受限于代码差异（diff）和它解析到的相关上下文。你需要确认，它是否看到了真实定义和调用方，还是只围着局部几行推理。

静态分析可能漏掉动态加载、框架入口和外部消费者。放到前端或 Node 项目里，一个文件没有被直接导入，并不自动证明它没有用途；被框架加载或被其他项目使用的路径，可能没有进入审查视野。同样，文本相同也不能证明两处代码的运行行为可以互换。

确认误报后，作者建议写下原因，例如解析器漏掉了某条调用路径、当前行为符合设计，或者触发条件实际不会出现。这样下次遇到类似提示，就不必从头争论。

验证后的发现分成三类：

• 立即处理：确定性检查失败，而且已经复现。
• 继续观察：推断合理但尚未验证，或相关路径超出了已解析的依赖关系。
• 写明理由后驳回：已确认是误报，或者属于预期行为。

这三类是作者给出的处理框架。审查结果为空，则仍然不足以证明代码正确。

我的判断

我赞同把证据放在措辞和优先级前面。这能让 AI 审查回到程序员熟悉的工作方式：拿到线索，验证条件，再决定修改。

但确定性检查也有边界。一个测试稳定失败，能证明该测试在当前条件下失败；至于测试预期是否合理、是否覆盖真正的业务要求，仍需要人判断。原文也明确说了，审查不能证明正确性。

另一个前提是工具愿意暴露证据。原文提到 Powerduck 会展示发现及其证据，并让开发者自行确认依赖关系。这属于产品能力描述，作者没有提供样例、实测过程或与其他工具的对照数据，不能据此判断它比其他 AI 审查工具更可靠。

和传统人工审查相比，这套流程保留了复现、追踪调用和解释误报的基本功；和直接接受 AI 修改相比，它增加了验证步骤。是否值得投入多少时间，应结合改动影响来判断。涉及公共模块、删除文件或外部接口的发现，尤其需要查清范围。

能拿来做什么

• 在前端或 Node 项目的 AI 审查记录中，要求保留检查命令和原始输出；涉及类型或测试失败的发现，先执行对应检查，再评估修改建议。
• 遇到删除文件、合并重复实现或调整公共模块的建议时，核对真实定义、调用方、动态加载路径和外部消费者，确认审查遗漏了哪些上下文。
• 把尚未复现的问题留在待查列表，并给确认的误报写明原因；不要用「已忽略」替代解释，也不要把没有审查提示当作验收通过。