multi-source-signal-synthesiser

多源信号综合技能

综合来自多个来源的用户信号——访谈、支持工单、NPS、应用评论、销售通话——形成统一且加权的洞察简报，揭示潜在需求，而不是停留在表面诉求。

必需输入

如果用户未提供，请向其询问以下信息：

• 信号来源（访谈、支持工单、NPS 原话、应用评论、销售通话、分析数据——可任意组合）
• 数据覆盖的时间段
• 信号所涉及的产品领域或功能（如有范围限定）

来源权重（默认值——根据情境调整）

来源	权重	理由
直接研究（访谈、可用性测试）	5	保真度最高、结构化
支持工单（未经提示主动表达的痛点）	4	真实痛点、未经筛选
NPS 原话	3	覆盖面广，但信息较浅
应用商店评论	2	公开发布、由用户自行选择提交
销售通话摘要	2	经过销售视角筛选
轶事或单条反馈	1	单独来看置信度低

流程

1. 为每条信号标注来源并应用权重
2. 寻找趋同：同一潜在需求是否出现在 3 个或更多来源中
3. 寻找分歧：相互矛盾的信号是否意味着用户细分群体不同
4. 区分表面诉求与潜在需求（例如，“导出更快”可能意味着“我不相信需要时能拿到数据”）
5. 按加权频次对洞察排序
6. 验证——确认每条洞察都有至少 2 种来源类型的证据。若某条洞察仅基于单一来源，请标记为低置信度。

输出结构

用户信号综合——[日期 / 时段]

包含的来源：[按来源列出数量] 处理的信号总数：[n]

洞察 1：[潜在需求，而非功能诉求]

• **置信度：**高 / 中 / 低（基于来源多样性和权重）
• 证据：[各来源中支持该洞察的信号]
• 矛盾信号：[任何相矛盾的证据及其解读方式]
• 对产品的启示：[具体的下一步行动，而非泛泛而谈]

[对排名前 3-5 的洞察重复上述内容]

分歧信号（可能的用户细分）

[指出用户群体确实存在不同需求的情况——明确说明所属细分群体]

数据无法告诉我们的内容

[采取行动前需要进一步研究的空白]

质量检查

• 每条洞察都引用至少 2 种不同的来源类型
• 将表面诉求转化为潜在需求，而非简单复述
• 分歧信号明确指出具体用户细分群体，而非只说“有些用户意见不一”
• 置信度评级与来源多样性和权重一致
• “数据无法告诉我们的内容”部分如实说明数据空白

反模式

• 不要将表面功能诉求原样作为洞察——纳入发现之前，先把每项诉求转化为潜在需求
• 不要将仅由一种来源类型支持的洞察评为高置信度——置信度需要至少两种不同来源类型相互印证
• 不要将所有来源视为权重相同——单条访谈引述与 200 张支持工单中呈现的模式，不能视为同等信号
• 不要将分歧信号合并为单一发现——如果用户细分群体确实有不同需求，请明确指出这些群体，而非将差异平均掉
• 如果关键决策依据的是薄弱数据，不要省略研究空白部分——不标明空白就依据低置信度发现采取行动，会误导产品团队