AI 代码审查 Prompt：从正确性、安全性和可维护性检查代码

适用场景

适合提交 Pull Request 前自查，也适合在不熟悉代码库时让 AI 辅助理解潜在问题。

Prompt 正文

你是一名严格但建设性的高级代码审查工程师。请审查以下代码变更。

重点关注：
1. 正确性和边界条件
2. 安全风险
3. 性能问题
4. 可维护性
5. 类型和异常处理
6. 测试覆盖缺口

输出格式：
- 严重问题：必须修复
- 一般问题：建议修复
- 可改进项：长期优化
- 测试建议

请只指出真实存在或高度可能的问题，不要泛泛而谈。

代码变更：
[粘贴 diff 或代码]

使用前需要准备什么

代码审查 Prompt 的质量取决于上下文密度。只贴一段代码，AI 容易给出泛泛建议；把变更背景、预期行为和验证结果一起提供，才能更接近真实 Code Review。

建议准备：

材料	为什么重要	示例
变更目标	判断代码是否解决了正确问题	修复登录失败次数未锁定的问题
diff 或相关文件	找到具体风险	粘贴 PR diff，而不是只贴最终函数
预期行为	判断边界条件	连续失败 5 次后锁定 15 分钟
已运行测试	避免重复建议	已运行 npm test，登录模块通过
重点关注	让 AI 聚焦	安全、并发、异常处理、测试遗漏
不希望改的范围	防止建议失控	不改数据库结构，不新增依赖

使用技巧

最好提供上下文：语言、框架、相关调用方、预期行为和测试结果。只贴单个函数时，AI 可能无法判断业务边界。

使用案例：提交前审查登录逻辑

场景

开发者完成了一个登录接口改动，涉及密码校验、错误提示和登录失败次数限制。提交 Pull Request 前，希望先用 AI 找出明显问题。

示例输入

背景：本次改动增加登录失败次数限制，连续失败 5 次后锁定 15 分钟。
关注重点：安全风险、边界条件、测试遗漏。
代码变更：
[粘贴 diff]

AI 应该输出什么

理想输出不是泛泛说“注意安全”，而是指出具体风险，例如：锁定时间是否可绕过、失败次数是否按用户维度记录、错误提示是否泄露账号存在性、是否有并发更新问题。

人工复核重点

AI 找到的问题需要结合真实代码路径确认。无法复现或无法指出具体条件的问题，可以先记录为“待观察建议”，不要直接改动核心逻辑。

输出示例

## 严重问题：必须修复
1. 登录失败次数按 IP 记录，而不是按账号或账号+设备维度记录，可能导致同一 IP 下多个用户互相影响。
2. 错误提示区分“账号不存在”和“密码错误”，存在账号枚举风险。

## 一般问题：建议修复
1. 锁定时间写死在业务函数中，建议提取为配置。
2. 缺少并发请求下失败次数更新的测试。

## 测试建议
- 连续失败 5 次后应锁定。
- 锁定期间正确密码也不能登录。
- 15 分钟后自动解除锁定。
- 不存在账号和密码错误返回一致提示。

这个输出示例展示了好 Code Review 的特点：问题具体、说明影响、给出测试建议，而不是泛泛说“注意安全”。

输入质量对比：只贴代码和提供完整上下文

同一段登录限制逻辑，如果只输入“请审查这段代码”，AI 可能只给出“提取常量、补充注释、增加异常处理”等通用建议。它不知道失败次数按什么维度记录，也无法判断锁定期间的预期行为。

补充下面这些信息后，审查才更容易落到可验证的问题：

变更目标：连续登录失败 5 次后锁定账号 15 分钟。
预期行为：锁定期间即使密码正确也拒绝登录；到期后自动解锁。
代码 diff：[粘贴实际 diff]
相关上下文：失败次数存储结构、登录接口调用方、锁定时间配置。
已运行测试：正常登录和单次密码错误通过；并发失败与自动解锁尚未验证。

此时有价值的输出应指出具体分支、状态或测试缺口，例如“两个并发失败请求是否会覆盖计数”，而不是根据不存在的代码断言一定有并发漏洞。

高质量 Code Review 的密度标准

可以用下面的标准判断 AI 审查结果是否有价值：

维度	低价值输出	高价值输出
问题定位	“可能有安全风险”	指出哪个条件下会账号枚举或锁定绕过
影响说明	“建议优化”	说明会导致用户互相影响、数据不一致或异常未捕获
证据	没有引用代码	引用具体函数、分支、参数或测试缺口
修复建议	“加强校验”	给出最小修改方向和需要补的测试
优先级	所有问题同等重要	区分必须修复、建议修复和长期优化

如果 AI 的输出没有具体条件、文件位置或测试建议，就不要直接作为审查结论。可以追问：

请只保留能指出具体触发条件、影响范围和验证方式的问题。删除泛泛建议。

二次审查 Prompt

请对你刚才的 Code Review 结论做一次反向验证。

要求：
1. 删除无法从代码或上下文支持的问题。
2. 对每个保留问题说明触发条件。
3. 给出最小复现方式或测试建议。
4. 标记哪些只是风格建议，不应阻塞合并。

误报处理与人工验证

AI 的审查结论不能直接等同于 Bug。对每个“必须修复”项，建议按以下顺序复核：

1. 回到实际 diff，确认 AI 引用的函数、分支和参数确实存在。
2. 检查调用方、配置、类型定义和已有防护，避免因为上下文缺失产生误报。
3. 写出最小触发条件，并用单元测试、集成测试或可控环境复现。
4. 无法复现但仍有合理风险时，标记为“待验证”，不要阻塞合并或贸然重构。
5. 涉及认证、支付、权限和用户数据时，由熟悉业务与安全边界的工程师做最终判断。

如果你只需要审查一次变更，可以直接使用本文 Prompt；需要固化团队检查项，可继续配置代码审查 Skill；需要完整的提交前步骤，可参考用 AI 做代码审查的工作流；持续处理仓库上下文和审查任务时，再评估 AI 代码审查 Agent。无论采用哪种方式，都不应上传密钥、生产数据或未经授权的私有代码。