代码审查绝对是研发流程里最容易被诟病的环节卡合并、抢注意力、低价值评论、来回拉扯。Ankit JainAviator 联合创始人在技术分享里提过一个很直接的观点——不是要取消代码审查而是要用自动化把审查从“人工卡点”变成“自动门禁 人类只处理真正需要判断的问题”。这篇文章就围绕这套思路展开给你一套可以落地执行的代码审查流程改造方案从合并队列、自动合并策略、CI 状态检查到批量清理小 PR、审查人指派规则和接口化集成。先回答你最关心的几个问题这个方案不是某个需要本地部署的模型而是一套工程流程 工具链组合核心工具可选用 Aviator、MergeQueue 或者 GitHub 原生功能硬件门槛为 0普通开发机就能跑不要求 50 系显卡不要求 GPU支持通过 GitHub Actions、GitLab CI 或 Webhook 接入现有仓库天然支持批量任务可以把大量积压 PR 排队合并有完整 API 可对接自研 DevOps 平台。如果你正在被“PR 长时间无法合并”“合并后冲突不断”“审查意见没人处理”这些问题困扰这篇文章值得收藏。下面我会按“核心能力 → 前置条件 → 配置步骤 → 功能验证 → 接口接入 → 性能观察 → 排错清单 → 最佳实践”的顺序把整套流程拆开讲清楚。1. 代码审查自动化改造核心能力速览能力项说明项目定位面向研发团队的代码审查流程自动化方案参考 Aviator 团队公开分享的工程实践核心功能合并队列、自动合并、CI 状态门禁、PR 自动指派、冲突自动检测、批量小 PR 合并推荐硬件无特殊要求普通开发机或 CI Runner 即可显存/GPU 要求不需要 GPU不涉及本地 AI 推理支持平台GitHub、GitLab、Bitbucket 等主流 Git 托管平台可通过 API 对接自研平台启动方式云服务托管官方托管、自建 Worker 进程、GitHub Actions / GitLab CI 流水线是否支持 API支持提供 Webhook 和 REST API 用于触发合并、查询队列状态、获取审查数据是否支持批量任务支持可配置批量合并策略、队列并发数、自动重试适合场景中大型团队多人协作、微服务仓库多 PR 并发、需要严格 CI 门禁的发布流程这个方案的核心理念是代码审查不是被终结而是被重新组织。传统模式里人工审查要处理一切包括风格、冲突、CI 是否通过、依赖是否安全。改造后机器能判断的交给机器人类只审查架构、业务逻辑和代码可读性。Aviator 团队公开分享中反复强调一个数据感受当 PR 数量超过团队规模后合并冲突和队列拥塞会成为比审查本身更浪费时间的因素。所以他们的工具重点做三件事把 PR 排成有序队列自动处理 rebaseCI 通过后自动合并。这三点正好对应“终结代码审查痛苦”的三个突破口。2. 适用场景与使用边界2.1 适合什么团队10 人以上研发团队PR 并发量大人工协调合并且成本高。微服务/多仓库架构跨仓库依赖多一个 PR 卡住会影响整条链路。对 CI 有强依赖测试、静态检查、安全扫描是合并前置条件。远程协作团队异步审查比实时讨论多需要规则化流程。2.2 能解决什么问题第一是合并等待时间过长。PR 提交后CI 跑 20 分钟人工审查再排 2 小时一天就过去了。改造后CI 通过且满足审查人数量要求就自动进入合并队列。第二是合并顺序混乱导致的冲突。多个 PR 同时改同一个模块谁先合并全看运气。合并队列可以保证按顺序 rebase 和合并后合并的 PR 自动解决与先合并 PR 的冲突。第三是审查分配不均。有人被 无数次有人从不被拉到。通过规则自动指派按文件所有者、团队分工、最近审查历史来分配。2.3 不适合什么场景个人项目或 2-3 人小项目引入队列和自动合并反而增加配置成本。对发布有强合规审计要求、必须逐行人工确认的行业自动合并只能做辅助不能替代流程。团队还没有稳定的 CI 测试直接把自动合并打开是有风险的测试缺失会让坏代码直接进主干。2.4 使用边界与合规提醒代码审查自动化的本质是让机器代替人做机械性判断但最终质量责任仍在人。第一不要把自动合并理解成“跳过审查”。建议配置最小审查人数为 1 或 2自动合并只解决“已经有人看过、CI 通过、按顺序合并”这三个问题。第二公司代码和 PR 元数据属于内部资产。如果使用第三方托管服务要确认数据存储区域、访问权限和合规条款敏感项目建议优先使用自建方案或企业版私有化部署。第三接入 AI 辅助审查时要遵守数据合规要求。不要把私有代码直接发送到外部 AI 服务除非经过安全评估。第四涉及开源项目时要遵循项目本身的 LICENSE 和 CONTRIBUTING 规范。自动合并不等于可以绕过开源社区的审查约定。3. 代码审查流程现状分析与改造点在动手配置之前先梳理一下大多数团队当前的工作流。通常长这样开发分支提交 PR → CI 运行测试 → 人工分配审查者 → 审查者评论 修改 → 再次触发 CI → 管理员手动合并 → 产生冲突手动 rebase这个流程每个人都很熟但问题也很明显。问题一人工分配审查者太随意。有人随机选择审查人有人只看谁的在线头像亮着。正确做法是按模块负责人和文件变更记录自动分配。问题二CI 状态和合并动作脱节。很多团队的 CI 结果是“参考性”的CI 红了也照样有人点合并按钮。改造后 CI 必须作为硬性门禁。问题三合并顺序随缘。多个 PR 同时改同一区域时谁先合并不确定导致后合并的频繁冲突开发者在 rebase 上花大量时间。问题四小 PR 和大 PR 混在一起排队。一个 1000 行的大 PR 和三个 20 行的小 PR 竞争同一个目标分支。理想情况是小 PR 快速通过大 PR 走独立队列。问题五没有批量处理机制。当积压 20 个 PR 时靠管理员手动一个一个点合并既慢又容易出错。改造后的目标流程提交 PR → 自动分配审查人 → CI 静态检查 安全扫描并行 → 审查人 approve可配置 1-2 人 → 进入合并队列 → 队列自动 rebase 重跑增量测试 → 按顺序自动合并 → 合并不成功的 PR 自动标记并通知4. 环境准备与前置条件4.1 硬件与环境要求不需要显卡不需要大内存服务器。你需要的是一台能跑 CI 的服务器或 SaaS CI 服务GitHub Actions / GitLab CI / Jenkins。Git 托管平台GitHub、GitLab、Bitbucket 都可。一个用于存放自动合并脚本的仓库。如果使用 Aviator 官方云服务只需要在 GitHub 或 GitLab 上安装 App 并授权仓库访问权限。如果希望自建需要准备一台可以运行 Docker 的 Linux 服务器来跑 Worker。4.2 账号与权限准备无论选择哪条路线都要准备以下权限目标仓库的Admin 权限用于安装应用、配置分支保护规则。用于触发合并的Personal Access Token需要repo、workflow权限。GitLab 对应api和write_repository权限。CI 系统的管理员权限用于配置受保护环境和变量。建议把 Token 放在 CI/CD 平台的 Secret 中不要写死在代码里。示例变量名GITHUB_TOKENghp_xxx MERGE_QUEUE_TOKENxxx GITLAB_TOKENglpat-xxx4.3 分支保护规则检查清单在配置自动合并之前先检查当前分支保护规则目标分支是否配置了「要求 PR 审查」是否配置了「要求 CI 通过」是否禁用了管理员直接 push 绕过规则是否配置了「线性历史」或「rebase 合并」是否清楚当前哪些分支是受保护分支如果没有这些规则自动合并会失去意义。先补规则再开自动化。5. 搭建自动化代码审查流程5.1 方案一使用 GitHub 原生合并队列GitHub 自身提供了 merge queue 功能。开启方式如下# 示例GitHub 分支保护规则中的 merge queue 配置 merge_queues: - name: main entry_conditions: - required_checks: [test, lint, build] merge_method: squash queue_size: 5开启后在仓库 Settings → Branches → Add rule 中配置包含 merge queue 的分支保护规则。重点勾选Require a pull request before mergingRequire status checks to pass before mergingRequire merge queueGitHub 原生 merge queue 会为排队的 PR 临时创建合并分支运行检查后按顺序合入目标分支。需要注意的是GitHub 原生队列的并发策略比较保守在积压 20 个以上 PR 时表现一般这也是第三方工具存在的原因。5.2 方案二配置 Aviator 风格的自动化合并Aviator 的核心组件是 Merge Queue、ChangeSets、Batch update。如果采用其官方服务核心配置在aviator.yml中。# aviator.yml 示例实际字段以官方文档为准 version: 1 merge-queue: - name: main auto-approve: true auto-merge: true required-checks: - test - lint - build max-queue-size: 10 merge-method: squash rebase-strategy: sequential labels: - name: batch-merge merge-batch: true这份配置表达的意思是auto-approve: true满足 CI 和审查条件后自动批准。auto-merge: true自动进入合并流程。required-checks只有这些 CI 任务通过才能进入队列。max-queue-size单个队列最大允许 10 个 PR。rebase-strategy: sequential按顺序 rebase避免并发冲突。merge-batch带batch-merge标签的可以批量合并。注意这段配置是通用示例如果你不使用 Aviator 官方服务需要按自己项目的实际配置模板修改。5.3 方案三自建 GitHub Actions 自动合并脚本如果你想从零开始搭建不依赖第三方服务可以用 GitHub Actions 写一个最小可用的自动合并工作流。name: Auto Merge Approved PRs on: pull_request_review: types: [submitted] jobs: auto-merge: runs-on: ubuntu-latest permissions: contents: write pull-requests: write steps: - name: Check approval count id: check env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | pr_number${{ github.event.pull_request.number }} approvals$(gh api repos/${{ github.repository }}/pulls/$pr_number/reviews \ --jq [.[] | select(.state APPROVED)] | length) echo approvals$approvals $GITHUB_OUTPUT - name: Check CI status id: ci env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | pr_number${{ github.event.pull_request.number }} status$(gh pr checks $pr_number --json state --jq .[].state | sort -u) echo status$status $GITHUB_OUTPUT - name: Merge if approved and green if: steps.check.outputs.approvals 1 steps.ci.outputs.status SUCCESS env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | gh pr merge ${{ github.event.pull_request.number }} --squash --auto这个工作流做到三件事PR 有新的 review 事件时触发。查询当前 PR 的审核通过数量和 CI 状态。审核通过数大于等于 1 且 CI 全部成功时自动 squash 合并。放在.github/workflows/auto-merge.yml即可。第一次跑之前确认GITHUB_TOKEN有pull-requests: write权限。5.4 自动分配审查人审查人分配是“终结代码审查痛苦”的重要一环。不要等开发者手动 人用脚本按文件变更自动分配。#!/usr/bin/env python3 import os import json import subprocess def get_changed_files(repo_path.): cmd [git, diff, --name-only, origin/main...HEAD] result subprocess.run(cmd, cwdrepo_path, capture_outputTrue, textTrue) return [line for line in result.stdout.split(\n) if line] def match_owner(path, owners_fileOWNERS): with open(owners_file, r) as f: for line in f: if not line.strip() or line.startswith(#): continue pattern, owner line.split() if pattern in path: return owner return None changed_files get_changed_files() print(变更文件:, changed_files) owners [] for path in changed_files: owner match_owner(path) if owner and owner not in owners: owners.append(owner) print(建议分配:, json.dumps(owners, ensure_asciiFalse))配合OWNERS文件使用# OWNERS 示例 src/api/ backend-api src/web/ frontend docs/ techwriter这个脚本可以集成到 CI 中自动输出建议审查人再通过 GitHub API 添加到 PR Reviewers。重点这不是在跳过审查而是让最合适的人来做审查。6. 功能测试与效果验证6.1 测试一PR 进入自动合并队列测试目的验证 PR 满足条件后是否自动进入合并队列。操作步骤创建一个 feature 分支修改代码后提交 PR。等 CI 任务test、lint、build全部通过。邀请另一位成员 approve PR。观察 PR 状态。预期结果PR 被自动标记为“已批准”并在 CI 通过后进入合并队列最终自动合并。判断标准合并队列中出现该 PR且目标分支上能看到合并提交。失败排查如果 PR 没有进入队列检查分支保护规则中是否启用了 merge queue。如果 CI 一直等待检查 required-checks 的 job 名称是否与.github/workflows中的 job id 完全一致。6.2 测试二队列内冲突自动处理测试目的验证多个 PR 同时改同一文件时自动 rebase 是否生效。操作步骤主分支上创建 PR-A 和 PR-B都修改src/config.ts。先让 PR-A 通过自动合并流程。PR-A 合并后观察 PR-B 的状态。预期结果PR-B 被自动 rebase 到新的 main 分支冲突被自动解决如果双方修改的是不同位置CI 重新运行并通过。判断标准PR-B 在 PR-A 合并后自动完成 rebase重新触发检查并继续排队。失败排查如果 PR-B 显示冲突且未自动处理确认是否允许自动化 rebase。如果 rebase 后 CI 没有重新运行检查 CI 配置是否监听 push 事件。6.3 测试三CI 失败拦截合并测试目的验证 CI 失败时 PR 不会进入合并队列。操作步骤提交一个故意让测试失败的 PR。让团队成员 approve。观察队列状态。预期结果该 PR 即使有 approve也会因 CI 失败停留在队列外不会被自动合并。判断标准PR 状态保持 open并显示 merge queue 等待中或 block。失败排查检查 required-checks 中是否漏掉了关键 job。检查 base branch 的受保护规则是否真正启用。6.4 测试四批量合并积压 PR测试目的验证大量积压 PR 是否可以批量进入队列并按顺序合并。操作步骤准备 5-10 个无冲突、CI 可过的小 PR。分别以上面配置的自动合并流程触发。观察队列处理速度。预期结果PR 按提交顺序依次合并冲突率明显低于手动合并。判断标准所有 PR 在设定时间内全部合并且中间没有人工干预。失败排查队列阻塞时检查是否有某个 PR 的 CI 长时间不结束。如果批量合并且后合入的 PR 触发更多 CI 任务考虑较小并行度。7. 接口 API 与批量任务接入7.1 通过 GitHub REST API 查询合并队列状态脚本判断当前队列是否积压。import requests import os headers { Authorization: fBearer {os.getenv(GITHUB_TOKEN)}, Accept: application/vnd.githubjson, X-GitHub-Api-Version: 2022-11-28 } owner your-org repo your-repo url fhttps://api.github.com/repos/{owner}/{repo}/pulls params { state: open, sort: updated, direction: desc, per_page: 50 } r requests.get(url, headersheaders, paramsparams, timeout30) pulls r.json() for pr in pulls: if pr[mergeable] is False: print(fPR #{pr[number]} 存在冲突需处理) elif pr[mergeable_state] blocked: print(fPR #{pr[number]} 被阻塞检查 CI 就绪状态) else: print(fPR #{pr[number]} 状态: {pr[mergeable_state]})这样可以在自建系统中拉取所有待合并 PR 的状态实时显示在团队看板上。7.2 通过 API 批量触发自动合并配合前一节的自建 Actions可以用 Python 脚本轮询并触发合并。下面是一个“批量处理积压 PR”的核心逻辑。import requests import os import time headers { Authorization: fBearer {os.getenv(GITHUB_TOKEN)}, Accept: application/vnd.githubjson } owner your-org repo your-repo def get_open_prs(): url fhttps://api.github.com/repos/{owner}/{repo}/pulls params {state: open, per_page: 100} r requests.get(url, headersheaders, paramsparams, timeout30) return r.json() def merge_pr(pr_number): url fhttps://api.github.com/repos/{owner}/{repo}/pulls/{pr_number}/merge payload { commit_title: fMerge PR #{pr_number} via auto-merge script, merge_method: squash } r requests.put(url, headersheaders, jsonpayload, timeout60) return r.status_code prs get_open_prs() for pr in prs: if pr[mergeable_state] clean: status merge_pr(pr[number]) if status 200: print(fPR #{pr[number]} 合并成功) else: print(fPR #{pr[number]} 合并失败HTTP {status}) time.sleep(2)这个脚本适用于无冲突、CI 已经通过的 PR。实际接入时建议加白名单规则、速率限制和失败重试。7.3 批量任务的失败重试设计批量合并最容易踩的坑是“合并了前一个后一个因为快照过期失败”。建议在批处理任务中设计重试机制import time def merge_with_retry(pr_number, max_retries3): for attempt in range(max_retries): status_code merge_pr(pr_number) if status_code 200: return True if status_code 409: print(fPR #{pr_number} 检测到冲突等待 retry) time.sleep(10) continue break return False重试次数建议控制在 3 次以内。超过后由人工介入避免无限循环导致资源浪费。8. 资源占用与性能观察8.1 执行时间观察自动化代码审查流程不是本地 AI 推理没有显存占用问题但你要重点观察以下时间指标CI 单次执行时间决定单 PR 进入队列的周期。队列内 PR 平均等待时间如果超过 CI 时间的 2 倍说明队列拥塞。从 approve 到自动合并的时间间隔正常应在 5-15 分钟。批量合并 10 个 PR 的总耗时用于评估并发策略。建议把这些指标通过 Webhook 上报到 Prometheus 或简单的统计表。8.2 冲突率观察这是最重要的效果指标。改造前统计一下每月因冲突导致的手动 rebase 次数改造后再统计一次对比即可。冲突率 产生过冲突的 PR 数 / 总合并 PR 数如果冲突率从 30% 降到 10% 以下说明合并队列策略有效。如果冲突率不降反升检查是不是合并队列并发数太大。实时观察 git 服务端的 CPU 使用率和 CI Runner 的负载。GitHub 原生队列在高并发时会频繁触发 re-run这是正常现象但注意不要超过 CI 服务的并发配额。8.3 资源消耗与成本GitHub Actions自动合并工作流每次触发占 1 个 job 运行成本很低。第三方合并队列服务按仓库数和活跃开发者计算中大型团队需要预算费用。自建 Worker一个 2C4G 的小型服务器足够支撑 100 人团队的自动合并逻辑瓶颈通常在 CI 系统而不是队列服务。8.4 端口冲突与进程残留排查如果自建 Worker运行时会监听本地端口。常见问题# 查看端口占用 netstat -tlnp | grep 8080 # 如果端口被占用换端口启动 python worker.py --port 8081netstat命令按实际系统环境使用 Windows/Linux/macOS 对应写法。启动脚本建议加上进程守护避免 Worker 意外退出。重点不要让多个 Worker 同时监听同一个仓库的合并事件否则会造成重复合并的竞态条件。9. 常见问题与排查方法问题现象可能原因排查方式解决方案PR 不进入合并队列分支保护规则未启用 merge queue查看 Settings → Branches 保护规则启用 Require merge queue 并配置 required-checksCI 一直显示 pendingworkflow job 名称与 required-checks 不一致对比 workflow 中 job id 和规则配置统一为相同 job 名称或使用 job id 而不是显示名自动合并脚本不执行GITHUB_TOKEN 权限不足查看 Actions 日志中的 403 报错在存储库 Settings → Actions → General → Workflow 权限中开启写权限自动合并后没有触发 review合并方式为 merge commit 时部分平台会把 review 归到历史提交中检查提交历史和 pull request 关联切换为 squash merge 或保持 rebase 策略PR 自动 rebase 失败文件改动区域重叠过多查看冲突文件和 PR 描述让开发者先手动解决冲突再允许进入队列批量合并时后续 PR 失效前一个 PR 改变了测试快照或生成文件查看合并后的 CI 日志使用顺序 rebase 策略不要并发处理同仓库 PR用 API 合并返回 409PR 不是 mergeable 状态查询 mergeable_state 字段先等 CI 通过再重新尝试合并自动化把坏代码合进主分支测试覆盖不足或测试被绕过查看提交信息和 CI 日志增加单元测试和 E2E 覆盖保证 required-checks 真正拦截Worker 端口被占用上次异常退出进程未清理netstat 查看 PID杀掉残留进程或换端口特别注意不要为了“自动化体验”跳过必要的测试环节。自动化合并的价值建立在可靠 CI 之上。如果 CI 本身不稳定建议先花两周时间稳定测试再引入自动合并。10. 最佳实践与使用建议10.1 从小批量试点开始第一次不要全仓库铺开。先选一个非核心仓库或一个扩展性好的模块试点观察两周指标。确认合并等待时间下降、冲突率下降后再推广到主仓库。10.2 配置最小审查门槛建议minimum approvers 1或2。不要搞成“0 审查 纯自动合并”那样会让团队失去对代码的集体认知。自动合并解决的是流程效率不是替代人的判断。10.3 使用 OWNERS 文件维护模块负责人将代码审查分配从“随机 人”改成“按模块负责人”。这样可以减少让无关人员被 的噪声也让审查更有针对性。10.4 把 CI 做成多阶段门禁推荐三个阶段① 快速检查lint、prettier、类型检查2 分钟内 ② 核心测试单元测试、集成测试10 分钟 ③ 安全与质量依赖扫描、覆盖率、代码扫描可选阻塞第①阶段跑不完就不要进入第②阶段。这样可以避免大量资源浪费在注定失败的 PR 上。10.5 保留人工降级通道就算是全自动合并的流程也要保留“紧急人工合并”的通道。线上 hotfix 场景需要快速合入建议设置标签hotfix绕过部分流程但记录日志事后复盘。10.6 合规与安全红线私有代码不要发送到未经评估的第三方 AI 审查服务。涉密项目必须使用自建服务或企业版私有化部署。对外开源项目要遵守上游仓库的审查约定不要强制引入自动合并而破坏社区协作模式。所有自动化操作建议开启审计日志方便追溯某个合并是谁触发的。11. 总结与下一步代码审查自动化改造最值得先做的一件事是先把分支保护规则和 CI 门禁补齐。没有这个基础合并队列和自动合并都是空中楼阁。最容易踩的坑是将 merge queue 和自动合并误认为“跳过审查”。记住一个原则人可以少看但关键业务逻辑必须有人负责。系统只是帮你处理机械性劳动最终质量责任在团队。建议下一步按顺序推进先统计当前团队的 PR 合并等待时间和冲突率建立基线。在试点仓库开启分支保护规则和 CI 门禁。接入合并队列观察 2 周数据。再考虑引入 AI 辅助审查或更复杂的批量合并策略。代码审查不会消失但那些让人烦躁的排队、冲突、重复检查和随机指派完全可以被自动化流程终结。把人的时间省下来用来真正理解业务逻辑和系统设计这才是这一套流程改造的最终目标。