AI写完代码如何安全上线？拆解Claude Code团队审查流程

AI写代码越来越快，但把代码审查和部署全交给AI，你放心吗？当每天合并的变更数量暴涨，逐行人工审查早已跟不上节奏。Anthropic最近分享了Claude Code团队的代码审查流程，给出了一个可复用的答案：在多智能体协作下，合并PR数量翻倍增长，需要回滚的比例却下降了超过40%。这套流程是如何运转的？对普通团队又有哪些借鉴意义？

代码产量暴增带来的审查压力

在Anthropic的单体仓库中，每天合入的变更从5月的约2500个增加到9月的超过3万个。这个数量级的变化说明，当代码产量快速增长时，逐行人工审查会面临巨大压力。

为了解决这个问题，Claude Code团队推出了一套Code Review流程，包含验证、CI、AI审查、安全审查、人工审批、合并和快速回滚几个环节。下面用一个具体功能——更改订单金额计算规则——把整个流程串起来。

开发环境验证：功能与代码的双重自测

开发完功能后，第一步是验证。这包含两部分：一是验证功能是否达到需求，可以在本机的Agent开发环境中进行。比如用Claude Code开发了一个功能，需要提供相应的工具和环境来检查实际效果——开发的是网页就让它能通过浏览器访问，涉及UI就提供截图作为参考，让它对照检查。

二是代码审查。这里的关键做法是：把需求和代码改动交给另一个智能体来检查。为什么要换一个新的智能体？因为写代码的智能体保留了之前的推理和对话上下文，回头检查时可能沿着原来的思路走，漏掉同样的问题。而一个拥有全新上下文的智能体可以提供独立的第二意见。也可以尝试让其他模型交叉检查，不过换个模型并不意味着一定审得更好，所以很多人会用不同的模型、不同的AI工具进行交叉Code Review来保证效果。

这一步相当于开发提交代码之前的自测：先验证功能，再检查代码，完成之后就可以提交PR了。

CI检查：提交后系统自动再查一遍

提交PR之后，项目会自动运行一套提前配置好的检查，这就是CI（持续集成）。还是拿订单金额计算举例：本机已经验证过商品总额减去优惠加上运费结果是对的，但这次修改会不会让其他订单场景也出问题？比如没有优惠券时怎么计算、多个优惠券叠加时又怎么算？这些场景都可以提前写成测试，提交后自动运行。

除了业务测试，系统还可以检查代码能否正常编译、有没有常见的代码问题、整个项目能否成功打包。具体检查哪些内容由项目提前配置，检查结果会显示在PR页面上。如果某项必须检查失败了，就根据错误信息修改代码再提交，检查通过之后才能继续合并。

持续集成（CI） 是一种开发实践：开发者频繁地将代码变更合并到主干，每次合并都触发自动化构建和测试流程，以便尽早发现集成错误。在PR场景下，CI通常由代码托管平台（如GitHub Actions、GitLab CI）自动触发，运行预先配置的脚本，执行编译、单元测试、静态代码分析、打包等任务。CI的价值在于将“集成”从一次性的、高风险的手工操作，转变为持续、小步、可重复的自动化过程，从而显著降低多个变更组合后才发现问题的概率。

AI审查：多智能体并行与投票机制

提交PR后，除了运行CI检查，还会进入一个非常重要的环节——AI审查。多个智能体并行查找代码中的问题，它们会先看PR描述了解改动意图，再结合代码变更以及整个仓库的上下文来审查。

审查主要看几个方面：这次改动有没有解决问题、是否适合现有系统、会不会影响其他功能；如果是修复bug，还会检查有没有找到根本原因。比如修改了订单金额计算规则，AI不仅要看这次金额算得对不对，还要检查优惠券和折扣的计算顺序是否符合现有规则，修改这个公共方法会不会影响退款金额的计算。

AI找到的问题不会直接全部交给开发者，一组智能体会对每条问题进行验证和投票，只有足够多的智能体认为问题确实存在，才会发布对应的审查意见。这个过程还会应用过滤规则，比如仅涉及代码风格、格式整理或代码清理的意见会被过滤。最终留下的审查意见会按严重程度排序，并标注为重要问题、小问题或原有问题——原有问题不是说它不严重，而是说它在这次PR之前就已经存在，避免把旧问题算到当前作者头上。

每个被发现的问题都需要提交PR方回复：确实有问题就修复；如果认为是误报或有理由不修改，就说明原因并将这条问题标注为已解决。这个过程也可以由智能体协助完成。只要缺陷审查或安全审查中还有未解决的发现项，这个PR就不能合并。

避免AI审查陷入无限循环

用多智能体审核时经常会出现一个问题：AI审查提出问题，写代码的AI改完再交回去审，这一轮又发现几个新问题，只好继续改，来回可能几十轮都结束不了。

为什么会这样？因为每次检查的范围都很大，审查的AI可能不断从已经看过的代码里找出一些之前没注意到的问题——这些问题不一定是刚修改造成的，但只要每一轮都有新意见，修改-审查就会一直继续。

可以从三个方面控制：

设置轮次上限。 来回三轮如果还没通过，就提醒作者先停一停，重新考虑整体方案。比如修改订单金额计算，AI连续改了三轮优惠券和满减叠加的结果还是不对，这时候就应该重新确认优惠到底按什么顺序计算、实现方案是不是有问题，避免继续在错误的思路上打补丁。注意这不是说三轮之后自动放行，而是需要重新思考。

逐步缩小复审范围。 前几轮可以结合整个项目全面检查这次改动及影响，后面再修改时就重点检查新增的差异。比如订单计算逻辑和相关调用已经审过了，这一轮只调整了金额和输入方式，复审就重点检查这次调整及影响，减少对已审内容的反复检查。

让意见一次说清。 比如发现一处金额计算用了double存在精度风险，就让作者一起排查其他同类的金额问题，避免这一轮改一处、下面又发现另一处。已经提出并处理过的问题也不要每轮重新发布、让作者反复回应。这样每一轮审查都有明确范围，能推动问题处理，减少两个AI一直互相修改却迟迟无法完成的情况。

多智能体系统（Multi-Agent System） 指由多个具备自主决策能力的智能体协同完成任务的架构。每个智能体拥有独立的上下文、角色或目标，可以通过并行、投票、辩论等机制聚合结果。在代码审查中，多智能体并行审查能覆盖更广的视角，而投票机制则用于过滤个别智能体的误报，提升审查意见的置信度。这种架构的核心优势在于：单个智能体的判断可能受限于其上下文或随机性，而多个独立智能体的共识能显著降低错误率。

安全审核：覆盖常见漏洞模式

接下来是安全审核，会对常见的漏洞模式检查代码，主要关注以下几类问题：

• SQL注入： 用户输入直接拼进数据库查询语句，可能让用户通过特殊输入改变原本的查询逻辑。
• 跨站脚本（XSS）： 把用户提交的内容直接显示在网页上而没有适当处理，可能让恶意脚本在其他用户的浏览器中执行。
• 身份验证和权限控制： 比如订单接口只检查用户有没有登录，却没有检查订单是否属于该用户，导致可以查看和修改别人的订单。
• 不安全的数据处理： 后端没有验证输入、直接信任前端传过来的价格或优惠金额，可能让用户篡改订单的应付金额。
• 第三方依赖中的已知漏洞： 项目使用的框架和软件包也可能存在安全问题。

团队可以根据项目的安全要求调整检查规则和敏感程度。发现问题之后需要修复，或者确认属于误报并说明理由；还有未解决的安全发现项，PR就不能合并。

SQL注入 是一种常见的注入攻击：当应用程序将用户输入直接拼接进SQL查询语句时，攻击者可以通过构造特殊输入（如 ' OR '1'='1）改变查询语义，从而绕过认证、读取或篡改数据库数据。跨站脚本（XSS） 则是将未经过滤的用户内容输出到网页中，使恶意脚本在其他用户的浏览器中执行，可窃取Cookie或会话信息。这两类漏洞长期位居OWASP Top 10前列，安全审查的核心目标之一就是识别这类“未经验证的用户输入直接进入敏感上下文”的模式。

人工审批：按风险分级决定参与程度

人工批准环节的核心是根据变更的风险决定需要多少人参与审查。Anthropic把风险分成低、中、高三级：

低风险如文档、文案、并控内部使用的功能，在自动审查和安全检查通过后可以不再需要人工批准。中风险如普通的产品功能变更，以及涉及缓存自动更新器或系统提示等敏感区域的变更，需要一位人工审查者批准。高风险则包括风险最高、人工批准者级别最高的代码，以及少数明确规定必须有两人批准的代码路径，这类变更需要两名人工审查批准。

风险等级不是提交PR的人自己随意选择的。Anthropic会使用分类器根据具体的代码变更判断风险，再由另一个分类器检查这次变更是否还需要额外的人参与。

拿订单金额计算来说，一旦算错就可能导致用户多付款或商家少收钱，所以这类改动可以被规定为高风险，要求两个人审查。

合并队列与发布后的持续观察

前面的检查和批准都满足要求后，PR进入合并队列。队列会在最新的主分支基础上加入准备合入的变更，重新运行检查，通过后才正式合入；后面的PR也会基于更新后的主分支接受检查，降低多个改动各自通过、组合起来却出问题的风险。

比如一个PR修改了订单金额计算规则，另一个修改了优惠券处理逻辑，各自的测试都没问题，组合起来却可能算错金额。合并队列就是为了减少这类组合问题。

合并之后，新功能通常还会放在功能开关后面，先向Anthropic内部员工开放——他们每天都在大量使用Claude Code，有机会在普通用户遇到问题之前先发现一些问题。对外发布也分阶段进行，在Claude发布有两个通道：Lattice通道面向少量新用户，Step通道才是稳定版本，新版本先进入Lattice通道，Step通道随后跟进，让版本先经过一段时间使用和观察，再逐步扩大范围。

即使经过这些检查，错误仍然可能落到线上，所以发布之后还需要持续观察运行情况。如果问题涉及带开关的功能，可以先关闭开关停止开放；如果开关无法解决，就根据情况撤销有问题的变更，或者修复后发布新版本。这一层的重点是尽快发现问题，并且有办法快速恢复控制对用户的影响。

功能开关（Feature Flag） 是一种允许在不重新部署代码的情况下动态开启或关闭某功能的机制。新功能上线时，可以先将其置于关闭状态，再通过配置逐步向内部员工、少量用户或特定区域开放。一旦发现问题，可以立即关闭开关，快速停止影响，而无需回滚代码。功能开关与分阶段发布（如金丝雀发布、灰度发布）结合，能显著降低新版本对全体用户的风险，并为问题排查争取时间。

人的注意力应该放在哪里

当大量常规检查交给机器和AI之后，人的注意力应该放在哪里？这并不代表人不在审查PR中，而是根据风险和检查证据，把精力用在更需要判断的地方。以订单功能为例，可以分为五个方面：

1. 决定是否值得做，把握方向、范围和用户体验。 比如要不要同时做满减、优惠券和积分抵扣，还是先把一种优惠做好，AI可以协助分析，但最后做什么、做到什么程度仍然需要人来决定。
2. 审查高风险的代码。 比如订单金额修改之后，优惠计算顺序、金额精度，以及订单金额和支付金额是否一致，都值得人重点检查。
3. 把关架构设计。 比如订单支付退款都要处理金额计算，规则应该放在哪里、哪些模块负责调用，需要提前想清楚，避免每个模块各写一套。
4. 阅读验证证据。 AI说测试通过了，要看它测试了哪些场景——是只有普通订单，还是覆盖了优惠叠加、退款等结果，还需要判断测试是否覆盖了重要风险。
5. 对结果负责。 上线后如果用户反馈金额不对，需要有人判断影响范围，决定关闭功能、修复或回滚，并跟进受影响的订单。代码虽然由AI编写，交付结果仍然需要人来负责。

这套流程的价值在于：把可自动化的检查交给机器和AI，把需要判断、权衡和担责的部分留给人。合并PR数量翻倍增长、回滚比例下降超过40%的数据背后，是流程设计与职责划分的共同作用，而不只是模型能力的提升。