用AI归纳用户访谈录音需求主题：保留原话、来源与反例的证据矩阵

先定义交付物：主题矩阵与开放问题

用AI归纳用户访谈录音需求主题，交付物不应只有几条流畅结论。更实用的是一份能回查的证据矩阵：每个候选主题对应哪条录音、哪句原话、什么情境，哪些属于研究者解释，还有哪些不同意见和问题没有解决。

先限定一个窄问题，例如“参与者如何处理预约后的信息与提醒”，再从至少两条获准使用、已经保存的访谈录音开始。不要一上来要求系统总结所有产品机会，也不要把未选入的访谈当成已经分析过。

我们的FoneClaw Voice Notes提供录音、转写及合集上下文，方便围绕所选记录提问。这里的证据矩阵是建议的研究整理格式与人工复核成果，不是宣称插件具备专门的质性编码平台，也不自动证明研究有效性或样本代表性。

三种表述应始终分开：引号中的逐字引语需要与来源一致；转述用自己的话概括，不冒充原句；研究者解释则提出可能的含义，应标为推测或待验证假设。即使几条访谈表达相近，结论范围也先限制在这些获准材料之内。

选取获准录音，建立中性来源标签

确认参与者允许录音、相应处理、研究用途及计划共享范围，只使用本次问题需要的内容。允许团队内部分析，不等于允许公开声音或引用身份信息。相关边界可参阅Android AI 会议录音同意指南：录音提示、转写共享与行动确认。

在兼容Agent中使用Voice Notes录音，按需暂停、继续，结束后保存并命名。先检查声音是否存在、内容是否完整，再核对转写；具体单条准备方法可参考Android AI 录音转写摘要指南：快速录音、说话人复核与行动确认。

为记录指定I01、I02、I03等中性标签，并记下访谈日期和主题。标签是你建立的来源对应关系，不是自动识别出的真实身份；如需保留身份映射，应另行受限保存。尤其要区分访谈者的问题与参与者的回答，不能仅凭说话人编号认定身份。

合集至少选择两条已保存录音，并复用已有转写。完整选择与组织方法见FoneClaw录音合集项目复盘：整理跨会议决策、变更与未决事项；本次使用相同的来源基础，但分析目标是访谈证据，不是跨会议决策时间线。

可通过FoneClaw 功能介绍了解Agent能力。兼容版本方面，完整 APK 在相应设置与权限下支持 APK 插件，而 Google Play Lite 不安装 APK 插件。免费插件不代表Agent或模型使用全部免费，处理不保证完全离线；也不应把本流程当作任意外部音频、PDF导入或其他服务的迁移通道。

三个虚构访谈片段：不要提前合并偏好

以下三条来源和引语全部是虚构练习材料，不是真实参与者、研究发现或应用生成结果。情境统一为预约结束后如何处理记录，便于展示不同偏好。

• I01，虚构片段：“预约结束后，我会把提醒复制到待办里，有时复制过去就忘了带上日期。”
• I02，虚构片段：“如果先给我一条提醒建议，我想看过内容和日期再保存，不要直接替我存。”
• I03，虚构片段：“我不想再多一个提醒，我只需要过几天还能找到当时的原笔记。”

初步可以分别标记“日期信息丢失”“保存前确认”“原笔记检索”三个候选主题。它们是对上述虚构文本的整理，不是已经验证的功能需求。

研究者也许会提出一个更高层假设：“这些情境可能涉及用户对后续信息的控制和可追溯性。”这句话是解释，不是任何一位参与者的原话，必须单列。I03明确不想增加提醒，不能为了主题整齐而删去。

后续表格若截取句中一部分，引号内仍须与这里的虚构原文一致；若改变措辞，就改标转述。真实研究中也采用同一规则，不生成一段看起来像受访者说过的话来补齐证据。

把原话、主题和解释放进证据矩阵

下面继续使用上述虚构材料示范矩阵。真实访谈中，“片段位置”由你回听后手动记录，可写录音名、相关章节或定位线索；这里不提供虚构时间戳，也不意味着系统自动生成可点击的音频引用。

矩阵中的解释都应比证据更谨慎。I01说日期有时丢失，不能扩大成日期总是丢失；I02想先看建议，不能概括为拒绝所有辅助；I03不想新增提醒，也不能反推其在所有场景都不要提醒。

真实访谈逐行回到转写和原音频，尤其核对否定、条件、上下文及提问方式。找不到原句，就保留“缺少可核对引语”，不要填一句合理的话。翻译后的摘要也不是原语言逐字引语，应与原文分别保存。

限定所选来源提出请求，再逐行复核

确认所选录音及标签无误后，可以用下面的一次请求作为起点，替换为自己的研究问题和标签：

“仅分析当前选中的访谈录音［标签列表］，围绕［窄研究问题］整理候选主题。每行分别写主题、正确录音标签、可核对的逐字引语、转述、研究者推测、不同意见和开放问题。只有来源确有原句时才用引号；找不到或来源不确定就明确标注。保留否定与适用情境，不编造姓名、引语、负责人、截止时间或产品承诺，不把未提及当作同意。片段位置无法确认时留待我手动补记。”

输出后先查来源，再看主题命名。逐行核对标签与原句是否匹配，并回听前后内容：一句话可能是在回答假设场景，或随后被参与者修正，不能脱离上下文当成稳定偏好。

发现问题，在自己的研究工作笔记中记录修正及依据；检查所选转写后，再重新提出范围明确的请求。不要假定改过一条转写，所有旧分析就自动刷新，也不要把人工修正记录描述成原生版本历史。

若模型把两个人的表述合为一段引语，应拆回各自来源，不能让合并后的流畅句子继续留在引号中。主题可以跨来源比较，引语却不能拼接成一个人说过的话。

保留反例，不把假设写成已确认需求

在这个虚构练习中，“所有人都希望自动保存提醒”没有依据。更合适的表述是：“I01描述复制时可能遗漏日期；I02希望先确认再保存；I03不希望增加提醒，而希望回查原笔记。”再单列假设：“不同情境可能需要不同的后续处理方式。”

接下来的研究问题可以是：“在什么情况下，你会选择保存提醒，而不是只保留原记录？”这是拟议追问，不是已经得到的答案，更不是获批的产品需求。

同一参与者重复说了三次，不等于三个独立用户；选中多少条录音，也不能换算成市场比例、因果结论或商业潜力。这里的三个虚构案例只是练习，不应计算为真实需求支持率。

保留I03这样的反例，有助于检查主题是否过宽。若后续来源与当前解释冲突，先比较情境、任务和问题措辞，不急于把少数意见归为异常。听不清的片段继续标为未知，沉默或未提及也不能当作支持。

最终可以形成候选主题和待验证方向，但功能愿望、研究者假设与团队决定应分开保存。访谈分析不自动产生排期、负责人或已经承诺交付的功能。

处理来源错误，只选择一项后续行动

整理完成前，先做一次来源检查。问题出在材料时，应该修正材料和对应关系，而不是要求生成一份语气更肯定的报告。

交付时保留复核后的矩阵、未知事项和一项自己选择的研究跟进。录音、转写、研究矩阵及后来得到的确认说明是不同材料，不把后来补充的答案写成原访谈已有内容。

如果决定建立个人待办，应另发当前工具支持的请求，核对目标账号和保存位置。有明确日期才写日期；没有就明确无日期、未安排，可参考Android AI 待办无日期保存指南。完成后打开实际记录，确认标题和日期状态。

这一步不代表自动分配团队任务、写入CRM、联系参与者或共享研究内容，也不承诺原生研究看板或特定导出功能。可以先只保存“补问日期丢失发生在哪一步”这一项，把未解决问题保留下来，比把所有访谈愿望转成任务更符合当前证据范围。