缺少日志时无法诊断
别名: 执行日志 · 事件日志 · execution log
概念解释
智能环境是个故障只能被动等待的系统：自动化偶发失灵时，用户既不能复现它（不知何时再发生），也不能查询它（没有留下记录）。没有日志，诊断就退化成守株待兔——人在场时它好好的，人一走它就出问题，而所有证据随事件一起消失。
日志（execution log）是把这些瞬态证据固化的手段：规则何时触发、条件当时何值、动作是否送达、送达后设备是否执行——逐环记下，故障才有被回溯的可能。它与触发记录的关系是从单点到全链：触发记录回答「这一次为什么」，日志回答「这系统最近到底在干什么」；前者服务于单事件追问，后者服务于模式发现与故障定位。
机制
无日志之所以致命，在于智能环境的故障有三个特点叠加。间歇性：竞态、信号丢失、条件边缘抖动造成的失灵不成规律，主动复现几乎不可能。延迟发现：失灵发生与用户发现之间隔着小时到天，现场早已改变。归因易错：用户拿不到机器证据，只能用记忆与常识补——而记忆会把「自动化关的灯」记成「灯坏了」，把「规则没触发」记成「传感器坏了」，错误归因直接导向错误的修复动作（换设备、删无辜的规则）。
日志把这些从「不可观测」变成「可回放」。工程传统上这是可观测性（observability）的老命题——软件系统数十年前就确立了「事件必须落盘才能被诊断」的共识，审计日志、链路追踪都是成熟形态。智能家居的特殊性只在于：事件源分散（云端、中枢、设备各自知道一段），日志天然碎片化——云知道规则触发了，中枢知道指令转发了，设备知道动作执行了，三段拼起来才是完整链路，任何一段缺失，故障就定位到断点为止。
最小可用日志集是三样：规则触发事件（谁、何时、命中何条件）、指令投递结果（送达/失败/被压制）、设备执行确认（做了没有、结果如何）。少于这三样，链路有洞；多于这三样，诊断收益递减而隐私成本陡增。
怎么研究
- 实境部署研究：对真实家庭自动化部署的纵向研究（泛写）反复报告同一现象——用户对偶发失灵的解释充满误归因，且排查手段仅限于现场试错。这是日志需求最直接的经验证据。
- 可观测性传统借鉴：运维与分布式系统对「事件留存—故障定位」关系有成熟方法论（日志级别设计、关联 ID、采样策略），可作为智能家居日志设计的机制参照，但要注意家用场景的约束不同（无专人值守、隐私敏感）。
- 有无日志的对照实验：制造一次间歇性故障（如条件边缘抖动导致的偶发不触发），比较提供完整日志、部分日志、无日志三组用户的定位成功率与错误归因率。日志价值的直接度量。
方法论注意点：故障定位实验的因变量要包含错误修复动作（用户接下来做了什么）——只测「找到原因了吗」会漏掉「自信地修错了」这一类，而它才是无日志的最大代价。
边界
- 日志不解决实时问题。 它是事后取证，不是事前防护——不能阻止故障发生，只能让故障不再逍遥。把日志当监控告警用（实时扫描异常并推送）是另一种产品形态，成本结构与隐私含义都不同。
- 留存即隐私负担。 智能家居日志实质是家庭行为的连续记录（何时在家、何时睡、哪个房间有人），其敏感度高于一般软件日志，保留策略、导出权限、与家庭其他成员的可见性都要按家庭数据对待——这里点到为止，展开属于共享空间隐私。
- 日志本身要可诊断。 堆积万条原始事件的「日志」等于没有——无结构、无筛选、无时间对齐的日志把诊断成本转嫁回用户。日志的可读性是诊断可行性的组成部分，不是锦上添花。
怎么落地
- 最小日志集三件套先落地：触发事件、投递结果、执行确认，每条带时间戳与关联标识（同一次执行的三条记录能串起来）。
- 日志视图提供按设备过滤与时间对齐：诊断「灯为什么没关」时，能把该灯相关的触发、投递、执行记录按时间排成一列，断点即故障点。
- 保留期与存储分级：近期明细 + 长期摘要（触发统计、异常计数），兼顾诊断深度与隐私暴露面。
- 验证办法：人为注入三类故障（不触发、指令丢失、执行失败），测用户从「报告症状」到「指出故障环节」的时间与准确率；三环节各注入一次，全链日志下应能定位到具体环节，无日志组应大量失败——这个差距就是日志的价值度量。