差评堆了三百条没人看？先别急着让AI“总结一下”
先说三个我亲眼见过的失败做法
失败做法一：把差评直接丢给AI，让它“总结一下”。 一个做笔记应用的朋友，把应用商店里两百多条一星评论复制粘贴给某个聊天机器人，得到的结果是：“用户主要对稳定性和功能有意见。”这话没错，但等于没说。他把这份“正确的废话”转发到群里，三天后没人再提这事。
失败做法二：让AI自己发明优先级。 有人接着追问“哪些问题最优先解决”，AI很配合地排出了一二三。问题是，它根本不知道你的用户规模、留存数据和技术债，排出来的优先级本质上是随机数。团队照着做了一个月的“AI认为最重要”的功能，次月留存纹丝不动。
失败做法三：一次性全量投喂。 还有人写脚本把几千条评论一次性塞进上下文，结果模型只认真看了开头和结尾，中间大量样本被“稀释”，输出的清单覆盖面还不如人工抽读一百条。
这三个做法的共同点是：把AI当成一个会说话的垃圾桶——倒进去，等它吐出结论。差评提炼恰恰是最不能这么干的场景，因为差评的价值不在“总结”，而在“拆解”：同一条“用着用着就闪退”背后可能是三个完全不同的bug。
差评到底难在哪
对独立开发者和小团队来说，差评处理的痛点很具体：
- 量大且脏：有真实bug报告，有情绪宣泄，有竞品水军，有“一星因为忘了密码”这种无效信息，混在一起。
- 表述模糊：用户不会说“内存泄漏”，他们说“越用越卡”。你得做一层翻译。
- 一个人身兼数职：没有专职用户研究员，看差评永远是“有空再说”，于是永远没空。
- 人读差评会emo：连续看五十条骂声之后，人会进入防御状态，要么全想反驳，要么全想忽略。
这四条里，前三条恰恰是AI擅长的：脏数据分类、模糊表述归一化、大批量不厌其烦地读。第四条AI还有个隐藏优势——它没有自尊心，骂得再狠它也只是个样本。
正确路径：把提炼拆成四步流水线
正确的做法不是“总结”，而是把差评当作原料，跑一条四步流水线：
第一步：清洗去噪。 先让AI把无效信息（与产品无关、单纯情绪、疑似水军）剔除，只留有效反馈。这一步单独做，不要和后面混在一起——混在一起的结果就是失败做法一。
第二步：逐条结构化。 对每条有效差评提取：问题描述、涉及功能模块、用户场景、严重程度信号（是否影响付费、是否导致流失、是否可复现）。这一步输出的是卡片，不是段落。
第三步：聚类合并。 把结构化卡片按问题聚类——“越用越卡”“开一会儿就发热”“切回来要重新加载”可能指向同一个内存问题。AI在这一步的价值是发现人类凭直觉发现不了的关联。
第四步：人工定优先级。 把聚类结果交给人，结合你手里的数据（留存、付费、技术成本）排序。AI给信息，人给判断。
一个可以直接复制的提示词模板
第二步的核心提示词，我经过十几轮迭代后固定成这样（用于第二步，配合你的功能模块清单使用）：
你是一名产品分析师。我会逐条提供用户差评，请对每条做结构化提取。
我们的产品功能模块清单如下：
【在此粘贴你的模块清单，如：编辑器 / 同步 / 导出 / 支付 / 通知……】
对每条差评，输出以下JSON：
{
"raw": "差评原文",
"valid": true/false, // 是否为有效产品反馈（无效=纯情绪宣泄/与产品无关/疑似刷评）
"issues": [
{
"module": "对应功能模块，无法对应则填'未分类'",
"problem": "用产品术语重述问题，如'越用越卡'→'长时间使用后性能下降'",
"scenario": "用户使用场景，原文没提则填'未知'",
"severity": "high/medium/low",
"churn_risk": "high/medium/low" // 根据语气判断流失风险
}
],
"quote_signal": "是否提及退款/卸载/转向竞品，是则引用原话，否则填null"
}
注意：
- 一条差评可能包含多个问题，全部提取，不要合并
- severity的判断标准：功能不可用=high，体验明显受损=medium，建议/吐槽=low
- 不要自行推断用户没说的事实跑完第二步后，聚类步骤再单独用一个提示词：“以下是N张结构化问题卡片，请按根因聚类，输出每类的名称、包含卡片数、代表原文、可能的产品侧解释。”两步分开，效果远好于一步到位。
关于成本：几千条差评分批跑这一套流水线，token消耗完全在个人开发者可接受范围内，具体以你所用的模型服务官网价格页为准。如果通过统一的API网关调用多个模型，成本和用量还会更透明一些。
用AI前后的对比
之前：两百条差评，团队“打算看看”，两周没人动。最后产品经理花一个下午抽读三十条，凭印象写下五条改进项，其中两条其实只各被一个用户提到过。
之后：同样的两百条差评，流水线半小时跑完，去掉四十一条无效信息，剩余的聚成九个问题类，其中三个类合计覆盖了超过一半的差评——而这三类在之前那份“凭印象”清单里一条都没有，因为它们的表述太分散，单条看都不起眼。
更重要的是流程本身的变化：以前看差评是一次性的苦役，现在变成了一条可以每周自动跑的流水线。新差评进来，增量并入已有聚类，问题清单变成一个活文档，而不是一份发完就沉底的报告。
还有个意外的收获：把结构化清单（去掉人身攻击部分）同步给开发时，沟通效率明显提高——“编辑器模块，长文档场景下性能下降，提及卸载的有7人”比“用户说太卡了”好用十倍。
最后
差评是用户免费给你的、最诚实的产品咨询报告，只是它用的是愤怒的语气写的。AI把“读两百条骂声”从一件没人愿意做的事，变成半小时的流水线作业——这不是替代你判断，而是把你的判断力用在排序上，而不是消耗在阅读耐力上。
如果你还没开始用AI处理这类任务，可以先注册一个统一的模型调用平台，把流水线跑起来再说：https://api.thistoken.ai/register
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。