把事故复盘连到评测：四步与三类事故

复盘结论停在文档里，同类事故还会再来。本文给出四步连接法（重点：缩减到最小复现输入）、三类事故各自的用例形式（体验类也要连）、让连接成为流程的做法与三个反模式。

复盘结论要变成评测用例

事故复盘写得再好 ✗，如果结论只停在文档里 ✔，同类事故还会再来 ✔

（见边界用例库那篇 ✔ —— 这里讲"怎么把复盘变成评测"的具体做法 ✔）。

**把事故复盘与评测集连起来** ✔，是让质量真正提升的关键一步 ✔。

```

① 事件 → 最小复现输入（能触发问题的**最小**样本）

② 期望行为 → 明确定义"正确应该是什么"（可判定 ✅）

③ 归类 → 属于哪一类失败（见失败分类那篇）

④ 入库 → 进评测集冒烟集，每次改动都跑

```

**第 ① 步的"最小"很关键** ✗：直接存线上原样本（几万字 ✔）会让冒烟集跑得慢 ✔；

**缩减到最小** ✔ → 跑得快、定位准 ✔。

| 事故类型 | 用例形式 |

|---|---|

| 格式崩了（下游报错 ✔） | 该输入 + schema 校验断言 ✔ |

| 答错了（事实/编造 ✔） | 该问题 + 期望"拒答或引用原文" ✔ |

| 越权/合规（不该答 ✔） | 越权用例清单（见权限模型 ✔） |

| 体验类（提示误导 ✔） | 断言提示文案含关键信息 ✔ |

**体验类也要连** ✗→✔：它是被投诉最多的一类 ✔，但最容易被排除在评测之外 ✔。

**复盘模板里加一栏**："本事故对应的评测用例（已提交/待提交 ✔）" ✔；

**没有用例不算复盘完成** ✔（与"没有 owner 不算修好"同理 ✔）；

**季度复查**：过去半年的事故，用例都进了吗 ✔？

**复盘只写"加强注意"** ✗（无法执行 ✔）；

**用例只进文档不进流水线** ✗（不会被跑 ✔）；

**用例写了但没有期望行为** ✗（跑起来也不知道对错 ✔）。

> 过去半年的事故 ✔，每一件都能在评测集里找到对应用例吗 ✔？

> 有缺的，说明复盘与评测还是两条平行线 ✗。