如何让 AI 分析用户反馈：从原话到问题分类和优先级

用户说了什么，是原始事实；它代表什么问题、影响多大、应该先处理什么，是分析结果。AI 可以帮助整理，但不能把自己的判断伪装成用户原话。

同一条反馈通常包含多个层次：用户描述的现象、表达的情绪、提出的需求和可能的原因。比如“提交后没有反应，我以为失败了”，事实是提交后缺少可见反馈，情绪是困惑，需求是知道处理状态；至于系统是否真的失败，还需要其他证据。

资料中关于信息提取、结构化输出、事实边界和评估的内容，适合直接迁移到用户反馈分析。先保留原文和来源，再做分类、聚类、频率统计和优先级判断，最后才给行动建议。

反馈分析前可以清理格式噪音、重复提交和明显无关内容，但不要过早改写用户原话。原话中的语气、用词和具体场景，可能帮助判断问题严重性和用户真正遇到的障碍。

重复反馈要区分完全重复和同类反馈。相同用户连续提交同一条问题，不应简单算成多个独立用户；不同用户描述相似问题，则可以归入同一问题组，但要保留样本数量和来源范围。

个人信息、订单号和联系方式应先脱敏。反馈中带有截图、日志或内部链接时，标注它们是否被纳入分析。不要为了让 AI 更方便而把无关的敏感信息一起发送。

清理规则要记录下来。删除了什么、合并了什么、哪些反馈被排除，都会影响后面的频率和优先级判断。没有清理记录，分析结果很难复核。

让 AI 对反馈分类时，不要只说“按主题分类”。应先给出类别定义、包含范围、排除范围和边界案例。例如可用性问题关注用户是否能完成操作，内容问题关注信息是否缺失或难以理解，性能问题关注响应时间和稳定性。

分类层级不要过深。第一层可以按问题性质区分，第二层再按具体模块或流程区分。类别太多会让相近问题被分散，类别太少又会让行动方向不清。

一条反馈可能包含多个问题。Prompt 中要说明是只选主类别，还是允许多标签；如果只能选一个，要要求 AI 说明主类别的判断依据；如果没有足够信息，标记待确认，不要强行归类。

分类规则要用测试案例验证。准备几条明确案例、边界案例和无法判断的案例，看模型是否能稳定使用同一规则，而不是根据关键词随意判断。

出现次数是有用信息，但不能直接代表优先级。一个被很多人提到的小不便，可能优先级低于一条出现次数少却会导致数据丢失的严重问题；一个高频反馈也可能来自某个特别活跃的用户群，不能直接代表全部用户。

优先级至少要结合频率、影响范围、严重程度、证据可信度、处理成本和是否存在替代方案。指标不必一开始就复杂，但要让团队知道为什么某个问题排在前面。

严重程度需要有定义。可以分为阻塞核心流程、明显影响使用、局部不便和偏好建议四类，并给出例子。不要只让模型按情绪强弱判断严重程度，愤怒的表达不一定代表影响最大，平静的描述也可能指出严重漏洞。

优先级结论要带范围。可以写“在本批反馈和当前目标用户中优先处理”，不要写成“所有用户都最需要这个功能”。样本有限时，结论必须保留边界。

每个问题组最好都能回到原始反馈。可以记录代表性原话、反馈数量、独立用户数、来源渠道、时间范围和对应的反馈编号。这样团队讨论优先级时，不需要只相信 AI 的一句总结。

样本范围会影响解释。来自客服的反馈可能更集中于遇到问题的人，来自问卷的反馈可能受题目设计影响，来自活跃用户群的反馈不一定代表沉默用户。让 AI 在结论中标注来源渠道和样本限制，避免把方便获得的数据写成总体结论。

如果反馈包含相互冲突的观点，要分别保留。不同用户对同一功能的期待可能不同，说明需要分群或进一步调查，而不是简单取平均。冲突也可能来自不同使用场景。

对于 AI 推断出的原因，要单独标记为假设。原话说明问题，不一定说明根因；建议行动也应该包含验证方法，而不是直接按推测改产品。

好的反馈分析不是把问题列完就结束。每个高优先级问题可以附上建议动作、需要验证的假设、负责人、预期交付物和复查指标。行动不要只写“优化体验”，而要写成可执行的下一步。

如果根因尚未确认，先安排验证。比如检查日志、观察用户完成任务、做小范围可用性测试或补充访谈。不要因为反馈数量多，就跳过原因确认直接开发功能。

建议动作要与问题类型对应。内容问题可能需要补充说明和测试，流程问题可能需要减少步骤，性能问题需要监测和压测，偏好建议则可以进入候选池。AI 可以给出初步分类，最终优先级和资源安排仍需要团队判断。

行动结果还要回到反馈。改动完成后，比较问题频率、成功率和用户反馈是否变化。这样反馈分析才形成闭环，而不是一次性的标签工作。

下面的模板适合分析客服记录、问卷开放题、评论和访谈摘录。使用时应先完成脱敏，并说明样本范围。

示例 Prompt： 任务：分析下面的用户反馈，找出主要问题、影响和下一步建议。 样本范围：反馈来自【渠道】，时间范围是【时间】，涉及【用户或产品范围】；不要把本批样本扩大为全部用户结论。 原话处理：保留代表性原话和反馈编号；区分用户描述的事实、情绪、需求和可能原因；可能原因标记为待验证假设。 分类规则：使用【类别列表】，为每类写清定义和边界；一条反馈允许【单标签或多标签】；无法判断时标记待确认。 优先级：综合独立用户数、出现频率、影响范围、严重程度、证据可信度、处理成本和替代方案；说明排序依据，不要只按情绪或数量排序。 输出：一、样本概览；二、问题分类表；三、代表性原话；四、优先级与依据；五、待验证假设；六、建议动作和验收指标；七、样本限制。 边界：不要补造用户身份、原因或数据；不要把建议写成已经确认的事实。

生成后可以继续要求：请检查每个结论是否能回到原始反馈，是否把少数意见扩大成总体需求，是否混淆频率和优先级，哪些建议需要先验证。

反馈分析的价值，不是生成一张看起来精确的标签表，而是帮助团队更快看见问题、判断影响和安排下一步。原话、分类、频率、严重程度和证据彼此对应，结果才有讨论基础。

AI 可以减少重复整理，但不能替团队决定什么最重要，也不能代替真实用户验证。对高优先级问题，仍应结合日志、行为数据、访谈和实验确认；对低置信度的建议，先保留为假设。

把样本范围、分类规则和优先级依据写进 Prompt，分析结果就能被复核、修改和持续比较。这样，用户反馈不只是零散意见，而会变成一组能推动产品改进的工作材料。