自动化的历史是调试的基础
别名: 自动化历史 · 执行历史 · automation history
概念解释
单次归因解决「这一次为什么」，但调试真正依赖的是积累的历史：这条规则过去三十天触发了多少次、都在什么时段、被压制过几次、改过参数之后行为变了多少——这些跨时间的模式，才是改规则、调参数、判「这条规则到底有没有用」的依据。
日志与历史的区别在于粒度与用途：日志是流水（每件事一条，服务于回放取证），历史是台账（按规则/按设备聚合，服务于评估与调整）。没有台账，用户对每条规则的认知只停留在「我当时为什么建它」的初衷层面，永远不知道它实际在怎么运行——初衷与实际的偏差，恰是智能环境里最普遍也最隐蔽的问题。
机制
历史数据支撑调试的四种方式，一层比一层深：
发现模式。单次事件看不出规律，三十天的触发记录能：「每天 23:00 后这条规则都触发失败」指向信号覆盖，「每周三都被压制」指向与日程规则的冲突。模式是单事件归因给不了的诊断维度。
提供反事实基线。改规则前后，行为有没有变好？没有历史就没有对照——用户改完参数只能凭印象判断「好像好点了」，而印象对低频事件（一周触发两次的规则）几乎不可靠。历史让「调整—验证」从玄学变成测量。
暴露闲置与过载。建了三个月从未触发的规则（条件永远不满足）与一天触发四十次的规则（条件太宽）都需要处理，但只有历史能把它们从几百条规则里筛出来。规则库的健康度是历史视角独有的产出。
支撑参数精调。传感阈值调多少合适？「晚上」从几点开始算？这些参数的合理值来自实际数据分布，而分布只能从历史里看。
为什么历史默认不存在：聚合需要主动设计——流水日志谁都会落，但按规则聚合、按设备聚合、支持时间段对比的视图，是没人要求就不会有的产品功能。工程惯性只生产日志，不生产台账。
怎么研究
- 实境部署的纵向研究（泛写）：对真实家庭自动化使用的研究普遍报告规则库「建而不管」的常态——用户建完即忘，鲜有回顾与调整；历史视图的缺失常被列为原因之一。这是历史需求最直接的证据来源。
- 反事实评估范式：A/B 式的规则调整评估（改前 N 天 vs 改后 N 天的触发与结果统计）可从实验设计上借鉴软件领域的 baseline 对比方法；家用场景的难点在于事件频率低、周期长，需要按规则的触发频率设计观察窗。
- 历史可视化研究：时间线、热力图等时间数据可视化对「跨天模式发现」的作用有成型人因研究，可作为历史视图设计的参照。
方法论注意点：评估历史视图的价值要用调试任务做因变量（找出无用规则 / 发现冲突模式 / 判断一次调整是否有效），而不是「用户喜不喜欢看」——可用性偏好与调试效能并不总一致，前者容易高估仪表盘的价值。
边界
- 历史是调规则的基础，不是自动调规则的许可。 系统可以基于历史建议改动（「这条规则三个月未触发，建议删除？」），但采纳必须是用户决策——自动改规则会摧毁规则系统的可预测性根基，那是从规则型滑向推断型的边界，两类系统的可理解性承诺完全不同。
- 低频规则的历史价值有限。 一周触发一两次的规则，攒出可读模式需要数月；对这类规则，单事件归因（这一次为什么）比历史模式（一般怎么运行）更切实际。历史视图要按触发频率分层呈现，而不是一律三十天。
- 历史加深隐私集中度。 聚合视图比流水日志更「可读」，也意味着导出一份就交出家庭行为的结构化摘要。聚合数据的导出与共享要按最高敏感级对待。
怎么落地
- 历史视图提供按规则与按设备两个入口：规则的页面看它自己的触发史（频次、时段分布、被压制次数、最近修改至今的行为对比）；设备的页面看作用于它的全部规则时间线。
- 规则编辑后自动进入对照期：标记改动时刻，之后 N 天的触发行为与之前并排显示，改动效果一目了然。
- 内置健康度筛查：从未触发、高频触发、高频被压制三类规则主动标出，作为规则库维护的固定入口。
- 验证办法：给用户一批包含已知问题（闲置规则、冲突压制、参数过宽）的规则库，比较有无历史视图下，找出问题规则的时间与漏检率；再单测对照期功能——改一次参数后，用户能否借助前后对比正确判断「变好了/变差了/没变」。