代码评审记录模板以一张评审记录表为核心，包含评审基本信息、变更范围、检查项结论、问题清单与合入结论五组字段。填写时先锁定变更标识与评审范围，再逐项记录检查结论和待办问题，最后由合入责任人给出通过、有条件通过或退回的结论并留痕。本文提供可直接复制的空白表、逐字段填写口径、必填项标注，以及一份完整填写示例，方便团队当天投入使用。
要点总览（TL;DR）
- 模板以一张评审记录表为核心，分五组字段：评审基本信息、变更范围、检查项结论、问题清单、合入结论，可直接复制到文档或表格工具使用。
- 检查项结论采用“通过／不通过／不适用”三值，问题严重级别分阻断、重要、建议三级，合入结论分通过、有条件通过、退回三种，取值口径统一后记录才能横向比较。
- 记录编号、变更标识、提交人、评审人、评审时间、变更范围、四项检查结论、结论与合入责任人为必填；问题清单相关字段在发现问题时必填，合入时间在退回时留空。
- 填写时先锁定变更标识与评审范围，再逐项记录检查结论并登记问题，最后由合入责任人给出结论；问题关闭状态与合入结论需相互对应。
- 模板按变更类型裁剪检查项，新增字段需通过准入判断，并保留版本号与变更记录，按季度或迭代节奏回顾有效性。
可复制空白代码评审记录模板
下面这张表按五组字段分组，可直接复制到文档或表格工具中。每组字段的先后顺序对应一次评审的实际推进顺序：先确认这次评审针对哪个变更、范围多大，再逐项记录检查结论，把发现的问题登记成可跟踪的条目，最后给出合入结论。空白表只提供结构，各字段的填写口径见下一节。
| 分组 | 字段 | 填写内容 |
|---|---|---|
| 评审基本信息 | 记录编号 | |
| 变更标识 | ||
| 提交人 | ||
| 评审人 | ||
| 评审时间 | ||
| 变更范围 | 涉及模块 | |
| 变更类型 | ||
| 影响面 | ||
| 检查项与结论 | 正确性 | |
| 可读性 | ||
| 测试覆盖 | ||
| 安全与依赖 | ||
| 问题清单 | 问题描述 | |
| 严重级别 | ||
| 责任人 | ||
| 关闭状态 | ||
| 合入结论 | 结论 | |
| 合入责任人 | ||
| 合入时间 | ||
| 遗留事项 |
问题清单在实际使用中往往不止一条，复制时把“问题清单”四行扩展成多行即可，每条问题占一行，并保留问题编号以便在讨论中引用。检查项也可以按团队技术栈增加行，但应保持“检查项—结论—说明”三列结构，避免结论与依据分离。
每个字段记录什么：字段说明
同一张表在不同团队手里填出不同口径，记录就无法横向比较，也无法在复盘时判断当时的评审质量。下表给出每个字段的含义、填写口径与示例值，团队可以直接把“填写口径”一列作为填写规范使用。
| 字段 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 记录编号 | 本次评审记录的唯一标识 | 按团队约定规则生成，保证全库不重复，便于检索与引用 | CR-2024-0317 |
| 变更标识 | 被评审的代码变更 | 填写变更单号、提交哈希或分支名，能唯一定位到具体改动 | feature/order-export 分支，提交 a1b2c3d |
| 提交人 | 发起变更并送审的人 | 填姓名或工号，与变更单上的提交人一致 | 张明 |
| 评审人 | 实际参与评审的人 | 列出全部参与者，多人用顿号分隔；只列实际给出意见的人 | 李华、王倩 |
| 评审时间 | 评审完成的时间 | 填写评审意见汇总完成的日期，精确到日即可 | 2024-03-18 |
| 涉及模块 | 变更触及的代码模块或服务 | 按仓库目录或服务名填写，跨模块时全部列出 | 订单服务、导出工具类 |
| 变更类型 | 改动的性质 | 从功能新增、缺陷修复、重构、配置调整中选一项或多项 | 功能新增 |
| 影响面 | 变更可能波及的范围 | 写明受影响的接口、数据表、上下游调用方；无外部影响时写“仅内部逻辑” | 订单导出接口，影响报表模块调用 |
| 正确性 | 逻辑是否符合需求与预期 | 结论取“通过／不通过／不适用”，附一句依据 | 通过：边界条件已覆盖 |
| 可读性 | 命名、结构与注释是否清晰 | 同上三值；小问题记入问题清单，不单独判不通过 | 通过 |
| 测试覆盖 | 新增与改动逻辑是否有测试 | 写明覆盖方式与用例数量；无自动化测试时说明手工验证情况 | 通过：新增 6 个单元测试 |
| 安全与依赖 | 是否引入安全风险或新依赖 | 新增第三方依赖须写明名称与版本；无变化时写“无新增依赖” | 通过：无新增依赖 |
| 问题描述 | 评审发现的具体问题 | 写清位置与现象，避免只写“建议优化” | 导出文件名未做非法字符过滤 |
| 严重级别 | 问题的处理优先级 | 分为阻断、重要、建议三级，判定口径见下文 | 重要 |
| 责任人 | 负责修复该问题的人 | 填具体人名，不填团队或角色 | 张明 |
| 关闭状态 | 问题的处理进展 | 取“待处理／已修复待验证／已关闭”三值之一 | 已关闭 |
| 结论 | 本次评审的最终判定 | 取“通过／有条件通过／退回”三值之一 | 有条件通过 |
| 合入责任人 | 执行合入的人 | 填姓名；与提交人可以是同一人 | 李华 |
| 合入时间 | 代码实际合入的时间 | 结论为退回时留空，待重新评审后补填 | 2024-03-19 |
| 遗留事项 | 本次未解决、需后续跟进的内容 | 逐条列出并注明计划处理时间；无遗留时写“无” | 导出性能优化，计划下个迭代处理 |
检查项结论采用三值而非简单的通过与否，是为了区分“检查过且合格”和“本次变更不涉及该检查项”。例如纯文档修改的变更，测试覆盖一栏填“不适用”比填“通过”更准确，复盘时也不会误判为有测试保障。
问题严重级别的判定口径建议统一为：阻断指会导致功能错误、数据损坏或安全漏洞，未修复不得合入；重要指影响可维护性或存在边界缺陷，应在合入前修复或明确接受；建议指风格与优化类意见，可延后处理。关闭状态中，“已修复待验证”用于提交人已修改但评审人尚未确认的情况，只有评审人确认后才改为“已关闭”。
合入结论的三种取值含义不同：通过表示检查项全部合格且无未关闭的阻断、重要问题，可直接合入；有条件通过表示仅剩建议级问题或已约定遗留事项，允许合入但须登记遗留事项；退回表示存在未解决的阻断或重要问题，变更需修改后重新评审。三种结论对应不同的后续动作，填写时不能混用。
必填与选填：哪些字段不能空
必填项的作用是保证每条记录都能被定位、追溯和判定。字段缺失时，记录无法回答“评的是哪个变更、谁评的、结论是什么”这三个基本问题，这样的记录在复盘和审计中不具备参考价值。下表标注各字段的必填属性。
| 字段 | 属性 | 说明 |
|---|---|---|
| 记录编号 | 必填 | 记录的唯一入口，缺失则无法检索与引用 |
| 变更标识 | 必填 | 缺失则无法定位被评审的代码 |
| 提交人 | 必填 | 追溯变更来源 |
| 评审人 | 必填 | 评审结论的责任主体 |
| 评审时间 | 必填 | 判断评审与合入的先后顺序 |
| 涉及模块 | 必填 | 影响面判断的基础 |
| 变更类型 | 必填 | 决定检查项的取舍 |
| 影响面 | 必填 | 合入风险评估依据；无影响也须写明 |
| 四项检查结论 | 必填 | 每项都须给出结论，不涉及填“不适用” |
| 问题描述、严重级别、责任人 | 有问题时必填 | 登记问题即须三项齐全 |
| 关闭状态 | 有问题时必填 | 随处理进展更新 |
| 结论 | 必填 | 评审的最终判定 |
| 合入责任人 | 必填 | 合入动作的责任主体 |
| 合入时间 | 结论为通过或有条件通过时必填 | 退回时留空 |
| 遗留事项 | 有条件通过时必填 | 其他结论下可写“无” |
选填字段的适用场景有限。问题清单相关字段在本次评审未发现问题时整组留空，不必强行填写“无问题”；遗留事项在通过和退回两种结论下可以写“无”或留空，但有条件通过时必须逐条登记，否则“有条件”就失去了约束。合入时间在退回场景下留空，等修改后重新评审再补填，避免出现“已退回却有合入时间”的矛盾记录。
必填缺失时的处理规则应当前置到流程中：提交评审前，提交人自查基本信息与变更范围是否完整，缺项不予送审；评审结束时，评审人确认四项检查结论均已给出，缺项视为评审未完成；给出合入结论前，合入责任人核对结论、合入责任人与遗留事项是否匹配，不匹配则退回补填。把这三道检查点写进团队约定，比事后补记录更可靠。
完整填写示例：一次功能变更的评审记录
以下示例为演示情景，用于展示字段之间的对应关系。背景是订单服务新增导出功能：提交人张明在 feature/order-export 分支完成开发并送审，评审人李华、王倩参与评审，变更涉及订单服务与导出工具类，影响订单导出接口及报表模块的调用。
| 分组 | 字段 | 填写内容 |
|---|---|---|
| 评审基本信息 | 记录编号 | CR-2024-0317 |
| 变更标识 | feature/order-export 分支，提交 a1b2c3d | |
| 提交人 | 张明 | |
| 评审人 | 李华、王倩 | |
| 评审时间 | 2024-03-18 | |
| 变更范围 | 涉及模块 | 订单服务、导出工具类 |
| 变更类型 | 功能新增 | |
| 影响面 | 订单导出接口，影响报表模块调用 | |
| 检查项与结论 | 正确性 | 通过：分页与空结果边界已覆盖 |
| 可读性 | 通过：方法拆分清晰，命名统一 | |
| 测试覆盖 | 通过：新增 6 个单元测试，覆盖导出主流程与异常分支 | |
| 安全与依赖 | 通过：无新增依赖；导出内容已做权限校验 | |
| 问题清单 | 问题描述 | 导出文件名未过滤非法字符，含斜杠时保存失败 |
| 严重级别 | 重要 | |
| 责任人 | 张明 | |
| 关闭状态 | 已关闭（3 月 18 日修复，李华验证通过） | |
| 合入结论 | 结论 | 有条件通过 |
| 合入责任人 | 李华 | |
| 合入时间 | 2024-03-19 | |
| 遗留事项 | 大批量导出性能优化，计划下个迭代处理 |
这份示例展示了几个关键对应关系。问题清单中登记了一条重要级问题，责任人张明当天修复，评审人李华验证后关闭，因此合入结论可以是“有条件通过”而非“退回”——重要问题已关闭，剩余的是性能优化这类不阻塞合入的遗留事项。如果该问题在评审结束时仍处于“待处理”，结论就应改为“退回”，合入时间留空，待修复后重新评审再补填。
检查项结论与问题清单之间也需对应：可读性判为通过，意味着风格类意见没有升级为问题条目；若评审中提出了命名建议并登记为建议级问题，可读性一栏仍可判通过，但问题清单中应出现对应条目并跟踪关闭。这种对应关系让记录在复盘时能回答“当时发现了什么、怎么处理的”。
当评审记录需要与代码变更、任务和合入状态保持关联时，可以把记录表挂到对应工作项下，由提交、评审、修复、合入各环节的负责人在同一处更新状态。ONES 支持在工作项中承载评审记录与状态流转，使记录编号、变更标识与合入结论形成可追溯的链条；具体承载方式以团队实际配置为准。
模板的调整与维护方法
模板投入使用后，团队技术栈和流程会变化，字段也需要随之调整。调整的原则是保持五组字段的骨架稳定，在组内做增减，避免每次改动都推翻结构导致历史记录无法比较。
按变更类型裁剪检查项是最常见的调整。功能新增类变更应保留全部四项检查；缺陷修复类可强化正确性与测试覆盖，安全与依赖一栏在无依赖变动时填“不适用”；纯重构类变更可增加“行为是否保持不变”的检查项；配置调整类变更可增加“回滚方案”一栏。裁剪时以变更类型字段为索引，在模板中写明不同取值对应的检查项组合，填写人按类型取用即可。
新增字段需要过一道准入判断：该字段是否能帮助回答定位、追溯或判定这三类问题之一；是否每次评审都能稳定填写；是否与已有字段重复。三项都满足才加入，并同步更新字段说明表与必填标注表。仅对个别项目有用的信息，放在遗留事项或问题描述中记录，不升级为模板字段。
模板本身应有版本号与变更记录。每次调整记录版本号、调整日期、调整内容与原因，旧版本记录保留原样，不回溯修改。这样在对比不同时期的评审记录时，能解释字段差异的来源。
定期回顾建议按季度或按迭代节奏进行，回顾时抽取若干条记录检查：必填项是否齐全、检查项结论是否与问题清单对应、合入结论与遗留事项是否匹配、是否有字段长期填“不适用”而失去意义。发现长期空置的字段，考虑删除或改为选填；发现反复补填的字段，考虑改为必填并前置到送审检查中。回顾结论记入模板变更记录，形成模板持续演进的依据。
常见问题
评审过程中发现问题但当天无法修复，记录应该怎么填？
先把问题登记完整：问题描述写清位置与现象，严重级别按阻断、重要、建议判定，责任人填具体修复人，关闭状态填“待处理”。合入结论此时应填“退回”，合入时间留空。等修复提交后，把关闭状态改为“已修复待验证”，评审人确认后再改为“已关闭”，并重新组织一次评审补填结论与合入时间。整个过程在原记录上更新，不另开新记录，保证同一条变更的评审历史可追溯。
小团队人少，评审人和提交人经常是同一批人，记录还有必要填这么细吗？
人少时字段可以裁剪，但定位、追溯、判定这三类信息建议保留。记录编号、变更标识、提交人、评审时间保证记录能被找到；四项检查结论保证评审确实发生过；结论与合入责任人保证有人对合入负责。可以简化的是评审人数量、影响面描述的详细程度，以及建议级问题的跟踪粒度。裁剪后把调整写进模板变更记录，避免不同时期的记录口径不一致。
检查项结论填“不适用”和填“通过”有什么区别，会影响复盘吗？
区别在于是否真的检查过。填“通过”表示该项检查执行了且合格，填“不适用”表示本次变更不涉及该检查项。例如纯配置调整的变更，测试覆盖一栏填“不适用”更准确；如果填“通过”，复盘时会误以为该变更带有测试保障。团队应在字段说明中固定“不适用”的适用条件，并约定填写时附一句简短依据，便于后续核对。
评审记录和代码变更、任务怎么关联，避免记录散落在各处？
常见做法是把记录表挂到对应工作项下，用变更标识字段与代码提交建立对应，由提交、评审、修复、合入各环节的负责人在同一处更新状态。这样记录编号、变更标识与合入结论形成一条链，复盘时从任一入口都能找到完整过程。ONES 支持在工作项中承载评审记录与状态流转，具体承载方式以团队实际配置为准。若团队暂未使用工具承载，至少在记录编号规则中约定与变更单号的对应关系。
模板用了一段时间后，很多字段长期空着，应该删掉还是保留？
先判断空置原因。如果该字段对应的检查项在当前技术栈下确实不涉及，可以改为选填或按变更类型条件启用；如果是填写人遗漏，应把该字段前置到送审检查中，而不是删除。定期回顾时抽取若干条记录，检查必填项是否齐全、检查结论与问题清单是否对应、合入结论与遗留事项是否匹配。删除字段前确认历史记录仍保留原样，并在模板变更记录中写明调整原因。
