Z5.06.4Exposed debounce parameters设计
防抖参数需要暴露给用户而非完全隐藏在后台
别名: 参数可见性 · 可调窗口 · hidden parameter
概念解释
冷却时长、稳定确认时长、滞回区间——这些防抖参数在多数产品里是后台常量，用户界面上不存在。把这条写出来是因为藏起来的代价不对称：藏得住时没人感谢（正常工作时参数本来就该隐形），藏不住时用户无从下手（灯反复开关，用户既看不到有个冷却参数，更改不了它）。
「暴露」不是把参数滑块平铺给所有用户，而是可发现、可解释、可调整三级：默认隐形；出现相关问题时能被发现（在规则的触发历史里露面）；被追问时能说清自己干了什么（这段时间内忽略了 N 次触发）；确有需要时可改（高级设置里可调）。
机制
隐藏参数之所以必须暴露，因为窗口值没有全局最优。它的合理取值取决于这个家的具体构成：有猫的家庭与没有的对存在传感的容忍完全不同；顶层西晒的房间与背阴房间的温度回差不同；有人上夜班的家庭，「夜间勿扰」的窗口边界整个平移。产品只能出厂一个对所有人都不太对的默认值，正确值必须在用户家里被调出来——藏起来的参数永远调不了，默认值就从「起点」变成了「上限」。
第二个机制在诊断侧：防抖是规则的静默组成部分。用户对规则的理解是「条件成立就动作」，而实际行为是「条件成立且冷却结束才动作」——后半句用户看不见。灯该亮没亮时，用户排查「条件」（人在不在、传感器好不好），永远查不到真凶是冷却窗口，因为界面上规则只显示前半句。隐藏的参数不参与用户的故障归因，却实际参与行为。
第三个机制在信任侧：被吞掉的事件无迹可寻时，系统的行为表现为随机失灵——同样的情况昨天触发今天不触发（今天处在昨天的冷却尾巴里）。不可复现的故障比稳定的故障更伤信任，用户无法建立任何「什么时候能用」的预期。暴露参数本身不解决问题，但把「随机失灵」变成「有参数的失灵」，后者是可理解、可操作的。
边界
- 暴露有等级，不是全量平铺。 参数界面全量展开会把创建规则的门槛重新抬回去——正确形态是「创建时隐形、运行时可查、出问题时可达」，默认用户不应该在第一屏看到任何时间参数。
- 暴露参数不能替代调好默认值。 把烂默认值交给用户自己改，是把产品决策打包成「灵活性」；暴露的意义是让好默认值在边角家庭里可修正，不是让每个家庭都当自己的调参工程师。
- 不是所有用户都会用、都需要用。 长尾调参永远只被少数遇到问题的家庭使用——这不削弱暴露的价值，正如备用出口不因平时无人走而多余；评估暴露的收益要看「遇到问题的家庭能否自救」，不看平均使用率。
怎么落地
- 规则详情页给防抖参数一个折叠的「触发规则细节」区：冷却时长、确认时长、当前值与含义（「触发后 10 分钟内不会再次执行」），默认收起。
- 触发历史并排显示「触发」与「被抑制」：每条被冷却吞掉的事件留一行记录（时间、所属规则、离冷却结束还差多久）——这是「灯怎么没反应」类投诉的答案页。
- 参数可改且有后果预览：拖动冷却滑块时显示「过去一周将少触发 3 次」——用历史数据让调参从盲目试错变成对照修改。
- 传感器灵敏度、防抖窗口、生效时段三个参数在同一个界面联动呈现，它们共同决定触发行为，分散三处会迫使用户在脑内拼模型。
- 验证办法：在支持论坛与客服记录里数「反复触发/该触发不触发」类工单——引入参数暴露与历史展示后，这类工单应显著转向「自助调整解决」；入户访谈时问遇到过触发问题的用户「你知道是什么在控制触发频率吗」，能答出参数所在的，才算暴露到位。