代码评审从提交到合入，通常要经过待审队列、反馈处理、合入审批三个环节。三者是一条流水线上的三段：队列负责排队与分派，反馈处理负责收敛问题，审批负责放行与留痕。衔接依靠状态流转和准入条件，每一步都有明确责任人与退出条件。本文按机制解析三个环节的组成、角色分工与常见误解，帮助梳理团队自己的评审流程。
要点总览（TL;DR）
- 待审队列负责排队与分派，反馈处理负责收敛评审意见，合入审批负责放行与留痕，三者是同一条评审流水线上的三段。
- 衔接靠状态流转与准入条件：变更入队分派、意见全部关闭且检查通过后进入审批、审批通过才执行合入，回退路径同样要明确。
- 提交者、评审人、审批人、合并执行者四类角色各有交接物；团队可兼任，但提交与审批建议分离，保留基本复核关系。
- 待审队列是团队视角的等待集合，个人待办只是被分派后的任务清单；评审通过是技术判断，合入放行是流程决策，两者可以分开设置。
- 意见未关闭就审批、审批后跳过检查直接合入、队列堆积无人分派，是三个常见误解，各自有对应的硬性条件和处理办法。
直接答案：三个环节各管一段，靠状态和准入条件串起来
待审队列解决“谁来评、先评哪个”的问题。变更提交后进入队列，按优先级、影响范围和评审人可用性排序并分派，使评审任务有明确归属，避免靠口头催促推动。
反馈处理解决“问题是否改到位”的问题。评审人提出意见后，提交者逐条修改或说明理由，评审人确认后关闭意见。这个环节的退出条件是意见全部关闭、必要检查通过，变更才具备进入审批的资格。
合入审批解决“能否放行、谁批准、留下什么记录”的问题。有权限的审批人核对意见关闭情况和检查结果，批准后由合并执行者完成合入，审批记录随变更留存。
一条变更的典型流转顺序是：提交进入待审队列 → 分派给评审人 → 评审意见进入反馈处理 → 意见关闭、检查通过 → 进入合入审批 → 批准后合入。反馈阶段若改动较大，变更可退回队列重新评审；审批被驳回，则退回反馈处理继续修改。衔接的关键在于每个状态都有明确的进入条件和退出条件，状态变化由系统记录，减少人工口头推动。
定义与边界：哪些属于评审合入流程，哪些不在此列
待审队列是等待评审的变更集合及其排序、分派规则。它回答三个问题：哪些变更在等评审、按什么顺序处理、由谁评审。队列是团队层面的视图，与个人待办列表不同。
反馈处理是评审意见从提出到关闭的全过程，包括意见分类（缺陷、建议、疑问）、提交者修改代码或补充说明、评审人复核并关闭意见。它关注问题是否收敛，不关注代码本身怎么写更好。
合入审批是变更合入前的最后一道关卡，由有权限的人依据检查项和意见状态决定是否放行，并留下审批记录。它属于放行决策，与评审的技术判断是两件事。
评审角色与分工贯穿三个环节：提交者发起变更并响应意见，评审人给出技术判断，审批人做放行决策，合并执行者完成合入动作。角色可以由同一人兼任，也可以分开设置，取决于团队规模与风险要求。
本文不展开的内容包括：代码优化与算法教程、具体编程规范细则、评审等待时长与队列积压等研发流动效率指标的分析口径。这些属于相邻主题，本文仅在误解纠正处点到为止。
机制解析：一条变更如何从待审队列走到合入
待审队列：排序、分派与评审人选择
变更进入队列时，通常携带变更范围、影响模块、紧急程度等信息。排序规则可按紧急程度、变更大小或业务优先级设定，团队应明确一种主规则，避免多条规则互相冲突。分派方式有按模块负责人自动指派、按轮值规则分配、由提交者指定加队列管理员调整几种。评审人选择要考虑代码熟悉度和当前负载，关键模块可要求多人评审。
反馈处理：意见分类、修改、回复与关闭
评审意见进入反馈处理后，先分类：必须修改的缺陷、可选采纳的建议、需要澄清的疑问。提交者对缺陷类意见逐条修改，对建议类意见说明采纳或不采纳的理由，对疑问类意见补充上下文。每条意见都应有明确结论——已修改、已说明、已关闭，避免意见悬空。意见全部关闭是进入审批的前置条件。
合入审批：检查项、批准权限与合入动作
审批前需核对检查项：意见是否全部关闭、自动化检查（构建、测试、静态扫描）是否通过、变更是否关联需求或工单。审批权限按变更影响范围设置，高风险变更要求更高层级审批。批准后由合并执行者完成合入，审批人、批准时间、检查结果随变更记录留存。
触发事件与回退路径
环节之间的推进由事件触发：变更提交触发入队，评审人完成首轮意见触发反馈处理，意见全部关闭触发审批待办，审批通过触发合入。回退同样有路径：反馈阶段改动超出原评审范围，变更退回队列重新分派评审人；审批被驳回，变更退回反馈处理，驳回理由作为新的待处理意见。回退路径明确，流程才不会在某个环节卡住后无人处理。
角色与分工：谁在队列、反馈、审批中各担什么
四个角色在三个环节中的职责与交接物如下表所示。团队规模较小时可以兼任，但审批与提交建议分离，以保留基本的复核关系。
| 角色 | 主要环节 | 核心职责 | 交接物 |
|---|---|---|---|
| 提交者 | 队列、反馈处理 | 发起变更、响应评审意见、完成修改 | 变更内容、修改说明、意见回复 |
| 评审人 | 队列、反馈处理 | 认领或接受分派、提出意见、复核并关闭意见 | 评审意见、意见关闭结论 |
| 审批人 | 合入审批 | 核对检查项、做出放行或驳回决定 | 审批记录、驳回理由 |
| 合并执行者 | 合入 | 按批准结果执行合入、确认合入结果 | 合入记录 |
职责分离的基本要求是：提交者不单独批准自己的变更；审批人核对的是意见关闭与检查结果，技术判断由评审人负责；合并执行者只执行已批准的合入，不自行改变审批结论。权限设置上，审批权限按变更风险分级，队列管理员负责处理长期无人认领的变更，避免队列堆积。
在评审意见与合入状态需要跨角色同步的场景中，ONES 的工作项与评审记录可以承载意见条目、处理状态和审批结论，使提交者、评审人、审批人看到同一份状态，减少在聊天工具里反复确认。具体配置方式以团队实际使用的产品能力为准。
相邻概念区别：待审队列、待办列表与合入审批的差别
待审队列与个人待办列表的区别在视角和规则。待审队列是团队层面的等待集合，带有排序和分派规则，解决“整体上先处理哪个、派给谁”；个人待办列表是某个人的任务清单，只反映个人视角。队列中的变更被分派后才进入个人待办，队列本身不因某人清空待办而消失。
反馈处理与合入审批的区别在判断对象。反馈处理判断“意见是否改到位”，产出是意见关闭结论；合入审批判断“能否放行”，产出是批准或驳回决定。意见关闭不等于审批通过，审批人仍需核对检查项。
评审通过与合入放行的区别在决策层级。评审通过表示评审人认可技术方案，是技术判断；合入放行表示有权限的人允许变更进入主干，是流程决策。两者可以合并为一次操作，也可以分开设置，高风险项目通常分开，以保留独立的放行环节。
具体例子与常见误解
以一个支付模块的变更为例（演示情景）：提交者提交变更并关联需求单，变更进入待审队列；队列按模块负责人规则分派给两名评审人。首轮评审提出两条缺陷意见和一条建议，进入反馈处理；提交者修改缺陷、对建议说明暂不采纳的理由，评审人复核后关闭全部意见。自动化检查通过后，变更进入合入审批；审批人核对意见关闭记录和检查结果，批准合入，合并执行者完成合入，审批记录随变更留存。若审批人认为改动范围超出预期，可驳回并写明理由，变更退回反馈处理。
常见误解一：意见未关闭就提交审批。后果是审批人面对未收敛的变更，只能驳回或带风险放行，前者浪费一轮流转，后者把问题带入主干。正确做法是把意见全部关闭作为进入审批的硬性条件。
常见误解二：审批通过后跳过检查直接合入。审批核对的是提交时的检查结果，若合入前代码又有变动，检查结果已失效。正确做法是合入前确认检查结果对应最新版本，变动后重新触发检查。
常见误解三：队列堆积无人分派。变更长期停留在待审状态，提交者只能私下催促，流程失去可预期性。正确做法是设置队列管理员或轮值规则，对超过约定时间未认领的变更主动分派，并把分派动作记录在队列中。
常见问题
小团队人手少，三个环节的角色可以合并吗？
可以合并，但建议保留一条基本约束：提交者不单独批准自己的变更。常见做法是提交者同时承担反馈处理中的修改工作，评审人兼任审批人，合并执行者由其中一人完成。团队规模扩大或变更影响范围提高时，再把审批环节独立出来，按变更风险分级设置审批权限。
合并角色时要写清楚谁在什么条件下有权放行，避免出现“谁都能批、谁都不负责”的状态。
评审意见一直不关闭，变更卡在反馈处理怎么办？
先区分意见类型。缺陷类意见需要提交者修改，建议类意见需要说明采纳或不采纳的理由，疑问类意见需要补充上下文。每条意见都应有明确结论，避免长期悬空。
流程上可以约定意见的响应时限，超时未回复的意见由评审人复核后给出结论，或升级给队列管理员协调。若改动范围已经超出原评审范围，把变更退回待审队列重新分派评审人，比在反馈处理里反复拉扯更清晰。
审批通过后代码又有改动，需要重新走流程吗？
需要重新确认检查结果。审批核对的是提交时的意见关闭情况和自动化检查结果，合入前代码再有变动，原有检查结果已不对应最新版本。
常见做法是变动后重新触发构建、测试和静态扫描，检查通过后再合入；如果变动涉及评审意见覆盖的范围，还应回到反馈处理补充评审。把“检查结果对应最新版本”作为合入前的确认项，可以避免带风险合入。
待审队列和每个人的待办列表是什么关系？
待审队列是团队层面的等待集合，带有排序和分派规则，回答“整体上先处理哪个、派给谁”；个人待办列表是某个人的任务清单，只反映个人视角。
变更被分派后才进入对应评审人的待办，队列本身不因某人清空待办而消失。队列管理员或轮值规则负责处理长期无人认领的变更，把分派动作记录在队列中，流程才有可预期性。
评审通过和合入放行一定要分成两步吗？
不一定，取决于变更风险和团队要求。评审通过表示评审人认可技术方案，属于技术判断；合入放行表示有权限的人允许变更进入主干，属于流程决策。
低风险、小范围的变更可以把两者合并为一次操作，由评审人批准后直接合入。高风险变更、核心模块或涉及线上稳定性的改动，通常分开设置，保留独立的放行环节和审批记录，便于事后追溯。
