Z1.06.1Mutual state legibility设计研究
多设备协同要求彼此的状态互相可读
别名: 状态互读 · inter-device state visibility · 协同可读性
概念解释
设备协同（「回家时开灯 + 开空调 + 播报日程」）不是指令的下发，而是状态的互读：每台设备要正确响应联动，前提是它能读到其他设备当前的状态，且自己的状态变化能被别人读到。协同失败最常见的形态不是「不做」，而是「基于过期状态做了」——联动触发时灯已经是手动关掉的，空调读到的是十分钟前的温度。
「互相可读」包含两层：设备到设备（机器可读，走协议），和设备到用户（人可读——用户能看到协同所依赖的那些状态）。第二层常被忽略，但它决定出错时用户能不能介入。
机制
为什么状态互读是协同的瓶颈？因为联动是分布式系统，而分布式系统的经典难题——一致性、时序、部分失效——在消费级设备生态里全都存在，只是被包装掉了：
- 时序竞争。人手动拨了物理开关，电信号即时生效；状态上报要走无线、网关、云端再回来，慢数百毫秒到数秒。窗口期内协同各方拿着相互矛盾的版本（「灯是开的」vs「灯已关」），谁后到谁覆盖，联动就可能建立在一个已经作废的状态上。
- 部分失效。协同链上任何一环掉线，其他设备读到的不是「不可用」而是「最后一次的值」。没有新鲜度标记的状态读起来与真实状态无异——过期被伪装成了现状。
- 语义漂移。设备间状态互读依赖语义对齐：一方用 0–100 表示亮度，另一方只有开/关/调光三档。翻译过程要么丢信息，要么造出双方都认不出的中间态。
对用户来说，这三层全发生在后台；用户只看到结果——联动错了——却无从知道是状态过期、语义丢失还是某台离线。
怎么研究
- 智能家居互联生态的实地研究是主要来源：入户追踪跨品牌联动家庭的日常故障，稳定发现包括状态过期引发的「幽灵动作」（无人操作设备自行动作）与故障归因困难。这类研究方法上以部署加访谈为主。
- 测试床实验：在受控的多设备测试床上注入延迟、丢包、离线，度量联动决策对状态新鲜度的敏感性——把「多旧的状态会导致错联动」变成可测曲线。
- 日志分析：网关侧时间戳可重建每次联动时各设备实际读到的状态版本，与应然状态比对，量化「基于过期状态决策」的发生率。
方法论注意点：实验室测试床的设备组合是研究者配的，真实家庭是逐步买来的混牌组合——生态异质性本身就是主要故障源，测试床若太干净会系统性低估问题。
边界
- 单一厂商全栈生态里问题大幅缓解——协议、语义、时钟都归一家。代价是锁定：互读性越好越难离开。这不是技术消失，是把矛盾换了个位置。
- 本地协议优于云端往返。低延迟、可离线的本地互读（局域网内直连）把时序窗口压小，但跨品牌时本地互通恰恰是最难的。
- 低后果联动对状态过期不敏感。 播报错一条日程无伤大雅；安防类联动（该锁没锁）对新鲜度要求高得多——新鲜度要求要与后果分级挂钩。
怎么落地
- 状态携带新鲜度：任何被联动消费的状态都带时间戳与来源（直读/缓存/云端），过期状态在联动决策前先判废。
- 联动执行前做一致性预检：触发动作前比对各参与设备当前实际状态，冲突时降级为提示而非硬执行。
- 给用户一张联动读数视图：每条联动「此刻依赖哪些状态、各是什么、多新」——出错时用户能看见协同的前提，而不是只看见结果。
- 验证办法：拔掉协同链上一台设备（制造部分失效），观察其余设备是把过期状态当真执行，还是识别出不可用并停手。后者才是互读合格的标志。