智能家居真正难的不是让设备联网，而是让一堆设备对同一个状态达成一致，并且知道什么时候该由 AI 决定。

装了几十个设备、写了几十条自动化，最后发现每天真正用到的还是那三个物理开关——这句抱怨在智能家居用户里非常普遍，而且它指向的不是设备不够好，是这套系统的架构只支持「条件—动作」，不支持「判断」；把设备连上网只是第一步，真正决定体验的是三件事：状态有没有唯一真相、规则引擎的表达力够不够、以及 AI 被放在了哪一层。

一、家里的自动化，大多停在脚本

1. 一个容易复现的夜晚

晚上十点，人从客厅起身去门口扔垃圾；门一开，走廊灯亮、客厅灯亮、电视打开；两分钟后回来，门再开一次，同一组动作又跑了一遍，电视从头开始播。更常见的一种是：躺在床上说了声「晚安」，全屋灯灭，包括自己正要看的卧室床头灯。

这两种情况看起来是「规则写得不聪明」，实际上是规则引擎根本没有能力表达「我只是出去两分钟」和「卧室不算在内」；它拿到的是一个瞬间的事件快照，而不是一段有前后文的状态。

2. 条件—动作的天花板

从 IFTTT 到各家 App 的「智能场景」，底层模型几乎都一样：一个触发器、一组条件、一串动作。这套模型表达力大致等价于一段没有变量、没有循环、没有异常处理的 if 语句，它能描述单点反应，却无法描述过程。

缺的是五样东西：状态记忆，不知道刚才发生过什么，也就无法判断「已经连续开了二十分钟」；时间维度，只知道条件成立，不知道成立了多久；互斥与仲裁，两条规则可以同时成立且互相矛盾；失败语义，动作执行失败了，没人知道该重试还是该放弃；作用域，规则不知道自己该管哪一片区域。

3. 规则越堆，体验越差

规则是叠加的，不是组合的。单看每一条都合理，放在一起跑就会互相打断：开灯的和关灯的抢同一个开关，空调的和窗户传感器的抢同一个判断。

规则数量是线性增长，冲突组合却是平方级——十条规则有 45 对关系要维护，三十条就是 435 对。所以「规则越写越多、体验越来越差」不是错觉，是组合爆炸的必然结果；解决办法不在于把规则写得更精细，而在于先把状态和仲裁这两层补上。

二、第一个真问题：没有唯一的状态

1. 一盏灯，四个爹

客厅那盏灯可以被至少四个东西控制：墙上的物理开关、手机 App、语音助手、自动化规则。物理开关通常不经过云端，它把灯断开的那一刻，系统的认知里灯还是「开着」的。

于是规则判断「灯是关的」就去开灯，实际灯本来就亮着，用户看到的是灯闪了一下；或者反过来说「灯是开的」就不开，实际它已经被墙上的开关关掉了，人在黑里站着。这类问题在排查时极其折磨人，因为它不是逻辑错误，是信息不完整。

2. 期望状态与实际状态

工业界的做法是给每个设备维护一份「影子」（device shadow）：一边是我们希望它处于的状态，一边是它上报的实际状态，两者之间允许短暂不一致，由协调器负责收敛。

规则的产出应该是期望状态，而不是直接的操作指令；「把客厅灯设为开」是一条愿望，「按下开灯键」是一次动作——前者可以重试、可以去重、可以比较，后者一旦丢失或重复执行就不可控。区分这两件事，是智能家居从玩具走向可用的第一个分水岭。

3. 幂等与收敛

由此推出一条很硬的约定：规则里禁止使用「切换」（toggle）。因为切换不是幂等的，重试一次就从开变成关，网络抖一下、消息重投一次，灯就自己闪。

所有动作都应该是「设为某个值」。设成开、设成 26 度、设成 40% 亮度，重复执行一百次结果都一样，协调器才敢做重试和补偿。

4. 物理优先

物理开关必须被当作最高优先级的输入，而不是被系统覆盖的对象。这意味着两件事：选型时优先选带状态上报的开关，或者干脆换成智能开关；做不到上报的设备，规则里就别假设自己知道它的状态，宁可改用「仅在检测到变化时」的写法，也不要每次开灯前都强推一次。

这套取舍的底层判断很简单：系统的权威不能高于人的手。

三、第二个真问题：规则引擎的表达力

1. 三段式不够用

一个能用的规则引擎，至少要在三段式上补三个维度。

其一是持续时间：不是「门是开的」，而是「门开了超过 90 秒」；其二是上下文：谁在家、人在哪个房间、当前处于什么模式、设备是否可用；其三是结果处理：动作超时怎么算、失败重试几次、连续失败之后是否要告警。

这三样缺任何一样，规则就只能写「一发生就做」，写不了「该做的时候才做」。

2. 人走过走廊的三秒

人体传感器是最典型的例子。PIR 传感器检测的是红外变化，人坐在沙发上一动不动，它就认为没人；大部分传感器的冷却时间在两分钟左右，于是「人走了就关灯」这条规则几乎一定会误关——人还在沙发上，灯灭了。

可靠的写法不是监听「无人」事件，而是维护一个「最后一次检测到人」的时间戳，配合一个足够长的定时器；如果条件允许，用毫米波存在传感器和 PIR 做双源融合，前者能感知静止的人，后者响应快、成本低，两者取长补短。

这类「信号本身不可靠、必须靠时间窗口和融合来补偿」的处理，是无法通过增加规则条数解决的。

3. 冲突、优先级与仲裁

两条规则同时要控制同一盏灯，靠「后写入者胜」是最差的选择——它让结果取决于消息到达顺序，而顺序在分布式系统里几乎不可控。

可行的做法有三层：每条规则显式声明它要控制的设备集合，让冲突在配置时就被检测出来，而不是在运行时才发现；冲突发生时按优先级 + 最近触发时间 + 人工介入标记仲裁，人工操作永远压过自动；引入全局模式（在家、离家、睡眠、观影），规则只在声明的模式下生效。

模式这一层最被低估，因为它把大量隐式的相互干扰，变成了显式的互斥关系——「睡眠模式下，除了夜灯和空调，其他规则一律不参与求值」这一句话，抵得上重写几十条规则。

4. 设备掉线时规则怎么办

这是最容易被忽略的一块：几乎所有平台在设备不可用时，要么静默失败，要么直接跳过，用户完全不知道发生了什么。

正确的处理是把失败分成两类：「设备离线」属于预期内的状态，不应该算作失败，保留期望状态，等设备上线后自动收敛；「设备在线但拒绝或超时」才是真失败，需要重试并计数。两者的区别在于，前者等一等就好，后者往往意味着配置错了或者设备坏了。

如果不做这个区分，告警会被离线刷满，最后所有人都会把告警关掉——这和技术团队里被静音的监控是同一个故事。

四、AI 应该站在哪一层

1. 别让大模型直接拧灯泡

把「开灯」这件事交给一次大模型调用，等于把一个确定性系统换成概率性系统，代价有四个：延迟，一次推理从几百毫秒到几秒，而人对开灯的期望是两百毫秒内；可靠性，输出格式会漂移、会编造不存在的设备；成本，每按一次开关付一次推理费用；可用性，断网即瘫痪。

这四条里任何一条都足以否决它，而它们同时成立。

2. 它擅长的是意图与策略

大模型在这个领域真正做得好的，是三件不需要实时、错了还能被人纠正的事。

意图解析：把「客厅有点闷」翻译成一组具体的候选动作（开窗、开新风、降两度），而不是让它自己决定开哪个。策略生成：从事件历史里找规律，提出候选规则，比如「过去三周你通常在 23:20 之后才离开客厅，现在这条 23:00 关灯的规则是否要调整」。异常解释：读一遍昨晚的事件日志，用人的话说明「灯为什么自己亮了」。

这三件事的共同点，是它们都在减少人写规则的成本，而不是替代规则本身。

3. 从意图编译成规则

关键约束是：大模型的输出必须是规则，不是动作。中间要有完整的一道编译链——先用结构化 schema 约束输出，再做语法与设备存在性校验，然后跑冲突检测，接着在「影子模式」下试运行（只记录将要做什么，不真的执行），最后交给人确认后生效。

这条链路和代码发布没有区别，因为它产出的东西就是代码；区别只在于这段代码控制的是灯，而灯关错一次的后果是有人半夜摔了一跤。

4. 不确定时怎么降级

概率系统必须有兜底。设置信度阈值，低于阈值时不要猜——要么问一句「你是要开客厅的灯还是走廊的灯」，要么干脆什么都不做。

「什么都不做」在家庭场景里往往比做错更好，因为做错会被记住很久，不做只是没帮上忙；这一条和大多数互联网产品的默认策略正好相反。

5. 本地与云的分界

分界线应该画在延迟敏感、隐私敏感、可用性关键这三条上。

开关、门锁、安防、摄像头的移动检测，全部留在本地，毫秒级响应，数据不出户；需要大模型推理、需要长期历史、需要跨设备关联的部分放云端。断网时本地规则必须还能完整运行，这是硬性要求而不是优化项——家里的网断了，灯还得能开。

五、一个最小可用的落地形态

1. 四层结构

一套能长期维护的家庭自动化，大致可以拆成四层：设备抽象层，把不同协议归一化成统一的能力模型（开关、调光、温控、传感），注意统一的是能力而不是协议；事件层，把所有状态变化归一化成不可变事件并落盘；规则运行时，订阅事件、求值、输出期望状态；协调器，把期望状态收敛成幂等的设备命令，负责冲突、重试与离线收敛。

这四层里，事件层是最容易被省掉、也最不该省的一层。

2. 规则也是代码

规则要版本化、要能 diff、要能回滚、要有测试。原因很直接：一条规则改坏的代价不比一段代码小——半夜把卧室灯关掉，用户第二天可能就把整套系统关了，而且不会再打开。

「规则也是代码」不是一个比喻，它在工程上应该被当成字面意思来对待：进版本库、走变更记录、改动前评估影响面。

3. 回放与测试

事件日志最大的价值不是排查，是回放。改一条规则之前，先拿过去三十天的事件跑一遍，看它会触发多少次、有几个时间点会误触发、有没有和别的规则撞车。

这是在家庭场景里做变更评估唯一靠谱的办法，因为你没法像压测那样制造「一个人凌晨两点起来喝水」这种流量；但过去三十天的事件里，它一定发生过。

六、结语

智能家居的工程难度常常被低估，因为它看起来只是把几个灯泡和插座连起来；但只要设备数量超过十个、规则超过二十条，它就会立刻变成一个分布式系统问题：状态不一致、事件乱序、部分失败、离线收敛。

好的家应该像一个好的基础设施——没人注意到它在工作。衡量它成功与否的标准不是「能听懂多少句话」，而是「这一年里你手动干预过几次」；把状态收敛、把规则表达力、把 AI 的边界这三件事做对，才有可能接近那个状态。