用户访谈后如何把多场访谈整合成有证据支撑的洞察与建议

在完成一轮用户访谈、客户通话或可用性测试后，跨参与者提炼主题、洞察与可执行建议。

适用场景

解决思路

1. 收集所有访谈笔记、转录稿或录音，确保至少有 3 位参与者的数据以识别有意义的模式，并记录研究目标与方法。
2. 为每位参与者建立画像，记录其角色、分群、任职时长及任何显著特征，帮助读者判断发现的代表性。
3. 通读所有笔记并按主题给观察打标签，寻找跨多位参与者（理想为 3 位以上）出现的主题，区分高频提及的话题与一次性评论。
4. 为每个主题摘录 3-5 条逐字引用，优先选择具体、带情绪或表达清晰的引用，并始终标注参与者 ID。
5. 把主题转化为洞察陈述：洞察要超越观察（“用户提到 X”），进入解读（“用户需要 Y，因为 Z”），把听到的内容与为何重要连接起来。
6. 基于洞察提出按优先级排序的行动建议，每条建议直接对应一个洞察，并根据证据强度标注置信度。
7. 记录局限性：承认未了解到的内容、样本偏差或需要进一步研究的领域，诚实的局限会提升可信度。
8. 若存在 .claude/pm-skills.local.md：读取其中的 phase 和 active_initiative，使发现围绕进行中的计划来表述；把画像与发现作为 interpretation 产物写入，供后续技能使用。
9. 写入前先提出条目并等待确认，除非设置了 memory_auto_append: true，此时直接追加并回显写入内容。
10. 写入前立即重新读取该文件（不要用生成提案时的副本）；若期间文件已变化，把自己的条目合并进当前状态并重新提案，而不是覆盖；只添加自己的条目，其他字段与章节保持逐字节不变。
11. 按 references/TEMPLATE.md 的结构组织输出，完整填写每个章节：Research Overview、Key Themes、Notable Quotes、Insights、Recommendations、Appendix。
12. 定稿前检查：主题有 3 位以上参与者证据支撑；引用逐字且标注参与者 ID；洞察解释“为什么”而非仅“是什么”；建议具体可执行；保护参与者身份（无 PII）；已说明局限与偏差。

适用边界 · 注意事项

• 只是为参会者总结某一次内部会议时，应使用 foundation-meeting-recap。
• 需要跨多次会议、随时间变化的模式时，应使用 foundation-meeting-synthesize。
• 数据是问卷回答而非访谈时，应使用 measure-survey-analysis。