AI Coding 时代，Code Review 应该怎么做？

AI 可以在很短的时间里写出大量代码，但团队理解、验证和承担这些代码后果的能力，不会自动同步增长。AI Coding 中的 Code Review，需要覆盖从需求判断到上线反馈的全过程：让机器承担可以重复执行的检查，让人集中判断目标、架构、风险和验证证据，同时保留及时发现问题与恢复服务的能力。

手持放大镜检查代码面板，旁边的勾选标记象征测试与验证

2026 年 10 月，Addy Osmani、Morgan Westlee Lunt 和 Qing Wang 发表了 How the Claude Code team does code review，介绍 Claude Code 团队如何应对 AI 带来的代码审查压力。下文以它为起点，结合公开工程案例和研究，讨论一套可以落地的做法。[1]

先给出我的整体判断：

  • 审查要提前。 写代码之前明确验收条件，开发过程中运行检查，提交 PR 之前完成自查和独立审查。
  • 证据要具体。 “AI 说完成了”“测试是绿的”“另一个 AI 也同意”都需要继续追问：具体验证了什么，遗漏了什么？
  • 审查要分工。 确定性问题交给工具，行为与上下文问题交给审查代理，方向、架构和重大风险由人判断。
  • 审批要匹配风险。 修改行数、作者资历和生成速度，都不能独自决定审查强度。
  • 合并之后仍需验证。 集成测试、渐进发布、监控、开关和回滚，是减少人工审查的必要支撑。
  • 审查系统也需要被审查。 既要衡量漏报，也要衡量误报、反复修改和总人力成本；事故应留下可以反复执行的回归用例。
  • 人必须保留责任与理解。 可以不逐行阅读所有代码，但必须有人理解关键机制、知道证据的边界，并对上线结果负责。

这些做法不一定需要同时引入。对多数团队，第一步是建立可靠的验收、证据和反馈，再逐渐调整人工参与的深度。

一、先看清楚：我们到底在优化什么

原文提供了几组背景数据：Claude 编写了约 90% 的 Claude Code 自身代码；6 月到 9 月，Claude Code 的合并 PR 数量增长超过一倍，而需要回滚的比例下降超过 40%。文章还提到 Anthropic 单体仓库的日合并变更从约 2,500 增长到超过 30,000，但明确说明 Claude Code 是另一个仓库。这些数字不能混为同一个统计口径。[1]

它们是团队的自述，足以解释为什么审查方式必须变化，但不是“AI 审查导致质量提高”的对照实验。PR 如何拆分、修改复杂度如何变化、事故怎样定义，都会影响结果。

我更关注的是，团队是否减少了完成一项有效变更所需的总成本。这至少包括开发、审查、返工、排障，以及后续维护。只压缩审查时间，却把工作转移给值班同事，不算真正提效。

可以持续记录下面几类指标：

观察对象 建议记录 主要用途
人的参与 每个 PR 的人工批准数、中位数和 P95、评论及实际审查时间 判断人力是否集中到了值得看的地方
等待 等待人工响应的时间、PR 从准备好到合并的时间 区分“工作量大”与“排队长”
质量 回滚比例、变更失败、事故严重度、用户影响 检查是否只是把成本转移到了上线后
审查效果 真问题命中、误报、漏报、修复轮次 判断审查器是否有用且能够收敛
长期成本 排障与维护耗时、架构规则偏离、重复实现 避免短期吞吐掩盖长期退化

其中，人工批准数及其分位数、评论、等待时间，以及回滚和事故，是原文强调的观察项；实际工时和长期维护指标是我建议补充的内容。原文希望多数 PR 只需至多一名人类参与，这个人可以是作者；这是一项流程目标，不应直接变成所有团队的考核指标。[1]

Google 的代码审查规范把目标放在代码库整体健康度的持续改善上，同时反对为了追求完美而无限阻塞改进。这种平衡在 AI Coding 中仍然成立。[2]

公开研究也提醒我们谨慎解释效率数字。METR 在 2026 年的研究更新中说明，开发者选择是否参加实验、是否提交某类任务，以及多个 Agent 并发工作时如何计时，都使生产率估计变得困难。不能把旧实验里的一个百分比，当成当下所有 AI 编程的结论。[3]

二、把验收放到实现之前，把审查放进开发过程

传统流程经常是代码已经写完，才开始认真讨论它是否正确。AI 提高生成速度后，这会导致审查成为一条越来越长的队列。

更有效的顺序是：先确定要验证的行为，再让实现过程不断接受反馈。PR 应当汇总已经发生的验证，而不应成为验证的起点。

例如，让 AI 修改一个多租户接口时，仅要求“实现按部门查询”不够。可以事先明确：普通用户只能访问本部门数据；管理角色的跨部门权限来自什么规则；分页和导出是否使用同样的权限；无权限时返回什么；日志中不能出现什么信息。这样，审查者有机会质疑验收条件本身，而不只是接受已经完成的代码结构。

验收还必须能执行。后端可以运行测试和契约检查；前端需要实际打开页面、操作关键路径并核对设计；性能修改需要基准和资源数据。对于复杂问题，还应有代表性的失败输入。

原文强调提交前运行测试、构建或截图检查，并由独立上下文的代理再次审查；查 Bug、简化差异、端到端验证和 UI 设计检查分别承担不同任务。文中引用 Boris Cherny 对验证价值的高度评价，其“效果提高两到三倍”属于个人经验估计，不宜当作通用测量结果。[1]

公开案例：让编译器接受一个外部答案的检验。 Anthropic 的 C 编译器实验中，多个 Agent 在编译 Linux 内核时会卡在同一个问题上。研究者引入 GCC 作为已知可用的参照，让大部分文件由 GCC 编译，只替换待验证的部分，逐步定位错误。团队还加强 CI，减少实现新功能时破坏旧功能的情况。[4]

这个案例最有价值的地方，是验证结果不完全依赖 Agent 对自己的解释。迁移到业务系统，也可以使用历史正确输出、协议规范、兼容性样例或已有系统作参照。但参照也有边界：旧系统可能有 Bug，历史输出也可能包含错误，不能不加辨别地奉为标准。

测试本身同样需要审查。一个测试即使执行成功，也可能只是重复了实现中的错误假设。应该追问：删掉关键逻辑后它会不会失败？错误租户、异常输入和并发操作是否真的被覆盖？Google 的审查指南明确要求检查测试是否正确、有用，不能因为它叫“测试”就默认可信。[5]

三、把项目知识变成可维护的审查依据

很多审查意见反复出现，并不是开发者每次都不会写代码，而是项目规则只存在于少数人的脑子里。AI 更容易遇到这个问题：它可以读代码，却未必知道为什么这段代码不能按另一种方式实现。

可以把知识分成三层：

层次 应当保存什么 适合的位置
项目上下文 技术栈、目标、非目标、模块边界、关键命令 简短的项目入口及链接文档
审查标准 什么后果必须阻断、需要什么证据、哪些内容不应重复评论 审查专用规则
必须执行的约束 依赖方向、类型检查、权限边界、发布条件 Lint、测试、CI、权限与分支规则

以 Claude 为例，CLAUDE.md 用于项目通用上下文，REVIEW.md 用于审查规则。审查规则应由熟悉模块的人维护，说明这个模块怎样才算失败：文档可能误导用户，配置可能把流量送错，账单可能算错钱。比起“注意代码质量”，这些描述更接近真正的风险。[6]

规则还应该限制无效工作：少提没有依据的风格意见，跳过适合交给既有工具的检查，报告问题时给出源码位置和行为证据；摘要先说明问题数量，没有发现就明确说没有发现。代码变更若使说明文档失效，也应一起修正。最后，需要抽样验证审查器是否真的使用了这些规则，而不是仅确认文件存在。

公开案例：OpenAI 放弃巨大的指令文件。 OpenAI 在 Harness engineering 中介绍，他们尝试过把大量知识塞入一个 AGENTS.md，后来改为简短入口加结构化文档。项目知识成为可导航、可检查的资料；能机械执行的架构约束则进入 Lint 和结构测试。[7]

我的理解是，规则文件应帮助 Agent 找到事实，不能变成另一套与代码脱节的百科全书。反复出现的确定性问题，应尽量升级成自动检查；依赖业务取舍的问题，则保留为审查判断。

这里还有一个容易踩到的工具差异：截至本文检索时，Claude 托管 Code Review 读取 CLAUDE.md 和 REVIEW.md，本地 /code-review 不读取 REVIEW.md。因此，写了规则后还应验证具体入口的行为，不能假定不同工具共享同一套上下文。[6]

四、独立审查要看懂变更，也要有能力反驳实现

让实现代理在同一段对话里“再检查一下”，通常有帮助，但它已经接受了很多实现前提。独立审查应拿到需求、差异、相关代码、项目约束和验证结果，重新判断方案是否成立。

独立上下文的意义，是降低对实现过程的路径依赖，并不意味着换一个对话就获得了完全独立的判断。相同模型可能共享盲点，多个模型也可能一起误解不完整的需求。

因此，审查者需要回答具体问题：

  • 修改是否解决了原始问题，还是只让某个报错消失？
  • 调用链、数据类型、权限和异常路径是否支持它的假设？
  • 是否破坏了相邻模块，或者重新实现了已有能力？
  • 指出的风险有没有可重现的输入、控制流或测试证据？

公开案例：TrueNAS 的一个相邻旧 Bug。 在 TrueNAS 的加密相关重构 PR 中，Claude 指出相邻代码把字符串键与字典列表做成员判断，导致缓存过滤后变空。公开评论给出了变量类型、执行路径和最小验证；维护者的回复是需要另开 PR 处理。[8]

这个案例同时说明两件事：审查不能只盯着新增行；发现旧问题，也不意味着本次 PR 必须无限扩张。可以记录并转交独立修复，但如果旧问题直接影响本次变更的安全性，就不能仅靠“原来就有”略过。

审查结果也应该区分重要缺陷、非阻断建议和已有问题。Claude 的公开文档使用 Important、Nit、Pre-existing 三种标记。它们既帮助排序，也避免把历史债务错误归责给当前作者。[9]

五、多代理审查的重点，是验证和筛选

不同代理可以分别检查逻辑、接口兼容、安全和测试，扩大关注范围。但代理数量本身不是质量保证。十份没有证据的怀疑，只会制造更多待处理工作。

原文采用并行发现、另一组代理核验和投票筛选，再按严重程度报告的方式；风格、诊断提示或清理类意见会被过滤，以减少无效往返，这些过滤规则先经过内部 PR 的 A/B 测试。文中还提到审查意见覆盖率从 16% 增至 54%，大 PR 更容易产生发现，小 PR 则常常没有发现。这些是过程统计，不能直接解释成缺陷召回率。[1]

我会把发现与核验分开：发现阶段允许提出假设；核验阶段必须补充源码证据、复现或明确的推导。最终报告应去重，并说明影响、触发条件和建议。对于低置信度问题，可以保留为待调查线索，不应包装成必须修改的结论。

公开案例：Mozilla 的安全加固流水线。 Mozilla 介绍，他们在现有模糊测试设施上构建 Agent 运行环境，让模型编写并执行可复现用例，验证安全漏洞假设。发现之后，还有去重、分类、修补、测试与发布环节。报告发现问题只是其中一步。[10]

Mozilla 也指出，早期看起来可信但实际错误的 AI 安全报告，会把很高的核验成本转嫁给维护者。这个经验适用于普通 Code Review：审查器的价值，应该包括它替团队排除了多少无效怀疑，而不只是写出了多少评论。该案例是安全加固实践，不是普通 PR 审查的对照实验。

六、安全审查与 CI 要成为可以执行的合并条件

逻辑正确与安全不是同一件事。功能测试可能证明“有权限的人可以成功操作”，却没有验证“没有权限的人一定无法操作”。安全审查应有独立的关注范围，包括权限、数据隔离、秘密信息、输入边界及危险操作。

自动化安全审查可以利用开源 GitHub Action 或本地安全审查入口接入。但启用一个工具，和建立一道可靠的关卡，是两件不同的事。

原文要求 Bug 与安全审查的未解决发现必须得到处置：修复，或者说明理由后关闭；后续提交修复的问题可被自动识别。AI 也可以继续处理反馈，但不能把“机器人回复过了”当成问题已经解决。[1]

还要特别区分 Anthropic 内部规则与公开产品默认行为。当前 Claude Code Review 文档明确说明，服务本身不会批准或阻断 PR；是否必须处理评论、是否阻断合并，取决于仓库自己的规则。把工具安装成功，不等于已经实现了文章中的内部流程。[9][11]

CI 负责另一组检查：格式、静态检查、类型、测试、构建和需要支持的平台。PR 中还应有测试方式、风险和恢复方案；这些说明可以由 AI 起草，但由发起变更的人确认。

公开机制：GitHub 分支保护。 GitHub 可以要求指定检查、代码所有者批准以及审查讨论得到解决，也可以限制状态报告来源。但管理员绕过、遗漏的检查和返回 neutral 或 skipped 的任务，都需要理解清楚。不能把所有勾号统称为“所有测试已执行且成功”。[12]

我建议先做一次小型故障演练：故意让必要测试失败、让审查没有结果、再让检查超时，确认系统都按预期处理。尤其不能把“没有拿到审查结论”解析为“发现零个问题”。

七、按变更风险安排人工，而不是按作者或行数

一行权限判断可能影响所有客户，几百行自动生成文件可能几乎不需要人工细读。风险主要来自行为后果、影响范围和恢复难度。

原文的人工批准分层如下。这里描述的是该团队的内部做法，不是 GitHub 的默认规则，也不是我建议直接复制的配置。[1]

分层 原文中的典型变更 人工批准
低风险 文档、文案、内部功能、开关后的增量改动 自动审查和安全检查通过后可不要求
中风险 普通产品修改，以及缓存、自动更新器、系统提示词等敏感区域的部分修改 1 人
高风险 最高风险代码及指定路径 2 人

分级还受例外约束：轻量路径只向受信任作者开放，未在受信任名单上的作者需要第二个人批准；指定敏感路径和 CI 工作流仍需人看。分类器判断风险后，还会再判断是否应增加人工。指挥 Agent 的人被视为作者，但 Agent 的同意不能占用人类批准名额。无法确认安全的后续提交或手工冲突解决，需要重新批准。[1]

这里有三点值得展开。

首先，风险分级要看具体变化。不能因为整个模块被标为中风险，就把修改文案和修改鉴权走相同流程；也不能因为作者很可靠，就忽略一次高风险改变。

其次，信任应体现在有边界的权限中。固定敏感路径、操作范围和强制检查，不应由本次提交随意降低。分类不确定时应升级核实，而不是让作者或分类器自己解释为什么可以跳过关卡。

最后，审批必须对应被审查的版本。GitHub 支持变更后撤销旧批准，或者要求最近一次可审查推送获得其他人的批准。它的具体机制围绕 diff 状态和推送，不宜简单等同于“所有情况下只绑定一个 SHA”，但治理目标很清楚：后加的代码不能偷偷继承旧批准。[12]

普通团队可以先保持全部人工批准，只让 AI 帮助确定审查重点。取得本项目的数据之后，再对低风险类型试行减负。

八、不要只验证单个 PR，还要验证它与系统的组合

两个 PR 单独测试都通过，合在一起却可能失败。一个修改字段格式，另一个新增消费者；一个调整超时，另一个增加重试。每个局部看似合理，组合行为却变了。

合并队列解决的是这类问题：把候选变更放到最新目标分支和前序变更之上，再运行必要检查。GitHub 的官方机制支持这种验证；使用 Actions 时还需要配置 merge_group 事件，只有普通 PR 检查并不够。[13]

当然，合并队列只会执行已经定义的检查，不能自动补齐缺失的业务测试。如果两个改动产生的组合风险不在测试范围内，队列同样会放行。

同样，多个 Agent 并行工作时，需要共同的接口约束、及时同步和集成验证。Anthropic 的编译器实验在引入 GCC 对照后，仍需要定位“各自单独工作、组合起来失败”的文件关系。这说明任务拆开以后，组合问题不会自动消失。[4]

九、渐进发布与回滚，是审查体系的一部分

审查不可能发现所有问题。减少人工逐行阅读之后，更需要让残余错误以有限影响、可观察的方式暴露。

原文介绍了内部先用、功能开关和分阶段发布，公开渠道中 latest 先于 stable。这些手段的共同目的，是让真实使用反馈进入全面放量之前。[1]

公开反例：Cloudflare 2019 年 WAF 事故。 一条正则表达式引起 CPU 耗尽，造成 27 分钟故障。变更经过了 PR 审批、CI 和包含部署及回滚步骤的变更流程，但测试没有识别异常 CPU 消耗，非紧急规则仍直接全球发布。控制台访问故障和备用操作不熟悉，又拖慢了止损。[14]

这不是 AI 编程事故，却非常适合提醒我们：按既定流程做对，不代表流程覆盖了真正的风险。配置修改也不能因为“只是配置”就免除性能和影响范围判断。

Google SRE 对金丝雀发布的定义包含三件事：有限范围、有限时间、评价结果并决定是否继续。仅仅“先发一点流量”，但没有对照指标和停止条件，不构成完整验证。[15]

我会要求每项有意义的渐进发布写清楚：

  • 首批覆盖谁，是否能代表关键使用场景；
  • 观察多久，按哪个版本、租户或功能状态区分数据；
  • 什么异常触发暂停，谁有权执行；
  • 如何关闭新行为，如何验证恢复；
  • 是否存在代码回滚无法撤销的数据变化。

功能开关本身也要被测试。GitLab 的开发规范要求开与关的路径都可用，覆盖相应测试，并在稳定后处理开关的生命周期。关掉一个分支，不一定能撤销已经写入的数据，更不能撤销已经泄露的信息。[16]

十、出错后先恢复，再把教训留在系统里

快速回滚需要事先建设：版本、操作入口、访问权限和验证方法都应准备好。事故发生时，临时询问 AI “现在怎么办”，不能替代演练过的恢复路径。

原文保留了作者、每周值班轮值以及回滚和事故看板的责任；同时坦承，当指标变坏时自动收紧审批的机制尚未建成。这是一个重要边界：它描述的是仍在演进的体系，不是已经闭环的一套完美自动化。[1]

对于普通团队，我会先确保异常出现后有人知道、有人能暂停放量，再逐步建立自动收紧条件。例如连续出现某类回归，就暂时恢复该类型的双人审查。具体阈值需要本项目数据，不能照抄别人的数字。

复盘也不能止于“作者粗心”或“模型不够聪明”。更有用的问题是：需求是否含糊？审查器缺了什么上下文？测试为什么没有覆盖？哪一道关卡本应发现它？恢复为什么慢？

Google 的无责复盘强调记录影响、处置、促成事故的条件和改进行动。它不意味着没人负责，而是让团队能够如实讨论失败机制。[17]

当原因明确后，把它变成具体资产：一个回归测试、一项结构检查、一条带反例的审查规则，或一项恢复演练。Anthropic 的 AI-native SDLC 指南也把生产事故转为后续评测用例，并建议在模型、提示词和流程组件变化时重新执行评测。[18]

十一、审查器也需要一套验收标准

一个评论很多的审查器，可能认真，也可能只是噪声很多。一个从不挑错的审查器，可能遇到的都是好代码，也可能根本没有发现问题。

评估时至少要同时保留两类材料：已经确认有缺陷的变更，以及经过检查没有目标缺陷的变更。前者用于观察漏报，后者用于观察误报。最好再加入团队已经讨论过的有意行为、可选改进和历史问题，检查它是否错误升级。

原文用历史事故 PR、修复和回滚建立评测集，并由熟悉代码的人确认问题，每日运行，审查器调整后重新检验；还观察评论后来是被修复、判为误报、说明为有意设计，还是认为不值得改。这些记录能帮助识别噪声，但任何单一反馈都不自动等于真值。[1]

公开研究：c-CRAB。 这项代码审查基准尝试把人工评论对应的问题转化为可执行测试，再检验审查意见能否帮助修复问题。这比只比较两段评论文字是否相似，更接近我们真正关心的行为后果。[19]

但它也有边界：结果会受到样本筛选和修复代理能力影响，不能代表所有仓库、所有缺陷和所有版本的工具。同样，团队内部的评测也不能只收集“模型擅长找的 Bug”，然后宣布审查已经可靠。

Anthropic 的评测指南强调，既要测试某行为应该发生的情况，也要测试它不该发生的情况，并结合自动评测、线上监控和人工校准。应用到审查中，就是既验证“该指出的问题有没有指出”，也验证“正确代码有没有被要求改坏”。[20]

我会优先保证严重真实问题能被发现，然后减少误报和无效轮次。必要时按缺陷类型拆开观察：权限、兼容性、并发和数据迁移，各自的表现可能差别很大。

十二、为审查设置停止条件，避免 Agent 相互折腾

“再检查一遍，总能找出更多问题”听起来很有道理，却可能产生无限工作。

原文记录过一个 PR 一夜经历超过 50 轮修改；追查发现，反复被指出的问题中约 59% 所涉及的代码，从第一次审查时就已存在。团队随后引入三轮后重新考虑方案、后续聚焦新增差异、同类问题整体修复、不重复报告等限制，并把轮次纳入评价。[1]

这里需要区分两种活动：本次变更是否可以合并，以及代码库还有哪些历史问题值得治理。前者需要明确边界；原文团队把后者另行安排为每晚扫描既有代码。若每个 PR 都承担整个仓库的清理责任，任何修改都可能永远做不完。[1]

公开原则与实现示例。 Google 的审查规范要求在整体健康度改善时允许前进，不以完美为批准条件；争议无法收敛时，应转为直接讨论或请维护者裁决。[2] Anthropic 的长任务示例则明确设置完成、无进展和预算耗尽等退出条件。不过它是演示材料，不能把示例循环直接当成生产系统。[21]

我建议将停止原因分开记录：

停止原因 应如何解释
约定验收通过，重要发现已处置 可以进入下一阶段
同一问题持续争议或修复无进展 需要人重新判断前提或方案
时间、Token 或轮次达到上限 本轮未完成，保留证据和待办
剩余内容是范围外的改进 转入独立任务，评估是否影响当前合并

预算耗尽不能自动变成“审查通过”。反过来，也不该为了让所有代理完全满意，接受一轮又一轮没有新增价值的修改。

十三、机器读代码以后，人如何理解系统

Code Review 一直有两项作用：发现问题，以及让团队知道代码如何变化。前一项逐步自动化后，后一项不能默认还会自然发生。

微软研究者在 ICSE 2013 发表的研究发现，现代审查除了找缺陷，还带来知识传递、团队知情和替代方案；理解代码及其变化，是审查中的核心挑战。这是 AI Coding 兴起前的研究，不能直接证明 AI 会削弱团队理解，却提醒我们不能只统计发现了多少 Bug。[22]

原文提出按需理解代码：围绕将要修改的模块让 AI 解释，必要时生成帮助理解的可视化，而不是要求每个人记住整个仓库。公开工作频道也让同事更容易看到正在进行的变化。不过作者同时说明，他们还没有为知识传播建立正式流程。[1]

我认为按需解释很有用，但需要一道核对：解释是否符合真实代码？尤其是接口边界、状态归属、失败模式、权限和恢复路径，不能只看一段讲得通顺的说明。如果说不清现有检查还可能漏掉什么，就应增加实质审查，而不只是快速批准。会成为其他模块模仿对象的架构设计，也值得提前投入人工判断。

可以有意识地保留几种交流：架构变化先讨论；重要行为变化给相关模块负责人做简短演示；新成员跟随一次真实排障；关键设计决定记录原因和替代方案。没有必要让所有人阅读每一行，但应该明确哪些机制必须有两个人理解。

十四、谁发起变更，谁承担后续；但不要把责任变成责备

AI 写代码后，最危险的责任空白，是产品认为研发看过了，研发认为审查器看过了，审查器又没有真正的组织责任。

我会把责任落到具体人：谁确认需求，谁判断风险，谁允许发布，谁跟踪首轮反馈，谁在异常时恢复。一个人可以承担多个角色，但不能因为执行者是 AI 就省略这些角色。

原文强调发起并合并小中型变更的人通常继续负责修复，团队共同承担质量责任；内部开放讨论也允许非代码所有者补充意见。它把小变更、容易撤销、有限影响范围和快速反馈，作为这种责任方式能够运行的基础。[1]

公开实践：Google 的 Small CLs。 Google 建议一次改动完成一个自包含的目的，以便审查、理解、合并和回滚。小的含义不是死守行数，也不是拆成无法独立工作的碎片；审查者需要看到足够完整的行为及测试。[23]

对 AI Coding 来说，可以把“顺手重构”“顺手统一风格”“顺手换库”从一个 Bug 修复中拿掉。简化差异能让人和模型更清楚地判断因果，也更容易在失败时恢复。历史清理仍然有价值，但应该有自己的目标和验收。

十五、提前讨论方向，也要敢于放弃已经写好的代码

有些 PR 的问题不在实现，而在它根本不该进入系统。功能可能没有必要，方案可能与既有决策冲突，也可能存在更简单的解决方式。

原文提到，团队会在公开讨论中早提方向问题，必要时关闭或重塑 PR，而不是等完成后再提出阻断意见。[1] AI 降低了实现成本，更应该降低我们对既有实现的依恋。

Google 的审查指南把整体设计放在重要位置，包括功能是否适合加入系统、是否过度设计。即使代码写得很好，不需要的功能仍然可以被拒绝。[2][5]

可以在复杂任务开头写一页很短的方案：要解决什么，不解决什么，有哪些实现选择，新增哪些长期依赖，最可能在哪里失败。不是每个小修改都需要方案文档；只有当方向错误会带来明显返工或长期负担时，提前讨论才划算。

需要拒绝的，常常是一个前提，而非几行代码。把这个前提早点说清楚，比让审查代理把错误方向打磨得越来越漂亮更有价值。

十六、普通团队如何逐步落地

我不建议第一天就追求无人审查。可以按以下顺序推进，每一步都检查实际效果。

第一步，建立证据。 给常见任务约定验收方法；PR 说明测试、风险和恢复方式；明确必要 CI 与责任人。先解决“是否真的验证过”，不急于减少批准人数。

第二步，让 AI 在人工之前审查。 选择一个仓库接入审查与安全检查，用短规则校准关注点；运行本地审查或独立上下文审查，记录误报、漏报和反馈是否被正确处理。按模块风险选择 Quick、Standard 或 Deep 等深度，而不是一律最贵或最快。相关名称属于 Claude 当前产品设置，其他工具应寻找相应能力。[11][24]

第三步，减少无效往返。 固定讨论结果，限制重复报告；几轮后聚焦新增差异；历史问题安排独立扫描与任务。不要为了评论更多而优化审查器。

第四步，建立上线后的保护。 验证组合后的代码，先内部使用，再有限放量；演练关闭和回滚；让事故进入回归评测。没有这些基础，不宜仅凭审查器表现好就放宽批准。

第五步，谨慎开放低风险自动合并。 写清适用类型、受信任范围、固定人工路径和异常升级；持续观察人力、质量及维护成本，必要时收紧。关键鉴权、计费、CI、安装更新与发布路径尤其需要明确所有者，不能让工具的默认配置决定责任边界。

实践中，一项经常出现的缺陷，应逐步从人的记忆进入规则，再进入可执行检查；一项新发现的风险，则可能暂时需要更多人工判断。审查流程应随证据调整，而不是只朝着“更少的人”单向变化。

最后：我的感受、观点和评价

读完这篇文章，我最认同的，是它把注意力从“代码有没有被人看过”，转移到了“团队有没有能力证明它足够可靠”。手工阅读很重要，但阅读这个动作本身不能替代证据。AI 加速以后，这个区别被放大了。

同时，我不认为文章证明了“大多数团队都应该取消第二个人的审查”。它更像一份来自特定团队的工程报告：他们有大量自动化、内部使用反馈、值班机制和恢复手段，才有条件尝试减轻人工批准。如果只复制最后的审批数量，省略前面的投入，得到的会是另一套风险完全不同的流程。

文章还有一个我会保留疑问的地方：回滚比例和事故率很重要，但不足以描述长期质量。系统可能没有立刻出事故，却逐渐积累重复抽象、复杂依赖和难以理解的边界。原文对知识传播尚无正式流程的坦诚，反而让我觉得这一问题值得持续观察。

我也不接受把“没人能记住整个代码库”进一步推成“团队无需理解关键实现”。不要求完整记忆是合理的，但关键模块仍然要有人能说明为什么这样设计、遇到异常会怎样，以及如何判断 AI 的解释错了。否则，按需解释只是把理解的责任再次外包。

另外，回滚能力有明确边界。在企业系统中，错误扣费、数据删除、秘密泄露，以及下发到现场设备的错误配置，未必能靠撤回代码恢复。像网络控制器这样的系统，控制面一行修改可能影响大量设备；如果变更还破坏了管理连接，远程恢复本身都可能变难。这里的风险分级需要业务和运维知识，不能只依赖模型阅读 diff。

因此，我会把这篇文章的价值概括为一种工程方向：让人的判断变成更明确的约束，让机器的工作接受更可靠的检验。 它没有减少专业判断的重要性，而是改变了判断发挥作用的位置。

对工程师而言，价值也会随之变化。除了实现功能，更重要的能力包括：辨别需求是否成立，设计能暴露错误的测试，识别共同盲点，维护可理解的架构，以及在真实故障中恢复系统。这些工作不会因为生成代码更便宜而自然消失。

如果让我选最先做的三件事，我会选：明确验收，要求证据，把真实失败留下来。 等这些做好，再讨论可以少掉哪一道人工环节，才比较踏实。

参考资料

以下资料检索于 2026 年 10 月 28 日。厂商内部数字按作者自述使用；历史事故用于讨论工程机制，不视为 AI Coding 效果实验；工具文档反映检索时的行为，后续可能变化。本文没有为每项内部流程找到独立复现实验，因此将公开案例作为相关机制的补充，而不把它们拼接成因果证明。

  1. Addy Osmani, Morgan Westlee Lunt, Qing Wang：How the Claude Code team does code review。本文讨论的起点。
  2. Google：The Standard of Code Review。整体代码健康、非阻断建议、争议处理与方向判断。
  3. METR：We are Changing our Developer Productivity Experiment Design。开发者生产率研究的选择偏差与计时限制。
  4. Nicholas Carlini / Anthropic：Building a C compiler with a team of parallel Claudes。外部参照、测试环境、集成与多代理协作。
  5. Google：What to look for in a code review。设计、行为、测试有效性、复杂度与文档。
  6. Claude Code Docs：Customize Code Review。规则文件分工、证据、适用分支与本地/托管工具差异。
  7. Ryan Lopopolo / OpenAI：Harness engineering: leveraging Codex in an agent-first world。可验证的运行环境、项目知识与可执行架构约束。
  8. TrueNAS：middleware PR #18291。加密重构中的公开审查与相邻旧问题。
  9. Claude Code Docs：Read and request reviews on a pull request。问题分类、处理意见、复审范围与无结果状态。
  10. Mozilla：Behind the Scenes Hardening Firefox with Claude Mythos Preview。可复现验证与安全问题处理流水线。
  11. Claude Code Docs：Code Review。服务工作方式、适用范围与审批边界。
  12. GitHub Docs：About protected branches。必要检查、批准、讨论解决及新变更处理。
  13. GitHub Docs：Managing a merge queue。集成后的验证与 CI 事件。
  14. Cloudflare：Details of the Cloudflare outage on July 2, 2019。WAF 规则、测试盲区、全球发布与恢复障碍。
  15. Google SRE：Canarying Releases。有限发布、评价和放量决策。
  16. GitLab Docs：Feature flags in the development of GitLab。开关路径、验证与生命周期。
  17. Google SRE：Postmortem Culture: Learning from Failure。无责复盘与持续改进。
  18. Louis Claxton / Anthropic：The AI-native SDLC playbook。开发全过程的评测与事故回归。
  19. Zhang et al.：Code Review Agent Benchmark，c-CRAB。基于可执行测试的审查评价及其限制。
  20. Anthropic：Demystifying evals for AI agents。双向测试、真实失败用例与综合评估。
  21. Anthropic：Harness Primitives for Long-Running Claude Agents。独立评估与停止条件的演示实现，非生产框架。
  22. Alberto Bacchelli, Christian Bird：Expectations, Outcomes, and Challenges of Modern Code Review。代码审查的知识传播和协作作用。
  23. Google：Small CLs。自包含的小变更及其审查、回滚价值。
  24. Claude Code Docs：Set up Code Review。不同审查深度的时间与成本取舍。
Written on October 28, 2026