把用户报告变成可复现用例：四步转换

投诉不是待办而是用例。本文给出四步转换（还原/缩小/定期望/入库）、三类用户报告各自的处理（体验问题也要转成指标）、四个纪律与三个反模式。

用户投诉不是"待办"，是"用例"

"用户说答得不对" ✗ 这种信息无法直接修复 ✔ ——

**要把它变成可复现的用例** ✔：固定输入 + 明确期望 ✔，然后才能修、才能验证 ✔。

```

① 还原（从日志里取原始输入与输出，见日志那篇）

② 缩小（把输入缩到最小可复现，见复盘连评测那篇）

③ 定期望（正确应该是什么？谁来定？）

④ 入库（进评测集，加断言，进冒烟集）

```

**第 ③ 步最容易含糊** ✗：用户说"不对" ✔，但**对的标准是什么** ✔？

→ 必须由业务方确认 ✔（而不是工程师自己猜 ✔ —— 见团队分工 ✔）。

| 类型 | 处理 |

|---|---|

| **事实错误**（答错了事实 ✔） | 取原始输入 → 期望"正确事实或拒答" ✔ |

| **理解偏差**（答非所问 ✔） | 期望"澄清或按意图回答" ✔ |

| **体验问题**（太长/太慢/太啰嗦 ✔） | 转成可测指标（长度/延迟/句数 ✔） |

**第三类常被忽略** ✗→✔：它不是"内容错" ✔，因此常被排除在评测之外 ✔ ——

但它占投诉比例很高 ✔（见可读性那篇 ✔）。

1. **必须带原文**（不要只记录"用户说不准" ✔）；

2. **必须可复现**（用当时的模型/提示词版本重跑 ✔ —— 见可复现那篇 ✔）；

3. **必须有 owner** ✔；

4. **修完要回归**（该用例进评测集 ✔ —— 见发布门禁 ✔）。

**把投诉当"个例"忽略** ✗（同一问题往往重复出现 ✔ —— 见问题聚类 ✔）；

**只改提示词不复现** ✗（改完不知道有没有修好 ✔）；

**期望由工程师拍** ✗（业务方不认 ✔）。

> 上周的用户投诉 ✔，有多少条变成了**带期望的评测用例** ✔？

> 是 0，说明投诉还在"处理个案"而不是"修系统" ✗。