旧规则会逐渐与现实脱节
别名: 规则脱节 · 配置腐化 · rule decay
概念解释
一条自动化规则在写下时贴合生活，之后逐渐与现实脱节——不是突然坏掉，而是慢慢变得不再合理：条件还成立但场景已无意义（给早已搬走的室友留的灯）、动作还在执行但需求已消失（冬天到了还在给风扇场景降温）、新规则叠在旧规则上而旧的从未清理。这个渐变过程可以叫规则漂移（rule drift）：规则的字面没变，它与生活的对应关系烂掉了。
脱节最麻烦的性质是无症状：规则仍然正常触发、正常执行、不报任何错——从系统视角看一切健康。症状只存在于「结果不合理」的零星时刻，而且往往被用户当作偶发不便消化掉，而不是识别为「有条规则该退休了」。
机制
脱节有三条独立的生成路径，通常同时发生：
前提蒸发。 规则编码的生活前提（谁在家、什么作息、哪个房间干什么用）被生活事件改写——上一条知识点讲的就是这个源头。前提没了，规则的字面逻辑原样空转。
叠加不清理。 新需求出现时，用户的自然动作是加一条新规则而不是改旧的：夏天加了「高温开空调」，冬天不想要了又加一条「低温关空调」，两件事其实是一件，三个季度后没人说得清这组规则共同的行为是什么。规则数量单调递增，行为由全部历史规则联合决定，而用户的心智模型里只有最近加的那几条——模型与现实的裂口随时间线性变宽。
语义漂移不设通知。 设备挪了位置、房间换了用途、家庭成员的标签变了——规则引用的实体还在（「卧室移动传感器」这个 ID 还在），它所指的世界已经换了内容。系统的引用完整性检查全部通过，语义对应早已断裂。
三条路径的共同点：没有任何一条会触发错误。脱节因此只进不出，除非有人主动复核——这正是它区别于故障的地方：故障有症状，脱节只有惯性。
怎么研究
- 配置考古：征得同意后导出长期家庭的规则库，重构每条规则的创建时间与触发历史，度量「僵尸规则」占比（长期零触发或触发后总被人工撤销的规则）及其随使用年限的增长——配置腐化的直接量化。
- 撤销行为分析：把「自动化动作发生后 X 分钟内被人工反向操作」编码为事实上的否决。撤销率是规则质量的敏感指标：用户嘴上说不出哪条规则有问题，手上的撤销动作不会说谎。
- 纵向配对访谈：同组家庭在间隔数月的两次访谈里分别解释自家某条规则「为什么存在」，第二次答不上来或答案改变的占比，度量规则语义在用户侧的遗忘速度。
方法论注意点：零触发不必然是脱节——安全类规则（燃气报警联动）零触发恰恰是正常的。判别「僵尸」必须结合规则类型与撤销记录，单纯按触发频率清理会误杀保护性规则。
边界
- 脱节不限于家庭场景。 办公室的工位感应、公共空间的定时策略同样漂移，只是公共场景的规则有管理责任人，脱节表现为「提交了工单但没人觉得是自己的工单」。
- 有些脱节是故意的。 用户保留一条失效规则作为「模板」或纪念（退休的季节场景留着明年再用），此时它在用户心智模型里有清晰位置，不算腐化——判据是用户能否解释它为何还在，而不是它是否触发。
- 规则多不等于脱节重。 有良好命名与分组习惯的家庭几十条规则仍然可理解；脱节的驱动是不可解释的积累，不是数量本身。
怎么落地
- 给规则标注最后触发时间与最后撤销时间并默认可见——把「这条规则很久没干活了/干活总被撤销」从考古题变成一眼可见。
- 定期（按事件而非日历）触发规则清点：检测到连续撤销、季节切换、设备移动时，把相关规则打包成一组请用户批量处理（保留/停用/删除），不是让用户自己想起来。
- 新规则创建时做相关规则比对：「你有一条相似的规则（……），要修改它还是新建？」——在叠加路径的源头分流，减缓单调递增。
- 验证办法：季度拉一次僵尸规则占比与撤销率两个指标；做了清点机制后，看占比是否下降、被清理的规则里「用户已无法解释」的比例——后者是腐化的真存货。