先假装，后实现：产品经理的 Wizard of Oz 原型测试实践

两年前我在构思一个 AI 写作辅助功能——用户输入一段文字，点击按钮就能自动扩写。听起来很实用，技术团队评估后告诉我，一个能用的生成模型最少需要两个月。两个月之后如果用户不需要，就浪费了。

这是 AI 产品经理的典型困境：模型开发周期长，验证假设却要等到成品。我当时的做法是：先做出一个看起来像 AI 在运行的假原型，后面坐着真人。

Wizard of Oz 测试，名字来自《绿野仙踪》——幕布后的人操控机器，用户以为一切自动完成。在软件产品中，我们用人工模拟模型后端，测试用户对尚未实现的功能的真实反应。

为什么不需要先跑模型？

多数时候，用户对 AI 的期望并非精准，而是“看起来合理”。扩写功能的核心假设是：“用户需要快速扩写一段文字”。但实际需要拆成更细的验证：用户真的需要扩写吗？扩写的长度和风格有要求吗？用户愿意等多久？如果是真人回复，他会怎么描述这个需求？

这些问题在模型跑起来之前就能回答大半。Wizard of Oz 测试的本质是——在功能完整实现前，先验证“用户是否愿意使用”这个最高风险点。模型性能可以慢慢优化，但方向错了，优化毫无意义。

我们怎么做的

我用 Figma 做了可交互原型，按钮点击后显示“正在生成……”的加载条，若干秒后呈现一段人工写好的扩写文本。不同输入我事先准备了模板，但也预留了即时撰写的能力。测试者并不知道另一端是我在临场发挥。

我们找了 8 名目标用户，给了他们几个写作场景：写邮件、写周报、写产品描述。观察他们是否主动使用扩写功能，以及扩写结果如何影响下一步。有人照着改，有人直接复制，有人皱了下眉头继续手写。

关键记录不是“他们点了多少下”，而是他们每次使用后的反应和原话。“这个语气不对”“太正式了”“比我自己写还长”……这些评论暴露的是我们对场景假设的偏差。

我用的设计框架

如果你也想做一次 Wizard of Oz 测试，可以按这四步走：

1. 拆出可模拟的核心行为。不要模拟整个模型，只模拟需要验证的交互。例如扩写功能的按钮、等待反馈、结果展示。其他部分简陋没关系。

2. 限制模拟覆盖范围。选择 3–5 个代表性输入场景，提前写好响应。超出预期的输入可以用“功能暂不支持”或即兴发挥，但要做好记录。

3. 控制响应质量与延迟。固定响应延迟（比如 2–3 秒），人工模拟的响应质量保持中等——太差会吓跑用户，太好会给你虚假信心。一致性也很重要，别让同一场景的两次回复风格截然不同。

4. 设计观察指标。除了任务完成率，更要关注用户尝试的动机、使用后的情感变化、是否自发向他人推荐。我自己会录屏并做简短回访。

哪些坑值得注意

• 模拟者水平波动：同一个场景，不同模拟者的回复质量可能差异很大。尽量固定模拟者，并提前排练。
• 测试环境与真实环境脱节：用户在测试中可能比实际更有耐心。可以在任务中穿插真实需求场景，降低表演感。
• 不敢戳穿谎言：测试结束后必须告知用户是人在模拟。但可以在测试前先让对方签署知情同意书，模糊描述测试方式，事后解释。
• 停留在测试结果：Wizard of Oz 能告诉你用户是否喜欢，但无法告诉你模型所需的训练数据或架构。测试后还要规划模型开发的基线。

什么时候不适合用

并非所有功能都适合 Wizard of Oz。如果核心假设是“模型能在毫秒级返回多种结果”，人工模拟无法保证延迟会暴露。如果响应需要依赖大量实时数据（如个性化推荐），模拟成本会快速上升。另外，模拟结果若无法被模型复现，测试就失去了指导意义。例如用户很满意某段回复，但那是你现场写的，模型很难学出来。

最终效果

那次测试之后，我们砍掉了扩写功能的即时按钮，改为用户选中文字后自动建议一条简短改写，并允许手动触发详细版本。方向变了，但要验证的核心行为仍然是“用户是否愿意在输出基础上修改”，而非“模型写得好不好”。这个假设我们用真人模拟就验证了，没有浪费两个月的开发时间。

Wizard of Oz 不是欺骗，是一种诚实的试探。你假装 AI 已经跑起来，是为了尽早知道它该不该跑。

PaxLee