AI 代码审查怎么用？从 PR 检查到测试的实战方法

AI 最适合替代码审查做的，不是给出“LGTM”，而是承担最枯燥、最容易漏的第一轮检查：看 diff、追调用链、列边界条件、比对类型和测试。人则把精力留给架构、业务语义和风险判断。

用得好，AI Code Review 能让每个 PR 的审查更完整；用得不好，它只会生成一长串听起来合理的废话。

先明确：AI 是第一位审查者，不是合并按钮

代码审查真正要回答的是：这次改动是否实现了需求、有没有破坏旧行为、是否足够安全且可维护。AI 可以快速找出可疑点，却不天然知道你的真实业务规则、上线窗口或数据风险。

因此最稳的分工是：

• AI：扫描 diff、搜索相关代码、提出假设、生成检查清单
• 开发者：确认需求、判断风险、审阅安全敏感改动
• 测试与 CI：用可重复的验证证明行为没有退化

给 AI 的输入，决定审查质量

只丢一句“帮我 review”通常效果很差。至少要提供四类上下文：

1. 改动目标：这次 PR 要解决什么，不解决什么。
2. 变更范围：diff、涉及的模块、相关接口。
3. 约束条件：兼容性、性能、权限、数据迁移等要求。
4. 验证方式：已有测试、手动验收步骤和不应被破坏的行为。

例如：

审查这个 PR。目标是新增文章标签筛选，不能改变既有 URL 或排序。重点检查空标签、中文编码、移动端布局和构建产物；按“必须修复 / 建议 / 需确认”输出，并为每项标注文件和原因。

这比泛泛要求“找 bug”更容易得到可执行反馈。

一个可复用的审查流程

1. 先让 AI 复述改动

先问“这个 diff 改了什么、可能影响哪些调用方”。若它连范围都没理解，后面的建议价值有限。

2. 让它找反例，不是找赞美

要求它从空值、重复提交、权限不足、网络失败、并发、旧数据这几个方向构造反例。许多 bug 只会在“正常流程之外”出现。

3. 对关键结论要求证据

每一个问题都应附具体文件、行附近的逻辑、触发条件和可能后果。没有证据的“可能有性能问题”只当作待调查线索。

4. 让 AI 提测试，但不替代测试

让它列出应该补的单元、集成和回归测试；再由 CI 实际执行。AI 生成测试时也要看断言是否真的覆盖了风险，而不是只提高了覆盖率数字。

最值得让 AI 检查的五类问题

• 空值与边界：空数组、超长文本、时区、分页最后一页
• 兼容性：旧 API、旧字段、已有 URL 和缓存数据
• 权限与泄露：是否越权读取、把敏感数据写入日志
• 错误处理：接口失败、重试、部分成功后的状态是否一致
• 重复逻辑：新代码是否绕过现有工具函数或约定

安全方面还应专门检查外部输入和命令拼接；AI 读取 issue、日志或网页时也会遭遇提示词注入，不要把外部文字直接当作可信指令。

常见误区

接受所有建议。 AI 会误报，也会提出不符合项目风格的重构。建议必须回到代码、需求和测试验证。

一次审查整个仓库。 范围太大时，模型容易只给泛泛意见。围绕一个 PR、一个模块或一个风险点审查更有效。

把业务决策交给 AI。 “这个折扣是否合规”“是否应该暴露这个字段”需要业务负责人判断。

只在提交前才用 AI。 在设计和实现过程中早一点让 AI 提风险清单，修复成本更低。

和 AI 编程 Agent 如何配合

像 Claude Code 这样的终端 Agent 能读取 diff、运行测试和搜索调用方。一个实用做法是先让它处于计划或只读模式完成审查，再由开发者明确授权修改；修改后重新审查 diff，形成“实现—验证—复查”的闭环。

总结

AI Code Review 的最佳定位是让审查变得更早、更系统、更可重复。提供清楚的目标和约束，要求具体证据与反例，把建议转化为测试和人工判断。AI 能帮你少漏细节，但真正可靠的合并，仍来自清晰需求、可读 diff 和跑得通的验证。