已知问题清单是什么
已知问题清单是版本发布时同步的遗留缺陷与限制说明：哪些问题已知、影响什么用户与场景、如何规避、计划何时修复。它面向支持团队与用户，让他们在问题被反馈之前就有答案。清单管理与发布节奏绑定——上线前汇总、上线后维护、版本间转结，否则它会迅速过期，变成没人看的旧闻。
基本信息
| 内容要素 | 问题描述、影响范围、规避方式、计划修复版本、状态 |
|---|---|
| 面向对象 | 内部支持团队、客户成功、必要时对最终用户公开 |
| 语言要求 | 用户视角描述，不暴露内部编号与实现细节 |
| 来源渠道 | 遗留缺陷清单、发布风险声明、用户反馈的新增问题 |
| 维护机制 | 随发布更新，修复后移出清单并通知相关方 |
| 版本转结 | 跨版本继承的问题逐版本确认，未修复则不消失 |
典型使用场景
- 大版本上线：把带病发布的缺陷提前告知支持团队与重点客户。
- 试用与灰度：灰度期间的新发现问题登记入清单，控制传播范围。
- 客户沟通：销售与客服面对询问时口径统一，避免各说各话。
- 迭代规划：清单作为下版本修复排期的输入之一。
- 合规披露：部分行业要求披露已知缺陷与影响范围。
清单要素示例
| 要素 | 写什么 | 避免什么 |
|---|---|---|
| 问题描述 | 用户可感知的现象 | 内部术语与工单编号 |
| 影响范围 | 哪些用户与场景受影响 | 含糊的少数场景 |
| 规避方式 | 操作建议或配置开关 | 只有内部能执行的操作 |
| 修复计划 | 目标版本或时间段 | 空头承诺与无期限挂起 |
清单要有人负责：指定维护人随发布节奏更新，否则一个月后就没人敢引用。
分级管理：面向用户的公开清单与内部完整清单分开，敏感细节不外泄。
修复完成要闭环：通知支持团队与用户，避免用户按旧清单继续规避早已修好的问题。