幕后手工 MVP
Wizard of Oz MVP（绿野仙踪 MVP）——先假装自动化，再手工交付
Wizard of Oz MVP 不是半成品 App。客户用的是看起来像产品的东西——一张表单、一个「生成」按钮、一封准时到达的邮件——输出却是你手工做的。问题是：这段体验值不值得自动化，而不是你能不能已经把工厂建起来。
最近更新：2026年9月25日
直接回答
什么是 Wizard of Oz MVP？
Eric Ries 在《精益创业》（The Lean Startup，Crown Business，2011）里，把 Wizard of Oz 测试当作学习工具：客户以为自己在用产品；创始人在视线外操作机器。这和 Concierge MVP 相反——后者公开承认服务是人做的。这个名字比精益创业更早。J.F. Kelley 在 ACM Transactions on Office Information Systems（1984）里描述了人机交互的「绿野仙踪」方法：用人模拟计算机系统，以便在系统存在之前研究体验。Ries 把同一块幕布用到了创业上。
关键要点
先记住这些
- 客户以为产品是真的。你是后端。如果他们知道是你本人，你跑的是 Concierge，不是 Wizard of Oz。
- 当最贵的未知是体验——格式、你真正守得住的时延、他们会不会再来——而不是「有没有人点落地页」时，才用它。
- 第一个客户到来之前，写好通过、失败、以及停止假装的规则。混乱一周之后才发明的门槛，不是结果。
- 交付你承诺的结果。把人工藏起来是测试。宣传连手工都做不到的能力，不是测试。
- 同一条路径不再需要临场发挥时，停止假装——或者你不雇人就守不住 SLA 时。永远假装，是一份没人发工资的运营工作。
选哪种测试
何时用 Wizard of Oz，而不是 Concierge、烟雾测试或假门
创始人（以及很多博客）把这些名字当同义词。它们不是。选能回答你真正问题的、最便宜的测试。这四种东西待在不同位置。
Wizard of Oz——幕布拉上
你能以客户会相信「这是软件」的时延，手工做出结果。你需要知道的是：他们会不会用、会不会再来、会不会为此付钱——不是他们愿不愿意和你一起坐在电话里。前台看起来像产品。后台是你、一张表格，和一个计时器。
Concierge——他们知道是你
你需要在客户看得见的情况下观察流程。把人工藏起来会不诚实（他们买的就是「有人来做这件事」），或者你守不住一个像样的自动化 SLA。Concierge 故意公开是手工的。
读 Concierge 操作手册 →假门——一个按钮，已有产品
人们已经在用你上线的东西。你想知道他们会不会伸手要某一个增量。把一个未接通的按钮放在他们已经工作的地方。不要为了测一个菜单项，把整家公司改造成 Wizard of Oz。
读假门测试操作手册 →本周就做
本周跑一轮 Wizard of Oz 的七步
前台要薄，后台剧本要无聊。一个你周二晚上操作不了的漂亮界面，不是测试。
- 1
写下一条可证伪的赌注
做表单之前先写完这句话：「[角色] 且最近遇到 [痛点] 的人，会在 [时间盒] 内为 [点名的结果] [做完这件事 / 要第二轮 / 付 X]，当前台看起来像自动化时。」写不完，就还没准备好。
- 2
先冻结通过、失败、以及停止假装的规则
谁算合格客户。你要数哪一个动作。读结果之前服务多少人。你决定的日历日期。以及落幕的那条线：同一条路径、不再临场发挥——或者 SLA 失守两次。写在和赌注同一页上。
- 3
设计最薄、仍诚实的前台
一个输入、一个输出、一个你醒着时守得住的周转时间。一张 Typeform、「生成」邮件、一个看起来像 App 的 Notion 页。如果你做不到 24/7、即时、或「没有人读这些数据」，就不要这么写。
- 4
写下后台剧本
工具、分钟数、以及你不会做的事。先对自己空跑一遍并计时。如果快乐路径需要你无法用五步描述的定制判断，你还没有产品候选——你有的是服务。
- 5
招募一小撮对的客户
3 到 5 个匹配 ICP、已经感到痛的人。优先将来会付钱的陌生人。朋友会把「感觉像魔法」吹大。这不是发布。不要买一波你交付不了的流量。
- 6
守住 SLA，记下每一次例外
打到你宣传的周转时间。每做完一单，写：花了多少分钟、临场发挥了什么、他们有没有用这个输出、有没有再要一单。临场发挥日志就是自动化待办。
- 7
跟进，然后对照你写下的门槛做决定
问要不要第二轮，以及什么价格条件。问他们以为哪些是自动的。拿这一周对照第 2 步——不是对照感觉。继续拉着幕布、公开并改成 Concierge、自动化某一个重复步骤，或停止。
通过 / 失败
第一个客户到来之前就定门槛
没有事先写好门槛的 Wizard of Oz 一周，最后会变成你讲给自己听的「我很忙」故事。写前台的同一天，写下下面五行。本页不会发明一个普适转化率。渠道、承诺、以及这件事有多难，都不能互换。
- 合格客户：谁算数（角色 + 最近的痛）。其他人丢掉，不拿来平均。
- 转化事件：你要数的那一个动作——用了输出、要了第二轮、或付了钱。一句夸奖不是事件。
- 样本：读比率之前你要服务多少合格的人。你能交付的一小撮，胜过你会失踪的候补名单。
- 通过线和失败线：两个你能接受的结果。「有意思」不是一条线。
- 时间盒和 SLA：你做决定的日历日期，以及测试要保持有效就必须打到的周转时间。
信号强弱的排序没变：第二次付费循环胜过一句谢谢；被用过的交付物胜过一次点击。拿自己对照你写下的门槛——不是对照别人仪表盘截图。
何时落幕
何时停止假装
幕布故意是临时的。开始之前就写停止规则，免得「再多一个客户」变成你的工作。
路径开始重复时，停止假装并自动化
你能不靠临场发挥描述快乐路径。同一个痛苦步骤出现在不止一个客户身上。先自动化那一步——不是让某个人微笑的罕见花样。
SLA 本身就是产品时，停止假装并公开
你宣传的周转时间失守两次，或者你得熬夜才能圆这个谎。要么收窄承诺，要么在接下下一单之前告诉他们这是手工（那就是 Concierge）。
他们买的是你、不是产品时，停止假装
他们只看重「对面有个聪明人」。那是咨询。若你还想学习，就改成 Concierge；否则走开。不要去自动化一个人的性格。
没人再来时，停止实验
合格的人做完第一单，不再要第二单，不用输出，也不肯说出价格。这是反对这段体验的证据——不是去造一个更快后端的理由。
实例
一段有名的历史，加上一周你可以照着做的安排
Zappos 的故事是创业案例，不是转化率基准。下面这一周是示意——名字和价格是编的，好让你看见怎么搭，不是一个该照抄的数字。
Zappos，1999——店面是真的，仓库不是
Nick Swinmurn 在当地鞋店给鞋子拍照，挂到网上。订单来了，他就按零售价买下那双再寄出。客户以为自己在网上鞋店买鞋。Eric Ries 在《精益创业》（2011）里把这件事写成已验证学习：在建工厂之前，先测人们会不会把这件事做完。没有库存系统，也没有宣称的履约率。要学的是幕布，不是某个百分比。
本周——一份你亲手写的「AI 研究简报」
仅作示意。一位创始人想卖 49 美元的简报：把一个 URL 加一个问题，变成给独立顾问的两页备忘。最贵的未知不是「有没有人点」，而是「他们会不会用一份四小时内送到的备忘，并再要一份」。
- 周一：写下赌注和失败线。前台 = 一张表单（URL + 问题 + 邮箱）。SLA = 工作日 9–6 的四小时。后台 = 创始人、浏览器、计时器。通过 = 五位合格顾问里有三位用了备忘并要第二份。失败 = 少于两位使用。
- 周二：用你自己上一份客户笔记空跑一份简报。如果要三小时，SLA 就是谎——在任何人到来之前，砍备忘或砍工时。
- 周三到周五：五个匹配 ICP 的顾问，不是 Product Hunt 发布。记录分钟数、临场发挥、以及他们是转发了还是归档了备忘。
- 周日：对照周一的门槛做决定。若他们用了并再要一份，先自动化大纲——不是做一个假的「AI 引擎」页。若他们只喜欢在 Slack 跟你聊天，你其实一不小心跑成了 Concierge。
清单
可直接勾选的执行清单
- 赌注写成一句话，带时间盒
- 招募之前写好通过线、失败线、停止假装规则
- 前台只有一个输入、一个输出、一个你醒着守得住的 SLA
- 没有连手工都做不到的宣称（24/7、即时、「没有人读这些数据」）
- 后台剧本已空跑计时
- 客户数量上限 = 本周你能交付的人数
- 记录分钟数、例外、以及他们有没有用输出
- 跟进第二轮和价格——然后用一句话写下决定
常见错误
通常会毁了测试的事
做一个比干活还久的假界面
你花四天做仪表盘，一小时做那件事。测试是那件事。一张表单就够了。
宣传你守不住的时延或隐私
「即时」和「没有人看见你的数据」是产品宣称。如果那个人是你，这些宣称就是假的。失守的 SLA 也会让你想测的体验作废。
收一份你无法退款或交付的「成品」钱
为一份已交付的简报收一点钱，是测试。为一套你没有的「平台」刷卡，是另一种法律和伦理姿态。如果本周交付不了或退不了，就不要收卡。
从不写下通过 / 失败线
忙碌的一周感觉像进展。它不是。如果周一没写下门槛，周日你就没有结果。
他们明明知道是你，你还叫它 Wizard of Oz
如果你在电话里、用真名回邮件、或把「白手套 onboarding」当成创始人本人，那是 Concierge。用 Concierge 手册。把两个名字混在一起，会掩盖：没有你时，这段体验还在不在。
永远假装
没有时间盒，没有自动化候选，没有公开计划。那是一家没人发工资的服务公司，外加一张产品落地页。
诚实
幕布是测试，不是商业模式
Wizard of Oz 比 Concierge 更吃伦理，因为客户看不见人工。界线很简单：交付你承诺的结果；不要卖连手工甚至都做不到的能力；计划好幕布怎么结束。
承诺一个结果，而不是一座工厂
「下午 4 点前你拿到两页简报」是你能用手守住的承诺。「我们的 AI 从不睡觉」是对一个你没有的系统的宣称。
不要收你退不了或交付不了的钱
若收费，本周交付或退款。对已交付工作收定金，信号强于候补名单。对一套不存在的软件收订阅，不是这个测试。
准备好公开或毕业计划
当他们问「这是自动的吗」，就回答。当你自动化时，体验不该变差。后来「App」让他们等更久、因而觉得被骗的客户，并没有被验证——他们只是被吓到了。
只收集最少必要信息
拿走做这件事需要的文件或 URL。不要收你不会用的账号、整个收件箱、或「训练数据」。
继续或停止
时间盒之后
可以继续，如果
合格的人用了输出，要了下一轮，并容忍除 SLA 以外的糙边。下一步：自动化最高频的步骤；若你仍需看着流程，就公开并改跑 Concierge。
暂停或转向，如果
没人要第二轮，他们只看重和你聊天，或每一单都是无法复述的定制路径。不要「反正先把真引擎造出来」。改写结果或 ICP。
来源
这些想法从哪来
- Eric Ries，《精益创业》（Crown Business，2011） — 把 Wizard of Oz 和 Concierge 当作自动化之前的学习工具；Zappos「先店面、后仓库」的故事是已验证学习，不是转化率。
- J.F. Kelley，ACM TOIS（1984） — 人机交互里的「绿野仙踪」方法：用人模拟系统，以便在系统存在之前研究体验。这个名字早于精益创业。
- Alberto Savoia，《Pretotype It》（2011） — Mechanical Turk / Wizard of Oz 预原型：看起来真的前台，幕后手工，用来测这段体验是不是对的那一件。
和 Yibud 一起用
用报告判断：幕布是不是下一步该做的事
Yibud 是免费、无需注册的创业点子验证器。分数来自确定性规则引擎——不是语言模型。可选的 AI 只润色文字。若最弱的维度是交付或「他们会不会用这段体验」，一周 Wizard of Oz 往往比直接开发便宜。若最弱的维度仍是需求，先跑烟雾测试。
分析我的想法 →常见问题
创始人真正会问的
Wizard of Oz MVP 和 Concierge MVP 是一回事吗？
不是。Concierge MVP 里，客户知道是人在交付服务。Wizard of Oz MVP 里，客户以为产品已经自动化。同样是人工，问题不同：Concierge 和他们一起看流程；Wizard of Oz 测的是他们以为系统做了这件事时，体验还在不在。当「把手公开」本身就是重点时，用 Concierge 指南。
这不就是多走几步的烟雾测试吗？
不是。烟雾测试是整概念落地页加一个 CTA——没有交付。Wizard of Oz 交付结果。如果还没人伸手要这个概念，你不需要假后端。先用烟雾测试指南。
这和假门测试一样吗？
不是。假门是已有产品里一个功能级的按钮或菜单。转化事件是点击，然后你说明功能还没好。Wizard of Oz 是一整段你真正用手交付的体验。测产品内伸手时，用假门指南。
把人工藏起来不道德吗？
若你宣称做不到的能力、收了退不了的钱、或消失，就不道德。若你交付承诺的结果、守住 SLA、只收集最少信息、并有公开或毕业计划，这是正常的早期实验。当你就是那个循环时，不要宣传「没有人在环里」。
需要多少客户？
从你能按宣传周转时间服务好的一小撮开始。深度胜过一次交付不了的发布。这个阶段没有普适的「统计有效」人数——周一写下你自己的样本，并守住它。
一定要收费吗？
第一天不一定，但同一周里应该发生价格对话。付款——哪怕很小——能把客气和优先级分开。只有在你能交付或退款时才收费。
什么时候开始写代码？
当同一个痛苦步骤在多个客户间重复，且你能不靠每次临场发挥描述快乐路径时。自动化那一步。不要从通用「AI 引擎」开始。
这和 Yibud 怎么接？
若你还不知道哪条假设最贵，先跑分析器。报告不会替你操作幕布。它会告诉你：本周该数需求、该找人聊，还是该用手交付一段体验。