一条条看日志，看不出系统性问题
用户问题成百上千 ✔，逐条处理永远处理不完 ✗。
把重复问题聚类 ✔，就能从"处理个案"变成"修一类问题" ✔（收益高一个数量级 ✔）。
一、怎么聚类（三种粒度）
- 按关键词/模板（最便宜 ✔）：把问题归一化后按高频短语分组 ✔
（例如"为什么提示额度不足"出现 200 次 ✔）；
- 按语义相似（中等 ✔）：用嵌入把问题聚类 ✔，适合问法多样但本质相同的情况 ✔；
- 按失败类型（最可靠 ✔）：先按失败类型分类 ✔（见失败分类那篇 ✔），再在类内聚类 ✔。
建议顺序：先做 3（类型）+ 1（关键词）✔ —— 成本低、可解释 ✔；语义聚类留到后面 ✔。
二、聚类结果要能"变成行动"
每个簇要给出五项 ✔：
① 代表样本（3 条原文 ✔）
② 规模（多少条、占比、环比 ✔）
③ 影响（涉及多少用户/多少成本 ✔）
④ 归因（检索？提示词？界面引导？✔）
⑤ 建议动作与验证方式 ✔
只给"Top 10 问题"是不够的 ✗ —— 必须带归因与动作 ✔。
三、三个高频"系统性根因"
- 界面引导不足 ✗（用户在用不合适的入口问问题 ✔ → 改 UI ✔，见用户教育那篇）；
- 数据/文档缺失 ✗（问的东西资料里根本没有 ✔ → 补资料或明确说明范围 ✔）；
- 口径不清 ✗（同一概念系统理解与用户不同 ✔ → 明确术语，见术语一致性那篇 ✔）。
注意：这三类都不是模型问题 ✔ —— 不聚类就永远在调模型 ✗。
四、怎么持续做（一周一次，半小时）
- 导出上周的负反馈与转人工记录（脱敏 ✔）；
- 人工看 30~50 条，标类型 ✔；
- 聚类，取 Top 3 簇 ✔；
- 每簇写一个待办（谁、什么时候、怎么验证 ✔）；
- 下周复查：该簇规模是否下降 ✔。
五、两个反模式
- 只做一次聚类 ✗（问题会变，聚类要持续 ✔）；
- 聚类完没有 owner ✗（报告发了没人管 ✔）。
一条判据
上周的 Top 1 问题簇 ✔，这周规模下降了吗 ✔？
没有下降，说明聚类只是"报告"，没有变成"修复" ✗。