做技术团队的同学大概都经历过这种场景一个分支开发了三天提了 Pull Request然后卡在代码审查环节两天没人动等终于有人 review评论区全是“这里命名改一下”“那里补个注释”的机械问题好不容易改完CI 又跑挂了重新提交、重新排队、重新等审查。代码审查本来是软件工程里最有价值的质量保障手段之一但在实际落地中它常常变成团队效率的“黑洞”——审不完的 PR、吵不完的格式问题、等不到的合并。近期看到 Aviator 联合创始人 Ankit Jain 关于如何“终结代码审查”的观点结合团队里的真实实践我整理了这篇文章。注意这里的“终结”不是取消代码审查而是终结低效、冗长、靠人肉重复的审查方式让机器去解决机器擅长的事情把人释放出来做真正需要人的判断。本文会拆解代码审查低效的根源介绍 Aviator 这类自动化平台的设计思路同时给出一套基于 GitHub 生态的可落地改造方案包含完整配置示例和常见排错思路。无论是后端开发、前端工程师还是带团队的 Tech Lead都能从这篇文章里找到可以立即执行的优化点。1. 背景与核心概念代码审查为什么需要被“终结”1.1 代码审查的价值没有人会否认代码审查Code Review是软件开发流程中最重要的质量闸门之一。它的目标很清晰在被合并进主分支之前通过另一位工程师的眼睛检查代码发现潜在的 Bug、设计缺陷、安全隐患和风格问题。除了发现缺陷代码审查还有几个隐性价值知识共享审查者能了解作者正在做什么团队的业务知识和技术方案会自然传递。规范统一通过审查团队编码规范会被慢慢落地而不是停在文档里。质量兜底很多问题在测试阶段很难暴露比如并发边界、异常处理路径、性能隐患代码审查是最后一道人工防线。所以从理论上讲代码审查越多、越严格软件质量就应该越高。这也是为什么几乎所有成熟团队都在采用 PR/MR 流程。1.2 低效的代码审查正在拖垮团队效率理想很丰满现实却很骨感。代码审查在实际执行中经常变成这样PR 提上去之后长时间无人响应。大家都很忙审查优先级永远低于自己的开发任务。审查者打开一个 2000 行的 PR根本看不下去草草点几个“建议修改”了事。评论区被格式化问题、命名意见、风格偏好占据真正设计层面的讨论少得可怜。审查者提出意见后作者修改重新推送但审查者没有及时收到通知又等了半天。CI 在审查之后才跑等所有东西都通过时分支早已落后主分支又要合并主分支解决冲突。这些问题积累起来会形成一个让人非常厌烦的体验开发一小时排队两小时。1.3 所谓“终结代码审查”到底终结的是什么Ankit Jain 的观点核心并不是“以后不审查了”而是说很多审查工作本来就不应该交给人类来做。代码审查中大量重复性、机械性的检查比如格式是否正确、命名是否规范、有没有明显的语法错误、测试有没有跑通这些完全可以交给自动化工具。人应该只关注真正需要人的智慧和经验的部分比如架构设计、核心逻辑、业务语义、异常场景覆盖。这个概念其实就是把代码审查从“人肉驱动的流程”变成“策略驱动的流程”。Aviator 这类工具的定位正是把合并策略、审查规则、自动化检查、分支同步这些流程整合起来让整个 PR 生命周期更像一条自动化的生产线而不是一个依赖人工盯守的“通报-响应”系统。所以在阅读本文时请记住一句话终结的应该是低效的审查方式而不是审查本身。2. 环境准备与工具选型构建自动化代码审查流程的基本条件要落地一套“机器先审、人工再审、自动合并”的代码审查流程需要准备以下环境。各团队的代码托管平台可能不同这里以 GitHub 为例但 GitLab、Gitee 上的思路完全一致。组件作用推荐方案代码托管平台承载 PR/MR 流程GitHub / GitLab / GiteeCI/CD 系统自动化执行测试与静态检查GitHub Actions / Jenkins / GitLab CI静态分析工具ESLint、Checkstyle、SpotBugs、SonarQube按语言生态选择自动化合并工具管理合并策略、PR 队列、自动同步Aviator / Mergify / GitHub 原生规则通知渠道让审查者及时感知 PR 状态邮件 / 企业微信 / 钉钉 / Slack需要说明的是具体版本请根据团队实际情况调整。比如 GitHub 仓库的分支保护规则在不同版本下界面可能存在差异GitHub Actions 的语法也随着版本更新有些调整。本文的重点是配置思路和流程设计示例配置以当前常见的稳定写法为准。3. 核心原理拆解为什么 Aviator 能改变审查流程3.1 从“人肉排队”到“策略驱动”的合并传统 PR 流程中合并往往依靠人工操作。开发者的实际操作是提交 PR。等人审查。根据评论修改。等 CI 通过。手动点击 Merge。发现分支冲突重新合并主分支。再等 CI再点击 Merge。这个流程中有大量时间浪费在等待和重复操作上。Aviator 想解决的就是这一点。它是一个面向工程团队的代码合并与审查自动化平台由 Ankit Jain 等人参与创建。Aviator 的核心思路是把“是否满足合并条件”变成一套明确的、可配置的策略。自动管理 PR 队列避免多个 PR 同时合并导致的互相破坏。自动让分支保持最新减少“合并前还需要手动同步主分支”的等待。通过规则引擎决定谁必须审查、什么检查必须通过、什么时候可以合并。这样开发者的 PR 不再需要人工盯守。只要策略配置好了整个流程会自动往前推进。3.2 机器能审什么人应该审什么在自动化审查流程的设计中最重要的事情是画清楚边界。如果自动化手段太激进什么都让机器决定会错过很多全局性问题如果太保守机器只跑一个编译流程价值也不大。按照通常的经验可以这样划分审查内容应该由谁处理说明代码格式、命名、注释风格机器ESLint、Prettier、Checkstyle 等工具已经非常成熟语法错误、简单逻辑错误机器编译检查、单元测试、静态分析工具测试覆盖率是否达标机器CI 脚本即可统计不达标直接失败安全漏洞扫描机器依赖扫描工具、Secret 扫描工具是否有明显反模式机器 人静态规则能识别一部分但设计层面的反模式需要人判断架构是否合理人机器很难理解业务上下文和系统边界业务逻辑是否正确人需要理解需求和业务语义异常场景是否考虑全面人这依赖工程师的经验和场景认知是否会对线上产生风险人需要结合发布策略、监控告警和回滚预案来判断机器负责“快而广”的检查人负责“慢而深”的判断。只有做到这种分工代码审查的效率和质量才能同时提升。3.3 自动化检查“前置”是关键在实践中很多团队的自动化检查放在审查之后甚至合并之前才跑。这会导致一个很尴尬的局面审查者花半小时看代码给出了一堆意见结果 CI 一跑编译都没通过。这种“先人工后机器”的顺序浪费了最宝贵的审查资源。正确的做法是把自动化检查尽量前置。开发者本地提交前可以跑 lintpush 之后立刻触发 CICI 全部通过后再邀请人工审查。已经安装了 Aviator 或者其他自动化合并工具的团队还可以配置“自动检查不通过就不允许审查者合并”从而保证人工审查只针对质量合格的代码。所以你在落地自动化审查时第一个改造点就是把 CI、静态检查、测试全部放到 PR 创建阶段让机器先跑。4. 完整实战用 GitHub 生态构建一套自动化代码审查流程这一节给出一个可直接照做的方案以 GitHub 为载体把“机器先审、人工再审、自动合并”的流程完整搭建出来。即使不使用 Aviator这套流程也能显著改善代码审查效率。4.1 创建项目结构这里以一个简单的 Node.js 后端项目为例目录结构如下code-review-demo/ ├── .github/ │ ├── workflows/ │ │ └── ci.yml │ └── pull_request_template.md ├── src/ │ └── index.js ├── test/ │ └── index.test.js ├── package.json └── README.md项目的核心逻辑不复杂关键是自动化配置的完整流程。4.2 配置 Pull Request 模板让作者先自问三个问题很多低效审查来自于信息不足。审查者打开 PR 时不知道这次改动的背景、影响范围、测试情况只能盲看。一份好的 PR 模板能倒逼作者把关键信息写清楚也能让审查者更快进入状态。文件路径.github/pull_request_template.md## 变更描述 请简要描述这次变更解决了什么问题为什么需要这样改。 ## 影响范围 - [ ] 本次改动涉及核心业务流程 - [ ] 本次改动涉及数据库结构或数据迁移 - [ ] 本次改动涉及对外 API 接口协议 - [ ] 本次改动涉及缓存/消息队列等基础设施 ## 测试验证 请说明本地测试情况、是否补充了单元测试、是否执行了集成验证。 ## 自查清单 - [ ] 已运行 lint代码格式合规 - [ ] 已运行单元测试测试全部通过 - [ ] 已补充或更新相关文档 - [ ] 已确认无敏感信息泄露密钥、Token 等 ## 备注 其他需要审查者关注的事项例如某些非预期的行为变化、后续待办的优化项。这段模板的价值是让作者在提交前先自查一遍。很多机械式问题在自查阶段就被消灭了审查者拿到的 PR 质量会高很多。4.3 配置 CI 工作流让机器先审在 GitHub 中最常用的 CI 方式是 GitHub Actions。下面的配置会在 PR 创建或更新时自动执行安装依赖、Lint、单元测试三个步骤。文件路径.github/workflows/ci.ymlname: CI on: pull_request: branches: - main push: branches: - main jobs: build: runs-on: ubuntu-latest strategy: matrix: node-version: [18.x, 20.x] steps: - name: Checkout code uses: actions/checkoutv4 - name: Setup Node.js uses: actions/setup-nodev4 with: node-version: ${{ matrix.node-version }} cache: npm - name: Install dependencies run: npm ci - name: Run lint run: npm run lint - name: Run tests run: npm test这个工作流有几个关键点on.pull_request表示 PR 创建、更新、重新打开时触发。branches限制为main避免所有分支都跑重复任务。matrix会生成多个并行任务分别在不同 Node 版本下测试。npm ci是干净安装依赖的方式比npm install更稳定适合 CI 环境。跑完这个 CI 后PR 的 Checks 区域会显示绿色的对勾或红色的叉号。只有 CI 全部通过才允许进入人工审查阶段。4.4 配置分支保护规则强制“机器先审”有了 CI 还不够还需要在 GitHub 上开启分支保护规则让“机器先通过”成为硬性要求。登录 GitHub打开仓库的Settings - Branches - Branch protection rules点击Add rule然后按下面参考配置Branch name pattern: 填入mainRequire a pull request before merging: 勾选并设置Require approvals为1Dismiss stale pull request approvals when new commits are pushed: 勾选Require status checks to pass before merging: 勾选并在搜索框中选择build任务Require branches to be up to date before merging: 勾选Do not allow bypassing the above settings: 可以勾选这能避免管理员绕过规则直接推送保存后当 PR 的 CI 还没有通过时Merge 按钮会被置灰。开发者无法绕过机器检查人工审查就不会浪费在明显不合格的代码上。4.5 自动同步主分支解决“合并前落后”的问题在实际开发中一个常见痛点是PR 开发周期长主分支变化快等 CI 通过后分支已经落后主分支需要手动执行git merge main或git rebase main然后重新等待 CI。如果团队有 Aviator 或者 Mergify 这样的工具可以配置自动更新分支的策略。以 Aviator 的常见能力为例它可以自动监测主分支变更并在安全的情况下把主分支合并回 PR 分支保持 PR 始终是最新的状态。如果暂时不接受引入额外工具也可以让开发者在提交 PR 时选择 GitHub 的Update branch按钮或者在 CI 中增加一个自动 rebase 的辅助脚本。比如下面的脚本可以自动合并主分支# 文件路径scripts/sync-main.sh # 核心思路本地拉取主分支合并回当前分支 git fetch origin main git merge origin/main # 如果有冲突需要人工解决然后重新推送 git push origin HEAD这个脚本建议由开发者手动执行而不是在 CI 中自动改提交。因为自动 rebase 在冲突场景下很容易把分支搞乱而且会造成很多无意义的 CI 重跑。4.6 引入 Aviator 自动合并策略核心思路当团队希望更进一步时可以考虑接入 Aviator 这类平台。Aviator 通常通过 GitHub App 的方式安装配置完成后它会在 PR 上自动评论、检查、更新状态。Aviator 的典型配置思路如下具体参数需要参考官方文档因为不同版本有差异配置合并条件要求 CI 全部通过、至少一个审查者批准、作者自检清单全部勾选。配置 PR 队列多个通过检查的 PR 会进入到自动合并队列按顺序合并避免并发合并互相踩踏。配置自动同步主分支更新后自动把主分支合并回 PR 分支而不是等开发者手动处理。配置审查者推荐根据代码改动文件、历史提交人自动推荐最合适的审查者。配置变更大小提醒对于超过某个行数阈值的 PR给予提示建议拆分成更小的提交。这套逻辑的核心是“把合并策略从人的控制转移到代码层面”。当所有策略都通过后Aviator 会自动执行合并开发者不需要守在电脑前反复刷新页面。需要特别提醒的是Aviator 本身是一个商业平台具体功能细节、配置面板、版本变化可能会比较快。本文描述的是它的通用设计思路实际接入时请以官方最新文档为准。如果你的团队暂时不准备引入新平台也可以只依靠 GitHub 原生的分支保护规则和 CI 脚本完成大部分自动化改造。4.7 运行与验证配置完成后可以按下面步骤验证流程是否正常创建一个新分支feat/demo修改代码并提交。将分支推送到远程创建 Pull Request。打开 PR 页面观察 CI 是否自动触发。在 CI 跑完之前确认 Merge 按钮是置灰状态。等待 CI 通过后邀请一位同事审查。审查者批准后观察是否触发自动合并如果配置了。检查合并后的主分支确认代码已进入主干。预期的正常结果是整个过程不需要人工在 CI 页面盯守也不需要反复提醒他人审查。机器负责推进流程人只负责真正有价值的设计评论和逻辑检查。5. 常见问题与排查思路自动化代码审查流程落地过程中几乎每个团队都会遇到一些典型问题这里整理一张排查表方便遇到问题时快速对照。问题现象常见原因解决思路CI 一直不触发Workflow 文件路径或分支名配置错误检查.github/workflows/ci.yml中on的触发条件确认分支名是否配置正确PR 的 Merge 按钮仍然可点分支保护规则未生效或管理员绕过在 Branch protection rules 中确认规则已保存并查看是否勾选了“Do not allow bypassing”审查者批准后仍然不能合并没有配置自动合并或还有未通过的 status check检查 PR 的 Checks 列表看是否还有其他检查未通过CI 每次都要跑很久依赖安装没有缓存在 GitHub Actions 中使用actions/setup-node的缓存能力或用actions/cache缓存依赖目录机械式评论仍然很多审查者没有意识到静态检查已经覆盖了这些问题把 lint 检查结果展示在 PR 的 Check 中并在团队规范里明确“格式问题交给机器不在 PR 评论区讨论”同步主分支后 CI 重新跑排队很久没有配置 PR 队列多个 PR 同时更新导致重复跑 CI引入 Aviator / Mergify 做合并队列管理或者减少分支同步频率审查者总是不看 PR 模板模板没有强制校验可以利用 GitHub 的 pull request 模板让作者勾选自查项并在 CI 中增加一个脚本检查 PR 描述是否填写完整有人绕过规则直接 push 到 main分支保护规则没有覆盖管理员勾选“Do not allow bypassing the above settings”要求管理员也走 PR 流程自动化工具冲突两个 bot 同时合并多个自动化工具配置了相同的合并权限统一工具入口只保留一个自动合并平台如果你遇到 CI 不触发的问题优先检查 YAML 的缩进和on字段这是最常见的低级错误。YAML 对空格非常敏感一个缩进错误会导致整个 workflow 被静默忽略。6. 最佳实践与工程建议从“人肉审查”走向“自动化审查”不仅是工具层面的改造更是一次流程文化和协作方式的升级。这里给出几条在真实项目中更容易落地的建议。6.1 控制 PR 规模比任何工具都重要Aviator 再智能也无法解决“一个 PR 改了 3000 行”的问题。人类对代码的短期理解能力是有限的一个 PR 超过 500 行审查质量就会明显下降。建议在团队规范中加入硬性约定功能 PR 尽量控制在 200-400 行左右。超过 800 行的 PR建议拆分为多个可独立合并的小 PR。纯重构类变更可以走单独的 PR不与新功能混在一起。小 PR 的好处是审查者能在短时间内完成通读理解的上下文更完整发现的深层问题反而更多。6.2 先约定“机器管什么人管什么”在团队里推行自动化审查时最容易出现的争议是AI 或工具检查出来的问题到底算不算必须修改。我的建议是在项目启动之初就拉一个清单明确如下lint 风格规则由机器强制任何人不允许在评论区争论命名和缩进。单元测试覆盖率不达标CI 直接失败不做人工豁免。安全扫描发现的高危问题自动 block 合并除非有安全负责人签署豁免。架构设计和业务逻辑问题必须由至少一位资深工程师人工审查。这个清单本身也是一份团队文档能让所有成员对齐预期减少“这个检查漏过了但我看到了”的不确定性。6.3 不要过度自动化核心架构仍要人工深度评审自动化不是银弹。有些问题是机器永远发现不了的两个服务之间的依赖方向是否合理、缓存一致性的方案是否站得住脚、未来的扩展性够不够。这些问题高度依赖业务上下文和系统全局视角必须由经验丰富的工程师在人工评审环节把关。所以推荐的做法是分级评审普通功能 PR自动化检查 1 位审查者。核心模块、高危变更、跨系统重构自动化检查 至少 2 位审查者 一次线下或线上评审会。自动化的目标是减少低价值等待而不是代替所有人类判断。6.4 建立审查指标用数据衡量效果引入自动化流程后要持续度量否则很难判断改进是否有效。建议关注以下指标平均首次响应时间PR 创建后到有人开始审查的时间。平均合并周期PR 创建到合并的总时长。PR 大小分布超过 800 行的 PR 占比是否在下降。审查意见中机器可识别问题的占比比如格式、命名类评论是否明显减少。自动化合并占比由系统自动合并的 PR 占全部合并 PR 的比例。这些指标可以从 GitHub API、Aviator 的统计面板或者定期导出的 PR 数据中获取。每月复盘一次找出流程中依然阻塞的环节持续迭代。6.5 安全与权限的最小化原则在配置自动化合并和分支保护时要始终秉持最小权限原则。自动化工具的 Token 只授予特定仓库的操作权限不要使用拥有全仓库管理权限的 Token。对于涉及生产环境发布或者数据迁移的合并应该额外强制人工审批而不是完全交给自动化流程。尤其是当自动化脚本要修改分支、合并代码、推送提交时一定要明确该操作是否越权是否会影响其他团队的代码如果脚本出现 Bug是否有回滚方案建议所有自动化配置的变更都通过代码评审的方式合入仓库的配置目录保留完整变更记录。6.6 让“快审”成为团队习惯工具的自动化可以减少等待但无法替代人的存在。团队文化上要给代码审查留出固定的时间比如每天下午的一个固定时间段专门用来处理 PR避免审查永远被排在“有空再说”的位置。可以设置审查 SLO服务等级目标例如“工作时间内 4 小时响应”让审查变成一种有承诺的行为。7. 总结与下一步思考回到开头的问题如何终结代码审查答案已经清晰了——不是把代码审查这个环节去掉而是让自动化承担所有机械化的审查让人专注于真正需要认知复杂度的审查。通过 CI 前置、分支保护、策略化合并、PR 模板、自动化同步这些手段团队可以把 PR 从“等人审”变成“机器推着走”。Aviator 这类工具解决的是合并策略和流程编排的问题如果你已经在用 GitHub 原生能力搭建了基础流程再接入这类工具会非常自然如果团队还没做过基础自动化本文第 4 部分的配置就足够你先跑起来。下一步可以继续做三件事先把本案例中的 CI、分支保护、PR 模板落地到团队仓库观察两周的 PR 合并效率。统计自动化改进前后的首次响应时间和合并周期用数据验证效果。如果 PR 量大、排队严重再评估是否引入 Aviator 或同类自动化合并平台。代码审查是软件开发中最值得投入时间去优化的环节之一。把机器能做的事交给机器把人从重复劳动中解放出来让每一次人工审查都物有所值这才是“终结代码审查”的真正含义。如果这篇文章对你有帮助可以收藏备用也欢迎在评论区聊聊你们的团队是如何处理代码审查排队问题的。实践出真知期待你的反馈。 终结低效代码审查：用自动化与策略驱动重塑PR流程
做技术团队的同学大概都经历过这种场景一个分支开发了三天提了 Pull Request然后卡在代码审查环节两天没人动等终于有人 review评论区全是“这里命名改一下”“那里补个注释”的机械问题好不容易改完CI 又跑挂了重新提交、重新排队、重新等审查。代码审查本来是软件工程里最有价值的质量保障手段之一但在实际落地中它常常变成团队效率的“黑洞”——审不完的 PR、吵不完的格式问题、等不到的合并。近期看到 Aviator 联合创始人 Ankit Jain 关于如何“终结代码审查”的观点结合团队里的真实实践我整理了这篇文章。注意这里的“终结”不是取消代码审查而是终结低效、冗长、靠人肉重复的审查方式让机器去解决机器擅长的事情把人释放出来做真正需要人的判断。本文会拆解代码审查低效的根源介绍 Aviator 这类自动化平台的设计思路同时给出一套基于 GitHub 生态的可落地改造方案包含完整配置示例和常见排错思路。无论是后端开发、前端工程师还是带团队的 Tech Lead都能从这篇文章里找到可以立即执行的优化点。1. 背景与核心概念代码审查为什么需要被“终结”1.1 代码审查的价值没有人会否认代码审查Code Review是软件开发流程中最重要的质量闸门之一。它的目标很清晰在被合并进主分支之前通过另一位工程师的眼睛检查代码发现潜在的 Bug、设计缺陷、安全隐患和风格问题。除了发现缺陷代码审查还有几个隐性价值知识共享审查者能了解作者正在做什么团队的业务知识和技术方案会自然传递。规范统一通过审查团队编码规范会被慢慢落地而不是停在文档里。质量兜底很多问题在测试阶段很难暴露比如并发边界、异常处理路径、性能隐患代码审查是最后一道人工防线。所以从理论上讲代码审查越多、越严格软件质量就应该越高。这也是为什么几乎所有成熟团队都在采用 PR/MR 流程。1.2 低效的代码审查正在拖垮团队效率理想很丰满现实却很骨感。代码审查在实际执行中经常变成这样PR 提上去之后长时间无人响应。大家都很忙审查优先级永远低于自己的开发任务。审查者打开一个 2000 行的 PR根本看不下去草草点几个“建议修改”了事。评论区被格式化问题、命名意见、风格偏好占据真正设计层面的讨论少得可怜。审查者提出意见后作者修改重新推送但审查者没有及时收到通知又等了半天。CI 在审查之后才跑等所有东西都通过时分支早已落后主分支又要合并主分支解决冲突。这些问题积累起来会形成一个让人非常厌烦的体验开发一小时排队两小时。1.3 所谓“终结代码审查”到底终结的是什么Ankit Jain 的观点核心并不是“以后不审查了”而是说很多审查工作本来就不应该交给人类来做。代码审查中大量重复性、机械性的检查比如格式是否正确、命名是否规范、有没有明显的语法错误、测试有没有跑通这些完全可以交给自动化工具。人应该只关注真正需要人的智慧和经验的部分比如架构设计、核心逻辑、业务语义、异常场景覆盖。这个概念其实就是把代码审查从“人肉驱动的流程”变成“策略驱动的流程”。Aviator 这类工具的定位正是把合并策略、审查规则、自动化检查、分支同步这些流程整合起来让整个 PR 生命周期更像一条自动化的生产线而不是一个依赖人工盯守的“通报-响应”系统。所以在阅读本文时请记住一句话终结的应该是低效的审查方式而不是审查本身。2. 环境准备与工具选型构建自动化代码审查流程的基本条件要落地一套“机器先审、人工再审、自动合并”的代码审查流程需要准备以下环境。各团队的代码托管平台可能不同这里以 GitHub 为例但 GitLab、Gitee 上的思路完全一致。组件作用推荐方案代码托管平台承载 PR/MR 流程GitHub / GitLab / GiteeCI/CD 系统自动化执行测试与静态检查GitHub Actions / Jenkins / GitLab CI静态分析工具ESLint、Checkstyle、SpotBugs、SonarQube按语言生态选择自动化合并工具管理合并策略、PR 队列、自动同步Aviator / Mergify / GitHub 原生规则通知渠道让审查者及时感知 PR 状态邮件 / 企业微信 / 钉钉 / Slack需要说明的是具体版本请根据团队实际情况调整。比如 GitHub 仓库的分支保护规则在不同版本下界面可能存在差异GitHub Actions 的语法也随着版本更新有些调整。本文的重点是配置思路和流程设计示例配置以当前常见的稳定写法为准。3. 核心原理拆解为什么 Aviator 能改变审查流程3.1 从“人肉排队”到“策略驱动”的合并传统 PR 流程中合并往往依靠人工操作。开发者的实际操作是提交 PR。等人审查。根据评论修改。等 CI 通过。手动点击 Merge。发现分支冲突重新合并主分支。再等 CI再点击 Merge。这个流程中有大量时间浪费在等待和重复操作上。Aviator 想解决的就是这一点。它是一个面向工程团队的代码合并与审查自动化平台由 Ankit Jain 等人参与创建。Aviator 的核心思路是把“是否满足合并条件”变成一套明确的、可配置的策略。自动管理 PR 队列避免多个 PR 同时合并导致的互相破坏。自动让分支保持最新减少“合并前还需要手动同步主分支”的等待。通过规则引擎决定谁必须审查、什么检查必须通过、什么时候可以合并。这样开发者的 PR 不再需要人工盯守。只要策略配置好了整个流程会自动往前推进。3.2 机器能审什么人应该审什么在自动化审查流程的设计中最重要的事情是画清楚边界。如果自动化手段太激进什么都让机器决定会错过很多全局性问题如果太保守机器只跑一个编译流程价值也不大。按照通常的经验可以这样划分审查内容应该由谁处理说明代码格式、命名、注释风格机器ESLint、Prettier、Checkstyle 等工具已经非常成熟语法错误、简单逻辑错误机器编译检查、单元测试、静态分析工具测试覆盖率是否达标机器CI 脚本即可统计不达标直接失败安全漏洞扫描机器依赖扫描工具、Secret 扫描工具是否有明显反模式机器 人静态规则能识别一部分但设计层面的反模式需要人判断架构是否合理人机器很难理解业务上下文和系统边界业务逻辑是否正确人需要理解需求和业务语义异常场景是否考虑全面人这依赖工程师的经验和场景认知是否会对线上产生风险人需要结合发布策略、监控告警和回滚预案来判断机器负责“快而广”的检查人负责“慢而深”的判断。只有做到这种分工代码审查的效率和质量才能同时提升。3.3 自动化检查“前置”是关键在实践中很多团队的自动化检查放在审查之后甚至合并之前才跑。这会导致一个很尴尬的局面审查者花半小时看代码给出了一堆意见结果 CI 一跑编译都没通过。这种“先人工后机器”的顺序浪费了最宝贵的审查资源。正确的做法是把自动化检查尽量前置。开发者本地提交前可以跑 lintpush 之后立刻触发 CICI 全部通过后再邀请人工审查。已经安装了 Aviator 或者其他自动化合并工具的团队还可以配置“自动检查不通过就不允许审查者合并”从而保证人工审查只针对质量合格的代码。所以你在落地自动化审查时第一个改造点就是把 CI、静态检查、测试全部放到 PR 创建阶段让机器先跑。4. 完整实战用 GitHub 生态构建一套自动化代码审查流程这一节给出一个可直接照做的方案以 GitHub 为载体把“机器先审、人工再审、自动合并”的流程完整搭建出来。即使不使用 Aviator这套流程也能显著改善代码审查效率。4.1 创建项目结构这里以一个简单的 Node.js 后端项目为例目录结构如下code-review-demo/ ├── .github/ │ ├── workflows/ │ │ └── ci.yml │ └── pull_request_template.md ├── src/ │ └── index.js ├── test/ │ └── index.test.js ├── package.json └── README.md项目的核心逻辑不复杂关键是自动化配置的完整流程。4.2 配置 Pull Request 模板让作者先自问三个问题很多低效审查来自于信息不足。审查者打开 PR 时不知道这次改动的背景、影响范围、测试情况只能盲看。一份好的 PR 模板能倒逼作者把关键信息写清楚也能让审查者更快进入状态。文件路径.github/pull_request_template.md## 变更描述 请简要描述这次变更解决了什么问题为什么需要这样改。 ## 影响范围 - [ ] 本次改动涉及核心业务流程 - [ ] 本次改动涉及数据库结构或数据迁移 - [ ] 本次改动涉及对外 API 接口协议 - [ ] 本次改动涉及缓存/消息队列等基础设施 ## 测试验证 请说明本地测试情况、是否补充了单元测试、是否执行了集成验证。 ## 自查清单 - [ ] 已运行 lint代码格式合规 - [ ] 已运行单元测试测试全部通过 - [ ] 已补充或更新相关文档 - [ ] 已确认无敏感信息泄露密钥、Token 等 ## 备注 其他需要审查者关注的事项例如某些非预期的行为变化、后续待办的优化项。这段模板的价值是让作者在提交前先自查一遍。很多机械式问题在自查阶段就被消灭了审查者拿到的 PR 质量会高很多。4.3 配置 CI 工作流让机器先审在 GitHub 中最常用的 CI 方式是 GitHub Actions。下面的配置会在 PR 创建或更新时自动执行安装依赖、Lint、单元测试三个步骤。文件路径.github/workflows/ci.ymlname: CI on: pull_request: branches: - main push: branches: - main jobs: build: runs-on: ubuntu-latest strategy: matrix: node-version: [18.x, 20.x] steps: - name: Checkout code uses: actions/checkoutv4 - name: Setup Node.js uses: actions/setup-nodev4 with: node-version: ${{ matrix.node-version }} cache: npm - name: Install dependencies run: npm ci - name: Run lint run: npm run lint - name: Run tests run: npm test这个工作流有几个关键点on.pull_request表示 PR 创建、更新、重新打开时触发。branches限制为main避免所有分支都跑重复任务。matrix会生成多个并行任务分别在不同 Node 版本下测试。npm ci是干净安装依赖的方式比npm install更稳定适合 CI 环境。跑完这个 CI 后PR 的 Checks 区域会显示绿色的对勾或红色的叉号。只有 CI 全部通过才允许进入人工审查阶段。4.4 配置分支保护规则强制“机器先审”有了 CI 还不够还需要在 GitHub 上开启分支保护规则让“机器先通过”成为硬性要求。登录 GitHub打开仓库的Settings - Branches - Branch protection rules点击Add rule然后按下面参考配置Branch name pattern: 填入mainRequire a pull request before merging: 勾选并设置Require approvals为1Dismiss stale pull request approvals when new commits are pushed: 勾选Require status checks to pass before merging: 勾选并在搜索框中选择build任务Require branches to be up to date before merging: 勾选Do not allow bypassing the above settings: 可以勾选这能避免管理员绕过规则直接推送保存后当 PR 的 CI 还没有通过时Merge 按钮会被置灰。开发者无法绕过机器检查人工审查就不会浪费在明显不合格的代码上。4.5 自动同步主分支解决“合并前落后”的问题在实际开发中一个常见痛点是PR 开发周期长主分支变化快等 CI 通过后分支已经落后主分支需要手动执行git merge main或git rebase main然后重新等待 CI。如果团队有 Aviator 或者 Mergify 这样的工具可以配置自动更新分支的策略。以 Aviator 的常见能力为例它可以自动监测主分支变更并在安全的情况下把主分支合并回 PR 分支保持 PR 始终是最新的状态。如果暂时不接受引入额外工具也可以让开发者在提交 PR 时选择 GitHub 的Update branch按钮或者在 CI 中增加一个自动 rebase 的辅助脚本。比如下面的脚本可以自动合并主分支# 文件路径scripts/sync-main.sh # 核心思路本地拉取主分支合并回当前分支 git fetch origin main git merge origin/main # 如果有冲突需要人工解决然后重新推送 git push origin HEAD这个脚本建议由开发者手动执行而不是在 CI 中自动改提交。因为自动 rebase 在冲突场景下很容易把分支搞乱而且会造成很多无意义的 CI 重跑。4.6 引入 Aviator 自动合并策略核心思路当团队希望更进一步时可以考虑接入 Aviator 这类平台。Aviator 通常通过 GitHub App 的方式安装配置完成后它会在 PR 上自动评论、检查、更新状态。Aviator 的典型配置思路如下具体参数需要参考官方文档因为不同版本有差异配置合并条件要求 CI 全部通过、至少一个审查者批准、作者自检清单全部勾选。配置 PR 队列多个通过检查的 PR 会进入到自动合并队列按顺序合并避免并发合并互相踩踏。配置自动同步主分支更新后自动把主分支合并回 PR 分支而不是等开发者手动处理。配置审查者推荐根据代码改动文件、历史提交人自动推荐最合适的审查者。配置变更大小提醒对于超过某个行数阈值的 PR给予提示建议拆分成更小的提交。这套逻辑的核心是“把合并策略从人的控制转移到代码层面”。当所有策略都通过后Aviator 会自动执行合并开发者不需要守在电脑前反复刷新页面。需要特别提醒的是Aviator 本身是一个商业平台具体功能细节、配置面板、版本变化可能会比较快。本文描述的是它的通用设计思路实际接入时请以官方最新文档为准。如果你的团队暂时不准备引入新平台也可以只依靠 GitHub 原生的分支保护规则和 CI 脚本完成大部分自动化改造。4.7 运行与验证配置完成后可以按下面步骤验证流程是否正常创建一个新分支feat/demo修改代码并提交。将分支推送到远程创建 Pull Request。打开 PR 页面观察 CI 是否自动触发。在 CI 跑完之前确认 Merge 按钮是置灰状态。等待 CI 通过后邀请一位同事审查。审查者批准后观察是否触发自动合并如果配置了。检查合并后的主分支确认代码已进入主干。预期的正常结果是整个过程不需要人工在 CI 页面盯守也不需要反复提醒他人审查。机器负责推进流程人只负责真正有价值的设计评论和逻辑检查。5. 常见问题与排查思路自动化代码审查流程落地过程中几乎每个团队都会遇到一些典型问题这里整理一张排查表方便遇到问题时快速对照。问题现象常见原因解决思路CI 一直不触发Workflow 文件路径或分支名配置错误检查.github/workflows/ci.yml中on的触发条件确认分支名是否配置正确PR 的 Merge 按钮仍然可点分支保护规则未生效或管理员绕过在 Branch protection rules 中确认规则已保存并查看是否勾选了“Do not allow bypassing”审查者批准后仍然不能合并没有配置自动合并或还有未通过的 status check检查 PR 的 Checks 列表看是否还有其他检查未通过CI 每次都要跑很久依赖安装没有缓存在 GitHub Actions 中使用actions/setup-node的缓存能力或用actions/cache缓存依赖目录机械式评论仍然很多审查者没有意识到静态检查已经覆盖了这些问题把 lint 检查结果展示在 PR 的 Check 中并在团队规范里明确“格式问题交给机器不在 PR 评论区讨论”同步主分支后 CI 重新跑排队很久没有配置 PR 队列多个 PR 同时更新导致重复跑 CI引入 Aviator / Mergify 做合并队列管理或者减少分支同步频率审查者总是不看 PR 模板模板没有强制校验可以利用 GitHub 的 pull request 模板让作者勾选自查项并在 CI 中增加一个脚本检查 PR 描述是否填写完整有人绕过规则直接 push 到 main分支保护规则没有覆盖管理员勾选“Do not allow bypassing the above settings”要求管理员也走 PR 流程自动化工具冲突两个 bot 同时合并多个自动化工具配置了相同的合并权限统一工具入口只保留一个自动合并平台如果你遇到 CI 不触发的问题优先检查 YAML 的缩进和on字段这是最常见的低级错误。YAML 对空格非常敏感一个缩进错误会导致整个 workflow 被静默忽略。6. 最佳实践与工程建议从“人肉审查”走向“自动化审查”不仅是工具层面的改造更是一次流程文化和协作方式的升级。这里给出几条在真实项目中更容易落地的建议。6.1 控制 PR 规模比任何工具都重要Aviator 再智能也无法解决“一个 PR 改了 3000 行”的问题。人类对代码的短期理解能力是有限的一个 PR 超过 500 行审查质量就会明显下降。建议在团队规范中加入硬性约定功能 PR 尽量控制在 200-400 行左右。超过 800 行的 PR建议拆分为多个可独立合并的小 PR。纯重构类变更可以走单独的 PR不与新功能混在一起。小 PR 的好处是审查者能在短时间内完成通读理解的上下文更完整发现的深层问题反而更多。6.2 先约定“机器管什么人管什么”在团队里推行自动化审查时最容易出现的争议是AI 或工具检查出来的问题到底算不算必须修改。我的建议是在项目启动之初就拉一个清单明确如下lint 风格规则由机器强制任何人不允许在评论区争论命名和缩进。单元测试覆盖率不达标CI 直接失败不做人工豁免。安全扫描发现的高危问题自动 block 合并除非有安全负责人签署豁免。架构设计和业务逻辑问题必须由至少一位资深工程师人工审查。这个清单本身也是一份团队文档能让所有成员对齐预期减少“这个检查漏过了但我看到了”的不确定性。6.3 不要过度自动化核心架构仍要人工深度评审自动化不是银弹。有些问题是机器永远发现不了的两个服务之间的依赖方向是否合理、缓存一致性的方案是否站得住脚、未来的扩展性够不够。这些问题高度依赖业务上下文和系统全局视角必须由经验丰富的工程师在人工评审环节把关。所以推荐的做法是分级评审普通功能 PR自动化检查 1 位审查者。核心模块、高危变更、跨系统重构自动化检查 至少 2 位审查者 一次线下或线上评审会。自动化的目标是减少低价值等待而不是代替所有人类判断。6.4 建立审查指标用数据衡量效果引入自动化流程后要持续度量否则很难判断改进是否有效。建议关注以下指标平均首次响应时间PR 创建后到有人开始审查的时间。平均合并周期PR 创建到合并的总时长。PR 大小分布超过 800 行的 PR 占比是否在下降。审查意见中机器可识别问题的占比比如格式、命名类评论是否明显减少。自动化合并占比由系统自动合并的 PR 占全部合并 PR 的比例。这些指标可以从 GitHub API、Aviator 的统计面板或者定期导出的 PR 数据中获取。每月复盘一次找出流程中依然阻塞的环节持续迭代。6.5 安全与权限的最小化原则在配置自动化合并和分支保护时要始终秉持最小权限原则。自动化工具的 Token 只授予特定仓库的操作权限不要使用拥有全仓库管理权限的 Token。对于涉及生产环境发布或者数据迁移的合并应该额外强制人工审批而不是完全交给自动化流程。尤其是当自动化脚本要修改分支、合并代码、推送提交时一定要明确该操作是否越权是否会影响其他团队的代码如果脚本出现 Bug是否有回滚方案建议所有自动化配置的变更都通过代码评审的方式合入仓库的配置目录保留完整变更记录。6.6 让“快审”成为团队习惯工具的自动化可以减少等待但无法替代人的存在。团队文化上要给代码审查留出固定的时间比如每天下午的一个固定时间段专门用来处理 PR避免审查永远被排在“有空再说”的位置。可以设置审查 SLO服务等级目标例如“工作时间内 4 小时响应”让审查变成一种有承诺的行为。7. 总结与下一步思考回到开头的问题如何终结代码审查答案已经清晰了——不是把代码审查这个环节去掉而是让自动化承担所有机械化的审查让人专注于真正需要认知复杂度的审查。通过 CI 前置、分支保护、策略化合并、PR 模板、自动化同步这些手段团队可以把 PR 从“等人审”变成“机器推着走”。Aviator 这类工具解决的是合并策略和流程编排的问题如果你已经在用 GitHub 原生能力搭建了基础流程再接入这类工具会非常自然如果团队还没做过基础自动化本文第 4 部分的配置就足够你先跑起来。下一步可以继续做三件事先把本案例中的 CI、分支保护、PR 模板落地到团队仓库观察两周的 PR 合并效率。统计自动化改进前后的首次响应时间和合并周期用数据验证效果。如果 PR 量大、排队严重再评估是否引入 Aviator 或同类自动化合并平台。代码审查是软件开发中最值得投入时间去优化的环节之一。把机器能做的事交给机器把人从重复劳动中解放出来让每一次人工审查都物有所值这才是“终结代码审查”的真正含义。如果这篇文章对你有帮助可以收藏备用也欢迎在评论区聊聊你们的团队是如何处理代码审查排队问题的。实践出真知期待你的反馈。