AI 用户调研：在编写第一个 Prompt 之前，用户真正需要的是什么

大多数团队决定开发一个 AI 功能，然后询问用户：“你想要这个吗？”用户说想。功能发布了。三个月后，周活跃用户（WAU）停留在 12% 且不再增长。复盘时将其归咎于实现或采用，但真正的失败在写下第一行代码之前就发生了——那就是在那些看起来很周全但方法论上存在缺陷的用户调研阶段。

核心问题在于：用户无法准确预测他们对从未体验过的能力的偏好。这并非小瑕疵。一项关于 AI 写作辅助的研究发现，基于用户表达的偏好设计的系统仅达到了 57.7% 的准确率——实际上表现甚至不如那些完全忽略用户表达偏好的原始基准方案。你可以进行长达数周的用户调研冲刺，收集广泛的定性反馈，但最终做出的产品却没人使用——这并非尽管做了调研，而是在一定程度上正是因为调研的开展方式所致。

为什么标准方法论在 AI 面前失效了

传统的 UX 调研假设你可以展示一个原型并收集有意义的反馈。这个假设对于确定性软件是成立的。但对于 AI 功能，它在两个层面上失效了。

首先，用户没有参考点。如果你展示一个 AI 生成摘要功能的模型（mockup），用户的反应是针对模型的视觉设计，而非该功能的实际价值。他们无法评估 AI 输出的真实情况——例如它的一致性如何、何时会失败、失败是否可以补救，以及它是否真的能在他们的实际工作流中节省时间。他们的反馈反映的是想象，而非体验。

其次，偏好是构建出来的，而非提取出来的。行为经济学家已经证实，人们的大脑中并不存在固定的偏好存储，等待在问卷调查中被读取。偏好是在决策时刻形成的，受环境、框架和近期体验的影响。当你询问用户是否想要在代码审查流程中获得 AI 辅助时，他们会当场构建一个答案。这种构建出的偏好对于功能发布后他们实际会做什么的预测能力非常弱。

结果就是：大多数传统的用户调研方法产生的是“陈述偏好”（stated preferences）。对于 AI 功能来说，陈述偏好是不可靠的输入。主要基于陈述偏好来做产品决策的团队会构建错误的东西——或者为错误的使用场景构建正确的东西。

绿野仙踪法：在构建前进行验证

早期 AI 调研中最强大的技术是“绿野仙踪法”（Wizard-of-Oz，简称 WOZ）：用户与一个看起来是自主 AI 的系统交互，但实际上该系统是由后台的人工操作员控制的。

这种方法比现代 AI 还要古老。它最初在 20 世纪 70 年代被记录，用于测试自动终端界面。其原理是：如果你需要了解用户如何与 AI 系统交互，你就需要一个他们可以交互的 AI 系统——但这并不意味着你真的需要先构建出 AI。一个遵循一套一致规则的人类“魔法师”（wizard），可以很好地模拟大多数 AI 行为，从而生成有效的行为数据。

以下是针对代码审查 AI 功能的 WOZ 设置：

• 魔法师坐在另一个窗口或使用对用户隐藏的通信渠道
• 用户向“AI”提交代码变更
• 魔法师阅读提交的内容并根据定义的行为规范编写回复
• 用户收到回复并继续工作流
• 引导员观察并记录用户在何处犹豫、误解或成功

你从中学习到的东西与询问用户对该功能的看法有着质的区别。你会了解到用户信任并采纳哪些建议。你会了解到交互在何处断裂。你会了解到用户是否真的将该工作流整合到他们的工作方式中，还是仅仅测试一次后就回到了旧的方法。你得到的是行为数据而非陈述偏好。

一次 WOZ 环节的成本是几小时。而构建一个错误的 AI 功能的成本是数月——还要加上项目失败带来的组织压力。在投入工程开发之前运行 WOZ 研究的团队可以在一周内验证或推翻核心假设，从而带着真正的信心去构建，而不是依靠美好的愿景。

行为面试：不问用户想要什么，而是挖掘真实的工作流

第二个关键方法是行为面试（behavioral interviewing）——但不是那种询问用户想要什么的方式。目标是挖掘用户已经以不完美的方式解决的真实、重复出现的工作流问题，因为这些不完美的解决方案揭示了真正的未满足需求。

结构应围绕最近发生的实际事件而非假设场景展开：

从具体的案例开始。 “请带我回顾一下你上一次进行大规模代码审查的情况。”而不是：“请向我介绍一下你通常的代码审查流程。”概括性的描述会抹平摩擦。具体的案例则能揭示摩擦。

追踪摩擦点。 当用户在描述中语速放慢、犹豫或提到变通方案（workarounds）时，这些都是信号。“你提到你先把它导出到了电子表格中——为什么？”用户为自己构建的变通方案是真实未满足需求最可靠的指标之一。如果有人构建了变通方案，说明这种痛苦已经真实到足以激励他们去寻找解决方法。

梳理整个工作流，而不只是目标任务。 AI 功能很少孤立存在。了解在你优化的任务之前和之后发生了什么，可以揭示你的 AI 是否正在解决正确的瓶颈。代码审查工作流中的瓶颈可能不是审查本身——可能是分选（triaging）哪些 PR 需要紧急处理，或者将发现的问题传达给那些不仔细阅读评论的作者。

忽略最后的陈述偏好。 当你结束行为面试时，用户通常会提供功能需求或赞美。请将这些视为弱信号。真正重要的是你在他们对实际行为的描述中观察到了什么。如果他们描述了一个耗时 20 分钟的手动变通方案，那就是一个真实的问题。如果他们没有描述任何摩擦，却说他们想要一个 AI 助手，那么这就是一个预测价值有限的假设性偏好。

每次行为面试后的诊断性问题应该是：“我是否观察到了这个人为解决真实、重复出现的摩擦而采取行动的证据？”如果答案是否定的，那么这个用例可能不够真实。

辨别信号：真实的用例 vs. 终将夭折的演示

企业级 AI 采用率基准显示出明显的双峰分布。排名后 25% 的部署在上线 90 天后，日活跃用户 (DAU) 仅为 12–18%，周活跃用户 (WAU) 为 25–35%。而排名前 25% 的部署在同一时间点的周活跃用户率则达到了 82–88%。技术栈很少是导致这种差异的原因。真正的差异点在于团队在构建之前对问题的理解程度。

加载中…