在写产品之前，先把用户的问题问具体

一个功能想法很容易获得礼貌的认可，但认可不一定意味着真实需求。为了决定是否值得继续开发，我们需要更具体的行为信息。

这份访谈框架是一种起步方法，不代表通过某几个问题就能预测用户是否付费。

从最近一次经历开始

与其问「如果有一个 AI 工具，你会使用吗」，可以请对方回忆最近一次遇到这个问题的情况。

• 当时发生了什么？
• 谁先发现问题，最后由谁处理？
• 使用了哪些文件、工具和沟通渠道？
• 哪一步最容易卡住？
• 如果不处理，会发生什么？

允许对方展示有权分享的实际材料。具体流程常常会暴露你在想象中没有考虑过的交接和限制。

了解现有替代方式

用户可能已经通过表格、人工服务、内部脚本或暂时忍受问题来应对。它们都是你需要理解的替代方式。

询问现有方法什么时候奏效、什么时候失败，以及切换工具需要付出什么。不要因为流程看起来繁琐，就假设它一定值得被替换。

把付费问题放回决策过程

「愿意花多少钱」通常不能脱离具体交付来回答。先明确谁使用、谁批准、谁付款，以及一次购买需要经过什么步骤。

如果对方愿意参加试用，再约定清楚的任务、交付标准与时间。真实的后续行动，比一次口头兴趣更有助于判断优先级，但仍不等于最终成交。

用一张卡片记录证据

访谈对象的角色：
最近一次发生的问题：
当前处理方式：
实际投入与影响：
不愿改变的原因：
愿意尝试的下一步：
尚未确认的假设：

区分对方的原话、你观察到的行为与自己的推测。不要把一位受访者的经验，直接推广成整个市场的结论。

让下一步小到可以执行

在产品开发前，你也许可以先人工完成一次交付，或者只实现最重复的一步。关键是让对方能在真实任务中判断结果是否有用。

如果没有人愿意提供材料、投入试用时间或继续讨论，也应把它记录下来。需求验证的价值，在于帮助你更早调整方向。