用户访谈 → 需求提炼 — 从录音到需求清单

    📊 页面导航

    适用角色与上手难度

    角色推荐度上手难度
    📦 产品★★★★★★☆☆☆☆
    🛠️ 开发★★★☆☆★★☆☆☆
    🧪 测试★★★☆☆★★☆☆☆

    🎯 学习产出： 掌握 Agent 文本分析模式，能独立将用户访谈转录稿交给 Agent 做痛点聚类、优先级排序和需求提炼

    🚀 AI 能力提升： 定性分析、需求提炼

    场景概述

    预计阅读时间: 14 分钟

    产品团队上周做了 5 场用户访谈，每场 30 分钟，录了音、转了文字——5 份 Word 文档，合计约 2.5 万字。按传统流程，PM 需要逐份通读、标黄重点、手动归纳痛点、写纪要、整理需求清单。这个过程至少半天，质量还严重依赖 PM 的阅读理解能力——疲劳时最容易发生的事就是漏掉某位用户第 28 分钟随口说的那个关键痛点。

    更隐蔽的问题是频次幻觉：PM 通读 5 份访谈后，印象最深的往往是最情绪化的那位用户，而不是提到次数最多的那个痛点。用户 A 用 10 分钟痛骂"导出功能太烂"比用户 B/C/D 每人提一句"搜索不太准"更容易被记住，但后者的用户基数可能是前者的 3 倍。

    Agent 在这个场景中的角色是不带情绪的文本分析引擎：读完全部转录稿 → 逐条提取痛点 → 按频次聚类排序 → 标注引文来源 → 输出优先级建议。PM 省下的是"读文本 + 标重点 + 归纳"的体力活，保留的是"判断这个需求要不要做、做到什么程度"的决策权。

    为什么用 Agent 做访谈分析

    对比维度人工分析Agent 分析
    耗时3-5 小时（读 + 标注 + 归纳）1-3 分钟（审查 + 调整）
    频次统计凭印象，容易受情绪化表达误导精确频次统计，每条痛点标注提到的人数
    遗漏风险后半段注意力下降，容易漏末尾信息全量覆盖，不会越读越粗
    可追溯性通常只记结论，忘记是哪个用户说的每条需求附引文来源（用户编号 + 段落位置）
    一致性同一个人两次分析结论可能不同同样的 transcript 输入 → 同样的输出

    核心边界：Agent 负责"提取"和"聚类"，PM 负责"判断"和"决策"。Agent 不会替你判断"这个需求重不重要"——它告诉你谁说了什么、说了几次、在什么上下文说的，判断仍在你手里。

    前置准备

    • 转录稿完整：5 份访谈转录稿，Word 或纯文本均可。每份标注用户编号（U1/U2/...）和用户画像（角色、行业、使用时长）
    • 分析维度已定：建议至少包含——痛点类型、频次、严重程度（用户自己的用词）、是否有 workaround、竞品是否已解决
    • 优先级划分标准：如"P0 = 3 人以上提及 + 无 workaround""P1 = 2 人提及或有 workaround""P2 = 1 人提及"
    Tip

    如果转录稿质量差（ASR 错误多），先让 Agent 做一次"文本清理"——修正明显的语音识别错误。垃圾进垃圾出在访谈分析中尤其致命。

    完整交互过程

    Step 1：把转录稿和分析要求一起给 Agent

    你是一位资深产品经理。请分析以下 5 份用户访谈转录稿，提炼需求。

**分析要求**
1. 逐份阅读，提取每位用户提到的所有痛点和期望
2. 对痛点进行聚类（相同或高度相似的归为一类）
3. 按提及频次排序输出需求清单（3 人以上 > 2 人 > 1 人）
4. 每条需求附引文来源（用户编号 + "原文摘录"）
5. 标注用户是否有 workaround（说明他们现在怎么凑合用的）
6. 按 P0/P1/P2 给出优先级建议

**优先级标准**
- P0：3 人以上提及 + 无有效 workaround — 必须解决
- P1：2 人提及 或 有 workaround 但体验差 — 本季度解决
- P2：1 人提及 — 放入 backlog，观察后续反馈

---
[转录稿 1] 用户 U1 | 角色：运营经理 | 使用时长：8 个月
...（转录内容）...

[转录稿 2] 用户 U2 | 角色：产品经理 | 使用时长：3 个月
...（转录内容）...

...（其余 3 份转录稿）...

    Step 2：Agent 输出结构化需求清单

    Agent 的输出格式：

    ## 用户访谈需求提炼报告

分析范围：5 份访谈转录稿 | 用户画像：运营经理(1)、产品经理(2)、市场(1)、技术(1)
分析日期：2026-07-06

---

### 需求清单（按频次降序）

#### P0 — 3 人以上提及，无有效 workaround

**需求 #1：批量操作功能缺失**
- 提及人数：4/5（U1, U2, U4, U5）
- 痛点描述：用户需要对多条数据执行相同的操作（如批量打标签、批量修改状态），
  目前只能逐条处理，50 条数据要操作 50 次
- 引文来源：
  - U1："我每周一要处理上周的全部反馈，一条一条点，点到手酸"
  - U2："批量打标签是刚需，按目前的逐条操作我们宁愿不做"
  - U4："竞品 Notion 可以选中多行一次性改属性，你们为什么不行"
  - U5："我们的客服团队每天处理 100+ 工单，批量操作能省一半时间"
- 当前 workaround：无。用户要么逐条手点，要么不做
- 建议优先级：P0

**需求 #2：搜索精准度不够**
- 提及人数：3/5（U1, U2, U3）
- 痛点描述：全文搜索返回大量无关结果，不支持字段级搜索和筛选组合，
  "搜一个标题关键词可能翻 3 页才找到"
- 引文来源：
  - U1："搜'Q3 规划'能出来 47 个结果，只有第 3 个是我要找的"
  - U2："搜索不支持筛选，比如搜'需求'时不能限制只搜标题"
  - U3："中文分词太差了，搜'会员'找不到'VIP 会员卡'那条数据"
- 当前 workaround：用户自己维护目录结构来减少搜索依赖，但维护成本高
- 建议优先级：P0

---

#### P1 — 2 人提及

**需求 #3：通知粒度不可控**
- 提及人数：2/5（U2, U4）
- 痛点描述：项目更新通知只有"全开"和"全关"两档，用户需要"只看和我相关的更新"
- 引文来源：
  - U2："一天 20 条通知，19 条和我无关，但我不敢关——怕错过 @我的那条"
  - U4："希望可以设置'仅我负责的页面变更时通知我'"
- 当前 workaround：关了通知，手动定期刷项目页——体验差但能用
- 建议优先级：P1

**需求 #4：移动端体验差**
- 提及人数：2/5（U1, U5）
- 痛点描述：移动端只能查看，无法编辑，表格列在手机上挤成一团
- 引文来源：
  - U1："上厕所刷到老板的评论想回一下，发现手机只能看不能回"
  - U5："移动端的表格就是个笑话，根本看不了"
- 当前 workaround：记住要改的内容，回到电脑前再处理
- 建议优先级：P1

---

#### P2 — 1 人提及（进入 backlog）

| # | 需求 | 用户 | 摘录 |
|---|------|------|------|
| 5 | 暗色模式 | U3 | "晚上加班用，白底太刺眼了" |
| 6 | Markdown 导出 | U2 | "想导出成 Markdown 发到 GitHub" |
| 7 | 快捷键自定义 | U1 | "Ctrl+B 加粗我是知道的，但想加个删除线的快捷键" |

---

### 统计摘要

| 指标 | 数值 |
|------|------|
| 原始痛点（去重前） | 23 条 |
| 聚合后需求 | 7 项 |
| P0（必须做） | 2 项 |
| P1（本季度） | 2 项 |
| P2（backlog） | 3 项 |

    Step 3：PM 逐条审核，甄别误判

    Agent 输出不是最终答案。PM 需要逐条确认：

    • 频次统计是否准确：打开转录稿抽样验证 Agent 标注的引文位置是否确实提到了相应痛点
    • 聚类是否合理：Agent 可能把两个本质不同的痛点归为一类，也可能把一个痛点的两种表述分成两类
    • 优先级建议是否符合产品策略：P0/P1/P2 的分界线是 PM 的业务判断，不是 Agent 的统计结果

    审核确认后的需求直接导入产品 backlog，每条需求自带用户引文——开发接到需求时知道"这是 U1/U2/U4 三个真实用户说的"，而非"PM 拍脑袋想的"。

    要点总结

    1. 转录稿质量决定分析质量。如果 ASR 准确率不到 90%，宁可用 Agent 先做文本清理再分析，也不要直接把满是错误的文本扔进去。
    2. 频次比情绪重要。Agent 按频次排序能对冲"最情绪化的用户被误认为最重要的用户"的认知偏差——这是人工分析最难做到的。
    3. 引文来源是 Agent 分析的不可替代价值。手工分析通常只记结论忘了来源，Agent 分析每条需求都有原文摘录——开发、设计、测试都能追溯原始用户声音。
    4. P2 不是"不做"。只有 1 人提及的需求可能是小众刚需，也可能是趋势信号。定期回顾 backlog 中的 P2 项，看是否有新增反馈让它们升级为 P1。
    5. Agent 不替你决策。它能做到的是"3 个用户提到搜索不好用"，不会替你说"所以我们应该用 Elasticsearch"。决策权永远在 PM 手里。

    变体与延伸

    • NPS 开放反馈分析：把 NPS 问卷中的"为什么打这个分"的开放文本交给 Agent，按主题聚类，找到 Promoter 的共性和 Detractor 的共性问题
    • 客服工单分析：把最近 200 条客服工单交给 Agent，按问题类型聚类，输出高频问题 TOP10 + 每条附典型工单编号
    • 竞品评价分析：把某竞品在 G2/Capterra/应用商店的 50 条评价交给 Agent，按好评/差评分类，提炼出竞品的核心优势和核心弱点
    • 内部调研分析：把团队内部问卷（如开发体验调研、技术债感知调研）的开放问题交给 Agent，聚类出团队的真实痛点

    每次输入从"代码文件"变成"文本数据"，但 Agent 的使用模式完全一致。

    相关场景