AI 生成代码审查清单：如何看 Diff、找风险并验证结果

先明确审查目标

AI Code Review 的第一步不是挑代码风格，而是判断“这次改动能不能安全进入项目”。你要先看结果、范围和风险，再进入实现细节。

确认 AI 是否真的解决了原始需求，而不是只生成了看似合理的代码。

确认改动范围是否收敛，避免小需求牵动共享模块、权限逻辑或核心流程。

确认安全、边界状态、测试和回滚方式清楚，降低 AI 代码进入生产的风险。

四层审查清单

需求一致性

这次改动是否解决了原始问题？

是否有遗漏的用户场景
是否偷偷改变了需求范围
是否把临时假设写成了正式逻辑

改动范围

AI 改了哪些文件，为什么要改？

文件数量是否异常
共享组件是否被过度修改
是否修改了无关配置、依赖或格式化结果

边界状态

正常流程之外的情况是否处理了？

空数据、加载中、错误状态
权限不足、重复点击、接口超时
移动端、长文本、多语言或极端输入

安全与数据

是否引入了权限、隐私或密钥风险？

API Key 是否暴露到前端
用户输入是否进入危险操作
服务端校验是否被绕过或删除

如何看 diff

Step 01

先看文件列表

判断 AI 是否只修改了和需求相关的文件。小需求如果改了路由、鉴权、数据库 schema 或全局状态，要先停下来追问原因。

Step 02

再看每个文件的修改目的

要求 AI 用一句话解释每个文件为什么需要改。解释不清的文件，优先回滚或单独拆出来人工确认。

Step 03

最后看实现细节

确认变量、分支、异常处理、接口字段和 UI 状态是否对应需求。不要一开始就陷入代码风格，先判断行为是否正确。

测试优先级

高风险改动必须运行自动化测试。没有测试时，至少写出手动验证步骤，并明确哪些路径没有覆盖。

必须测试

登录、支付、权限、数据写入
删除、发布、审批等不可逆动作
影响已有核心路径的共享逻辑

建议测试

表单校验和错误提示
接口字段映射
新增页面或新组件的主要交互

手动确认

静态文案
样式微调
不影响数据和权限的布局优化

需要立刻停下来的风险信号

AI 修改了和需求无关的大量文件，且无法解释每个文件的目的。
AI 删除了权限校验、参数校验、错误处理或日志记录。
AI 把 API Key、Token、客户数据或内部接口地址暴露到前端代码、截图或日志中。
AI 为了通过类型检查使用了 any、空 catch、硬编码 mock 数据或直接跳过校验。
AI 没有给出验证步骤，却声称功能已经完成。

可直接使用的审查 Prompt

请总结这次改动影响了哪些文件，每个文件为什么需要改。不要解释代码细节，先解释业务目的。

请指出这次改动可能破坏的已有功能，并按风险从高到低列出验证步骤。

请检查这段 diff 是否存在权限、安全、空状态、错误状态、重复点击或移动端适配遗漏。

请用产品经理能理解的语言解释这次 diff 的业务影响，并说明哪些地方需要开发者人工确认。

请把这次改动拆成：必须测试、建议测试、可以手动确认三类，并说明每类的验证方式。

常见问题

AI 生成的代码一定要人工审查吗？

需要。AI 可以快速生成候选方案，但它不知道团队的真实约束、历史 bug、权限边界和生产风险。越接近核心流程，越不能跳过人工审查。

产品经理不懂代码，怎么参与 AI Code Review？

产品经理可以先审查需求是否被正确实现、页面状态是否完整、用户路径是否被破坏，再让开发者确认实现方式、测试覆盖和安全细节。

AI 代码审查最容易漏掉什么？

常见遗漏包括权限不足、空数据、接口错误、重复提交、移动端长文本、密钥暴露、服务端校验被绕过，以及小需求引入大范围改动。

什么时候必须补测试？

只要涉及登录、支付、权限、数据写入、删除、发布、审批或共享业务逻辑，就应优先补自动化测试；没有测试时至少写清手动验证步骤。

如果 AI 改了很多无关文件怎么办？

先暂停合并，让 AI 解释每个文件的修改目的。解释不清的文件不要保留，必要时把需求拆小，重新让 AI 只处理一个明确范围。

审查 Cursor、Codex、Antigravity 生成的代码有区别吗？

工具界面不同，但审查原则相同：先看需求和范围，再看 diff 和风险，最后看测试与验证。不要因为工具能自动执行就降低审查标准。

AI 生成代码审查清单