复盘结论要变成评测用例
事故复盘写得再好 ✗，如果结论只停在文档里 ✔，同类事故还会再来 ✔
（见边界用例库那篇 ✔ —— 这里讲"怎么把复盘变成评测"的具体做法 ✔）。
把事故复盘与评测集连起来 ✔，是让质量真正提升的关键一步 ✔。
一、四步连接法
① 事件 → 最小复现输入（能触发问题的最小样本）
② 期望行为 → 明确定义"正确应该是什么"（可判定 ✅）
③ 归类 → 属于哪一类失败（见失败分类那篇）
④ 入库 → 进评测集冒烟集，每次改动都跑
第 ① 步的"最小"很关键 ✗：直接存线上原样本（几万字 ✔）会让冒烟集跑得慢 ✔；
缩减到最小 ✔ → 跑得快、定位准 ✔。
二、三类事故各自怎么连
| 事故类型 | 用例形式 |
|---|---|
| 格式崩了（下游报错 ✔） | 该输入 + schema 校验断言 ✔ |
| 答错了（事实/编造 ✔） | 该问题 + 期望"拒答或引用原文" ✔ |
| 越权/合规（不该答 ✔） | 越权用例清单（见权限模型 ✔） |
| 体验类（提示误导 ✔） | 断言提示文案含关键信息 ✔ |
体验类也要连 ✗→✔：它是被投诉最多的一类 ✔，但最容易被排除在评测之外 ✔。
三、让"连起来"成为流程的一部分
- 复盘模板里加一栏："本事故对应的评测用例（已提交/待提交 ✔）" ✔；
- 没有用例不算复盘完成 ✔（与"没有 owner 不算修好"同理 ✔）；
- 季度复查：过去半年的事故，用例都进了吗 ✔？
四、三个反模式
- 复盘只写"加强注意" ✗（无法执行 ✔）；
- 用例只进文档不进流水线 ✗（不会被跑 ✔）；
- 用例写了但没有期望行为 ✗（跑起来也不知道对错 ✔）。
五、一条判据
过去半年的事故 ✔，每一件都能在评测集里找到对应用例吗 ✔？
有缺的，说明复盘与评测还是两条平行线 ✗。