代码评审清单按“提交前准备—评审中检查—合入前确认”三段组织，每项写明检查内容、通过标准、证据和负责人。它把改动范围、测试结果、评审意见关闭情况、合入条件等可判断的事实写成勾选项，主观建议留在评论里。下面给出可直接套用的表格和判定规则。
要点总览（TL;DR）
- 清单按提交前准备、评审中检查、合入前确认三段组织，提交者、评审人、合入执行人各对应一段，在各自时点使用。
- 每项检查写明检查内容、通过标准、证据和负责人；通过标准要可观察、可判断，避免“合理”“适当”等模糊表述。
- 合入前确认只有“满足”和“阻断”两种结果；未关闭的高风险意见、必跑测试失败或未执行、缺失回滚说明、冲突解决后未重新验证，都必须阻断合入。
- 评审意见按阻断性、建议性、疑问分类记录，作者逐条回复处理结果；无法判定的项标记待确认并指定确认人和期限，不能默认通过。
- 评审意见与合入条件建议关联到需求或缺陷单上留存，形成可追溯的记录，便于后续评审参照历史结论。
谁在什么时点使用这份清单
这份清单服务三个角色：提交者、评审人、合入执行人。三者不是同时打开同一份清单，而是在各自负责的时点使用对应段落。提交者在发起评审前完成提交前准备段；评审人在评审进行中逐项判断评审中检查段；合入执行人在点击合入前核对合入前确认段。角色与段落一一对应，避免出现“大家都看、没人负责”的情况。
| 角色 | 触发时点 | 负责段落 | 完成标志 |
|---|---|---|---|
| 提交者 | 发起评审前 | 提交前准备检查项 | 准备段全部勾选，评审请求已发出 |
| 评审人 | 评审进行中 | 评审过程检查项 | 给出通过/需修改结论，意见已记录 |
| 合入执行人 | 点击合入前 | 合入前确认项与阻断条件 | 确认段无阻断项，合入完成 |
清单覆盖范围限定在评审与合入管理：改动是否对应需求、评审意见是否关闭、测试是否通过、合入条件是否满足。代码优化技巧、算法设计、评审等待时长等流动效率指标不在本清单内，遇到这类问题应转到对应的技术评审或效率分析场景。
提交前准备检查项
提交前准备段的目标是让评审人拿到一个“可以开始判断”的变更，而不是替提交者补信息。提交者逐项确认以下内容，任一项不满足就不应发起评审。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 改动范围与需求/缺陷单对应 | 变更描述中写明关联单号，改动文件与单号描述的功能或缺陷一致 | 评审请求中的关联链接、改动文件列表 | 提交者 |
| 自测与自动化测试结果可查 | 本地或分支上相关测试已执行，结果可被评审人打开查看 | 测试运行记录、流水线结果链接 | 提交者 |
| 变更说明、影响面与回滚方式写清 | 说明包含改了什么、影响哪些模块或调用方、出问题如何回滚 | 变更说明文档或评审描述 | 提交者 |
| 大改动已拆分或提前沟通 | 单次改动超出团队约定规模时，已拆分为可独立评审的提交，或已与评审人提前对齐 | 拆分后的提交列表、沟通记录 | 提交者 |
“大改动”的判定标准由团队约定，例如改动文件数、涉及模块数或是否触及公共接口。约定一旦确定就写进清单，避免每次评审临时争论。拆分的目的在于让每个提交都能被独立判断，拆分后每个提交仍需单独走完本段检查。
评审过程中的检查项
评审人按以下维度逐项判断，每项给出明确结论：通过、需修改、或标记待确认。结论写在评审记录里，不停留在口头或即时消息中。
| 检查维度 | 检查内容 | 通过标准 | 证据 |
|---|---|---|---|
| 逻辑正确性 | 主流程、异常分支、边界条件（空值、越界、并发、超时）是否处理 | 关键分支有对应处理，边界情况有测试或说明 | 评审评论、测试用例 |
| 命名与结构 | 命名是否表达意图，函数与模块职责是否单一，是否引入重复逻辑 | 无需额外解释即可读懂主要逻辑，无明显重复实现 | 评审评论 |
| 安全与权限 | 输入校验、鉴权、敏感信息处理、日志是否泄露数据 | 涉及权限的改动有校验点，敏感信息未进入日志或明文存储 | 评审评论、安全检查结果 |
| 测试充分性 | 新增或修改逻辑是否有对应测试，测试是否覆盖风险最高的路径 | 改动风险与测试覆盖匹配，高风险路径有测试 | 测试报告、覆盖率记录 |
意见处理遵循三条规则。第一，每条意见标明类型：阻断性（必须改）、建议性（可讨论）、疑问（需作者答复）。第二，作者对每条意见回复“已修改并说明位置”或“不改并说明理由”，不允许无回复关闭。第三，建议性意见由作者与评审人协商是否本次处理，协商结果写入记录，避免同一问题在后续评审反复出现。
合入前的确认项与阻断条件
合入执行人在点击合入前逐项确认，确认结果只有“满足”和“阻断”两种，不存在“大概可以”。
| 确认项 | 满足条件 | 证据 | 负责人 |
|---|---|---|---|
| 评审意见关闭情况 | 全部意见已关闭，或有明确结论（含“本次不处理”的协商结论） | 评审记录中的意见状态 | 评审人/提交者 |
| 流水线与测试 | 必跑构建与测试全部通过 | 流水线结果 | 合入执行人 |
| 冲突解决后重新验证 | 解决冲突后重新跑过受影响测试，结果通过 | 冲突解决后的流水线记录 | 提交者 |
| 回滚说明 | 变更说明中可查到回滚步骤或回滚开关 | 变更说明 | 提交者 |
以下情况必须阻断合入：存在未关闭的高风险意见（安全、数据一致性、权限相关）；必跑测试失败或未执行；缺失回滚说明；冲突解决后未重新验证。阻断不是否决，而是把问题退回给对应负责人处理，处理完成后重新走确认段。合入执行人对阻断项只有放行与退回两种动作，放行需要记录理由和批准人。
每项怎么判定通过：标准与证据
清单能否起作用，取决于每项是否可判断。通过标准的写法遵循三条：描述可观察的事实，给出明确的判定结论，限定判断范围。例如“测试通过”不可判断，“本次改动涉及的单元测试全部通过，结果链接可打开”可判断。
| 要素 | 写法要求 | 示例 |
|---|---|---|
| 通过标准 | 可观察、可判断、有明确结论，避免“合理”“适当”等模糊词 | “新增接口有鉴权校验，未登录请求返回拒绝” |
| 证据 | 评审记录、测试报告、流水线结果、变更说明四类之一，且可被他人打开 | 流水线运行链接、评审评论截图或记录 |
| 负责人 | 写具体角色或人名，不写“相关同学” | 提交者、评审人、合入执行人 |
| 检查时点 | 与角色触发时点一致，写在表头或行内 | 发起评审前、合入前 |
遇到无法判定的情况，处理方式是标记“待确认”并指定确认人和期限，不能默认通过。待确认项在合入前必须转为满足或阻断，否则视为未完成。清单本身也应定期回看：如果某项连续多次被标记待确认，说明标准写得不够具体，需要修订标准而不是放宽判定。
清单落地：评审记录与合入状态的管理承载
清单执行后，评审意见、合入条件和结论需要留在工作项上，才能支撑追溯和复用。建议把评审意见与对应的需求单或缺陷单关联：每条意见记录类型、提出人、处理状态和结论，意见关闭时同步更新工作项状态。合入条件做成可勾选的状态项，勾选时附上证据链接，形成“条件—证据—结论”的完整记录。
在 ONES 中，这类记录可以依托工作项承载：需求或缺陷单上关联评审意见与处理状态，合入条件作为工作项上的检查项逐条勾选，评审结论与变更说明随工作项留存，后续追溯时从单号即可回看当时的评审过程与合入依据。具体字段与配置方式以团队实际使用的版本为准。这样做的价值在于，清单不再是一次性的检查动作，而是变成工作项生命周期中的可查记录，下一次评审可以直接参照历史结论，减少重复沟通。
常见问题
小团队改动量不大，也需要按三段清单逐项检查吗？
三段结构可以保留，但检查项可以按团队实际裁剪。提交前准备段至少保留改动与需求/缺陷单对应、测试结果可查两项；评审中检查段可以合并维度，但逻辑正确性和测试充分性建议保留；合入前确认段的阻断条件不建议删减，尤其是必跑测试和回滚说明。裁剪的原则是：删掉的是形式化记录，保留的是能支撑判断的事实。
评审意见已经口头沟通过，还需要逐条记录吗？
需要。口头沟通的结论如果没有落到评审记录里，合入执行人无法判断意见是否关闭，后续追溯也找不到依据。建议的做法是：沟通后由提出人在评审记录中补一条结论，写明意见类型和处理结果；作者回复“已修改并说明位置”或“不改并说明理由”。这样合入前的意见关闭情况才有可核对的记录。
合入后发现清单某项漏检，应该怎么处理？
先按变更说明中的回滚方式处理问题，再回看漏检原因。如果是个别执行遗漏，在评审记录中补充说明并提醒对应角色；如果是清单标准写得不够具体导致无法判断，就修订该项的通过标准和证据要求。连续多次出现同类漏检时，说明该检查项需要重新设计，而不是简单增加提醒。
紧急修复场景可以跳过合入前确认段吗？
不建议整体跳过。紧急修复可以简化评审中检查的维度，但合入前确认段中的必跑测试、回滚说明和意见关闭情况仍应保留。如果确实需要先合入后补验证，应由合入执行人记录放行理由和批准人，并在约定时间内补齐测试与评审记录。这样紧急处理有据可查，也不会让阻断条件形同虚设。
评审意见和合入状态记录在哪些工作项上比较合适？
通常关联到对应的需求单或缺陷单上，因为评审的出发点是这次改动要解决的需求或缺陷。评审意见记录类型、提出人、处理状态和结论；合入条件做成可勾选的状态项，勾选时附证据链接。在 ONES 中，这类记录可以依托工作项承载，需求或缺陷单上关联评审意见与处理状态，合入条件作为检查项逐条勾选，具体字段与配置方式以团队实际使用的版本为准。
