一个PR合入了。这个PR改了后台会话超时逻辑。代码写得不错，格式整齐，自动测试都过了，AI评审只提了一条小建议加个日志，人工评审也很快通过了。两周后，企业客户的数据导出开始大量超时失败。后台任务到了第四个小时就中断，但这些任务本来三小时就能搞定。工程组花了整整三天查日志、看提交历史，才终于定位到两周前的改动：它假设所有后台任务都能在一个常规的交互会话里跑完。但这个假设六周前在大客户定制层级上线时就已经不成立了，大客户的数据量远远超过普通用户。那次的产品改动并不在这次PR的代码差异里，AI看不见，点过批准的人也没把它连起来。修复只需要一行配置，但花了一周排查和向客户解释。
这个案例来自工程团队负责人的一篇公开复盘。这个12人的团队曾经把Claude Code引入评审，PR的流转时间从47小时压缩到了3小时以内。在尝到效率提升的甜头后，团队决定把人工评审设为可选。结果不到三周，那个改坏会话过期的改动就溜进了主干。作者后来总结，关键的错误在于把人变成了可选项。
这个事故揭开了一个长久以来的误解：在研发流程里，我们常常默认 PR 顺利获批，就等同于代码得到了充分理解。2026 年 10 月 15 日，Anthropic 的 Claude Code 团队公开了他们内部的代码评审实践，同时上线了面向企业客户的 Code Review 正式版。抛开宣传话术，他们内部改造代码评审的原因在于：机器写代码的速度已经数十倍于人类阅读的速度，过去靠人工通读代码来兼顾发现缺陷、理解上下文和承担责任的机制，已经难以维系了。
过去 Code Review 之所以有效，是因为人读代码很慢。花大半个小时读完几百行改动，这个慢动作实际上同时完成了三件事：第一，你在字里行间挑错漏，抓空指针和边界条件，这是缺陷发现；第二，你在脑海里把作者的意图跟全局架构对齐，顺便想起不久前刚给客户开了超长导出开关，这是上下文对齐；第三，你按 Approve，把自己的名字写进提交历史，线上出事跟着一起扛，这是责任绑定。
更深层的原因是，以前我们整个研发流程中最昂贵、最稀缺的环节是写代码，PR从来不是系统的瓶颈，所以没人想着去过度压缩审查时间。但在我们引入编码 Agent 以后，写代码的边际成本跌到了接近零。工程师让模型生成一段代码只要两三分钟，提交量在短时间内翻了几倍。当写代码不再构成阻碍，PR 流转就顺理成章成了整个交付链路上的最大瓶颈，最稀缺的资源变成了工程师的专注力。
边际成本的变化很快就把这三件原本绑在一起的事情给拆开了。自动化测试全绿，只能说明改动没有违反仓库里已有断言写明的规则。一个大客户功能上线时如果没有补齐长耗时导出的集成测试，测试套件自然一路绿灯。AI 评审没有异议，也仅仅意味着在当前的代码差异和周围几个文件的静态上下文里，没有发现明显的语法逻辑冲突或已知安全漏洞。至于人类评审者，一旦习惯了机器先扫一遍，点 Approve 的心态往往会滑向另一个方向：从过去的确认这段代码安全，变成既然机器没挑刺、自己也没看出明显毛病。
传统流程之所以把有人读过当有人负责的代表，是因为读完一段复杂代码要花很多精力，凡是愿意逐行啃完的人，往往也想清了系统风险。现在读代码成了机器的分内工作，但机器没办法在事故复盘会上替团队担责。真正要为线上事故向客户解释的人，退到了审查的边缘，既没有真正理解改动的系统影响，也在按下批准那一刻卸下了心理防备。批准依然在，理解和责任却流失了。
每次线上出事故，团队的第一反应往往是上紧发条：要求大家把 PR 读得再细致一点，靠人力把理解重新塞回流程。但在真实的工程吞吐面前，这条路走不通。首先是人类注意力的生理上限。SmartBear 和 Cisco 在一项涵盖 50 名开发者、320 万行代码的经典实证研究 中发现，人类评审代码的效率有一个硬门槛：每小时阅读量低于 300 行时，发现缺陷的质量最好；一旦阅读速度超过每小时 450 行，绝大多数情况下发现的缺陷密度就会大幅下滑。
把这个每小时 300 行的天花板放进今天的开发节奏里，工时立刻捉襟见肘。Anthropic 披露过一组内部数据：到 2026 年 9 月，他们的大单体仓库每天合并的代码超过 30,000 次，而 Claude Code 仓库里约九成代码由模型生成。普通团队即使达不到这个量级，工程师借助 Agent 让每周提交量翻上两三倍后，如果继续要求所有 PR 逐行精读，要么发布队列全线瘫痪，要么大家只能以每小时两千行的速度滑动屏幕，把代码评审变成心照不宣的形式主义。
退一步讲，就算我们真能花一个小时把那个过期的会话仔细看了三遍，问题还是会漏过去。因为真正致命的内容压根不在代码差异里。改动本身排版工整、异常处理健全，只看代码无论如何也推不出它会破坏六周前一个业务前提。Bacchelli 和 Bird 在探讨代码评审的一篇实证研究里早就指出，代码审查的核心价值不只是找 bug，更关键的是理解代码意图和知识传递。代码由人写的时候，写代码的人脑子里装着业务上下文，评审是两个大脑的对齐。机器大段生成代码之后，写代码的人自己对边缘假设的记忆也在变模糊。光看几张网页上的代码变更，谁也拼不出不在代码库里的隐性历史。
但这并不是人类独有的优势。如果我们细看这个故障，AI评审之所以没发现问题，是因为我们只给了它孤立的代码差异。如果我们也把团队的内部文档、产品变更记录和历史故障复盘都纳入系统，让它核对改动是否会影响后台任务时长，它同样有机会发现这一点。在模型推理能力迅速提升的今天，给 AI 加入跨系统上下文只是一个工程实现问题。指望人类用肉身记忆去硬扛越来越复杂的业务背景，既不现实，也不经济。
在真正构建上下文管道之前，我们必须理解现有工具的局限性。开源基准 ReviewBench 在跨多种语言的真实仓库上测试了十多个主流代码评审 Agent，发现它们普遍呈现出相同的特征：报出来的建议里绝大多数是对的，但真实存在的隐患却有一半以上漏掉了。独立机构对 CodeRabbit 在上万个 PR 上的实测 也表明，工程师直接忽略或拒绝了大量机器建议。显式结构中的语法、空指针、调用匹配等交给机器去过滤，而涉及到业务假设和架构决策的地方仍然需要人类的稀缺注意力来精准投放。
看清了机器只能抓局部、人类注意力稀缺的前提之后，Anthropic 并没有尝试造一个全知全能的超级评审员，而是把原先堆在 PR 页面上的评审工作，分流到了研发周期的三个位置。这套流水线从本地开发一直延伸到最终的合并门禁，把重心从追求批准速度转为守住代码背后的系统意图与责任防线。
第一道工序发生在 PR 之前：本地自证与交叉复审。代码在提交 PR 之前，必须先在本地跑完测试、构建和代码规范检查，并且在提交信息里附带真实的运行输出。随后，系统会唤起一个上下文全新的子 Agent，独立复查这次改动。刚写完代码的 Agent 会带着自己的推理惯性，容易把潜在的 bug 合理化；而一个只看改动结果、不知晓生成过程的干净 Agent，往往能更快挑出低级错误，把大部分低级问题截留在提交之前。
第二道工序发生在 PR 期间：自动化缺陷发现与收敛。在 PR 提交之后，Anthropic 让多组 Agent 从不同视角并行扫描改动，各自提出潜在缺陷或改进建议。另一组 Agent 扮演 verifiers 的角色，对发现的候选问题交叉投票，只有得到足够支持的才会在 PR 页面上呈现，同时屏蔽代码风格或者琐碎的清理建议。更重要的是，它引入了防止无限内耗的机制：如果写代码和挑错的两端都是 AI，双方很容易陷入无休止的相互打磨。Anthropic 为这个过程设置了三轮上限，如果三轮修改之后仍然不能收敛，它就会强制作者停下来重新设计。
第三道工序留在合并口：责任分流与强制签字。前面所有机器评审只负责提意见，没有放行或阻断 PR 的权力。改动能否合并，由串联的风险分类器决定需要几个人签字。低风险改动（比如纯文档、内部小工具，或是藏在功能开关后面的增量代码），如果测试全绿且作者在可信名单里，允许 0 人签字直接合入。中风险改动（比如常规业务逻辑，或是涉及缓存、自动更新器、系统提示词的敏感区域），必须有 1 名人类工程师批准。核心高危路径或关键配置，则强制要求 2 人签字。第二个分类器还会对低风险代码做二次复检，如果发现异常特征，随时可以把它升档到人工通道。
在责任分配上，Anthropic 坚持三条铁律：第一，Agent 的意见不算数，无论多少模型赞成都不能代替人类签字；第二，批准只针对具体 commit，一旦有新改动，批准立刻失效；第三，指挥 Agent 写代码的人，本身就是必须签字的人之一。这四个月里，Claude Code 仓库合入的 PR 数量翻了一倍以上，合并后需要回滚的比例降了 40% 以上，平均每个 PR 的评审轮次也从两轮多降到了一轮出头。机器可以跑腿，但放行的钥匙还在人手里。
对于大多数没有巨大吞吐压力的团队来说，照搬 Anthropic 的整套系统既不现实，也没必要。更具参考价值的做法，是把审查按风险拆开，把责任留在人身上。
实际落地的顺序应当由后往前推进。第一步，先看自己有没有快速回滚和灰度发布的能力。DORA 2025 年度的行业调查 指出，AI 的广泛使用在推高交付吞吐的同时，也在同步放大系统的不稳定性；而行业内九成以上的团队依然采用批量发布的模式。如果团队上线一次需要大费周章，线上出事无法在几分钟内回退，盲目压缩评审时间只会让更多未经深思的改动快速堆积到线上。没有扎实的回滚和监控兜底，谈自动化放行无异于拆掉刹车跑高速。
第二步，用真实的事故来构建自己的评估集。Anthropic 的做法是把每次线上故障和代码回滚都转化为测试用例，在调整评审规则之前先跑一遍真题。团队可以把过去半年导致过生产故障、紧急热修或严重阻断的二三十个真实 PR 整理出来，作为衡量 AI 评审工具的标准。只有当工具能稳定抓出这些曾经踩过的坑，而且不产生铺天盖地的无关噪声时，它才有资格进入主流程。
第三步，按团队规模定制审查流程。小团队（10人左右）适合把 AI 作为严格的预审：引入好用的评审工具，在仓库里写明架构红线与禁区，限制自动评审不超过三轮，守住模型批准不计入合规要求的底线。对文档和纯静态文案改动可以适度宽松，对涉及业务状态流转、计费、认证的核心逻辑则要老老实实交给人类工程师进行低速精读。
假如第二天另一个 PR 又不小心改了关键业务的超时时间，这个流程能在哪一步把它截住？指望一个机器人用几十行的 diff 理解团队几个月前的业务改动，几乎是不可能完成的任务。它要是不想溜进主干，要么是因为风险分类器看见它动了核心状态边界，硬是把业务上最清楚的工程师叫了过来；要么是因为来签字的工程师知道自己已经查过语法错误，坐在电脑前唯一要干的就是核对业务假设；或者前两步都没拦住，灰度监控在第一笔长耗时任务失败时就抓住了异常，直接触发了回滚。当 AI 把写代码和读代码的成本大幅压缩之后，代码评审的重心早已不再是字面上的挑错，而是如何把人类有限的注意力集中到不可推卸的责任上，并为随时可能发生的失误准备好退路。