需求访谈记录怎么变成可执行的产品需求

一次需求访谈结束后，团队通常拿到两类材料：一段长录音和几页随手记。产品经理急着推进，就让 AI 总结“用户需求”。几分钟后，文档里出现账号体系、批量导出、消息提醒等功能清单。问题是，用户原本可能只说“月底对账很麻烦”。功能从哪里来，已经找不到了。

访谈材料要经过观察、问题、机会和需求几个层次。AI 适合转写、归类和查找原话，不适合把单次表达直接变成产品承诺。

先保住录音中的位置和语境

Openai Whisper Skill 可以在本地把录音转成文字，并输出带时间信息的字幕。多人重叠、口音、产品名和数字仍可能识别错误，所以产品经理要对关键片段回听。转写稿中的姓名、联系方式和业务数据也需要按权限保存。

整理时不要只摘一句“我希望有批量导出”。至少保留这句话之前发生了什么、用户现在怎样处理、失败带来什么影响、这个需求出现的频率。语境决定它是稳定问题、临时偏好，还是访谈中的随口回答。

可以为每条观察保留四列：原话或行为、出现时间、当时任务、团队解释。团队解释必须使用自己的措辞，并标记为推断。用户说“每次都要找财务确认”，事实是存在确认动作；“用户缺少权限管理”只是可能的解释。

Atlassian 介绍的客户访谈整理方法，会把观察、问题和机会连接起来，并建议不要把访谈笔记原样扔给团队。这个思路适合做需求证据卡：

一位用户反复抱怨某个步骤，可以说明问题对他很重，却不能证明整个客群都如此。归类时要记录出现人数、用户角色、使用场景和反例。不同角色说同一句“太慢”，可能分别指页面响应、审批等待或学习成本。

AI 聚类容易把表面相似的句子合并。复核时要问：这些片段是否发生在同一任务下，影响是否相同，有没有被少数表达更强烈的受访者带偏。没有足够样本时，把结论写成待验证假设。

Doc Co-Authoring Skill 适合把证据卡整理成需求说明。它会先确认文档读者、目标和限制，再按章节推进，并在接近完成时做读者测试。对于访谈转需求，先写最不确定的问题定义和范围，摘要可以最后再写。

提示词示例：

请把这些带时间戳的访谈观察整理成需求证据卡。
严格区分用户原话、观察事实、团队解释、机会方向和拟定需求。
相似表达只有在任务场景和影响相同时才合并。
保留反例、样本角色和待验证假设。
每条需求都列出证据位置、适用用户、成功条件和不在本轮范围的内容。
不要把单个受访者提出的功能自动设为高优先级。

可执行需求不等于写满模板。工程需要知道输入、状态、异常和边界，设计需要知道用户任务与限制，测试需要知道怎样判断满足。产品经理还要说明依赖、数据来源、隐私要求和未决定事项。

完成后找一位没有参加访谈的同事阅读。让他指出用户是谁、问题是什么、为何现在做、成功怎样判断，以及哪些内容仍需决定。如果答案只能靠作者口头补充，文档还不能独立支持执行。

访谈记录的价值不在于把每句话保存下来。团队需要一条能回到录音的证据链，也需要在证据不足时允许需求暂时停留在假设阶段。