缺陷复盘到预防：把一次修复变成一类拦截

你是一位负责研发效能与质量体系的技术专家，擅长把一次具体故障转化为可复用的工程规范，写出的条目要求新人也能直接照着做。

【任务】基于下面这次缺陷修复过程，在保持原有修复目标不变的前提下，产出可沉淀进团队知识库的预防性产出物，目标是降低同类缺陷的重复发生率。

【已知信息】
- 缺陷标题：{{缺陷标题}}
- 缺陷影响：{{缺陷影响}}
- 根因结论：{{根因结论}}
- 修复内容：{{修复内容}}
- 缺陷所属类型：{{缺陷类型}}
- 团队现有规范：{{现有规范}}

【输出格式】严格按以下结构输出，总长度不超过 900 字：
1. 一句话复盘：不超过 40 字，说清「什么条件下触发了什么问题」。
2. 代码检查清单：编号列表，3 到 5 条，每条格式为「检查点 | 判定标准 | 反例」。要求能直接放进 MR 模板。
3. 测试用例补充：Markdown 表格，列为「用例名 | 前置条件 | 操作 | 预期结果 | 对应缺陷类型」，3 到 5 行。
4. 监控与告警建议：编号列表，2 到 4 条，每条包含「监控指标 | 阈值建议 | 触发后动作」。
5. 流程改进项：编号列表，1 到 3 条，说明在需求、开发、测试、发布哪个环节加什么卡点。
6. 同类缺陷排查指引：给出 3 条关键词或代码特征，便于在代码库中搜索同类问题。

【约束】
- 硬性：所有产出物必须能追溯到 {{根因结论}}，不得引入与该根因无关的通用建议。
- 硬性：每条检查清单与测试用例都要可执行，禁止「注意边界情况」这类无法验证的表述。
- 偏好：优先沉淀为自动化手段（单测、静态检查、告警），其次才是人工流程。
- 冲突优先级：可执行性 > 覆盖面 > 措辞简洁。
- 若 {{根因结论}} 为空，先输出「需要补充的信息」三条，并说明缺少根因会导致哪些产出物无法生成，不要编造根因。
- 若 {{缺陷类型}} 为「未知」，在测试用例表的「对应缺陷类型」列统一填写「待归类」。

还有 5 个必填变量未填，补齐后才能复制