代码评审分派要解决的是“谁来看、看什么、多久看完、看完怎么合入”这四个问题。把改动范围与风险、评审人来源与数量、指派与响应时限、合入条件写成可执行规则，分派才能稳定运行。本文给出评审人选择规则表、分派操作步骤、角色职责对照和完成检查清单，并在评审状态与合入条件的管理环节说明ONES可承载的方式。
要点总览（TL;DR）
- 先按改动类型定评审人来源与人数：文档与常规改动1–2人，公共接口、安全权限类改动2–3人并要求专家或合入把关人确认。
- 分派按四步执行：补齐改动说明、按规则匹配评审人、带时限通知、处理意见并按需重新分派。
- 提交人、评审人、模块负责人、合入把关人各有交付物；分歧由模块负责人裁决，跨模块由相关负责人共同确认。
- 合入以通过人数、关键角色确认、自动化检查三类条件收口，未闭环的退回并记录缺失项。
- 机制是否跑通看规则覆盖度、长期无人评审的改动、记录可追溯三项，按迭代周期检查并修订规则。
分派前先定规则：评审人怎么选、选几个
分派动作的质量取决于前置规则。如果每次提交都临时找人，评审人数量随心情变化，高风险改动和文档修订走同一套流程，分派就会变成协调负担。建议先把改动分类，再为每类改动固定评审人来源和人数，让指派成为按规则匹配的动作。
评审人来源通常有四类：代码归属人（最近修改该文件的开发者）、模块负责人（对目录或服务整体负责的人）、领域专家（涉及安全、性能、数据模型等专门知识的人）、轮值评审人（团队内按周轮换、承担常规改动的人）。四类来源可以组合使用，但每类改动应明确主评审人来自哪一类，避免出现“大家都相关、没人负责”的情况。
评审人数量按改动影响面确定。常规改动一名主评审人加一名同模块评审人即可；涉及公共接口、数据迁移、权限与支付等高风险改动，增加领域专家并要求模块负责人确认。改动越小、越局部，越应减少评审人，避免为一行修复拉三个人。下面是可直接套用的规则表，团队可按自身模块划分调整来源名称。
| 改动类型 | 评审人来源 | 人数 | 是否需专家 |
|---|---|---|---|
| 文档、注释、格式调整 | 同模块轮值评审人 | 1 | 否 |
| 模块内常规功能修改 | 代码归属人 + 同模块评审人 | 2 | 否 |
| 跨模块改动 | 各涉及模块负责人 | 每模块1人 | 视接口影响而定 |
| 公共接口、数据结构变更 | 模块负责人 + 领域专家 | 2–3 | 是 |
| 安全、权限、支付相关 | 模块负责人 + 安全或领域专家 + 合入把关人 | 3 | 是 |
| 紧急修复 | 模块负责人或值班评审人 | 1 | 事后补审 |
规则表要写清例外：紧急修复可以只由一名值班评审人放行，但需在合入后约定时间内补一次完整评审；高风险改动即使已有两名评审人通过，仍要求模块负责人做最终确认。例外条款越具体，分派时越少争论。
分派动作拆解：从提交到指派的四步
规则确定后，分派可以拆成四个连续动作。每一步都有明确输入、动作、输出和完成标志，便于提交人和评审人知道当前卡在哪一步。
第一步：提交时补齐改动说明
输入是本地改动和关联的工作项；动作是填写改动目的、影响范围、涉及模块、自测情况与风险判断；输出是一份可被评审人独立理解的提交说明；完成标志是说明中能回答“改了什么、为什么改、影响谁”。缺少影响范围的提交应退回补充，而不是直接指派，否则评审人需要反向猜测改动边界。
第二步：按规则匹配评审人
输入是提交说明中的模块与风险信息；动作是查规则表确定评审人来源与人数，从代码归属、模块负责人名单、专家名单或轮值表中取人；输出是具体评审人名单与主评审人；完成标志是名单中每个人都能对应到规则表中的一条来源。匹配冲突时按优先级处理：模块负责人优先于代码归属人，领域专家优先于普通评审人；被指派人休假或已满负荷时，由模块负责人指定同资质替代人，并记录替代原因。
第三步：指派后的通知与响应时限
输入是评审人名单；动作是发出指派通知，写明期望首次响应时间与评审完成时间；输出是带时限的评审任务；完成标志是每位评审人确认接收。时限可按改动规模约定，例如常规改动一个工作日内给出首次意见，高风险改动当天响应。超时未响应的，由提交人提醒一次，仍无响应则转交模块负责人重新分派。
第四步：评审意见处理与重新分派
输入是评审意见；动作是提交人逐条回复、修改或说明不修改的理由，意见涉及新模块时补充对应评审人；输出是意见处理记录与更新后的改动；完成标志是所有意见都有明确结论，新增影响面已由相应评审人确认。出现评审人认为改动方向需要重新设计时，应暂停合入并重新走一次分派，而不是在原评审串里继续追加讨论。
角色与交付物：谁负责什么
分派链路涉及四类角色。职责边界清楚，交接点才不会遗漏；每个角色在分派环节都应留下可核对的交付物。
| 角色 | 职责边界 | 分派环节交付物 | 交接点 |
|---|---|---|---|
| 提交人 | 写清改动说明、响应评审意见、发起重新分派 | 提交说明、意见处理记录 | 向评审人交付可评审的改动 |
| 评审人 | 在时限内给出意见，判断改动是否符合模块约定 | 评审意见与结论（通过/需修改） | 向提交人交付意见，向合入把关人交付结论 |
| 模块负责人 | 维护评审人名单与规则例外，处理缺席与冲突 | 评审人名单、替代指派记录 | 向提交人交付指派结果 |
| 合入把关人 | 核对合入条件是否满足，决定是否合入 | 合入检查记录 | 向团队交付合入结果 |
评审意见分歧时需要有裁决角色。通常由模块负责人裁决技术方案分歧，涉及跨模块接口时由各模块负责人共同确认，涉及安全与合规时由领域专家给出约束性意见。裁决角色应在规则中提前指定，而不是等分歧出现再找人。
这些角色和交付物如果散落在聊天记录里，分派状态就难以追踪。ONES 可以把改动关联到工作项，让评审人、评审状态与合入条件挂在同一条记录上，提交说明、意见处理和合入检查都留存在工作项中，便于模块负责人查看谁被指派、谁已响应、哪条改动还卡在评审环节。
合入条件与分派结果的收口
分派完成不等于评审完成。合入条件是把评审结果转成明确判断的收口机制，建议至少包含三类前置条件：达到规则要求的通过评审人数、关键角色确认、自动化检查通过。
- 通过评审人数：按改动类型对应的规则表核对，高风险改动需额外确认专家意见已闭环。
- 关键角色确认：模块负责人或合入把关人对高风险改动给出明确同意，口头同意需补记录。
- 自动化检查：构建、静态检查、单元测试等流水线结果通过，失败项需说明原因并记录豁免依据。
评审未闭环时，合入把关人应退回而不是放行。退回时写明缺失项：是评审人未响应、意见未处理，还是检查未通过；需要重新分派时，由模块负责人按规则补派评审人，并在记录中注明原指派与变更原因。合入完成后，合入记录与评审记录应一并留存，包含评审人名单、意见结论、检查结果和合入时间，便于后续追溯某次改动为何被放行。
示例：一次高风险改动的分派过程
以下为演示情景，用于说明规则如何落到具体动作。某团队的用户服务需要调整权限校验逻辑，改动涉及公共鉴权接口和两个调用方模块。
提交人先补齐说明：改动目的是收紧接口访问范围，影响鉴权服务与订单、报表两个调用模块，自测覆盖主要角色，风险判断为高。按规则表，这属于“安全、权限相关”改动，需要模块负责人、安全领域专家和合入把关人共三人评审。
分派顺序为：先指派鉴权模块负责人作为主评审人，再指派安全领域专家，最后指定合入把关人。订单与报表模块各由一名模块负责人确认调用方兼容性，作为附加评审人。通知中约定当天首次响应、两个工作日内完成评审。
评审过程中，安全专家提出令牌过期处理存在边界遗漏，提交人补充处理后重新提交；订单模块负责人确认调用方式无需修改。所有意见闭环后，合入把关人核对三名必要评审人通过、自动化检查通过、专家意见已处理，做出合入决定，并将评审记录与合入记录关联留存。
完成检查：分派机制是否跑通
规则上线后，需要从机制层面验证它是否可运行。建议按下面清单逐项核对，每项都给出可观察的判断依据。
- 规则覆盖度：抽查近期的改动类型，确认每种常见改动都能在规则表中找到对应的评审人来源与人数；出现规则表未覆盖的类型时，补充规则而不是临时口头指派。
- 响应与闭环：检查是否存在超过约定时限仍无人评审的改动，统计重新分派的次数与原因；长期无人评审的改动集中出现在哪些模块，往往说明该模块评审人名单需要更新。
- 记录可追溯：随机抽取若干次合入，确认能查到评审人名单、意见处理记录、合入检查结果与合入时间；记录缺失的环节应补入流程，而不是依赖个人记忆。
- 例外使用情况：核对紧急修复与替代指派的记录，确认例外都有事后补审或替代原因说明，例外比例过高时回头调整规则表。
三项检查可以按迭代周期做一次。规则覆盖度反映分派是否有据可依，响应与闭环反映指派是否落到人，记录检查反映结果是否可追溯。三者都通过，说明分派机制已经跑通；某一项反复出问题，就回到对应环节修订规则，而不是在每次评审时临时协调。
常见问题
团队规模小、没有专职模块负责人时，评审人规则怎么简化？
可以把模块负责人与代码归属人合并为“熟悉该目录的开发者”，在规则表中按目录而非按人指定主评审人。人数上保留常规改动1人、高风险改动2人的下限，专家角色由团队内最熟悉该领域的人兼任，并在规则中写明兼任名单。这样规则仍然可执行，只是角色数量减少，交接点相应简化。
紧急修复走了单人放行，事后补审怎么保证不流于形式？
补审需要在合入时就生成一条待办，写明补审时限、补审人和补审范围，而不是等有人想起来再补。补审人按规则表对应的高风险来源确定，补审结论同样记录通过或需修改。检查机制时把补审完成率作为一项观察指标，长期未补审的改动集中出现，说明例外条款需要收紧。
评审人长期不响应，除了重新分派还能怎么处理？
先区分原因：是通知没送达、时限约定不清，还是该评审人本身负荷过高。通知问题调整指派方式；时限不清在规则中写明首次响应与完成时间；负荷问题则由模块负责人更新评审人名单，增加轮值或替代人。重新分派只是兜底动作，反复出现说明名单与规则需要修订。
跨模块改动的评审人怎么指派，才不会互相等待？
按涉及模块各指派一名负责人，并明确其中一人为主评审人，负责汇总意见和判断是否闭环。分派通知同时发给所有评审人，约定同一响应时限，避免串行等待。接口影响较大时增加领域专家，由主评审人协调意见冲突，跨模块方案分歧由各模块负责人共同确认。
分派规则上线后，多久复盘一次比较合适？
可以按迭代周期做一次轻量检查，重点看规则覆盖度、超时未评审的改动和记录完整性；每个季度做一次较完整的复盘，统计重新分派次数、例外使用比例和补审完成情况。复盘结论落到规则表的修订上，而不是停留在讨论层面。
