AI 代码审查清单：把生成结果变成可合并变更

AI 工具已经可以很快生成一个功能、修复一个问题，甚至顺手补上测试。但在真实项目里，“能生成”不等于“能合并”。代码进入主干之前，仍然需要经过可读性、边界条件、兼容性、测试和运维风险的检查。

更实用的做法，是把 AI 生成代码后的审查过程固定成一张清单。这样每次变更都能从“看起来能跑”推进到“可以被团队维护”，也能减少人工 review 时反复追问上下文的成本。

一、先看任务边界有没有被守住

AI 参与开发时，最常见的问题不是代码完全不可用，而是改动范围悄悄扩大。

一次普通 bug 修复，可能顺手改了命名、重排了目录、升级了依赖、格式化了整份文件。功能本身也许能跑，但 review 成本会迅速上升，因为审查者必须同时判断“业务修复是否正确”和“这些额外改动是否安全”。

审查时可以先问几个问题：

本次改动是否只覆盖需求要求的文件和模块。
是否存在和任务无关的格式化、重命名、抽象提取。
是否引入了新的依赖、脚本或配置。
是否修改了公共接口、数据库结构、权限或构建流程。
是否保留了用户或同事已有的未提交改动。

如果边界已经失控，优先拆分变更。把核心修复留下，把风格调整、重构和依赖升级移到单独任务里，后续 review 会更干净。

二、检查业务路径而不是只看语法

AI 很容易写出语法正确的代码，但业务正确性需要结合上下文判断。

例如一个订单状态流转，代码里可能只判断了 PAID 和 CANCELED，却漏掉 REFUNDING；一个 Android 页面可能能正常加载列表，却没有处理旋转屏幕后状态恢复；一个 Linux 服务脚本可能能启动进程，但没有考虑工作目录、环境变量和日志路径。

业务路径审查可以按“输入、状态、输出”拆开：

输入：参数是否校验，空值、非法值、重复请求是否处理。
状态：状态机是否完整，失败后是否能恢复，是否有并发竞争。
输出：返回值、错误码、日志和 UI 状态是否符合调用方预期。
副作用：数据库、缓存、文件、消息队列是否会产生不可逆影响。
兼容性：旧数据、旧客户端、旧配置是否还能继续工作。

这一步不要只依赖 AI 的解释。解释可以帮助理解意图，但最终仍然要回到代码路径、调用链和已有测试。

三、把异常路径当成第一等公民

很多生成代码只覆盖了“阳光路径”：接口成功、权限存在、文件可读、网络稳定、线程没有竞争。一旦进入真实环境，异常路径才是稳定性的关键。

以一个下载任务为例，至少要考虑：

网络中断后是否重试或明确失败。
文件已存在时是覆盖、跳过还是断点续传。
磁盘空间不足时是否能给出可诊断错误。
取消任务后是否释放线程、连接和临时文件。
多个任务同时写同一目录时是否会冲突。

后端接口也类似。不能只看 200 响应，还要看超时、重试、幂等、重复提交和下游服务失败。Android 客户端则要额外关注生命周期变化、后台限制、权限拒绝和低内存回收。

一个简单原则是：凡是 AI 生成了“成功处理”，就要求它或开发者同时补上“失败处理”和“清理逻辑”。如果失败路径没有测试，至少要在 review 里明确风险。

四、测试要证明关键假设

AI 生成测试时，容易出现两类问题：一种是只测最简单的 happy path；另一种是测试和实现绑得太死，看起来覆盖率高，实际没有验证业务约束。

更有价值的测试应该证明关键假设：

正常输入能得到稳定输出。
边界输入不会崩溃或产生错误副作用。
重复调用不会破坏幂等性。
异常分支会返回可预期错误。
旧行为在新改动后没有回退。

如果是 Android 代码，可以优先补 ViewModel、Repository、纯 Kotlin 逻辑的单元测试，再根据风险增加 instrumentation 测试。如果是 Linux 或后端服务，可以优先覆盖参数解析、配置加载、状态转换、文件 IO 边界和错误返回。

测试命令也应该写进变更说明里，例如：

1
2
3

./gradlew testDebugUnitTest
npm run build
go test ./...

不同项目命令不同，重点是让审查者知道“验证过什么”和“还有什么没验证”。

五、关注可维护性而不是追求炫技

AI 有时会生成看起来很聪明的代码，比如过度泛型、复杂链式调用、提前抽象出来的框架层。短期看代码量少，长期看可能增加理解成本。

可维护性审查可以看这些点：

命名是否贴近业务，而不是只有技术名词。
函数是否过长，是否混合了校验、执行、持久化和展示。
抽象是否有真实复用场景，而不是为了“显得优雅”。
错误信息是否能帮助定位问题。
日志是否包含关键上下文，又没有泄露敏感信息。
并发和异步代码是否有清晰的生命周期边界。

如果一个实现需要很长解释才能让团队理解，通常应该先简化。可维护代码不一定最短，但应该让下一个接手的人能快速判断它在解决什么问题。

六、安全和权限不能靠默认值

AI 生成代码时，如果提示里没有强调安全边界，它可能会选择最省事的实现。例如把 token 打到日志里、使用宽泛文件权限、把外部输入直接拼进 SQL 或 shell 命令，或者为了调试临时关闭证书校验。

审查时要重点排查：

密钥、token、手机号、邮箱等敏感信息是否进入日志。
用户输入是否参与 SQL、命令行、路径拼接、HTML 渲染。
文件权限是否过宽，临时文件是否可预测。
网络请求是否校验证书和域名。
管理接口、调试接口是否有权限控制。
Android 权限申请是否符合最小权限原则。

这类问题一旦进入生产环境，影响往往比普通 bug 更大。即使是个人项目，也应该从一开始养成安全审查习惯。

七、让 AI 反向参与审查

AI 不只适合写代码，也适合在提交前做一次反向审查。比较有效的提示不是“看看有没有问题”，而是要求它按风险类型输出具体发现：

请以代码审查的方式检查这次 diff。
优先指出可能导致 bug、回归、安全问题、性能问题或缺失测试的地方。
每个问题请给出文件、行号、原因和建议修复方式。
如果没有高风险问题，请明确说明剩余测试缺口。

这种提示会让 AI 更接近真实 review 的输出形式。它不一定能发现所有问题，但经常能提前暴露遗漏的边界条件、无用代码和测试缺口。

需要注意的是，AI 的审查结论仍然要被人复核。它可以降低漏看概率，不能替代最终责任。

八、形成一张可复用清单

每个团队或个人项目都可以沉淀一份固定清单。一个轻量版本可以是：

1. 改动范围是否只覆盖本次任务。
2. 业务主路径和异常路径是否都处理。
3. 是否影响旧数据、旧接口或旧客户端。
4. 是否补充了能证明关键假设的测试。
5. 是否运行了项目约定的验证命令。
6. 日志、权限、密钥和外部输入是否安全。
7. 错误信息是否可诊断。
8. 变更说明是否写清楚验证结果和残留风险。

这张清单不需要复杂，但要能反复使用。AI 越深入开发流程，越需要明确的工程门禁。否则效率提升会变成 review 压力，把问题从编码阶段推迟到合并阶段。

九、结语

AI 生成代码的速度很快，但工程质量来自持续约束。把审查清单固化下来，本质上是在给 AI 协作建立边界：可以让它承担更多重复工作，也要让每一次输出都经过可解释、可验证、可维护的检查。

当生成、审查、测试和说明形成闭环后，AI 才真正从“写代码的工具”变成“能帮助交付变更的协作者”。