代码评审分派要解决的是“每次改动由谁评、评到什么程度、多久给回应”。做法是先定规则，再定角色，最后落到提交、指派、评审、合入的动作上。本文按规则、操作步骤、角色职责、完整示例和上线检查五部分展开，帮助团队把临时拉人变成可重复执行的分派机制。
要点总览（TL;DR）
- 分派机制先定三条规则：按变更范围与风险划分评审级别、每级配几名评审人、各级响应时限与超时处理方式。
- 分派操作按提交评审单、按规则选人、通知确认、意见处理与重新分派、合入前确认五步执行，每步都有输入、输出和完成标志。
- 作者对评审单信息质量负责，评审人对评审结论负责，合入者对合入前完整性负责，模块负责人维护评审人名单并处理超时改派。
- 评审单需要承载改动范围、风险级别、期望完成时间等字段和待指派、评审中、待合入、已合入等状态，分派结果才能回溯到具体负责人。
- 上线一个月后按规则覆盖、必填字段、响应时限、名单更新、结果回溯五项检查，发现问题落到具体调整动作。
分派前先定三条规则：谁评、评几个、多久响应
分派混乱通常源于规则缺失：作者在群里喊人，谁有空谁看，评审深度随人而异。把分派做成机制，第一步是把三个决策项写下来：评审级别怎么分、每级配几名评审人、响应时限多长。规则确定后，指派动作才有依据，评审质量也才有可比性。
评审级别建议按变更范围和风险划分，而不是按作者职级或提交时间。常见做法分三级：常规改动指单模块内、逻辑局部、无接口变化；跨模块改动指涉及两个及以上模块，或修改公共组件、数据结构的调用方；高风险改动指涉及对外接口、数据库结构、权限与安全逻辑、核心交易链路。级别越高，评审人数和专长要求越高。
评审人数要与改动风险匹配。常规改动一名熟悉该模块的评审人即可；跨模块改动需要每个受影响模块各一名评审人，必要时增加一名架构或接口负责人；高风险改动在此基础上增加安全、数据或运维相关专长的评审人。人数不是越多越好，每名评审人都应有明确的评审关注点，否则容易出现“都看一眼、都不负责”的情况。
响应时限要按级别区分，并写明超时处理方式。例如常规改动要求一个工作日内给出首次回应，跨模块改动两个工作日内，高风险改动当日响应。超时处理可以设定为：系统提醒评审人、提醒模块负责人、由模块负责人改派备选评审人。时限的起点应统一为评审单提交且信息完整的时间，避免作者反复补信息导致口径不一。
规则本身也需要负责人。建议由研发负责人或技术委员会制定级别划分与人数要求，模块负责人维护本模块的评审人名单，规则每季度或每半年复核一次。复核时重点看两类信号：高风险改动是否频繁漏加签，以及某级别评审是否长期无人按时响应。规则调整要有记录，避免口头变更造成执行口径分裂。
| 评审级别 | 触发条件 | 评审人数 | 专长要求 | 响应时限 |
|---|---|---|---|---|
| 常规改动 | 单模块内、无接口与数据结构变化 | 1人 | 熟悉该模块代码与业务逻辑 | 1个工作日内首次回应 |
| 跨模块改动 | 涉及两个及以上模块，或修改公共组件、被多方调用的接口 | 每个受影响模块各1人，必要时加1名接口负责人 | 各模块负责人或指定评审人；接口变更需接口负责人确认 | 2个工作日内首次回应 |
| 高风险改动 | 对外接口、数据库结构、权限与安全逻辑、核心交易链路 | 2人及以上，含1名领域负责人 | 模块专长加安全、数据或运维相关专长 | 当日响应，加签人24小时内给出结论 |
分派的具体操作步骤：从提交到指派到完成
规则确定后，分派就变成一串有输入、有输出的动作。下面按提交、指派、通知确认、意见处理、合入确认五个环节展开，每一步都说明做什么、产出什么、以什么为完成标志。
第一步：提交评审单并填全必填信息
输入是作者完成的代码改动。动作是在评审单上填写改动范围（涉及哪些模块和文件）、关联工作项、风险标签、期望完成时间，并附上改动说明和自测结果。输出是一张信息完整的评审单。完成标志是必填字段全部填写、系统校验通过，评审单进入待指派状态。信息不全的评审单不应进入指派环节，否则评审人需要反复询问背景，响应时限也会失真。
第二步：按规则选择评审人
输入是评审单上的改动范围与风险标签。动作是先查模块负责人名单，为每个受影响模块选出对应评审人；再核对专长要求，高风险改动补充安全、数据等加签人；若首选评审人处于休假或已满负荷状态，从备选名单中改派。输出是评审人列表及各自的评审关注点。完成标志是评审人数量与级别要求一致，且每名评审人都对应到具体模块或关注点。
第三步：通知与确认
指派完成后，系统向评审人发送通知，内容包括评审单链接、改动范围、期望完成时间和评审关注点。评审人需要在时限内做出确认动作：接受指派并给出预计评审时间，或说明冲突并建议改派。输出是评审人的接受记录或改派请求。完成标志是所有被指派人都已确认，没有悬空的指派。
第四步：处理评审意见与重新分派
评审人给出意见后，作者逐条回应：采纳的说明修改方式，不采纳的说明理由。出现以下情况时触发重新分派：改动范围扩大、新增接口或数据结构变化导致级别上升；原评审人无法继续评审；评审意见涉及新的专长领域。重新分派时保留原有评审记录，新增评审人只针对新增范围评审，避免全量重来。
第五步：合入前确认
输入是评审意见处理完毕的评审单。动作是合入者核对评审人数是否满足级别要求、所有评审人是否明确给出通过结论、必要检查项（如自动化测试、静态检查）是否通过。输出是合入记录。完成标志是代码合入目标分支，评审单状态更新为已合入，且评审人与合入者信息可追溯。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 提交评审 | 完成的代码改动 | 填写改动范围、关联工作项、风险标签、期望完成时间 | 信息完整的评审单 | 必填字段齐全，进入待指派 |
| 选择评审人 | 改动范围与风险标签 | 按模块负责人匹配，按专长加签，必要时改派 | 评审人列表与关注点 | 人数与级别要求一致 |
| 通知与确认 | 评审人列表 | 发送通知，评审人接受或请求改派 | 接受记录或改派请求 | 所有指派均已确认 |
| 意见处理 | 评审意见 | 逐条回应、修改代码、判断是否重新分派 | 处理记录与更新后的改动 | 所有意见有明确结论 |
| 合入确认 | 处理完毕的评审单 | 核对评审完成情况与检查项，执行合入 | 合入记录 | 代码合入，状态更新为已合入 |
这些动作要稳定执行，评审单本身需要承载字段与状态。在 ONES 中，可以把评审单建成工作项类型，用改动范围、风险级别、关联工作项、期望完成时间作为必填字段，用状态流转表示待指派、评审中、待合入、已合入，指派动作对应到具体负责人，通知与超时提醒由工作项状态变化触发。这样分派结果留在工作项上，后续可以按负责人和状态回溯。
角色与交付物：作者、评审人、合入者各管什么
分派链条上有四类角色，职责边界清楚，交接才不会断档。作者对评审单的信息质量负责，评审人对评审结论负责，合入者对合入前的完整性负责，模块负责人对评审人名单与专长映射负责。
作者的交付物是信息完整的评审单和逐条回应的意见处理记录。提交前应完成自测，说明改动意图与影响范围；评审过程中及时响应意见，修改后重新提交并标注变更点。作者的完成标志是评审意见全部有结论，代码达到可合入状态。
评审人的交付物是可执行的评审意见和明确的通过或退回结论。意见应指向具体代码位置和修改建议，避免“再看看”“感觉不对”这类无法执行的表述。评审人接受指派后应在时限内给出首次回应，无法继续评审时及时提出改派，而不是沉默等待超时。
合入者的交付物是合入记录。合入前核对评审人数是否满足级别要求、是否所有评审人都已通过、必要检查项是否完成。合入者不替代评审人做技术判断，发现评审不完整时应退回补充，而不是自行放行。
模块负责人的交付物是维护中的评审人名单与专长映射。名单要覆盖模块的主要代码区域，标注每名评审人的专长方向与可用状态，人员变动或模块拆分时及时更新。模块负责人也是超时改派的执行人，在首选评审人无法响应时指定备选人。
| 角色 | 核心职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 作者 | 提交信息完整、回应评审意见、修改后重新提交 | 评审单、意见处理记录、更新后的代码 | 提交评审单；意见处理完毕后移交合入者 |
| 评审人 | 按时响应、给出可执行意见、明确通过或退回 | 评审意见、评审结论 | 接受指派；给出结论后交回作者 |
| 合入者 | 核对评审完成情况与检查项后执行合入 | 合入记录 | 合入前核对；合入后更新评审单状态 |
| 模块负责人 | 维护评审人名单与专长映射，处理超时改派 | 评审人名单、专长映射、改派记录 | 指派环节提供名单；超时时执行改派 |
示例：一次跨模块改动的分派全过程
以下为演示情景，用于说明规则如何落到动作，不代表任何真实团队的数据。某团队要修改订单模块的优惠计算逻辑，同时调整支付模块调用订单接口的参数结构，改动涉及两个模块并包含接口变更。
作者提交评审单，填写改动范围为订单模块与支付模块，关联工作项为优惠规则调整需求，风险标签选择“接口变更”，期望完成时间为两个工作日后。系统根据风险标签判定为跨模块改动，要求每个受影响模块各一名评审人，并提示接口变更需要接口负责人确认。
作者按模块负责人名单选出订单模块评审人和支付模块评审人，系统同时按规则加签接口负责人。三名评审人收到通知后确认接受，分别标注关注点：订单模块评审人关注优惠计算边界，支付模块评审人关注参数兼容性，接口负责人关注接口版本与调用方影响。输出是三名评审人的确认记录和关注点清单。
评审过程中，支付模块评审人提出参数结构变更会影响另一个调用方，改动范围实际扩大到第三个模块。作者据此触发重新分派，新增该模块评审人，级别维持跨模块，原有评审记录保留。新增评审人只针对参数兼容性给出意见，避免重复评审已确认部分。
所有意见处理完毕后，合入者核对：三个模块评审人均已通过，接口负责人已确认接口版本，自动化测试通过。合入者执行合入，评审单状态更新为已合入，评审人、合入者与各步时间均记录在评审单上。这个示例中，输入是改动与风险标签，动作是判定级别、选人、加签、改派、核对，输出是评审记录与合入记录，完成标志是状态更新且信息可追溯。
分派机制上线后的完成检查
机制是否运转，不能只看有没有发通知，要看规则覆盖、字段填写、时限达成和结果可追溯。建议上线一个月后做一次检查，之后按季度复核。下面五项可作为逐项核对的清单。
| 检查项 | 核对内容 | 通过标准 |
|---|---|---|
| 规则覆盖 | 抽查近期评审单，核对级别判定是否覆盖常规、跨模块、高风险三类主要变更 | 主要变更类型均有对应级别，未出现无法归类的评审单 |
| 必填字段 | 检查改动范围、关联工作项、风险标签、期望完成时间是否实际填写 | 必填字段填写率达标，空字段评审单未进入指派 |
| 响应时限 | 统计各级别首次回应时间，核对超时单是否执行提醒与改派 | 时限达成情况可统计，超时单均有处理记录 |
| 名单更新 | 核对模块负责人名单与专长映射是否随人员变动更新 | 名单覆盖主要模块，无长期失联评审人 |
| 结果回溯 | 随机抽取已合入改动，确认能查到评审人、合入者与各步时间 | 每笔合入均可回溯到具体负责人和评审记录 |
检查中发现的问题要落到具体动作：字段填写率低，就收紧提交校验；超时集中出现在某级别，就复核该级别的人数与时限是否合理；名单长期未更新，就把更新责任明确到模块负责人并设定复核周期。分派机制的完成标志不是制度文档发布，而是每次改动都能按规则找到评审人、按时得到结论、合入后可以回溯。
常见问题
团队规模较小、模块划分不清晰时，评审级别规则怎么简化？
模块边界不清晰时，可以先按改动影响面划分两级：只影响单个功能区域的改动，由一名熟悉该区域的评审人评审；涉及公共代码、对外接口或数据结构的改动，至少两名评审人，其中一名由技术负责人担任。级别名称可以简化，但触发条件要写清楚，避免作者自行判断“这次算不算高风险”。等模块负责人名单逐步建立后，再把两级细化为三级。
评审人长期不响应，除了改派还有哪些处理方式？
改派解决单次阻塞，长期不响应需要从名单和负荷两端处理。先看该评审人是否承担了过多模块，把部分模块的评审职责分给备选人；再看响应时限是否与该级别改动量匹配，时限过短会导致评审人习惯性拖延。模块负责人应定期核对名单中的可用状态，把休假、转岗人员及时移出首选名单。若某级别超时集中出现，应复核该级别的人数要求和时限设定，而不是只催个人。
评审过程中改动范围扩大，重新分派时原有评审意见还有效吗？
原有评审记录应保留，已确认的部分不需要全量重评。重新分派时明确新增范围和新评审人的关注点，例如新增模块只评审接口兼容性，已评审过的计算逻辑不重复评审。若范围扩大导致评审级别上升，按新级别补足评审人数和专长要求。作者需要在评审单上标注变更点，让新增评审人知道哪些内容是本次新增、哪些已经确认。
合入者发现评审人数不够但作者急于上线，应该怎么处理？
合入者按规则退回补充评审，不自行放行。可以采取的加速方式包括：由模块负责人从备选名单中指定评审人、对已评审部分沿用结论只补缺失的专长评审、与作者确认是否可以拆分改动先合入低风险部分。规则本身应预留紧急通道，例如高风险改动在特定条件下由技术负责人代评审并记录原因，但紧急通道的使用要有记录并定期复核，避免成为常态。
评审单的必填字段总是填不全，怎么让规则真正执行？
先收紧提交校验，必填字段不齐的评审单不进入待指派状态，从流程上阻断“先提交再补”。再检查字段设计是否过重：字段过多、含义不清会让作者敷衍填写，可以合并同类字段、给出填写示例。最后把字段质量纳入检查，抽查评审单中改动范围与风险标签是否与实际改动一致，发现系统性漏填时调整字段或校验规则，而不是反复口头强调。
