缺陷根因复核记录用于把一次缺陷复盘从口头讨论变成可追溯的书面结论。模板通常按五组字段组织：缺陷基本信息、根因分析、复核结论、预防措施、闭环与归档。下面先给一张可直接复制填写的空白表，再逐字段说明填写口径、必填与选填的划分，并用一条完整记录示范写法，最后说明如何按团队情况裁剪和长期维护。
要点总览（TL;DR）
- 模板按五组字段组织：缺陷基本信息、根因分析、复核结论、预防措施、闭环与归档，可直接复制到文档或缺陷工作项中使用。
- 必填字段以“缺了就无法复核或无法闭环”为判定标准：缺陷编号、缺陷描述、根因分类、复核结论、预防措施与责任人、关闭状态不能空。
- 根因描述要写到可验证的机制层面，复核结论与预防措施一一对应，每条措施带责任人和验证时点。
- 模板可按缺陷类型增减字段，并保留版本号与变更记录；复核记录可承载在缺陷工作项与知识库文档中。
可复制空白模板：缺陷根因复核记录表
下表为空白模板，可整体复制到文档、知识库页面或缺陷工作项的描述字段中使用。表格按五组字段分区，填写时在“填写内容”列逐项录入，不需要的选填项可留空或标注“不适用”。
| 分区 | 字段名称 | 填写内容 |
|---|---|---|
| 一、缺陷基本信息 | 缺陷编号 | |
| 缺陷标题 | ||
| 缺陷描述 | ||
| 发现阶段与环境 | ||
| 影响范围 | ||
| 复现条件 | ||
| 二、根因分析 | 直接原因 | |
| 根因分类 | ||
| 根因描述 | ||
| 证据链接 | ||
| 分析参与人 | ||
| 三、复核结论 | 复核参与人 | |
| 复核日期 | ||
| 复核结论 | ||
| 结论依据 | ||
| 四、预防措施 | 预防措施 | |
| 措施责任人 | ||
| 验证时点 | ||
| 措施验证结果 | ||
| 五、闭环与归档 | 关闭状态 | |
| 关闭日期 | ||
| 归档位置 | ||
| 关联缺陷或需求 |
复制时保留分区列有助于填写人理解字段归属；如果目标系统只支持平铺字段，可去掉分区列，把分区名称并入字段名，例如“根因分类”“复核结论”。
字段说明：每个字段记录什么、怎么填
字段说明的作用是让不同人填出的记录口径一致，尤其是根因分类和复核结论这两处最容易写成主观判断。以下按五组逐一说明。
缺陷基本信息组
- 缺陷编号：填写缺陷系统中的唯一编号，便于与工作项对应。没有系统编号时，用“项目简称-日期-序号”自编。
- 缺陷标题：一句话概括现象，包含对象和异常表现，例如“订单导出在超过一万行时超时中断”。
- 缺陷描述：写清预期结果、实际结果和触发操作，控制在能独立读懂的范围。
- 发现阶段与环境：记录在需求评审、开发自测、测试、上线后哪个阶段发现，以及涉及的版本、环境或配置。
- 影响范围：说明受影响的用户、数据、功能模块或业务量级，用于判断复核优先级。
- 复现条件：写清前置数据、操作步骤和出现频率，稳定复现与偶发要分别注明。
根因分析组
- 直接原因：导致缺陷出现的直接技术或操作原因，例如某段逻辑未处理空值。
- 根因分类：从团队约定的分类中选择，常用口径包括需求遗漏、设计缺陷、编码错误、测试覆盖不足、环境与配置问题、流程与协作问题。分类应指向可改进的环节，避免只写“人为疏忽”。
- 根因描述：写到可验证的机制层面，说明“什么环节缺少什么控制，导致问题未被发现或未被阻止”。例如“需求文档未定义大数据量导出的性能指标，开发与测试均未覆盖该场景”。
- 证据链接：附上日志、代码提交、测试记录、聊天记录或文档链接，供复核人核对。
- 分析参与人：记录参与根因讨论的人员及其角色，便于追溯分析视角是否完整。
复核结论组
- 复核参与人：填写参加复核评审的人员，通常包括缺陷责任人、模块负责人和质量角色。
- 复核日期：记录复核完成的日期。
- 复核结论：明确写出“根因成立”“根因需补充”“根因判断有误并修正为……”等结论，并说明是否认可现有预防措施。
- 结论依据：简述支撑结论的证据或讨论要点，避免结论只有一句“已确认”。
预防措施组
- 预防措施：针对根因写出可执行的动作，例如补充需求模板中的性能指标项、增加该类场景的自动化用例、在代码评审清单中加入空值检查项。措施与根因、复核结论应一一对应。
- 措施责任人：每条措施指定一名负责人，避免集体负责。
- 验证时点：写明何时验证措施是否落地，例如“下个迭代评审前”“本月末”。
- 措施验证结果：措施完成后填写验证方式和结果，未完成时注明当前进度。
闭环与归档组
- 关闭状态：使用统一取值，如“待复核、复核中、措施执行中、已关闭”。
- 关闭日期：记录缺陷与复核记录正式关闭的日期。
- 归档位置：填写记录存放的文档路径或知识库页面，便于后续检索。
- 关联缺陷或需求：登记由同一根因引出的其他缺陷、需求变更或改进项，用于识别重复问题。
必填与选填：哪些字段不能空
必填字段的判定标准是“缺了就无法完成复核或无法闭环”。按此标准，缺陷编号、缺陷描述、根因分类、复核结论、预防措施与责任人、关闭状态为必填；其余字段按缺陷类型和流程阶段选填。
| 类别 | 字段 | 判定理由或适用情形 |
|---|---|---|
| 必填 | 缺陷编号 | 缺少编号则记录无法与缺陷对应，追溯链断裂 |
| 必填 | 缺陷描述 | 复核人需要据此判断根因是否成立 |
| 必填 | 根因分类 | 分类是后续统计重复问题和改进方向的依据 |
| 必填 | 复核结论 | 没有结论的记录不构成复核 |
| 必填 | 预防措施 | 复核的目的是防止再发，措施为空则闭环无意义 |
| 必填 | 措施责任人 | 无责任人的措施无法跟踪落地 |
| 必填 | 关闭状态 | 状态决定记录是否仍在处理队列中 |
| 选填 | 影响范围、复现条件 | 偶发或影响面小的缺陷可简化，但影响面大的缺陷建议填写 |
| 选填 | 证据链接 | 根因清晰且证据已在缺陷系统中留存时可省略 |
| 选填 | 复核参与人、复核日期 | 单人复核的小团队可简化，多人评审时建议填写 |
| 选填 | 措施验证结果 | 措施尚未到期时留空，到期后补填 |
| 选填 | 归档位置、关联缺陷或需求 | 记录已存放在固定位置时可省略归档位置 |
必填字段缺失时，记录不应进入“已关闭”状态。处理方式有两种：一是退回填写人补充，二是在复核会上当场补齐并注明补填人和补填日期。对于确实无法获取的信息，例如缺陷已无法复现，应在对应字段写明“无法获取及原因”，而不是留空，以便后续读者判断记录的完整程度。
填写示例：一条完整复核记录
以下示例为演示情景，用于说明各字段的写法，字段顺序与空白模板一致。
| 分区 | 字段名称 | 填写内容 |
|---|---|---|
| 一、缺陷基本信息 | 缺陷编号 | ORD-2317 |
| 缺陷标题 | 订单导出超过一万行时超时中断 | |
| 缺陷描述 | 预期导出全部订单并生成文件；实际在数据量超过一万行时请求超时，页面提示失败，无文件生成 | |
| 发现阶段与环境 | 测试阶段，预发布环境，版本 3.4.0 | |
| 影响范围 | 使用批量导出的运营人员，日均约二十次导出请求 | |
| 复现条件 | 选择时间范围覆盖一万行以上订单，点击导出，稳定复现 | |
| 二、根因分析 | 直接原因 | 导出接口同步查询全部数据，超过网关响应时限后被中断 |
| 根因分类 | 需求遗漏 | |
| 根因描述 | 需求文档只描述导出功能，未定义数据量上限与性能指标；设计与测试均未覆盖大数据量场景，导致同步导出方案在评审阶段未被识别为风险 | |
| 证据链接 | 网关超时日志、导出接口代码提交记录、需求文档导出章节 | |
| 分析参与人 | 后端开发（接口实现）、测试（场景设计）、产品（需求编写） | |
| 三、复核结论 | 复核参与人 | 后端负责人、测试负责人、产品负责人 |
| 复核日期 | 2024-06-12 | |
| 复核结论 | 根因成立；认可预防措施，需补充导出类需求的性能指标模板项 | |
| 结论依据 | 日志显示请求在网关时限处中断，需求文档确无数据量约定 | |
| 四、预防措施 | 预防措施 | 1. 需求模板增加“数据量与性能指标”必填项；2. 导出类功能默认评估异步方案；3. 测试用例库补充大数据量导出场景 |
| 措施责任人 | 措施1：产品负责人；措施2：后端负责人；措施3：测试负责人 | |
| 验证时点 | 下个迭代需求评审前完成模板修订，本月底前完成用例补充 | |
| 措施验证结果 | 需求模板已更新并在两次评审中执行；大数据量导出用例已加入回归集，验证通过 | |
| 五、闭环与归档 | 关闭状态 | 已关闭 |
| 关闭日期 | 2024-06-28 | |
| 归档位置 | 项目知识库“缺陷复盘”页面下按季度归档 | |
| 关联缺陷或需求 | 关联需求“导出性能优化”；关联缺陷 ORD-2298（同类超时问题） |
示例中根因写到“哪个环节缺少哪项控制”，复核结论明确认可或修正根因，预防措施逐条对应根因并带责任人和验证时点，这三处是记录能否支撑后续改进的关键。
调整与维护：按团队情况裁剪字段
模板拿到后不必原样长期使用，可以按缺陷类型、团队规模和流程阶段裁剪，但需保留支撑复核与闭环的核心字段。裁剪的原则是：影响“能否判断根因是否成立”和“能否跟踪措施落地”的字段保留，仅影响描述丰富度的字段可按需增减。
按缺陷类型增减字段
- 线上严重缺陷：保留全部字段，并强化影响范围、证据链接和关联缺陷，便于评估同类风险。
- 一般功能缺陷：可简化复现条件和分析参与人，保留根因分类、复核结论与预防措施。
- 配置或环境类缺陷：在根因分类中单列“环境与配置”，并在证据链接中要求附配置差异记录。
- 重复出现的同类缺陷：在关联缺陷字段中登记历史记录，用于判断预防措施是否失效。
模板版本与变更记录维护
模板本身应有版本号和变更记录，写明每次调整的字段、原因和生效日期。调整字段时同步更新字段说明和必填清单，避免模板与说明脱节。已归档的历史记录保持原样，不因模板升级而回改，必要时在归档位置注明所用模板版本。
与缺陷系统字段的对应关系
复核记录通常一部分信息已在缺陷工作项中，另一部分需要单独文档承载。建议建立对应关系：缺陷编号、标题、描述、状态直接引用工作项字段；根因分类、复核结论、预防措施可作为工作项字段或关联文档字段维护。使用 ONES Project 跟踪缺陷时，缺陷可提交到对应项目或迭代中记录修复情况，并统计缺陷状态分布；复核记录作为文档沉淀时，可放在 ONES Wiki 中与项目任务关联，借助页面模板库固化为制式模板，并通过页面版本记录保留每次修订，便于查看与回滚。字段是否落在工作项还是文档，取决于团队希望在哪个环节查看和统计，模板设计本身保持一致即可。
常见问题
缺陷根因复核记录和缺陷复盘会议纪要有什么区别，需要两份都留吗？
两者可以合并，也可以分开，取决于团队习惯。会议纪要记录讨论过程、参与人和分歧点；复核记录聚焦结论与措施，字段更固定，便于统计和检索。如果团队已有规范的纪要模板，可以在纪要中嵌入复核记录的五组字段，形成一份文档；如果纪要偏过程记录，则单独维护复核记录，并在纪要中引用其归档位置。关键是复核结论、预防措施和责任人只在一处维护，避免两份文档结论不一致。
缺陷无法复现或已经修复，根因分析字段怎么填？
无法复现时，在复现条件字段写明“无法复现”及已尝试的条件，在根因描述中说明推断依据和不确定性，例如“根据日志推断为并发写入冲突，未能稳定复现验证”。已经修复的缺陷仍应补做根因分析，可依据代码提交记录、日志和修复方案反推原因，并在证据链接中附上对应记录。确实无法定位根因的，复核结论写“根因未确认”，预防措施可先落在监控告警或补充日志上，待同类问题再次出现时补充分析。
小团队人少，复核参与人和分析参与人能否由同一人填写？
可以简化，但建议保留区分。分析参与人记录谁参与了根因讨论，复核参与人记录谁对结论负责。小团队中同一人既分析又复核时，在复核参与人字段注明“独立复核”或“与分析的同一人”，让后续读者知道这条记录的复核独立性有限。对于线上严重缺陷或重复出现的问题，仍建议安排分析人之外的角色参与复核，避免根因判断停留在个人视角。
预防措施到期未完成，记录应该保持什么状态？
措施未完成时，关闭状态不应置为“已关闭”，可保持“措施执行中”，并在措施验证结果字段写明当前进度和延期原因。验证时点到期后由措施责任人更新进度，复核人定期检查逾期措施。如果措施因需求变更不再适用，应在复核结论或措施验证结果中说明取消原因，并记录替代措施，避免记录停留在无人跟进的状态。
复核记录放在缺陷工作项里还是知识库文档里更合适？
取决于团队在哪个环节查看和统计。缺陷编号、标题、描述、状态等信息已在工作项中，复核结论和预防措施若需要按缺陷筛选统计，适合作为工作项字段维护；需要完整叙述根因分析过程、附证据链接和长期归档的记录，适合放在知识库文档中。使用 ONES 时，缺陷可提交到对应项目或迭代中跟踪修复情况，复核记录可放在 ONES Wiki 中与项目任务关联，并通过页面模板库固化为制式模板、借助页面版本记录保留修订。两种方式可以并存，用缺陷编号建立对应关系即可。
