基本功能应可本地完成
别名: 功能分级 · 本地闭环 · local control · graceful degradation
概念解释
断网降级的设计原则：设备的核心功能——灯的亮灭、锁的开关、温度的调节——应当在家内网络闭环完成；云只承担增值部分：远程访问、语音助手、跨家联动、数据分析。断网时失去的是锦上添花，不是雪中送炭。
「基本」的判定不靠产品经理的直觉，靠后果：涉及安全（锁、报警、火警联动）、健康维持（极端气候下的供暖制冷）、日常高频（照明）的功能属于基本盘。这些功能的存在理由不依赖网络，它们的可用性也不应依赖网络。
机制
功能按执行位置分三级：Tier 0 机械功能——物理开关直接操作，无需任何计算与网络；Tier 1 本地闭环——传感、判断、执行全部在家内网络或网关内完成，断广域网存活；Tier 2 云增强——远程、语音、场景集成、学习，断广域网失效。降级设计的实质是把功能往低层级放：核心功能至少 Tier 1，安全关键路径最好 Tier 0 有旁路。
为什么本地闭环可行：传感到执行的距离是米级，判断逻辑是规则与简单模型，家用网关的算力绰绰有余。云在这些环节里没有技术上的必要性——它的必要性在连接（在外面控制家里）与聚合（多厂商、多地点），而这正是 Tier 2 的定义。把规则引擎放在云端，多数情况下是部署方便与商业粘性（锁定生态、数据回流）的产物，不是功能需要。
实现层面，本地闭环依赖本地协议栈：设备与网关之间的无线协议（家庭内部网格网络）本就不出门；网关上跑自动化引擎，规则触发不经过互联网。语音是最大的例外——唤醒词在本地，语义理解长期在云端，因此语音不能作为任何核心功能的唯一入口。
怎么研究
- 架构原则的论证：local-first software 运动（Kleppmann 等 2019）提出以本地为数据源、网络为增强的一组原则，虽然针对应用软件，其「快路径在本地、慢路径为增益」的结构论证可直接迁移到设备控制；边缘计算的文献同样论证了把决策放到数据旁的时延与可用性收益。
- 断网演练测评：对设备做广域网切断测试，逐项功能记录存活/失效，得到每台设备的「断网功能矩阵」；这类测评可标准化为评测项，也是消费者可复制的方法。
- 长期在野对照：对比云架构与本地架构家庭在一段时间内的功能可用率与故障恢复时间——自然发生的 ISP 故障与云端事故提供了对照窗口。
方法论注意点：断网演练必须区分局域网断与广域网断两个条件，只测后者才暴露云依赖；不少测评混为一谈，把路由器故障的后果记到了云架构头上。
边界
- 跨地点联动本质需要中继。 度假屋监控、给父母家的远程照看，两端不在一个局域网，必须有服务中转——这类场景的「云」不是依赖而是构成。批判的对象是「单室内的控制也必须过云」，不是远程功能本身。
- 本地算力有上限。 学习型自动化（个性化调度、占用预测）在网关级硬件上训练受限，重模型仍需云端；分级原则允许学习失效但基础调度存活，而不是全有全无。
- 激励错位是主要阻力。 本地化与厂商的云订阅模式、数据回流、生态锁定直接冲突；「技术上可行」与「商业上会被提供」是两个命题，采购决策不能假设后者。
怎么落地
- 产品需求里为每个功能标注 Tier 0/1/2 归属，并作为断网验收的检查表。
- 自动化引擎选本地网关执行（设备侧无线协议 + 网关规则引擎），不用纯云规则引擎跑核心联动。
- 语音之外永远保留非云控制路径（本体控制、本地直连应用、物理旁路三者任一）。
- 验证办法：全屋断广域网 24 小时正常生活试用，逐日记下失败的日常动作——开灯、调温、锁门、场景切换。失败清单就是架构缺陷清单；清单为空，分级才真正成立。