当一个 PR 从 200 行变成 2000 行而且主要贡献者是 AI 的时候团队的瓶颈通常不再是“写不出来”而是“审不过来”。我见过不少团队的 Review 队列变成这个样子PR 标题都带 AI 辅助生成标签改动量动辄上千行但审查者只有一两个人。点开 Diff 之后发现代码能跑、风格统一、边界也处理得差不多但就是有一种“说不上来哪里可能出问题”的不安。这种不安不是错觉而是现有代码审查机制正在失效的信号。本文想给出的判断是AI 写代码这件事已经不可逆真正要解决的不是让人去逐行读完 AI 生成的代码而是重新设计审查结构把有限的、昂贵的人类注意力投放到机器无法判断的意图和风险上。读完你可以得到一套可落地的分层审查方案包括信任分级、CI 自动化验证、Prompt 约束和常见排障思路。1. 这篇文章要解决的现实问题先说一个很多团队都经历过又很难量化的问题PR 列表里大量任务停留在waiting for review状态而且等待时间越来越长。以前代码审查慢主要因为开发节奏问题是“写的速度赶不上需求”。现在情况变了AI 编程工具把生成代码的成本压得非常低一个周末可以生成过去两三周的业务代码。于是流程的瓶颈从“编写”转移到了“审查”。这会带来三个连锁问题第一审查积压导致部署周期变长。代码写得越快Review 队列越堵功能上线反而更慢。团队很快会陷入一种尴尬局面AI 提升了开发效率但工程交付效率没有同比例提升。第二审查质量下降。当人面对一眼看不完的大 Diff 时很容易产生两种极端行为要么干脆不改直接 Approve要么只挑小毛病对真正的结构性问题视而不见。这两种行为都会让审查流于形式。第三风险归属模糊。AI 生成的代码引入 bug责任算谁的如果团队没有规则最终责任还是会落在“最后 Approve 的那个人”头上。这种模糊性会让审查者变得更保守也更容易被牵着走。所以你会发现这已经不是“把代码读完”的问题而是整个审查流程假设被打破的问题。传统 Code Review 的前提是人可以在有限时间内读完所有代码变更并且有能力判断其中的大部分风险。但 AI 生成时代这个前提不复存在。这篇文章提供的解法思路是把对“所有代码”的审查改造成对“风险体系”的审查。人会累但验证体系可以持续运转。2. 前置概念AI 代码和人类代码的故障模式完全不同要设计新审查方案先要理解一个容易被忽略的事实AI 生成的代码和人类写的代码出错方式并不完全一样。人类程序员写代码错误通常集中在边界条件、并发控制、命名混乱、逻辑分支遗漏这些地方。这些问题虽然隐蔽但一般有迹可循审查者凭经验可以大概率嗅出问题区域。AI 生成的代码有一种更麻烦的错误模式看起来非常正确但可能建立在错误的假设上。比如调用了一个并不存在的第三方 API但参数和返回类型刚好对齐引入了一个依赖并在代码里使用了它但依赖版本的许可证或兼容性有问题对某个业务规则的实现“合理”但不是“正确”因为它不理解业务的真实意图在异常处理里吞掉了所有异常代码因此“永远不会挂”但也不会恢复把安全校验写在注释里却忘了真正实现鉴权逻辑。这些错误很难通过“通读代码”发现因为它们不是写得烂而是“写得太顺”。人的大脑在处理合乎语法、结构完整的代码时非常容易产生信任感这是认知机制决定的靠意志力很难克服。我把人类代码和 AI 代码的错误模式整理成一张对比表方便后续设计方案时对照维度人类传统代码AI 生成代码主要错误来源边界条件、并发、逻辑遗漏错误假设、幻觉 API、语义误解代码风格因人而异可能不一致通常一致甚至过度一致结构性坏味道可能通过长期迭代累积可能大面积复制相似结构测试覆盖取决于开发者习惯取决于提示词约束审查特征问题隐藏在不规范处问题隐藏在“太规范”处看清这个差异之后你就会明白靠提高审查效率解决不了问题。正确方向是建立一个不依赖人类通读能力的防线体系让 AI 代码在进入人类审查之前先被结构化的工具矩阵过滤一遍。3. 分层审查从“逐行读”到“信任矩阵”既然没法逐行审查所有代码那就必须给代码划分信任级别。不同信任级别的代码使用不同强度的验证方式。这个思路很像银行的风控体系对于一个首次大额转账的用户和一个十年老客户安全策略不应该一样。我把代码变更分成三个信任级别低风险区文档、注释、单元测试、脚本、配置示例。这类变更即使出错影响面小可以交给自动化工具验证。中风险区业务模块、普通 API 接口、数据处理逻辑。这类变更需要自动化验证加抽样人工审查。高风险区鉴权、支付、权限模型、数据迁移、基础设施、对外协议。这类变更无论由谁生成都必须同时经过自动化验证和人类核心审查。基于这个分级可以写一个策略配置。下面是一个参考示例实际项目中你可以按团队情况扩展字段{ version: 1, trust: { low: [docs/, tests/unit/, scripts/dev/, *.md], medium: [src/modules/, src/utils/], high: [ src/auth/, src/payment/, infra/, migrations/ ] }, review: { low: automated, medium: automatedsampling, high: automatedhuman }, sampling: { mediumRatio: 0.2 } }这个配置文件解决的是审查资源分配问题。它的核心逻辑是让机器完成全部代码的自动化验证让人类只保留两个义务——抽查中风险区审查高风险区。这里要注意一点信任分级不是一成不变的。当某个目录或模块的 AI 生成代码质量持续稳定且测试覆盖率足够高时可以把它从高风险区移入中风险区。反过来如果一个看似低风险的脚本实际被生产任务调用就要立刻升级它的信任等级。从工程实践看这个矩阵带来的最大收益不是节省了多少审查时间而是让团队在“哪里值得花时间”这件事上达成了共识。没有共识之前审查质量取决于个人责任心有了共识之后审查质量取决于体系设计。4. 四层防线AI 代码不是不能审而是要换一种审法分级完成之后下一步是为每个信任级别设置对应的防线。我建议把整个防御体系设计成四层从机械执行到人机协同每一层都承担明确的职责。4.1 第一层自动化验证门禁这一层的核心是“任何代码都先过机器再说”。编译、静态检查、单元测试、依赖漏洞扫描、覆盖率检查全部在 CI 中完成。AI 生成的代码必须和人类代码进入同一套门禁没有任何特权。很多团队在引入 AI 编程工具的时候会觉得反正代码是 AI 写的测试是不是就可以少写一点这是最危险的想法。AI 生成代码时往往只关心“如何完成这个函数”并不关心“这个函数在真实系统里会怎样被调用”。单元测试和集成测试恰恰是对抗这种短视的唯一手段。4.2 第二层生成阶段约束不要等 AI 把代码生成完了再想怎么审查应该在生成阶段就限制它的输出范围。例如使用 Claude Code 或类似 AI 编程工具时可以在项目根目录配置规则明确不允许 AI 修改某些文件不允许调用某些函数必须使用指定的日志组件。这种约束的价值在于从源头减少“需要人判断”的代码量。下面是一个示例约束文件你可以放在项目根目录AI 工具在生成时会读取它# AGENTS.md - Allowed paths: src/, tests/ - Forbidden paths: infra/, migrations/ - Forbidden functions: eval(), exec(), system() - Logging must use the project logger wrapper, not print() - Any API call must include timeout parameter - Public functions must have JSDoc comments with throws tags4.3 第三层变更分级策略这一层把“自动验证门禁”和“文件信任矩阵”结合起来。CI 在合并请求中检测变更路径自动计算变更风险等级然后决定是否需要在合并前进行人工审查。比如一个 PR 只改了docs/目录即使没有人工审查也可以合并如果改了src/auth/系统直接打回要求至少一个指定审查者确认。4.4 第四层人类审查黄金路径人类审查员的职责要重新定义为“意图审查”和“风险审查”而不是“代码通读”。具体来说人类需要回答以下几个问题这段代码是否符合业务预期是否有办法在不需要改核心逻辑的前提下降低这个实现的风险AI 是否误解了某个隐含的业务规则如果发生故障团队能否快速定位到这段代码换句话说人不再去逐行找语法错误而是在机器已经过滤过的代码上做更深层的判断。5. 工作流落地在 CI 里接入 AI 代码审查流程设计完之后要在实际工程链路里跑起来才能产生价值。下面我给出一个最小可落地的 CI 配置示例以及配套的 Prompt 和规则文件。5.1 CI 自动化验证配置name: ai-code-review on: pull_request: types: [opened, synchronize] jobs: verify: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Run lint run: npm run lint - name: Run type check run: npm run type-check - name: Run unit tests with coverage run: npx jest --ci --coverage - name: Check dependency vulnerabilities run: npm audit --audit-levelhigh这段配置只做一件事让机器完成所有可以自动化的检查。lint、类型检查、单元测试、依赖安全审计这套流程对 AI 生成的代码和人类代码一视同仁。如果 AI 生成代码连 lint 都过不了它根本不应该进入人工审查环节。5.2 AI 审查助理的 Prompt 示例即使当前 AI 代码审查工具还不完美用它做“第一轮筛选”依然有价值。给 AI 审查者一个清晰的系统提示词可以有效减少误报You are a code review assistant. You review diffs in a pull request. Focus on: 1. Resource lifecycle: any unclosed connections, missing cleanup. 2. Error handling: swallowed exceptions, missing rollbacks. 3. Data safety: hard-coded credentials, injection risks. 4. Contract stability: changes to public API signatures without test changes. Do NOT comment on: - Code style unless it affects correctness - Naming conventions - Missing comments Output format: - P0: must fix before merge - P1: should fix soon - P2: acceptable but worth noting Keep the total output under 10 items.这个 Prompt 的价值是把审查范围限定在“机器更容易发现、人也更容易遗漏”的高价值问题上。毕竟 AI 生成的代码往往风格统一机械 lint 级别的意见意义不大真正有价值的是生命周期、异常处理、安全边界这一类硬伤。5.3 AI 生成文件标记规范为了让审查者快速判断一段代码是否需要重点看可以在 AI 生成或 AI 辅助修改的文件头部加上标记# GENERATED_BY_AI: true # REVIEW_LEVEL: high # REVIEW_OWNER: team-backend有了这个标记CI 可以在 PR 页面自动标识高风险文件也可以触发更严格的测试要求。例如要求该目录的测试覆盖率必须达到某个阈值才能合并。6. 用 AI 审 AI 的边界既然 AI 写代码已经挡不住很多人会想那就再用 AI 来审代码用加速对抗加速。这个思路在局部有效但必须清楚它的边界。AI 审查工具的优势在于它可以很快扫完一个巨大的 Diff找出跨文件的引用关系、检测重复代码、发现潜在的空指针路径也不会因为连续工作三小时而疲劳。把它定位成“自动化验证的补充”价值非常明显。但它目前没有办法做以下三件事第一判断产品意图。AI 不知道为什么客户要这个功能也不知道那个异常分支是不是产品经理特意设计的。它只能从代码形式判断“是否自洽”不能判断“是否符合需求”。第二识别语义上的“错得离谱”。AI 生成的代码可能在逻辑上完美无缺但它实现的功能根本不是用户想要的。AI 审查者大概率同样看不出这个问题因为它是基于 AI 对正确性的预设来评分。第三承担责任。无论 AI 审查工具给出多少条建议最终对生产事故负责的一定是团队中的具体人。所以 AI 审查建议只能作为参考不能替代人工确认。更实际的风险是如果 AI 审查工具误报率太高开发团队会产生“狼来了”效应最终忽略所有 AI 审查结果。因此我建议AI 审查的输出不要直接作为合并门禁而是要经过人工 review 通道过滤后再沉淀为规则。7. 验证方法与效果指标当你把分层审查方案落实之后不能只看“感觉好多了”要用指标来验证机制是否有效。下面几个指标值得长期跟踪指标含义健康信号平均 PR Review 等待时间PR 从提交到首次人工反馈的时间小于 24 小时未审查代码变更比例直接合并的低风险变更占比低于 20%缺陷逃逸率上线后 30 天内发现的 bug 数量稳定或下降AI 生成文件被回滚率上线后因问题回滚的 AI 文件占比低于 1%人工审查聚焦度人工 review 是否集中在中高风险区域高审查意见可执行率Review 意见被采纳并产生代码修改的比例高于 60%从我的观察来看很多团队在实施分层审查后最先看到的不是缺陷减少而是 Review 等待时间下降。因为机器承担了大量低风险验证人工只需要处理高风险区域队列自然清空。缺陷率的变化需要更长时间才能体现但它会随测试覆盖率的提升而逐步改善。如果你想验证自己团队是否走在正确方向上最快的方法是随机抽 10 个合入主干的 PR看两个数据有没有超过一半的变更依赖自动化验证而不是人工通读人工审查意见是否集中在高风险文件上如果答案是肯定的说明分层审查结构已经生效。8. 常见问题与排查方法在实施这套方案的过程中团队会遇到一些典型问题以下是我整理的排查表问题现象可能原因排查方式解决方案AI 生成的代码通过全部单测但线上返回错误数据单元测试覆盖的是“正常路径”没有覆盖边界条件审查测试用例中是否存在真实业务断言补充集成测试和契约测试对高风险区增加属性测试AI 审查工具大量误报开发者开始无视Prompt 范围太宽审查者对项目上下文了解不足查看 AI 审查输出的 P0 类建议是否集中在合理范围收窄 Prompt 范围限定只检查资源、安全、错误处理人工审查只盯着小改动大改动直接通过大 Diff 产生认知过载审查者放弃深度分析统计 Approve 时平均审查代码行数强制按文件拆分 PR高风险目录必须至少一人明确确认提示词约束没生效AI 还是改了不该改的目录约束规则没有写入 AI 工具实际读取的规则文件检查 AI 工具的 system prompt 或 AGENTS 文件是否被正确加载把约束文件放到项目根目录并在 CI 中校验输出路径Review 队列堆积等待时间持续上升未按信任级别分流所有 PR 都等同一个审查者检查是否所有 PR 都要求同一人 Approve建立按目录/模块分配审查人的机制低风险区自动化放行AI 生成代码使用了一个不存在的依赖版本模型训练数据中的版本信息过时检查package-lock.json或requirements.txt是否包含伪造版本统一使用公司内部依赖源并在 CI 中强制锁文件9. 最佳实践与工程建议方案跑通之后如果你想把它沉淀为团队长期质量标准下面几条建议很值得参考。9.1 强制记录 AI 生成来源在代码中标记哪些文件由 AI 生成或主导生成不是为了追责而是为了调整后续审查策略。如果一个模块的 AI 生成文件回滚率一直很低可以考虑降低它的信任风险等级如果一个模块反复出问题就要提高它的验证密度。9.2 控制 AI 生成的变更粒度让 AI 一次只生成一个小模块而不是一个巨型 PR。变更粒度越小自动化验证越容易覆盖人类审查的认知负担也越小。如果 AI 工具倾向于一次性生成大量文件建议在 Prompt 中显式要求每次只输出一个功能单元。9.3 在高风险目录增加强制双人复核对于支付、鉴权、数据迁移、基础设施这类变更即使 AI 生成代码看起来完全合理也建议设置“双人复核 回滚演练”机制。常见的做法是主审查者负责业务逻辑副审查者负责安全边界和依赖风险两个角色同时确认后才能合并。9.4 把审查决策沉淀为规则人工审查发现的问题不要只停留在当前 PR 里应该及时转化为自动化检查规则。例如如果发现两次 AI 生成代码都漏了 API 超时参数就在 CI 中加入对应的静态检查规则。这样团队的经验会沉淀为“资产”而不是只依赖某个人的记忆力。9.5 补充契约测试和属性测试AI 生成代码的一大问题是它非常擅长实现接口但不一定理解接口背后的约束。契约测试可以保证服务调用方和提供方之间的数据格式一致属性测试可以从随机输入中找出实现逻辑的盲区。这两类测试对 AI 生成代码的审查价值非常高建议优先补上。10. 总结与下一步实践我会把核心观点再重复一遍AI 生成代码之后人类审查的瓶颈不是速度而是结构。与其强迫自己把每一行 AI 代码都读完不如建立一套按风险分层的验证体系让机器处理机器擅长的事让人处理人擅长的事。如果你目前的团队还没有任何对策下一步可以这样启动第一步先跑通 CI 中的自动化验证门禁。哪怕只有 lint、类型检查和单元测试这一层也能过滤掉大量低质量 AI 代码。第二步给代码目录分信任级别。挑出 10 个左右的高风险目录要求这些区域必须有人工审查。第三步在 AI 编程工具的规则文件里写清禁止修改的路径和禁止调用的函数。第四步给 AI 审查助理一个清晰的 Prompt并把它接入 PR 流程让它在人工审查之前先跑一遍。第五步持续跟踪“平均 Review 等待时间”“缺陷逃逸率”“人工审查聚焦度”这三个指标用数据验证方案是否有效。长期再看AI 写代码的比例还会上升但代码审查会变成一项更需要系统思维的工作。它考验的不是谁的阅读速度快而是谁能在有限的人类注意力下设计出更高效的验证和决策结构。