无解释的自动化会被归因为故障
别名: 归因为故障 · 无法解释行为的信任损耗 · breakdown attribution
概念解释
自动化做了一件用户没预期的事，又不解释原因时，用户不会想「大概有它的道理」，而是默认它坏了或乱了。无法解释的意外行为在用户眼里与故障不可区分——这是可理解性缺失最直接的行为后果：系统越努力替用户做事，越频繁地被当成坏掉。
它不是「用户不理解新技术」的暂时现象。归因是人对意外行为的自动反应：预期被违背，就启动对原因的搜索；搜索没有输入时，最省力的答案就是「它出毛病了」。这个默认解释不需要证据，只需要系统沉默。
与之对照：同样意外但带一句原因的行为（「因检测到家中无人，已调低暖气」），会被归入「系统在正常工作」——意外本身不制造故障归因，意外的沉默才制造。
机制
链条分三步。
预期违背触发归因搜索。 人对环境中的系统行为持有预测；行为落在预测之外（该做的没做、不该做的做了）就产生解释需求。自动化系统的日常行为大多在注意之外，所以被注意到的行为天然以意外居多——被察觉的样本里故障占比被系统性放大。
解释缺席时采用最省力归因。 归因遵循省力原则：可获得什么解释，就用什么解释。系统沉默时，「故障」与「随机乱来」是仅剩的候选项。更糟的是负面偏好：无法解释的行为在事后回忆里更容易被编码为负面事件，成为「这系统不靠谱」叙事的累积证据。
故障框架一旦形成会自我强化。 用户带着「它爱出毛病」的预期去观察，后续行为里中性事件也被读成故障征兆，信任折价反过来降低使用与依赖，系统沦为摆设。此时即使解释功能后来补上，要翻案也需要多次无故障经验——损耗快、恢复慢的不对称是这条知识点最实用的部分。
怎么研究
- 归因访谈：智能家居实地研究里，请用户回忆系统「行为奇怪」的时刻并复原当时的解释。稳定发现是：无解释情境下「它出 bug 了」是第一归因，即使后来查证是规则被家人改过——用户宁可相信故障，也不假设系统有自己不知道的理由。
- 信任校准实验：布置一次性的意外行为（系统做了一个用户未预期的合理动作），比较「伴随解释」与「不伴随解释」两版的信任量表、依赖行为与后续预测准确率。可理解性研究线里 why / why not 类解释的对照实验用的就是这个骨架。
- 日记 / 经验取样：长期部署中随机采样用户对系统行为的即时评价，统计故障归因的基线频率及其与使用衰减的相关。
方法论注意点：一次性实验测得到归因差异，测不到不对称恢复——信任损耗快恢复慢需要数周尺度的部署才能观察，横断面问卷会把恢复期误判为「已经没事了」。
边界
- 只有意外行为触发归因。 与预期一致的日常行为不需要解释，全部解释是打扰。设计目标不是「事事解释」，是「意外必有解释」。
- 高信任储备能短暂垫付。 关系良好的系统出一次无解释意外，用户可能主动脑补合理原因（「大概是检测到什么了吧」）；但这是消耗储备，不是免死金牌，连续两三次后同样崩盘。
- 解释错一次比不解释更糟。 系统给的解释事后被证明不实（说是因为 A，其实因为 B），用户对解释通道本身失去信任，此后连真解释也被打折——解释必须来自真实日志，不能是公共关系的措辞。
怎么落地
- 系统知道自己何时做了罕见动作：把动作按历史频率分级，罕见动作自动附带解释；这比全量解释便宜，比不解释安全。
- 解释与动作同时抵达，不事后补——归因在发现的几秒内就完成了，隔天的说明改变不了已经形成的判断。
- 解释写具体条件与具体值（「23:40 后检测到无人在客厅，关闭了灯」），不写倾向性措辞（「为了节能优化」）——后者读起来像免责声明，反而加重怀疑。
- 验证办法：在部署里注入一次合理但意外的行为，分伴随解释/不伴随解释两组，测其后一周的信任量表与依赖行为；再把解释撤走一周看衰减速度。故障归因率、恢复时间这两个数，是解释功能的真实成绩单。