用户投诉不是"待办"，是"用例"
"用户说答得不对" ✗ 这种信息无法直接修复 ✔ ——
要把它变成可复现的用例 ✔：固定输入 + 明确期望 ✔，然后才能修、才能验证 ✔。
一、四步转换
① 还原（从日志里取原始输入与输出，见日志那篇）
② 缩小（把输入缩到最小可复现，见复盘连评测那篇）
③ 定期望（正确应该是什么？谁来定？）
④ 入库（进评测集，加断言，进冒烟集）
第 ③ 步最容易含糊 ✗：用户说"不对" ✔，但对的标准是什么 ✔？
→ 必须由业务方确认 ✔（而不是工程师自己猜 ✔ —— 见团队分工 ✔）。
二、三类"用户报告"各自怎么处理
| 类型 | 处理 |
|---|---|
| 事实错误（答错了事实 ✔） | 取原始输入 → 期望"正确事实或拒答" ✔ |
| 理解偏差（答非所问 ✔） | 期望"澄清或按意图回答" ✔ |
| 体验问题（太长/太慢/太啰嗦 ✔） | 转成可测指标（长度/延迟/句数 ✔） |
第三类常被忽略 ✗→✔：它不是"内容错" ✔，因此常被排除在评测之外 ✔ ——
但它占投诉比例很高 ✔（见可读性那篇 ✔）。
三、四个纪律
- 必须带原文（不要只记录"用户说不准" ✔）；
- 必须可复现（用当时的模型/提示词版本重跑 ✔ —— 见可复现那篇 ✔）；
- 必须有 owner ✔；
- 修完要回归（该用例进评测集 ✔ —— 见发布门禁 ✔）。
四、三个反模式
- 把投诉当"个例"忽略 ✗（同一问题往往重复出现 ✔ —— 见问题聚类 ✔）；
- 只改提示词不复现 ✗（改完不知道有没有修好 ✔）；
- 期望由工程师拍 ✗（业务方不认 ✔）。
五、一条判据
上周的用户投诉 ✔，有多少条变成了带期望的评测用例 ✔？
是 0，说明投诉还在"处理个案"而不是"修系统" ✗。