代码评审要判断一次变更该不该合入，依据可以归为四层：需求与任务依据确定目标，变更依据界定范围，技术规范依据提供标准，质量与流程依据给出客观证据。本文按从提交到合入的顺序，说明每层材料由谁准备、如何与具体变更关联，以及依据齐全与否的判断方法。
要点总览（TL;DR）
- 代码评审依据分四层：需求与任务依据定目标，变更依据定范围，技术规范依据定标准，质量与流程依据提供客观证据。
- 按提交前准备、发起评审关联、评审人逐项核对、合入前确认四个阶段推进，每步都有输入、动作、输出和完成标志。
- 作者交付变更说明与自测证据，评审人交付可追溯的评审意见，合入负责人确认合入条件并留存判断记录，需求方或测试方提供验收标准与验证结果。
- 依据齐全与否分发起评审前、评审中、合入前三个时点检查，设定通过标准与阻断条件，并随变更归档证据。
代码评审依据的四层结构
评审中最常见的问题是评审人只看到一段代码差异，却不清楚这次改动要解决什么、影响哪些模块、按什么标准判断合格。四层依据的作用，是把这些问题在评审开始前就变成可查的材料。四层之间是递进关系：需求定目标，变更定范围，规范定标准，质量定证据。缺少任何一层，评审就容易退化为对代码风格的零散讨论。
| 层级 | 包含材料 | 在评审中的用途 |
|---|---|---|
| 需求与任务依据 | 需求条目、验收标准、任务单或缺陷单、优先级与排期信息 | 确认这次变更该不该做、做到什么程度算完成 |
| 变更依据 | 提交说明、变更文件与代码范围、影响面说明、关联的配置或数据变更 | 界定评审范围，判断改动是否超出任务边界 |
| 技术规范依据 | 编码规范、接口与数据约定、架构约束、安全与合规要求 | 提供判断实现是否合格的标准，减少个人偏好之争 |
| 质量与流程依据 | 单元测试与集成测试结果、构建结果、静态检查报告、评审规则与合入条件 | 用自动化结果作为客观证据，支撑合入判断 |
四层依据并非每层都要写成正式文档。小范围修复可以只关联缺陷单和自测记录，涉及接口或数据结构的变更则需要补充接口约定与影响面说明。判断标准是：评审人能否仅凭这些材料回答“为什么改、改了什么、按什么标准判断、有什么证据”。
需要区分的是，自动化检查通过只说明代码满足机器可验证的规则，需求符合性与设计合理性仍需人工判断。质量依据是评审的输入之一，不能替代评审结论本身。
从提交到合入：评审依据的准备与使用步骤
把四层依据落到操作上，可以按提交前、发起评审、评审中、合入前四个阶段推进。每个阶段都有明确的输入、动作、输出和完成标志，避免依据在流转中丢失。
第一步：提交前由作者准备依据
输入是任务单或需求条目、本地开发完成的代码。动作包括：核对实现是否覆盖验收标准；编写提交说明，写清改动目的、主要改动点和未覆盖的内容；整理变更范围，列出涉及的模块、接口、配置与数据脚本；完成自测并保留测试结果；对影响面较大的改动补充设计说明或影响面分析。输出是一组可随变更一起提交的材料。完成标志是作者能对着提交说明向他人讲清这次改动的前因后果。
第二步：发起评审时把依据与变更关联
输入是第一步准备好的材料。动作是把评审请求与任务单、提交记录、测试报告建立关联，在评审说明中列出本次评审需要重点关注的部位，例如兼容性处理、权限校验、异常分支。输出是一条可追溯的评审记录，评审人打开即可看到需求背景与变更范围。完成标志是评审请求中不存在“无关联任务”或“说明为空”的情况。
在工具层面，ONES 支持将工作项与代码提交、评审记录关联，使需求条目、任务状态和评审意见集中在同一处查看。对于需要按需求追溯评审过程的团队，这种关联可以减少在多个系统之间来回查找依据的成本。
第三步：评审人逐项核对依据
输入是关联好的评审记录与代码差异。动作是按四层依据依次核对：对照需求条目检查功能覆盖是否完整；对照变更范围检查是否有夹带改动；对照编码规范、接口约定与安全要求检查实现；对照测试与检查报告确认证据有效，并判断测试是否覆盖了本次改动的关键路径。输出是评审意见，分为必须修改、建议修改和确认通过三类。完成标志是每条意见都能指向具体依据，而不是仅凭个人习惯。
第四步：合入前确认依据齐全
输入是修改后的代码、更新后的测试结果和评审意见处理记录。动作是逐条确认必须修改项已关闭、自动化检查重新通过、评审结论为通过、合入条件全部满足。输出是合入判断记录。完成标志是合入负责人能够说明本次合入依据了哪些材料、遗留了哪些已知问题及其处理安排。
评审角色与各自需要交付的依据
依据能否齐全，取决于每个角色是否清楚自己该交什么。职责不清时，最常见的结果是作者只提交代码、评审人凭经验判断、合入环节无人对证据完整性负责。
| 角色 | 主要责任 | 交付物 | 交接点 |
|---|---|---|---|
| 提交作者 | 保证变更与需求对应，材料完整可读 | 提交说明、变更范围与影响面说明、自测结果、必要的设计说明 | 发起评审时移交评审人与合入负责人 |
| 评审人 | 按依据核对实现，给出可执行的评审意见 | 评审意见、评审结论、对关键风险的标注 | 评审结束时把结论与待办移交作者 |
| 合入负责人 | 确认合入条件满足，记录合入判断 | 合入判断记录、遗留问题清单 | 合入完成后归档，供后续追溯 |
| 需求方或测试方 | 提供验收标准与验证结果 | 验收标准、测试用例或验证结论 | 在提交前或评审中提供，供作者与评审人引用 |
职责边界上，作者对材料真实性负责，评审人对判断质量负责，合入负责人对流程完整性负责。三者不能互相替代：评审人不应替作者补写变更说明，合入负责人也不应以“评审已通过”为由跳过合入条件核对。需求方提供的验收标准如果中途变更，应及时同步给作者和评审人，否则评审依据会与实际目标脱节。
示例：一次功能变更的评审依据清单
以下为演示情景，用于说明依据清单的组织方式，不代表任何真实项目。
背景：某系统需要为订单导出功能增加按时间范围筛选的能力，涉及后端接口参数、查询逻辑和前端筛选控件。
| 依据类别 | 本次具体内容 | 提供方 |
|---|---|---|
| 需求与任务 | 需求条目“订单导出支持时间范围筛选”，验收标准为起止时间可选、超出范围有提示、导出结果与筛选条件一致；关联任务单与排期 | 需求方、作者 |
| 变更说明 | 提交说明写明新增两个查询参数、修改查询构造逻辑、前端增加日期控件；变更范围列出三个文件与一个接口文档 | 作者 |
| 影响面 | 接口参数为新增可选字段，旧调用方不受影响；查询逻辑改动涉及分页与排序，需要回归导出总量校验 | 作者 |
| 规范与检查 | 参数命名符合接口约定；时间边界处理符合编码规范中的时区要求；静态检查无新增告警；构建通过 | 作者、自动化检查 |
| 测试证据 | 单元测试覆盖起止时间组合与边界值；集成测试验证导出结果条数与筛选条件一致 | 作者、测试方 |
| 评审结论 | 评审人确认需求覆盖完整，提出分页边界需补充一条测试用例，作者补充后复核通过 | 评审人 |
| 合入判断 | 必须修改项已关闭，检查重新通过，合入条件满足，记录一条遗留建议：后续补充大数据量导出的性能验证 | 合入负责人 |
这份清单的价值在于，评审人不需要从代码差异反推意图，合入负责人也能看到结论背后的证据。示例中评审人提出的补充测试要求，正是依据测试证据与影响面说明做出的判断，而非主观意见。
依据是否齐全的完成检查
依据齐全与否，宜在三个时点分别检查，每个时点设定通过标准与阻断条件，并保留确认记录。
| 检查时点 | 检查项 | 通过标准 | 阻断条件 |
|---|---|---|---|
| 发起评审前 | 任务关联、提交说明、变更范围、自测结果、影响面说明 | 材料与变更一一对应，评审人可直接阅读 | 无关联任务、说明为空、自测未执行 |
| 评审中 | 需求覆盖、规范符合性、测试覆盖关键路径、意见可追溯 | 每条意见指向具体依据，必须修改项明确 | 关键路径无测试证据、存在未说明的越界改动 |
| 合入前 | 必须修改项关闭、检查重新通过、评审结论为通过、合入条件满足 | 全部条件满足并有确认记录 | 存在未关闭的必须修改项、检查失败、评审结论缺失 |
证据留存方式上，评审意见、检查报告与合入判断记录应随变更一起归档，保证事后可以回答“当时依据什么做出这个判断”。负责人确认环节，建议由合入负责人做最终签字式确认，而不是默认流转。对于紧急修复等特殊场景，可以简化材料，但简化本身应被记录，并明确后续补正的责任人与时限。
常见问题
小范围缺陷修复也要准备完整的四层依据吗？
可以按变更风险裁剪。小范围修复通常只需关联缺陷单、写清修复原因与影响范围、保留自测记录，编码规范与安全要求按既有约定执行。裁剪的判断标准是评审人能否仅凭这些材料回答“为什么改、改了什么、按什么标准判断、有什么证据”。涉及接口、数据结构或权限逻辑的改动，即使代码量小，也应补充接口约定与影响面说明。
自动化检查全部通过，评审人还需要逐项核对需求吗？
需要。构建、静态检查和测试报告验证的是机器可判定的规则与已覆盖的路径，需求是否被完整实现、设计是否合理、异常分支是否处理，仍要由评审人对照需求条目和验收标准判断。把检查结果当作评审输入，可以缩小人工核对的范围，但不能替代评审结论。
评审过程中需求或验收标准发生变更，依据怎么处理？
由需求方及时同步变更内容，作者更新任务关联与变更说明，评审人据此重新核对受影响的部分。若变更导致原评审结论不再成立，应重新发起评审或补充评审记录，并在合入判断中注明依据的是哪一版验收标准。缺少这一步，合入记录会与实际目标脱节，事后追溯时难以说明判断依据。
紧急修复可以简化评审依据吗？
可以简化材料，但简化本身要留痕。常见做法是保留缺陷单关联、最小变更说明和回滚方案，先按紧急通道合入，再在约定时限内补齐测试证据与完整评审记录，并明确补正责任人与时限。简化不等于免除合入条件核对，合入负责人仍需记录当时依据了哪些材料、遗留了哪些风险。
评审意见怎样写才算指向依据？
每条意见尽量对应到具体材料：功能覆盖问题指向需求条目或验收标准，实现问题指向编码规范、接口约定或架构约束，证据不足指向测试报告未覆盖的路径。意见分为必须修改、建议修改和确认通过三类，必须修改项要写明关闭条件。这样作者知道改什么、改到什么程度，合入负责人也能据此判断条件是否满足。
