代码评审分派要真正明确责任和交付要求，关键是把“谁评、评什么、评到什么程度、何时给结论”写进分派规则和评审单，而不是依赖口头约定。本文按角色划分、评审单字段、执行步骤、完整示例和完成检查五个环节展开，适用于希望建立或优化代码评审与合入机制的研发团队。
要点总览（TL;DR）
- 按变更类型确定评审角色：业务逻辑、公共组件、配置与脚本、紧急修复分别对应不同的主评审人与领域评审人来源，作者不能自评自合。
- 评审单固定四类交付要求：变更范围与影响面、检查项清单、结论口径（通过/有条件通过/退回）、时限与响应约定，让每次评审有统一输入和可核对的输出。
- 执行流程分四步：提交评审、分派确认、评审执行、合入判定，每步都有输入、动作、输出和完成标志，避免流程停在“已提交、待处理”。
- 合入责任人核对的是评审结论与检查项是否齐全，遗留问题要有责任人和关闭时间；有条件通过的变更在遗留问题关闭前不越过约定条件合入。
- 用定期抽查判断机制是否生效：角色覆盖、字段完整、结论口径统一、遗留问题可追踪、合入可追溯、超时有转交或升级记录。
分派前先定角色：谁对哪类变更负责
评审责任落不到具体角色，分派就会退化成“谁有空谁看”。分派规则的第一步是按变更类型确定评审角色，让每类变更都有可预期的评审人来源，而不是每次临时找人。
常见的角色划分包括四类：作者、主评审人、领域评审人和合入责任人。作者对变更说明和自检负责；主评审人对评审完整性负责，判断是否需要追加领域评审人；领域评审人对特定领域的正确性负责；合入责任人对合入前的条件核对负责。四类角色可以兼任，但职责边界要分开写清。
| 角色 | 核心职责 | 交付物 |
|---|---|---|
| 作者 | 说明变更范围与影响面，完成自检，响应评审意见 | 填写完整的评审单、修改记录 |
| 主评审人 | 组织评审，逐项核对检查项，给出结论 | 评审结论、遗留问题清单 |
| 领域评审人 | 对特定领域（如支付、权限、公共组件）的正确性给出意见 | 领域评审意见 |
| 合入责任人 | 核对评审结论与检查项后决定是否放行 | 合入记录、放行或退回说明 |
分派规则可以按变更类型设定：业务逻辑变更默认由模块主评审人评审；公共组件变更必须增加组件维护人作为领域评审人；配置与脚本变更由运维或平台负责人评审；紧急修复可以简化流程，但需要事后补评审并记录原因。默认主评审人建议按代码目录或模块归属产生，规则写进团队约定，减少每次协商。
还要明确一条底线规则：作者不能自评自合。作者可以是评审参与者，负责解释和修改，但结论和合入放行应由其他角色完成。紧急情况下由值班负责人代行合入责任，并在评审单中记录代行原因。
评审单要写清的四类交付要求
评审单是把交付要求固定下来的载体。字段设计的目标是让评审人有统一输入、让结论可核对、让遗留问题可追踪。建议至少覆盖四类内容。
变更范围与影响面。要求作者写明改了什么、影响哪些模块和调用方、是否涉及数据或配置变更、回滚方式。这一项决定评审人需要看多深，也是判断是否需要领域评审人的依据。
检查项清单。把评审关注点拆成可逐条勾选的条目，通常包括正确性（边界条件、异常处理）、可读性（命名、结构、注释）、测试覆盖（新增或修改的测试、未覆盖部分的说明）、风险点（兼容性、性能、安全）。检查项不宜过多，按团队实际关注点取舍，每条都要能给出“通过/不通过/不适用”的判断。
结论口径。统一为三种：通过、有条件通过、退回。通过表示可以直接合入；有条件通过表示遗留问题已登记责任人和关闭时间，可在约定条件下合入；退回表示存在必须修改的问题。遗留问题要写清描述、责任人、计划关闭时间，避免“先合再说”。
时限与响应约定。约定提交后多久给出首次响应、多久给出结论，例如一个工作日内首次响应、两个工作日内给出结论。超时未响应的处理方式也要写明，比如由主评审人转交或升级给模块负责人。时限约定用于形成可预期的节奏，具体数值由团队根据变更规模确定。
| 字段类别 | 必填内容 | 填写人 |
|---|---|---|
| 变更范围与影响面 | 改动内容、影响模块、回滚方式 | 作者 |
| 检查项清单 | 正确性、可读性、测试覆盖、风险点逐条结论 | 主评审人及领域评审人 |
| 结论口径 | 通过/有条件通过/退回，遗留问题及责任人 | 主评审人 |
| 时限与响应 | 提交时间、首次响应时间、结论时间 | 主评审人 |
分派与评审的执行步骤
规则和字段确定后，需要串成一条从提交到合入的连续流程。每一步都应有明确的输入、动作、输出和完成标志，避免流程停在“已提交、待处理”。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 提交评审 | 代码变更、变更说明 | 作者填写评审单，按模块归属指定主评审人 | 待评审的评审单 | 评审单字段完整，主评审人已确认接收 |
| 分派确认 | 评审单、变更类型 | 主评审人判断是否需要领域评审人并补充分派 | 评审人名单 | 所需角色均已确认参与 |
| 评审执行 | 代码变更、检查项清单 | 评审人逐条给出结论，登记遗留问题 | 评审结论、遗留问题清单 | 检查项全部有结论，遗留问题有责任人和关闭时间 |
| 合入判定 | 评审结论、检查项结果 | 合入责任人核对结论与遗留问题状态后放行或退回 | 合入记录或退回说明 | 合入记录可追溯到评审结论 |
执行中有两个容易松动的环节。一是分派确认：主评审人接收后应尽快判断变更是否触及公共组件、配置或安全相关代码，触及则补充领域评审人，而不是等到评审中途才发现缺人。二是合入判定：合入责任人核对的是评审结论和检查项是否齐全，而不是重新做一遍评审；发现结论缺失或遗留问题未登记时退回补充，不直接放行。
当团队使用 ONES 管理研发任务时，可以把评审单作为工作项的一部分记录，将代码提交与对应需求或任务关联，评审结论和遗留问题随工作项流转，合入前在任务上核对评审状态。ONES 支持通过业务需求、研发任务等工作项拉取代码分支，并通过代码提交与工作项关联，便于在需求交付过程中查看代码进展与风险；在项目、迭代、需求中也可以查看代码提交、流水线构建等过程。这样评审责任和交付要求就落在同一条工作项记录上，便于后续追溯。
一个完整示例：支付模块变更的评审分派
以下为演示性情景，用于说明角色、字段和步骤如何配合，不代表真实客户案例。
背景。某团队修改支付回调的重试逻辑：调整重试次数上限，增加失败告警，并修改相关配置项。变更涉及业务逻辑和配置，影响支付结果通知的可靠性。
角色分派。作者为支付模块开发人员，负责填写评审单并完成自检。主评审人按模块归属默认为支付模块负责人。由于变更涉及支付回调这一关键链路，主评审人确认后补充支付领域评审人；配置项变更部分由平台负责人作为领域评审人核对。合入责任人由当周值班的发布负责人担任。
评审单关键字段。变更范围写明：重试次数上限从固定值改为可配置，新增失败告警上报，影响支付回调失败后的补偿路径，回滚方式为恢复原配置。检查项逐条填写：正确性核对重试边界和幂等处理；可读性核对配置读取方式；测试覆盖说明新增了重试失败和告警触发两类用例；风险点标注告警频率可能上升。时限约定提交后一个工作日内首次响应，两个工作日内给出结论。
结论与遗留问题。领域评审人指出告警阈值缺少上限保护，主评审人给出“有条件通过”：遗留问题为增加告警频率上限，责任人为作者，计划在两个工作日内关闭，关闭前不放开全量配置。合入责任人核对结论和遗留问题登记后，允许在测试环境先行验证，全量合入待遗留问题关闭后执行。整个过程在评审单和工作项上都有记录，后续可以查到谁在什么时间给出了什么结论。
完成检查：责任与交付要求是否真正落地
机制是否生效，可以用一组可核验的检查项来判断。建议在团队内定期抽查若干评审单，逐项对照。
- 每类变更都有明确的主评审人，公共组件、配置与脚本、紧急修复等类型有对应的领域评审人规则，抽查的评审单中不存在无人接收或临时指定却无记录的情况。
- 评审单字段完整：变更范围、影响面、检查项、结论、时限均有填写，空字段有说明而不是留白。
- 结论口径统一：抽查的结论只出现通过、有条件通过、退回三种，未出现含义模糊的表述。
- 遗留问题有责任人和关闭状态：每条遗留问题都能查到负责人和当前状态，有条件通过的变更在遗留问题关闭前没有越过约定条件合入。
- 合入前检查可追溯：每个合入记录都能对应到评审结论，作者自评自合的情况有例外记录和审批说明。
- 时限执行有反馈：超时未响应的评审有转交或升级记录，而不是长期挂起。
检查发现的问题应回到规则本身修正：如果某类变更反复缺少领域评审人，就补充该类变更的分派规则；如果遗留问题经常无关闭状态，就把关闭状态设为合入前的必填核对项。通过几轮抽查和规则修正，评审分派会从个人习惯变成团队可执行、可追溯的固定机制。
常见问题
小团队人手少，作者同时担任主评审人是否可行？
作者可以参与评审，负责解释变更和响应意见，但结论和合入放行应由其他角色完成，这条底线规则在小团队同样适用。人手少时可以用兼任方式解决：由同一名同事担任主评审人和合入责任人，或由模块负责人代行合入责任，但要在评审单中记录兼任或代行的原因。这样既保留了责任分离，也避免因缺人导致评审长期挂起。
紧急修复来不及走完整评审流程，怎么处理责任和交付要求？
紧急修复可以简化流程，但简化的是评审时机，不是责任记录。建议约定：紧急修复由值班负责人代行合入责任，评审单至少填写变更范围、影响面和回滚方式，合入后在一个约定时间内补做完整评审并记录原因。补评审时重点核对正确性与风险点，遗留问题照常登记责任人和关闭时间。这样紧急通道有据可查，也不会让简化流程变成长期惯例。
评审人长期不响应，分派规则应该怎么补？
先检查时限约定是否写清并被执行：提交后多久首次响应、多久给出结论，超时未响应由谁转交或升级。规则上可以设两级兜底，主评审人超时未响应时转交同模块其他评审人，仍无响应则升级给模块负责人。同时把超时情况纳入定期抽查，如果某类变更反复超时，说明默认主评审人设置不合理或评审负载集中，需要调整分派规则，而不是只催个人。
评审结论和合入记录怎么保证能对应上？
关键是让合入动作以评审结论为前提。合入责任人放行前核对评审单上的结论和检查项是否齐全，合入记录中注明对应的评审单或工作项。团队使用 ONES 管理研发任务时，可以把评审单作为工作项的一部分记录，将代码提交与对应需求或任务关联，评审结论和遗留问题随工作项流转，合入前在任务上核对评审状态，后续可以追溯到谁在什么时间给出了什么结论。
有条件通过的变更，遗留问题关闭前能否先合入？
可以，但要在评审单中写清合入条件和范围。有条件通过的含义是遗留问题已登记责任人和计划关闭时间，可在约定条件下合入，例如先在测试环境验证、暂不放开全量配置。合入责任人核对的是条件是否被遵守，遗留问题关闭前不越过约定条件。如果遗留问题涉及正确性或安全风险，应改为退回，等修改完成后再评审。
