缺陷预防措施清单把“缺陷为什么会发生”转成“下一次怎样避免”，核心字段包括缺陷现象、根因归类、预防措施、责任人与落地时点、验证方式和状态。本文先给出一张可直接复制到文档或表格工具中的空白表，再逐列说明填写口径、必填规则，并用一条完整记录示范，最后说明如何按团队情况裁剪字段并定期维护。
要点总览（TL;DR）
- 空白清单以缺陷类型分组，表头覆盖缺陷现象、根因归类、根因说明、预防措施、责任人、落地时点、验证方式、复发观察期、验证结果和状态。
- 创建阶段必填缺陷类型、编号、缺陷现象、根因归类、根因说明、预防措施、责任人、落地时点和验证方式；复发观察期与验证结果在关闭前补全。
- 预防措施要写成可检查的动作，并与验证方式成对出现；写不出验证动作时，继续拆到可检查的程度。
- 清单按团队规模裁剪字段，按迭代或按月评审，观察期内复发则重开条目并保留原措施记录。
- 清单可放在文档中维护，并与缺陷记录保持对应；团队已有缺陷管理工具时，可把措施条目与缺陷放在同一项目下跟踪。
可复制空白模板：缺陷预防措施清单表
下面这张表可以直接复制到表格工具或文档中。表头固定，行按缺陷类型分组，每组预留若干空白行；状态与验证结果两列先留空，等预防措施落地并观察一段时间后再回填。分组行只写缺陷类型名称，不填具体内容，便于后续按类型筛选和统计。
| 缺陷类型 | 编号 | 缺陷现象 | 根因归类 | 根因说明 | 预防措施 | 责任人 | 落地时点 | 验证方式 | 复发观察期 | 验证结果 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 分组一：需求与设计类 | ||||||||||||
| 需求与设计类 | ||||||||||||
| 需求与设计类 | ||||||||||||
| 分组二：编码实现类 | ||||||||||||
| 编码实现类 | ||||||||||||
| 编码实现类 | ||||||||||||
| 分组三：测试与验证类 | ||||||||||||
| 测试与验证类 | ||||||||||||
| 测试与验证类 | ||||||||||||
| 分组四：环境与发布类 | ||||||||||||
| 环境与发布类 | ||||||||||||
| 环境与发布类 | ||||||||||||
分组名称可以按团队实际缺陷分布调整，常见做法是沿用缺陷管理系统中的缺陷类型字段，保证清单与缺陷记录使用同一套分类。空白行数量按每类近期缺陷数量预留，不必一次填满。
字段说明：每一列填什么、怎么填
同一张表由不同角色填写时，最容易出现口径不一致的是根因归类和预防措施两列。前者容易写成现象复述，后者容易写成“加强评审”“提高质量意识”这类无法验证的口号。下表给出每个字段的含义与填写口径，填写前建议先对齐一次。
| 字段名 | 含义 | 填写口径 |
|---|---|---|
| 缺陷类型 | 该条预防措施对应的缺陷分类 | 沿用缺陷记录中的类型字段，如需求与设计类、编码实现类、测试与验证类、环境与发布类；一条措施只归一个类型 |
| 编号 | 清单内唯一标识 | 建议用“类型缩写-序号”，如 REQ-01、COD-03，便于在评审和复盘中引用 |
| 缺陷现象 | 缺陷发生时可观察到的表现 | 写用户或系统层面看到的结果，包含触发条件，如“订单金额超过 1 万元时，优惠券叠加计算错误”；避免只写“计算错误” |
| 根因归类 | 缺陷产生的环节类别 | 从需求理解、设计缺失、编码疏忽、测试覆盖不足、环境配置、发布流程等类别中选择，与缺陷类型区分开：类型描述缺陷长什么样，根因归类描述它从哪个环节漏进来 |
| 根因说明 | 已确认的具体原因 | 写经过复现或分析确认的原因，如“优惠券叠加规则在需求文档中未定义优先级”；根因未确认时先标记待确认，不凭猜测填写 |
| 预防措施 | 为避免同类根因再次发生而采取的动作 | 写成可执行、可检查的动作，包含对象和产物，如“在需求评审检查单中增加优惠叠加优先级确认项，评审记录附规则表”；避免“加强评审”“提高意识”等口号 |
| 责任人 | 负责推动措施落地的人 | 写具体角色或姓名，一名责任人对应一条措施；跨角色协作时写主责人，协作者放入备注 |
| 落地时点 | 措施完成的时间节点 | 写具体日期或明确的迭代节点，如“2025-07-15 前”或“下个迭代需求评审前”；避免写“尽快”“后续” |
| 验证方式 | 判断措施是否生效的方法 | 写可观察的检查动作，如“抽查最近 5 次需求评审记录，确认检查项已勾选并附规则表”；验证方式应与预防措施一一对应 |
| 复发观察期 | 观察同类缺陷是否再次出现的时间范围 | 按缺陷发生频率设定，如“措施落地后 2 个迭代”或“上线后 30 天”；观察期结束时回填验证结果 |
| 验证结果 | 观察期结束后的结论 | 填“未复发”“复发 N 次”或“部分生效”，复发的需在备注中关联新缺陷编号 |
| 状态 | 条目的处理进度 | 建议使用待确认、待落地、观察中、已验证、已关闭、已重开六种状态，状态变更时同步更新验证结果 |
| 备注 | 补充信息 | 记录关联缺陷编号、协作者、措施调整原因等 |
预防措施与验证方式要成对填写。一条措施如果写不出对应的验证动作，通常说明它还不够具体，需要继续拆到可以检查的程度。
必填与选填：哪些字段不能空
清单条目在创建阶段和关闭阶段的必填要求可以不同。创建时保证根因和措施可追溯，关闭时保证验证结论完整。下表区分两类字段，并给出空缺时的处理方式。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 缺陷类型 | 必填 | 分组和统计的基础，缺失后无法按类型汇总 |
| 编号 | 必填 | 评审、复盘和缺陷记录之间互相引用的依据 |
| 缺陷现象 | 必填 | 判断措施是否针对同一类问题的前提 |
| 根因归类 | 必填 | 决定预防措施从哪个环节入手 |
| 根因说明 | 必填 | 根因未确认时填“待确认”并注明分析中，确认后补全 |
| 预防措施 | 必填 | 清单的核心内容，空缺的条目没有存在意义 |
| 责任人 | 必填 | 没有责任人的措施无法推进；暂未确定时填主责角色并注明待指派 |
| 落地时点 | 必填 | 没有时点的措施容易长期停留在待落地；暂无法确定时先填最近一个评审节点 |
| 验证方式 | 必填 | 与措施成对出现，缺失时措施视为未定义完成 |
| 状态 | 必填 | 驱动清单流转，新建条目默认“待确认” |
| 复发观察期 | 选填（关闭前补全） | 创建时可暂空，措施落地进入观察阶段时必须填写 |
| 验证结果 | 选填（关闭前补全） | 观察期结束后填写，未到观察期时留空 |
| 备注 | 选填 | 用于关联缺陷编号、协作者和调整原因 |
必填项暂缺时，统一用“待确认”“待指派”“待定”等标记，并在备注中写明补齐的时间或前置条件，避免用空白行表示未知。评审时优先检查带待定标记的条目，超过约定时间仍未补齐的，在清单评审中单独提出。
填写示例：一条完整记录怎么填
以下为演示情景，用于说明字段之间的对应关系，不代表真实项目数据。
| 字段 | 填写内容 |
|---|---|
| 缺陷类型 | 编码实现类 |
| 编号 | COD-07 |
| 缺陷现象 | 订单金额超过 1 万元且同时使用两张优惠券时，实付金额比预期多 50 元，触发条件为两张券叠加且订单含运费 |
| 根因归类 | 编码疏忽 |
| 根因说明 | 优惠计算函数先扣减券面额再计算运费门槛，与需求中“先判断运费门槛再叠加优惠”的顺序相反；需求文档已写明顺序，开发实现时遗漏 |
| 预防措施 | 在优惠计算模块补充金额顺序的单元测试用例，覆盖“含运费 + 多券叠加”组合；将该组合加入该模块的回归用例集 |
| 责任人 | 优惠模块开发负责人 |
| 落地时点 | 2025-07-20 前，随当前迭代提测 |
| 验证方式 | 检查回归用例集中是否包含该组合用例，并在提测版本上执行一次，确认用例通过 |
| 复发观察期 | 措施落地后 2 个迭代 |
| 验证结果 | 未复发 |
| 状态 | 已关闭 |
| 备注 | 关联缺陷 BUG-2317；需求文档顺序描述已同步在评审检查单中确认 |
这条记录体现了几个填写要点：缺陷现象带触发条件，根因说明指出具体代码逻辑与需求的偏差，预防措施落到测试用例这一可检查的产物，验证方式与措施直接对应，观察期结束后才回填验证结果并关闭。
调整与维护方法：按团队情况改字段并定期更新
清单首次填写完成后，字段和条目都需要随团队情况调整。裁剪的原则是保留能支撑“根因—措施—验证”闭环的字段，合并重复信息，删去长期无人填写的列。
按缺陷类型与团队规模裁剪字段
- 缺陷数量较少的小团队，可将“根因说明”与“缺陷现象”合并为一列，用一段话描述现象和原因，减少填写负担。
- 缺陷类型集中的团队，可去掉分组行，直接在类型列填写，靠筛选完成分组。
- 跨团队协作较多时，保留“责任人”和“备注”，并在备注中写明协作方，避免责任模糊。
- “编号”在条目超过几十条后价值明显，条目较少时可暂用行号替代，规模扩大后再补编号规则。
定期评审与关闭条目的节奏
建议按迭代或按月安排一次清单评审，检查三类内容：处于待确认和待落地的条目是否按期推进；观察期已结束的条目是否回填验证结果；已关闭条目中是否有同类缺陷再次出现。评审的输出是状态更新和新增条目，评审记录可附在清单所在文档中，便于回溯。
措施无效时的回退与重开处理
观察期内同类缺陷再次发生时，将该条目状态改为“已重开”，在验证结果中写明复发次数，并在备注中关联新缺陷编号。重开时先判断原措施是执行不到位还是方向不对：执行不到位的，补充落地检查；方向不对的，回到根因说明重新分析，必要时更换根因归类并制定新措施。原措施记录保留，不删除，以便后续复盘时看到调整过程。
清单需要长期使用时，承载方式会影响维护成本。若团队已经在使用 ONES Project 管理缺陷，可将缺陷记录与预防措施条目放在同一项目下跟踪，借助缺陷跟踪记录修复情况，并按缺陷状态分布观察同类问题是否收敛；清单本身可放在 ONES Wiki 的文档中，通过文档关联任务、插入工作项列表，让措施条目与缺陷记录保持对应。字段自定义和状态流转的具体配置方式，建议在选型或搭建时结合实际流程核验。团队规模较小、缺陷记录不多的场景，用共享表格维护同样可行，关键是保持评审节奏和状态更新。
常见问题
根因还没确认时，这条记录能不能先建？
可以先建，但要把“根因说明”填成“待确认”，并在备注中写明正在做的分析动作和预计确认时间，状态设为“待确认”。此时预防措施一列可以暂空，等根因确认后再补。评审时优先检查这类条目，超过约定时间仍未确认的，单独提出跟进。
一条预防措施对应多个缺陷，需要拆成多条记录吗？
按根因判断。多个缺陷由同一个根因引起，可以合并为一条记录，在备注中列出关联缺陷编号；根因不同则拆成多条，避免一条措施同时承担多个验证目标。合并后的记录在验证时，要覆盖备注中列出的全部关联缺陷。
观察期内没有同类缺陷出现，是否可以直接关闭？
可以关闭，但要先回填验证结果，写明观察期范围和“未复发”的结论，再改状态为“已关闭”。如果观察期尚未结束就关闭，后续复发时缺少对照基准，重开时难以判断原措施是否执行到位。
清单条目很多时，怎样避免评审流于形式？
评审只聚焦三类条目：带“待确认”“待指派”“待定”标记的、观察期已结束但未回填结果的、近期出现复发的。其余已关闭条目按季度抽查即可。评审输出状态更新和新增条目，记录附在清单所在文档中，便于回溯。
用文档维护清单和用缺陷管理工具维护，怎么选？
缺陷记录少、参与人少的团队，用共享文档维护清单即可，重点是保持评审节奏。缺陷量大、需要按状态分布观察同类问题是否收敛时，可把措施条目与缺陷记录放在同一项目下跟踪。若团队使用 ONES，缺陷跟踪可记录修复情况并统计缺陷状态分布，清单本身可放在 ONES Wiki 文档中，通过文档关联任务、插入工作项列表与缺陷记录保持对应；字段自定义和状态流转的具体配置方式，建议在搭建时结合实际流程核验。
