AI 可以快速生成组件、测试和迁移脚本，代码量不再是明显瓶颈。问题也随之改变：一段实现看起来完整、风格一致，却可能误解业务不变量，或者引入项目中不存在的抽象。

评审如果仍然主要检查格式和常见语法，就无法覆盖新的风险。

AI 编程从任务契约、仓库建模、最小变更到分层验证和人工评审的闭环

图 1：生成代码只是中间一步。评审从意图和不变量开始，以不同来源的验证证据结束。

交付时我会要求一份评审证据包：任务契约、仓库基线、修改文件、关键假设、测试命令与输出、未验证项和人工关注点。只给 diff，会把理解成本转嫁给评审者。对认证、迁移、并发和外部副作用，评审必须有人类重新推演失败路径——AI 可以加快实现和搜索，责任不能被“模型写的”稀释。

证据包让产出速度与可审查性一起提高。这套标准在真实仓库里跑过一轮之后的细节——Agent 怎样理解仓库、交付怎样带证据——在如何让 AI 编程 Agent 在真实仓库里交付里展开；执行环境本身的边界则是编码 Agent 的沙箱的主题。

先验证意图

提交应说明解决什么问题、关键约束和验证方式。评审者先确认模型实现的是否是正确问题，再查看边界情况、失败模式和数据影响。

生成代码常倾向补齐“合理功能”，例如自动重试、默认回退或额外缓存。这些行为必须被显式确认，不能因为代码能运行就进入系统。

我遇到过一类很典型的生成结果：为了“提高可靠性”，模型给创建订单接口加了三次自动重试。代码有退避、日志和测试，看起来很完整，却没有回答创建接口是否幂等。第一次请求已经成功但响应超时，重试就可能创建第二笔订单。

评审这种代码时，我不会先讨论退避参数，而是先写不变量：

// 同一个 clientRequestId 最多对应一个订单
type CreateOrderCommand = {
  clientRequestId: string;
  userId: string;
  items: Array<{ sku: string; quantity: number }>;
};

只有服务端对 clientRequestId 建立唯一约束，并能查询已有结果，客户端才有安全重试的基础。AI 容易补出机制，评审者必须确认机制背后的业务前提。

缩小生成范围

让 AI 在稳定接口内完成局部实现，比一次生成跨越多层的大改动更容易验证。公共协议、权限、财务和不可逆数据变更仍需要更强人工设计。

测试也不能只由同一提示同时生成。先列不变量和反例，再让工具补充实现；关键路径保留独立验收与真实样本。

我会把评审按风险顺序走，而不是从第一行读到最后一行：

顺序 检查内容 典型问题
1 行为与非目标 是否实现了错误问题，是否顺手扩展范围
2 数据与副作用 幂等、事务、迁移、删除、权限
3 失败路径 超时、部分成功、取消、恢复
4 跨层契约 调用方、旧版本、缓存、序列化
5 局部实现 可读性、复杂度、性能

生成代码往往在第五层表现最好，风险却集中在前四层。先看漂亮实现，会让人过早接受它的前提。

提交要保留可追溯意图

使用 AI 反复修改后，开发者容易只保留最终文件，不知道某段代码为何出现。提交前需要清理无关生成、删除未使用抽象，并用自己的语言说明关键选择。无法解释的代码不应因为测试通过就进入生产。

我要求提交说明至少包含四段：

Intent: 要改变的行为
Invariants: 保持不变的业务事实
Evidence: 实际运行的检查与结果
Residual risk: 尚未覆盖的场景

“AI 生成并经人工检查”不是证据。类型检查通过、幂等并发用例通过、旧客户端回归通过，才是可以复核的证据。提示词可以保存为开发过程附件，不能替代这些工程事实。

模型与提示上下文也可以作为开发过程记录，但不能代替正式设计说明。未来维护者需要知道系统约束，而不是重放一场冗长对话。把探索压缩成可验证的决策，是使用 AI 后新的整理工作。

AI 提高的是产出候选方案的速度，不是自动提高正确率。未来代码评审更像设计审查：关注假设、系统边界和长期成本，而不只是逐行纠错。