反馈不是"收集起来看看"
上线后用户会点踩、会改写、会放弃。这些信号极其宝贵（它们标出了系统的真实短板），
但如果只堆在日志里，等于没有。要做成闭环：收集 → 分类 → 归因 → 修复 → 回归。
一、收集：把反馈接到具体请求
- 每条反馈必须带上请求 id（否则无法定位当时的输入、模型版本、检索结果）；
- 记录反馈类型：点踩 / 改写 / 放弃 / 转人工；
- 记录上下文（用了哪个入口、第几轮、是否走了降级）；
- 给用户一个可选的文字说明入口（哪怕一句话，价值很高）。
二、分类：把反馈变成失败类型
原始反馈是杂乱的，要归到有限几类（数量控制在 8~12 类）例如：
- 事实错误 / 编造；
- 漏答（该说的没说）；
- 格式不符（要 JSON 给了散文）；
- 理解偏差（答非所问）；
- 延迟不可接受；
- 语气/长度不合预期。
分类要人工先标 100~200 条，形成标准后能量化的再自动化。
三、归因：别停在"答错了"
每一类继续往下问：
- 输入是否清楚？（需求本身模糊 → 加澄清机制）
- 检索是否给对了片段？（片段不足导致的错不该记在生成头上）
- 提示词是否约束不足？（格式类问题多半在此）
- 模型能力不足？（换模型是最后手段）
归因顺序决定了修复成本 —— 从最便宜的那层往下查。
四、修复与回归
- 每次修复都要转成一条评测样本（否则同类问题会再犯）；
- 修复后跑评测集（见"评测集接进流水线"那篇），确认没有引入新问题；
- 记录"修复前/后"的失败率变化，用数据说明有效。
五、定期看两件事
- 失败类型的分布变化（不是总量）—— 总量下降但"编造"占比上升，说明质量在恶化；
- 沉默的失败：用户没点踩但直接离开了 —— 这类信号要靠行为埋点（重试、二次提问、放弃）捕获。
一个最小闭环（一周可跑起来）
- 反馈接请求 id（半天）；
- 人工标 150 条，归纳 8 类（一天）；
- 每周挑占比最高的 2 类做归因与修复；
- 每条修复进评测集；
- 周会上只过一张图：失败类型分布 + 本周修复项。