多条规则可能对同一设备下相反指令
别名: 规则冲突 · 指令冲突 · conflicting automations
概念解释
两条各自都合理的规则，可以在同一时刻对同一台设备下相反的指令：「日落开客厅灯」与「家中无人时关所有灯」，在冬天的傍晚全家人恰好外出时同时成立——一个要开，一个要关。这是规则冲突（rule conflict），多规则模型的结构性产物，不是谁写错了。
冲突的判定要从指令层面看，不是从规则意图层面看：两条规则目标一致但路径相反也是冲突（一条「节能关灯」、一条「感应到人开灯」，在有人路过的走廊上交替触发）；两条规则毫不相干但共享动作设备，同样会在设备上汇聚成相反指令。用户的体感是「设备不听话」「时灵时不灵」，很少有人能自己把现象归因到规则对上。
机制
冲突的根源是触发条件空间的重叠。每条规则的条件是某个多维空间里的区域（时间、位置、传感值的组合），不同规则的区域在真实世界里必然相交——因为设计者各自只看自己的规则，没人负责检查全体的交集。
而冲突只在动作汇聚的设备上显形。规则的评价在系统层各自独立进行：A 规则成立、B 规则也成立，各自发出指令，系统并不知道自己刚发了一对矛盾——矛盾是在设备端被「执行谁」暴露出来的。这解释了为什么冲突在创建时不可见：创建界面呈现的是规则的语义（合理），不呈现指令的时序（冲突）。
第三层：冲突的显性形式少见，隐性形式日常。同一毫秒内的正面相撞很少；更常见的是时间上错开的拉锯——A 开了灯，两分钟后 B 的条件也成立把灯关掉，A 的下一个评价周期又把它打开。用户看到的是设备反复开关，不会想到背后是两条规则的循环。
怎么研究
- 冲突检测研究：智能家居文献中有把静态分析与模型检验方法用于规则集的工作，枚举触发条件可同时成立的规则对，按动作是否相悖分类。这类研究给出冲突的理论发生率随规则数与设备共享度的增长关系。
- 规则语料分析：在真实规则集上跑冲突检测，统计实际重叠的规则对占比——Ur 等 2014 年 IFTTT 语料的方法可复用于此（触发源、动作目标的分布决定了冲突的结构可能性）。
- 用户归因实验：给用户呈现「设备反复开关」的现象与其背后的规则对，测量用户自发发现冲突的比例与所需提示层级。这个范式度量的是冲突的不可见程度——修复之前先要知道它有多难被看见。
方法论注意点：冲突的操作化定义要提前固定——「指令相反」（开/关）、「参数相悖」（22 度 vs 26 度）、「语义冲突但指令相同」三类后果与对策都不同，混在一起统计会得出无意义的冲突率。
边界
- 冲突不是都要消除的缺陷。 有些「冲突」是有意的冗余设计：安全规则的「无人也常亮」压过节能规则的「无人关灯」，恰恰是正确的优先序——问题不在于冲突存在，在于冲突的裁决是否符合意图。
- 隐性别与偶发混淆。 同刻冲突罕见、错峰拉锯常见，后者的表象（反复开关）一部分属于触发去抖的范畴，那里的对策（时间窗、滞回）解决的是反复触发，不是指令相悖——两件事经常同时发生但可以分开处理。
- 规则数少不等于无冲突。 两条规则只要共享设备且条件可同时成立，冲突就成立；家庭里最常见的冲突恰恰只涉及两三条规则。
怎么落地
- 规则创建保存前做冲突预检：同设备既有规则的条件区间与新区间求交，非空即提示「此规则可能与『日落开灯』在冬天傍晚全家人外出时同时触发」——用具体场景语言，不用「检测到潜在冲突」。
- 冲突提示要给出裁决预告：「同时触发时将执行哪条」在创建时就声明，而不是留到运行时用行为暗示。
- 运行时记录被压制与被覆盖的指令，让冲突的每次发生都留痕。
- 验证办法：对目标设备模拟「多条规则同刻成立」的注入测试，核对结果是否符合声明的优先序；再统计真实运行一周内同设备多规则触发的次数，与用户感知的「不听话」次数对照。