---
name: 用户反馈分析
description: >
  上传用户反馈数据（Excel/CSV/文本），自动分类统计并提取高频模式，输出包含情感分析、痛点排序和改进建议的洞察报告。
  支持主题聚类、趋势分析和三角验证，从反馈中提炼用户画像。
  连接~~Notion后报告直接写入知识库。
  当用户说"用户反馈"、"反馈分析"、"用户声音"、"VOC分析"、"NPS分析"、"用户评价分析"、
  "应用商店评论"、"客诉分析"、"用户调研"、"满意度分析"、"差评分析"、"好评分析"、
  "反馈聚类"、"反馈趋势"、"用户画像提炼"时触发。
argument-hint: "上传反馈数据文件或粘贴反馈文本"
name_en: "user-feedback-analysis"
description_en: >
  Upload user feedback data (Excel / CSV / text) for automatic classification, high-frequency
  pattern extraction, sentiment analysis, pain-point ranking, and actionable improvement
  recommendations. Supports topic clustering, trend analysis, and triangulation across data sources.
  Extracts user personas from the feedback data. When connected to ~~Notion the insight report is
  written directly into the team wiki. Trigger when the user says "user feedback", "feedback
  analysis", "voice of customer", "VOC analysis", "NPS analysis", "review analysis", "app store
  reviews", "support ticket analysis", "user research", "satisfaction analysis", "negative reviews",
  "positive reviews", "feedback clustering", "feedback trends", "user persona extraction", "analyze
  feedback".
---

# 用户反馈分析

对用户反馈数据进行结构化分类、情感分析和模式提取，输出可驱动产品决策的洞察报告。内置反馈分类体系、痛点优先级排序模型、主题聚类方法和趋势分析框架。

## 工作方式

**独立能力（无需连接器）**

- 6大类反馈自动分类
- 正面/中性/负面情感判断
- 痛点Top N排序 + 改进建议
- NPS分数计算（如数据含评分）
- 主题聚类（亲和图法 + 主题编码）
- 趋势分析（环比变化 + 拐点识别）
- 三角验证（多源交叉验证）
- 用户画像提炼

**增强能力（连接器加持）**

- ~~Notion → 洞察报告写入产品知识库

## 连接器（可选增强）

| 连接器 | 增强能力 |
|--------|---------|
| **Notion** | 洞察报告写入团队知识库 |

> 没有连接器也完全可以使用。

## 输入要求

| 字段 | 必填 | 说明 |
|------|------|------|
| 反馈数据 | 是 | Excel/CSV文件、粘贴文本、或应用商店评论截图 |
| 分析目的 | 否 | 产品改进/满意度评估/专题分析（如某功能上线后的反馈），默认"产品改进" |
| 时间范围 | 否 | 反馈收集的时间段，用于标注报告时效和趋势分析 |
| 数据来源渠道 | 否 | 如有多渠道数据可标注来源，便于三角验证 |

> **数据规模判断**：<=20条 → **精读模式**（逐条分析，输出详细解读）；>20条 → **统计模式**（自动分类统计，输出聚合报告）。

## 执行流程

### 第一步：数据预处理

解析用户上传的文件或粘贴的文本。

**数据清洗规则**：
- 去除完全重复的反馈
- 合并高度相似的反馈（相似度>90%），标注合并数量
- 超短反馈（<5字且无实质内容，如"好""差"）单独统计，不纳入深度分析
- 若数据含评分列（1-10分或1-5星），自动提取用于NPS计算
- 识别反馈来源渠道（微信客服、钉钉反馈群、App Store评论、小红书评论、知乎问答、飞书反馈表单、400热线工单等）

### 第二步：反馈分类

**反馈分类体系（6大类+判断标准）**：

| 类别 | 判断标准 | 示例 |
|------|---------|------|
| **功能需求** | 用户希望有但目前没有的功能 | "希望能支持批量导出" |
| **Bug报告** | 功能存在但表现异常 | "点击保存后数据丢失了" |
| **使用咨询** | 不知道怎么用，找不到功能 | "怎么修改密码？" |
| **体验吐槽** | 功能有但体验不好 | "加载太慢了""界面太复杂" |
| **正面评价** | 满意、好评、推荐 | "这个功能很好用，推荐！" |
| **其他** | 无法归类或与产品无关 | 灌水、广告、无意义内容 |

分类不确定时（一条反馈可能属于多类），标注主分类+次分类。

### 第三步：情感分析

每条反馈标注情感倾向：

| 情感 | 判断信号 | 校准规则 |
|------|---------|---------|
| **正面** | 点赞、好评、推荐、感谢、表扬 | 仅表述事实的好评（"功能可用"）判为中性而非正面 |
| **中性** | 陈述事实、提问、建议（语气平和） | 功能需求默认中性，除非带有明显不满语气 |
| **负面** | 抱怨、愤怒、失望、威胁 | "希望能支持XX"是中性，"为什么还不支持XX"是负面 |

**情感强度分级**（负面反馈额外标注）：
- **轻度**：语气平和的不满（"不太方便"）
- **中度**：明确表达失望（"很失望""体验很差"）
- **重度**：威胁性表达（"再不修就卸载""要投诉"）→ 高优先级处理

### 第四步：主题聚类

运用两种方法对反馈进行主题聚类，提取核心议题：

**方法一：亲和图法（Affinity Mapping）**

1. **拆分观察点**：将每条反馈中的独立观点拆分为单独的"卡片"
2. **自然聚类**：按相似性将卡片分组，不预设分类标签，让主题从数据中自然浮现
3. **命名主题**：为每个聚类命名（如"支付流程繁琐""搜索结果不相关"）
4. **识别层级**：小聚类归入更大的主题群（如"支付流程繁琐"+"退款周期长" 归入"交易体验"主题）
5. **标注异常值**：无法归入任何聚类的反馈单独标注——这些可能是早期信号

**方法二：主题编码（Thematic Coding）**

1. **开放编码**：逐条反馈标注描述性标签（如"加载慢""闪退""找不到入口"）
2. **轴心编码**：将描述性标签归类为更抽象的主题（"加载慢"+"闪退" → "性能问题"）
3. **选择性编码**：识别核心主题，建立主题之间的逻辑关系
4. **量化频次**：统计每个主题被提及的次数和占比

**聚类输出格式**：

| 主题 | 子主题 | 提及次数 | 占比 | 代表性反馈 |
|------|--------|---------|------|----------|
| {主题1} | {子主题a} | {N} | {X%} | "原文引用" |

### 第五步：NPS分析（如数据含评分）

若反馈数据包含数字评分（1-10分制），自动计算NPS：
- **推荐者**（9-10分）占比 - **贬损者**（0-6分）占比 = NPS分数
- NPS基准参考：SaaS行业平均30-40，消费类App平均20-30
- 5星制评分自动换算：5星=10分，4星=8分，3星=6分，2星=4分，1星=2分

### 第六步：趋势分析（如有时间维度数据）

当反馈数据包含时间信息时，进行趋势分析：

**环比变化计算框架**：
- 按周/月统计各类反馈的数量变化
- 计算环比增长率 =（本期 - 上期）/ 上期 x 100%
- 关注增长率>30%的异常变化，标注为"需关注"

**趋势拐点识别**：
- 监测连续3期以上的单方向变化（持续上升或持续下降）
- 识别突然的方向反转（如负面反馈连续下降后突然上升）
- 关联外部事件：版本发布、运营活动、竞品动态等可能的触发因素

**趋势分析输出**：
- 各类别反馈的时间变化曲线描述
- 显著变化点标注及可能原因
- 预警：哪些指标在恶化、哪些在改善

### 第七步：三角验证

当数据来自多个渠道时，通过交叉验证提升结论可信度：

**方法论三角**：同一问题用不同分析方法验证
- 如：主题聚类发现"加载慢"是Top1痛点 → 检查NPS贬损者的开放回答是否也集中在性能问题

**来源三角**：同一发现在不同渠道的出现情况
- 如：App Store差评提到"闪退" + 微信客服工单也反映"闪退" + 钉钉群用户也提到 → 高可信度
- 仅单一渠道出现 → 标注"单源发现，需进一步验证"

**时间三角**：同一问题在不同时间的持续性
- 持续3周以上的问题 → 系统性问题
- 仅在特定时间出现 → 可能是偶发或已修复

**可信度分级**：
| 等级 | 条件 | 标注 |
|------|------|------|
| **高** | 多渠道+多方法+持续出现 | 可直接驱动决策 |
| **中** | 2种验证维度支持 | 建议补充数据后决策 |
| **低** | 单一来源或单一方法 | 仅作参考，需进一步验证 |

### 第八步：用户画像提炼

从反馈数据中识别典型用户类型：

**画像构建方法**：
1. **行为聚类**：根据反馈内容推断用户类型（新手/老用户/高频用户/偶尔使用）
2. **需求聚类**：哪些用户关注效率、哪些关注体验、哪些关注价格
3. **情感聚类**：忠实拥护者 / 沉默使用者 / 积极抱怨者 / 流失边缘者

**画像模板**：
```
[画像名称]：{一句话描述}
- 典型特征：{使用频率、关注点、行为模式}
- 核心诉求：{最关心什么}
- 主要痛点：{遇到的问题}
- 反馈风格：{倾向如何表达}
- 占比估算：{在反馈数据中的比例}
- 代表性原文："{引用}"
```

> 画像数量控制在3-5个，过多则不具备行动指导意义。

### 第九步：痛点排序

**痛点优先级 = 频次 x 严重度 x 用户权重 x 可信度**

| 维度 | 赋值标准 |
|------|---------|
| **频次** | 高频(>10次)=3, 中频(3-10次)=2, 低频(<3次)=1 |
| **严重度** | 致命(功能不可用)=3, 严重(影响核心流程)=2, 一般(体验不佳但可用)=1 |
| **用户权重** | 付费用户=1.5, 免费用户=1.0（如无用户类型数据则均为1.0） |
| **可信度** | 高(三角验证通过)=1.2, 中=1.0, 低(单源)=0.8 |

按综合分数降序排列，输出Top 10痛点。

### 第十步：生成洞察报告

**如果连接了~~Notion：**
1. 将报告写入团队知识库指定位置

**如果未连接：**
1. 以Markdown格式输出完整报告

## 输出格式

```markdown
# 用户反馈分析报告

**分析期间**：{日期范围}
**反馈总量**：{N}条（去重后{M}条）
**数据来源**：{渠道列表，如"App Store评论、微信客服工单、钉钉反馈群"}

## 一、分类统计
| 类别 | 数量 | 占比 | 环比变化(如有) |
|------|------|------|--------------|

## 二、情感分布
**正面**：{X}%  |  **中性**：{Y}%  |  **负面**：{Z}%
（负面中：轻度{a}条 / 中度{b}条 / 重度{c}条）

## 三、主题聚类
| 主题 | 子主题 | 提及频次 | 占比 | 可信度 |
|------|--------|---------|------|--------|

## 四、NPS分析（如有评分数据）
**NPS分数**：{分数}（推荐者{X}% - 贬损者{Y}%）
**行业基准对比**：{高于/低于}行业平均{差值}分

## 五、趋势分析（如有时间数据）
- 显著上升趋势：{类别}，环比+{X}%
- 显著下降趋势：{类别}，环比-{X}%
- 拐点事件：{描述}

## 六、Top 10 痛点
| 排名 | 痛点描述 | 频次 | 严重度 | 可信度 | 综合分 | 代表性原文 | 产品建议 |
|------|---------|------|--------|--------|--------|----------|---------|

## 七、用户画像
<!-- 3-5个典型画像 -->

## 八、关键洞察
<!-- 每条洞察格式：发现+数据佐证+可信度+意义 -->
1. {洞察1}
2. {洞察2}
3. {洞察3}

## 九、改进建议（按优先级排序）
| 优先级 | 建议 | 关联痛点 | 预期效果 | 验证方式 |
|--------|------|---------|---------|---------|

## 十、统计说明
- 分类置信度：{高/中}（样本量{N}条）
- 存疑分类：{数量}条
- 三角验证覆盖率：{X}%的发现经过多源验证
- 统计有效性：{样本量充足/样本量有限，结论仅供参考}
```

## 质量标准

1. 分类有据——不确定的分类标注置信度
2. 洞察基于数据——每条洞察引用具体数字
3. 改进建议可操作——具体到功能层面
4. 样本量<50条时标注"样本量有限，结论仅供参考"
5. 统计结果用代码执行计算，确保准确
6. 情感判断经过校准规则验证
7. 主题聚类结果互斥且完整（MECE）
8. 三角验证明确标注可信度等级

## 红线规则

1. **不过度推断**：20条反馈中3条提到某问题，不能说"大量用户反馈"
2. **保留原文**：痛点需附代表性原文，确保可追溯
3. **不编造趋势**：无历史数据时不做环比分析
4. **不虚构画像**：用户画像必须基于数据聚类结果，不能凭想象编造

## 输入不足处理

- **反馈数量<10条**：输出逐条详细解读，不做统计分析（样本太少无统计意义）
- **无渠道/时间信息**：正常分析，但标注"缺少数据来源和时间信息，建议补充"；跳过趋势分析和三角验证
- **混杂多语言反馈**：按语言分组分别分析
- **单一渠道数据**：正常分析，但在报告中标注"单一数据源，建议补充其他渠道数据进行交叉验证"

## 反馈量不足时的主动补充策略

当可用反馈<30条时，分析价值有限。建议主动补充数据：

| 补充方式 | 获取周期 | 适用场景 | 预期补充量 |
|---------|---------|---------|----------|
| 应用商店评论爬取 | 即时 | C端产品 | 50-500条 |
| 客服工单导出 | 1天内 | 有客服体系的产品 | 100+条 |
| 产品内嵌反馈弹窗 | 1-2周收集 | 需定向收集某功能反馈 | 视DAU定 |
| 用户1v1访谈 | 1-2周 | 深度挖掘痛点 | 5-10人（质>量） |
| 社交媒体监测 | 即时 | 用户自发讨论多的产品 | 不定量 |

> 原则：先穷尽已有数据源再考虑新增收集，避免"数据不够就做调研"的冲动。

## 反馈渠道参考

中国互联网产品常见反馈渠道（按数据质量排序）：

| 渠道 | 数据特点 | 适合分析维度 |
|------|---------|------------|
| **微信客服/企业微信** | 即时反馈，语境完整，可追问 | 深度痛点分析 |
| **钉钉反馈群/飞书反馈群** | B端用户为主，需求明确 | 功能需求提炼 |
| **App Store/应用宝评论** | 公开评分+文字，量大 | NPS计算、情感分析 |
| **小红书评论/笔记** | 真实体验分享，含竞品对比 | 竞品感知、体验洞察 |
| **知乎问答/讨论** | 深度讨论，专业用户 | 深层需求挖掘 |
| **400热线/工单系统** | 结构化记录，紧急问题 | Bug和紧急痛点 |
| **产品内嵌反馈入口** | 使用中即时反馈，场景明确 | 功能体验优化 |

## 相关技能

- `/需求优先级排序`：将反馈中提取的功能需求 → 用RICE排优先级
- `/PRD生成`：高频需求 → 转化为PRD
- `/竞品分析`：反馈中的竞品提及 → 进一步竞品研究
- `/产品指标复盘`：反馈趋势与产品指标交叉验证
