遗留缺陷管理策略要解决的核心问题，是把“当前版本暂不修复、但也不能直接关闭”的缺陷，从模糊搁置变成有分级、有责任人、有复核时点的受控状态。本文以一份已填写的遗留缺陷登记与处置表为主线，演示分级、处置动作、复核周期、关闭与升级条件如何落到字段和评审记录里，并给出换团队套用时的调整方法。文中情景为演示设定，不对应任何真实客户。
要点总览（TL;DR）
- 遗留缺陷指当前版本不修复但未关闭的缺陷，管理动作与普通待修复缺陷不同：跟踪的是暂不修复的理由、责任人、复核时点和升级条件。
- 示例以一份7条记录的遗留缺陷登记与处置表为主线，字段包括现象、影响范围、触发条件、分级、处置动作、责任人、复核时点和状态。
- 分级按影响范围与触发概率组合确定，处置动作从修复、规避方案、文档说明、接受风险、下版本重评五类中选一个，复核周期与等级挂钩。
- 关闭条件要可验证，升级条件要可观测；评审分歧记录理由，便于后续复核沿用同一判断口径。
- 迁移时保留两维分级结构与固定处置动作，按团队风险偏好和版本节奏调整阈值与周期，运行一到两个版本后回看微调。
示例要解决什么：遗留缺陷为何需要单独策略
遗留缺陷指已经确认存在、在当前版本或当前迭代内不安排修复、但尚未满足关闭条件的缺陷。它与普通待修复缺陷的差别在管理动作上：普通缺陷进入修复队列，跟踪的是修复进度和验证结果；遗留缺陷进入的是“受控搁置”状态，跟踪的是为什么暂不修复、由谁承担、什么时候重新评估、什么条件下必须升级处理。
缺少单独策略时，遗留缺陷通常会出现三种失控形态：一是缺陷长期停留在待处理状态，无人认领，版本发布时被反复翻出讨论；二是口头约定“下个版本再说”，但没有记录触发条件和复核时点，等到问题在线上出现才追溯；三是分级只依赖严重程度标签，导致高影响但低触发概率的问题被过度投入，低影响但高频触发的问题被长期忽略。这份示例要回答的正是这些决策点如何写成可执行的规则。
示例的产出物是一份可直接参照填写的遗留缺陷登记与处置表，覆盖以下决策点：
- 分级：按影响范围与触发概率组合确定等级，而非单一严重程度标签；
- 处置动作：修复、规避方案、文档说明、接受风险、下版本重评五类选项及适用情形；
- 复核周期：与分级挂钩的重新评估节奏；
- 关闭与升级：什么条件下可以关闭，什么条件下必须升级为当期处理。
表后附一段示例评审会记录，用于说明分级出现分歧时如何裁决并留痕。
完整示例：一份遗留缺陷登记与处置表
以下为演示情景：某中型研发团队在版本 V3.2 发布前梳理缺陷库，将 7 条确认存在但当期不修复的缺陷登记入表。团队规模、产品类型均为示例设定，不代表真实客户情况。
| 编号 | 现象 | 影响范围 | 触发条件 | 分级 | 处置动作 | 责任人 | 复核时点 | 当前状态 |
|---|---|---|---|---|---|---|---|---|
| L-001 | 批量导入超过 5000 行时页面无响应约 30 秒 | 使用批量导入的运营人员，约每周 2 次 | 单次导入行数超过 5000 | B | 规避方案：导入前拆分文件，操作手册补充说明 | 后端负责人 | V3.3 需求评审前 | 已规避，待复核 |
| L-002 | 导出报表在特定浏览器版本下列宽错位 | 使用该浏览器的少量用户，展示问题不影响数据 | 使用指定浏览器版本导出 | C | 文档说明：已知问题清单登记，引导升级浏览器 | 前端负责人 | 下一季度首月 | 已登记 |
| L-003 | 权限变更后需重新登录才生效 | 所有管理员账号，每月约 3 次操作 | 管理员调整角色权限后未重新登录 | B | 下版本重评：与权限模块重构合并处理 | 平台负责人 | V3.3 开发启动前 | 待重评 |
| L-004 | 移动端离线缓存偶发丢失，需重新加载 | 移动端用户，发生频率低于千分之一 | 弱网切换且本地缓存写入中断 | C | 接受风险：监控上报，频率上升则升级 | 移动端负责人 | 每两个月 | 监控中 |
| L-005 | 对账任务在月末高峰时段延迟超过 2 小时 | 财务对账流程，影响月末结算时效 | 月末最后两个工作日且任务量翻倍 | A | 修复：排入 V3.2 补丁版本 | 数据平台负责人 | 补丁发布后一周 | 已升级，修复中 |
| L-006 | 旧版接口文档与实际返回字段不一致 | 对接方开发者，影响联调效率 | 调用已标记废弃的接口版本 | C | 文档说明：更新废弃接口说明并标注差异 | 接口负责人 | 下一季度首月 | 已登记 |
| L-007 | 搜索结果排序在数据量超过阈值后不稳定 | 全体用户可见，触发依赖数据规模 | 单索引数据量超过既定阈值 | B | 下版本重评：与搜索服务升级一并评估 | 搜索模块负责人 | V3.3 开发启动前 | 待重评 |
示例评审会记录（演示情景）：V3.2 发布前评审会上，L-005 最初被登记为 B 级，理由是“仅月末出现”。财务代表提出，月末结算延迟直接影响对外交付承诺，触发时间可预期且后果明确。评审结论为：影响范围涉及对外承诺时，即使触发窗口窄，也按 A 级处理，L-005 升级并排入补丁版本。L-004 则有相反意见，有人主张按 B 级处理，评审会核对监控数据后确认发生频率低于千分之一且无数据损失，维持 C 级，但把复核周期从每季度缩短为每两个月，并明确“频率上升即升级”的触发条件。两条裁决均记入会议纪要，与登记表状态同步更新。
逐项解释：分级、处置动作与复核周期怎么定
分级依据：影响范围与触发概率的组合
示例中的 A、B、C 三级由两个维度交叉确定，严重程度标签只作为参考输入。影响范围回答“谁会受影响、后果是什么”，触发概率回答“多大概率会遇到”。组合规则可写成：影响涉及对外承诺、资金、数据正确性或大面积用户时，无论触发概率高低，起点为 A；影响限于内部效率或展示效果，且触发概率低时，起点为 C；其余组合落入 B。L-005 的裁决正是这条规则的直接应用。
这样分级的原因是：单看严重程度标签，容易把“理论上很严重但几乎不会发生”的问题排到最前，也会漏掉“看起来不严重但天天发生”的问题。两个维度组合后，分级结果能直接对应资源投入和复核强度。
处置动作的五个选项
示例为每条遗留缺陷指定一个明确的处置动作，避免“先放着”这种无动作状态：
- 修复：排入当前或补丁版本，适用于分级为 A 或触发条件即将普遍化的缺陷；
- 规避方案：不改代码，通过操作约定绕开，需同步更新操作说明并验证规避有效；
- 文档说明：登记为已知问题，向受影响方说明现象与应对方式，适用于影响有限且可解释的缺陷；
- 接受风险：明确记录风险内容与监控手段，适用于低频、后果可控的问题；
- 下版本重评：与后续版本的技术改造或需求合并评估，需指定重评时点，不能只写“以后再看”。
复核周期与分级挂钩
复核周期的设定逻辑是：等级越高，重新评估越频繁，因为高等级缺陷的触发条件可能随版本演进而变化。示例中 A 级在处置完成后一周内复核，B 级与版本节奏对齐（在下一版本开发启动前或需求评审前复核），C 级按季度或两个月复核。复核不是重新讨论一遍，而是核对三件事：触发条件是否仍然成立、规避或监控手段是否仍有效、是否出现升级信号。
责任人与复核时点的填写要求
责任人填写到具体角色或个人，承担的是“确保该缺陷按处置动作执行并在复核时点给出结论”，而非修复代码本身。复核时点写成可核对的时间锚点，例如“V3.3 开发启动前”“下一季度首月”，避免写“尽快”“后续跟进”这类无法验证的表述。每条记录的状态字段随处置进展更新，示例中使用了已登记、已规避待复核、待重评、监控中、已升级修复中五种状态。
关闭条件与升级条件的写法
关闭条件建议写成可验证的表述：缺陷已修复并通过验证；或规避方案已生效且操作说明已更新；或经复核确认触发条件已不存在（例如相关功能已下线）。仅“讨论过了”不构成关闭依据。升级条件同样要具体：影响范围扩大到对外承诺、监控频率超过设定阈值、触发条件在新版本中变为普遍场景，出现任一情形即从遗留状态转回当期修复队列。L-004 的“频率上升即升级”就是一条可执行的升级条件。
当登记表、复核记录和评审纪要分散在聊天工具与个人文档中时，状态同步容易滞后。ONES Project 支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代并记录跟踪修复情况，缺陷状态分布也可统计；ONES Wiki 支持文档关联任务，并可插入工作项列表。把登记表作为文档维护、把每条遗留缺陷作为工作项跟踪，复核结论与状态变更可以留在同一处，评审会裁决也有据可查。具体字段与状态如何配置属于系统实施范畴，本文不展开。
可迁移规律：换一个团队怎么套用这份示例
示例中的具体阈值和周期是演示设定，迁移时应保留结构、调整参数。可复用的规律如下：
- 分级矩阵保留“影响范围×触发概率”两维结构，阈值按团队风险偏好调整。对外承诺多的团队可把“涉及对外承诺”直接定为 A 级起点；内部工具团队可把展示类问题整体下移一级。
- 复核周期与版本节奏对齐。双周迭代的团队可把 B 级复核放在每个迭代规划会前，C 级按月复核；季度发布的团队则按发布节点设置。
- 每条记录必须有且只有一个处置动作和一个责任人，处置动作从固定选项中选择，减少“先放着”的模糊状态。
- 评审分歧的裁决要记录理由，而不只是结论。示例中 L-005 与 L-004 的裁决都写明了依据，后续复核时可直接沿用同一判断口径。
- 升级条件写成可观测的信号，例如监控阈值、影响范围变化、版本计划调整，便于任何人在复核时点之外主动触发升级。
从示例表迁移到团队实际登记表的步骤：
- 先盘点现有缺陷库，筛出“确认存在、当期不修复、未关闭”的条目，作为初始登记范围；
- 与业务方共同确定影响范围的判定口径，例如哪些后果算涉及对外承诺或数据正确性；
- 按两维矩阵为每条缺陷定级，分歧条目集中到一次评审会裁决并记录理由；
- 为每条缺陷指定处置动作、责任人和复核时点，复核时点对齐团队版本节奏；
- 把登记表放入团队共用的文档或工作项系统，设定复核提醒，并在每次版本规划会上过一遍到期条目；
- 运行一到两个版本后回看：升级和关闭的比例是否合理，复核是否按时发生，据此微调阈值与周期。
适用边界：这份示例不覆盖的情况
本文的登记表与评审记录均为演示情景，用于说明字段填写与规则设计，不代表任何真实客户的做法，也不构成实测效果数据。迁移时应按团队实际情况重新定级和设定周期。
以下内容不在本文范围内：单个缺陷从提交到修复完成的进度跟踪与验证流程；缺陷管理工具内的字段、状态机与权限配置；安全类与合规类缺陷的专门处置流程，这类缺陷通常需要遵循独立的上报、评估与修复时限要求，不能套用本文的分级与复核周期。此外，本文给出的分级矩阵与周期是通用方法示例，涉及对外承诺或监管要求的场景，应以组织既定的风险管理制度为准。
常见问题
遗留缺陷和普通待修复缺陷在跟踪上有什么不同？
普通待修复缺陷进入修复队列，跟踪的是修复进度和验证结果。遗留缺陷进入受控搁置状态，跟踪的是为什么暂不修复、由谁负责、什么时候重新评估、什么条件下必须升级为当期处理。两类缺陷的字段和评审节奏不同，混在同一队列里容易让遗留缺陷长期无人认领。
分级时影响范围和触发概率冲突怎么办？
示例给出的处理方式是设一条优先规则：影响涉及对外承诺、资金、数据正确性或大面积用户时，无论触发概率高低，起点定为 A 级；影响限于内部效率或展示效果且触发概率低时，起点为 C 级；其余组合落入 B 级。冲突条目集中到评审会裁决，并把裁决理由记入纪要，后续复核沿用同一口径。
复核时点写“下个版本再看”可以吗？
建议写成可核对的时间锚点，例如“V3.3 开发启动前”“下一季度首月”。复核时核对三件事：触发条件是否仍然成立、规避或监控手段是否仍有效、是否出现升级信号。无法验证的表述会让复核落空，遗留缺陷重新回到模糊搁置状态。
团队迭代节奏和示例不同，复核周期怎么调整？
保留“等级越高复核越频繁”的结构，把周期对齐自己的版本节奏。双周迭代的团队可把 B 级复核放在每个迭代规划会前、C 级按月复核；季度发布的团队按发布节点设置。调整后运行一到两个版本，回看升级和关闭比例是否合理、复核是否按时发生，再微调阈值。
安全类或合规类缺陷能套用这份示例吗？
不建议直接套用。这类缺陷通常需要遵循独立的上报、评估与修复时限要求，分级与复核周期应以组织既定的风险管理制度为准。本文示例适用于一般业务缺陷的遗留管理，涉及对外承诺或监管要求的场景需另行确认流程。
