场景把多设备状态打包为一次操作
别名: 一键场景 · 场景模式 · scene as macro
概念解释
场景（scene）是多设备编排的基本打包单位：一条命令把一组设备各自设置到指定状态——「观影」= 客厅灯 10%、窗帘合上、投影仪开、空调 24 度。它把 N 次独立操作压缩为一次，是命令空间里的时间压缩，本质上是宏（macro）：一个名字绑定一组预先编排好的动作。
要把它与自动化规则区分开：场景是用户主动调用的命令（按下、说出「观影模式」），规则是条件自动触发的行为（日落时开灯）。产品话术常把两者混称「自动化」，但调用模型完全不同——场景解决「懒得逐个调」，规则解决「希望不用管」。同一个家庭里通常两者并存且互相调用：一条「到家」规则的最后一步可以是执行「回家」场景。
机制
场景有效的基础是状态设置语义：「把灯设到 10%」是设置到目标状态（set-to），不是相对调整（toggle/调整量）。这带来一个关键性质——幂等：重复执行同一场景，结果一致；中断后重按一次，系统收敛到同一组目标值，不需要用户记得「刚才调到哪了」。相对调整语义（「调暗一点」）做不成场景：重复执行会越叠越暗。
第二个基础是命令与状态的一致性前提：场景执行时设备必须可达且服从。设备离线、被物理开关抢占、被他人手动改动，都会让宏执行出缺口——场景假设的是一群设备同时听话，这正是它比单设备控制脆弱的地方：N 个设备的可用性相乘。
第三个基础在认知侧：一个名字对应一组状态，把「布置环境」的认知负荷从逐设备参数决策压缩为单个情境标签的检索。用户不必记住「看电影需要哪些设备什么参数」，只需要「我在看电影」。
怎么研究
智能家庭的纵向部署研究中，一键场景/例程（routine）稳定地出现在最被实际使用的功能之列——设备买回后长期存活的自动化多是一键场景与简单定时，而非复杂条件规则。这反过来说明打包单位选对了：用户最高频的需求确实是「一次布置一组状态」。
常用方法：日志分析统计场景与规则两类自动化的创建量、存活时长与日均调用次数；访谈追踪「场景名从哪来」——多数家庭自创的命名（「娃睡了」「老人模式」）与生活事件而非设备相关，这是打包单位贴合生活结构的证据。
边界
- 打包的前提是设备支持绝对状态设置。 只有开关量、不支持调到指定值的设备（老式继电器插座上的风扇），进场景后只能表达「开/关」，场景的表达力被最笨的设备拉平。
- 场景的幂等性止于设备边界。 带持续量的设备（窗帘走到一半断电）重执行可以收敛；但场景不知道「人」的状态——在有人熟睡时执行「起夜场景」仍是全量设置。
- 场景数量本身成为负担。 场景超过十几个后，检索与记忆成本开始抵消压缩收益；场景的收益在「少量、高频、名字自明」，不在多。
怎么落地
- 场景内每个设备的目标状态用绝对值定义，避免「增加/减少」「切换」类相对语义进场景。
- 把跨场景重复出现的设备组提取为子场景（「全屋关灯」被「离家」「睡眠」复用），修改一处、处处生效。
- 场景执行结果汇报缺口：五个设备成功、窗帘离线时，明确说「窗帘未执行」，而不是静默放过——宏的部分失败必须可见，否则用户对场景的信任建立在幸运上。
- 场景命名让用户自定义并保留其生活词汇，预置名（「场景一」）改名为「娃睡了」的门槛要足够低。
- 验证办法：统计每个场景的月调用次数分布——长尾零调用的场景是死重；入户让用户说出「这个家里你最常用的三个场景」，答不出的场景应该被合并或删除。