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%。技术栈很少是导致这种差异的原因。真正的差异点在于团队在构建之前对问题的理解程度。

以下行为模式可以区分真实的用例与那些周活跃用户率将停留在 12% 的夭折演示：

真实用例的迹象：

• 用户在无需提醒或培训的情况下，自动将 AI 整合到现有工作流中
• 使用量在发布时不会出现激增后随之平稳的现象；相反，随着用户发现更多应用场景，使用量会逐渐增长
• 用户在遇到 AI 错误时仍会继续使用产品，因为这些错误并不会破坏他们的工作流
• 用户要求将功能扩展到相邻任务（这是整合而非仅仅是尝试的信号）
• 无需推广活动，自然而然地出现了核心用户群

演示将夭折的迹象：

• 使用量在发布时激增——由新鲜感驱动——然后在两周内下降 60–70%
• 采用率停留在目标人群的 10–15% 并维持在该水平
• 用户描述自己在尝试 AI，但在处理实际工作时会回到原来的工作流
• 问题集中在“这能做什么？”而不是“我该如何用它来做某事？”
• 用例要求用户从根本上改变其工作流以适应 AI，而不是让 AI 适应工作流

最后一点是最可靠的信号。当用户必须改变工作方式才能使用 AI 时，说明该 AI 解决的是团队发现的问题，而不是用户实际面临的问题。当 AI 契合用户已有的工作方式，并消除了现有工作流中的摩擦时，你就拥有了一个真实的用例。

在投入工程开发前运行提示词原型测试

在“绿野仙踪”测试 (Wizard-of-Oz testing) 和全面的工程投入之间，有一个非常有用的中间步骤：提示词原型测试 (Prompt Prototype Test)。在编写生产代码之前，你可以通过在 30 分钟的环节中针对真实用户输入手动运行 AI 工作流，来验证 AI 功能的核心价值。

对于代码审查摘要功能，流程如下：

1. 从你团队最近的记录中提取五个真实的拉取请求 (PR)
2. 将它们通过精心构建的提示词输入到顶尖模型中
3. 让两到三名工程师根据实际代码独立评估输出结果

这并不测试用户体验 (UX)、集成、延迟或规模。它只测试一件事：对于你目标定位的用例，AI 是否真的能产生有用的输出？在构建任何基础设施之前，这个问题都应该得到解答。

提示词原型测试的产出包括：

• 关于核心能力是否可实现的判断（基于当前模型和当前成本）
• 关于失败模式的早期证据——什么样的输入会产生糟糕的输出
• 对生产系统所需的提示词工程和输出精细化程度的初步校准

在投入工程开发前运行提示词原型测试的团队，能够做出更准确的估算，并避免在技术上不可行或经济上不可行的功能上投入数月时间。

组织层面的错误：将用户研究视为一次性的阶段

AI 用户研究中更深层的失败模式并非方法论上的，而是组织层面的。团队将用户研究视为构建前的一个阶段，然后就停止了。对于 AI 功能来说，这种做法代价尤其高昂，因为随着模型更新、生产环境中边缘案例的出现，以及用户群体超越了协助设计的早期采用者，产品的行为会发生变化。

高效率的 AI 团队将对用户的理解视为持续的基础设施：

• 捕获失败模式的生产遥测数据。 当用户在任务中途停止使用某项功能、撤回某项建议或明确拒绝输出时，这些都是信号。为这些行为建立监测机制，可以为你提供比周期性研究冲刺更可靠的持续行为数据。
• 对支持和反馈渠道进行定期的结构化审查。 联系支持部门的用户已经跨越了报告问题的较高门槛。系统地分析这些反馈可以发现被聚合数据掩盖的重复出现的失败模式。
• 与代表性用户（而不仅仅是核心用户）进行定期的行为访谈。 团队倾向于从最活跃的用户中招募研究参与者，这会导致调查结果偏向那些已经整合了产品的人的用例。刻意包含低参与度用户可以揭示为什么周活跃用户率一直无法突破 12% 的瓶颈。

那些实现 82–88% 周活跃用户率的团队不仅在构建 AI 方面更出色，他们更擅长持续理解真实用户如何与他们构建的东西互动，并且能更快地在理解与产品迭代之间形成闭环。

结论

对于喜欢快速行动的团队来说，这种实际影响是令人不适的：对于 AI 功能而言，真正重要的研究并不比传统用户研究更快或更便宜。它只是有所不同。它依赖于行为观察和“绿野仙踪”模拟，而不是陈述性偏好和问卷调查。在确定一个用例是否真实之前，它需要对模糊性保持耐心，然后再投入工程开发。

同样，忽视这一点的代价也令人难以接受：2025 年，42% 的公司放弃了他们的大部分 AI 计划，46% 的 AI 概念验证 (PoC) 从未进入生产阶段。这些失败大多是探索阶段的失败 (Discovery Failures)——团队针对一个最终证明并非真实、并非经常发生或摩擦力不足以维持长期使用的问题，构建了技术上令人印象深刻的东西。

在你写下第一个提示词之前，请回答那个你无法回避的问题：我是否观察到了用户已经采取行动去解决的、真实的、经常发生的摩擦？如果是，那就开工。如果不是，请回到访谈中去。