怎么读、怎么 Review AI 生成的代码
AI 又快又自信，但「看起来对」不等于对。你的工作从「写代码」变成「核对意图 + 把关风险」。
背景：生成变便宜了，验证没有
AI（Copilot、Cursor、Claude Code、Codex…）写代码又快又自信，但错误往往隐蔽、质量分布很大。关键变化是：代码的「生成成本」趋近于零，而「验证成本」没有同步下降。 所以人的稀缺能力，从「产生代码」移到了「判断代码」。
怎么读：以意图为基准，分层读
以意图 / 规格为基准，而不是语法。 判据是「实现是否符合意图」，不是「语法对不对」。所以第一步永远是：先明确需求、规格、验收标准，把它当对照物。
然后分层读，不线性读，把 AI 生成的整块代码降维成可核对的多层契约：
- 契约层：输入输出、副作用、错误行为
- 数据与控制流层：数据怎么流转，分支怎么走
- 集成层：类型、API、依赖、架构是否一致
- 健壮性层：空值、越界、并发、失败、资源释放
重点找「貌似正确的错误」——这是 LLM 的典型失败模式，也是评审的高频命中区：
- off-by-one、错误的 API 用法
- 吞异常（
except: pass）、静默失败 - 幻觉出的库 / 接口（AI 编造的 API 或依赖）
- 过度设计
- 边角输入：空字符串、0、超大值、并发
连测试一起读。 测试编码了「期望行为」，但 AI 生成的测试常自洽而空洞——测实现不测行为。要检验断言是否真的触及真实行为，而不是只让代码跑通。
读 diff 与影响面。 读改动行及其调用方、下游，而不是整段重读。
怎么 Review：从「逐行挑错」到「意图 + 风险」
AI 代码量大、评审时间有限，逐行挑错不可持续。正确的姿势是把评审清单聚焦到意图与风险：
- 契约：是否符合验收标准？有没有对应测试？
- 边界：空值、越界、非法输入
- 安全：注入、密钥、越权、数据泄露
- 集成：与既有 API / 依赖是否一致
- 性能：意外的 O(n²)、N+1、无限循环
- 一致性：命名、风格、与既有代码是否协调
- 测试是否有意义：断言是否触及真实行为
分级把关（triage）：高风险 diff（权限、资金、数据、并发、安全、外部依赖）重点审；低风险（重命名、格式）快速放行。
用 AI 辅助 AI：让模型自审、列出边界清单与测试建议——但必须用「真值」验证，不采信它的自述。
流程护栏：小 diff、清晰的 spec、测试先行、CI + lint + 类型检查 + 静态分析。把 AI 当成「很快但过度自信的初级同事」，最终责任在人。
把 Review 前置到「生成前」：规格质量决定代码质量，先写清需求和验收标准再让 AI 生成，比事后补审高效得多。
一句话
读代码 = 核对意图与风险；Review = 意图的守门人 + 风险闸门。速度和数量不是瓶颈，判断力才是。可落地：先写规格（AI 任务规格），再用评审清单逐项核对。