代码评审规范要能直接指导日常操作：先按变更风险划分评审等级，再规定提交前自检、评审请求写法、评审意见分级和合入条件，最后用角色分工与检查清单固定下来。规范的核心产物是一份评审分级表、一份评审检查清单和一套合入准入规则。本文按从提交到合入的顺序给出可执行步骤，并附一个中等风险变更的演示情景和落地检查清单。
要点总览（TL;DR）
- 代码评审规范应包含五部分：适用范围与分级、提交前准备、评审执行、合入准入、例外与记录，每部分对应可查阅的表格或清单。
- 按变更类型、影响范围和是否涉及核心链路划分L1至L3三级，分别约定评审人数、领域负责人参与、测试证据和响应时限。
- 提交前完成自检并写清改了什么、为什么改、怎么验证、重点看哪里，能减少评审中的低价值往返。
- 合入需同时满足评审通过、阻断意见清零、必要检查通过、关联记录完整；紧急合入走批准加补评审的留痕通道。
- 规范落地后按周期抽查分级执行、请求完整性、阻断意见状态和例外记录，例外频繁出现时优先调整分级与时限。
一份可执行的代码评审规范包含哪些内容
代码评审规范的价值在于让不同的人对同一类变更做出相近的判断。它需要覆盖五个部分：适用范围与分级、提交前准备、评审执行、合入准入、例外与记录。每个部分都对应一个可被查阅和核对的产物，避免停留在“认真评审、及时沟通”这类原则表述上。
| 组成部分 | 回答的问题 | 产物形式 |
|---|---|---|
| 适用范围与分级 | 哪些变更需要评审，不同风险走什么流程 | 评审分级表 |
| 提交前准备 | 提交者要完成哪些自检，评审请求写什么 | 自检清单、评审请求模板 |
| 评审执行 | 评审人看哪些维度，意见如何分级处理 | 评审检查清单、意见分级规则 |
| 合入准入 | 满足什么条件才能合入 | 合入准入规则条目 |
| 例外与记录 | 紧急情况怎么走，事后如何留痕 | 例外审批与补评审记录规则 |
篇幅上建议控制在团队能在一刻钟内读完的范围，正文以表格和清单为主，原则性描述只保留必要的判定依据。颗粒度以“新成员看完能独立发起一次评审”为准：分级规则要能直接对照变更判断，检查清单要能逐项勾选，合入条件要能作为放行与否的依据。规则过细会增加维护成本，过粗则无法执行，可以先覆盖高频变更类型，运行一个迭代后再补充边界情况。
第一步：按变更风险划分评审等级
所有变更一刀切，要么让低风险改动承担不必要的等待，要么让高风险改动得不到足够审视。分级的目的，是让评审人数、评审深度和响应时限与变更的实际影响相匹配。
分级依据建议取三项：变更类型（新功能、缺陷修复、配置与脚本、依赖升级）、影响范围（单模块、跨模块、公共组件）、是否涉及核心链路（登录鉴权、支付、数据写入等）。三项组合后归入三个等级，判定时以影响最大的一项为准。
| 等级 | 典型情形 | 评审人数 | 领域负责人 | 测试证据 | 响应时限 |
|---|---|---|---|---|---|
| L1 低风险 | 单模块内的缺陷修复、文案与日志调整、注释与文档 | 1人 | 不需要 | 自测说明即可 | 1个工作日内 |
| L2 中风险 | 新功能、跨模块改动、配置与脚本变更、非核心依赖升级 | 2人 | 按需 | 自测记录加相关用例结果 | 1个工作日内 |
| L3 高风险 | 核心链路改动、公共组件与基础库、数据库结构变更、核心依赖升级 | 2人以上 | 必须 | 测试用例结果加回归范围说明 | 2个工作日内启动 |
填写方式是在评审请求中勾选等级并写明判定理由，例如“L2：涉及订单与库存两个模块的接口调整”。评审人发现分级偏低时可以直接上调，下调则需要领域负责人确认。这一步的输入是变更内容与影响面，动作是对照分级表判定并记录理由，输出是带等级的评审请求，完成标志是等级与理由已填写且评审人数量满足要求。
第二步：提交前自检与评审请求的写法
评审中的大量往返来自信息缺失：评审人不知道改动目的、验证方式，或者一次提交混入了多个不相关的修改。把准备工作前移到提交环节，能显著减少这类低价值沟通。
提交前自检建议包含四项：变更范围是否只包含本次任务相关内容；自测是否完成并留有结果；是否关联了对应的需求或缺陷编号；是否写清了对外部模块和既有功能的影响。自检未通过时不发起评审。
评审请求应回答四个问题：改了什么、为什么改、怎么验证、需要重点看哪里。最后一项尤其容易被忽略，明确指出风险点能让评审人把注意力放在关键位置，而不是逐行通读。
- 变更粒度：单次提交聚焦一个可独立描述的改动，建议控制在评审人一次能完整理解的规模；重构与功能修改分开提交。
- 拆分原则：按逻辑单元拆，而不是按文件数量拆；无法拆分的较大改动在请求中说明原因并约定分段评审。
- 完成标志：评审请求包含上述四项信息，自检清单已勾选，变更已推送并可供查看。
第三步：评审执行与意见分级处理
评审人需要一份固定的检查维度，避免凭个人习惯抽查。检查清单可按变更等级裁剪，L1 侧重正确性与可读性，L3 增加安全、权限与回归影响。
| 检查维度 | 关注点 |
|---|---|
| 正确性 | 逻辑是否满足需求，边界条件是否处理 |
| 异常处理 | 错误分支、超时、空值与失败重试是否有对应处理 |
| 可读性与命名 | 命名是否表意，结构是否便于后续维护 |
| 测试覆盖 | 新增逻辑是否有对应用例，关键分支是否被覆盖 |
| 安全与权限 | 输入校验、敏感信息处理、权限判断是否到位 |
| 既有功能影响 | 是否影响被调用方、公共组件或数据兼容性 |
意见按处理要求分为三级：阻断合入（必须修改并重新确认）、建议修改（应处理，确有理由可不改但需说明）、可选优化（记录即可，不阻塞流程）。评审人提出意见时标注级别，提交者逐条回应，形成“提出—回应—确认”的闭环。
分歧处理约定升级路径：提交者与评审人对某条意见无法达成一致时，由领域负责人裁定，裁定结论记录在评审请求中。响应时限沿用分级表中的约定，超时未评审时由提交者提醒或转交备选评审人。这一步的输入是带等级的评审请求，动作是按清单评审并分级提意见，输出是意见清单与回应记录，完成标志是所有意见均有明确状态。
第四步：合入准入条件与例外处理
合入判定需要一组明确条件，全部满足才允许合入：评审通过且所需人数已确认；阻断级意见清零；必要的自动化检查通过；关联的需求或缺陷记录完整。合入执行者在放行前逐项核对，任一项不满足则退回。
紧急情况需要一条留痕的通道，而不是绕开规范。建议的例外流程是：由团队负责人或值班负责人批准，在评审请求中标注紧急原因与批准人；合入后约定时限内完成补评审，补评审发现的问题按普通缺陷处理并记录。例外记录应可查询，便于事后统计频率。
合入后的回看包括两项动作：确认变更在生产或测试环境的表现符合预期；对补评审的变更检查问题是否已闭环。这一步的输入是评审完成的变更，动作是核对准入条件并决定放行，输出是合入记录与例外记录，完成标志是准入项全部核对完毕且记录可追溯。
当团队把评审请求、意见状态和合入记录分散在聊天工具与代码托管平台之间时，核对成本会明显上升。ONES 可以把需求、缺陷与代码变更关联到同一工作项，让评审意见的处理状态和合入记录随工作项流转，便于在合入前集中核对准入条件，也便于事后追溯例外情况。具体配置方式需结合团队使用的代码托管方式确认。
角色分工与各环节交付物
规范落到人身上才可执行。各角色的职责边界与交接时点如下表，团队规模较小时可以一人兼多个角色，但职责仍需分开表述。
| 角色 | 职责边界 | 交付物 | 交接时点 |
|---|---|---|---|
| 提交者 | 完成自检、判定等级、编写评审请求、回应意见 | 自检清单、评审请求、意见回应记录 | 发起评审时、意见处理后 |
| 评审人 | 按清单评审、分级提意见、确认修改 | 分级意见清单、评审结论 | 响应时限内 |
| 领域负责人 | 确认高风险变更分级、裁定分歧、审批例外 | 裁定结论、例外批准记录 | 分歧发生时、例外合入前 |
| 合入执行者 | 核对准入条件、执行合入、记录结果 | 合入记录 | 合入前核对、合入后记录 |
| 团队负责人 | 维护规范、复审分级与例外情况 | 规范修订记录、复审结论 | 固定周期复审时 |
评审工作量分摊可以按模块归属分配默认评审人，再设一名备选，避免请求集中在少数人身上。高风险变更的领域负责人由模块负责人担任，保证判定有明确责任人。
示例：一次中等风险变更的完整评审过程
以下为演示情景，用于说明规范如何串联执行，不代表任何真实项目。
变更背景：某团队需要调整订单查询接口，使其支持按时间范围筛选，涉及订单模块与网关层的参数校验。提交者对照分级表判定为 L2：属于新功能、跨两个模块、不涉及核心支付链路，因此需要 2 名评审人，测试证据为自测记录加相关用例结果。
提交前自检：提交者确认改动仅包含该功能相关文件，自测覆盖了无参数、单边时间、跨月范围三种情况，关联了对应需求编号，并在影响说明中注明网关层参数校验规则有调整。评审请求写明：改了什么（新增时间范围筛选参数）、为什么改（运营按时间段查询订单）、怎么验证（三种自测场景加两条用例）、重点看哪里（网关层参数校验与空值处理）。
评审过程：第一名评审人提出一条阻断意见，指出时间范围未做上限校验，可能引发大范围查询；第二名评审人提出一条建议修改，认为参数命名与既有接口不一致；另有一条可选优化，建议补充日志。提交者修改上限校验并补充用例，统一命名，日志优化记录为后续任务。阻断意见经评审人确认关闭，建议修改项说明处理结果。
合入判定：合入执行者核对评审人数满足、阻断意见清零、自动化检查通过、需求关联完整，执行合入并记录。整个过程未触发例外流程。
可迁移的规律是：分级决定投入，请求信息决定评审效率，意见分级决定收敛速度，准入核对决定放行质量。四者缺一，规范就容易在压力下被跳过。
规范落地后的完成检查
规范发布不等于落地。可以按固定周期抽查一批已合入的变更，逐项核对以下内容，判断规范是否真正运行。
| 检查项 | 通过标准 | 证据来源 |
|---|---|---|
| 分级是否被执行 | 评审请求均标注等级与理由，抽查样本中分级与变更内容相符 | 评审请求记录 |
| 评审请求信息是否完整 | 四项信息齐全，重点评审位置有说明 | 评审请求内容 |
| 阻断意见是否清零后合入 | 合入时无未关闭的阻断意见 | 意见状态与合入记录 |
| 例外是否留痕 | 紧急合入均有批准人与补评审记录 | 例外记录 |
| 角色是否履职 | 高风险变更均有领域负责人参与 | 评审参与人记录 |
规范本身也需要复审，建议每个季度或每个大版本结束后检查一次：分级规则是否覆盖了新出现的变更类型，检查清单是否有长期无人使用的条目，例外频率是否偏高。例外频繁出现通常说明分级或时限设置与实际节奏不匹配，应调整规则而不是放任绕过。
常见失效信号包括：评审请求只有一句“请 review”、意见长期停留在未回应状态、合入记录中查不到对应评审、例外没有批准人。对应的纠正动作分别是补充请求模板并抽查、明确响应时限与备选评审人、将评审记录与合入记录关联、恢复例外审批并要求补评审。检查结果应形成简短结论并指定改进责任人，下一周期复查同一批指标。
常见问题
团队规模很小，评审人凑不齐两个，分级表还能用吗？
可以调整人数要求，但建议保留分级判断本身。小团队常见做法是L1维持1人，L2和L3由同一名评审人加一名模块负责人共同确认，或者由领域负责人承担第二评审人的角色。关键是把“谁确认过”记录清楚，而不是把等级取消。人数减少后，高风险变更的测试证据和回归范围说明应更完整，用证据补足人力。
紧急修复上线时来不及走完整评审，怎么处理才不算破坏规范？
把紧急合入设计成规范内的例外通道，而不是临时绕开。建议由团队负责人或值班负责人批准，在评审请求中写明紧急原因和批准人，合入后在约定时限内完成补评审，补评审发现的问题按普通缺陷记录并跟踪闭环。例外记录要可查询，定期统计频率；如果某类变更反复走例外，说明分级或时限与实际节奏不匹配，应调整规则。
评审意见长期没人回应，规范里应该约定什么？
在规范中同时约定响应时限和升级路径。响应时限沿用分级表的约定，例如L1和L2在一个工作日内、L3在两个工作日内启动评审；超时未评审时，提交者可以提醒或转交备选评审人。意见本身也要有状态：提出、已回应、已确认关闭。团队负责人按周期抽查未回应意见的数量，长期堆积时先检查评审工作量分摊是否过度集中。
评审检查清单条目很多，每次都要逐项过一遍吗？
检查清单按变更等级裁剪使用。L1侧重正确性、异常处理和可读性；L2增加测试覆盖与既有功能影响；L3再增加安全与权限、数据兼容性等维度。清单中连续多个周期无人使用的条目，可以在规范复审时删除或合并，避免清单变成形式化勾选。裁剪规则本身应写进规范，让评审人知道哪些维度在什么等级下必须看。
规范运行一段时间后，怎么判断需要修订？
建议每个季度或每个大版本结束后复审一次，重点看三类信号：新出现的变更类型是否无法归入现有等级；例外合入的频率是否偏高；检查清单是否有长期空置的条目。例外频繁通常指向分级过严或时限过紧，应调整规则而不是默认绕过。复审结论和修订内容形成简短记录，指定责任人，下一周期复查同一批检查项。
