一份可用的 Code Review 检查清单，需要按提交前自检、评审中核对、合入前确认三个时点组织，每项写清通过标准、证据和负责人，并标出必须清零才能合入的阻断项。本文给出可直接套用的检查表，覆盖评审与合入管理；代码优化技巧与算法设计不在清单范围内。
要点总览（TL;DR）
- 清单按提交前自检、评审中核对、合入前确认三个时点组织，提交者、评审者、合入者各管一段，每项写明通过标准、证据与负责人。
- 提交前自检重点在变更描述可对应需求或缺陷单、改动可编译、粒度适合一次评审、敏感信息与调试代码已清理。
- 评审中核对覆盖逻辑与边界条件、命名结构、安全权限改动、测试补充，评审意见须标注为阻断项或建议项。
- 合入完成需同时满足阻断项清零、必跑流水线通过、审批符合规则、记录可追溯；例外放行须记录理由、放行人与补做计划。
- 清单要嵌入评审单与工作项字段，让评审意见、审批与测试结果可回溯，并按触发条件定期复盘修订。
谁在什么时点使用这份清单
清单要有人用、有人负责，才有约束力。同一份清单在不同时点由不同角色执行：提交者负责发起评审前的准备，评审者负责评审过程中的判断，合入者负责放行前的确认。三类角色各自只对属于自己的段落签字，避免出现“大家都看过、没人真正负责”的情况。
使用时点与代码变更的生命周期对应。发起评审前，提交者完成自检并附上证据；评审过程中，评审者逐项核对并给出意见分级；合入前，合入者核对阻断项、流水线结果与审批记录。三个时点之间存在先后依赖：前一阶段的证据缺失，后一阶段不应放行。
| 角色 | 使用时点 | 负责的检查段落 | 产出 |
|---|---|---|---|
| 提交者 | 发起评审前 | 提交前自检表全部条目 | 变更描述、自测说明、清理后的提交 |
| 评审者 | 评审过程中 | 评审中核对表全部条目 | 分级后的评审意见（阻断项/建议项） |
| 合入者 | 合入前 | 合入前确认表与阻断项清单 | 放行结论、合入记录、例外说明（如有） |
需求变更或紧急修复时，清单可以简化，但不能跳过阻断项。常见做法是：需求变更导致改动范围扩大时，提交者重新走一遍提交前自检，评审者重点复核受影响模块；紧急修复允许缩短评审等待、减少建议项讨论，但正确性缺陷、必跑测试、必要审批这三类阻断项仍需清零，并在评审记录中注明“紧急修复”及简化理由，便于事后复盘。
提交前自检：发起评审前的准备项
提交前自检的目标是让评审者拿到一份“可以直接看”的变更，减少因描述不清、范围过大、残留调试代码造成的评审轮次浪费。以下条目由提交者在发起评审前逐项勾选，任一条不满足就不发起评审。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 变更范围与描述完整 | 描述说明改了什么、为什么改、影响哪些模块；能对应到需求单或缺陷单编号 | 评审单描述中的关联工作项链接 | 提交者 |
| 改动可编译 | 本地或流水线构建通过，无新增编译错误与警告 | 构建结果截图或流水线记录 | 提交者 |
| 附带自测说明 | 写明自测场景、执行方式与结果；无法自测的部分说明原因 | 评审单中的自测说明段落 | 提交者 |
| 变更粒度适合一次评审 | 一次评审聚焦一个需求或缺陷；混合了重构与功能改动时已拆分或说明 | 提交记录与变更文件清单 | 提交者 |
| 敏感信息已清理 | 提交中无明文密钥、口令、内网地址、个人配置；调试代码与临时日志已删除 | 提交差异中的自查结果 | 提交者 |
变更粒度这一项最容易被忽略。把格式化、重命名与功能改动混在一个提交里，评审者很难分辨哪些行需要认真看。可行的判断标准是：如果评审者需要问“这部分改动和需求有什么关系”，说明粒度不合适，应拆分后再提交。
评审中核对：评审者要逐项判断的内容
评审者的核对围绕四个方向展开：逻辑是否正确、代码是否可维护、安全与权限是否被单独审视、测试是否随改动更新。每项都要给出明确结论，而不是笼统的“看起来没问题”。
| 检查项 | 通过标准 | 证据 | 评审者 |
|---|---|---|---|
| 逻辑正确性与边界条件 | 主流程、异常分支、空值/越界/并发等边界情况已被处理或在描述中说明取舍 | 评审意见中逐条对应的代码位置 | 评审者 |
| 命名、结构与可读性 | 命名符合团队约定；函数职责单一；无复制粘贴式重复逻辑 | 评审意见中的具体行号与修改建议 | 评审者 |
| 安全与权限改动 | 涉及鉴权、数据访问、输入校验的改动被单独标注并说明影响面 | 评审单中的安全标注与说明 | 评审者 |
| 测试覆盖 | 新增或修改的逻辑有对应测试用例；未补充测试的写明理由并获得认可 | 测试文件变更或理由说明 | 评审者 |
| 意见分级 | 每条意见标注为阻断项或建议项；阻断项写明不修复的后果 | 评审意见的分级标签 | 评审者 |
意见分级是评审环节最需要统一口径的动作。阻断项指不修复就不能合入的问题，例如会导致数据错误、越权访问、必跑测试失败；建议项指可以改进但不影响本次合入正确性的问题，例如命名风格、注释补充。评审者给出阻断项时应说明判断依据，避免把个人偏好升级为阻断项；提交者对分级有异议时，由合入者或团队约定的裁决人裁定，并把结论记录在评审单中。
合入前确认：合并条件与证据留存
合入者是放行的最后一道关口，确认的重点是把评审结论、流水线结果和审批记录对应起来，而不是重新做一遍代码评审。以下条目全部满足才可合入。
| 检查项 | 通过标准 | 证据 | 合入者 |
|---|---|---|---|
| 阻断项全部关闭 | 评审中标注的阻断项均已修复或经裁决撤销，无遗留 | 评审单中阻断项的状态记录 | 合入者 |
| 建议项已记录处理方式 | 每条建议项标注“本次修复”“后续跟进”或“不采纳及理由” | 评审单中的建议项处理记录 | 合入者 |
| 构建与自动化测试通过 | 目标分支上的必跑流水线全部通过，无跳过或忽略的必跑项 | 流水线运行记录与结果链接 | 合入者 |
| 审批符合团队规则 | 审批人数与审批人满足团队规定，例如至少一名模块负责人 | 评审单中的审批记录 | 合入者 |
| 合入方式与目标分支明确 | 明确使用合并、压缩合并或变基中的哪一种；目标分支正确；回滚方案已写明 | 合入操作记录与回滚说明 | 合入者 |
| 记录可追溯 | 评审记录、测试结果与关联需求单或缺陷单可互相跳转 | 工作项与评审单的关联关系 | 合入者 |
回滚方案不必复杂，但要具体：回滚哪个提交、是否需要数据修复脚本、回滚后如何验证。对于涉及数据库结构变更或配置变更的提交，回滚方案缺失应视为阻断项。
阻断项清单与合入完成条件
阻断项是从各时点检查项中抽取出来的“必须清零”集合。它的作用是给合入者一个明确的停止信号：只要存在未关闭的阻断项，合入就不成立，例外放行必须留下记录。
常见的阻断项包括：未关闭的正确性缺陷，例如会导致计算结果错误、数据丢失或越权访问的问题；未通过的必跑测试，包括单元测试、集成测试与团队约定的静态检查；缺失的必要审批，例如涉及核心模块却未获得模块负责人审批；未清理的敏感信息，例如提交中残留明文密钥；缺失回滚方案的破坏性变更。建议项不进入阻断清单，例如命名优化、补充注释、非关键路径的日志完善。
区分阻断项与建议项可以用两个问题判断：不修复是否会导致错误行为、安全风险或无法回滚？不修复是否违反团队已明确的规则？任一答案为“是”，即为阻断项；两个答案都为“否”，归为建议项。这个规则应在团队内统一，避免同一类问题在不同评审中分级不一致。
合入完成的判定条件可以归纳为：阻断项清零、必跑流水线通过、审批满足规则、合入记录与关联工作项可追溯。四项同时满足，合入才算完成。例外放行指在阻断项未清零的情况下仍决定合入，必须记录放行理由、放行人、补做计划与截止时间，并在下一次清单复盘时检查补做情况。例外放行是受控的例外，不是常规通道。
把清单落到评审流程与工具记录中
清单只有嵌入评审流程，才能从文档变成可查的记录。落地时先做条目与字段的对应：提交前自检的每一项对应评审单中的描述字段或检查项勾选；评审中核对的意见分级对应评审意见的标签字段；合入前确认的流水线结果、审批记录对应评审单关联的构建记录与审批流。对应关系确定后，检查结果就不再依赖个人记忆。
留痕的关键是让三类证据可回溯：评审意见及其分级、审批人与审批时间、测试与构建结果。每条阻断项的关闭都应有对应的提交记录或说明，建议项的处理方式应写在评审单中而不是散落在聊天工具里。这样在复盘或追溯问题时，可以从需求单出发找到评审单，再找到具体意见与合入记录。
在协作工具中承载这套流程时，可以把评审单作为工作项的一种类型，关联需求单或缺陷单，把审批与测试结果作为该工作项的附件或字段记录。ONES 支持工作项之间的关联与评审、审批信息的记录，适合把清单条目、评审意见与合入结论放在同一条工作项链路中，便于按需求追溯评审历史。具体字段配置与流程设置需结合团队现有工作项类型设计，使用前确认与当前流程的衔接方式。
清单本身也需要维护。触发复盘的条件可以设为：连续出现同类阻断项遗漏、例外放行次数超过团队约定阈值、评审流程或分支策略发生变更、团队新成员加入后的第一个月。复盘时检查条目是否仍可核验、通过标准是否过时、阻断项范围是否需要调整，并把修订结果同步到评审单模板中，保证清单与流程记录保持一致。
常见问题
紧急修复时清单可以简化到什么程度？
可以缩短评审等待、减少建议项讨论，但阻断项不能跳过。正确性缺陷、必跑测试、必要审批这三类仍需清零，并在评审记录中注明“紧急修复”及简化理由。涉及数据库结构或配置变更的提交，回滚方案缺失仍按阻断项处理。
评审者把个人偏好标成阻断项怎么办？
团队先统一分级口径：不修复会导致错误行为、安全风险或无法回滚，或者违反团队已明确的规则，才归为阻断项；两个条件都不满足的归建议项。提交者对分级有异议时，由合入者或团队约定的裁决人裁定，结论记录在评审单中，避免同类问题在不同评审中分级不一致。
建议项不修复会影响合入吗？
建议项不进入阻断清单，但每条都要标注处理方式：本次修复、后续跟进或不采纳及理由。合入者确认的是“已记录处理方式”，而不是要求全部修完。这样既保证合入不被非关键问题拖住，也避免建议项在聊天记录里丢失。
例外放行需要留下哪些记录？
例外放行指阻断项未清零仍决定合入，必须记录放行理由、放行人、补做计划与截止时间，并在下一次清单复盘时检查补做情况。例外放行是受控的例外，不宜作为常规通道；连续多次例外放行可作为复盘清单与流程的触发条件。
清单多久复盘一次比较合适？
不必固定周期，可按事件触发：连续出现同类阻断项遗漏、例外放行次数超过团队约定阈值、评审流程或分支策略发生变更、新成员加入后的第一个月。复盘时检查条目是否仍可核验、通过标准是否过时、阻断项范围是否需要调整，并把修订结果同步到评审单模板。
