Claude Code 团队是如何进行代码审查的
内容提要
Anthropic的Claude Code团队超90%代码由AI生成，逐行人工审查成为瓶颈，遂转向人机协同分级审查：提交前由Claude自测并交叉验证，PR先经AI审查、多智能体投票过滤误报，再按风险分级决定人工审批人数，低风险变更可零人工合并。配合自动化安全检查、合并队列、功能开关与快速回滚，PR量翻倍而回滚率降超40%。人类专注方向决策、高危代码与最终责任，事故复盘持续转化为评测集以优化审查器。
延伸解读
审查目标从“有人看过”转向“风险由谁拦截”
文章指出，传统审查常把“是否有人逐行读过代码”当作质量指标，但这只是粗糙的代理指标。Claude Code 团队改为追问：这项变更可能带来什么风险，应由哪道自动化或人工检查最有效地拦截。由此审查从流程终点的关卡变成持续运行的动作，多数变更在提交人类前已被 Claude 审查并修复一轮，人类注意力被留给更高层面的质疑与决策。
风险分级决定人工审批，但机器批准不能替代人类名额
文章按变更本身而非提交人划分低、中、高风险，分别对应零人工、1 人、2 人批准。低风险变更在自动化审查与安全检查全绿后可无人工合并，但仅限受信任作者；关键路径如敏感区域和 CI 工作流始终强制人工介入。文章特别强调，Agent 的批准绝不能冲抵人类审批名额，且新提交会使已有批准失效，责任仍由指导 Agent 的人类工程师承担。
审查器需要收敛机制，否则 Agent 互审会陷入循环
文章披露，Agent 作者与 Agent 审查器可能来回拉扯，曾有一个 CLI PR 夜间经历 50 多轮审查与修改，直到人类介入才停止。团队发现审查器反复提出的意见中约 59% 的代码从第一轮就存在，说明它常在挖掘旧账而非新 Bug。为此团队设置轮数硬性封顶、后续仅审查增量 Diff、要求一次性修复同类问题，并禁止重复提出已发布意见，同时把“通过所需轮数”纳入指标。
人类保留方向决策、高危代码与最终责任
文章明确，人类工作重心已从通读每行 Diff 转向机器不擅长的领域：是否该做这个需求、产品品味与范围界定；计费、自动更新器、CI 核心工作流等高危代码；可能被其他模块效仿的架构设计；以及审阅测试输出、命令结果和截图等验证凭据。每个合入变更都必须有对应人类全权负责，团队也保留对团队外部提交变更的人工审查，以守住“是否真的有必要做”的追问。
Q&A
Claude Code 团队为什么放弃逐行人工代码审查？
因为 Claude 编写了 Claude Code 自身约 90% 的代码，PR 数量激增（2026 年 6 月到 9 月翻倍），逐行人工审查成为生产力瓶颈。团队认为“是否有人读过代码”不是精准指标，真正核心是“变更可能带来什么风险、应由哪道检查最有效拦截”，因此转向人机协同分级审查。
Claude Code 团队如何对 PR 进行风险分级和人工审批？
风险等级由代码变更本身决定，而非提交人。低风险（文档、文案、Feature Flag 后的增量改动）在自动化审查和安全检查全绿后无需人工批准；中风险（常规产品功能、缓存/自动更新器/系统提示词等敏感区域）需 1 人批准；高风险（核心代码、固定双人确认路径）需 2 人批准。分类器通读改动评估层级，第二个分类器甄别是否仍需额外人工把关。
AI 审查器提出的意见如何避免误报和无限循环？
审查意见先由多个 Agent 并行排查，再由独立验证 Agent 投票，只有足够多 Agent 一致认为问题属实才发布；纯风格、日志、微小清理意见直接丢弃。为防无限循环，团队设置轮数硬性封顶（三轮后要求作者重新审视方案）、后续仅审查增量 Diff、要求一次性修复同类问题、禁止重复提出已发布意见。
在自动化审查之外，人类工程师还需要负责哪些核心工作？
人类专注于机器不擅长的决策领域：是否该做这个需求（方向把控、产品品味、范围界定）、高危敏感代码（计费系统、自动更新程序、CI 核心工作流）、架构演进、研读验证凭据（测试日志、命令结果、截图等），以及对结果全权负责。团队仍严格保留对团队外部提交变更的人工审查。
Claude Code 团队如何让代码审查器持续变聪明？
团队将所有线上事故转化为评测基准：收集历史事故 PR 及其修复/回滚提交，由熟悉业务的工程师确认 Bug 性质，审查器每天对照评测集运行。同时通过观察人类对评论的处理行为（修复、指出错误、解释设计等）衡量审查噪音，并将审查器放到干净 PR 上统计假警报频率。原则是优先捕捉真实 Bug，其次削减审查轮数。
这套人机协同审查流程带来了哪些实际效果？
从 2026 年 6 月到 9 月，合并到 Claude Code 代码库的 PR 数量增加了一倍以上，而需要回滚的比例下降了超过 40%。内部推出 AI 审查研究预览版后，获得实质性审查意见的内部 PR 比例从 16% 跃升到 54%。团队目标是在最多一人参与闭环的前提下完成绝大多数 PR 合并，同时确保回滚率和事故率不上升。
团队如何保障合并后的代码质量与快速回滚？
采用合并队列（每次变更与最新主分支结合重跑所有检查）、功能开关（无需发版即可关闭）、内部员工先行试用、分阶段灰度发布（latest 先行、stable 滞后）以及一键快速回滚。每周轮值 on-call，故障复盘时倒查本应在哪个防护层级拦截。团队尚未引入熔断机制，希望在推动更多零人工合并前先落地断路保护。
