Code Review要真正约束合入行为，需要同时回答两个问题：这次变更由谁评审，满足什么条件才能合入。本文给出一套可执行的规则设计方法，包括评审人分配表、合入检查清单、角色分工和周期性检查表，帮助团队把“凭经验判断”变成“按规则核对、有记录可查”。
要点总览（TL;DR）
- 评审人名单由变更内容推导：以代码所有权文件、模块负责人、架构或安全角色为来源，按功能改动、公共库与接口、配置与部署脚本、紧急修复区分必选与加签。
- 合入标准写成可逐项核对的清单，标注阻断项与提醒项，并为每条标准指明判定依据和证据位置，如评审记录、流水线结果、工作项链接。
- 作者、评审人、合入人、模块负责人各有明确动作与产出，评审结论使用通过、需修改、拒绝的统一表达，合入人对阻断项负责。
- 把最少批准数、必选评审人、状态检查配置到代码托管平台的分支保护与合并请求规则中，评审记录与合入结果关联到需求或任务工作项。
- 定期抽查评审记录、统计例外合入与补审完成情况、核对代码所有权文件更新，发现偏差时区分规则不清与执行不到位并明确责任人。
先定评审人：按变更范围划分评审责任
评审人名单应当由变更内容推导出来，而非每次临时指定。可行的做法是先建立代码所有权关系，再按变更类型叠加必选角色，最后用风险等级决定是否加签。这样同一类变更每次都能得到结构相近的评审名单，作者提交时也知道该找谁。
评审人来源主要有三类：代码所有权文件（如OWNERS、CODEOWNERS）中登记的路径负责人，负责判断该目录下改动是否符合模块约定；模块负责人，对业务逻辑与边界条件负责；架构或安全角色，在涉及公共接口、鉴权、数据存储、部署配置时介入。三类来源可以组合使用，先覆盖高风险路径，再按变更类型补充。
不同变更类型的评审要求应区别对待。功能改动通常由模块负责人主评；公共库与接口改动影响多个调用方，需要接口维护方加签；配置与部署脚本改动涉及运行环境，需要运维或SRE角色确认；紧急修复可以简化流程，但必须保留事后补审。把差异写进规则表，评审人确定就有据可依。
| 变更类型 | 必选评审角色 | 加签条件 | 最少通过人数 |
|---|---|---|---|
| 普通功能改动 | 模块负责人 | 涉及跨模块调用时加签被调用方负责人 | 1人 |
| 公共库与接口 | 模块负责人、接口维护方 | 涉及鉴权或数据格式变更时加签架构或安全角色 | 2人 |
| 配置与部署脚本 | 模块负责人、运维或SRE | 涉及生产环境参数时加签值班负责人 | 2人 |
| 紧急修复 | 模块负责人或值班负责人 | 事后由原模块负责人补审 | 1人（事后补足常规要求） |
必选评审人与可选加签人要分开定义。必选人未批准则不能合入，加签人用于影响面较大的变更，由作者或系统根据路径自动加入。单人评审适用于改动局部、测试覆盖充分的功能变更；双人评审适用于公共库、接口、配置与安全相关改动。评审人数量与响应时间也应写入约定，例如必选评审人应在工作日内一个工作日内给出首次意见，超时由模块负责人协调替代人选，避免合并请求长期悬置。
再定合入标准：把条件写成可核对的清单
合入标准如果只写“评审通过、测试通过”，执行时容易各自解释。更有效的做法是把每条标准写成可逐项判断的条目，标注判定依据和证据位置，并区分阻断项与提醒项。阻断项不满足时系统或合入人应拒绝合入，提醒项由合入人判断是否接受并记录理由。
常见条目包括：达到规定数量的评审通过；关键角色（模块负责人、接口维护方、安全角色）已批准；自动化检查（构建、单元测试、静态检查、安全扫描）全部通过；与目标分支无冲突；变更说明完整并关联需求或缺陷工作项。每条标准的判定依据应指向具体记录，例如评审意见状态、流水线检查结果、工作项链接，避免口头确认。
| 检查项 | 类型 | 判定依据 | 证据位置 |
|---|---|---|---|
| 评审通过数达到要求 | 阻断项 | 批准人数与规则表一致 | 合并请求评审记录 |
| 关键角色已批准 | 阻断项 | 必选评审人状态为已批准 | 评审记录中的角色标记 |
| 自动化检查通过 | 阻断项 | 构建、测试、静态检查均为成功 | 流水线运行结果 |
| 无合并冲突 | 阻断项 | 目标分支可自动合并 | 合并请求状态 |
| 变更说明与工作项关联 | 提醒项 | 说明包含改动目的、影响范围、验证方式 | 合并请求描述与工作项链接 |
| 回滚预案 | 提醒项 | 高风险变更附回滚步骤 | 变更说明或发布单 |
紧急合入需要保留例外通道，但例外本身也要有规则：明确谁有权批准例外（通常是模块负责人加值班负责人），要求记录例外原因与影响范围，并约定事后补审的时限与责任人。例外记录应进入定期检查范围，防止紧急通道变成常规路径。
角色与交付物：谁在什么时点做什么
规则要落到人身上才有执行力。作者、评审人、合入人、模块负责人在流程中承担不同动作，每个动作都应有明确产出和完成标志，避免出现“提了没人看、看了没结论、合了没记录”的情况。
| 角色 | 动作 | 产出 | 完成标志 |
|---|---|---|---|
| 作者 | 提交前自检、编写变更说明、关联需求或缺陷 | 合并请求描述、自检记录 | 说明包含目的、影响范围、验证方式，工作项已关联 |
| 评审人 | 按粒度提出意见并给出结论 | 评审意见与通过、需修改、拒绝的结论 | 结论明确，遗留问题有处理人或关闭理由 |
| 合入人 | 逐项核对合入清单、执行合入、记录例外 | 合入记录、例外说明 | 阻断项全部满足，例外已登记 |
| 模块负责人 | 维护代码所有权与评审标准、处理争议 | 所有权文件更新、标准修订记录 | 规则变更经过评审并通知相关方 |
评审意见的粒度值得单独约定：指出问题时尽量定位到文件与行，说明是阻断性问题还是建议；结论使用统一表达，避免“看起来可以”这类模糊状态。合入人对清单负责，遇到条件不满足时应退回作者或发起例外审批，不能自行跳过阻断项。
示例：一次跨模块变更的评审与合入过程
以下为演示情景，用于说明规则如何执行。某团队需要修改订单服务中的优惠计算逻辑，同时调整公共金额工具库的一个函数签名，并更新部署配置中的超时参数。
作者提交合并请求后，按规则判断影响范围：订单服务属于交易模块，金额工具库为公共库，部署配置涉及生产环境。系统根据代码所有权自动推荐交易模块负责人和公共库维护方为必选评审人，作者补充加签安全角色，因为金额计算涉及权限校验。最终评审人名单为：交易模块负责人、公共库维护方、安全角色，最少通过人数为2人，其中公共库维护方为必选批准人。
合入人逐项核对清单：评审通过数达到2人，公共库维护方已批准，构建与单元测试通过，静态检查无新增告警，目标分支无冲突，变更说明关联了需求工作项并写明回滚方式。核对过程中发现安全角色尚未给出结论，属于阻断项未满足，合入人将请求退回作者等待评审，未执行合入。
安全角色随后提出权限校验需补充一个边界用例，作者补充测试后重新提交。由于发布窗口临近，团队评估后决定先合入订单服务改动，公共库签名变更延后一个版本，并通过例外审批记录拆分原因、审批人和补审时限。该例外进入月度检查，补审在三个工作日内完成。
落地到工具：用平台规则约束评审与合入
规则写在文档里容易被绕过，配置到代码托管平台才能形成稳定约束。常见做法包括：对主干与发布分支启用保护，要求合并请求达到最少批准数、必选评审人批准、状态检查通过后才允许合并；用代码所有权文件自动推荐评审人；把合并请求与需求或任务工作项关联，使评审记录和合入结果可以回溯。
配置要点可以对应前文的规则逐条落地：最少批准数对应评审人数量约定；必选评审人对应代码所有权与关键角色；状态检查对应自动化检查阻断项；合并请求模板对应变更说明与工作项关联。平台能力因产品而异，具体配置项需按团队实际使用的代码托管平台核验，本文不展开具体版本与参数。
评审记录与合入结果还需要与需求、任务等工作项建立关联，便于后续追溯“这次合入解决了哪个需求、经过了谁评审”。在ONES中，可以将合并请求对应的开发任务与需求工作项关联，评审结论和合入状态随工作项流转记录，检查时从工作项即可回看评审与合入过程。规则本身的变更也应有维护责任人和评审动作，例如代码所有权文件调整需经模块负责人确认后生效。
完成检查：规则是否真的在运行
规则建立后需要定期核对执行情况，否则容易出现“规则存在但没人遵守”。检查不必追求复杂指标，重点是确认评审记录完整、例外可控、规则文件与实际代码结构同步。
| 检查项 | 通过标准 | 责任人 |
|---|---|---|
| 抽查合并请求评审记录 | 抽样请求均有符合规则的批准记录，必选评审人到位 | 模块负责人 |
| 例外合入统计 | 例外数量在约定范围内，均有审批人与补审记录 | 合入人或值班负责人 |
| 补审完成情况 | 例外合入在约定时限内完成补审 | 模块负责人 |
| 代码所有权文件更新 | 目录调整或人员变动后文件及时更新 | 模块负责人 |
| 偏差修正 | 发现未按规则执行的请求有退回、补审或规则修订记录 | 团队负责人 |
检查频率可按发布节奏设定，例如每个迭代抽查一次合并请求，每月汇总例外合入与补审情况。发现偏差时先判断是规则不清还是执行不到位：规则不清则修订评审人分配表或合入清单，执行不到位则明确责任人和纠正动作。检查结果与修正记录一并留存，下一轮检查时对照确认问题是否关闭。
常见问题
小团队评审人少、响应慢，评审人规则可以怎么简化？
可以先保留必选评审人这一层，把加签条件收窄到真正高风险的变更，例如公共接口、鉴权和部署配置。普通功能改动由模块负责人单人评审，跨模块调用时再临时加签被调用方负责人。响应时间约定可以按团队实际节奏调整，但需要写明超时后的替代人选，避免合并请求长期悬置。规则简化后仍要保留记录，便于后续检查是否被遵守。
紧急合入走了例外通道，事后补审应该怎么管？
例外通道需要同时记录三件事：例外原因与影响范围、审批人、补审责任人与时限。补审应在约定时限内完成，并由模块负责人确认结论。例外记录要进入定期检查范围，统计数量和补审完成情况；如果例外频繁出现，说明常规流程存在阻塞点，应回头修订评审人分配或合入清单，避免紧急通道变成默认路径。
合入清单里的提醒项，合入人可以自行决定跳过吗？
提醒项与阻断项的区别在于是否允许合入人判断。提醒项不满足时，合入人可以基于变更风险决定是否接受，但需要记录接受理由，例如变更说明不完整但影响范围极小、回滚预案缺失但属于低风险配置调整。阻断项不满足时不能合入，应退回作者或发起例外审批。把判断理由留在合并请求记录中，后续检查才有依据。
代码所有权文件经常和实际代码结构脱节，怎么维护？
可以把所有权文件的更新纳入目录调整和人员变动的常规动作：新增模块或调整目录结构时同步更新对应路径负责人，人员转岗或离职时由模块负责人确认接替人。定期检查中增加一项，核对所有权文件覆盖的路径与实际代码目录是否一致。规则变更本身也应经过评审并通知相关方，避免文件长期停留在旧状态。
评审记录和合入结果如何与需求、任务对应起来？
常见做法是在合并请求描述中关联需求或任务工作项，并在工作项上记录评审结论与合入状态，使一次合入可以回溯到它解决的需求和经过的评审人。在ONES中，可以将合并请求对应的开发任务与需求工作项关联，评审结论和合入状态随工作项流转记录，检查时从工作项即可回看评审与合入过程。具体关联方式需按团队实际使用的代码托管平台与协作工具核验。
