Z3.06.2Auto-resumption设计研究
接管后系统不应在无提示下自动恢复原有行为
别名: 自动恢复 · behavioural rebound · 行为回弹
概念解释
用户中止或接管之后，系统不应自作主张恢复被中止的行为——回弹（behavioural rebound / auto-resumption）。用户停下的那一刻做了一个决定：「现在不要」；系统在用户不知情时重新执行那个决定，等于宣布用户的接管只是一次打扰。
回弹是接管体验里最破坏信任的单一事件，因为它发生在用户已经确认自己赢了的时刻：设备停了、界面显示停了、用户转身去做别的了——然后灯又亮了、暖气又开了。此时用户面对的问题从「怎么停」升级成「到底谁能说了算」，而答案看起来是「不是我能」。
机制
回弹不是恶意，是三种工程疏漏的常见产物：
- 定时器到期重启：中止只取消了当次执行，下一个调度周期照常到达——「暂停」被实现成了「延迟」。
- 状态机复位：接管走的是异常处理路径，异常处理完回到主循环，主循环不知道发生过接管。
- 云端重推：本地接管改了本地状态，云端仍持有旧状态，下一次同步把旧行为推回来——「灯又自己亮了」类报告的一大来源。
第二重罪是静默：即便恢复有时有正当理由（安全监控必须恢复值守），用户无从区分「它又出故障了」与「它故意的」。归因空缺的伤害和回弹本身相当——用户只能按更坏的那种理解。
回弹的行为后果：用户学到「接管不是终局」，于是要么放弃接管（认输，容忍错误行为），要么升级手段（拔电源、退订服务、物理遮蔽）——无论哪种，软件层面的控制通道已被判定无效。
怎么研究
- 航空与自动驾驶的重接研究：飞行员对自动重接的意外行为是自动化 surprises 文献的经典素材；接管后系统何时、以何种方式重新介入（re-engagement）被确立为独立设计变量，不是接管的附属细节。
- 智能家居状态同步故障：本地操作与云端状态不一致导致的「设备自己又动了」类报告，在智能家居的用户支持渠道与实地研究中反复出现（泛写为领域常见发现）。
- 方法：回弹检测——从日志中提取「用户中止后 T 分钟内系统重启同一动作」的事件率，按原因分类（定时器/状态机/同步）；预期调查——接管后系统应该怎么做，用户预期的问卷与访谈。
边界
- 有些恢复是正当的：安全监控类（烟感静音后恢复监测）、周期明确且事先声明的（「暂停两小时后自动恢复」且用户知情）。正当性的判据有两条：恢复语义与用户约定一致、恢复发生时可见。缺一条就还是回弹。
- 用户要的常常是中间态：「今天别闹」既不是「永远关闭」也不是「仅这一次」——恢复策略要支持这个粒度（暂停到明天、本场景内抑制），只有全有/全无两档时，用户被迫选择过重的那档。
- 区分设计性回弹与同步缺陷：一个是策略（故意的恢复逻辑），一个是 bug（同步竞态）。对用户体验是同一种伤害，修法完全不同——先把日志里的事件分成这两类再谈修复。
怎么落地
- 接管语义显式化：中止时说明影响范围——「停止本次」「暂停到明早」「关闭此自动化」三个选项明确摆出，别让系统猜用户停的语义。
- 任何自动恢复必须事先约定 + 恢复时告知，两个条件同时满足。
- 状态机审计：接管路径必须真正改变状态机的状态，而不是绕一圈回原态；云-本地同步把「用户最近的显式操作」设为权威源。
- 验证办法：接管后跨同步周期、跨云端重连、跨定时器到期做长时观察（分钟到小时级），系统侧重启同一动作的事件率应为零——用户明确约定过的恢复除外。