有个团队PR积压了两百多个，合并周期从半天拖到三天。不是人不够，是AI让写代码变快，但评审还是人在看、人在等。
为什么评审成了新瓶颈
AI加速写代码，却卡住了评审环节
这听起来像是一个产能问题，但真相更微妙。AI生成的代码量在变大，单次PR涉及的文件数也在增加。一个过去需要人工逐行看的改动，现在可能涉及十几个文件、几百行自动生成的代码。评审者需要理解的不只是「这行对不对」，而是「AI想做什么、做得对不对」。这种认知负担的跃升，比单纯的量增更难消化。
某团队在全面引入Claude Code后的复盘里提到一个数字：Bug漏检率从41%降到了11%。降幅可观，但剩下那11%往往是结构性问题——AI能发现空指针、忘记处理异常，却很难判断「这个架构决策是否合理」「这段业务逻辑是否覆盖了真实场景」。后者才是评审的核心价值所在，也是瓶颈所在。
产出和消费的严重错配
开发侧的产出速度被AI拉高了，消费侧的评审节奏却没跟上。这造成了一种典型的流水线卡点：上游在加速，下游在减速，中间堆积了大量待处理的PR。
更麻烦的是，AI生成代码往往带有一种「看起来很完整」的错觉。它不会留下明显的TODO标记，也不会告诉你它跳过了什么边界条件。评审者需要额外的认知资源去验证——这就是为什么说，评审不只是审代码，而是要审「这段代码背后的假设是否成立」。
AI时代评审瓶颈的因果链
这个循环如果不被打破，就会出现一种恶性叠加：PR越多，评审越慢，团队越倾向于攒一波再合并，累积的代码规模又进一步推高下一次评审的成本。很多团队卡在这个环节，不是因为找不到好工具，而是因为他们还在用旧的节奏应对新的产出速度。
Agent运行时的真实状况
Claude Code团队内部分享过五条工作原则，其中一条很直白：代码评审正在经历新的规模、新的形态、新的工具。这意味着什么？过去那种「写完提交、等人逐行review」的模式，已经跟不上PR数量的增长曲线了。
问题在于，评审本质上是个「消费端」——你写得越快，消费端压力越大。要打破这个错配，只能改变评审发生的位置。
JIT规划：不再写长篇设计文档
Fiona刚加入Claude Code团队时，参与制定过一个六个月路线图。写得很漂亮，逻辑清晰，每个里程碑都有明确的时间节点。三个月后，它过时了。
原因很简单：Claude Code本身的迭代速度，超过了任何静态规划的保质期。写代码之前先花大量时间做完整设计，这个前提本身就不成立了——因为等你写完了，需求早就变了。
现在的做法叫「JIT规划」（Just-In-Time）。概念来自制造业的准时生产，在软件领域就是：在对的时间做恰好足够的规划。
砍掉的是那个「先写设计文档、再写代码」的仪式。改而做的是两件事：把讨论移到PR里，把验证移到原型上。
这不是说完全不要规划，而是把规划的时机延后、把规划的形态变薄。一个功能该不该做，不是靠写50页PRD来论证，而是靠内部用户先跑起来看反馈。
更狠的是，这个思路直接改变了评审的触发时机——你不需要等一个完美的方案被批准才能开始，你可以在一个小改动里让评审持续发生。
规划这件事，写得太早反而成了负担
先在PR里讨论，再做原型验证
传统流程是这样的：需求评审 → 技术方案设计 → 编码实现 → Code Review → 合并。每个阶段都是串行的，且评审集中在最后一个环节。
新的节奏把它打散了。Fiona提到的团队规范里有一条：先做原型，让内部用户去用，然后根据反馈快速迭代。原型本身就是一个「活的讨论场」，PR里的评论直接指向可运行的代码，而不是抽象的设计描述。
这种模式下，评审不再是「事后纠错」，而是「事中确认」。
具体到操作层面，变化体现在三个地方：
第一，设计文档从「写作任务」变成了「活文件」。技术方案不再是写一次就归档的东西，而是在PR评论、prototype反馈里不断演化的。
第二，评审人的角色从「决策者」变成了「信号收集者」。他们不再需要先审批才能动手，而是在代码推进过程中随时提供输入。
第三，评审的入口从「合并前的一票否决」变成了「PR创建后的持续对话」。这听起来细微，但实际上是把评审从「门槛」降级为「过程」。
代码评审不是为了拦住错误，是为了让正确的事更快流过去。当你把评审从终点线移到赛道中间，它的性质就变了。
评审不是拦错，是让正确的路更宽
很多人对代码评审有误解，认为它是质量门禁——不通过就不能上线。这个理解本身没问题，但把它当成唯一的评审形式，就会出问题。
当PR数量因为AI辅助编程翻倍增长时，「门禁模式」的瓶颈效应会被指数级放大。每个评审人同时能处理的PR数量有限，一旦堆积起来，整个团队的交付速度就会被这个点卡住。
解决思路不是招更多人做评审，而是重新定义评审的形态。让评审发生在写代码的过程中，而不是之后；让评审成为持续对话，而不是单次裁决。
这样做的另一个好处是「信息密度更高」。评审人在看到可运行的原型时给出的意见，和看到抽象文档时给出的意见，质量是完全不同的。前者基于真实行为，后者基于想象推演。
人机分工：AI扫机械检查，人做架构判断
把评审变成持续检查，还需要解决一个现实问题：谁来读这些持续产生的review输入？
Claude Code团队的实践是做一个明确的分工：AI负责机械性的正确性检查——空指针、异常处理、并发安全、边界条件——这些有固定模式，人做反而容易因为疲劳漏看。人类负责理解改动的意图、评估架构决策是否合理、判断业务逻辑是否覆盖完整。
前者是「找错」，后者是「判断」。
一个PR的最优Review路径变成了：Claude先扫一遍 → 把机械性问题标记出来 → 人类reviewer聚焦在架构和业务逻辑上。
这种分工不是AI替代人，而是重新定义人的职责——让人从「逐行检查语法错误」回到「判断方向是否正确」的位置。
从前逐行审代码，现在审判断
AI不会替你确认最后的效果，它只能提醒你哪里需要再看一眼。真正的答案还在人手里。
评审从关卡变成检查，从事后变成持续，从人工扫描变成人机分工。这三层变化叠加在一起，才是「评审不只是审代码」这句话的真正含义。
Claude Code团队的5条工作原则
Fiona加入Claude Code团队时，他们也写过漂亮的六个月路线图。结果呢，三个月后产品迭代已经走偏，路线图成了一纸空文。
他们的解法是JIT规划——Just-In-Time，像JIT编译一样，在对的时间做恰好足够的规划。不再写长篇大论的设计文档，直接在PR里讨论；不再做冗长的产品评审，先做原型让内部用户使用，根据反馈快速迭代。
这条原则的底层逻辑是：评审的成本不该在合并前一次性支付，而应该摊到整个开发过程中。评审的本质不是拦截错误，而是让正确的变更更快流过去。
人的判断力聚焦在真正需要的地方
引入Claude Code进行代码评审后，他们团队的Bug漏检率从41%降到了11%。
这个数字变化的背后是人机分工的重构。Claude负责机械性的正确检查：空指针、异常处理、并发安全、边界条件。这些检查有固定模式，人做反而容易因疲劳或赶时间漏看，Claude专注且不知疲倦。
人负责什么？理解改动的意图、评估架构决策是否合理、判断业务逻辑是否覆盖完整、发现「代码能跑但方向错了」的问题。这些需要理解系统全貌和业务背景，AI现在还做不好。
Agent流水线跑满时的日常
更狠的是，这种分工让新人一周就能开始产出代码。
为什么？因为AI承担了新人最薄弱的环节——那些容易踩的坑、容易漏的检查。新人不需要成为全栈专家才能提PR，只需要在关键判断点上做出合理选择。AI帮他们挡住那些机械性的失误。
这也解释了为什么他们的招聘偏好变了：看重创造力和判断力，不看纯产出速度。当AI可以替你做90%的机械工作时，剩下的10%才是你真正需要考核的能力。
招聘看重创造力和判断力，不看纯速度
这在业内并非孤例。
某团队在2026年的复盘报告中明确写道：「代码生成能力提升，并不会自动消除验证需求；反而会提高对验证体系的要求。」当AI能快速产出代码时，筛选代码质量的能力变得更重要。
这与Claude Code团队的做法一致：把人的注意力从「有没有写对」转移到「写得值不值」。写对的问题交给AI检查，写值的问题才需要人来做判断。
当AI帮你挡掉90%的低级错误
这种转变对工程师的职业发展路径提出了新要求：不再是以写完多少行代码为荣，而是以做出多少有价值的判断为荣。技术债的识别、架构决策的权衡、业务逻辑的完整性——这些才是人类工程师不可替代的核心竞争力。
坦白讲，这对习惯了「卷代码量」的工程师是个挑战。但趋势已经明朗：AI不会替你确认最后的效果，它只能提醒你哪里需要再看一眼。最后一道闸门，永远是人。
Claude Code团队的解法不是加人，而是把人从机械检查里抽出来，只做真正需要人类判断的事。
AI负责机械性检查：空指针、边界条件、并发安全
AI能稳定完成的，是那些有固定模式的检查项：空指针、异常处理、边界条件、并发安全。这些检查靠经验也能做，但人做容易因为疲劳或赶时间漏看，AI专注且不知疲倦。
一个团队引入Claude之后，在REVIEW.md里加了这样一条规则：「检查测试代码的mock是否和被测逻辑一致」。之前这种问题经常靠reviewer的个人习惯去发现，现在成了标准化检查项。
当然AI也会误报。比如有次它标记「这个接口没有rate limit」，但实际上rate limit在API Gateway层统一做了，接口本身不需要。这类问题需要在REVIEW.md里显式排除，或者让reviewer知道怎么识别和忽略。
更狠的是，这类误报反而帮团队暴露了文档缺失的问题。有些架构决策没人写下来，AI先替你问了。
人负责理解意图和业务覆盖
人剩下的工作，是理解改动的意图、评估架构决策是否合理、判断业务逻辑是否覆盖完整、发现「代码能跑但方向错了」的问题。
某团队复盘后总结出一条原则：让人类的判断力聚焦在真正需要的地方。具体来说，reviewer不再逐行看语法对不对，而是重点回答三个问题：这次改动的核心意图是什么、有没有覆盖所有边界case、有没有引入不必要的复杂度。
这直接导致了新人培养周期的变化。原来新人需要先学团队的review习惯，再慢慢积累判断力，现在通过AI先做机械检查、人做意图判断的模式，新人一周就能开始产出有价值的review意见。
Bug漏检率从41%降到11%的数据背后
某团队使用Claude Code两个月后，Bug漏检率从41%降到11%。这个数字背后的机制不是AI变强了，而是检查项被重新分配了。
人机分工重构前后对比
这11%也不是终点。同样那篇复盘提到，安全类问题的误报率仍然较高，需要团队在REVIEW.md里定制排除规则。这说明AI和人的分工还在迭代，不是一次配置就固化。
落地实践：pipeline里的持续审查
GitLab CI与Claude Code的集成路径
把上述分工落到工程里，关键是触发时机和反馈速度。某团队在GitLab CI里加了Claude Code的步骤，PR打开后自动运行code-review命令，然后把结构化意见直接发到MR评论里。
GitLab CI中的AI评审流水线
触发时机有三种：MR创建后一次、每次推送后、手动触发。流量高的仓库建议用手动或MR创建后一次，避免频繁推送带来大量成本。
从单Agent到Agent-Teams的协作演进
单个Claude Code Agent已经能覆盖大多数日常review场景，但复杂项目开始尝试多Agent协作。比如一个Agent负责代码风格和规范检查，另一个负责业务逻辑覆盖，还有一个负责安全扫描。
这种分工的前提是规划文档写得足够清晰。规划文档成为驱动Agent团队的「需求规格书」，不同Agent拿着各自专长去验证不同维度。
不过多Agent的成本目前还比较高，建议先从代码review、bug调查这类低风险任务入手，跑通后再扩展到核心业务代码。
哪些场景适合先用，哪些需要谨慎
适合先用的场景：新入职团队快速建立review标准、历史代码库突然引入AI生成代码、review积压严重需要紧急疏通。这些场景的共同点是「人手不足或标准不统一」，AI能补足这部分缺口。
需要谨慎的场景：核心安全模块、涉及外部依赖的重大架构变更、团队正处于高压发布期。这些地方人的判断不可替代，AI只能做辅助提醒。
坦白讲，这套机制的核心不是AI有多强，而是团队愿意重新定义「reviewer该做什么」。
现在可以做的第一件事：在现有MR流程里加一个AI review步骤，先跑两周看误报率，再决定要不要调整REVIEW.md里的规则。不要一开始就追求完美分工，先让AI承担最枯燥的那部分检查，人慢慢适应新的review节奏。
参考文献
- Claude Code团队工作原则分享
- 我用 Claude Code 做 Code Review 两个月，Bug 漏检率从 41% 降到 11%
- Building a Real AI Code Review Pipeline with Claude Code
- 基于Claude Code 的GitLab CI 代码评审
延伸入口
- 原文归档：tobemagic.github.io/ai-magician…
- 公众号：计算机魔术师
