用户需能知道某个动作由什么触发
别名: 触发归因 · 触发追溯 · what triggered this
概念解释
环境计算里的每个自动化动作，用户都要能查明它的触发原因：是哪条规则、命中了什么条件、当时的传感值是什么。「灯为什么自己关了」不该是一个悬案。
这是可理解性需求里最常用的一类——触发归因（trigger attribution）。与推断型系统「为什么认为我想要这个」的概率解释不同，规则型系统的触发归因有一个确定的机器答案：动作由规则触发，规则由条件命中，条件由传感值满足——三者都可被精确记录。问题从来不是答案不存在，而是答案默认只存在于执行的那一瞬间，没有人为它留下来。
机制
规则系统在归因上有一个结构性优势：因果链是确定且有限的。传感值 → 条件命中 → 规则触发 → 动作执行，四步走完，没有隐藏的推断层。这意味着触发归因不需要任何解释算法——不需要生成模型、不需要事后合理化，只需要把执行引擎本来就知道的东西（它刚刚评估过哪些条件、哪些成立了）落到持久存储里。
但默认不落。执行引擎的数据流是评估后即丢弃：条件命中与否在评价周期内是布尔值，用完就弃，为归因保留它们是额外的写入负担，没有功能性收益——直到用户问出「为什么」的那一刻才产生价值。工程上的「无用数据」与用户侧的「唯一线索」是同一份数据，这是触发记录需要被显式要求而非自发出现的根本原因。
归因答案有三个组成，缺一不可：规则身份（哪条规则）、条件命中（它的哪个条件、与什么值）、时刻上下文（当时还有什么其他信号在场——用于排除「其实是我自己碰的」）。只有规则身份的归因回答不了「那它这次为什么会触发」；三个都在，用户才能完成从现象到原因的完整闭环。
怎么研究
- 单事件追溯测试：给用户看一段自己家中已发生的动作（或重放一段部署日志），测量其查明触发链的时间、步数与成功率。这是把「归因可用性」变成度量的直接范式，智能家居审计与可追溯研究（泛写）以此为主。
- 可理解性研究线的框架：Lim 与 Dey 对情境感知应用的解释需求调研里，「why（为什么做了）」是用户最常问的问题类型之一——触发归因是 why 问题在规则系统上的具体化。该实验范式（比较有无归因支持的预测准确率与信任校准）可以平移过来。
- 日志留存策略对比：比较「全量留存 / 仅动作留存 / 无留存」三档下，事后归因的成功率与存储成本，为保留粒度提供决策依据。
方法论注意点：归因成功率的测量要区分「查到了」与「看懂了」——界面能给出规则 ID 是前者，用户能读懂「因为玄关传感器在 21:04 检测到移动」是后者；两个失败的原因不同（前者是记录缺失，后者是表述问题）。
边界
- 确定性归因只对规则系统成立。 学习型自动化（从习惯中学出的行为）没有规则可查，归因退化为「依据了哪些信号」的相关性解释——那属于情境推断可解释性的范畴，两类的用户预期要分开管理：前者承诺准确答案，后者只能承诺依据清单。
- 归因不能事后补建。 执行瞬间没记下的东西，任何界面都查不出来——归因能力是记录的函数，不是查询界面的函数。先解决「记不记」，再谈「好不好查」。
- 并非所有动作都需要同等待遇。 高频低风险动作（例行开灯）的归因需求稀薄，按需记录即可；涉及安全、涉他、财产的动作，归因记录是硬需求。一刀切的留存策略要么浪费存储，要么丢掉关键证据。
怎么落地
- 每个已执行动作落一条触发记录：规则身份、命中的条件与值、时间戳、当时的关键上下文信号。执行引擎评价过什么就记什么，不额外推断。
- 归因入口放在动作显形处：用户发现「灯自己关了」的地方（通知、设备页、场景现场）一步可达触发记录，而不是只有全局日志的入口。
- 保留期至少覆盖典型发现延迟——从发生到被用户注意并追问，通常以天计；按周清空的日志等于没有。
- 验证办法：随机抽取最近两周的历史动作，测用户归因成功率与耗时；再统计「误归因」（把自动化动作当成设备故障或反之）的占比变化——归因界面上线前后，误归因率应显著下降。