voice-of-customer-miner

客户之声挖掘器

目的

从公开渠道挖掘客户之声——评价网站、应用商店、Reddit 和从业者论坛、社区版块——以发现未满足的需求、竞争对手的弱点和促使客户转向的因素：**搜索计划 → 来源扫描 → 原话摘录 → 需求主题 → 所以呢 → 后续选项。**这连接了竞争情报与产品发现：无需等待一轮访谈，就能获取客户的原话。 但公开声音往往偏向愤怒和善于发声的人，因此它提炼出的每个主题都是有待验证的假设，而非定论——最终产出始终要落到一次真实对话上。

输入

效果最佳的输入：要挖掘的产品或竞争对手（可以是你的、竞争对手的，或一组），以及这项分析应为哪项决策提供依据。 **也有帮助：**你想聚焦的主题（入门引导、定价、可靠性）；如果没有，就进行开放式扫描。

在调用时内联提供的输入——技能名称之后的文本、粘贴的上下文，或追加的 ARGUMENTS: 行——都视为已回答的问题。将其计入问题预算；不要重复询问。

**空手而来也没关系。**该技能最多会先提出 3 个问题（要听取谁的声音、要为哪项决策提供依据、指定主题还是开放式扫描），如果没有得到回答，则基于明确标注的假设继续。

调用示例： 为[竞争对手 A]和[竞争对手 B]挖掘客户之声，聚焦入门引导——为我们的 Q1 重点是否应开发迁移工具提供依据。

关键概念

• **主导协议：**遵循 autonomous-investigation 合约——问题预算为 3、搜索计划关卡、事实／推断／假设标签、适度模式、稳定的架构，以及包含 4 个选项的最终步骤。执行准则：OSINT 的评价与社区层（参见 intelligence-collection-disciplines）。
• 按需求归纳主题，而非按功能。“导出功能坏了”是对功能的抱怨；“我没法把数据放到团队工作的地方”才是潜在需求。按需求归纳主题，秉持与 JTBD 和痛点风暴相同的无预设解决方案原则，也因此能将主题迁移到产品发现中。
• **原话就是成果。**附带 URL 的简短、真实客户引述。原话能教会你用户画像的语言：客户使用的确切措辞，可以转化为访谈探查问题和定位文案。 切勿捏造引述、评分、评价数量或评价者角色。
• **每个来源都有已知偏差。**评价者往往更倾向于负面；供应商社区往往忠于供应商；应用商店中的评价过度代表对更新的不满。记录每个来源的偏差——公开声音是带有已知偏差的证据，而非绝对真相。
• **如实描述频率。**多个来源中反复出现 ≠ 集中于一个讨论串 ≠ 孤立但令人印象深刻。明确说明属于哪种情况；一个表达清晰的吐槽者不能代表一个主题。
• **不适用的情况：**没有有意义的公开信息（早期阶段、细分企业市场）→ 改用 discovery-interview-prep；你需要了解私有渠道中自己用户的声音 → 挖掘自己的工单和研究资料；需要统计置信度 → 这是定性主题归纳。

应用

1. **计入内联上下文，**然后只询问尚未回答的问题（最多 3 个）：
   1. 要听取谁的客户之声——你自己的、竞争对手的，还是一组对象？
   2. 这项分析应为哪项决策提供依据？
   3. 有没有要聚焦的特定主题，还是进行开放式扫描？
2. 展示包含 3 条要点的搜索计划——将扫描哪些声音来源、如何选择有代表性的原话，以及如何区分观察与解读。除非用户要求修改，否则继续执行。
3. 扫描多种声音来源——评价网站（G2、Capterra、TrustRadius）、应用商店、Reddit 和从业者论坛、社区版块、社交媒体讨论串——摘录附带 URL 的简短真实引述，并注明每个来源的偏差。
4. 严格按下方架构输出。

输出架构（不得调整顺序）

# Voice-of-Customer Snapshot

## 1. Scope
**Products mined:** | **Decision supported:** | **Sources swept:** | **As-of date:**

## 2. Need Themes
For each of the top 3-5 themes:
### Theme: [Underlying need, solution-free, 4 to 8 words]
- **Frequency:** [recurring across sources / concentrated / isolated]
- **Verbatim:** "[short real quote]" — [source, URL]
- **Verbatim:** "[short real quote]" — [source, URL]
- **Who says it:** [role/segment, if evident — labeled]
- **Reading:** [Inference — what this suggests]

## 3. Competitor Weak Points
- **[Competitor]:** [weakness in customers' words; frequency; URL]
- [Max 5, strongest evidence only]

## 4. Switching Triggers
- [What pushes customers off a product; what pulls them; labeled, cited]

## 5. So What?
- **3** opportunity hypotheses (phrased as problems, not features)
- **2** battle-card-ready weaknesses (with evidence quality noted)
- **3** assumptions to validate in real interviews
Each bullet: label, confidence, URL where relevant.

此架构的可复制填写版本（含质量检查）位于 template.md。

最后一步（恰好提供 4 个选项）

1. 根据首要主题生成探索访谈问题（discovery-interview-prep）
2. 将弱点整理成竞争对战卡（battle-card-builder）
3. 根据首要假设构建机会解决方案树（opportunity-solution-tree）
4. 限定为一个主题，以详细模式重新运行

接受 1、2、3、4、1 and 2、Verbose Mode 或自定义路径。

示例

恰到好处的主题（虚构产品，示例性引述）：

主题：合同到期时导出历史数据

• **频率：**反复出现——过去 6 个月内，两个站点上有 9 条评论，另有一条论坛帖子
• 原文引述：“导出过程提交了三张支持工单，还是漏掉了自定义字段”——[G2 风格评论，URL]
• 原文引述：“我们比预期多留了一年，因为离开就意味着丢失审计记录”——[论坛帖子，URL]
• **发言者：**拥有 50-200 名员工的企业中的运营经理——推断（评论者头衔仅在有显示时参考）
• **解读：**离开阻力正演变为非自愿留存——推断；若竞争对手能实现轻松迁移，就能把这道护城河变成促使客户流失的诱因。

请注意，主题名称不包含任何功能（“导出工具”）——它描述的是需求，因此探索可以研究评论中从未设想过的解决方案。

请参阅 examples/sample.md，了解完整的挖掘示例（虚构的 FSM 软件市场）：其中，频率方面的严谨判断将一个鲜明的主题评为低置信度，并将每个来源的偏差作为解读指引。examples/sample-industrial.md 展示了声音稀少的情况——当市场几乎不发布评论时，如何诚实地进行挖掘。

常见陷阱

• 以功能名称划分主题。 按客户归咎的功能而非其背后的需求进行聚类，会让最响亮的界面抱怨左右你的路线图。
• 篡改原文引述。 改写评论后却加上引号。凡是加了引号的内容，都必须是来自真实 URL 的真实摘录——这个领域设立“严禁编造”清单，正是因为伪造客户引述既诱人又有害。
• 放大咆哮。 把一条鲜明的一星评论说成一个主题。频率方面的严谨判断是一项原则：要说明它是反复出现、集中出现还是孤立出现。
• 忽视样本偏差。 把评论网站当作普查数据来阅读。愤怒且爱发声的人被过度采样；满意却沉默的大多数从不发帖。必须为每个来源注明偏差。
• 跳过验证交接。 直接把主题放进路线图。输出中的“待在真实访谈中验证的假设”部分是通往探索的桥梁——请善加利用。

参考资料

• autonomous-investigation（工作流）——主导流程的协议
• intelligence-collection-disciplines（组件）——OSINT 评论挖掘来源与偏差处理技巧
• jobs-to-be-done（组件）——主题应采用的无解决方案预设表述方式
• discovery-interview-prep（交互式）——进行验证的环节
• opportunity-solution-tree（交互式）——梳理机会假设
• battle-card-builder（工作流）——使用这些弱点
• 改编自 market-intelligence/voice-of-customer-miner-prompt.md，源自 https://github.com/deanpeters/product-manager-prompts 仓库。