如果你正在用 Claude Code、Cursor 或 Copilot 这类 AI 编程工具大概率已经撞上过一个很尴尬的问题AI 写代码的速度太快了人审代码的速度根本跟不上。需求一提工具几下就把一版代码交出来了diff 几百上千行看起来逻辑完整、命名规范、注释齐全但你真的敢直接合进主干吗只要认真看过其中一段异步逻辑、一段 SQL 拼接或者一个错误处理分支心里多半会打一个问号。问题就出在这里AI 负责写的部分越来越多人负责审的部分还是老办法——逐行看 diff、凭经验找问题。结果就是审查速度跟不上生成速度要么硬着头皮放过风险要么把 PR 堆在队列里最后还是要人工补审。这个矛盾不是靠多招几个人或者更努力地看代码能解决的。这篇文章围绕“AI 写代码但人审不完”展开。先说结论不要追求把每一行 AI 生成的代码都人工审一遍而是把代码审查拆成三层——生成前约束、机器自动检查、高风险重点复核。用自动化把常规问题挡掉把人的精力集中在真正容易出事的决策点上。下面先拆清楚问题再讲落地步骤、参数和判断标准最后给一套可以直接抄的最小审查流程。1. 先承认现实AI 生成速度超过人审速度是结构性问题很多团队第一次引入 AI 编程时流程还停留在“AI 写完人来审”的阶段。这个阶段崩溃得特别快因为它的前提假设本来就不成立人真的能审完所有代码。1.1 为什么“逐行人工审查”这条路走不通人类读代码的速度大约是每小时几百行而且这个数字还要乘以上下文理解成本。AI 生成代码的速度是按秒计的一次补全就能给出几十行一个任务下来 diff 上千行并不奇怪。两边速度差距太大逐行审查必然成为瓶颈。更麻烦的是审查不是“看一眼对不对”。你要知道这个改动是做什么的、调用方是谁、失败时怎么办、会不会破坏既有行为。读 diff 只是第一步真正的成本在理解上下文。代码量翻倍理解成本不是翻倍是接近指数增长。所以很多团队最后都在稀里糊涂地合入 AI 生成的代码不是因为人没有能力审而是因为真审不完。还有一个容易被忽略的点审查疲劳。连续看 500 行 AI 生成的代码人的注意力会明显下降。前面 100 行最认真后面 100 行基本在扫标题。疲劳状态下漏掉的问题往往正好是最隐蔽的那一类。1.2 真正要解决的不是“看得完”而是“看哪里”既然不可能逐行审完就要换一个思路把审查资源花在风险最高的地方。这不是放弃人工审查而是把人工审查从“全量检查”改成“重点复核”。打个比方。体检不会把全身每个细胞都查一遍而是先做常规检查指标异常再深入检查。代码审查也一样语法、格式、类型、编译、单测这些问题机器比人快得多也稳定得多人应该负责的是“机器查不出来”的问题比如业务逻辑是否符合预期、安全边界是否合理、失败路径是否处理干净。所以“AI 写代码人审不完”的真正解法是重构流程而不是增加人力。让机器负责常规检查让人负责高风险的判断。两者分工而不是互相替代。1.3 这套思路的适用边界这套流程更适合普通业务代码、内部系统、Web 应用、工具脚本以及样板代码较多的项目。在这些场景里自动化检查能覆盖大部分问题人工重点复核也来得及。如果是涉密系统、核心基础设施、医疗或金融关键链路、涉及人身安全或合规审计的代码那人工审查的强度不能降甚至需要双人交叉审查和外部审计。即使在这种场景分层检查仍然有用因为它能先把低级问题过滤掉让专家把时间留给真正危险的逻辑。一句话边界感很重要。分层审查是降低风险的方法不是“可以不审”的借口。2. 第一道防线生成前约束让 AI 少写需要人审的代码很多人把审查当成“AI 生成完之后”的事其实最关键的控制在生成之前。任务描述得越清楚约束定得越明确AI 生成的代码就越容易审也越不容易出边界问题。第一道防线的作用是减少 AI 的“自由发挥空间”。2.1 任务拆小diff 变小审查质量才会好我一般会要求 AI 一次只做一个最小任务。比如不要写“帮我做个用户模块”而是写“实现用户注册接口接收邮箱和密码密码用 bcrypt 哈希后入库重复邮箱返回 409”。前者会让 AI 生成一个包含路由、模型、控制器、数据库表结构的大块代码diff 动辄几百行后者范围明确生成结果集中在几个文件里一眼能看完。为什么任务拆小这么重要因为 diff 大小直接决定审查质量。小 diff 意味着改动边界清晰出问题时容易定位回滚也方便。大 diff 意味着多文件联动一个改动牵动好几处审查时很难同时盯住所有上下文。团队可以把“单次任务改动文件数”和“单次 diff 行数”作为约定先定一个轻量的阈值比如单次改动不超过 3 个文件、200 行左右超出就拆成多个任务。当然这个阈值不是死的。重构类任务、自动生成脚手架、依赖升级往往需要大 diff这类改动要有单独的处理流程不能和普通功能 PR 混在一起。2.2 把约束写进提示词和项目规则给 AI 的提示词不是越短越好而是越“可预测”越好。至少要把这几类约束说清楚技术栈和框架、目录结构、命名规范、依赖限制、禁止事项、测试要求。例如使用项目已有的 ORM不要新增数据库访问库改动范围限制在src/modules/user目录不要改公共组件错误处理统一使用项目异常类不要使用裸throw新增逻辑必须补充单元测试不要修改与本次任务无关的配置文件。如果用的是 Claude Code、Cursor 这类支持项目规则的工具可以把这些约束放到项目级规则文件里让每次生成都自动带上。这样比每次手写提示词更可靠也方便团队统一维护。判断约束是否有效有一个很直接的标准看生成的代码是不是集中在任务相关文件里。如果 AI 总是顺手改掉公共文件、依赖版本或格式化配置说明任务边界没定义清楚先不要急着合并回去补约束。