规则上线前需要在不影响真实设备的情况下预演
别名: 预演 · 沙盒测试 · dry-run · staging
概念解释
预演（dry-run / rehearsal）：新规则启用前，在不动真实设备的前提下跑一遍——用历史数据回放或模拟触发，展示「这条规则会做什么」，然后由用户决定是否真正启用。软件交付里有 staging 环境的传统，家庭自动化没有：家就是生产环境，规则一启用就在真人真物上执行。预演是在这个没有测试环境的领域里，人为造出一个只读执行层。
它防的不是语法错误——语法错在保存时就报了——而是语义错误：规则完全合法地跑着，做的却不是用户想要的事。语义错误在启用前唯一的表现机会，就是预演。
机制
为什么家庭自动化特别需要预演？因为规则的副作用不可见、不可逆、且外溢：
写规则的时刻与触发时刻是分离的。用户在下午创建「凌晨自动关加湿器」，无法亲眼看到它在凌晨如何与「婴儿房湿度下限」规则竞争；条件组合的真实覆盖面（会在周三凌晨两点触发吗？）只在实际时间流里展开。人评估规则靠心算，心算的准确率随条件数量陡降——两个布尔条件以上，未经训练的预期基本不可靠。
同时家用的动作多不可逆或不便逆：已经发出的通知、已经关掉正在烘干程式的插座、凌晨被唤醒的家人。试错学习在物理后果面前代价高到不可用——软件可以灰度发布，家庭自动化「先跑跑看」的代价由住的人当场承担。
预演的机制因此是把执行与生效分离：同样的条件评估、同样的规则引擎，输出指向展示层而非设备层。历史回放型预演用「过去一个月会触发几次、都在何时」给出覆盖面；模拟触发型预演手动注入一个条件为真，观察整条链路的判定。两者都在真实时间流之外，这正是 staging 的本质。
怎么研究
终端用户编程研究长期把测试与调试支持的缺失列为采用的核心障碍之一：Ko 等人对终端用户编程学习障碍的分析指出，用户面临的最深障碍之一是无法回答「为什么它没做我以为它会做的事」——而家庭自动化的实地研究反复发现，用户对新规则的态度被「怕出事」压制，只敢建后果轻微的规则。这类发现共同指向：预演能力决定编排系统的使用上限。
评估预演本身的常用方法：让用户分别在有/无预演的条件下创建并启用规则，比较启用前的规则修改率、启用后一周内的意外事件率与用户的置信自评；回溯型研究统计预演功能引入前后「启用即反悔」（48 小时内删除或停用）的比例变化。
方法论注意点：预演的生态效度依赖历史数据代表性——刚装的传感器没有历史，回放预演只能基于极短样本，覆盖不了季节与作息变化；评估与设计都要把「预演数据不足」当作独立条件处理。
边界
- 预演只能覆盖引擎可见的世界。 它模拟条件评估与规则链路，模拟不了物理执行的真实后果（窗帘卡住、灯泡坏了）——执行层的故障在预演层不存在，别把预演通过当成端到端可靠。
- 模拟触发测不出时间相关的缺陷。 时区错位、跨日边界、夏令时切换，只在真实时间流里暴露；历史回放对这类缺陷的检出依赖历史里恰好包含边界事件。
- 预演有使用门槛，不是放上去就有人用。 强制每条规则预演会劝退低后果规则的创建；正确形态是按后果分级——锁、通知、购买类强制预演，调光类可选。
- 预演结果会被「看起来对」欺骗。 用户在预演里确认的往往是他以为的规则而非实际的规则（与自然语言创建规则的确认问题同构）；预演展示的具体度决定它能不能工作，这正是同组下一条要处理的。
怎么落地
- 每条规则保存后、启用前提供两种预演：历史回放（「按上月数据会触发 4 次：3 次日落、1 次手动灯亮」）与单次模拟（「假设现在门开且天黑——将执行：廊灯 100%、通知妈妈」）。
- 预演入口内嵌在启用动作旁，不藏在菜单——它属于启用决策，不属于设置。
- 后果分级强制：动作含不可逆或外溢（锁、通知他人、消费）的规则，未经预演不允许直接启用。
- 预演结果可保存：用户把「上月会触发 4 次」的回放留在规则旁边，启用后对照实际触发数——偏差是规则语义走样的最早信号。
- 验证办法：统计预演使用率与「预演后修改了规则」的比例——修改率是预演真实价值的直接读数（用户在预演里发现了自己的错误）；再看启用后 48 小时反悔率的变化。