制定代码评审规范，核心是把“谁在什么条件下评审、什么条件下可以合入”写成可判定的条款，而不是罗列编码偏好。本文给出一份可直接成文的五块骨架——变更分级、角色职责、评审检查项、合入条件、记录与例外，并说明如何用一个团队试点两周、依据评审记录修订，最后固化为检查清单与合入规则。
要点总览（TL;DR）
- 规范先划边界：按变更类型与风险分三到四级，明确各级评审人数与合入要求，并把代码优化、算法选型排除在阻断条件之外。
- 规范正文按五块成文：变更分级、角色职责、评审检查项、合入条件、记录与例外，每条规则都要有判定条件和责任人。
- 角色分工落到交付物：作者交说明与自检，评审人区分阻断项与建议项，合入人核对条件，例外审批人负责加急与补审。
- 先在一个团队、一类变更上试点两周，收集评审轮次、阻断项分布与例外次数，据此修订条款并保留版本记录。
- 发布前用验收清单核对：规则可判定、检查项可勾选、例外路径闭合、新成员能独立走通一次评审与合入。
先定边界：规范管哪些变更、不管哪些事
规范的第一页应当回答“管什么”。边界不清的规范通常有两个后果：评审人对风格细节争论不休，真正的高风险变更却缺少足够的人看。建议先按变更类型与风险把仓库内的变更分成几级，再为每级规定评审要求。
分级不必复杂，三到四级足够一个团队起步。下面是一份可参考的分级示例，具体阈值由团队按系统实际情况填写。
| 级别 | 典型变更 | 评审要求（示例） |
|---|---|---|
| 高（核心链路） | 支付、登录、订单主流程、数据迁移脚本 | 至少两名评审人，其中一名为该模块负责人；合入前流水线全部通过 |
| 中（公共组件与配置） | 公共库、接口契约、构建配置、权限配置 | 至少一名熟悉该模块的评审人；涉及接口变更需通知调用方 |
| 低（局部改动） | 单模块内的缺陷修复、文案与日志调整 | 一名评审人；自检清单完成即可提交 |
| 紧急修复 | 线上故障处置 | 可先合入后补审，须在约定时限内补齐评审记录 |
同时要写明规范不覆盖的内容，避免评审会变成方案讨论会：代码优化方案、算法选型、性能调优的具体做法，属于设计评审或技术方案讨论的范围，评审人可以在评论中提出建议，但不作为合入的阻断条件。规范也应说明与需求评审、测试验收的分工——需求是否做对由需求评审和验收把关，代码评审关注的是这次变更本身是否正确、可维护、可回退。
核心步骤：五块内容写成一份可执行规范
规范文本宜短，建议控制在一份文档内，按以下五块组织。每块都要有判定条件和责任人，避免出现“应充分考虑”“必要时评审”这类无法执行的表述。
第一块：变更分级标准
写清分级的判定依据，例如按涉及模块、是否改动对外接口、是否涉及数据与权限、是否可在不发布的情况下回滚。给出每级对应的评审人数、评审人资格和流水线要求。分级由作者在提交时标注，评审人有权上调级别。
第二块：角色与职责
至少定义四类角色：作者、评审人、合入人、例外审批人。每个角色写明职责边界和不可兼任的情形，例如作者不能作为自己变更的唯一评审人。
第三块：评审检查项
检查项按维度分组，每条写成可勾选的是非判断：正确性（边界条件、异常处理、并发与事务）、可维护性（命名与结构是否与现有代码一致、是否引入重复逻辑）、安全与权限（输入校验、敏感信息是否入库或入日志、权限判断位置）、测试覆盖（新增逻辑是否有对应测试、测试是否能在本地运行）、变更说明（是否说明改了什么、为什么改、如何验证、如何回滚）。
第四块：合入条件
合入条件必须是机器或人可核对的：达到该级别要求的通过人数；所有阻断项评论已解决或明确关闭；流水线检查通过；变更说明完整。建议明确“建议项不阻断合入，但需在记录中保留”，防止评审人用个人偏好卡住变更。
第五块：记录与例外
规定评审结论、评论处理情况和合入操作需要留痕，留痕位置统一。例外路径写明适用情形（如线上故障、发布窗口临近）、审批人、补审时限和补审未完成的处理方式。评审记录、检查项勾选与合入条件核对需要有承载位置，ONES 的工作项与文档可以承担这部分管理动作：变更关联到工作项，检查项以清单形式随变更流转，合入前的条件核对结果留在同一处，便于事后追溯。
角色与交付物：谁在什么时点交出什么
把规范落到人，关键是每个角色都有明确的输入、动作、输出和完成标志。下表可作为规范附录直接使用。
| 角色 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 作者 | 需求或缺陷单、变更代码 | 填写变更说明，逐项完成自检清单，标注变更级别，关联需求或缺陷 | 可提交评审的变更，含说明与自检结果 | 说明字段无空缺，自检项全部勾选或有说明 |
| 评审人 | 变更说明、代码差异、检查项清单 | 按检查项逐条给出结论，评论标注为阻断项或建议项 | 评审结论与分类评论 | 每条检查项有结论，阻断项均已明确 |
| 合入人 | 评审结论、流水线结果 | 核对通过人数、阻断项状态、流水线结果与说明完整性 | 合入操作与核对记录 | 合入条件逐项满足并留痕 |
| 例外审批人 | 例外申请、风险说明 | 判断是否同意降级或先合入，指定补审人与时限 | 例外审批记录与补审任务 | 补审在时限内完成并归档 |
角色表要配合一条兼任规则：合入人可以由模块负责人或值班人担任，但不能由作者本人担任；例外审批人应是能对线上风险负责的人，通常为技术负责人。规则写明后，评审时就不需要每次临时找人拍板。
示例：一次中等风险变更的评审与合入过程
以下为演示情景，用于说明规范条款如何被执行，数值与角色均为示例。
提交。作者修改了公共组件中的日期处理函数，按分级标准标注为“中”。变更说明写清三点：修复跨时区场景下的日期偏移；影响三个调用方；验证方式为新增单元测试并在测试环境回归。自检清单中“是否通知调用方”一项勾选为“是”，并附上通知记录。
评审。评审人按检查项逐条给出结论。正确性一项发现未处理空输入，标为阻断项；可维护性一项建议将重复的格式化逻辑抽为私有方法，标为建议项。作者修复阻断项后重新提交，评审人确认关闭；建议项记录在案，作者说明本次不处理的原因，评审人接受。
合入。合入人核对：通过人数达到中级别要求的一名，阻断项已全部关闭，流水线通过，变更说明完整。核对结果记录在变更关联的工作项中，随后执行合入。
例外。若同一变更因发布窗口临近申请先合入，例外审批人需确认风险可控，指定补审人和补审时限，并在记录中写明。补审完成后关闭例外记录；未按时补审的，由审批人跟进并在下次评审回顾中说明。
试点与修订：让规范在真实评审中站住
规范成文后不要直接全团队推行。建议选一个变更量适中、成员配合度高的团队，先覆盖一类变更（例如公共组件与配置类），试点两周。周期过短收集不到足够样本，过长则问题暴露太慢，两周是一个可调整的起点。
试点期间需要收集三类记录：每个变更的评审轮次（提交到通过经过几轮）、阻断项的分布（集中在哪些检查项）、例外次数与补审完成情况。这些记录直接指向规范的薄弱处——如果阻断项大量集中在“测试覆盖”，说明检查项表述不清或团队缺少测试习惯，需要补充判定示例；如果例外频繁发生，说明分级或时限设置与实际节奏不符。
修订触发条件建议写进规范本身：试点结束、连续出现同类争议、例外次数超过约定比例时启动修订。规范文档要有版本号和修订记录，每次修订说明改了哪条、依据是什么，避免口头约定替代文本。评审等待时长、评审吞吐等流动效率指标属于研发效能分析的范畴，不在本规范内设定阈值，规范只保证记录可被后续分析使用。
完成检查：规范可用的判定标准
规范发布前，用下面这份清单逐项核对。全部满足，才算达到可执行状态。
- 每条规则都有明确的判定条件和责任人，抽查任意三条，能回答“谁在什么情况下做什么”。
- 检查项以可勾选的是非题呈现，评审人不需要额外解释就能给出结论。
- 阻断项与建议项的区分标准写清楚，并说明建议项的处理方式。
- 合入条件可逐项核对，且核对结果有统一留痕位置。
- 例外路径闭合：有申请、有审批人、有时限、有补审未完成的处理办法。
- 变更分级有示例，作者能独立判断自己变更的级别。
- 找一名未参与制定的新成员，只读规范完成一次模拟评审，能走通提交、评审、合入全流程，且提出的疑问不超过约定数量。
- 规范文档有版本号与修订记录，试点与修订的触发条件已写入。
这份清单也可以作为每季度回顾规范时的检查表：条款是否仍与团队实际做法一致，例外是否在收敛，新成员是否仍能按规范独立完成评审。
常见问题
团队规模很小，还需要做变更分级吗？
需要，但可以简化。分级的作用是让高风险变更获得足够的人看，与团队人数无关。小团队可以从两级起步：涉及核心链路、数据与权限的变更要求两人评审，其余变更一人评审。级别由作者提交时标注，评审人有权上调。等变更量和争议点积累起来，再细分级别。
评审人之间意见不一致，规范里应该怎么处理？
规范要预设分歧处理路径，而不是留到评审时临时协调。常见做法是：评论先标注为阻断项或建议项，只有阻断项影响合入；对阻断项是否成立有分歧时，由该模块负责人裁定，裁定结论记入评审记录。若同类分歧反复出现，说明对应检查项表述不清，应作为修订触发条件更新规范文本。
紧急修复先合入后补审，补审没按时完成怎么办？
例外路径必须闭合。规范中写明补审时限、补审人和未完成的处理方式，例如由例外审批人跟进、在下一次评审回顾中说明原因，并记录该次例外。例外次数本身也是试点与修订的依据：频繁出现说明分级或时限与实际节奏不符，应调整条款，而不是长期靠口头放行。
规范写好后，怎么判断它真的被执行了？
看记录而不是看文本。抽查若干变更，核对变更说明是否完整、检查项是否逐条有结论、阻断项是否关闭、合入条件核对是否留痕。再找一名未参与制定的成员，只读规范完成一次模拟评审，能独立走通提交、评审、合入全流程，说明规范具备可执行性。记录缺失的位置，通常就是条款需要补充判定条件的地方。
评审检查项应该写多细？
细到评审人能给出是非结论即可，不必写成编码手册。按正确性、可维护性、安全与权限、测试覆盖、变更说明分组，每条对应一个可勾选的判断，例如“新增逻辑是否有对应测试”。过细会拖慢评审，过粗则无法区分阻断项与建议项。试点期间统计阻断项集中在哪些检查项，据此补充判定示例或拆分条目。
