代码审查自动化改造：合并队列与CI门禁实战指南

代码审查绝对是研发流程里最容易被诟病的环节：卡合并、抢注意力、低价值评论、来回拉扯。Ankit Jain（Aviator 联合创始人）在技术分享里提过一个很直接的观点——不是要取消代码审查，而是要用自动化把审查从“人工卡点”变成“自动门禁 + 人类只处理真正需要判断的问题”。这篇文章就围绕这套思路展开，给你一套可以落地执行的代码审查流程改造方案：从合并队列、自动合并策略、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 排成有序队列，自动处理 rebase，CI 通过后自动合并。这三点正好对应“终结代码审查痛苦”的三个突破口。

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_TOKEN=ghp_xxx MERGE_QUEUE_TOKEN=xxx GITLAB_TOKEN=glpat-xxx

4.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 merging
• Require status checks to pass before merging
• Require merge queue

GitHub 原生 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, cwd=repo_path, capture_output=True, text=True) return [line for line in result.stdout.split("\n") if line] def match_owner(path, owners_file="OWNERS"): 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_ascii=False))

配合OWNERS文件使用：

# OWNERS 示例 src/api/ @backend-api src/web/ @frontend docs/ @techwriter

这个脚本可以集成到 CI 中，自动输出建议审查人，再通过 GitHub API 添加到 PR Reviewers。重点：这不是在跳过审查，而是让最合适的人来做审查。

6. 功能测试与效果验证

6.1 测试一：PR 进入自动合并队列

测试目的：验证 PR 满足条件后是否自动进入合并队列。

操作步骤：

1. 创建一个 feature 分支，修改代码后提交 PR。
2. 等 CI 任务（test、lint、build）全部通过。
3. 邀请另一位成员 approve PR。
4. 观察 PR 状态。

预期结果：PR 被自动标记为“已批准”，并在 CI 通过后进入合并队列，最终自动合并。

判断标准：合并队列中出现该 PR，且目标分支上能看到合并提交。

失败排查：

• 如果 PR 没有进入队列，检查分支保护规则中是否启用了 merge queue。
• 如果 CI 一直等待，检查 required-checks 的 job 名称是否与.github/workflows中的 job id 完全一致。

6.2 测试二：队列内冲突自动处理

测试目的：验证多个 PR 同时改同一文件时，自动 rebase 是否生效。

操作步骤：

1. 主分支上创建 PR-A 和 PR-B，都修改src/config.ts。
2. 先让 PR-A 通过自动合并流程。
3. 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 不会进入合并队列。

操作步骤：

1. 提交一个故意让测试失败的 PR。
2. 让团队成员 approve。
3. 观察队列状态。

预期结果：该 PR 即使有 approve，也会因 CI 失败停留在队列外，不会被自动合并。

判断标准：PR 状态保持 open，并显示 merge queue 等待中或 block。

失败排查：

• 检查 required-checks 中是否漏掉了关键 job。
• 检查 base branch 的受保护规则是否真正启用。

6.4 测试四：批量合并积压 PR

测试目的：验证大量积压 PR 是否可以批量进入队列并按顺序合并。

操作步骤：

1. 准备 5-10 个无冲突、CI 可过的小 PR。
2. 分别以上面配置的自动合并流程触发。
3. 观察队列处理速度。

预期结果：PR 按提交顺序依次合并，冲突率明显低于手动合并。

判断标准：所有 PR 在设定时间内全部合并，且中间没有人工干预。

失败排查：

• 队列阻塞时检查是否有某个 PR 的 CI 长时间不结束。
• 如果批量合并且后合入的 PR 触发更多 CI 任务，考虑较小并行度。

7. 接口 API 与批量任务接入

7.1 通过 GitHub REST API 查询合并队列状态

脚本判断当前队列是否积压。

import requests import os headers = { "Authorization": f"Bearer {os.getenv('GITHUB_TOKEN')}", "Accept": "application/vnd.github+json", "X-GitHub-Api-Version": "2022-11-28" } owner = "your-org" repo = "your-repo" url = f"https://api.github.com/repos/{owner}/{repo}/pulls" params = { "state": "open", "sort": "updated", "direction": "desc", "per_page": 50 } r = requests.get(url, headers=headers, params=params, timeout=30) pulls = r.json() for pr in pulls: if pr["mergeable"] is False: print(f"PR #{pr['number']} 存在冲突，需处理") elif pr["mergeable_state"] == "blocked": print(f"PR #{pr['number']} 被阻塞，检查 CI 就绪状态") else: print(f"PR #{pr['number']} 状态: {pr['mergeable_state']}")

这样可以在自建系统中拉取所有待合并 PR 的状态，实时显示在团队看板上。

7.2 通过 API 批量触发自动合并

配合前一节的自建 Actions，可以用 Python 脚本轮询并触发合并。下面是一个“批量处理积压 PR”的核心逻辑。

import requests import os import time headers = { "Authorization": f"Bearer {os.getenv('GITHUB_TOKEN')}", "Accept": "application/vnd.github+json" } owner = "your-org" repo = "your-repo" def get_open_prs(): url = f"https://api.github.com/repos/{owner}/{repo}/pulls" params = {"state": "open", "per_page": 100} r = requests.get(url, headers=headers, params=params, timeout=30) return r.json() def merge_pr(pr_number): url = f"https://api.github.com/repos/{owner}/{repo}/pulls/{pr_number}/merge" payload = { "commit_title": f"Merge PR #{pr_number} via auto-merge script", "merge_method": "squash" } r = requests.put(url, headers=headers, json=payload, timeout=60) 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(f"PR #{pr['number']} 合并成功") else: print(f"PR #{pr['number']} 合并失败，HTTP {status}") time.sleep(2)

这个脚本适用于无冲突、CI 已经通过的 PR。实际接入时建议加白名单规则、速率限制和失败重试。

7.3 批量任务的失败重试设计

批量合并最容易踩的坑是“合并了前一个，后一个因为快照过期失败”。建议在批处理任务中设计重试机制：

import time def merge_with_retry(pr_number, max_retries=3): for attempt in range(max_retries): status_code = merge_pr(pr_number) if status_code == 200: return True if status_code == 409: print(f"PR #{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 8081

netstat命令按实际系统环境使用 Windows/Linux/macOS 对应写法。启动脚本建议加上进程守护，避免 Worker 意外退出。重点：不要让多个 Worker 同时监听同一个仓库的合并事件，否则会造成重复合并的竞态条件。

9. 常见问题与排查方法

问题现象	可能原因	排查方式	解决方案
PR 不进入合并队列	分支保护规则未启用 merge queue	查看 Settings → Branches 保护规则	启用 Require merge queue 并配置 required-checks
CI 一直显示 pending	workflow 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 合并返回 409	PR 不是 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 和自动合并误认为“跳过审查”。记住一个原则：人可以少看，但关键业务逻辑必须有人负责。系统只是帮你处理机械性劳动，最终质量责任在团队。

建议下一步按顺序推进：

1. 先统计当前团队的 PR 合并等待时间和冲突率，建立基线。
2. 在试点仓库开启分支保护规则和 CI 门禁。
3. 接入合并队列，观察 2 周数据。
4. 再考虑引入 AI 辅助审查或更复杂的批量合并策略。

代码审查不会消失，但那些让人烦躁的排队、冲突、重复检查和随机指派，完全可以被自动化流程终结。把人的时间省下来，用来真正理解业务逻辑和系统设计，这才是这一套流程改造的最终目标。