可在开发前验证交互假设
别名: 开发前 WOZ · 交互假设预验证 · Wizard of Oz before build
概念解释
Wizard of Oz 的研究价值在于：交互假设可以在工程能力尚未就绪时被证实或推翻。假设通常长这样——“用户会用一句话完成预订”“看到不确定的推荐仍会继续”“生成草稿会降低而不是增加编辑负担”。这些假设关于人怎么与能力相处，不关于模型准确率本身。在写识别、训练数据或后端之前用扮演来测，失败的是交互设想，而不是已经沉没的开发成本。
机制
交互假设一旦进入开发，会被实现细节保护起来：团队会把失败解释成“模型还没训好”，而不是“这个对话结构就不该存在”。前置扮演把能力当成可开关的服务，于是可以单独操纵话轮设计、确认方式、失败可见性和控制权分配。若在扮演条件下假设仍失败——人不愿说那种句子、不信任那种推荐、无法编辑那种草稿——继续开发该能力不会自动修好交互。反之，扮演成功只说明交互在理想能力下成立，仍要在真实模型上复验；它排除的是“交互本身走不通”，不是“模型一定够用”。
怎么研究
把假设写成可观察的人侧行为：特定句式是否出现、在何种提示后出现、失败后是否换策略。Wizard of Oz 条件提供上限能力，再设对照：降低能力（强制识别错误、拒绝某些请求）看假设是否仍成立。Kelley 的早期语音系统工作就是先测对话结构，再决定把工程资源投向哪类识别。分析单位是交互片段，不是模型指标。开发里程碑应设“假设被推翻则停建该交互”，否则扮演结果进不了决策。
边界
有些假设本来就是模型假设（“在我们的声学条件下词错误率能否低于某阈值”），Wizard of Oz 回答不了，需要语料和离线评测。组织若已经承诺交付某能力，前置否定会被忽略，方法就失去决策功能。对需要数周适应的工作实践，单场扮演只能测初次遭遇，不能测稳定使用。伦理上，若假设涉及欺骗或高风险建议，即使是扮演也要按真实伤害潜力审查。
怎么落地
- 在立项材料里把交互假设与模型假设分成两列，前者走 Wizard of Oz，后者走离线评测。
- 为每个交互假设预先写“何种观察算推翻”，扮演前冻结，避免事后改口。
- 扮演成功不排期开发收尾；排期的是“用真实能力复验同一假设”。
- 推翻后的产物是改交互或取消该能力，而不是“先做出来再看”。