不修复与延后决策是什么
won't fix（不修复）与 defer（延后）是缺陷处理中的主动决策，不是丢失或放弃：不修复意味着基于现有信息判定修复收益不足，延后意味着承认问题但安排在后续版本处理。两者都必须记录理由、影响评估、替代方案与责任人，并同步给支持与产品团队；决策写进缺陷库可检索，避免同一问题反复讨论、反复承诺。
基本信息
| 常见结论 | won't fix / defer / duplicate / as designed |
|---|---|
| 必填信息 | 结论、理由、影响范围、替代方案、决策人与日期 |
| 同步对象 | 支持团队（对外口径）、产品经理（排期）、客户成功（客户沟通） |
| 延后复核 | 登记目标版本或复核时间点，到期重新评估 |
| 可检索性 | 决策入缺陷库，同类问题引用先例答复 |
| 例外规则 | 安全与合规问题不得直接不修复，进入升级流程 |
典型使用场景
- 缺陷评审会：区分「必须修」「延后」「不修」三类，当场给出结论与理由。
- 跨团队沟通：支持团队引用决策记录答复客户，避免口头承诺扩散。
- 版本规划：延后项进入下个版本候选清单，与需求一起排优先级。
- 重复问题处理：同类缺陷再次上报时，直接引用先例快速答复。
- 质量复盘：统计不修复比例与理由分布，反查需求与设计环节的缺陷。
- 风险升级：涉及安全合规的缺陷直接走升级通道，不进入常规评审。
决策记录模板
决策记录模板
结论：won't fix / defer / duplicate
理由：设计如此（附文档链接）/ 成本高于收益 / 与 #1234 重复
影响：受影响用户范围、功能与版本
替代：规避方法或临时方案
复核：defer 需写目标版本或日期
决策人：姓名 日期：YYYY-MM-DD情形与结论对照
| 情形 | 结论 | 后续动作 |
|---|---|---|
| 设计与文档一致的行为 | won't fix | 附文档链接与对外解释口径 |
| 修复成本高于收益 | defer | 登记复核时间点与新版本候选 |
| 与既有报告重复 | duplicate | 合并跟踪，保留原始报告人信息 |
| 无法复现且证据不足 | 待补充信息 | 限时等待，超时后按无后续处理关闭 |
| 涉及安全或合规风险 | 不得 won't fix | 升级处理，走安全评审通道 |
决策记录至少包含结论、理由、影响与决策人四项，缺一项，半年后没人能解释当时为什么这样处理。
延后项要有复核机制：到期未复核的条目每周巡检一次，否则延后会变成事实上的不修复。
对外口径与内部结论保持一致：支持团队引用决策记录本身，而不是二手转述。