AI 写的代码有个共同特征：看起来非常对。命名规范、结构清晰、注释齐全、能跑通——比很多人手写的还整洁。也正因如此，AI 代码的 review 最容易变成「橡皮图章」：扫一眼觉得挺好，通过。而问题恰恰藏在那些「看起来对」的地方：一个被悄悄改掉的边界条件、一段幻觉出来的 API 调用、一处静默吞掉的异常。
审 AI 代码和审同事的代码不一样——同事会在不确定的地方留 TODO、会问你，AI 则会用同样自信的语气把对的和错的一起写出来。这篇文章给出一套专门针对 AI 生成代码的 review 清单和方法。
AI 代码 review 的第一原则：越是「看起来没问题」的地方，越要停下来验证。
先看改动范围，再看代码质量
review AI 代码的顺序和平时相反。平时你信任同事只会改该改的地方，先看逻辑；审 AI 代码要先看它到底改了什么、有没有超范围。AI 常见的越界行为：让它修一个函数，它顺手「优化」了旁边三个；让它加一个字段，它重排了整个数据结构；让它改 A，它删了看起来没用其实有用的 B。
用 Git Worktree 或分支 Diff 把这次 AI 改动完整框出来，第一遍只问一个问题：这些文件、这些行，都是这个任务该动的吗？ 超范围的改动先剔出来单独评估，别让它们混在「主要功能」里蒙混过关。
AI 代码最容易翻车的六个地方
按踩坑频率排序，这些是 review 时要重点盯的：
1. 幻觉的 API 和依赖
AI 会调用不存在的函数、传错参数顺序、import 一个查无此库的包，或者用了某个库早已废弃的旧 API。它对此毫无察觉，语气一样自信。凡是不熟悉的 API 调用，去查官方文档核对签名；新引入的依赖，确认它真实存在、维护状态正常、许可证合规。这类问题幻觉是根源，靠肉眼看代码风格发现不了，必须交叉验证。
2. 边界条件和错误处理
主流程 AI 写得很好，边角料经常糊弄：空数组、null、超长输入、并发、网络失败——要么没处理，要么用 catch {} 静默吞掉异常让错误消失得无影无踪。专门检查：空值和边界有没有覆盖？异常是被处理了还是被藏了？失败路径会不会留下脏数据？
3. 安全问题
AI 会写出拼接 SQL（注入风险）、把密钥硬编码进源码、对用户输入不做校验、日志里打印敏感信息、权限检查缺失。它优化的是「让功能跑起来」，不是「让功能安全」。涉及输入处理、鉴权、数据库、外部请求的代码，按安全清单过一遍。
4. 悄悄改掉的行为
最阴险的一类。让 AI 重构，它把 >= 改成了 >；让它「优化」，它改了默认值、调了排序、动了缓存时长。功能「看起来」还是那个功能，行为已经变了。对照原代码逐处确认语义有没有被无意改动，这是 review AI 重构类改动的重中之重。
5. 编造的测试
让 AI 写测试，它可能写出「必然通过」的假测试：断言写得很宽松、mock 掉了真正要验证的逻辑、或者测的是它自己刚写的错误行为。测试要看它到底断言了什么，别被绿色的通过标记安抚。 好的做法是自己想几个它没覆盖的边界用例补上。
6. 过度工程
AI 倾向于「显得专业」：为一个简单需求引入设计模式、加一堆配置项、抽象出用不上的接口层。这不算 bug，但会累积成维护负担。问一句：这个复杂度是需求要求的，还是 AI 自作主张加的？
六个高危区里，「悄悄改掉的行为」和「幻觉 API」最隐蔽——它们都伪装成正确代码。
一份可打印的检查清单
□ 改动范围：只动了该动的文件和行？超范围的已剔出单独评估？
□ API 核对：不熟悉的调用查过官方文档？新依赖真实存在且合规？
□ 边界：空值/null/超长/并发/失败路径都处理了？
□ 异常：是处理了，还是被 catch{} 吞了？
□ 安全：SQL 拼接、硬编码密钥、输入校验、权限、日志脱敏？
□ 语义：重构处对照原逻辑，行为没被悄悄改动？
□ 测试：断言是否真的验证了逻辑？边界用例够吗？
□ 复杂度：这些抽象和配置是需求要的，还是 AI 加戏？
□ 运行验证：真的跑起来看过效果，而不只是读代码？最后一条最重要也最常被跳过：AI 代码必须实际运行验证，不能只靠读。读代码能发现明显错误，但边界行为、集成问题、副作用只有跑起来才暴露。改动可预览的，就在浏览器或测试里驱动一遍看真实结果。
用 AI review AI：能帮忙，但别托管
一个有效的技巧是让另一个 AI（或换个提示词的同一个 AI）来 review 生成的代码——它擅长发现语法层面的疏漏、明显的安全模式、不一致的命名。很多工具（Claude Code 的 review、各类 CI 集成的 AI reviewer）已经把这做成了一键能力，AI 代码审查工具也是一个成熟品类。
但要清醒：AI reviewer 和 AI coder 有相同的盲区——它俩可能一起看不出同一个幻觉 API，一起觉得那段过度工程「很专业」。把 AI review 当成「多一双眼睛的初筛」，能拦掉一批低级问题，替你省力；但业务逻辑对不对、行为有没有被改、这个改动符不符合系统设计，最终判断必须是人。AI 可以帮你 review，不能替你负责。
AI reviewer 做初筛、人做终审——它们的盲区重叠，不能互相替代。
适用人群与工作流建议
适合所有用 AI 写代码并要为代码质量负责的开发者和团队。给三条落地建议：
- 改动越大，review 越要慢。AI 一次改几百行时，别指望通读，拆成逻辑块逐块过，或者干脆让它分几次小改，每次小改易于 review——小步提交本身就是降风险手段。
- 建立团队 AI 代码规范：哪些场景允许 AI 主导、哪些必须人写（如安全核心、支付逻辑）、合并前必过哪些检查，写进团队 AI 协作约定。
- 用 CI 兜底：类型检查、lint、测试、安全扫描能自动拦掉一批问题，让人的 review 专注在机器发现不了的语义和设计层面。
常见问题
Q：AI 代码 review 要比人写的代码花更多时间吗？ A：单看「读」可能更快（AI 代码通常更规整），但「验证」要花更多——因为不能信任它在边界和 API 上的正确性。总体上，别把 AI 省下的编码时间全花掉，留足 review 预算。
Q：小改动也要走完整清单吗？ A：按风险裁剪。一行文案改动不必上纲上线；但凡涉及逻辑、数据、安全、外部调用，哪怕只有几行，清单里的相关项都要过。风险不由代码行数决定。
Q：怎么防止自己变成橡皮图章？ A：强制「先跑再批」——没实际运行验证过的 AI 改动不合并。运行这个动作会自然逼你面对真实行为，而不是被整洁的代码催眠。
小结
审 AI 代码的心法就一句：它越是看起来对，你越要验证。 先框定改动范围防越界，重点盯幻觉 API、边界处理、安全、被悄悄改掉的行为、假测试和过度工程这六个高危区，最后一定实际运行。AI 能帮你初筛，但代码合进主干那一刻，负责的人是你，不是模型。