从完整的原始记录开始
不要只导入客服标签或 AI 摘要。保留原始文字、会话上下文、来源、时间、用户与账户标识、产品版本，以及任何能够定位真实事件的引用。后续分类会变，但原始证据不能重新生成。
先明确分析窗口和问题：是在寻找本周回归、下一季度需求，还是流失风险？没有决策问题，分析很容易变成无边界的主题整理。
统一结构，但不要抹平差异
- 用户想完成的工作与预期结果。
- 实际问题、严重程度和发生频率。
- 当前替代方案、成本与后果。
- 用户、账户、套餐与业务价值。
- 产品页面、版本、设备、模型或 Trace。
- 来源和原始证据链接。
同义词可以归一化，但不要让多个不同工作流只因为使用了相似词语就被合并。
分析的目标不是得到最少的主题，而是得到足够稳定、能够支持决策的主题。
从问题与工作流形成主题
主题应描述一个具体问题，而不是宽泛标签。与其使用“导出”，不如使用“财务团队无法把每周 2,000 条记录批量导入 ERP”。后者包含受影响者、工作流和限制，更容易判断解法。
先对小样本人工编码，形成分类词典和边界例子，再让 AI 扩展到更多记录。保留“其他”和“不确定”，不要强迫所有反馈进入已有框架。
把数量放回客户与产品上下文
提及次数不能独立代表优先级。统计独立用户和账户，检查套餐、收入、生命周期、工作流和版本分布。十条来自同一事故的消息，不等于十个独立客户都遇到了问题。
结合产品行为、支持量、流失、版本发布与 AI 运行信息，判断反馈是长期缺口、短期事件还是新回归。任何相关性都应标为假设，直到证据足够。
用反例和原始证据验证结论
- 打开每个高价值主题的代表性原话。
- 检查是否存在被错误合并的反例。
- 确认影响来自多个独立用户或账户。
- 查看不同用户群、来源和时间窗口是否一致。
- 记录证据置信度与仍然缺失的信息。
- 让熟悉客户和系统的负责人复核。
AI 可以提出主题，但不能把推测写成事实。所有影响判断都必须能回到明确数据或客户证据。
最常见的分析错误
只看数量忽略严重程度、客户价值和同一事件造成的重复。
只看摘要无法检查语境、反例和模型是否夸大。
分类过早在理解用户目标前，把反馈塞进内部标签。
没有时间维度把长期问题和刚发生的回归混在一起。
没有行动报告写得很好，却没有负责人、决定和复查日期。