用 AI 做代码审查的完整工作流

AI 做代码审查的价值不是替代 Reviewer，而是帮助开发者在提交前发现低级错误、边界条件遗漏、测试缺口和文档不一致。它尤其适合做第一轮自查：你把 diff、变更目标和测试结果交给 AI，让它从多个维度提出疑点，然后由你验证哪些是真问题。

需要注意的是，AI 很容易给出“看起来合理但无法复现”的问题。如果你不要求它说明代码路径、输入条件和失败结果，它可能会把风格建议包装成严重 bug。因此，这个工作流的核心不是让 AI 多找问题，而是让 AI 找到可验证的问题。

这个工作流解决什么问题

AI 可以帮助开发者在正式提交前发现一些低级错误、边界条件和测试遗漏，但需要正确使用。

适合：

• 提交 PR 前自查
• 修改范围较小但涉及多文件联动
• 新增页面、表单、搜索、数据处理等功能
• 需要补充测试用例
• 想让 AI 从安全、性能、可维护性角度补充视角

不适合：

• 把生产安全责任完全交给 AI
• 不提供上下文，只贴一小段代码
• 让 AI 直接大规模重写代码但不跑测试
• 涉及密钥、用户隐私、内部系统凭据的代码片段

工作流总览

1. 准备 diff 和上下文。
2. 让 AI 理解变更目的。
3. 多维度审查代码。
4. 验证每个问题是否真实。
5. 生成测试建议。
6. 根据确认的问题修复。
7. 再运行测试和构建。

Step 1：准备输入

不要只贴一段代码。最好提供：变更目标、相关文件、调用方式、预期行为和测试结果。

推荐输入：

变更目标：
[说明为什么改]

涉及文件：
[列出文件]

关键 diff：
[粘贴 diff]

预期行为：
[说明用户或系统应该看到什么]

已运行测试：
[例如 npm run build / npm test]

担心的问题：
[例如边界条件、权限、空状态、性能]

Step 2：让 AI 先复述变更目的

在找 bug 前，先让 AI 复述它理解的变更：

请先用 5 条以内总结这次变更的目的、主要代码路径和可能影响范围。暂时不要提出问题。

如果它连变更目标都理解错了，后续审查就会跑偏。

Step 3：多维度审查

要求 AI 从正确性、安全性、性能、可维护性和测试覆盖角度审查。

请从以下维度审查这次代码变更：
1. 正确性：是否存在错误输出、状态不同步、边界条件遗漏
2. 安全性：是否暴露敏感数据、缺少权限校验、存在注入风险
3. 性能：是否有不必要的重复计算或阻塞加载
4. 可维护性：命名、结构、重复逻辑是否会增加维护成本
5. 测试覆盖：哪些场景还没有测试或验证

对每个问题，请给出：
- 问题摘要
- 具体文件或代码路径
- 触发条件
- 可能后果
- 如何验证
- 修复建议

Step 4：验证问题

对 AI 找到的问题，继续追问“请指出具体代码路径和复现条件”。无法说明的问题可以先降级为建议。

可以使用：

请逐条验证你刚才提出的问题。对于每个问题，请说明：
1. 需要什么输入或状态才能触发
2. 实际错误结果是什么
3. 为什么现有代码会导致这个结果
4. 如果无法确定，请标记为“需要人工确认”而不是“必须修复”

这一步能过滤掉大量“合理但不真实”的 AI Review。

Step 5：补充测试

让 AI 为真实问题生成测试用例，再由开发者执行和调整。

测试建议应包含：

• 正常路径
• 空状态
• 错误输入
• 权限边界
• 移动端或无 JS 场景
• 构建和静态资源路径

使用案例：审查搜索页上线改动

场景

你为 Astro 内容站增加了 /search/ 页面，并接入 Pagefind。上线前想确认不会影响静态构建。

输入材料

• 搜索页代码
• Header 中新增的搜索入口
• npm run build 输出
• Pagefind 生成目录

AI 审查重点

AI 应检查路径是否正确、构建后资源是否存在、是否有客户端脚本加载问题、无 JS 时是否有提示。

输出结果

最终应得到一个审查清单：必须修复项、建议优化项、上线前验证路径。

常见失败案例

失败 1：AI 把风格建议当严重 bug

例如：

变量名不够语义化，可能导致系统崩溃。

变量名可能影响可维护性，但通常不是崩溃原因。要求 AI 标记严重程度：blocking、important、minor。

失败 2：AI 没有考虑框架上下文

Astro、React、Vue、Next.js 的运行时边界不同。如果 AI 不知道代码在服务端还是客户端执行，可能会提出错误建议。输入时要说明框架、渲染方式和部署环境。

失败 3：只给修复建议，不给验证方法

一个好的 Review 问题必须能验证。没有复现条件的问题，最好先进入“待确认”，不要直接改代码。

可复制的 Review Prompt

你是一名严格但务实的代码审查员。请审查下面的代码变更。

背景：
[说明功能目标]

技术栈：
[说明框架、运行环境、部署方式]

变更 diff：
[粘贴 diff]

已运行验证：
[粘贴测试或构建结果]

请输出：
1. 你对变更目的的理解
2. 必须修复的问题
3. 建议优化的问题
4. 需要人工确认的问题
5. 建议补充的测试

要求：
- 每个问题必须说明触发条件和错误结果
- 不确定时标记为“需要人工确认”
- 不要只给泛泛的最佳实践
- 不要要求大范围重构，除非确实影响正确性或安全性

人工复核清单

• AI 是否理解了变更目标？
• 每个问题是否有具体触发条件？
• 是否区分了 bug、风险和风格建议？
• 是否需要运行测试验证？
• 修复建议是否可能引入新问题？
• 是否涉及权限、用户数据、支付、删除或发布？
• 是否已经运行构建、测试或手动验证？

AI Code Review 的最佳用法是“先扩大检查视角，再收窄到可验证问题”。不要因为 AI 提了很多问题就全部修改，也不要因为它没发现问题就跳过测试。最终责任仍然在开发者和团队的 Review 流程上。