想在不做访谈的情况下从公开评论挖掘客户未满足需求…

从公开评论、应用商店和论坛中挖掘客户原声，提炼未满足需求、竞品弱点和切换触发点，并附真实引用证据。

适用场景

解决思路

1. 先利用调用时内联提供的上下文（技能名后的文字、粘贴的上下文或附加的 ARGUMENTS: 行）作为已给出的答案，对照问题预算，不要重复提问。
2. 最多只问 3 个未回答的问题：1) 挖掘谁的客户声音——自己的、竞品的还是一组；2) 这个结果要支持什么决策；3) 是否有特定主题聚焦，还是开放式扫描。若未回答则基于标注的假设继续推进。
3. 展示 3 条要点的搜索计划：将扫描哪些声音来源、如何挑选代表性原声、如何把观察与解读分开。除非被修改，否则继续执行。
4. 混合扫描多种声音来源——评论网站（G2、Capterra、TrustRadius）、应用商店、Reddit 和从业者论坛、社区板块、社交帖子——抓取简短真实引用并附 URL，同时记录每个来源的偏差。
5. 严格按既定 schema 输出，不得重排顺序：1. Scope（挖掘的产品、支持的决策、扫描的来源、截止日期）；2. Need Themes（3-5 个主题，每个含：以需求而非功能命名的 4-8 词主题名、频率标注为跨来源反复出现/集中/孤立、至少两条带来源和 URL 的真实引用、说话者角色或细分（如有则标注）、标注为 Inference 的解读）；3. Competitor Weak Points（最多 5 条，用客户原话描述弱点，附频率和 URL，只保留最强证据）；4. Switching Triggers（什么把客户推离产品、什么把他们拉过来，带标注和引用）；5. So What?（3 条以问题而非功能表述的机会假设、2 条可用于战卡的弱点并注明证据质量、3 条需在真实访谈中验证的假设；每条都带标签、置信度和相关 URL）。
6. 按需求而非功能来归纳主题：把「导出功能坏了」这类功能抱怨转化为「我无法把数据送到团队工作的地方」这类底层需求，使主题可移植进发现流程。
7. 原声引用就是产品本身：使用简短、真实、带引号的客户语言并附 URL，绝不编造引用、评分、评论数或评论者角色。
8. 为每个来源标注已知偏差：评论者偏负面、厂商社区偏忠诚、应用商店过度代表更新引发的愤怒——公开声音是带已知偏差的证据，不是事实真相。
9. 诚实标注频率：区分跨来源反复出现、集中在单一帖子、孤立但生动三种情况，一个能说会道的抱怨者不构成一个主题。
10. 最后一步恰好提供 4 个选项：1) 从首要主题生成发现访谈问题（discovery-interview-prep）；2) 把弱点输入竞品战卡（battle-card-builder）；3) 从首要假设构建机会解决方案树（opportunity-solution-tree）；4) 以 Verbose Mode 重新聚焦单一主题运行。接受 1、2、3、4、1 and 2、Verbose Mode 或自定义路径。

适用边界 · 注意事项

• 目标产品没有有意义的公开足迹（早期阶段、小众企业级）——应改用 discovery-interview-prep。
• 需要自己用户在私有领域的原声——应挖掘自己的工单和研究资料。
• 需要统计置信度——本技能只做定性主题归纳。