把代码审查“终结”掉听起来像是在挑战工程界的政治正确。但如果你问任何一个被 PR 卡了两天、合并队列排了十个小时、或者因为一条格式注释来回拉扯三轮的开发者他心里大概都想过同一个问题这玩意儿到底是在保证质量还是在给交付上刑Aviator 创始人 Ankit Jain 的很多判断恰好指向这个问题的核心。他的观点不是“撤掉代码审查”而是重新设计代码审查的流程、节奏和边界让它不再靠人肉堆时间和耐心。这篇文章我会从代码审查的痛点出发聊聊为什么传统审查模式越来越不适合高速迭代的团队Aviator 这类工程效能工具到底解决了什么问题以及一个团队可以怎么一步步把手动审查改造成自动化流水线。1. 为什么“终结代码审查”是个值得认真对待的话题先给一个明确判断代码审查本身不会消失但当前占用开发者大量精力、以“人盯人”为核心的传统审查模式确实正在被重构。很多团队对代码审查的态度非常分裂。一方面管理层认为审查是质量红线少了它心里不踏实另一方面一线工程师普遍吐槽审查流程繁琐、反馈滞后、形式大于内容。更麻烦的是代码审查经常变成隐性瓶颈——代码写完了但没人及时看有人看了但只回复几个表情有人认真提了意见但改完一轮后合并队列已经堆成山。这不是某个团队的管理水平问题而是流程设计问题。传统代码审查建立在“异步 全人工”的假设之上人在、时间在、注意力在审查质量就在。但软件开发的现实是人在、时间在、注意力不一定在代码在、PR 在但上下文可能已经丢了。从工程效能视角看代码审查真正消耗的成本有几块等待成本PR 长期无人处理开发链路持续阻塞。上下文切换成本审查者要从自己的任务里切出来阅读别人的代码。返工成本审查意见和实现思路大相径庭改动反复重来。主观偏好成本审查意见掺杂个人风格偏好而不是客观风险判断。合并摩擦成本多个 PR 并行开发主干冲突频繁审查通过也合并不进去。Aviator 这类工具切入的正是这些成本而不是“要不要审查”这个哲学问题。理解这一点就不会把“终结代码审查”误解成“废除质量保障”。2. 代码审查背后的核心矛盾质量、速度与注意力的三角博弈要理解 Aviator 的价值先要理解代码审查的本质。代码审查本质上是一种“风险控制手段”。它做的事情是在一个变更进入主干之前通过另一个(或一组)人的视角发现单点开发者容易忽略的问题。它和测试、静态检查、CI 一样都是质量防线的一部分。但代码审查有一个其他防线做不到的功能——传递上下文和团队共识。通过审查新成员了解老代码的逻辑老成员了解新功能的影响面团队逐步形成统一的规范认知。问题在于很多团队把代码审查当成了唯一的防线。于是质量责任被转嫁到审查者身上开发者写代码时反而放松了自查。结果就是 PR 体积越来越大、审查负担越来越重、反馈周期越来越长。这里有一个恶性循环PR 过大审查难度高。审查者拖延等待时间变长。开发者为了尽快合并同时开多个 PR。PR 之间互相冲突合并成本上升。为了控制风险团队要求更严格的审查。PR 更大审查更慢。循环一旦形成靠喊口号“大家要重视审查”是解决不了的。因为问题不在态度而在流程结构。Aviator 的思路本质上是用自动化手段打破这个循环。它把代码审查拆成两个部分机器可以判断的部分和必须由人来判断的部分。前者交给自动化和规则后者提供更好的工具和队列来保障。举个最直观的例子格式问题、命名问题、明显的逻辑错误这些都可以通过静态检查、机器人规则和 CI 自动拦截。但“这个接口设计是否满足未来的扩展需求”“这个改动是否影响到了其他模块的隐性契约”这些必须靠人来判断。传统做法是让审查者在一大堆 diff 里同时处理这两类问题。而 Aviator 的做法是先把机器能判断的部分全部过滤掉让人集中精力处理真正需要判断力的问题。这就是“终结”二字的真正含义——终结的是低效的审查方式不是审查这个活动。3. 代码审查的新形态自动化、合并队列与变更集Aviator 的核心能力可以归纳为几个方向它们分别对应着不同层面的效率问题。3.1 自动化审查规则Aviator 提供了一套可配置的自动化审查体系。团队可以定义什么类型的变更需要人工审查、需要谁来审查、满足什么条件才能跳过审查。这套规则不是死的而是可以按目录、按文件类型、按依赖范围来区分。举个例子修改 README 或注释完全可以走轻量路径修改支付模块或数据库迁移脚本则必须指定核心维护者审查。这个粒度上的自动化极大减少了低价值 PR 的等待时间。3.2 合并队列合并队列是 Aviator 比较有代表性的能力也是很多团队觉得“用了就回不去”的功能。在没有合并队列的仓库中多个 PR 并行开发时会出现经典问题PR A 和 PR B 都通过了 CI但 PR B 先合进去了PR A 的分支基础已经变了需要重新跑 CI重新解决冲突。如果 PR 很多这个过程会反复发生CI 的时间大部分浪费在“验证一个马上就要过期的提交”上。合并队列的思路是把多个通过审查的 PR 放入一个队列由系统按照顺序自动完成 rebase、测试和合并。Aviator 还会对即将合并的 PR 进行批量测试保证任何时刻主干的健康状态。这个设计带来的变化非常直观开发者不需要自己盯着合并进度不需要反复手动 merge 主干合并过程从“多个人协作抢资源”变成“自动化流水线排队处理”。3.3 变更集和跨仓库管理大型项目经常涉及多仓库联动。一个功能可能在 A 仓库改了接口在 B 仓库改了调用方在 C 仓库改了配置。传统的做法是为每个仓库单独开 PR每个仓库单独审查、单独合并。协调成本极高某个仓库先合并了另外的仓库还没就绪主干直接处于不可用状态。Aviator 的变更集(Change Set)概念就是把跨仓库的多个 PR 作为一个整体来管理和合并确保多个仓库的变更能够原子化落地。对于微服务团队来说这个能力能省掉大量协调成本。4. 落实自动化审查的第一块基石审查前的机器检查无论你是否使用 Aviator代码审查自动化的第一步都是先把机器能做的事全部做完。这是投入产出比最高的一环也是后续所有工具能够有效运转的基础。一个比较合理的自动检查链路包含以下层次层次工具类型解决的问题格式层Prettier、Black、gofmt、Spotless代码风格统一消灭格式争论静态分析层ESLint、Checkstyle、SonarQube常见逻辑问题、安全漏洞、坏味道类型检查层TypeScript、mypy、编译检查类型错误提前暴露单元测试层JUnit、pytest、Jest核心逻辑行为验证构建集成层CI 流水线保证代码可构建、依赖可解析这些检查最好在 PR 提交时自动运行并且把结果直接反馈到 PR 上。没有通过检查的 PR不应该进入人工审查环节。很多团队的问题是这些工具都用了但效果不佳。核心原因有两个第一检查结果没人处理。机器人报了十条告警开发者看一眼觉得问题不大就忽略了。长期下来工具变成摆设。第二检查规则和团队实际标准脱节。团队对某些规则并没有共识机器人报了审查者也不觉得是问题反而觉得噪音太多。真正有效的做法是让自动检查结果具有“拦截权”。没有通过检查PR 不允许被合并通过检查但仍存在争议的地方才进入人工讨论环节。这里给出一个简单的 GitHub Actions 示例用于在 PR 阶段自动执行 lint 和测试name: pr-check on: pull_request: types: [opened, synchronize, reopened] jobs: lint-and-test: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkoutv4 - name: Set up Node.js uses: actions/setup-nodev4 with: node-version: 20 - name: Install dependencies run: npm ci - name: Run lint run: npm run lint - name: Run tests run: npm test配置要点有两个一是pull_request事件包含了synchronize保证每次新提交都会触发检查二是 lint 和 test 都放在同一条流水线中任何一个失败都会让 PR 处于不可合并状态。5. 从“人审”到“规则审”用 CODEOWNERS 和自动化规则降噪做完机器检查之后第二步是优化人的参与方式。核心思路是让不同的人只被拉进他们真正应该参与的审查中。GitHub 的 CODEOWNERS 是一个基础但容易被忽略的机制。它可以指定某个目录或文件类型由谁负责审查。配置示例# CODEOWNERS 文件位于仓库根目录的 .github/ 目录下 # 默认审查者 * backend-team # 前端代码由前端小组审查 /src/frontend/** frontend-team # 数据库迁移脚本必须由 DBA 审查 /db/migrations/** dba-team backend-lead # 文档修改不需要默认审查者 /docs/** docs-maintainer这个配置生效后修改前端代码时GitHub 会自动把审查请求发到前端小组修改数据库脚本时DBA 会被强制拉入修改文档时默认的后端团队不会被通知。但 CODEOWNERS 本身的机制仍然不够灵活。比如“修改 X 目录中非关键代码可以只由一位成员审查”“高风险文件必须有两人以上审查”这些策略 CODEOWNERS 无法直接表达。Aviator 这层工具的价值就体现在这里它可以叠加更细粒度的审查策略比如按 PR 行数、影响文件、依赖变更情况来决定审查人范围做到按风险分级审查。配置逻辑通常包括三个部分定义文件路径规则。定义满足规则时触发的审查人策略。定义满足规则时自动执行的操作如跳过审查、请求指定人审查、添加标签。一个可参考的配置思路大概是review_policies: - name: high-risk-db-change paths: - db/migrations/** requires: approvers_count: 2 required_approvers: [backend-lead, dba-team] message: 数据库变更需要 DBA 视角确认 - name: docs-only-change paths: - docs/** - README.md requires: approvers_count: 0 auto_approve: true comment: 文档变更无需人工审批这种规则化的审查策略比“所有 PR 都需要两个 approve”更贴近实际。因为不是所有变更的风险等级都一样。一刀切的审查策略本质上是对高风险变更保护不足对低风险变更过度消耗。6. 合并队列原理与配置解决“合并不进去”的终极难题很多团队解决了审查慢的问题却卡在了合并环节。审查通过了但代码就是合不进去。原因通常有两种并行 PR 之间存在竞争关系谁先合谁后合无法协调。主干更新频繁PR 分支不断落后需要反复 rebase 和重新验证。Aviator 的合并队列就是把“人肉协调合并”变成“自动化排队合并”。理解它的核心原理对日常使用很有帮助。假设有四个 PRA、B、C、D它们分别从同一个主干分叉出来都通过了各自的 CI 校验。在没有合并队列的情况下常见的合并过程是A 合入主干。B 检测到主干变化需要 rebase重新跑 CI。B 的 CI 通过后C 发现主干又变了又要 rebase。C 还没跑完D 又冲突了。这是一个典型的多 PR 协作噩梦。在合并队列模式下系统会先把这些 PR 临时组合成一个测试队列。它会在队列中为每个 PR 创建一个临时分支这个分支包含了主干中所有已合并的变更以及当前 PR 自己的变更。然后对这些临时分支统一跑测试。这样做的优势在于系统可以一次性验证多个 PR 合并后的集成结果而不只是一个 PR 单独的结果。如果队列中的某几个 PR 本身存在集成冲突系统可以在真正的合并之前提前发现而不是合并之后靠线上事故暴露。配置合并队列时通常需要设置几个参数merge_queue: enabled: true max_parallel_batches: 3 merge_strategy: merge_queue_squash preconditions: required_checks: - pr-check - e2e-test参数含义大致如下参数作用enabled是否开启合并队列max_parallel_batches同时可测试的批次数量merge_strategy合并方式是 squash 还是 merge commitrequired_checks进入队列前必须通过的检查使用合并队列后开发者的日常习惯也会变化。以前是“写完代码就盯着 PR 等合并”现在是“PR 通过审查后进队列完成后自动通知”。这个转变对个人体验和团队节奏的影响是立竿见影的。7. 跨仓库变更集微服务场景下的多仓库原子合并对于微服务架构的团队跨仓库合并是一个常见但容易被低估的痛点。一个需求往往要涉及多个服务。比如在订单服务中新增了一个字段在网关服务中调整了转发逻辑在配置仓库中增加了路由配置。这三个变更是同一个需求的不同切片它们需要一起发布、一起生效。如果分别管理问题是三个 PR 的审查进度不一致有人快有人慢。某一个 PR 被合并了但另一个还挂着线上状态已经半新半旧。如果某一环需要回滚其他环节如何配合Aviator 的变更集功能就是把多个仓库的 PR 绑定为一个整体。它可以实现所有相关 PR 都通过审查后才自动合并合并时保持跨仓库的一致性顺序如果其中一个变更失败会整体阻止合并而不是留下一个残缺状态。这个能力对发布系统有额外的价值。理想情况下代码合并时序和发布时序应该是可规划的。使用变更集后团队可以在一个视图里看到整个需求的跨仓库状态而不是在各个仓库之间来回切换。结合 CI/CD 流水线变更集还能帮助团队实现“跨仓库原子发布”的约定主仓库相关代码合并后附属仓库的代码同时或按顺序进入发布管线减少人为错配。8. 验证自动化审查的效果看哪些指标引入自动化和合并队列后不能只看“大家感觉轻松了”需要用指标验证结果。建议重点关注四个指标的变化。1. 合并时间(Merge Time)从 PR 创建到合并进主干的总时长。这个指标直观反映开发链路的流畅度。自动化手段上线后这个时间应该明显下降。2. 审查等待时间(Review Response Time)从 PR 创建到第一位审查者给出第一次反馈的时间。这个指标反映“有人响应”的速度。如果这个值仍然很高说明问题不在工具而在团队没有人力和规则来响应审查请求。3. 失效构建/失效合并次数合并队列上线后主干上的构建失败率应该大幅下降。这个指标反映集成质量。4. 回滚率(Rollback Rate)自动化检查并不直接证明质量上升回滚率是检验质量的关键指标。如果合并速度提升但回滚率同步上升说明自动化检查的防线还没有构建扎实需要补强测试和静态分析。指标期望变化异常信号合并时间下降CI 时间过长或合并队列堆积审查等待时间下降审查人力不足规则不合理失效构建次数下降覆盖率不足自动化检查形同虚设回滚率持平或下降检查层缺失审查质量降低如果一个工具上线后合并速度上去了但回滚率也在飙升那说明团队把“加快合并”当成了目标而忽略了质量防线。自动化工具的定位是加速流程而不是替代质量判断。9. 常见问题与排查思路在实际接入过程中团队会遇到各种问题。以下是比较常见的几类问题现象可能原因排查方式解决方案合并队列一直阻塞required check 名称配置错误或测试时间过长查看合并队列日志确认 CI 是否正常结束修正 required_checks 名称优化测试执行时间PR 被自动跳过审查路径规则匹配过宽检查 review policy 的 path 规则范围缩小路径规则增加排除条件审查人长期不响应职责划分不明确查看 CODEOWNERS 和高风险规则配置指定备份审查人增加超时提醒跨仓库变更无法合并变更集关联关系未配置确认所有相关 PR 是否已绑定到同一变更集重新绑定关联检查各仓库的合并前置条件自动合并后线上出现冲突集成测试覆盖不足查看合并后主干 CI 和集成测试结果增加集成测试环节并开启合并队列批量验证排查时的第一原则是先看日志再看配置最后再谈人为因素。很多自动化工具的“异常”其实都是配置偏差比如策略规则路径写错、检查名不匹配、开启了冲突的自动化规则。生产环境改造前建议先在测试仓库中完整演练一遍流程再把策略同步到正式仓库。10. 工程实践建议从“终结代码审查”到“重建审查文化”回到开头讨论的问题。Aviator 这类工具和理念的意义在于终结低效的审查模式而不是终结质量文化。在具体工程实践中有三条建议值得留心。第一先建机器防线再引入自动化流程。如果团队的 lint、测试、构建流程本身都不稳定直接上合并队列和自动合并没有意义。机器防线是地基地基不牢越自动化越容易失控。第二审查规则要分级不要一刀切。低风险变更和核心模块变更采用不同的审查强度。把有限的人工注意力集中在真正关键的风险上而不是平均分配到所有 PR 上。第三自动化是流程的一部分不是全部。自动化负责过滤、拦截和加速但代码审查承载的“团队共识传递”无法完全自动化。新人需要通过审查理解系统设计老成员需要通过审查发现架构腐化。这部分价值无法用工具替代。从实际执行的角度建议按以下节奏逐步落地第一步补齐 PR 阶段的自动检查lint、测试、静态分析。第二步用 CODEOWNERS 或规则配置明确不同代码路径的审查职责。第三步在低风险仓库试点合并队列观察合并时间和回滚率。第四步将高风险的跨仓库协作场景纳入变更集管理。第五步根据指标复盘调整审查规则和自动化策略。这个过程不需要一步到位。工具的价值只有在团队流程稳定后才真正显现。如果团队目前的代码审查本身就处于失控状态先解决人的流程再谈自动化。Aviator 这类工具的定位不是取代工程管理而是让工程管理从低效的重复流程中解脱出来把注意力还给真正需要判断力的事项。这也正是“终结代码审查”这一说法最准确的理解终结低效保留价值。