Z5.06.3Trigger latency设计
时间窗设置过长会让真实变化的响应显得迟钝
别名: 触发延迟 · 响应迟钝 · 窗口过长
概念解释
防抖窗口的另一半代价：窗口定长了，真实事件也要等窗口走完才被响应或才能再次触发。用户感知到的就是「系统迟钝」——人进了房间，灯要等三十秒才亮；离开半小时了空调还在吹；半小时内第二次倾倒检测被冷却时间吞掉。「该动的时候不动」与上一条的「不该动的时候乱动」是同一个参数的两端，调任何一端都在恶化另一端。
迟钝的伤人在信任：自动化对真实事件的漏响应，用户不会归因于「窗口参数」，只会归因于「这东西不可靠」——于是回到手动操作，自动化被架空。误触发招人烦，迟钝直接杀功能。
机制
窗口造成迟钝有三条通路，对应三种时间语义：
触发前的稳定确认直接把延迟加进响应路径：要求「有人持续 2 分钟才开灯」，则每次开灯都自带 2 分钟延迟——延迟是刚性的，无论事件多真实。稳定确认对慢变量（温度、湿度）无伤，因为人类对这些量的变化本身不敏感；对快变量（人、门、声音）则是致命的，因为用户对「我进来了—灯亮了」的因果预期是以秒计的。
触发后的冷却延迟的不是首次响应而是再次响应：离开检测（「15 分钟没人关空调」）的冷却意味着检测窗口内的人来了又走、走了又来，系统不再看——这对「真正离开」的判定引入了盲区，且盲区大小等于冷却值。多次事件被合并成一次，第二次真实事件发生在冷却期内时被静默吞掉，无日志、无提示。
感知侧的迟钝会放大为系统侧的失信：因果预期断裂的机制在心理层——用户行动后短时间内未见到结果，会重复行动（再按一次开关、走两步再走回来），重复行动本身又制造新的传感事件，进一步搅乱规则看到的世界。迟钝引发的行为补偿，成为新的噪声源。
边界
- 迟钝的可容忍度按事件类型差好几个量级。 舒适类（温度调节晚五分钟无感）与在场类（灯亮晚三秒已嫌久）、安全类（毫秒级）不是同一把尺子；不存在全局统一的「合理窗口」，只有按事件类型分档的容忍度。
- 窗口长不是迟钝的唯一原因。 轮询式架构（每 5 分钟查一次状态）与云端往返（本地事件绕服务器一圈再回来）造成的延迟与窗口无关——用户抱怨迟钝时先量延迟到底出在哪一段，再决定动不动窗口。
- 对「合并事件」类意图，长窗口是正确的。 「一天最多提醒一次」「同一访客一小时内只记一次」——这里「迟钝」就是语义，不是缺陷；区分标准是规则作者到底想要每次事件还是每段时期。
怎么落地
- 为每类自动化定延迟预算：人在场类秒级（稳定确认改用传感层的多传感融合，而不是时间滤波）、通知类分钟级、汇总类小时级。窗口从预算倒推，不从防误触发正推。
- 首次响应与重复响应分开定价：首次事件零延迟（不做触发前确认），冷却只作用于重复触发——多数「误触发烦、迟钝也烦」的两难，出在把两种响应共用了一个窗口。
- 冷却吞掉真实事件时留痕：「12:40 第二次开门事件在冷却期内被忽略」——这条记录是用户投诉「没反应」时的唯一真相来源。
- 迟钝投诉的排查顺序：先分段计时（传感上报延迟、规则引擎延迟、动作执行延迟各多少），再动窗口；顺序反了会把架构延迟误诊成参数问题。
- 验证办法：抽一条自动化做端到端计时——真实事件发生到动作完成的 p95 时延，与该类事件的用户容忍度对比；再统计冷却期内被吞事件的比例。两个数分别对应「迟钝」的两半，都接近零预算才算合格。