我做“open-code-review”这个项目，不是一时兴起搞个玩具，而是因为吃了太多代码评审的亏。
你可能也有过这种感觉：代码评审（Code Review）该有的都有，PR/MR提了、人也凑齐了、评论也回了一堆，但总感觉哪里不对劲。要么是评审流于形式，看一眼标题就 Approve；要么是节奏拖得太久，分支三天合不进去；要么是“评审完了”代码里该炸的雷一个没少。我把这套东西整体重做了一遍，名字就叫 open-code-review——一套开源的、可落地的代码审查实践方案，从流程约定、自动化检查到度量闭环都有。这篇文章就是我把它从0搭起来、在团队里推行三个月的完整复盘。
如果你正准备优化团队的代码审查流程，或者你在一个人维护开源项目但不想让 Review 变成自嗨，这篇文章应该能给你一些可以“抄作业”的东西。
1. 为什么要把代码审查当成一个“项目”来做
1.1 大多数团队对代码评审的误解
先说个扎心的事实：很多人以为 Code Review 只是一道“流程关卡”，是合并代码之前必须走完的手续。这种心态下，评审变成了两个极端——要么是“都写完了，赶紧给我过了”，要么是“终于有机会挑你毛病了”。
我过去在两个团队待过，状态非常典型。第一个团队，Review 完完全全走形式，改动大不大都得等一天，Reviewer 上线之后评论“LGTM”就完事，过两周线上出问题一查，问题代码全是当初“快速通过”的。第二个团队则走了另一个极端，两位资深工程师在 PR 里从命名吵到架构，一个改动拖了五天合不进去，版本发不出去，最后搞到要 CTO 出面调停。
这两个极端的根源是一样的：把代码评审看成了“人的问题”，而不是“系统设计的问题”。只要人靠谱、态度好、经验足，评审自然就好——这个假设在十人小团队里可能成立，但人一多、改动一杂、业务一赶，再靠谱的人也会被流程拖垮。
我决定做 open-code-review 之前，给身边朋友做过一轮小调研，问大家最讨厌 Code Review 的什么。答案里出现最多的是这几条：
- “不知道 Review 什么，打开 diff 就脑袋一片空白”
- “我写的注释被当成废话删掉，我又不敢改回来”
- “等 Reviewer 回复的时间比写代码还长”
- “CI 检查跑了二十分钟，就为了查一个拼写错误”
- “每个人评审标准完全不一样，在 A 那能过的在 B 那就得返工”
你会发现，这些都是“流程、工具、标准”的问题，不是“人蠢人懒”的问题。所以思路应该反过来：把代码审查当成一个工程问题去设计，用清晰的规则、适当自动化工具和可见的度量指标，让每个参与的人都能在框架内有效率地协作。
1.2 open-code-review 想解决什么问题
一句话说清楚：我想让代码评审变得“快、准、稳”。
快，是指从提交 MR 到合并的平均耗时可控，不被无效等待卡住。准，是指评审真正能发现有效问题，而不是走过场。稳，是评审标准统一、流程可持续，不依赖某个“大神”的直觉。
围绕这三个目标，我在方案里做了几层设计：
- 统一的提交规范与 MR 模板，让 Reviewer 在最省力的情况下读懂变更背景
- 一套明确的评审清单，把“凭经验看”变成“照着单子查”
- 用静态检查与 CI 管道拦截低层级问题，把人的注意力留给架构和逻辑
- 用轻量化的度量数据反馈流程问题，持续调整而非一次性建设
这套方案不强依赖某个特定平台，GitHub、GitLab、Gitea 都能用。我用的是 GitLab 自托管，但后面讲到的每一项做法，换到别的平台只是按钮位置不同。
2. 整体方案设计：评审流程、检查清单与自动化切分
2.1 拆解一次评审里到底发生了什么
在设计方案之前，我把一次评审的过程拆成了六个动作：理解需求、阅读变更、检查逻辑、验证边界、评估可维护性、给出结论。很多评审之所以低效，是因为这六个动作全部挤在 Reviewer 打开 MR 页面的那一刻。
你想想看，如果 Reviewer 对这次改动的背景一无所知，他需要先翻 Issue、翻需求文档、翻聊天记录，才能开始看 diff。看完 diff 之后还要手动脑补“这个函数为什么从三行变成三十行”“这个异常为什么不抛出”“测试为什么少了一个 case”。整个大脑负载非常高，而 MR 页面本身并不能给他提供足够的上下文。
所以方案的第一步不是“写代码”，而是“降低评审的认知负担”。具体做法是把“背景信息”和“检查标准”前置到 MR 的模板里，让开发者在提交时就主动提供上下文。
我做了一个非常简单的 MR 描述模板，每个 MR 都必须填写这几块内容：
- 本次改动解决什么问题，关联哪个 Issue
- 变更的核心思路是什么，涉及哪些模块
- 关键设计决策，比如为什么选 A 方案不选 B 方案
- 测试范围和本地验证结果（加了什么用例、跑过哪些场景）
- 自查清单（照抄下文的标准检查项，逐条打勾）
这个模板上线之后，Reviewer 的反馈非常直接：以前要自己问东问西的，现在打开 MR 第一屏就能了解背景，可以直奔主题看代码。
2.2 评审清单是怎么定出来的
清单是我花了最多心思的部分。很多人说“评审靠经验”，但经验没法复制，清单可以。我把过往线上事故、严重 Bug、反复返工的代码模式做了归类，最终沉淀成一张五类检查清单。
第一类是功能性检查，重点看变更是否覆盖了需求描述的全部场景，有没有漏掉边界值。第二类是架构与设计检查，关注模块边界是否清晰、有没有引入循环依赖、扩展性是否被破坏。第三类是性能与并发检查，比如是否在循环里查库、锁的粒度是否过粗、缓存失效是否合理。第四类是安全与异常检查，比如用户输入是否被正确校验、异常路径会不会导致数据不一致、敏感信息有没有打日志。第五类是测试质量检查，确保新代码有对应单测、关键分支被覆盖、测试不是只测 happy path。
每一条都是一个建议性的问题，而不是命令。清单里最经典的一条是“如果我要改这个模块，需要动多少行不相关代码”——这个指标比什么耦合度都能说明问题。
我把清单做成 Markdown 文件放在仓库根目录的.github/review_checklist.md里，MR 模板中直接引用它。Reviewer 看代码的时候对照清单逐项过，把自己确认过的条目勾上，最终在 MR 评论中留下结论。这样做还有个副作用——每个 MR 的评论本身就是一份可追溯的评审记录，后面出问题时可以回头查“当时为什么这么评”。
2.3 自动化工具的边界：哪些交给人，哪些交给机器
有了清单之后，下一步是决定哪些检查交给自动化。我的原则很简单：凡是机器能干得比人好的，绝不让 Reviewer 干；凡是机器判断不了的，才交给人。
具体来说，自动化的第一层是“格式与规范层”，包括缩进、引号、分号、命名规范。这些琐碎的东西以前是评审中的吵架重灾区——有人觉得必须加分号，有人觉得不需要；有人用 4 空格，有人用 Tab。这种争论毫无价值，直接让 Prettier 统一掉。
第二层是“静态逻辑层”，用 ESLint、Stylelint 这类工具查“未使用变量”“可疑的空值判断”“重复代码”等问题。这一层能过滤掉很大比例的低级错误。
第三层才是“人”，人的精力集中在这几件事：业务逻辑是否正确映射了需求、架构设计是否合理、有没有隐藏的边界情况、测试是否真的有效。
我见过一些团队把自动化做到另一个极端：CI 里挂了 20 多个检查，随便提交一次代码要跑半小时，于是开发者开始想办法绕过检查，或者提交之前根本不在本地跑。这不是自动化的问题，是自动化目标没选对。自动化的目的是替人省时间，不是给人添麻烦。把 CI 总耗时控制在 5 分钟以内是我给自己定的一个硬指标。
3. 实操过程：从零搭建可落地的评审基础设施
3.1 提交规范与 MR 模板配置
第一步，固定提交信息格式。我采用的版本是type(scope): subject，type 限定为 feat、fix、refactor、docs、test、chore，scope 是模块名。这么做不为了好看，而是为了后续生成 changelog、追溯回归来源时能自动化。如果团队有人已经在用别的规范也没关系，关键是要统一，不要一个人一个格式。
第二步，定制 MR 模板。GitLab 下我放在.gitlab/merge_request_templates/Default.md，GitHub 对应.github/pull_request_template.md。模板内容不要写得太多，否则开发者会抗拒填写，五六行足矣。我的模板是这样的：
## 背景 （关联 Issue：编号，简要说明为什么要做这个改动） ## 变更内容 （列出主要变更点，不要复制 git log，用自己的话概括） ## 设计决策 （如果有多个可选方案，说明为什么选了当前这个） ## 测试验证 - [ ] 本地测试命令及结果 - [ ] 新增/更新了哪些测试用例 ## 自查确认 （对照 .github/review_checklist.md 逐项确认后贴入截图或不贴）这里有一个容易被忽略的小技巧：在模板里加一句“如果此 MR 改动超过 400 行，请说明拆分计划”，能从源头上逼开发者思考自己提交的粒度。后面我还会细讲“为什么 400 行是一个坎”。
3.2 搭建 CI 管道：让检查自动跑起来
CI 是整套方案的自动化骨架。我使用的是 GitLab CI，配置写在.gitlab-ci.yml里。我的管道分四个阶段：install、lint、test、build，代码检查在 lint 阶段完成。
这里给出一个经过实战精简的配置示例，你可以按自己的项目调整：
stages: - install - lint - test - build install: stage: install script: - npm ci cache: key: ${CI_COMMIT_REF_SLUG} paths: - node_modules/ only: - merge_requests - main lint: stage: lint script: - npx prettier --check . - npx eslint . --max-warnings=0 - npx tsc --noEmit only: - merge_requests - main test: stage: test script: - npm run test -- --coverage coverage: /All files[^|]*\|[^|]*\s+([\d.]+)/ only: - merge_requests - main build: stage: build script: - npm run build only: - main有几个细节我想单独说明一下。
--max-warnings=0是个狠活。很多项目的 ESLint 只在有 error 的时候失败，warning 直接忽略；但 warning 攒着攒着就成了无人区的垃圾场，所以我把 warning 也当 error 卡死。第一周团队会哀嚎一片，第二周就安静了，代码质量明显提升。
npm ci在 CI 里代替npm install。区别是npm ci严格按照 lockfile 安装，能避免“本地能过、CI 挂掉”的根本原因——依赖没有锁定。这是一个几乎所有 CI 从零搭建都会踩的坑。
npx tsc --noEmit在 JS/TS 项目里用来做类型检查。如果你的项目没用 TypeScript，这一步可以换成flow check或者其他静态检查命令。总之原则是：把能在提交时发现问题的手段全部前置。
3.3 本地钩子与增量检查：在源头拦下低级问题
CI 虽然能在提交到远端之后检查代码，但如果每个人都在本地把低级问题解决掉，整个流程会高效很多。这里用到的是 Git pre-commit 钩子。
在 Node.js 生态里最常用的组合是 husky + lint-staged。lint-staged 只对暂存区的文件做检查，也就是你git add过的那些文件，这样不会因为仓库里历史遗留的脏代码导致你提交不上去。
package.json里的配置可以这样写：
{ "husky": { "hooks": { "pre-commit": "lint-staged" } }, "lint-staged": { "*.{js,ts}": ["eslint --fix", "prettier --write"], "*.{json,md,css,scss}": ["prettier --write"] } }这个配置的效果是：你每次 commit 时，本地自动把暂存文件格式化一遍、修掉能自动修的 lint 问题，然后把修改追加进暂存区。如果你写的代码有严重的语法错误或者违反规则，commit 会被拦截，你必须先修好它。
有人可能会担心“本地钩子太烦人了，影响效率”。我的看法是：它拦截的是那些本来就不该存在的低质代码，被拦一次你记住一次，以后写的时候就会注意，长远来看是省时间的。真正的效率杀手不是“提前解决问题”，而是“问题在很晚才被发现”。
3.4 增量检查与老代码治理
这里有个非常现实的问题：如果项目历史悠久，存量代码的 lint 错误数以千计，你直接上--max-warnings=0，所有人都会原地爆炸，因为随便改一行文件，就要把整个文件的历史债务都还掉。
我的做法是分两步走。
第一步，存量代码放宽。对不符合规范的老文件，通过.eslintignore或者 ESLint 的 override 把它排除在 CI 强制检查之外。但这不能是一锤子买卖，要配上清理计划。我在仓库里建了一个tech-debt.md，记录所有“豁免文件”的清单和清理负责人，每季度专项消灭一部分。
第二步，新增代码严格卡死。用增量检查的方式做到“你能放宽存量，但不能放宽新增”。GitLab CI 里可以用git diff --name-only --diff-filter=AM拿到本次变更的文件列表，然后只对变更文件做严格检查。具体实现我写过一个脚本：
#!/bin/bash FILES=$(git diff --name-only --diff-filter=AM origin/main...HEAD | grep '\.js$') if [ -z "$FILES" ]; then echo "No JS files changed, skip" exit 0 fi npx eslint $FILES --max-warnings=0这个增量检查脚本配合存量豁免名单，能让团队在灰度推进代码质量时既不卡业务、又能守住新增质量红线。
3.5 让 Reviewer 更省力的 diff 展示策略
评审体验里有一个经常被忽视的元凶：MR 里的 diff 毫无上下文结构。几千行代码摊成一个平铺的 diff，Reviewer 看完第一屏已经忘了前面改了啥。
GitLab 和 GitHub 其实都支持按提交查看 diff，但不一定所有团队都习惯这么用。我要求的规范是：开发者在 MR 描述里写明“建议按 commit 逐一查看，commit 顺序代表实现步骤”。这样做有两个好处，一是把巨量变更拆成几个可独立理解的小步骤，二是 Reviewer 能顺着开发者的思路走，而不是自己在乱石堆里找路。
如果某个 MR 涉及重构，我还会建议开发者加一条“行为对比说明”，列举重构前后哪些行为保持不变、哪些行为发生了预期变化。这个习惯一开始需要有人提醒，但养成后对减少误判帮助极大。
再补一个容易踩的坑：不要在 MR 里混入无关的格式调整。你本来只想改一个函数，结果顺手把整个文件从 2 空格换成了 4 空格，Reviewer 的 diff 被格式噪音淹没，真正的逻辑变更反而不容易被看到。这一点可以直接写进团队约定里，并在自动化中通过只检查“逻辑改动文件”来辅助约束。
4. 核心难点拆解：Review 什么样的代码才算真正“看过”
4.1 高效评审五步法
有了流程和工具后，剩下最核心的问题就一个：Reviewer 拿到一个 MR 后，应该怎么读代码？
很多 Review 之所以是无效评审，是因为读代码的方式太随意。有的人从文件开头按顺序看到结尾，有的人只看自己熟悉的部分，还有的人干脆直接看测试过了没有就 Approve。为此我总结了一个“五步评审法”，流程是这样的：
第一步，读上下文。先看 MR 描述、关联 Issue、相关设计文档。没有上下文就直接看 diff 等于不看。这一步的目的不是找问题，而是建立“改动应该是什么样”的心理预期。
第二步，瞄全局结构。不要一上来钻细节，先浏览变更涉及了哪些模块、新增了哪些文件、改了哪些接口。在脑海里画一张“从入口到出口”的地图。
第三步，从核心逻辑入手。找到本次改动的主干路径，比如一个请求进来、经过哪几个函数、产生什么副作用、返回什么结果。先验证主干是否通顺，再检查分支。
第四步，逆推边界与异常。这个是最考验功力的环节。试着问自己：输入参数为 null 时会怎样？中间环节抛异常了会怎样？并发调用会怎样？数据量翻 100 倍会怎样？Reviewer 的经验体现在这几问上。
第五步，评估可维护性。代码是新功能合完之后就没人动了，还是未来一周内就会被扩展？如果是后者，命名是否准确、抽象是否合理、注释和文档是否对后人友好？
五步不是死规矩，但至少能保证你的评审不是盲人摸象。我把这个方法写进团队 Wiki 之后，“只看 diff 就评论”的比例明显下降，评审里的有效评论量反而上升了。
4.2 代码行数、评审速度与质量的平衡
“一个 MR 应该多大”是个经久不衰的话题。我的答案非常明确：最好保持在 400 行以内，越小越好。
这个数字不是拍脑袋拍的。有研究发现代码评审的有效性和变更规模成反比，当 diff 超过 400 行时，Reviewer 发现缺陷的能力显著下降。我自己的体感也差不多：一个 diff 在 200 行以内时，我能把它从头到尾仔细过一遍；到了 400 行，我会不由自主地开始扫读；超过 600 行，基本就变成“凭感觉看重点”了。
要在流程上限制 MR 大小，除了靠自觉，还可以从任务拆分入手。开发者规划任务时，如果发现一个功能需要写上千行代码才能完成，就要反思是不是设计上出了问题——是不是应该拆成多个 MR，是不是把非核心重构混进来了，是不是在同一个功能里改了太多无关的东西。
如果确实遇上一个 800 行的富重构类 MR，还有一种做法是要求 Reviewer 分批评审，先看第一波（比如基础重构），给完反馈之后再出第二波，避免一次性疲劳阅读。我在实际团队中把这个做法叫做“分阶段评审”，每次回复都用“本轮先看整体的、下一轮再抠细节”这样的节奏来走。
4.3 与机器共舞：静态分析结果如何辅助人做判断
很多人对静态检查工具又爱又恨。爱的是它能快速发现明显问题，恨的是它会误报，而且有时候“你改了按要求做，但还是会挂”。想让自动化真正成为评审的一部分，而不是评审的替代品，需要做好两件事。
第一，配置要贴合项目。默认配置永远不可能完美匹配你的业务，必须花时间按项目特性裁剪规则。比如 Node 服务端项目，我会关掉浏览器端的某些规则；而纯前端项目，审计库里某些依赖的规则又会更严格。这个调参过程可能最长需要两周，但我认为非常值得。
第二，把工具的结论当“线索”而非“判决”。ESLint 报了一个“no-non-null-assertion”不代表这里 100% 有 Bug，它只是提示你“这里使用了非空断言，是不是真的能保证不为空？”评审的关键价值，就是去判断这条线索指向的是真问题还是误报。
举个我经历过的例子：ESLint 有一条规则叫no-console，默认是禁止 console.log 进生产代码。刚上线时大家老老实实把调试日志删掉，后来有人开始用window.console.log绕过检查，被我发现后加了no-restricted-syntax在 AST 层面上直接禁止console的全部访问形式。这只是一个小点，但代表了一种态度——你需要对工具规则保持敬畏，也要持续根据团队实际情况调整规则强度的边界。
4.4 安全维度：在评审中前置安全意识
安全审查不是只有安全工程师才需要做的专项，而应该成为开发者的一个思维习惯。我在评审清单里加入了几个约等于“保命题”的检查项，强烈建议你把它们写进自己的清单。
- 用户输入（包括 query、body、header、文件上传）是否经过校验和转义？
- 鉴权逻辑是不是放在了数据访问的最外层，而不是每个方法里都重复做？
- 日志里会不会打印 token、密钥、手机号等敏感信息？
- 存在不存在越权读取的可能——比如用户 A 能通过篡改 ID 读取用户 B 的数据？
- 涉及支付、积分等资金类操作时，有没有做幂等和防重复提交？
尤其是“越权”这一项，我见过太多项目在业务开发时完全没考虑到，上线后被人用遍历 ID 的方式刷了个底朝天。代码评审是拦截这些问题成本最低的环节，比测试、渗透测试都要便宜得多。
我在安全上的一个实操经验是：组织一次“安全评审专项周”。一整周内团队不看业务功能，专门拿历史代码和安全检查清单过一遍，把发现的安全问题逐个建 Issue 追踪修复。这个活动做两周后，整个团队的安全敏感度提升了一个台阶，之后再写新代码时，很多安全问题在源头就被规避了。
5. 常见问题与排查技巧实录
5.1 评审等待时间长，MR 堆积成山
这是推行代码审查制度后最常见的问题，也是最容易让组织退回到“不分叉、直接推到主干”的导火索。根源无非两类：Reviewer 不够，或者等待机制不透明。
解决“Reviewer 不够”的办法是先有一个“公共评审者”阶段。小团队里，可以指定每个模块有两个 Code Owner，任何 MR 都必须由至少一个 Owner 通过才能合并。Owner 在 MR 中被自动指派，同时在 GitLab 的合并权限设置里强制开启“审批通过才能合并”，这就把“等评审”从口头约定变成了系统强约束。
解决“等待机制不透明”的办法是设置 SLA 约定。我们团队约定：工作时间内，Reviewer 必须 4 小时内给出第一轮反馈；如果 Reviewer 自己忙，需要在 MR 里明确标注“预计明天中午评审”，不能沉默到底。
人的时间是有限的，评审也是一种工作负荷，必须纳入排期。把“评审工时”想清楚之后，很多团队一算才发现“哦原来我们没有给评审留时间”，自然就会调整节奏，而不是嘴上喊着“大家多 review”却不断插 New 需求。
5.2 新人不知道如何开始 Review，评论质量低
新加入团队的同学通常代码能力不差，但 Review 起来不知道从何下手，要么不评论，要么只能评论“这里的命名可以改一下”。这是很正常的，本质上是团队知识库没有建立。
我的做法是给新人安排“影子评审”：前两周不强迫他独立负责 MR，而是让他给资深 Reviewer 的评论做“二次摘要”——阅读资深 Reviewer 对某个 MR 的评论，然后在自己的笔记里整理出“这个问题属于哪类问题”“为什么资深 Reviewer 会这么判断”。这样做既能帮新人积累经验，也能反哺团队的评审清单，把个案经验变成通用规则。
我还鼓励新人从测试覆盖入手做评审。一个 MR 里测试写得好不好、有没有针对边界条件的用例，是比较容易入手的角度。新人在这个维度上给出的评论通常质量不低，很快就能获得正反馈，慢慢建立信心。
5.3 自动化检查误报率高，CI 频繁失败
CI 频繁失败的另一个常见场景就是工具误报。比如 ESLint 对某些规则在特殊场景下的判断不准确，或者 prettier 和 eslint 的格式规则冲突，导致改了又改还是报错。
遇到误报的正确姿势是“基于证据修正 config”，而不是“绕过检查”。我通常的操作是：
- 复现问题，确认是配置冲突还是规则本身不适合。
- 如果是规则冲突，调整规则优先级或关闭其中一条。
- 如果是规则本身不适合，在 config 里用
rules关闭或降低级别，写上备注原因。 - 在 MR 里同时提交 config 修改与代码修改，让团队知道“这个规则为什么被调整了”。
误报率高的时候，先解决掉那些最刺眼、最频繁的几条规则，而不是一股脑全关掉。使用--quiet参数暂时隐藏 warning、只显示 error 也可以作为过渡期的缓解手段。
5.4 评审意见“互相抬杠”，讨论变成争论
代码评审中意见分歧是必然的，分歧本身是好事，但如果讨论方式不对，就会变成情绪对抗。我最常看到的一种争论是“我觉得这里应该抽象成一个基类”和“我觉得不需要，YAGNI”。双方都觉得自己有理，最后谁都不服谁。
我的处理原则是：区分“必须改”和“可以讨论”。在评审评论里明确标注严重程度，比如用[must]表示必须修改，[suggest]表示建议，[question]表示疑问。为这条约定设定一个硬规则：[must]的修改必须在合并前完成，[suggest]的评论可以讨论也可以直接忽略，但忽略要在 MR 评论里说明理由。
这个简单的标记法能大幅降低无意义争论。因为争论通常是双方对“这条意见的定位”认知不一致导致的，一旦明确了是“建议”还是“必须”，讨论就有了边界。
再补一个技巧：当两个 Reviewer 意见冲突时，最好有“最终决定者”的机制，由 Code Owner 拍板。绝对不要出现“两个资深工程师对着吵三天，业务侧等不住”的情况。决定做出后，无论结果倾向谁，另一方都需要记录自己的不同意见，但这不影响合并。
5.5 代码审查流于表面，Bug 依然漏到线上
有些团队把自动化做得很好、流程也走了，线上还是出故障，于是开始怀疑“代码评审到底有没有用”。这种情况通常不是评审没用，而是评审的“注意力放错了地方”。
最常见的漏网场景是“Reviewer 看了 diff，但没跑起来验证”。代码逻辑静态看没问题，一跑就出问题的情况太常见了。所以我在清单中明确要求，对于涉及核心链路的 MR，Reviewer 应该把分支拉下来实际跑一遍关键用例，不只是凭脑内模拟。
另一种漏网场景是“只看了新增代码，没看删掉的代码”。有时候一个功能改动的风险不是来自新加的代码，而是来自被删除的代码——别处的逻辑可能依赖它。尤其是重构型 MR，需要重点检查删除了哪些公共函数、是否还有调用方。
漏网最多的其实是“改 A 坏 B”的交叉边界问题。这个很难靠人盯出来，需要依靠足够的自动化测试来兜底。所以我在推行评审的同时，一直在督促团队补单测与核心 E2E 用例，这些用例本身就是“第三只眼睛”。
5.6 常见问题速查表
为了便于日常翻查，我整理了下面这张速查表。它覆盖了我推行 open-code-review 过程中团队成员最常问的 10 个问题，也基本对应文章讲到的各个要点。
| 问题 | 快速诊断 | 推荐解法 |
|---|---|---|
| MR 长时间无人评审 | 没有强制审批机制 | 开启合并审批制，指派 Code Owner |
| Reviewer 不知道看什么 | 缺少统一评审清单 | 部署五类检查清单，写进 MR 模板 |
| 评论总是迟到 | 评审负荷没排期 | 约定首轮反馈 SLA 时间 |
| 新人评论质量低 | 没有学习路径 | 影子评审 + 二次摘要 |
| CI 老失败 | 规则误报或配置不合理 | 基于证据修正配置，增量检查过渡 |
| 格式问题反复争论 | 没有统一格式化 | Prettier 强制 + commit 钩子 |
| 评审只走形式 | 没有真正的逻辑检查 | 五步评审法 + 核心链路实跑验证 |
| 两个 Reviewer 意见冲突 | 没有最终决策机制 | Code Owner 拍板，保留异议记录 |
| 线上出了漏点 | 自动化覆盖不足 | 补单测、核心 E2E、安全清单 |
| 团队抵触流程 | 流程太繁琐 | 砍掉冗余步骤，自动化能做的绝不手动 |
6. 度量与迭代：怎么知道这套流程真的有效
6.1 三个关键指标：评审耗时、有效评论率、缺陷逃逸率
任何方案不做度量都是耍流氓。代码评审流程也必须有数据反馈，否则你根本不知道哪里需要优化。
我日常看的指标有三个。
第一个是“评审耗时”，从 MR 创建到合并的总时长。这个数字过长说明评审阻塞严重，过短（比如 10 分钟内）则要警惕评审是不是走过场。我通常把平均值控制在 4-8 小时，超过 24 小时的 MR 每周复盘一次原因。
第二个是“有效评论率”。把评审评论分成三类：Bug/缺陷类、设计建议类、纯风格类。前两类是有效评论，第三类说明自动化没做到位、或者规范没被遵守。如果有效评论率太低，说明评审者没有真正投入，或者 MR 质量已经好到不需要评论——后一种情况当然也有，但按照经验前三周以第一种居多。
第三个是“缺陷逃逸率”，就是线上问题中有多少是“经过评审但没被发现的”。这个指标无法精确统计，只能结合故障复盘去估。我会在每次线上问题复盘时，特别打一个标签：该问题是否经过代码评审，评审时的结论是什么。如果连续多次发现问题都在评审中漏过，说明评审清单要更新，或者评审注意力的分配有问题。
6.2 迭代周期：月度回顾与规则更新
方案做出来不是一劳永逸的。我每个月用半天时间，召集团队做一个“Code Review 回顾会”。会议内容很固定：
- 拉出本月所有合入主干的高风险 MR，过一遍评审质量
- 统计评审耗时、评论数量、问题类型分布
- 讨论新增的、不容易被发现的 Bug 模式
- 更新评审清单与规则配置
这套“月度回顾”的价值，是让规则成为活文档而不是墙上的纸。比如我们就在某次回顾中新增了“禁止在循环中调用同步 IO 类函数”的检查项，因为那周连续出现了两个线上性能问题都源于这个模式。没有月度回顾，这些新认知就流失了。
6.3 度量不成负担：轻量表格与自动化报表
有读者可能担心度量本身会增加团队负担。我的经验是：不要一开始就上太重的东西，先用 Google Sheets / 飞书表格手动记录核心字段，再考虑做自动化报表。
手动阶段，我让每个开发者在 MR 合并后花 30 秒填一行：MR 链接、类型、评审耗时小时数、评论数、有效评论数、是否引发线上问题。一个月下来能积累一些数据，也够月度回顾用了。
等到团队规模大了、数据多了，再考虑用 API 自动拉取 MR 数据做报表。GitLab 的 API 可以拿到 MR 创建时间、合并时间、评论数量、参与人等信息，这些字段足够算出百分之八十的度量指标。我从手动表格切换到 API 自动化报表时，整体时间成本降低了一半，准确率也提升了。
我需要提醒的是：度量是用来改进流程的，不是用来考核个人的。如果变成了“评审慢了要扣分”，团队一定会想办法刷数据，最终损失的是实质质量。
7. 三个月的实战复盘与掏心窝子的体会
代码审查这个事，改的是流程，难的是人心。
我推行这套方案的头两周，最大的阻力其实不是“不知道怎么用”，而是“为什么要这么麻烦”。一个经历过无数线上事故的团队可能还好，但一个业务能跑、大家也没出过大事故的团队，通常觉得“我们已经在 Review 了啊”。直到我把那次因为没走严格评审而上线后数据被清掉的故障记录贴出来，会议室才安静下来。
所以如果你也想推行这套方案，我的第一个建议是：先找一个血淋淋的教训案例，不管是自己的还是行业公开的，让大家意识到“现状的代价”，而不是空谈“我们质量要提高”。
第二个体会是，方法要先僵化、再优化。推行前期别允许太多“例外”，例如“这个 MR 比较急，大家快点过一下”“这是临时修复，不用走完整流程”。例外开多了，系统就崩了。建议先把完整路径跑顺一个月，再根据真实反馈调整规则。先僵化，后优化，是最快的路径。
第三点是关于人的疲劳管理。评审确实是脑力活，一天要看三四个大 MR，注意力会明显下降。我后来定了个规矩：每个 MR 改动超过 400 行的必须拆分，每天评审总时长超过 1.5 小时要主动提醒自己放在第二天的 Review 队列，而不是硬撑着提 Approve。宁可晚一天合入，也不要一个满是漏洞的快速通过。
第四个体会是，自动化是手段，不是目的。我见过有团队把 CI 配置弄得极度复杂，全流程要跑 40 分钟，结果大家为了通过检查开始在提交信息里做手脚、在代码里加 eslint-disable。这等于把工具变成了新的负担。我的做法是：任何自动化规则上线前，先回答一个问题——这条规则能帮 Reviewer 省多少时间？回答不了的，不上线。
现在这套方案已经是我处理所有个人项目代码时的默认工作流，操作 GitHub 上的仓库也用同一套 MR 模板与本地钩子。它是开源工具组成的链路，所以叫 open-code-review——开放、透明、可复用。
最后分享一个小技巧：如果你现在连一个 MR 模板都没有，别想着一口气全都构建完成。建议就先加一个“MR 描述模板”，把“为什么改”和“怎么验证”这两栏写清楚。你会在第一周就发现评审效率产生了显著变化，这种正向反馈会推动你把剩下的环节慢慢补上。
代码评审的本质不是“给代码找错”，而是“让团队一起搞懂代码在做什么”。如果这套分享能帮你把评审从走形式变成真投入，我会觉得这几个月的复盘没有白写。
