代码评审与合入管理要解决的是让每一次改动可控地进入主干：提交时说明改了什么、自检到什么程度，评审时按风险匹配评审人和检查项，合入时用门禁条件拦住不满足要求的改动，合入后留下决策记录供回溯。本文给出四段流程表、分级评审检查清单、合入门禁条件和角色交付物对照表，并说明这些记录与状态如何在ONES中承载。
要点总览（TL;DR）
- 评审与合入管理固定为“提交—评审—合入—回溯”四段，每段有输入、动作、输出和完成标志，状态不满足就停在当前段。
- 评审规则按改动类型和影响面分低、中、高三级，通用检查项控制在十条以内，专项检查项按接口、数据、权限、性能等类型附加。
- 合入门禁至少包含评审通过、自动化检查通过、冲突已解决三项条件，主干分支开启保护，紧急合入走例外通道并留痕。
- 提交人、评审人、合入负责人、模块负责人各有交付物，交接以评审请求和工作项状态为准，分歧按升级路径裁决。
- 机制是否跑起来看规则文档、检查清单、门禁配置是否齐备，抽样合入记录和例外留痕是否完整，并定期复审规则。
核心答案：评审与合入管理要固定哪四段流程
评审与合入管理可以固定为“提交—评审—合入—回溯”四段。每段都有明确输入、动作、输出和完成标志，团队按同一套骨架执行，再根据改动风险调整评审深度和参与人数。流程长度按风险分级，低风险改动走轻量通道，高风险改动增加评审人和专项检查，避免所有改动套用同一套重流程。
| 阶段 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 提交 | 代码改动、关联需求或缺陷、自检结果 | 提交人写明改动目的、影响范围、自测方式与结果，标注风险级别 | 一条信息完整的评审请求 | 改动说明与自检记录齐全，评审人已指派 |
| 评审 | 评审请求、分级检查清单 | 评审人按改动范围执行通用与专项检查项，提出意见并给出结论 | 评审意见、评审结论 | 所有必查项有结论，意见已处置或明确待办 |
| 合入 | 评审通过的改动、门禁检查结果 | 合入负责人核验门禁条件，选择合入方式完成合入 | 已合入的提交记录、门禁核验记录 | 门禁条件全部满足，合入记录可查 |
| 回溯 | 合入记录、评审意见、关联工作项 | 记录决策依据与例外情况，定期抽查与复盘 | 可追溯的评审与合入档案 | 改动可追溯到评审人、结论与合入时间 |
四段之间靠状态衔接：提交完成才进入评审，评审结论为通过才进入合入核验，合入完成后记录归档。任何一段缺少完成标志，改动就停在当前状态，不向下推进。风险分级体现在评审段和合入段：低风险改动可减少评审人数、缩短检查项；高风险改动增加模块负责人参与、补充专项检查，合入前多一道核验。
评审规则与检查清单怎么定
评审规则的作用是把“看一遍代码”变成可核对的判断。规则要回答三个问题：这次改动由谁评审、要检查哪些项、评审意见怎么处置。建议先按改动类型和影响面划分评审级别，再为每个级别配置检查清单。
按改动类型和影响面划分评审级别
| 级别 | 典型改动 | 评审要求 |
|---|---|---|
| 低风险 | 文案、注释、日志格式、局部配置调整 | 一名同模块评审人，执行通用检查项 |
| 中风险 | 业务逻辑调整、接口字段增减、局部重构 | 一名同模块评审人加一名关联方评审人，执行通用与专项检查项 |
| 高风险 | 核心链路、数据模型、权限与安全相关改动 | 模块负责人参与，必要时增加安全或数据负责人，执行完整检查清单并留存评审记录 |
级别由提交人初判，评审人或模块负责人可以上调。判断依据写进规则文档，例如“涉及数据库结构变更即按高风险处理”，减少每次靠感觉定级。
通用检查项与专项检查项
通用检查项适用于所有改动，数量控制在十条以内，便于每次逐项确认：改动是否与描述一致、是否有对应测试或自测记录、错误处理是否覆盖、日志是否包含必要信息、是否引入敏感信息、命名与风格是否符合团队约定、是否影响既有接口契约、回滚方式是否明确。
专项检查项按改动类型附加：接口改动检查兼容性与调用方影响；数据变更检查迁移脚本与回滚脚本；权限改动检查越权路径；性能敏感改动检查关键路径的复杂度与资源占用。专项检查项由模块负责人在规则文档中维护，新增类型时补充对应条目。
评审意见的处置方式
评审意见统一归为三类处置：需要修改的，提交人修改后在原意见下回复处理结果并请求复审；需要说明的，提交人补充背景或设计取舍，评审人确认后关闭；不予采纳的，由评审人说明理由并驳回该意见，涉及分歧时升级到模块负责人裁决。每条意见都要有明确状态，避免评审结束时仍有未关闭的意见。
评审时限与超时处理
规则中约定评审响应时限，例如工作日一个工作日内给出首次反馈。超时未评审时，提交人可提醒评审人，仍无响应则改派同模块其他评审人或升级到模块负责人。时限按评审级别区分，高风险改动可约定更长的评审窗口，但要有明确的到期时间，避免改动长期停在待评审状态。
合入门禁与分支保护怎么设置
评审通过只说明改动被认可，合入还需要门禁条件把关。合入门禁的作用是让“评审通过但检查未过”或“检查通过但冲突未解决”的改动无法进入主干。
合入前必须满足的条件
- 评审结论为通过，且所有评审意见已关闭或标记为不阻塞。
- 自动化检查通过，包括构建、单元测试、静态检查等团队已配置的检查项。
- 与目标分支的冲突已解决，合并后的代码在本地或流水线中验证通过。
- 改动关联的需求或缺陷工作项状态正确，便于合入后追溯。
分支保护与合入权限分配
主干分支开启保护：禁止直接推送，必须通过评审请求合入；要求最少评审人数；要求指定检查通过后才能合入。合入权限与评审权限分开配置，合入负责人负责执行合入动作，评审人负责给出结论，同一个人可以兼任但要按角色分别记录。模块负责人拥有分支保护规则的调整权限，规则变更需留记录。
紧急合入的例外通道
线上故障修复等场景需要快速合入时，设置例外通道：允许在评审人数不足或部分检查未完成的情况下合入，但必须由模块负责人或值班负责人批准，并在合入记录中写明原因、影响范围和后续补做事项。例外合入后要在约定时间内补齐评审与检查，补做情况纳入回溯抽查。
合入方式选择与提交历史整理
合入方式按团队习惯统一：合并提交保留完整分支历史，适合需要看清改动来源的场景；压缩合入把一次评审请求整理为单个提交，适合提交历史需要简洁的主干；变基合入保持线性历史，要求提交人在合入前自行整理提交。无论选择哪种方式，提交信息要包含改动目的和关联工作项编号，便于回溯时定位。
在ONES中，评审请求可以关联到对应的需求或缺陷工作项，评审结论与合入状态随工作项流转记录，门禁检查结果和例外批准信息一并留存在工作项下，回溯时从工作项即可看到改动从提交到合入的完整过程。
角色分工与各角色交付物
四段流程落到人身上，需要明确谁在什么阶段做什么、交给下一个人什么。角色可以兼任，但职责边界要清楚，交接物要可核对。
| 角色 | 主要动作 | 交付物 | 交接对象 |
|---|---|---|---|
| 提交人 | 编写改动说明、完成自检、初判风险级别、响应评审意见 | 评审请求（含改动描述、自检结果、风险级别） | 评审人 |
| 评审人 | 按级别执行检查项、提出意见、给出评审结论 | 评审意见与结论 | 提交人、合入负责人 |
| 合入负责人 | 核验门禁条件、选择合入方式、完成合入、记录例外 | 合入记录与门禁核验结果 | 模块负责人、回溯抽查 |
| 模块负责人 | 界定评审范围、指派评审人、裁决分歧、审批例外合入、维护检查清单 | 范围界定与裁决记录、例外批准记录 | 评审人、合入负责人 |
评审人按改动范围指派：改动集中在某个模块时，由该模块的评审人主评；改动跨模块时，每个受影响模块至少一名评审人，由提交人在评审请求中列出关联模块，模块负责人确认指派是否完整。交接方式以评审请求和工作项状态为准，口头确认不作为交接完成的依据。
职责冲突时按升级路径处理：提交人与评审人对意见有分歧，先在工作项中说明各自依据；仍无法达成一致，升级到模块负责人裁决；涉及跨模块影响或发布节奏的，由模块负责人提交到技术负责人或发布负责人协调。升级过程和结论记录在工作项中，作为后续回溯依据。
示例：一次中等风险改动的完整评审与合入过程
以下为演示情景，用于说明各段输入输出如何衔接。某团队需要调整订单查询接口，增加按时间范围筛选的参数，属于接口字段增减，按规则定为中风险。
提交：改动描述与自检信息
提交人在评审请求中写明：改动目的为支持订单查询按时间范围筛选；影响范围为订单查询接口及两个调用方；自检结果为本地单元测试通过、调用方联调通过、接口文档已更新；风险级别为中风险，关联需求工作项编号。评审人指派为订单模块评审人和调用方所在模块评审人各一名。
评审：检查项执行与意见提出
订单模块评审人执行通用检查项，确认改动与描述一致、测试覆盖新增参数、错误处理覆盖非法时间范围；执行接口专项检查项，确认新参数为可选、默认行为与旧版本一致、调用方影响已在描述中列出。调用方模块评审人确认两个调用方的适配改动已包含在同一次评审请求中。评审人提出一条意见：时间范围上限缺少校验，需补充。评审结论为“修改后复审”。
意见修改与复审
提交人补充上限校验与对应测试，在原意见下回复处理结果并请求复审。评审人确认修改后关闭意见，评审结论改为通过。整个过程在工作项中留有意见记录与状态变化。
合入条件核验与记录留存
合入负责人核验：评审结论为通过、意见全部关闭；构建与单元测试通过；与目标分支无冲突；关联需求工作项状态为待合入。条件满足后选择压缩合入方式，提交信息包含需求编号与改动摘要。合入记录、评审意见、门禁检查结果保存在工作项下，回溯时可从需求工作项直接查到本次改动的评审人与合入时间。
完成检查：流程是否真正跑起来的核对项
流程建立后，用一组可逐项核对的检查判断机制是否在运行，而不是只看文档是否存在。
- 规则文档齐备：评审级别划分、检查清单、意见处置方式、评审时限均有书面说明，且团队成员可获取。
- 检查清单可用：通用检查项与专项检查项按改动类型可查，最近一个月内有按清单执行的记录。
- 门禁配置生效：主干分支保护已开启，直接推送被阻止，合入需满足评审与检查条件。
- 抽样检查合入记录：抽取近期若干次合入，确认每次都有评审结论、门禁核验记录和关联工作项，抽查中发现缺失的改动要补记录并分析原因。
- 例外合入留痕：紧急合入均有批准人、原因和补做事项记录，补做事项在约定时间内完成。
- 角色交接可核对：评审人指派与改动范围匹配，合入负责人与评审人按角色分别记录，升级裁决有记录。
- 规则定期复审：按季度或半年复审检查清单与门禁条件，根据漏检问题和改动类型变化调整条目，复审结论留档。
核对结果按项记录，未通过项指定负责人和完成时间。规则复审时优先处理抽查中反复出现的问题，例如某类改动多次在合入后才发现遗漏检查项，就把对应条目补进专项清单或调整该类型的评审级别。
常见问题
小团队人少，评审人和合入负责人由同一人兼任，流程还能成立吗？
可以兼任，但记录要按角色分开。同一个人先以评审人身份给出评审结论，再以合入负责人身份核验门禁条件并执行合入，两个动作在评审请求或工作项中分别留痕。这样回溯时能看清结论由谁给出、合入由谁执行，避免出现“自己评自己合、没有任何记录”的情况。团队规模扩大后再逐步拆分角色。
紧急合入走了例外通道，后续补做评审和检查怎么跟踪？
例外合入时就要在记录中写明批准人、原因、影响范围和需要补做的评审与检查项，并指定补做完成时间。补做完成后在原记录下更新结果，回溯抽查时把例外合入作为重点样本，核对补做是否按期完成。如果同一类改动反复走例外通道，说明评审级别划分或检查项设置需要调整，应在规则复审时处理。
评审意见一直不关闭，改动长期停在待评审状态怎么办？
先区分原因：评审人未响应，按约定时限提醒，超时改派同模块其他评审人或升级到模块负责人；意见本身有分歧，提交人在工作项中说明依据，仍无法一致则升级裁决；意见已处理但未关闭，由提交人回复处理结果并请求复审，评审人确认后关闭。规则中约定评审响应时限，高风险改动可设更长窗口，但要有明确到期时间。
合入方式选合并提交、压缩合入还是变基合入，需要统一吗？
建议团队统一一种默认方式，减少主干历史风格混杂。合并提交保留分支来源，适合需要看清改动脉络的场景；压缩合入把一次评审请求整理为单个提交，主干历史更简洁；变基合入保持线性历史，要求提交人在合入前自行整理提交。无论哪种方式，提交信息都要包含改动目的和关联工作项编号，回溯时才能定位。
流程运行一段时间后，怎么判断检查清单需要调整？
看两类信号：一是回溯抽查中反复出现同类遗漏，例如某类改动多次在合入后才发现漏检，就把对应条目补进专项清单或上调该类型的评审级别；二是改动类型发生变化，新增的接口、数据或权限场景没有对应检查项。建议按季度或半年复审一次，复审结论留档，调整后的清单同步给团队成员。
