先拆一个容易误会的标题“终结代码审查”不是让你取消代码审查而是要把审查流程里那些拖慢交付、消耗心力、让工程师一整天原地等待的环节去掉。Aviator 联合创始人 Ankit Jain 在讨论“如何终结代码审查”时核心观察是大多数团队的问题不是“审查不够严格”而是“审查太慢、太阻塞、太消耗上下文”。代码审查作为质量门禁这个角色不会退场。退场的应该是无休止的等待、反复弹出来的通知、说不清该谁审的模糊地带以及多个 PR 同时竞争主干时一遍遍 rebase 的循环。这篇文章会把“终结代码审查”拆成可执行的工程实践自动化前置检查、小批量变更、合并队列、异步审查、效果度量。适合正在被 PR 堆积和合并冲突困扰的研发团队也适合想搭建一套轻量级代码审查机制的独立开发者。1. 要终结的不是代码审查而是审查瓶颈许多团队引入代码审查时目标是对的让变更被第二双眼睛看过早点发现设计缺陷和低级错误。但用着用着流程本身变成了新的问题。PR 提交后没有明确审查人躺在列表里没人点开。审查人打开一个 2000 行的大 PR从头看一遍需要半天。看的过程中又有新任务插入审查再次被搁置。好不容易评审通过发现主干上已经有其他 PR 合并又得 rebase。合并后 CI 还可能是红的因为分支的检查结果是基于过期代码的。这些问题有一个共同特征质量没守住多少流程时间倒是成倍增加。Ankit Jain 的视角里“终结代码审查”并不是否定审查人的价值而是把那些阻塞效率、又无法真正提升质量的环节去掉让审查回归核心对变更设计提出有效反馈而不是在等待、合并冲突和 CI 修复中消耗时间。从工程上看这个过程可以分三层理解。第一层自动化能判断的事交给自动化。格式、编译、单测、静态检查、覆盖率变化这些不需要人工反复看。第二层人工审查只关注机器判断不了的事。业务逻辑对不对、架构设计是否合理、边界条件是否覆盖、接口变更是否兼容。第三层流程本身要能并行和自适应。多个 PR 可以安全并行合并顺序由系统计算审查人不需要反复处理冲突和 rebase。后面所有实践都是围绕这三层展开的。2. 传统代码审查为什么成为开发流程瓶颈先看数据意义上的瓶颈节点。一个 PR 从创建到合并大致会经过提交、CI 检查、等待审查、审查反馈、修改、重新检查、合并。其中最容易失控的是“等待审查”和“合并前冲突处理”两段。等待审查失控的常见原因审查人没有明确指派。默认情况下团队靠“看到了就审一下”的自觉但人的注意力会优先处理自己手头正在做的事不会主动去翻待办列表。审查人同时承担多个任务。开发任务、线上事故、会议、另一条业务线的需求都会把 PR 审查挤到边缘位置。缺少响应目标。没有明确约定“应该在多长时间内给出第一轮反馈”自然不会有人觉得这是紧急事项。审查颗粒度不匹配。团队没有约定“一个 PR 最多改多少行”导致出现 1500 行的大改动。改动量越大审查启动难度越高因为审查人需要先理解背景才能给出反馈。合并前冲突失控的常见原因多个分支基于同一个旧主干开发谁先合并都会让其他人产生冲突。并行开发的 PR 改动同一批核心模块但合并顺序没有协调。CI 检查在合并前没有基于最新主干重新执行合入后主干立刻变红。这两类问题叠加会让团队产生一种很常见的负面反馈一个大功能从开发到合并真正写代码可能只占一半时间另一半时间都在等审查、改冲突、修 CI。这种体验一旦固化就会促使成员绕过流程比如直接推送主干、事后补 PR、或者“合并后再说”。流程被绕过质量门禁就名存实亡。所以一个更准确的诊断是代码审查低效不是某个人不负责而是流程结构设计有问题。要让流程变快必须先改变结构而不是继续要求大家“更积极一点”。3. 终结审查瓶颈的四个核心原则在进入具体工具和配置前先确定四个原则后面所有方案都是这四个原则的落地。3.1 机器能判定的机器先判代码审查的人手应该集中在逻辑和设计层面。格式、命名、未使用变量、编译错误、单元测试失败这类问题交给 CI 和静态检查工具。人工打开 PR 时看到的应该是“机器已经帮你排除了低级问题现在只需要看设计”。常见实现CI 中串联 lint、格式检查、类型检查、单元测试、构建并在分支保护中设置“全部通过才能合并”。3.2 每次变更尽量小PR 越小审查启动成本越低反馈速度越快冲突概率也越低。小并不是一个绝对行数而是一个相对标准一次 PR 应该只做一件事并且能在一次专注的阅读中完成理解。常见方式用 feature flag 控制功能上线拆开“写代码”和“放开流量”重构分步提交不把重构和新功能混在同一个 PR 里大的界面或模块改造按“基础结构 - 核心逻辑 - 外围完善”的顺序拆成多个 PR。3.3 合并顺序由系统调度而不是靠人排队当多个 PR 同时准备合并每个 PR 是否基于最新主干、CI 是否复测、合并后是否让主干保持绿色这些判断应该由合并队列自动处理。人工不需要盯“该谁先合”更不需要一遍遍手动 rebase。常见实现GitHub Merge Queue、GitLab Merge Train或自建基于 CI 状态和分支更新的合并调度脚本。3.4 审查响应要有明确时间约定等待是流程中最大的隐性成本。团队应该约定一个可接受的首轮审查响应时间例如“一个工作日内给出第一轮反馈”。约定不需要很严苛但要存在。有了约定审查行为才能被安排进日程而不是永远随机发生。4. 第一道闸自动化前置检查让机器先审这一章最实操。以 GitHub Actions 为例把常见的自动检查配置到 PR 的合并门禁里。4.1 一个最小可用的 CI 检查配置先看一个前端项目的例子。假设项目使用 Node.js包含 lint、测试和构建三个检查。在仓库根目录创建.github/workflows/ci.ymlname: ci on: pull_request: types: [opened, synchronize, reopened] jobs: check: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - run: npm ci - run: npm run lint - run: npm test - run: npm run build这段配置的作用是每次 PR 创建、推送新提交或者重新打开时自动执行安装依赖、lint、测试、构建四个步骤。任何一个失败PR 状态都会显示为失败。要注意npm ci需要依赖锁文件否则安装可能不稳定node-version要根据项目实际版本替换如果项目使用 pnpm 或 yarn命令需要对应调整。4.2 分支保护把检查结果变成硬性门禁光有 CI 配置还不够还要设置分支保护强制所有进入主干的分支必须通过检查。以 GitHub 为例在仓库 Settings - Branches - Add branch protection rule 里配置分支名规则设置为main或master。勾选 Require status checks to pass before merging。选择刚才的 CI job 名称比如check作为必过检查。需要时勾选 Require pull request reviews before merging并设置审查人数量。可以勾选 Require conversation resolution确保讨论在合并前得到处理。分支保护的意义在于它把“自动化检查”从可选项变成必选项。即使某个成员赶进度想跳过检查直接合并也会被平台阻止。4.3 自动化前置检查的边界自动化能解决很多低级问题但它不能判断“代码设计是否合理”。实践中经常出现的误区是把自动化检查配置得过于严格导致 PR 疯狂失败、开发被迫花大量时间应付规则反而增加了等待时间。常见做法是区分两类规则硬性规则编译、单元测试、lint、构建失败必须阻止合并。软性规则覆盖率阈值、复杂度和行数报告只展示数值不直接阻止合并或者只在明显下降时阻止。以“覆盖率下降超过 3%”作为硬性门槛比“覆盖率必须 80%”要合理因为后者容易诱导团队写一堆没意义的测试去凑数字。具体的阈值和严格程度需要根据团队阶段调整不建议第一轮配置就上最严档。5. 小批量变更从源头缩小审查范围自动化门禁解决的是“重复劳动”但审查时间的另一个大头是“看大 PR”。如果一次变更 1500 行即使没有 lint 噪音审查人也要花很长时间理解上下文。真正有效的方法是从流程上限制单次变更的规模。5.1 小批量变更的三个实现技巧按行为拆分不按文件拆分。同一个模块的改动如果包含重构、功能添加、配置调整三类行为就拆成三个 PR而不是一个 PR 里混着三个目的。审查人无法从“改了哪些文件”判断意图但从“这个 PR 想解决什么问题”出发更容易给出有效反馈。使用 feature flag。新功能可以先隐藏在开关后面先把代码合入主干再通过开关逐步放开。这样即使功能还没完全开发完代码也可以先通过审查和合并避免一个超大 PR 长时间阻塞在分支上。重构与功能分开。重构会改变代码结构功能会改变行为两者混在一起时审查人难以区分“行为变化是否合理”和“结构变化是否合理”。先合并重构再合并功能每步都保持主干可运行冲突率也会下降。5.2 用 PR 模板降低沟通成本大 PR 难以审查部分原因是描述信息不足。审查人看到一堆改动却不知道前因后果只能从头猜。一个清晰的信息模板能显著降低理解成本## 变更内容 一句话描述这个 PR 解决了什么问题。 ## 变更范围 列出改动涉及的主要模块、文件范围、影响面。 ## 测试验证 - [ ] 本地单测通过 - [ ] 相关功能手工验证通过 - [ ] 未影响已有接口 ## 部署影响 是否包含数据库迁移、配置变更、依赖升级、需要回滚预案的情况。 ## 关联需求 关联的 issue 或需求链接。模板不需要每次都写得很长但“变更内容”“影响范围”“部署影响”三项应该成为默认结构。这能减少审查人在评论区和私聊里反复追问“为什么改这里”的时间。5.3 多少行算小没有一个绝对标准不同团队、不同技术栈差异很大。更可操作的方式是设定相对规则新功能 PR 尽量控制在 400-600 行以内超过就需要拆分。重构类 PR 可以稍大但需要保证每步可编译、可运行。任何人看到 PR 变更量超出常规值时都有权要求拆分后再审。这里的关键不是行数本身而是“审查人是否能在一次专注的阅读中理解全部改动”。如果答案是否定的就说明这个 PR 拆得不够小。6. 合并队列解决并发合并且不阻塞这一部分是整个方案里最像“基础设施”的一环也是很多工程团队的痛点。多个 PR 同时通过审查后谁先合并后合并的人怎么保证分支是最新的合并后 CI 是否重新跑过这些问题靠人工协调很容易出错合并队列就是专门解决这个问题的。6.1 合并队列的工作原理合并队列的核心思路是平台或工具维护一个“等待合入”队列。每个 PR 进入队列后系统按顺序或按优先级把它与当前主干最新状态合并并触发一次基于最新主干的 CI 验证。只有验证通过的 PR 才会真正合并到主干验证失败的 PR 被弹出队列由作者修复后重新入队。从开发者的角度看好处非常直接不需要手动了解“现在主干上有什么”队列会自动把最新状态带上。不需要反复手动 rebase系统在队列内部处理合并和重跑。多个 PR 可以并行开发和审查最终的合并顺序由队列统一调度。6.2 在 GitHub 上启用 Merge QueueGitHub 原生提供 Merge Queue 能力可以在仓库分支保护设置里开启进入 Settings - Branches - 编辑分支保护规则。勾选 Require status checks to pass before merging 后会看到 Merge queue 选项。启用 Merge queue并选择队列参数例如最大 PR 数量、每个 PR 需要重跑的检查等。受保护分支上的合并操作会进入队列而不是直接合并。启用后即使多个 PR 同时准备合并也会由队列负责按顺序调度每个 PR 都会基于最新主干重跑检查。需要注意合并队列的具体参数以 GitHub 官方文档为准因为不同阶段的 UI 和配置项会有调整这里只提供思路实际配置时先在一个非核心仓库做实验。6.3 自建还是使用现成工具如果团队使用 GitHub 或 GitLab优先考虑平台自带的 Merge Queue / Merge Train 能力。如果团队使用开源 Git 平台或者定制化流程可以考虑自建简单的合并调度脚本但自建的成本通常比较高要处理并发、原子合并、重试、通知、权限等问题。Aviator 这类工具在做的事情就是把合并队列和代码审查流程的自动化打包成更完整的解决方案。它也不是要让“审查”消失而是让审查结果和合并行为都由系统自动协调减少人工协调成本。6.4 一个简化的合并队列配置参考如果只想在 GitHub Actions 中触发与合并队列相关的检查可以监听merge_group事件on: merge_group: pull_request: jobs: check: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - run: npm ci - run: npm run lint - run: npm test这个配置表示 PR 检查和合并队列的检查共享同一个 job避免“PR 状态正常但合并后状态异常”的脱节。核心思路是合并前必须基于最新主干再跑一遍检查而不是沿用 PR 创建时的旧结果。7. 异步审查与轮值机制把等待时间压到最低代码审查不仅是流程问题也是协作模式问题。很多团队把审查做成了“同步会议”你要等某个人上线才开审你要凑齐几个人才敢合你在群里喊一句然后所有人一起开始评论。同步方式看着热闹效率通常很低。7.1 异步优先有效的方式是异步审查提交 PR 后审查人在自己的空闲时间完成评审评论和修改也异步进行。代码审查不需要实时对话更不需要大家同时在线。异步审查的前提是信息完整。PR 描述写清楚背景CI 已经跑完审查人打开就能看到结果。这样审查人可以在任务间隙花 10-15 分钟完成一次评审而不需要专门腾出大段时间。7.2 明确审查人每个 PR 必须有明确的审查人。推荐用“默认分配 人工指定”的组合。按项目或者模块分配默认审查人。提交者可以在 PR 中额外指定熟悉该模块的人。对于跨模块改动至少指定一名熟悉主改动模块的人。很多团队的 PR 躺在列表里没人看就是因为没有明确 owner。把“谁来审”自动化分配比写十条“大家要积极主动”有效得多。7.3 响应时间约定建议在小团队内部约定一个底线例如工作日 24 小时以内给出第一轮反馈。如果无法按时审在 PR 中标记“今天没时间”并 re-assign 给其他成员。对紧急修复类 PR可以约定更短的响应时间比如 4 小时。有了约定之后“等待审查”就从模糊状态变成了可预期状态。团队可以在此基础上进一步看到哪个人、哪个环节容易超时再针对性优化。7.4 轮值与例行审查大团队可以安排“审查轮值”每天或每周指定一名成员负责处理当天的 PR 审查队列。轮值不是唯一审查人而是负责“兜底”保证每个 PR 在过期前至少被某个人看过。这样即使提交者指定的审查人请假或忙碌流程也不会完全停摆。8. 用数据度量审查效能用数据验证效果优化了一段时间之后怎么知道是否真的变好了只靠感觉不够要建立简单的度量指标。这里不建议一上来就搭一套复杂的数据平台先从三个最关键的数据开始。8.1 三个核心指标指标含义观察目标PR 生命周期PR 从创建到合并的总时间能反映整体交付链路是否顺畅首次审查响应时间PR 提交到第一个审查评论的时间能反映等待审查的瓶颈合并后主干稳定性主干 CI 在合并后失败的频率能反映自动化门禁是否有效另外可以辅助观察单个 PR 的平均变更行数评估小批量原则是否被执行。平均每人的审查数量评估审查负担是否集中在少数人身上。被弹出合并队列的 PR 数量评估并发合并时的冲突频率。8.2 用一个简单脚本统计 PR 生命周期在没有现成平台指标的情况下可以写脚本调用 GitHub API 做基础统计。下面的 Python 脚本只统计最近关闭的 100 个 PR 的平均生命周期作为示例import os from datetime import datetime, timezone import requests owner os.getenv(GITHUB_OWNER) repo os.getenv(GITHUB_REPO) token os.getenv(GITHUB_TOKEN) if not owner or not repo or not token: raise SystemExit(请先设置 GITHUB_OWNER、GITHUB_REPO、GITHUB_TOKEN 环境变量) headers { Authorization: ftoken {token}, Accept: application/vnd.githubjson, } url fhttps://api.github.com/repos/{owner}/{repo}/pulls params {state: closed, per_page: 100} resp requests.get(url, headersheaders, paramsparams, timeout30) resp.raise_for_status() pulls resp.json() if not pulls: print(没有取到 PR 数据) raise SystemExit total_days 0.0 for pr in pulls: created datetime.fromisoformat(pr[created_at].replace(Z, 00:00)) closed datetime.fromisoformat(pr[closed_at].replace(Z, 00:00)) total_days (closed - created).total_seconds() / 86400 avg_days total_days / len(pulls) print(f最近 {len(pulls)} 个已关闭 PR 的平均生命周期: {avg_days:.2f} 天)脚本很简单但已经能回答“优化之后PR 平均从几天降到几天”这个问题。要让数据更准确还需要区分合并的 PR 和被关闭的 PR并排除机器人提交这里只是给出一个统计思路实际使用时要按仓库情况过滤。8.3 数据改进的闭环建议每个迭代周期比如两到三周简单同步一次数据PR 生命周期是上涨还是下降首次审查响应时间是否达标主干是否经常被合并后变红如果 PR 生命周期降了但主干变红频率上升说明自动化门禁有漏洞要立刻补检查项。如果首次审查响应时间仍然很长说明审查人分配或者轮值机制没有真正落地。如果 PR 生命周期没降先检查是不是大 PR 比例仍然很高再检查是不是合并队列没有开启或者 CI 重跑时间过长。数据不会直接给出答案但它能精准指出下一个该优化的环节这就是它的价值。9. 落地阻力与排查方法这套方案在落地过程中会遇到各种阻力。最常见的问题并不是技术不会配而是流程改变引发的不适应。下面按问题分类给出排查思路。问题现象可能原因排查思路解决方案PR 还是没人审审查人没有明确分配或约定没有建立检查每个 PR 是否有 assignee 和被指定的审查人启用默认分配配置轮值人约定首轮响应时间CI 配置后 PR 长时间卡在失败态检查项过多、阈值过严、命令在本地和 CI 结果不一致查看 CI 失败日志确认是命令问题还是配置问题先用最小检查集跑通再逐步加规则合并队列开启后 PR 排队时间更长每个 PR 都需要重跑完整 CICI 本身跑得慢观察 CI 总耗时和队列等待时长拆分 CI job有选择地重跑必须项或提升执行环境影响大 PR 拆不动功能设计阶段没有考虑拆分检查功能是否能用 feature flag 分阶段上线先引入 feature flag按功能开关拆分合并后主干仍然红自动检查覆盖不足检查结果基于过期分支检查合并前是否基于最新主干重跑开启合并队列或设置合并前强制更新分支团队成员绕过流程流程规则不合理等待成本太高观察绕过的 PR 数量和时间节点简化流程让合规路径比绕过更省事下面再展开两个最容易被低估的点。9.1 不要让 CI 本身成为新的瓶颈自动化门禁的思路是把人工审查时间替换成机器检查时间。如果 CI 跑一次要 40 分钟而每次提交都要完整重跑团队很快就会有人不满意。建议的做法把检查分成快速反馈层和慢速验证层。lint、单测、构建属于快速层必须每次跑端到端测试、性能测试等慢速检查可以放到 nightly 或者合并队列中再跑。本地开发时保留 pre-commit 钩子在提交前就提前拦截低级的语法和格式问题。对于依赖安装慢的项目使用依赖缓存减少每次 CI 的耗时。9.2 先在试点团队验证再全量推广流程变更最怕一步到位。建议先选一个活跃度中等、技术栈统一的小组试点两到三周收集真实数据后再决定是否推广。试点期间重点关注三件事自动化门禁是否能稳定运行、审查响应时间是否明显缩短、团队成员是否愿意继续使用流程。试点没问题后再向其他团队推广同时把配置模板化。CI 配置、PR 模板、分支保护规则、合并队列参数都可以沉淀成文档和模板仓库团队之间只需要替换仓库名和项目差异项。10. 总结与下一步“终结代码审查”的正确理解是终结低效的代码审查流程而不是终结代码审查本身。代码审查作为质量门禁仍然要保留如果它能变得更快、更自动、更少打断人团队的整体交付速度会明显上一个台阶。五条可执行路径值得立即开始用自动化前置检查处理机器能判定的问题让人工只关注设计用小批量变更降低审查启动成本和冲突概率用合并队列消除并发合并时的等待和 rebase 循环用异步审查和轮值机制缩短首次响应时间用数据指标验证每一步是否真的有效。如果团队正在被 PR 堆积和合并冲突困扰下一步可以从一个最小改动开始先给仓库加一个 CI 检查和分支保护统计一下当前 PR 的平均生命周期然后对照两周后的数据看有没有变化。最容易踩的坑有两个一是把自动化门禁配置得过严让 CI 变成新的等待源二是合并队列、轮值机制等做了很多但没有用数据验证最终分不清哪个环节真正有效。再往后可以扩展的方向包括把审查者评论和修改请求转化成自动化的回归检查项把常用的审查规则沉淀成团队内的检查模板以及在流程稳定后再探索 AI 辅助代码审查。无论工具怎么变核心目标始终一致让代码审查不再干扰开发节奏同时不牺牲代码质量。这比单纯追求“合并得快”更有价值也更值得长期投入。