本文给出一份虚构但自洽的代码评审规范示例，覆盖评审范围与分级、提交前自检、评审人分配、意见分级与回复、通过条件、合入与回退六个部分。示例中的团队规模、分级阈值、评审人数与时限均为演示取值，读者可对照自身分支策略与发布节奏替换。规范落地时，评审任务、意见状态与合入记录需要可追溯，ONES 可在这一管理环节承接。
要点总览（TL;DR）
- 示例给出七个字段的规范骨架：适用范围、变更分级、评审人规则、意见等级、通过条件、合入方式、回退条件，可逐项对照填写。
- 变更分级按影响面判定（数据结构、对外接口、核心状态逻辑、权限），比按代码行数更便于评审人判断和事后核对。
- 通过条件拆成人数、阻断意见关闭、建议意见有结论、自动化检查通过、描述完整五类可核对项，合入决定才有据可查。
- 迁移时先用历史合入数据校准分级阈值，再把自检项与自动化检查对齐，删除重复项，并约定规范负责人与复审周期。
- 示例阈值仅作演示，小团队应下调评审人数并改用跨模块互评，强监管团队需另行补充合规审批链。
这份示例要解决什么问题
这份示例面向正在起草或修订代码评审规范的技术负责人、研发组长和工程效能同学。它演示一份规范从条款到判定的完整写法，让读者拿到后能逐条对照改写，而不是从零构思格式。示例设定为虚构团队“星图”与虚构项目“订单服务”，团队 12 人、分 3 个小组，采用主干开发加短生命周期分支的方式，每周一次常规发布。所有角色、数字与场景均为演示，不代表任何真实团队的做法或成效。
一份能执行的代码评审规范，需要回答四类问题：谁评，即不同变更由谁评审、评审几人；评什么，即评审关注范围与提交前必须完成的自检；怎么算通过，即通过条件写成可核对的判定；合入后怎么兜底，即合入方式与回退条件。这四类问题缺一项，规范就容易停留在原则层面，评审时仍靠个人经验判断。
对应这四类问题，规范骨架可拆成七个字段，填写时逐项落值：
- 适用范围：规范约束哪些仓库、哪些分支、哪些变更类型。
- 变更分级：按影响面把变更分为若干级，每级对应不同评审要求。
- 评审人规则：评审人如何产生、需要几人、是否需要特定角色参与。
- 意见等级：评审意见如何分级，每级对应什么回复与处理要求。
- 通过条件：满足哪些条件才算评审通过，逐条可核对。
- 合入方式：使用哪种合并方式、合并前执行哪些检查、分支如何处置。
- 回退条件：出现什么情况触发回退，由谁决定，如何记录。
这七个字段构成示例的骨架。下一节按此顺序填入具体条款，形成一份可直接对照改写的填写版。
完整示例：一份代码评审规范（填写版）
以下为“星图”团队订单服务的代码评审规范填写版。文中团队、项目、角色与阈值均为虚构演示。
一、适用范围
本规范适用于订单服务主仓库的全部合入请求，覆盖主干分支与发布分支。文档、配置样例等非代码变更同样走评审，评审人数可按变更分级下调一级。紧急修复按第七条的例外条款处理。
二、变更分级与评审要求
变更按影响面分为三级，评审人数与时限按下表执行。时限从提交合入请求起算，按工作小时计。
| 级别 | 判定标准（示例） | 评审人数 | 评审时限 | 附加要求 |
|---|---|---|---|---|
| 一级：高影响 | 涉及数据库结构变更、对外接口签名变更、支付与订单状态核心逻辑、权限校验 | 2 人，其中 1 人为模块负责人 | 1 个工作日内首次响应 | 需附影响面说明与回退方案 |
| 二级：一般 | 常规业务逻辑修改、内部接口调整、依赖升级 | 1 人 | 1 个工作日内首次响应 | 依赖升级需注明版本与变更点 |
| 三级：低影响 | 注释、日志文案、单元测试补充、无行为变化的格式调整 | 1 人 | 2 个工作日内首次响应 | 可合并评审，不单独占用评审会 |
分级由提交人初判，评审人有权上调级别；下调级别需模块负责人确认。
三、提交前自检与描述模板
提交合入请求前，提交人需完成自检并在描述中逐项填写。自检项包括：本地构建与单元测试通过；新增或修改逻辑有对应测试；无调试代码与临时开关残留；涉及配置变更的已注明默认值与回滚方式；涉及数据变更的已附迁移脚本与验证方式。
描述模板固定为五段：变更目的、影响范围与分级、验证方式与结果、回退方案、关联任务编号。缺少任一段的合入请求，评审人可退回补充，不计入评审时限。
四、评审意见分级与回复要求
评审意见分为三级，提交人需逐条回复，回复即视为对该条意见的处理结论。
- 阻断：存在正确性、安全性或数据风险，必须修改后才能通过。提交人修改后回复修改说明，由提出人确认关闭。
- 建议：可改进但不影响本次合入，提交人可选择本次修改、另建任务跟进或说明不采纳理由。选择另建任务的需附任务编号。
- 提问：评审人对实现意图或边界条件不清楚，提交人回复解释即可关闭，无需代码改动。
评审人提出意见时需标注等级；未标注等级的，提交人可按提问处理并请评审人确认。
五、通过条件与合入方式
合入请求满足以下全部条件才算评审通过：达到对应级别的评审人数且均为同意；全部阻断意见已关闭；建议意见均有明确处理结论；自动化检查（构建、单元测试、静态检查）全部通过；描述模板五段填写完整。
合入采用压缩合并，合入后删除源分支。一级变更合入发布分支前，需由模块负责人在发布记录中登记。合入操作由提交人执行，评审人不代执行，以便责任归属清晰。
六、例外与回退条款
线上故障修复可走例外通道：由值班负责人口头确认后先行合入，24 小时内补齐评审与描述。例外合入需在合入记录中标注“例外”及确认人。
出现以下情况触发回退：合入后监控出现与本次变更相关的错误率上升；核心流程验证失败；发现阻断级问题在评审中遗漏。回退由提交人或值班负责人执行，回退后在原合入请求中记录原因与影响范围，并补充评审复盘意见。
逐项解释：每条规则为什么这样写
示例条款的取值都有可替换的替代写法，理解取值理由比照抄数字更重要。
变更分级为何按影响面而非代码行数
代码行数与风险的相关性有限：一行权限判断改错的影响可能超过数百行文案调整。示例用“是否触及数据结构、对外接口、核心状态逻辑、权限”作为分级依据，评审人容易判断，也便于事后核对。替代写法是按“变更涉及的服务与调用方数量”分级，适合服务拆分较细的团队；两种写法都要求判定标准可观察，避免“感觉比较重要”这类主观描述。
评审人数与角色如何避免形式化通过
示例要求一级变更的 2 人中含 1 名模块负责人，目的是让熟悉该模块历史与边界的人参与，减少“点同意但没看”的情况。人数并非越多越好：人数增加会拉长等待，且第三人往往依赖前两人的判断。替代做法是对高影响变更要求“跨组评审”，即评审人来自调用方团队，适合接口变更频繁的场景。无论哪种写法，都应明确评审人产生规则，例如按模块代码归属自动指定，而非提交人自行挑选熟人。
意见分级如何减少无效往返
未分级的意见常导致两种低效：提交人把提问当成阻断反复修改，或把阻断当成建议直接合入。示例要求评审人标注等级，提交人按等级采取不同动作，回复即关闭，减少“改了但没有回应”的悬空状态。替代写法是只分“必须修改”和“可选”两级，适合评审量较小的团队；分级越细，对评审人标注习惯的要求越高。
通过条件为何写成可核对判定
“代码质量良好”“评审充分”这类描述无法判定，也无法在争议时作为依据。示例把通过条件拆成人数、意见状态、自动化检查、描述完整性四类可核对项，任一项不满足即不通过。这样做的代价是需要工具或流程记录每项状态，收益是合入决定有据可查。替代写法是把自动化检查设为强制门禁、把意见状态交由评审人确认，适合已有持续集成基础的团队。
回退条款与合入方式的配套关系
回退能否快速执行，取决于合入方式是否留下清晰边界。示例采用压缩合并并删除源分支，每次合入在主干上对应一个提交，回退时可直接定位；若采用频繁的小步合并且不保留合入记录，回退范围就难以界定。因此回退条款要与合入方式一起设计：合入记录越清晰，回退条件越容易写成可执行的判定。替代写法是保留合入提交并打标签，适合需要按版本整体回退的发布模式。
从一个示例迁移到自己的规范
示例不能直接照搬，迁移的关键是把演示取值换成团队自身的约束。以下步骤按顺序执行，每步都有可交付的产物。
- 对齐现有分支策略与发布节奏。先写清团队使用主干开发还是发布分支、发布频率、是否有冻结期，再决定变更分级。产物是一页现状说明，作为后续条款的前提。
- 用历史变更数据校准分级阈值。抽取近三到六个月的合入记录，按“是否触及数据结构、对外接口、核心逻辑、权限”统计分布，检查一级变更占比是否过高或过低。占比过高说明判定标准过宽，评审会成为瓶颈；过低说明高风险变更被漏判。产物是分级判定标准与预期占比。
- 把自检项与自动化检查对齐。逐条核对自检项中哪些已由构建、测试、静态检查自动完成，删除重复项，只保留机器难以判断的内容，例如回退方案是否可执行。产物是精简后的自检清单与描述模板。
- 约定规范复审周期与修改入口。明确谁有权修改规范、修改走什么流程、多久复审一次。产物是规范文档的负责人与复审日期。
迁移过程中，评审任务的分派、意见等级的状态流转、合入与回退记录的留存，需要有承载位置。ONES 可将合入请求对应为工作项，把评审意见记录为带状态的评论或子项，合入与回退动作留痕在同一工作项下，便于按变更分级核对通过条件。是否采用工具承载取决于团队现有流程，规范条款本身应先确定。
示例的适用边界与常见误用
示例的阈值与角色设定服务于演示，直接套用会在两类团队中出问题。小团队人数少，一级变更要求 2 人评审可能导致无人可评或评审人固定为一两人，此时应下调人数并改用跨模块互评；强监管团队对评审留痕、审批层级有额外要求，示例未覆盖合规审批链，需按所在行业规定补充。两类情况都应重设阈值，而非调整示例文字了事。
常见误用有三类。其一，把示例中的时限当作承诺对外公布，时限取决于团队响应能力，应先测量再设定。其二，把规范写成工具配置说明，条款围绕某个按钮或字段展开，工具更换后规范失效；规范应描述判定与责任，工具只作承载。其三，只写通过条件不写回退条款，合入后出现问题缺少处理依据。
示例不构成对任何工具能力的承诺。规范落地需要三项管理承载：评审任务能分派到具体评审人并显示状态；意见能按等级记录并追踪关闭；合入与回退记录可按变更追溯。这三项是流程要求，具体实现方式由团队现有工具决定。评审等待时长、评审吞吐等效率指标的分析方法不在本文范围，需要时另行讨论。
常见问题
团队人少，凑不齐示例要求的两名评审人怎么办？
示例中一级变更要求 2 人评审，前提是团队有足够熟悉该模块的人。人数不足时，可把一级变更的评审人数下调为 1 人，同时要求评审人来自调用方或相邻模块，用跨模块互评补上视角差异。另一种做法是把高风险变更集中到固定的评审窗口，由值班负责人统一评审，避免每次临时找人。无论怎么调整，评审人产生规则要写清楚，例如按模块代码归属指定，减少提交人自行挑选的空间。
规范里的评审时限可以直接对外承诺吗？
不建议直接承诺。示例中的“1 个工作日内首次响应”是演示取值，实际时限取决于团队当前的响应能力和评审负载。更稳妥的做法是先统计一段时间的合入请求从提交到首次评论的间隔，取一个多数情况能达到的值作为初始时限，运行一两个发布周期后再调整。时限写成内部约定，与对外承诺分开表述，避免因临时人力紧张造成违约。
自动化检查已经覆盖的内容，还需要写进提交前自检吗？
不需要重复。自检清单只保留机器难以判断的部分，例如回退方案是否可执行、配置默认值是否合理、迁移脚本的验证方式是否说明。构建、单元测试、静态检查这类能由流水线自动判定的项目，写成通过条件里的强制门禁即可。重复列在自检里会增加提交人负担，也容易让人形成“勾选即完成”的习惯。
紧急修复走例外通道后，补评审要注意什么？
例外通道的价值在于缩短故障恢复时间，补评审的价值在于留下可追溯的记录。补评审时重点看三件事：修复本身是否引入了新的边界问题；例外合入是否按约定在记录中标注了确认人；同类问题是否需要补充测试或监控。补评审的时间窗口要写进规范，例如 24 小时内，超期未补的由模块负责人跟进。例外次数本身也值得定期回看，频繁触发说明常规流程存在阻塞点。
规范写好后，怎么判断它是否真的在被执行？
可以从记录层面核对几个可观察的点：合入请求的描述是否按模板五段填写完整；阻断意见是否都有提出人确认关闭的记录；一级变更是否都有对应角色的评审参与；回退事件是否在原合入请求中记录了原因。这些点都能从评审与合入记录中查证，比问卷式检查更可靠。发现偏差时先判断是条款不合理还是执行不到位，前者改条款，后者补流程承载。
