Z5.05.3Scene exit path设计
退出场景的路径需明确
别名: 场景退出 · 场景还原 · scene rollback
概念解释
进入场景是一键，退出不是。「观影模式」按一下就进来，看完之后呢——灯回不回来？回多少？窗帘开吗？多数产品对退出场景没有设计：场景语义只有「设置到」，没有「恢复到」。用户要么手动把每个设备调回去（把压缩过的操作再展开一遍），要么再建一个「退出观影」场景（两份配置从此要人工保持互逆），要么干脆不退出，让房间停在错误的亮度里过夜。
问题常被误读为「缺一个退出按钮」，实际缺的是退出语义：退出是回到进入前状态（恢复），还是去往另一个指定状态（对偶场景），还是把模式结束掉（见同组关于隐性模式的讨论）——三种语义对应三种实现，混用会产生比没有更糟的困惑。
机制
退出困难的根源在场景的设置语义没有记忆。执行「设置到」时，系统不记录设备此前是什么状态——没有基线快照，就没有可恢复的对象。「恢复到」在机制上要求系统额外做三件事：进入时拍快照、退出时按快照回写、处理快照过时（期间设备被物理开关改过）的冲突。主流场景实现一件都没做，所以「退出」在系统里根本没有对应操作，只有再一次的「设置到」。
对偶场景方案（建一个「退出观影」场景）把恢复问题转嫁为配置负担：互逆关系的正确性由用户维护，改了入口场景忘了改出口，两份配置就漂移了——这是把状态一致性从系统职责挪给了人的记性，注定漂移。
认知侧还有一个「进来容易出去难」的不对称：进入场景的收益是即时的（一秒布置好环境），退出的成本是延迟的（散场后才体会）。用户建场景时满脑子是进入的爽，不会想退出的路——所以退出的设计缺口不会被使用前的判断发现，只在长期使用里变成持续的小摩擦。
边界
- 不是所有场景都需要显式退出。 终态型场景（「离家」的下一站是「回家」）由下一个场景自然接续，单给退出按钮反而添乱；需要明确退出路径的是临时占用型场景（观影、会客、游戏）——它们结束后应当交还环境，而不是定义环境。
- 快照恢复只对「期间无人干预」可靠。 观影两小时里家人开过厨房灯，退出时按快照回写会把厨房灯也一并抹掉——恢复语义必须与「期间的手动改动如何处置」一起设计，否则退出本身制造新的非预期变化。
- 模式型场景的退出是模式结束，不是设备恢复。「勿扰」退出后设备去哪不重要，重要的是模式行为（静音、不推送）何时停——这类退出错了方向，代价比亮度错一档大得多。
怎么落地
- 每个场景创建时强制回答退出方式：对偶场景（建「观影」同时建「散场」）、自动到期（限时场景，如「会客 3 小时」）、或无需退出（终态型）。三选一，没有默认跳过。
- 对偶场景成对生成、成对修改：编辑入口场景时把出口场景并排展示，让互逆关系的维护成本落在系统界面里而不是用户脑子里。
- 临时场景提供计时退出：散场前的自然提醒（「观影已 3 小时，恢复客厅？」），把退出时机交给用户确认而不是自动执行。
- 恢复类退出先展示快照差异再执行：「退出将把客厅灯从 10% 恢复到 85%、打开窗帘——执行/只恢复灯光/取消」，让「恢复会改什么」在发生前可见。
- 验证办法：入户观察场景结束后的三十分钟——数一数用户手动调整设备的次数。每个手动调整都是退出路径缺口的直接读数；场景结束后手动调整越少，退出设计越成立。