上周给路由器升级固件，家里断了十几分钟网。那次断网让我第一次认真看了一遍家里的设备：客厅的吸顶灯还能用墙上的开关，厨房的插座不受影响，走廊的人体感应灯却不亮了——它的判断在云端。窗帘停在半开的位置，语音音箱反复回答“网络连接异常”。门锁倒是能正常进出，但远程查看访客的功能用不了。
这不是偶发故障，而是架构决定的。多数消费级智能家居把“判断”放在远端：传感器上报、云端决策、指令下发。只要中间那段路断了，设备本身再聪明也只是块通电的塑料。
两种假设
云端方案假设网络一直在线、延迟可以接受、厂商的服务会长期存在。本地方案假设网络随时会断、设备得自己活下去。两者的成本结构完全不同：前者把算力集中起来，设备可以做得便宜；后者要在网关或设备里塞进足够的处理能力，还要维护一套本地规则。
近几年局部趋势在往回摆。Thread、Zigbee 这类低功耗协议本来就偏向本地组网，Matter 试图让不同品牌互相认账，一些网关开始支持断网后继续执行预设场景。但要说明白：本地化不是万能药。规则越复杂，本地设备需要的算力越多，价格和功耗都会上去；跨品牌互联的兼容性，目前也很难说已经彻底解决。
场景的隐性成本
“回家模式”是个典型例子：开门触发玄关灯、客厅灯、空调、窗帘、背景音乐，五件事串在一起。设计时看着漂亮，实际用起来，只要有一台设备响应慢半拍，整套动作就会显得迟钝。更麻烦的是排查——用户看到的是“没反应”，背后可能是网关、协议、账号、固件任一层出了问题。
我后来的做法是砍掉大部分联动。常用的自动化其实就那么几条：晚上有人经过亮灯、离家后关掉该关的、睡前把窗帘放下来。其余的花哨场景，一年也触发不了几次，却要长期占着配置和维护的精力。
谁在维护它
智能家居的账单不止在购买时。固件要更新，App 会改版，账号体系可能迁移，某个品牌甚至可能退出这块业务。硬件还在墙上，支撑它的服务已经变了。买设备的时候，很少有人会问：五年后这套东西还能不能按现在的方式工作？
家里有老人的，这个问题更直接。对他们来说，一个能按的开关比一句语音指令可靠得多。任何需要打开手机、找到 App、等页面加载的步骤，实际使用率都会迅速下降。
哪些地方不该省掉物理开关
我的判断是分层的：照明、窗帘这类体验型设备，智能失效顶多是不方便；门锁、燃气报警、水浸传感这类涉及安全的，底线必须落在本地——断网也要能报警，没电也要能开门。这一点在产品说明里往往写得含糊，需要自己确认。
网络恢复之后，我把几处关键的自动化改成本地执行，又给走廊的感应灯换回了独立工作的一款。不是不信任云端，只是不想让一件日常小事挂在一段自己控制不了的链路上。
好的智能家居大概是这样：它不常被想起，也不总在提醒你它有多聪明。断网的时候，家里该亮的灯还亮着，这就够了。