Z3.03.1Attribution gap in intent inference设计研究
用户往往不知道系统为何这样做
别名: 归因缺口 · 莫名其妙的自动化 · unexplainable agent behaviour
概念解释
意图推断失败时（自动化做了用户不想要的事），用户面对的第一道障碍不是「怎么改」，而是**「它为什么这么干」——推断依据的传感器信号看不见，判断过程不展示，用户拿到一个没有理由的动作。这个状态叫归因缺口**（attribution gap）：行为有，依据无。语音助手的误唤醒是原型场景：音箱突然应答，用户既没说唤醒词，也永远无法知道它「听到了什么」。
归因缺口是意图推断失败的放大器：同样的错误，伴随可见原因的（「我碰到了传感器」）用户能归档、能预防；无原因的会被反复咀嚼——不知道何时会再发生，防御无从谈起，最后沉淀为对整个系统的不安。
机制
归因需要材料：可观察的输入、可追溯的判断、可对照的规则。意图推断系统三样都不给——这不是疏忽而是结构：
- 输入不可见。推断消费的是传感器流（声音特征、位置、心率、用电曲线），这些信号用户感知不到，也就无法检验「系统是不是听错了」。
- 过程不可查。概率判断没有「规则」可对照，模型内部不存放人类可读的「因为你平时这时……」；系统即便输出理由，也常是事后编造的解释模板，与真实触发原因无关。
- 预期不可形成。用户无法从观察失败中学习边界——「什么情况下它会误会」这个问题，在黑箱前没有答案。
Norman 对智能机器的论述点破了第二层：行为越「聪明」，用户越倾向于过度归因——给它安上理解、意图甚至性格。误判被解释成「它懂我」或「它坏了」，两种民间理论都离真实原因很远，且都妨碍正确的应对。
怎么研究
- 智能音箱误唤醒（unwanted activations）的现象研究：日志驱动的误触发统计与用户访谈结合——用户对「为什么唤醒」的猜测五花八门且大多错误，是最直接的归因缺口证据。
- 智能家居实地访谈：让用户解释自家自动化的触发条件，与实际配置比对；研究发现用户大量持有错误但自信的触发理论，错误理论在故障时引导出错误的应对。
- 归因实验范式：呈现同一错误 + 不同解释条件（无解释/模板解释/具体信号解释），比较用户的信任修复、复发预期与后续操作。
方法论注意点：用户会补全一个理由，无论系统给不给——「它大概是听到电视了」。测量归因缺口不能只问「你知道原因吗」（人人都有答案），要对照真实触发日志看答案对不对；猜测的置信度同样关键，错误且自信的理论比「不知道」危害更大。
边界
- 归因缺口只在失败时显形。 判断正确时用户不需要理由，缺口无害——这是它容易被产品忽视的原因；评估必须包含失败场景，正常路径测试测不到它。
- 不是所有解释都有用。 给出真实的信号级解释（「检测到 43Hz 持续声波」）对普通用户只是另一种黑话；解释的粒度要匹配用户模型，这一权衡在「解释粒度」的相关知识里展开，此处不重复。
- 缺口随设备数量叠加。 单设备时用户还能靠排除法（家里只有它会说话）；十几个主动设备并存时，「谁干的」都成问题，归因在定位到设备之前就失败了——多设备场景的归因是不同量级的问题。
怎么落地
- 每个自动执行的意图推断动作携带原因标签：动作显形处（通知、状态变化）附一句「依据什么信号判断的」，如「检测到你离家且 20 分钟未活动，关闭空调」——不说模板话，给真实依据。
- 原因标签可展开：一层给人话，展开后一层给可核对的信号事实（时间、传感器、阈值），照顾想深究的用户。
- 为误判留复盘入口：错误发生后能回看「当时的信号是什么、判断置信多少」，把一次失败变成可学习的边界知识。
- 验证办法：在误触发后 24 小时内回访，请用户复述「系统为什么那样做」，对照触发日志计答对率；对原因标签做 A/B（有/无），比较误触发后的关闭率与信任修复速度。