Anthropic公开Claude Code团队内部代码审查工作流

原创 心兰 2026-10-17 08:00 江苏

↑阅读之前记得关注+星标⭐️，😄，每天才能第一时间接收到更新

当AI写了团队90%的代码、每天合并提交达到3万次时，人类程序员已经彻底读不过来了。

面对这种情况，Claude Code团队交出的答卷是：把绝大多数阅读工作交给机器，让人类审查时间降到最低，同时保证线上事故和代码回滚率不升反降。

从今年6月到9月，Claude Code代码库合并的Pull Request（PR）数量翻了一倍以上，但需要回滚的比例下降了超过40%。

他们没有取消代码审查，而是重构了整个流程：让机器承担大部分阅读，保护人类的时间和注意力，全力保障能够快速撤回错误。

重新思考代码审查的目的

智能体写代码的速度极其惊人。在Anthropic的代码大仓库里，每天合入的代码变更从5月的约2500次，暴增到9月的超过30000次。

Claude Code有独立的仓库，同样承受着巨大的交付压力。在这样的速度下，由人类逐行进行代码审查，几乎是不可能的任务。

代码审查主要做两件事：

第一，在代码发布前发现并修复问题。

第二，在团队内部建立共享的上下文，让大家理解代码库。

过去，审查是写完代码后的最后一道关卡：写好代码，提交PR，然后坐等同事来挑错。

现在，审查贯穿在编码的整个过程中，就像边打字边运行的拼写检查。大部分代码变更在送交人类眼球之前，已经被Claude自己审查并修复过至少一次。常规错误在前面就被消灭了，团队的精力得以留给更高层面的审视。

稀缺资源：人类的时间和注意力

团队的目标是把有限的人类注意力留给机器解决不了的问题。

人类的时间成本包含两块：一块是审查代码花的时间，另一块是修复坏代码引发线上故障花的时间。省下审查时间却导致线上事故激增，没有任何意义。

现在的指标是：在Claude Code的相关仓库中，绝大多数PR只需最多一个人类参与即可合并，这个人甚至可以是代码提交者本人，同时绝不增加回滚和线上事故。

为了衡量这一点，团队密切追踪每个PR的人类审批次数、人类评论数、PR等待人类处理的时长。回滚率和事故率则是底线指标。

代码变更的生命周期

一个典型的改动，从工程师的电脑或者Slack中的Claude会话发起，会穿过七层审查。

1. 任何人看到代码之前，先跑验证

绝大多数审查发生在PR创建之前。

工程师会给Claude提供可运行的验证手段，比如自动化测试、编译构建，或者用来和设计图比对的截图，要求Claude直接展示运行输出，而不能只说一句搞定了。随后，一个子智能体会带着全新的上下文重新审视这段diff变更。

Claude Code的创始人Boris Cherny把给Claude提供验证手段称为拿到好结果最重要的一件事。他估计这能让最终结果好上两到三倍。

在提交PR前，工程师还会运行几个内部技能：一个专门找Bug，一个负责精简diff，还有一个进行端到端行为检查。UI改动还会自动比对设计规范。

如果自动化审查总是抓出同类问题，团队会从源头修正：修改技能，增加静态检查规则，或者更新两份关键指南：

CLAUDE.md告诉Claude项目的技术栈、规范、目标和非目标。每次审查都会加载它。团队会保持它短小精炼，详细内容链接到其他文档。审查器会自动标记违反其中规则的代码，也会揪出让指南内容过期的修改。

REVIEW.md由模块负责人编写，告诉审查器当前代码最该关注什么。好规则通常很短，会明确定义当前仓库里的失败长什么样，比如文档写错了就是说谎，配置搞错了就是路由异常；同时限制挑刺的数量，排除不需要审查的路径，要求给出确切的文件和行号作为证据，并且在没有问题时必须明确给出零错误的统计。

2. 每个PR都有专属AI审查

每个PR在人类介入前都会接受一次Claude审查。AI会结合整个仓库的上下文和PR的预期目标来研读diff，确认改动是否解决了目标问题、是否适配系统架构、是否会破坏其他模块。遇到Bug修复，它会追查根本原因。

内部PR获得实质性审查意见的比例从16%大幅提升到了54%。超过1000行的大PR基本都能被抓出问题，而小型改动大多能顺利通过。

为了防止误报，审查意见在展示给人类之前，还会经过其他智能体投票验证。多个智能体同时排查Bug，另一组智能体对发现的问题进行投票，只有达成足够共识的意见才会发布出来。单纯涉及代码风格、诊断信息或清理建议的意见会被直接过滤掉。留下来的问题会按严重程度排序，标上重要、次要或原本已存在。

所有被标记出的问题都必须得到回应。开发者要么动手修复，要么给出理由关闭讨论。很多时候智能体在夜间就会接手修复，作者第二天上班时，代码已经自动完成了新一轮审查。

3. 具备一票否决权的自动化安全审查

安全审查是独立的自动化流程。

只要Bug审查或安全审查中还有未关闭的议题，PR就绝对无法合并。开发者必须修复代码，或者填写简短理由来清除误报。

如果在后续提交中修复了该问题，系统会自动关闭对应的议题。

4. 自动化CI检查门禁

常规门禁一应俱全：代码风格检查、类型检查、多平台测试、打包构建。一个典型的CLI改动在人类查看前可能会跑几十项检查。

PR模板必须填写该改动如何测试、如何回滚。Claude可以代写这些内容，但触发该改动的人类必须签字确认。

5. 按风险等级划分的人类审批

修改文档与修改自动更新模块的风险完全不同，对应的审查机制也不同。

风险等级由代码改动本身决定，而不是由提交者决定。

系统先由分类器读取改动并划分风险等级，再由第二个分类器研判该改动是否需要额外的人类介入。敏感路径和CI工作流文件，永远需要人工介入。

只有在受信名单上的核心团队成员才能走轻量审批通道，其他人必须拿到第二个人类的批准。智能体的批准永远不能算作人类批准。自动化审查可以通过低风险改动，但无法替代明确要求人工审批的席位。

谁指派智能体写代码，谁就对代码负全责。在智能体编写的PR中，下达指令的人就被算作必须到场的审查人之一。

每一次审批只针对特定的某次commit生效。一旦有新的未被系统担保的代码推上来，比如智能体的新提交，或者手动解决的冲突合并，原有的审批立即作废，必须重新审批。

6. 合并队列、特性开关与灰度发布

合并队列会把改动合入最新的main分支重新跑一遍全部检查，防止两个单独能跑通的PR合在一起把主分支搞挂。

新功能通常会先通过特性开关向Anthropic内部员工开放，高频的内部使用能赶在外部用户之前暴露问题。对外发布时，最新版本通道先走，稳定通道随后跟进。

7. 快速发现与极速回滚

难免有漏网之鱼，最后一层防线就是快速止损。

特性开关不需要重新部署就能直接关掉。团队每周有专人值班排查故障，复盘时会追溯前面的哪一层本该拦下这个问题。

团队目前正在开发自动熔断机制，计划在回滚和事故率上升时自动收紧审批权限，在此之前，他们不会贸然推进更大范围的零人工合并。

放慢发布节奏确实可以减少错误，但这只是因为做的事情变少了。更健康的做法是提升发现问题和解决问题的速度。

如何让AI审查器越来越聪明

代码审查系统处于持续的自我进化循环中。

团队把过去所有引发事故的PR、修复提交以及回滚记录做成了评估测试集，每天运行审查器进行跑分。

为了避免审查器为了追求检出率而变成乱挑毛病的话痨，团队通过人类对审查意见的处理动作来衡量噪音率：接受修复、指明AI判断错误、确认是既定行为、还是判定无所谓。此外，团队还会拿没有Bug的干净PR去测试，看AI会不会给出误导性的有害修改建议。团队明确规定：抓住真Bug是第一优先级，压减审查轮次排在第二。

当作者也是智能体时，审查噪音的杀伤力会被放大。人类扫一眼觉得无所谓可以忽略，但智能体收到意见就会去改，一改就会产生新的commit，进而触发新一轮审查。

审查过程必须能够收敛。曾有一个CLI相关的PR，智能体作者和智能体审查器在夜里互相拉扯了五十多轮，最后不得不由人类叫停。

用git blame分析那些被反复揪住的代码发现，其中59%的内容在第一轮审查时就存在了。审查器并不是在不断发现新Bug，而是在每一轮里挤牙膏一样多挑出几个原本就有的老毛病。

为了解决审查死循环，团队引入了硬性规则：
审查轮次设限：超过三轮，审查器必须要求作者停下来重新思考方案。
后续轮次只审新生成的diff。
指出整类Bug，要求作者全局排查，不要每次只改一行。
禁止重复发布已经发过的审查意见。
夜间跑批：审查智能体会在夜间主动扫描现有代码库，提前扫除老Bug。

必须留给人类的核心阵地

把高级工程师从深度工作中拽出来找低级错误，成本极高。在Anthropic，人类的工作已经从逐行阅读代码，转向机器干不了的决策：

判断该不该做：把握产品方向、调性与功能范围。即使在审查瓶颈已经解决的团队，来自团队外部的PR依然需要人工过目，去评估做这件事本身的意义。
高风险代码把关：支付计费、自动更新逻辑以及CI核心流水线。
架构演进：确定未来会被其他人照搬的底层模式。
审查证据链：测试运行结果、执行命令及其返回值、对比截图、审查器的发现报告。如果看不出自动化检查会漏掉什么，就要启动严肃审查，不能随便点通过。
为结果负责：无论代码是谁敲出来的，最后必须由人类来背书承担后果。

团队之间如何共享代码认知

代码审查以往扮演的第二个角色，是让成员通过读代码了解系统演进。如果全交给机器读，大家怎么掌握系统？

团队在这个环节没有设立繁琐流程。团队里没有任何一个人能在脑子里装下整个Claude Code的完整模型，他们认为也没这个必要。

当工程师需要了解某块代码时，会直接让Claude针对那个切片生成一份即时解说。这只需要几分钟，而且反映的是最新代码状态。

有人甚至会让Claude生成一个可视化的小工件，用自己最容易接受的方式把逻辑直观展示出来。

在需要节省精力的情况下，这比一行行看细枝末节的diff有效得多。看别人改一行文案学不到什么，但在你要修改某个模块前让AI讲一遍架构，收获会大得多。团队默认在公开的Slack频道协作，大家能实时看到别人在做什么。

谁上线，谁负责

如果在合入中小型改动后出现问题，团队惯例是由提交者去处理修复。以下机制保证了这套模式不翻车：

改动保持小步快跑，易于审查、调试和回滚。

一切操作可逆。特性开关、快速回滚和灰度发布能在几分钟内抹平失误。

风险决定防线。越关键昂贵的代码，配备的人力和检查越重。

问题暴露极快。通过内部使用和监控遥测迅速抓出回退。

这不是问责甩锅。由提交者主导修复，是因为他拥有最完整的上下文。故障复盘的重点永远是改进系统机制。

同时，这种责任是透明分担的。大家在公开频道工作，任何人都能看到别人的进展并提供建议，这保证了不需要层层卡关也能维系高质量。

发现方向错了就果断撤退

智能体让写代码的启动成本变得极低，这也意味着有些代码写完后根本不应该合入。

经常有人在频道里提问为什么这么做，指出之前的技术决策，或者提供一个更简单的路径，作者就会主动关掉或者重构PR。

由于代码写起来极快，放弃一个PR不会让人产生心血白费的沉没成本。关键在于及早在讨论线程里讨论替代方案，而不是等PR全部做完了再去提反对意见阻拦合并。

如何落地这套流程

这套工作流所需要的工具，业界目前基本都已具备：

提交PR之前

• • 在简短的CLAUDE.md中列出智能体可运行的检查命令，配置好格式化和静态代码检查钩子。

• • 在本地运行代码审查和安全审查，或者让拥有全新上下文的子智能体过一遍diff。

• • 引入REVIEW.md，把经常重复出现的审查意见沉淀为规则。

PR提交之后

• • 强制要求CI通过，在PR模板中加入测试说明、风险评估和回滚步骤。

• • 在一个仓库中接入AI审查器，花几周调试REVIEW.md的规则，再逐步推广。

• • 引入自动化安全审查，强制要求合并前必须解决所有审查议题。

• • 根据风险调整审查力度：常规改动快审，高危模块深审。

• • 限制审查轮次，前几轮之后只审新增的diff。

审批阶段

• • 制定清晰的风险等级，根据代码改动的内容而非提交者身份来定级，先严后宽。

• • 只给高信任度的提交者开放轻量审批通道。

• • 利用CODEOWNERS和分支保护规则，强制要求认证、计费、CI工作流以及安装程序等关键模块必须有人类审批。

• • 严禁机器人的批准充当人类审批名额，一旦有新commit提交，立即重置审批状态。

合并及后续

• • 启用合并队列、特性开关、内部先行体验、灰度发布以及一键回滚机制。

• • 把历史故障和回滚案例转化为评估测试集，在提示词、工具或模型更新时，重新评估审查器的能力。

• • 监控人类耗费的审查时间，同时以回滚率和线上事故率作为安全红线。

代码审查从根本上说是风险控制。如果能把机械的找茬工作彻底交给机器，人类工程师才能真正把精力收拢到架构、方向以及系统的最终安全性上。

--end--

最后记得⭐️我，每天都在更新：如果觉得文章还不错的话可以点赞转发推荐评论

/...@作者：你说的完全正确（YAR师）

跳转微信打开