用户反馈堆了八百条没人敢碰——我用AI把它变成一份全组都认的需求清单

一、管理者的老问题：反馈不是没有，是没人能“消化”

如果你带过一个三五人的小团队，大概率经历过这样的场景：

用户反馈散落在应用商店评论、微信群聊天记录、客服工单、问卷表格里。每一条都有价值，但没有人有时间看。让产品经理逐条归类？他上周的排期还没排完。让客服顺手整理？客服只会按“退款”“崩溃”这种表面标签归档，根本到不了“需求”层面。

于是形成了一个尴尬的循环：反馈越积越多，团队越不敢碰，用户觉得“提了也没用”，慢慢就不提了。而真正致命的是——等到版本复盘时才发现，上个月有三条高危问题的反馈早就出现了，只是埋在第四百多条的聊天记录里没人看见。

作为管理者，我关心的不是“AI能不能读文本”这种技术问题，而是三件事：

1. 流程：从原始反馈到可用的优先级清单，中间有几步、每步谁负责；
2. 协作：AI给出的结果，团队怎么验证、怎么达成共识，而不是又多一个互相不服的“意见来源”；
3. 风险控制：AI会不会漏掉关键反馈、会不会幻觉出用户根本没提过的需求。

这篇文章就是把这三件事拆开讲清楚。

二、AI在这个流程里到底能做什么

先说结论：AI不是替你做决策，而是把“不可见”变成“可见”，把“凭印象”变成“凭数据”。具体它能做四件事：

第一，批量清洗与去重。 八百条反馈里，可能有两百条说的是同一件事，只是措辞不同。AI可以把“登录不上了”“一打开就闪退进不去”“auth失败”识别为同一类问题的不同表述，合并成一个需求项，并标注出现次数。

第二，语义归类。 不是按关键词，而是按真实意图归类。用户抱怨“每次都要重新登录”，表面上骂的是登录，真实诉求可能是“希望支持长期会话保持”。这层转译，传统标签系统做不到，AI做得到。

第三，提取隐含的严重程度信号。 “有点卡”和“完全没法用”是两回事；“已经准备卸载了”是流失预警。AI可以按你定义的严重度框架逐条打分，并给出打分依据，方便人工复核。

第四，结构化输出。 最终产出一份可直接进评审会的表格：需求描述、原始反馈引用、出现频次、影响面判断、建议优先级。每个结论都能溯源到原始反馈，这是风险控制的第一道防线——AI的每个判断都可以被追溯和验证。

三、我跑通的完整流程（五步）

第一步：数据集中

把各渠道反馈导出成统一格式（CSV或JSON都行），字段至少包括：时间、渠道、原文、用户标识。这步没有AI什么事，但决定了后面所有环节的质量。垃圾进，垃圾出。

第二步：脱敏

用户反馈里经常夹带手机号、订单号甚至支付信息。在喂给AI之前，先用脚本做一轮正则脱敏，再让AI做一轮兜底检查。这是合规底线，不可省略。

第三步：批量分类与打标

把反馈分批（每批建议50~100条）连同分类框架一起发给模型。注意：分类框架要由人来定义，比如“功能缺陷 / 体验问题 / 新功能诉求 / 商业化相关 / 无效信息”。AI执行你的框架，而不是自己发明框架——这是管理者视角下最重要的一条原则。

第四步：聚类与优先级初评

分类完成后，让AI在同一类目内做语义聚类，统计频次，并按“影响面 × 严重度 × 出现趋势”给出优先级初评。用哪个模型？日常分类用性价比高的快模型即可，聚类和优先级评估这种需要综合判断的环节换强模型——分层用模型，成本能压到很低。具体各模型的费用，以官网价格页为准。

第五步：人工复核与评审

AI输出的是“草案”，不是“结论”。我的做法是：随机抽取10%~15%的条目人工核对分类是否准确；所有被评为P0的项必须点开原始反馈逐条确认。这个复核动作本身就是团队对齐的过程——评审会上大家讨论的是同一份有据可查的清单，而不是各自的印象。

四、可直接复用的提示词模板

# 角色
你是一位资深产品分析师，负责整理用户反馈。

# 输入
- 分类框架：{功能缺陷 / 体验问题 / 新功能诉求 / 商业化相关 / 无效信息}
- 严重度定义：
  - P0：核心功能不可用、数据丢失、涉及资金或隐私风险
  - P1：功能可用但严重受阻，用户明确表达放弃意愿
  - P2：体验受损但有替代路径
  - P3：建议性质，不影响使用
- 用户反馈列表（每条含编号和原文）：{{反馈数据}}

# 任务
1. 将每条反馈归入一个类目；跨类的取最主要的一个，并在备注说明。
2. 对语义相同的反馈进行合并，记录合并条数和各原始编号。
3. 按严重度定义逐条评级，必须引用原文中的具体表述作为评级依据。
4. 输出出现频次≥3次的合并项为“高频问题”。

# 输出格式（Markdown表格）
| 合并项ID | 需求/问题描述 | 类目 | 频次 | 严重度 | 评级依据（原文引用） | 原始反馈编号 | 建议优先级 |

# 约束
- 不得推断用户未明确表达的需求，推测内容需单独标注[推测]。
- 无法判断的条目标记为“待人工复核”，不要强行分类。

最后一条约束是刻意加的。允许AI说“我不知道”，能显著降低它编造结论的概率。

五、用AI前后的对比

最直观的变化不是“快了”，而是争论的性质变了。以前评审会一半时间在争论“用户到底是不是这么说的”，现在直接进入“这个P0这周修还是下周修”。

六、管理者需要盯住的三个风险点

1. 框架漂移：AI偶尔会把边界模糊的反馈归错类。解法是定期（比如每月）人工校准一次分类框架，把典型错例补充进提示词。
2. 幻觉需求：AI可能“总结”出用户没说过的需求。解法就是提示词里那条硬约束加人工抽查。
3. 过度依赖：优先级排序永远保留人工终审权。AI给你的是更好的决策材料，不是决策本身。

---

如果你所在的小团队也想把这条流程跑起来，选一个稳定、支持多模型切换的API平台会省很多事——分类用快模型、评估用强模型的分层策略，需要能灵活调度。可以试试这个平台注册上手：https://api.thistoken.ai/register

---

本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。