场景创建通常需要手动逐条配置设备状态
别名: 场景搭建 · 逐条配置 · scene creation
概念解释
一个「场景」（scene）把多台设备的目标状态打包成一次操作——「离家」是关灯、调低地暖、上锁、关闭插座的集合。问题在创建侧：主流应用要求用户逐台设备、逐项状态地手工指定这个集合，选中每盏灯、设定每档亮度。场景的价值随设备数增长，创建的负担也随设备数增长，而负担先到瓶颈。
「记录当下」这条捷径在多数产品里不存在：用户把房间调到理想状态后，没法说「就存成这样」。于是用户必须把刚刚亲手做过的设置，在应用里再对着一遍清单重做。
机制
负担为什么长在「逐条」上？看创建成本的结构：场景在系统里存储的是一张显式状态表——每台设备一个目标值。创建成本正比于设备数，且是纯手工劳动：用户要凭记忆还原「观影时灯光 30%、窗帘关闭、空调 24 度」这样的向量，应用不提供从现实状态导入的通路。
「记录当下」难做有真实的技术理由：场景执行的是绝对目标而不是相对调整，而「当前状态」里有噪声——设备离线时读到的是陈旧值，半开的窗帘「就是现在这样」未必是用户想要的目标。采集当下要求所有设备在线且状态可信，这个前提在真实家庭经常不成立，于是厂商干脆不做，把枚举劳动完整留给用户。
再加一层心智模型错位：用户思考的是情境（「看电影」这个活动），系统存储的是设备向量（N 个 setpoint）。从情境到向量的翻译没有任何辅助，全靠用户在脑内完成——这正是「逐条配置」体验上如此疲惫的原因：不是点击次数多，而是每一次点击前都要先做一次翻译。
怎么研究
触发-动作编程（trigger-action programming）的系列研究是这组经验事实的主力证据：
- Ur 等人 2014 年对 IFTTT 用户的大规模调查发现，真实用户创建的规则远比系统允许的简单——绝大多数是单触发单动作，涉及一两台设备/服务；用户实际使用的复杂度远低于平台表达能力，「能配很多」和「愿意配很多」是两回事。
- Dey 等人更早的上下文编程原型（iCAP，CHI 2006）尝试过用示范与抓取降低指定成本，指出了「从示例构造规则」这条路线。
- 方法上，创建负担的标准度量是创作任务研究：给非技术用户真实设备清单，请其搭建指定场景，计完成率、耗时、语义偏差；配合出声思考记录翻译发生在哪一步。
方法论注意点：实验室创作任务用研究者拟好的场景描述，省掉了用户自己构思场景的环节——真实家庭里最贵的往往是想到要建什么，而不是建；补充入户访谈问「你家有哪些场景、怎么来的」才能补上这一段。
边界
- 例外存在且在增多。 部分平台已有「保存当前状态为场景」；语音助手支持示范式创建（把屋子调好，说「记住这是观影模式」）。「必须逐条」的论断强度随平台而异，写评估前先确认目标产品的实际能力。
- 真实家庭的场景数不大。 现场研究里多数家庭活跃场景只有个位数，负担论断不该外推到重度用户——他们反而享受细粒度控制。
- 跨品牌设备混用时逐条配置会更碎。 不同品牌各自的应用里各建半个场景，体验断裂加倍；但协同障碍本身是另一个话题，这里只计它在创建负担上的放大效应。
怎么落地
- 提供**「记录当下」入口**：一键把当前所有可控设备的状态存为场景草稿，允许离线设备标注「未采集，手动补」。把技术前提的失败从「功能不存在」降级为「个别项待补」。
- 场景创建从房间/活动模板反推设备清单，而不是让用户从全屋设备列表里翻找。
- 示范式创建：先把屋子调到理想状态再命名保存，对齐用户的心智方向（先有体验，后有配置）。
- 验证办法：度量创建一个 N 设备场景所需的手工操作数（点击+输入），与「记录当下」路径对比；新用户首周场景创建完成率是直接的行为指标。