别再问“你会用吗”？一个提问帮你过滤伪需求

大多数糟糕的产品决策并非发生在代码审查阶段，而是源于那些从未被质疑的假设。StareBrain 团队在开发 Android 端侧 AI 代理的过程中，用亲身经历验证了这一点：一个错误的调研问题，让他们浪费了大量时间。

错误的问题：为什么“你会用吗”毫无价值

早期，StareBrain 团队向潜在用户提问：“你会使用一个能帮你控制手机的 AI 代理吗？”几乎所有人都回答“会”。但这个答案几乎没有提供任何有用信息。

“你会用吗”是一个假设性问题。用户回答“会”没有任何成本，不需要回忆具体场景，不需要承诺，也不需要付出任何努力。这是最低摩擦的信号，也因此是最没有意义的信号。团队得到了大量的“会”，却完全不知道是否存在真实的问题。

正如原文所指出的：“大多数糟糕的产品决策并非发生在代码审查阶段，而是源于那些从未被质疑的假设。”在写下一行代码之前，错误的问题已经埋下了隐患。

假设性偏差（Hypothetical Bias） 是市场调研与行为经济学中的经典概念，指人们在面对假设性场景时，倾向于给出比真实行为更积极、更理想化的回答。其根源在于假设性问题不涉及真实成本，受访者无需调动记忆中的具体经历，也无需承担承诺带来的心理负担，因此回答往往反映的是“理想自我”而非“真实自我”。在软件产品验证中，这种偏差尤为危险，因为“你会用吗”得到的“会”既不能预测下载率，也不能预测留存率。规避假设性偏差的常用方法是行为溯源——追问受访者过去是否真的采取过行动（付费、搜索、尝试变通方案），因为过去的行为是未来行为最可靠的预测指标。

改变研究的关键问题：聚焦具体经历

转折点出现在团队开始问：“请带我回顾一下，你最近一次在手机上做某件事时，感觉它本应自动完成，是什么情况？”

这个问题迫使受访者回忆真实经历，而非假设；它揭示的是实际的摩擦点，而非想象的需求；它展示了用户当前正在使用的变通方案；它还能帮你判断这个问题发生的频率是否足够高。

答案的具体程度是第一个问题从未达到的。人们描述了精确的操作步骤：打开某个应用、复制内容、返回、粘贴、导航到特定界面、重新输入手机已经知道的信息。这些摩擦并非抽象概念，而是一条由四个应用组成的操作链，用户已经重复到不再觉得它烦人。

这种答案才是产品构建的基础。

关键事件法（Critical Incident Technique） 由心理学家 John Flanagan 于 1954 年提出，最初用于分析飞行员操作失误，后被广泛引入用户体验研究与产品调研。其核心是让受访者回忆并详细描述一个具体发生过的、有明确起止的事件，而非泛泛评价。在 StareBrain 的案例中，“最近一次感到本应自动完成的经历”就是典型的关键事件提问：它把时间锚定在过去，把场景锚定在具体操作，从而绕过了假设性偏差。使用关键事件法时，追问细节（打开了哪些应用、步骤顺序、当时在做什么）比追问感受更有价值，因为细节才能暴露真实的操作链与摩擦点，也能帮助判断该问题发生的频率。

进一步过滤的追问：行为验证

在故事性问题之后，团队增加了另一个问题：“你是否曾为让这件事变得更简单而付过费，或者花过真实的时间去尝试解决它？”

如果有人花过真实时间或金钱试图解决这个问题——搜索过应用、尝试过快捷方式、购买过工具——那这就是一个被确认的问题。他们已经用行为投了票。

如果对方只是说“是啊，挺烦的”，但从未尝试去解决，那么这个痛点的尖锐程度可能不足以驱动用户采用。在构建之前知道这一点非常有用。

原文中还给出了一个代码示例，对比了用户手动操作的繁琐与代理自动处理的简洁：

// 我们试图消除的现状：
// 用户意图：“叫车去机场”
// 当前现实：
fun userDoesManually() {
    openApp("Maps")
    searchFor("airport terminal")
    copyAddress()
    openApp("CabApp")
    pasteAddress()
    checkCalendarForFlightTime()
    switchBackToCabApp()
    confirmBooking()
}

// StareBrain 的处理方式：
fun agentHandles(intent: String) {
    val plan = planner.decompose(intent)
    plan.steps.forEach { step ->
        dispatcher.execute(step, requiresConfirmation = step.hasIrreversibleSideEffect)
    }
}

这个对比清晰地展示了代理要解决的真实摩擦：跨应用的信息复制与重复输入。而只有通过具体的故事性问题，才能发现这种用户已经习以为常的摩擦。

“为解决方案付费或付出努力”这一追问背后的逻辑，对应精益创业中的“行为验证”原则：用可观测的投入（时间、金钱、注意力）代替口头意向。 在需求过滤中，这常被称为“痛点尖锐度测试”——一个真正的痛点，用户往往已经自发寻找过变通方案（搜索应用、设置快捷方式、购买第三方工具、编写脚本），这些行为构成了“已确认的问题”的证据。反之，仅停留在“挺烦的”层面的抱怨，说明痛点尚未尖锐到驱动用户改变现有习惯。值得注意的是，该问题不要求受访者已经购买了完美方案，只要求他们尝试过解决，因为尝试行为本身就证明问题值得投入。

实践中的改变：从假设验证到行为验证

StareBrain 团队彻底停止了用“你会用这个吗”来验证功能。每一次用户调研对话现在都以故事性提示开始，以花费或努力问题结束。

故事性提示告诉你问题是否真实存在；花费问题告诉你问题是否值得解决。在这两者之间，你可以在打开 Android Studio 之前过滤掉大量“为想象用户构建”的浪费。

代码是容易的部分。把问题问对，才让写代码变得有价值。

这一方法不仅适用于 AI 代理产品，对于任何软件产品乃至硬件产品的早期验证都具有参考意义。在资源有限的情况下，用行为数据代替口头承诺，是降低产品风险的有效策略。