discover-interview-synthesis

访谈综合分析

访谈综合分析会将原始用户研究数据转化为结构化洞察，推动产品决策。好的综合分析不会只是罗列参与者说了什么，而是会找出不同对话中的模式，将观察结果与潜在的用户需求联系起来，并把研究发现转化为可执行的建议。

适用场景

• 完成一轮用户访谈后（通常为 5 位或以上参与者）
• 完成客户探索访谈或销售反馈会议后
• 完成可用性测试后，整合观察结果
• 利益相关者需要研究发现摘要时
• 开展构思会议前，让团队立足于真实的用户情况

不适用场景

• 你要为参会者总结一次内部会议 -> 使用 foundation-meeting-recap
• 你需要梳理多次会议在一段时间内形成的模式 -> 使用 foundation-meeting-synthesize
• 你的数据来自问卷，而非访谈 -> 使用 measure-survey-analysis
• 研究发现已经综合完成，你准备好界定问题 -> 使用 define-problem-statement
• 你已综合研究发现，并希望将其映射到客户跨越不同阶段和触点的旅程中 -> 使用 discover-journey-map

说明

收到综合访谈发现的要求时，请按以下步骤操作：

1. 收集原始材料 收集所有访谈笔记、转录稿或录音。确保至少有 3 位参与者的数据，以便找出有意义的模式。记录研究目标和所采用的方法。

2. 创建参与者档案 记录每位参与者的相关背景信息：其角色、细分群体、任职时长及任何值得注意的特征。这有助于读者评估研究发现的代表性。

3. 找出反复出现的主题 通读所有笔记，并按主题标记观察结果。寻找在多位参与者中反复出现的主题（理想情况下为 3 位或以上）。区分频繁提及的话题和个别评论。

4. 摘录有意义的引述 每个主题摘录 3-5 条原话，有力地阐明洞察。好的引述具体、富有情感或表达特别清晰。务必注明引述对应的参与者 ID。

5. 综合形成洞察 将主题转化为洞察陈述。洞察应超越观察（“用户提到了 X”），进一步解释（“用户需要 Y，因为 Z”）。将听到的内容与其重要性联系起来。

6. 提出建议 根据洞察提出按优先级排序的行动。每条建议都应直接对应一条洞察。根据证据的充分程度注明置信度。

7. 记录局限性 说明你未能了解的内容、样本偏差或仍需进一步研究的领域。坦诚说明局限性有助于提升可信度。

项目记忆约定

仅当 .claude/pm-skills.local.md 存在时生效。若文件不存在，则完全忽略本节， 并严格按照上述说明行事。

• 读取： phase 和 active_initiative，让研究发现以当前正在推进的计划为背景，而不是要求你重复说明。
• 写入： 将用户画像和研究发现作为 interpretation 工件保存，以便后续技能调用，无需你再次粘贴。
• 处理方式： 提出要写入的内容并等待确认，除非设置了 memory_auto_append: true，此时则直接追加并回显写入的内容。
• 写入规范： 写入前立即重新读取文件，切勿使用生成提案时读取的副本。如果文件内容期间发生变化，请将你的条目合并到当前状态中，并重新提出，而不是覆盖文件；只添加你自己的条目，其他所有字段和章节都必须保持字节级一致。运行时不会强制执行这些规则，而且该文件已加入 gitignore，因此若不谨慎地重写整个文件，可能会丢失其他会话的工作，且无法恢复。

这是该循环中由写入方承担的部分，也是该群体要展示的内容：此技能记录的内容，之后由 deliver-prd 读取。

输出格式

使用 references/TEMPLATE.md 中的模板来组织输出。完整的综合报告应填写模板的每个部分：研究概览；关键主题；重要引言；洞察；建议；以及附录。

质量检查清单

定稿前，请确认：

• 主题有来自 3 位以上参与者的证据支持
• 引言为逐字引用，并注明参与者 ID
• 洞察解释了“为什么”，而不只是“是什么”
• 建议具体且可执行
• 参与者身份受到保护（不含个人身份信息）
• 已说明局限性和偏见

示例

请参阅 references/EXAMPLE.md 中的完整示例。