晚上十点，路由器例行重启。那一刻，客厅的灯没有响应，语音助手回了一句“网络连接失败”，空调面板还在闪。设备都在，功能却像被临时收走了。这不是故障，而是很多人第一次意识到：家里的“智能”，有一部分并不住在家里。
被默认的前提
过去几年，智能家居的默认架构是把判断放在云端。语音识别、场景联动、设备状态同步，大多要绕一圈服务器再回来。好处是设备本身可以做得很便宜，算法升级不用换硬件；代价是家里多了一条看不见的依赖——网络稳不稳、厂商的服务在不在，直接决定灯亮不亮。
这条依赖平时感觉不到。宽带正常、服务器正常的时候，云端和本地几乎没有差别。它只在几种时刻显形：断网、厂商调整服务、账号登录异常，或者老设备停止支持。前几种是偶发，最后一种是必然。
把一部分判断搬回来
于是“本地优先”成了这两年硬件圈反复出现的方向。做法不复杂：在网关或主机上跑一部分逻辑，开关灯、温湿度联动、简单的自动化规则不必经由外部网络。近些年围绕 Matter、Thread 的讨论，本质上也是想让设备之间少绕路、少依赖单一平台。
但要克制地看这件事。本地化不是一个开关，而是一堆取舍：网关要算力，算力要成本，成本要有人买单；本地跑的逻辑越复杂，出问题时越难远程排查；不同厂商对“本地”的定义也不一样，有的指局域网内可控，有的指数据不出户，两者并不等同。
本地解决不了的部分
复杂的语音理解、跨设备的习惯学习、需要大模型的对话式交互，短时间内仍然更适合放在云端。它们依赖算力和模型迭代，塞进一个几百块的网关并不现实。所以更可能长期存在的形态是混合：日常的、确定性的动作留在本地，需要理解与推理的部分上云。
对普通用户来说，这意味着选购时该问的问题变了。与其看设备能连多少个、支持多少种场景，不如先问几句具体的：
- 断网之后，哪些功能还能用？是全部失效，还是开关、定时这类基础动作仍可执行。
- 自动化规则存在设备上还是账号里？换一个路由器、改一次密码，会不会全部重配。
- 历史数据留在本地多久，导出是否方便。
- 这款设备过去几年有没有持续更新，厂商停服之后它还能不能当普通开关用。
一个更朴素的判断标准
智能家居谈了很多年“连接”，连接的设备数量成了某种默认刻度。但家里真正需要的，其实是稳定和可预期。灯该亮的时候亮，不该被提醒“请检查网络”。
所以我看这类产品时，会先想一个不太浪漫的问题：如果明天断网一周，这个家还能住得舒服吗？答案越接近“能”，这套系统就越接近成熟。技术往里走，把麻烦藏起来，而不是把依赖摆在明面上——这大概才是智能家居该有的样子。