客户真实需求深度调研

做产品和增长时，最大的陷阱是把“我以为用户需要”当成需求证据。访谈转录堆在网盘里，工单散落在支持系统，NPS 问卷只统计了分数，社区里的真实抱怨没有被系统化整理；等到要改定位、写落地页或判断流失原因时，团队只能凭印象开会。这个技能要解决的问题很具体：把分散的一手与二手资料，转换成可追溯、可分级的洞察，并明确标注证据强度。

它如何工作

1. 先读取现有上下文：若存在 .agents/product-marketing.md（或旧版路径），会先加载，避免重复追问已确认的产品定位与目标用户。
2. 确定研究模式：Mode 1 分析已有资产（销售通话转录、问卷、客服对话、赢单/输单访谈、NPS）；Mode 2 主动进入线上水源地（Reddit、G2/Capterra、Hacker News、Indie Hackers、App Store 低分评论等）采集未过滤表达。多数项目会混合两种模式。
3. 按框架抽取信号：输出六类结构化字段——Jobs to Be Done（功能/情感/社会任务）、痛点、触发事件、期望结果、客户原话、曾考虑的替代方案。问卷会先按客群分层再下结论，工单先分类再分析，不把 bug、困惑、缺失功能与期望错配混为一谈。
4. 综合与分级：跨来源聚类主题，按频率与强度打分；每条洞察标注 High/Medium/Low 置信度，对 12 个月内的新证据加权，并提示样本偏差（如评论者偏重度用户、工单偏问题侧）。
5. 输出可决策文档：可选研究报告、VOC 原话库、画像文档、JTBD 地图、竞品情报摘要或研究缺口分析；没有足够证据时不会硬造画像，而是走代理来源并明确标注为假设。

适用边界与注意点

• 画像至少需要同一细分下 5–10 个独立数据点，不足时只给临时假设。
• 社区抓取受平台规则与访问限制约束，结果应作为线索而非全量统计。
• 不自动安装依赖、改系统权限或执行外部写入；需要发送、发布、部署时会先说明影响并等待确认。
• 凭据仅用于用户指定的官方服务，不回显、不记录、不转发。