缺陷版本影响清单用来回答一个具体问题：这个缺陷影响了哪些版本、哪些对象，在哪个版本修复、由谁验证关闭。本文提供一张可直接复制填写的空白表，并逐字段说明填写口径、必填与选填的划分、一条完整示例，以及清单随版本节奏调整和维护的方法。清单以“一条缺陷一行”组织，重点记录从缺陷出发的影响链路。
要点总览（TL;DR）
- 清单以“一条缺陷一行”组织，六组字段覆盖缺陷本体、版本、影响对象、影响范围、关联关系与处置验证，核心是还原从缺陷到版本的影响链路。
- 缺陷编号、标题、严重程度、发现阶段、发现版本、受影响版本、修复版本、影响模块、影响范围描述、责任人、状态为必填；验证版本与验证结论在关闭前必填。
- 版本字段要区分发现、受影响、修复、验证四个口径，混用会导致发布判断漏掉更早版本中的同一问题。
- 清单应在缺陷提交、修复合入、验证完成三个节点更新，发布前按受影响版本筛选作为发布检查输入，并与缺陷跟踪系统字段保持对应。
- 字段可按项目规模裁剪，接口类、数据类与线上缺陷应补齐影响接口、影响数据、上下游系统与验证结论。
可复制空白模板：缺陷版本影响清单表
下表可直接复制到 Excel、在线表格或缺陷跟踪系统的自定义字段中。一行对应一条缺陷；一条缺陷影响多个版本或多个对象时，在对应单元格内分行列出，或拆成多行并在“缺陷编号”列保持相同编号，便于筛选汇总。
| 序号 | 缺陷编号 | 缺陷标题 | 发现阶段 | 严重程度 | 发现版本 | 受影响版本 | 修复版本 | 验证版本 | 影响模块 | 影响接口 | 影响配置 | 影响数据 | 上下游系统 | 影响范围描述 | 影响面等级 | 关联缺陷 | 关联需求 | 关联变更 | 责任人 | 当前状态 | 验证结论 | 关闭时间 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
表格按六组字段排列：缺陷本体（编号、标题、发现阶段、严重程度）、版本（发现、受影响、修复、验证）、影响对象（模块、接口、配置、数据、上下游系统）、影响范围（描述与影响面等级）、关联关系（缺陷、需求、变更）、处置验证（责任人、状态、验证结论、关闭时间）。复制后可按团队习惯调整列宽和顺序，字段含义保持不变。
字段说明：每个字段记录什么、怎么填
字段填写的共同口径是：写可核验的具体对象和版本号，避免“相关功能”“多个版本”这类无法复查的表述。下表逐字段说明含义与填写方式。
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 缺陷编号 | 缺陷在跟踪系统中的唯一标识 | 直接引用系统编号，保证清单与系统记录可对应 |
| 缺陷标题 | 一句话描述缺陷现象 | 写“什么条件下出现什么错误结果”，便于非提交人理解 |
| 发现阶段 | 缺陷被发现的时点 | 填写如开发自测、测试、验收、线上等阶段名称 |
| 严重程度 | 缺陷对业务的影响级别 | 按团队既有分级填写，与影响面等级分开记录 |
| 发现版本 | 首次发现该缺陷的版本 | 填具体版本号或构建号 |
| 受影响版本 | 实际存在该缺陷的版本 | 逐版本列出；不确定时标注待确认并写明确认人 |
| 修复版本 | 包含修复的版本 | 填计划或实际合入修复的版本，未修复时留空并说明 |
| 验证版本 | 执行验证的版本 | 与修复版本一致或为其后续版本，填实际验证所用版本 |
| 影响模块 | 缺陷所在的业务模块 | 写模块名称，多个模块分行列出 |
| 影响接口 | 受影响的对外或内部接口 | 写接口名称或路径，注明调用方 |
| 影响配置 | 需要调整或核对的配置项 | 写配置项名称与当前取值，避免只写“配置问题” |
| 影响数据 | 受影响的数据表、字段或数据范围 | 写表名、字段名或数据范围，涉及历史数据时注明数量口径 |
| 上下游系统 | 受牵连的其他系统 | 写系统名称及受影响的交互方式 |
| 影响范围描述 | 影响的具体表现与边界 | 说明哪些用户、场景、数据受影响，哪些不受影响 |
| 影响面等级 | 影响广度的分级 | 按团队规则填写，如单模块、多模块、跨系统 |
| 关联缺陷 | 同源或同批次的缺陷 | 填缺陷编号，说明关联原因 |
| 关联需求 | 缺陷涉及的需求或用户故事 | 填需求编号，便于回溯需求实现情况 |
| 关联变更 | 引入或修复该缺陷的代码、配置变更 | 填变更单号或提交记录，注明变更内容 |
| 责任人 | 当前负责处理的人 | 填修复负责人，验证阶段可另记验证人 |
| 当前状态 | 缺陷处理进度 | 与跟踪系统状态保持一致，如待修复、修复中、待验证、已关闭 |
| 验证结论 | 验证是否通过及依据 | 写通过或不通过，附验证用例或验证方式 |
| 关闭时间 | 缺陷关闭的日期 | 填实际关闭日期，与系统记录一致 |
版本字段需要区分四个口径：发现版本回答“在哪里发现”，受影响版本回答“哪些版本有这个缺陷”，修复版本回答“在哪个版本修好”，验证版本回答“在哪个版本验证过”。四者混用会导致发布判断出错，例如把发现版本当作受影响版本，可能漏掉更早版本中的同一问题。
必填与选填：哪些字段不能空
清单的最低可用标准是：任何人拿到一行记录，都能判断缺陷影响谁、影响多大、在哪个版本修复、是否已验证。满足这个标准的字段为必填，其余按缺陷类型和阶段取舍。
| 字段 | 建议属性 | 理由与适用场景 |
|---|---|---|
| 缺陷编号、缺陷标题 | 必填 | 清单与跟踪系统对应的基础，缺失则无法追溯 |
| 严重程度、发现阶段 | 必填 | 决定处置优先级和发布判断 |
| 发现版本、受影响版本 | 必填 | 影响链路的核心，缺失则无法判断发布风险 |
| 修复版本 | 必填（未修复时注明计划） | 回答“在哪个版本修复” |
| 影响模块、影响范围描述 | 必填 | 回答“影响谁、影响多大” |
| 责任人、当前状态 | 必填 | 保证有人跟进、状态可查 |
| 验证版本、验证结论 | 关闭前必填 | 关闭依据，缺失则不能判定修复有效 |
| 影响接口、上下游系统 | 涉及对外或跨系统时必填 | 线上缺陷、对外接口缺陷必须填写 |
| 影响配置、影响数据 | 涉及配置或数据时必填 | 配置类、数据类缺陷必须写明具体项 |
| 影响面等级 | 选填 | 团队有分级规则时填写，用于汇总统计 |
| 关联缺陷、关联需求、关联变更 | 选填 | 存在同源缺陷、需求回溯或变更追溯需要时填写 |
| 关闭时间 | 关闭时必填 | 用于统计修复周期 |
不同缺陷类型的取舍不同：界面文案类缺陷可只填模块与影响范围；接口或数据类缺陷应补齐影响接口、影响数据与上下游系统；线上缺陷无论类型，影响对象与验证结论都应作为必填。字段暂时缺失时，不要留空当作已确认，应填写“待确认”并注明确认人和确认时限，在缺陷进入验证前补齐。
填写示例：一条缺陷的完整记录
以下为演示情景，用于说明字段如何配合形成完整影响链路，不代表真实项目数据。
| 字段 | 填写内容 |
|---|---|
| 缺陷编号 | BUG-2317 |
| 缺陷标题 | 订单导出在数据量超过一万条时超时失败 |
| 发现阶段 | 测试 |
| 严重程度 | 高 |
| 发现版本 | V3.2.0 |
| 受影响版本 | V3.1.0、V3.2.0 |
| 修复版本 | V3.2.1 |
| 验证版本 | V3.2.1 |
| 影响模块 | 订单管理、报表导出 |
| 影响接口 | 订单导出接口 /order/export，调用方为运营后台 |
| 影响配置 | 导出超时阈值 export.timeout，当前 30 秒 |
| 影响数据 | 订单主表 order_main，涉及近三个月订单数据 |
| 上下游系统 | 数据同步服务：导出失败导致下游报表延迟 |
| 影响范围描述 | 运营人员导出超过一万条订单时失败；一万条以下导出正常 |
| 影响面等级 | 多模块 |
| 关联缺陷 | BUG-2298：同一导出接口的分页参数错误 |
| 关联需求 | REQ-512：运营后台订单批量导出 |
| 关联变更 | CHG-880：导出逻辑改为异步分批处理 |
| 责任人 | 后端开发 A（修复），测试 B（验证） |
| 当前状态 | 已关闭 |
| 验证结论 | 通过：一万五千条订单导出成功，耗时 42 秒；下游报表同步正常 |
| 关闭时间 | 2024-06-18 |
这条记录的影响链路是：缺陷在 V3.2.0 测试中发现，V3.1.0 同样存在；影响订单管理与报表导出两个模块，牵连数据同步服务；修复通过 CHG-880 变更合入 V3.2.1，并在同版本验证通过后关闭。受影响版本列出两个，说明发布 V3.1.0 的维护分支时也需要评估是否合入修复。验证结论写明了验证数据量和耗时，关闭依据可复查。
调整与维护方法：让清单长期可用
清单的价值取决于它和版本节奏、缺陷跟踪系统保持一致。字段可以裁剪，但裁剪要有规则，更新要有固定时点。
按项目规模与缺陷类型裁剪字段。小型项目可保留缺陷本体、版本、影响模块、影响范围、责任人、状态、验证结论这几组核心字段，合并接口、配置、数据为一列“影响对象明细”。中大型项目或涉及多系统集成的项目，建议保留完整字段，并按缺陷类型设置字段模板：接口类缺陷默认展开接口与上下游系统，数据类缺陷默认展开数据范围。
在版本发布节点固定更新。建议在三个时点更新清单：缺陷提交时填写缺陷本体与发现版本；修复合入时填写修复版本、关联变更与影响对象；验证完成时填写验证版本、验证结论与关闭时间。版本发布前，按受影响版本筛选清单，确认每个版本对应的缺陷是否已修复或已评估风险，作为发布检查的一项输入。
与缺陷跟踪系统同步。清单字段应尽量映射为跟踪系统中的字段，减少两套记录。以 ONES Project 为例，缺陷可一键提交至对应项目或迭代并跟踪修复情况，团队可将受影响版本、影响模块、验证结论等作为缺陷工作项的记录项维护，清单则作为按版本汇总的视图使用。ONES Wiki 支持文档关联任务并插入工作项列表，适合把清单作为版本发布文档的一部分，与缺陷记录保持对应。具体字段配置需按团队实际系统设置核验。
定期复核与字段演进。建议每个版本周期复核一次清单：检查是否有长期停留在“待确认”的字段，检查受影响版本与修复版本的对应关系是否完整，统计因字段缺失导致返工的记录。新增字段时，先在一个项目试用一个版本周期，确认填写成本与使用收益后再推广；删除字段前，确认历史记录中的信息已有其他留存方式。
本文聚焦从缺陷出发的影响链路记录。需求覆盖与需求追溯矩阵的设计、跨对象变更治理与变更影响分析流程，属于相邻主题，可按团队需要另行建立规范，并与本清单在关联需求、关联变更两列上保持编号对应。
常见问题
一条缺陷影响多个版本或多个模块时，清单应该拆成多行还是写在一行里？
两种做法都可以，取决于后续怎么用。如果主要按版本筛选发布风险，建议拆成多行，每行对应一个受影响版本，缺陷编号列保持相同，这样按版本过滤时不会漏行。如果主要看单条缺陷的全貌，可以一行内用换行列出多个版本和模块，但筛选和统计会不方便。
无论选哪种，受影响版本与修复版本的对应关系要写清楚，避免出现某一行只写了受影响版本、却没写该版本是否合入修复的情况。
缺陷还没修复时，修复版本和验证字段怎么填？
修复版本可以填计划合入的版本，并在影响范围描述或备注中注明“计划中”；尚未确定计划时填“待确认”，写明确认人和确认时限。验证版本与验证结论在缺陷进入验证前可以留空，但不能用空白表示已确认，关闭前必须补齐。
发布前按受影响版本筛选清单时，这类记录应单独列出，作为发布风险评估的输入，而不是默认视为已处理。
清单和缺陷跟踪系统里的记录重复维护，怎么减少两套数据不一致？
优先让清单字段映射为跟踪系统中的字段，清单本身作为按版本汇总的视图使用，减少手工誊抄。更新时点与缺陷状态流转对齐：提交时填缺陷本体与发现版本，修复合入时填修复版本与关联变更，验证完成时填验证结论与关闭时间。
以 ONES Project 为例，缺陷可一键提交至对应项目或迭代并跟踪修复情况，团队可将受影响版本、影响模块、验证结论等作为缺陷工作项的记录项维护；ONES Wiki 支持文档关联任务并插入工作项列表，适合把清单作为版本发布文档的一部分。具体字段配置需按团队实际系统设置核验。
小型项目字段太多填不过来，最少保留哪些字段？
最低可用标准是任何人拿到一行记录，都能判断缺陷影响谁、影响多大、在哪个版本修复、是否已验证。按这个标准，可保留缺陷编号、标题、严重程度、发现版本、受影响版本、修复版本、影响模块、影响范围描述、责任人、状态，关闭前补验证版本与验证结论。
接口、配置、数据三类影响对象可以合并为一列“影响对象明细”，但涉及对外接口、数据变更或线上缺陷时，仍应写清具体接口名、表名或配置项，避免只写“相关功能”。
清单多久复核一次，新增字段要注意什么？
建议每个版本周期复核一次，重点检查长期停留在“待确认”的字段、受影响版本与修复版本的对应是否完整，以及因字段缺失导致返工的记录。版本发布前按受影响版本筛选，是复核的自然时点。
新增字段时先在一个项目试用一个版本周期，确认填写成本与使用收益后再推广；删除字段前确认历史记录中的信息已有其他留存方式。字段演进规则写进团队规范，比每次临时加列更容易长期执行。
