怎样让 AI 做代码审查：先找 Bug、回归和缺测试

代码审查先找行为风险

第一轮优先寻找 Bug、回归、数据损坏、安全边界和缺失测试，再讨论命名与风格。每条发现都要说明触发条件、影响和具体位置。

理解变更意图

读取 issue、PR 说明、规则和 diff，确认旧行为、目标行为和范围外，不从单个文件猜全局。

把涉及的文件、目录、版本、命令和实际输出写进记录；代码变化同时保留 diff 与测试结果。

沿关键路径检查

追输入、权限、状态、错误、数据写入和外部副作用，关注边界和失败路径。

确认“沿关键路径检查”已经有可回查结果，再进入“验证兼容与迁移”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

验证兼容与迁移

检查接口、配置、数据库、缓存、客户端和回滚是否同步，寻找单点改动引发的不一致。

确认“验证兼容与迁移”已经有可回查结果，再进入“检查测试是否有效”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

检查测试是否有效

测试应能在旧错误下失败，覆盖高风险分支；只增加覆盖率但无断言不算。

确认“检查测试是否有效”已经有可回查结果，再进入“按严重度写发现”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

按严重度写发现

先给位置和结论，再给触发、影响与修复方向；不确定项标问题，不宣称已证实。

需要修改时先限定文件和行为范围，无法说明回滚方式或影响面的动作先不执行。 完成后把证据归入“按严重度排序的审查清单”。

没有发现也要说明测试缺口

审查结论区分已证实问题、开放问题和残余风险。风格建议不与真实 Bug 混在同一优先级。