用 AI 做代码评审：别只找语法错误，要检查意图、边界和回归风险

一次合并请求改了三百行代码。AI 很快给出十几条意见：变量名可以更清楚、函数可以再拆、注释可以补充。看起来很勤快，可真正让线上出错的那一行却没被发现：新逻辑把“未付款订单”也算进了可发货列表。

这正是 AI 代码评审最容易制造的错觉：它很擅长发现文本表面的模式，却不天然知道产品规则、历史包袱和这次改动真正要保护什么。高质量评审不是让 AI 挑更多毛病，而是让它沿着意图、数据流、失败路径和证据逐步缩小风险。

先说清评审到底在保护什么

代码评审通常同时承担正确性、安全性、可维护性和知识传播等目标。目标不清时，AI 会把精力花在最容易评论的格式问题上。开始前先告诉它本次改动的业务目标、不能改变的行为、主要风险和不在范围内的内容。

只给差异文件还不够

一段代码是否正确，取决于它被谁调用、输入从哪里来、输出流向哪里，以及系统原来承诺了什么。给 AI 提供合并请求差异时，还应附上相关接口定义、数据结构、关键调用方、测试、配置和简短需求说明。敏感仓库必须使用组织批准的工具，并先去除密钥、客户数据和内部凭证。

关键原则：代码差异告诉 AI“改了什么”，上下文才告诉它“为什么这样改”和“什么绝不能被破坏”。

第一遍先画改动地图

不要一上来就让 AI 找漏洞。先让它列出新增、删除和改变的行为，标记入口、持久化、外部调用、权限检查与错误处理，并指出无法仅凭现有材料确认的地方。这一步能暴露漏看的文件，也能防止后面的评论建立在错误理解上。

例如一个“修改收货地址”的接口，表面只改控制器，实际可能影响订单状态规则、风控校验、配送缓存和审计日志。改动地图应把这些关联写出来，再逐项判断是否真的受到影响。

沿数据流检查正确性

对每个入口追踪输入如何被解析、验证、转换、保存和返回。重点查看空值、重复值、极大或极小值、编码、时区、精度和默认值。AI 可以按变量追踪路径，但它可能漏掉反射、动态配置、框架魔法和运行时注入，因此结论必须回到真实代码验证。

把状态转换写成表

很多严重问题不在单个函数，而在状态之间跳错了。让 AI 枚举“当前状态、操作、允许条件、新状态和副作用”，再与业务规则对照。订单取消后还能发货、任务失败后重复扣款、已删除账号仍可刷新令牌，都是状态约束遗漏的典型结果。

主动寻找失败路径

成功流程最容易写，也最容易被测试覆盖。评审时要追问数据库写入成功但消息发送失败怎么办，第三方超时后重试会不会重复执行，进程在两步之间退出是否留下半完成状态。对每条外部依赖，检查超时、重试、熔断、幂等和补偿，而不是只看有没有捕获异常。

并发问题不能靠“看起来没事”

读取后再写入、先检查再创建、共享缓存更新等逻辑在单线程测试中可能完全正常。要求 AI 明确指出共享资源、事务边界、锁、唯一约束和幂等键，并构造两个请求交错执行的时间线。AI 给出的并发判断只是候选假设，最终应通过数据库约束、压力测试或可重复实验确认。

安全检查要结合信任边界

仅搜索“危险函数”不等于安全评审。先标出用户输入、内部服务、第三方回调和管理员操作的信任边界，再检查认证、授权、注入、路径处理、敏感信息泄露和资源消耗。尤其要区分“已经登录”和“有权操作这个对象”，防止只做身份验证却漏掉对象级权限。

兼容性和数据迁移经常被漏掉

接口字段改名、枚举新增、数据库列改为非空，都可能让旧客户端或历史数据出问题。检查是否需要双读双写、默认值、分阶段发布和回滚兼容。若迁移不可逆，应先备份或影子验证，并说明旧版本服务在发布窗口内如何工作。

不要把“有测试”当成测试充分

AI 可以把改动分支与现有测试对应起来，指出没有覆盖的条件，但测试数量不是答案。好的测试应能在旧实现上失败、在新实现上通过，并验证可观察结果而非内部写法。对关键缺陷，先写一个能复现问题的测试，再讨论修复方案。

一条有用的评审意见长什么样

评论应包含位置、触发条件、可能后果、判断依据和建议验证方式。比如：“当两个相同请求同时通过第 84 行的存在性检查时，都可能进入创建逻辑；当前表没有唯一约束，可能生成重复记录。建议增加并发测试，并由数据库唯一键兜底。”这比“这里可能有竞态，请优化”更容易确认和处理。

给问题分级，别让小建议淹没风险

• 阻断：会导致错误结果、安全问题、数据损坏或无法回滚。
• 重要：在合理条件下造成故障、兼容性下降或明显维护成本。
• 建议：可读性和局部设计改进，不影响本次正确上线。
• 疑问：缺少上下文，需要作者解释，不能伪装成确定缺陷。

识别 AI 的误报和“想象中的代码”

AI 可能评论一个并不存在的调用方，误解框架保证，或建议项目里根本没有的 API。处理每条意见时回到仓库搜索定义和引用，运行对应测试，并让作者确认业务规则。无法定位具体代码或构造触发条件的高风险结论，应标为待验证而不是直接阻断合并。

推荐的三轮评审法

1. 理解：概括需求、改动地图、依赖与未知项，不给修改建议。
2. 挑战：按正确性、安全、并发、兼容和运行保障寻找反例。
3. 验证：把候选问题变成测试、查询、日志或最小复现，再保留有证据的评论。

可直接使用的提示词

“你是代码评审助手。先依据编号需求、验收标准和代码差异说明改动意图，画出入口、数据流、状态变化、外部依赖和信任边界。未知内容标【待确认】，不要假设仓库外的实现。随后分别检查正常、异常、边界、并发、权限、兼容、迁移、可观察性和回滚。每个问题写明文件位置、触发条件、用户或系统后果、证据、置信度和验证方法；把风格建议与行为缺陷分开。”

合并前检查清单

• 实现是否对应明确需求和验收标准？
• 新增行为、删除行为和受影响调用方是否列全？
• 边界、失败、并发和重复请求是否验证？
• 对象级权限和敏感数据处理是否正确？
• 旧客户端、历史数据和回滚是否兼容？
• 关键意见是否有复现证据，而非 AI 猜测？
• 日志、指标和告警能否发现上线后的异常？

AI 能扩大评审者的搜索范围，却不能替代需求判断、系统经验和责任归属。最可靠的用法，是让它持续提出可验证的问题，再由人和工具用代码、测试与运行证据决定哪些问题真实存在。

本文为读懂 AI 原创内容。向 AI 提交代码前，请遵守所在组织的源码、密钥、客户数据和第三方许可政策；高风险系统仍需人工评审、安全测试与正式发布流程。