Z2.07.1Intelligibility of context inference设计研究
系统对情境的判断结果应可被用户查看
别名: 可理解性 · intelligibility · 判断可查
概念解释
情境判断在后台进行，用户看到的只有它的后果——灯变了、推荐换了、消息没响。最低限度的可理解性（intelligibility）要求：系统当前认为「我在哪、在做什么、什么状态」这个判断本身，用户随时可以查看。
这是情境感知研究里 accountability 概念的一半：系统不仅要执行，还要能回答「你现在对我做了什么判断」。另一半是给出判断依据，那是更深一层的要求；此处只主张第一层——判断结果本身可查。没有这一层，后面的解释、纠正、信任都无从谈起：用户连系统「以为」了什么都不知道，更谈不上纠正它。
机制
为什么后台判断必须显式可查？因为情境判断与它的后果之间隔着一层用户看不见的推理。传统界面里动作与结果直接相连（点了按钮灯灭了）；情境驱动系统里，中间插入了「系统对现状的判断」这个隐藏环节。判断错了，后果就错；而用户只看得到错的结果，看不到错的判断。
可查看的判断把这个隐藏环节变成可检查的对象。它的作用不只是「告知」：判断是纠正的前提——不知道系统把自己认成了「已离家」，就解释不了为什么报警设防，也找不到推翻这个判断的入口。判断可查还天然形成质量压力：写出来给人看的判断，「差不多就行」的标准立刻不够用。
从记忆负担看，情境系统没有屏幕、没有会话，用户无法在交互中顺便获得系统状态；不提供主动可查的入口，用户对系统认知的全部来源就只剩后果反推——那条路既慢又错。
怎么研究
- Bellotti 与 Edwards 2001 年把可理解性与可问责（intelligibility and accountability）列为情境感知系统的核心人类考量：系统须能呈现它在感知什么、据此做了什么判断。这组概念成为后来十余年可解释智能系统研究的骨架。
- Lim 与 Dey 在 CHI 2009 的调查工作评估了用户对解释的需求分布：不同类型的情境应用里，用户最需要知道的是「当前判断是什么」与「为什么触发/没触发」，前者正是「判断结果可查」这一主张的内容——可查需求排在解释需求之前。
- 测量方法成熟：给用户提供可查的判断视图与否做对照，量信任量表、心智模型准确度（请用户预测系统下一步行为）与故障归因准确率三个量。
方法论注意点：「可查」的使用频率不是有效性的指标——判断视图像灭火器，平时不看，出事时找不到才是灾难。评估要看故障场景下的可达时间，不能只看日常点击率，低使用率不等于低价值。
边界
- 可查不等于常显。 把判断实时推到用户眼前违背环境计算的消隐原则；正确的形态是安静存在、按需可查——一入口可达的当前判断清单，而不是常驻通知。
- 判断粒度受隐私约束。 展示到「系统认为家里有 2 人在客厅」这一层即可，逐条列出依据的传感器细节反而制造暴露——粒度的权衡是另一层问题，这里只主张结果可查。
- 对没有账号的在场者（访客、儿童），「可查」在产品形态上难以完整实现；这类人群的判断可见性只能靠空间级的可见指示部分覆盖，承认这个缺口比假装覆盖了好。
怎么落地
- 提供一个当前判断视图：系统此刻对在场者、位置、活动、各自动化生效条件的全部判断，一屏列全，入口固定（不随版本改位置）。
- 判断变化历史留可查记录：昨天为什么半夜开了暖气——翻历史判断比翻记忆可靠。
- 判断视图里每一条挂动作：确认、纠正、跳到相关自动化设置。可查的终点是可改，不是看完叹气。
- 验证办法：故障演练时测「从异常现象到查到系统当时的判断」的耗时；日常抽查用户对「系统现在认为你在做什么」的答对率。两个数一起构成可查性的验收。