AI 编程生成的代码如何做 Code Review

AI 编程工具可以很快生成代码，但“能跑”不等于“可以上线”。尤其是独立开发者或小团队，用 Cursor、Claude Code、Copilot 生成代码后，最容易忽略权限、安全、边界条件和长期维护问题。

这篇文章给一套适合 AI 生成代码的 Code Review 清单。目标不是否定 AI 编程，而是让 AI 生成的代码更可控。

快速结论

AI 生成代码最需要检查的不是语法，而是：需求是否理解对、改动范围是否过大、有没有隐藏安全风险、是否引入不必要复杂度、出了问题能不能回滚。

我的建议是：AI 可以写初版，但人必须做 Review，尤其是涉及登录、支付、数据删除、权限、外部 API 和生产配置的代码。

为什么 AI 代码更需要 Review

传统代码 Review 主要看人写的逻辑是否合理。AI 代码 Review 还要额外看：

• AI 是否误解需求
• 是否为了完成任务改了太多文件
• 是否引入不存在的 API
• 是否复制了不符合项目风格的模式
• 是否把临时方案写成长期方案
• 是否遗漏错误处理

AI 很擅长生成“看起来完整”的代码，所以 Review 时不能只看表面。

Review 总清单

第一层：先看改动范围

AI 工具有时会为了修一个小问题，顺手重写很多文件。Review 的第一步不是读代码细节，而是看 diff 范围。

重点检查：

改了哪些文件？
新增了哪些依赖？
有没有删除旧逻辑？
有没有改配置、环境变量、构建脚本？
有没有改数据库 schema？

如果一个小需求改了大量无关文件，建议先让 AI 缩小范围。

第二层：检查安全和权限

AI 生成代码常见安全问题：

• 在前端暴露 API key
• 服务端接口没有鉴权
• 直接信任用户输入
• 文件上传没有限制类型和大小
• 管理员操作没有权限判断
• 日志记录了敏感信息

特别是这类代码，必须人工检查：

登录
支付
用户数据
文件上传
数据库写入
删除操作
第三方 API 密钥

第三层：检查错误处理

AI 很容易只写 happy path。比如 API 成功时页面能显示，但失败、超时、空数据时没有处理。

至少检查：

• 请求失败是否提示用户？
• 是否有重试或降级方案？
• 空数组、null、undefined 是否处理？
• JSON 解析失败怎么办？
• 外部服务限流怎么办？

第四层：检查数据写入

凡是写数据库、写文件、发邮件、创建订单、触发 webhook，都要格外小心。

常见问题：

• 重复提交导致重复写入
• 没有幂等处理
• 删除操作没有确认
• 批量任务没有分页
• 失败后部分成功，数据状态不一致

AI 自动化项目尤其要注意：不要让模型输出直接决定高风险写操作。

一个实用 Review Prompt

你可以让 AI 先自查一遍，但不要只依赖它：

请对这次 diff 做 Code Review。重点检查：
1. 是否改动了需求之外的文件
2. 是否有安全和权限风险
3. 是否有错误处理遗漏
4. 是否有数据重复写入或删除风险
5. 是否新增了不必要依赖
6. 是否有更小范围的实现方式
请按 High / Medium / Low 风险列出问题。

发布前最低标准

对于 AI 生成代码，我建议至少满足：

• 本地构建通过
• 关键页面人工点过一遍
• 没有密钥出现在前端或仓库
• 没有无确认删除操作
• 失败状态有提示
• 重要改动有回滚方式

不适合直接合并的情况

如果出现以下情况，不建议直接合并：

• AI 大规模重写但你看不懂
• 引入新依赖但没有充分理由
• 改了认证、支付、权限但没有测试
• 生成代码依赖不存在的接口
• 只修了表面 bug，没有解释根因

总结

AI 编程可以大幅提高速度，但 Review 标准不能降低。越是 AI 生成的代码，越要检查边界、权限、错误处理和数据影响。

最好的流程是：让 AI 写初版，让 AI 做一次自查，然后由人做最终 Review。这样既能利用速度，又不会把不可控风险直接带到生产环境。

时间成本估算

AI 代码 Review 不一定会拖慢开发，反而能减少返工。一个小改动可以按下面节奏处理：

如果 AI 一次生成了很大的 diff，不要硬看。先让它拆成更小的提交，再逐个检查。