用途
Voice-of-Customer Miner 用于挖掘公开的客户声音——评论网站、应用商店、Reddit 及从业者论坛、社区版块——以发现未被满足的需求、竞品弱点和用户切换触发因素。它把竞争情报与产品发现衔接起来：无需等待访谈周期，就能获得客户的真实用词。
但公开声音偏向愤怒者和发声者，因此它呈现的每个主题都是待验证的假设，而非结论——输出的最后一站始终是真实对话。
主要能力
- 按“搜索计划 → 来源扫描 → 逐字捕获 → 需求主题 → 所以呢 → 下一步选项”的流程执行。
- 扫描混合声音来源：评论网站（G2、Capterra、TrustRadius）、应用商店、Reddit 及从业者论坛、社区版块、社交帖子。
- 捕获带 URL 的简短真实引用，并标注每个来源的偏差。
- 按需求而非功能归纳主题，使主题可移植到产品发现中。
- 输出固定结构的快照，包含范围、需求主题、竞品弱点、切换触发因素和“所以呢”分析。
- 最后提供恰好四个后续选项。
使用方式
调用时可在技能名称后内联提供上下文（文本、粘贴的上下文或附加的 ARGUMENTS: 行），这些视为已给出的答案，不再重复提问。
若空手而来也可以：技能最多提出 3 个问题（谁的声音、支持什么决策、聚焦主题还是开放扫描），若未回答则基于标注的假设继续。
示例调用：Mine voice-of-customer for [Competitor A] and [Competitor B], focus on onboarding — informs whether our Q1 bet is a migration tool.
流程：
- 认可内联上下文，然后只问未回答的问题（最多 3 个）：
- 谁的声音——你的、竞品的，还是一组？
- 这应支持什么决策？
- 有特定聚焦主题，还是开放扫描？
- 展示 3 条搜索计划——扫描哪些声音来源、如何选择代表性逐字引用、如何将观察与解读分开。除非被修改，否则继续。
- 扫描混合声音来源，捕获带 URL 的简短真实引用，并记录每个来源的偏差。
- 严格按输出模式输出。
输出模式（不得重排）：
Voice-of-Customer Snapshot
1. Scope
Products mined: | Decision supported: | Sources swept: | As-of date:
2. Need Themes
对前 3-5 个主题，每个包含：
Theme: [底层需求，不含解决方案，4 到 8 个词]
- Frequency: [跨来源反复出现 / 集中 / 孤立]
- Verbatim: "[简短真实引用]" — [来源, URL]
- Verbatim: "[简短真实引用]" — [来源, URL]
- Who says it: [角色/细分，若明显——标注]
- Reading: [推断——这暗示了什么]
3. Competitor Weak Points
- [竞品]: [用客户的话描述的弱点；频率；URL]
- [最多 5 条，仅最强证据]
4. Switching Triggers
- [什么把客户推离产品；什么把他们拉过来；标注、引用]
5. So What?
- 3 个机会假设（表述为问题，而非功能）
- 2 个可用于作战卡的弱点（注明证据质量）
- 3 个需在真实访谈中验证的假设 每条：标签、置信度、相关 URL。
最终步骤（恰好提供 4 个选项）：
- 从顶部主题生成发现访谈问题（discovery-interview-prep）
- 将弱点输入竞争作战卡（battle-card-builder）
- 从顶部假设构建机会解决方案树（opportunity-solution-tree）
- 以 Verbose Mode 重新运行并限定到一个主题
接受 1、2、3、4、1 和 2、Verbose Mode 或自定义路径。
适用场景
- 有公开足迹的产品或竞品调研。
- 需要快速获得客户真实用词以支持决策。
- 需要识别竞品弱点和切换触发因素。
- 需要为发现访谈、作战卡或机会解决方案树提供输入。
限制
- 不适用于没有有意义公开足迹的产品（早期阶段、小众企业）——应改用 discovery-interview-prep。
- 不适用于需要私有区域用户声音的场景——应挖掘自己的工单和研究。
- 不适用于需要统计置信度的场景——这是定性主题归纳。
- 公开声音偏向愤怒者和发声者，满意而沉默的大多数从不发帖；每个来源的偏差说明是强制性的。
- 逐字引用必须真实可查，不得编造引用、评分、评论数或评论者角色。
- 频率需诚实说明：跨来源反复出现 ≠ 集中在一个帖子 ≠ 孤立但生动；一个能言善辩的抱怨者不是一个主题。
- 主题不得以功能命名，应按底层需求命名。
- 输出中的“需在真实访谈中验证的假设”部分是通往产品发现的桥梁，不可跳过。
常见陷阱
- 按功能命名主题：按客户指责的功能而非底层需求聚类，会把路线图交给最响亮的 UI 抱怨。
- 逐字引用洗白：转述评论并当作引用。若带引号，必须是真实 URL 上的真实摘录。
- 抱怨放大：把一个生动的一星评论当作主题。频率诚实是纪律：反复出现、集中还是孤立，必须说明。
- 偏差盲视：把评论网站当作普查。愤怒者和发声者被过度采样。
- 跳过验证交接：把主题直接送入路线图。
参考
- autonomous-investigation（工作流）——治理协议
- intelligence-collection-disciplines（组件）——OSINT 评论挖掘来源与偏差技巧
- jobs-to-be-done（组件）——主题应落入的不含解决方案的框架
- discovery-interview-prep（交互）——验证发生的地方
- opportunity-solution-tree（交互）——结构化机会假设
- battle-card-builder（工作流）——消费弱点
改编自 https://github.com/deanpeters/product-manager-prompts 仓库中的 market-intelligence/voice-of-customer-miner-prompt.md。