用户需能回答系统为何这样做
别名: 可理解性 · 系统可解释性 · accountability
概念解释
自动化系统替用户做了动作，用户就必须能回答一个问题：它为什么这样做。系统支持这个回答的性质叫可理解性（intelligibility）——Bellotti 与 Edwards 在 2001 年把它与问责性（accountability）并列为感知系统交互的两条底线：系统要让用户看得出它在感知什么、依据什么行动，且事后可被追问。
这不是「界面友好」层面的要求。环境计算里系统动作往往发生在注意之外，用户看到的是结果（灯自己亮了、门自己锁了、暖气调高了）而不是过程；可理解性要求系统能在事后补上「依据什么」，否则用户面对的是一个行为无法预测的黑箱。
它与「给出操作说明」不同。说明书回答的是「我该怎么用」，可理解性回答的是「它为什么刚做了那个」——对象是系统已经发生的具体行为，不是抽象功能。
机制
用户对自动系统的使用依赖一条因果链：预测系统下一步 → 决定是否依赖它 → 出错时定位纠正。三个环节都消费同一个输入——对「系统为什么这样做」的答案。
预测靠心智模型，而自动化系统的心智模型无法从外观推出：动作由传感条件与规则在后台决定，这些内部结构不可见。解释是模型唯一的建筑材料。没有解释，模型停留在安装时刻的想象，随系统演化越来越失真。
依赖决策是信任校准问题：用户需要知道系统在哪些条件下可靠、哪些条件下不可靠。只有被告知判断依据，用户才能划定「信它」的边界——把高风险情境排除在自动化之外。不透明系统得到的不是理性信任而是赌博式依赖，崩起来也快。
没有因果答案的自动化还有一层代价：行为失去可问责性。出了问题无法回答「是系统判断错了、条件设错了、还是设备坏了」，责任悬空——这条属于故障诊断的领域，但它的入口正是这里的解释。
怎么研究
这个知识点的经验基础主要来自可理解性（intelligibility）研究线：
- 解释需求调研：Lim 与 Dey 对情境感知应用做的信息需求评估，先收集用户面对系统行为时实际想问的问题，归纳出解释需求的类型——为什么做、为什么没做、如果条件不同会怎样。
- 解释类型工具包：随后的工作整理出 why、why not、what-if、how to 等解释问题类型的工具包，供设计者按应用挑选该支持哪几类。
- 对照实验：Lim、Dey 与 Avrahami 的实验比较「有 why / why not 解释」与「无解释」的版本，度量用户对系统行为预测的准确度、信任与依赖校准。这是这个知识点的直接检验范式。
变量设计的惯例：自变量取解释类型（why / why not / what-if）与解释呈现时机（行为发生时 / 被询问时），因变量取行为预测准确率、信任量表、依赖行为（是否把任务交给系统）。方法论注意点：实验室里被试对系统没有真实利害，信任量表的绝对值意义有限，近年的做法是带真实后果的部署或在野研究里测依赖行为的变化。
边界
- 解释需求随自主性与后果量级上升。 每天按日程开关的低风险自动化几乎不需要解释；自主决定、后果外溢（涉钱、涉隐私、影响他人）的动作，解释是硬需求。对全部动作一视同仁地解释，成本会淹没收益。
- 解释有打扰成本。 行为发生时主动给出解释等于强制中断；被询问时才给又可能太迟。时机本身是设计变量，没有免费选项。
- 可理解性不消除不确定性。 概率推断系统的解释只能给出「依据了什么信号」，不能保证判断正确——把解释误当成正确性证明，是用户侧与设计侧都会犯的错。
怎么落地
- 每个已执行的自动化动作，保留一条事后可查的因果记录：触发了哪条规则、命中了什么条件、当时的关键传感值。不必主动推送，但要答得出。
- 解释内容按用户的问题组织——「为什么做」「为什么没做」「如果我改了条件会怎样」——而不是按系统的内部结构组织。
- 解释入口放在动作显形处：用户发现「灯自己关了」的界面与场景里，一步可达因果记录。
- 验证办法：随机抽查系统最近动作，问用户「它为什么这样做」，统计首次答对率；对照有解释入口前后的答对率与信任量表变化。答对率不升，解释就是装饰。