反馈不是"收集起来看看"
上线后用户会点踩、会改写、会放弃。这些信号**极其宝贵**（它们标出了系统的真实短板），
但如果只堆在日志里，等于没有。要做成**闭环**：收集 → 分类 → 归因 → 修复 → 回归。
一、收集：把反馈接到具体请求
二、分类：把反馈变成失败类型
原始反馈是杂乱的，要归到**有限几类**（数量控制在 8~12 类）例如：
**分类要人工先标 100~200 条**，形成标准后能量化的再自动化。
三、归因：别停在"答错了"
每一类继续往下问：
**归因顺序决定了修复成本** —— 从最便宜的那层往下查。
四、修复与回归
五、定期看两件事
1. **失败类型的分布变化**（不是总量）—— 总量下降但"编造"占比上升，说明质量在恶化；
2. **沉默的失败**：用户没点踩但**直接离开**了 —— 这类信号要靠行为埋点（重试、二次提问、放弃）捕获。
一个最小闭环（一周可跑起来）
1. 反馈接请求 id（半天）；
2. 人工标 150 条，归纳 8 类（一天）；
3. 每周挑占比最高的 2 类做归因与修复；
4. 每条修复进评测集；
5. 周会上只过一张图：**失败类型分布 + 本周修复项**。