场景建立后仍需验证其在真实环境下的效果
别名: 场景验证 · 部署后调适 · in-the-wild 调整
概念解释
场景「配置正确」不等于「效果正确」。创建时逻辑无误的「观影模式」，到真实晚上才暴露问题：日落触发的灯其实太暗、设备依次响应的延迟让窗帘关上时电影已经开始、周六的家庭作息让「工作日夜间」联动整晚不触发。场景建立的那一刻只是提出假设，真实生活才是检验——配置界面里没有任何东西能预告这些。
所以「建立场景」应当包含部署后的验证环节：跑过、观察过、调过。产品把「保存」当成流程终点，等于把全部验证负担无偿转给用户的日常生活。
机制
为什么配置正确性与真实效果之间存在必然的裂缝？四个来源，都来自「配置引用的是代理量，而效果发生在真实世界」：
代理量误差。 配置里写的是「日落时刻」，用户想要的是「暗到需要开灯的时刻」——两者在阴天、朝向、季节上系统性偏离。每个触发条件都是目标体验的代理，代理精度只能在真实环境的样本上测出。
共存效应只在共跑时出现。 单测每条联动都对；多条同时活着的自动化相遇才产生冲突与次序问题——两条规则在 18:00 同时抢一台设备，这种交互没有孤立测试可发现。
生活节律的方差。 周一成立的前提（家里没人）在周六不成立；场景是关于典型一天的假设，而家庭过的是方差很大的一串日子。
传感器位置决定语义。 运动传感器装在走廊尽头，它的「有人」就不是客厅的「有人」。应用预览不了物理安装位置与语义的错配。
四者共同的结构：验证需要真实时间流逝。场景是对生活的假设，只能被生活检验——这是它与「按钮功能测试」的本质差别，后者测一次就收敛。
怎么研究
- 在野部署（in-the-wild deployment）：把场景建好后留在真实家庭运行数周，期间用日志记录触发与执行轨迹、用日记法捕捉用户的调适事件（「昨晚把观影灯从 30% 调到 50%」）。调适历史就是错配数据——每一次用户手工覆盖或修改，都是环境对假设的一次否决。
- 调适重建访谈：数周后请用户回溯「改过什么、为什么改」，与日志比对。日志知道改了什么，只有访谈知道为什么；两者对不上的部分（改了却说不清、说了却没改）分别指向习惯性修补与未落地的不满。
- 触发轨迹分析：场景的触发时间分布——长期零触发的场景大概率是死场景（条件永假或被绕开），触发后伴随手工反向操作（开了又手动关）的场景是过度触发。
方法论注意点：评估期要覆盖作息方差（至少含一个完整周末与一个工作周）；只在工作日部署五天的验证，会系统性漏掉周末型错配。季节性触发的场景（日落、采暖）理论上要跨季验证，短期研究至少要把季节依赖显式标为未验证项。
边界
- 验证深度应随场景风险分级。 灯光错了大不了手动调；门锁、安防、采暖的错配有安全与财产后果——「验证后交付」的严格程度必须分设备类别，一刀切要么浪费要么危险。
- 部分错配是发现而非缺陷。 用户在使用中把「观影模式」改造成「观影与加班共用」，是场景被生活重新定义——验证研究要把「错误」与「演化」区分开，别把正常的共同演化记成缺陷率。
- 样板间与展厅验证无效。 标准化环境的部署测不出户型、作息、安装位置的方差——恰恰是这些构成真实错配。
怎么落地
- 保存场景时提供**「立即试运行」**：当场执行一次，带明确的撤销入口——把「第一次真实执行」从深夜无人监督搬到创建时刻。
- 头两周给调适窗口：场景触发数次后主动问「观影模式这几次效果如何？」，把调适从被动等待变成系统促发。
- 场景详情页挂触发历史：最近何时触发、执行了什么、之后用户有没有手工改动——用户与研究者都靠这个诊断。
- 季节性场景设到期复核：日落时间相关的场景在季节交替时提醒复核参数。
- 验证办法：调适曲线——场景创建后各周的修改与覆盖频次。长期零修改且零触发的场景是死亡嫌疑（unused 而非 working）；触发后高频反向手工操作是过度触发信号。两条都盯着才算验证。