AI 辅助代码评审实践：从上下文整理到风险清单

一、AI 适合做什么样的代码评审

AI 做代码评审，不应该只当成“自动找 bug”的工具。更合理的定位是辅助阅读、整理上下文、发现遗漏，并把评审者的注意力集中到高风险位置。

适合交给 AI 的任务：

总结本次改动的范围。
找出改动涉及的入口、状态和边界条件。
检查明显的空指针、异常分支和资源释放问题。
对比测试覆盖和行为变更。
生成评审清单。
提醒可能影响兼容性的接口变化。

不适合完全交给 AI 的任务：

判断业务规则是否正确。
决定架构方向。
替代最终代码责任人。
在不了解生产约束时给出结论。

AI 的输出可以作为线索，但不能直接作为评审结论。

二、先给足上下文

很多 AI 评审质量差，不是模型能力问题，而是上下文太少。只贴一段 diff，让它判断完整风险，往往会得到很泛的建议。

更好的输入包括：

这次改动要解决什么问题。
相关模块的职责。
关键接口和数据流。
是否涉及数据库、缓存、消息队列或外部服务。
线上兼容性要求。
已经跑过哪些测试。

示例提示词：

1
2
3

请基于下面的变更做代码评审。
重点关注：行为回归、并发安全、异常处理、数据兼容、测试缺口。
先总结改动范围，再列出高风险问题，不要泛泛建议。

如果上下文很大，可以先让 AI 总结文件职责，再逐段审查关键 diff。

三、让 AI 先复述改动

进入问题列表之前，先让 AI 复述改动范围很有用。它能暴露模型是否真的理解了代码。

需要关注复述里有没有这些问题：

把新增逻辑说成删除逻辑。
忽略关键配置。
混淆调用方和被调用方。
没有提到数据库或状态变化。
把测试代码当成生产逻辑。

如果复述已经不准确，后面的评审结论也不可靠。此时应该补充上下文，或者缩小输入范围重新审查。

四、按风险维度提问

不要只问“这段代码有什么问题”。更有效的方式是按维度拆开。

可以依次检查：

正确性：输入、输出、边界值是否符合预期。
兼容性：旧数据、旧接口、旧客户端是否还能工作。
并发性：重复请求、竞态条件、锁粒度是否合理。
可靠性：异常、超时、重试和降级是否完整。
性能：循环、查询、缓存、批量处理是否有明显风险。
安全性：鉴权、越权、日志脱敏和注入风险。
可测试性：关键路径是否有单元测试或集成测试。

这样得到的反馈更具体，也方便评审者逐项确认。

五、要求它给证据

AI 很容易给出听起来合理但没有依据的判断。评审时应该要求它指出代码位置、触发条件和可能后果。

更好的问题形式：

如果你认为这里有风险，请说明：
1. 风险发生在哪个函数或分支
2. 什么输入或状态会触发
3. 最坏结果是什么
4. 建议如何验证

如果一个问题不能说明触发条件，大概率只是泛化建议。评审者可以降低优先级，不必被长列表牵着走。

六、让 AI 生成测试清单

测试清单通常比修复建议更有价值。因为它能帮助人确认行为，而不是直接接受模型的修改。

可以让 AI 生成：

正常路径用例。
边界输入用例。
异常返回用例。
重复请求用例。
权限不足用例。
旧数据兼容用例。
并发访问用例。

示例：

1 2	请根据这次改动列出必须补充的测试。每条测试包含：场景、输入、期望结果、属于单元测试还是集成测试。

这类输出更容易落到实际工程动作上。

七、不要让 AI 直接大改

AI 可以给补丁建议，但不要在没有理解的情况下直接接受大面积改动。尤其是公共模块、数据迁移、鉴权逻辑和支付相关代码。

更稳的做法：

先让 AI 解释问题。
再让它给最小修复方案。
人确认方案后再改代码。
改完后让 AI 复查新增 diff。
最后跑测试和人工验证。

如果 AI 给出的方案需要改很多无关文件，通常说明问题没有收敛。此时应重新定义目标，而不是继续扩大改动。

八、形成固定模板

团队里可以准备一个固定评审模板，让 AI 输出结构稳定。

示例模板：

请输出：
1. 改动摘要
2. 高风险问题
3. 中低风险问题
4. 测试缺口
5. 需要人工确认的问题

只列和本次 diff 直接相关的问题。
不要输出通用编码建议。

稳定模板的好处是方便比较、归档和复用。评审者也能快速跳过低价值内容。

九、最终责任仍在人

AI 辅助评审的目标不是减少责任，而是提高阅读效率。它能帮你看到一些遗漏，但不能替你理解业务。

最终评审结论应该来自：

对需求的理解。
对系统边界的判断。
对线上风险的经验。
对测试结果的确认。

把 AI 当成一个很快但需要复核的初级评审助手，效果通常最好。它能节省时间，但不能替代工程判断。