解释缺口指结果发生后用户缺少可归因的原因，而非结果本身出乎意料
别名: explanation gap · gulf of evaluation · 归因缺口
概念解释
系统做出一个和预期不符的举动，用户第一反应是惊讶——这只是预期违背本身。但惊讶过去之后，如果用户依然想不出任何一个理由来解释"它为什么这样做"，这时候留下的才是解释缺口（explanation gap）：一个已经发生、无法归因的空白。这条讲的是两件事的区别——预期落空是一瞬间的事件，解释缺口是这次事件之后持续存在的状态，只要没有可归因的原因出现，这个缺口就一直悬在那里。
机制
心智模型靠预测和事后验证不断被巩固或修正，两条路径都需要一个前提：能把结果和原因对应起来。结果符合预期时，对应关系是现成的，模型被直接确认；结果不符合预期时，模型要更新，靠的也是把这次意外结果归因到某个具体原因上，再把这个原因并入模型。解释缺口出现的地方，正是这条归因链断掉的地方——用户有一个需要被解释的异常结果，手里却没有任何线索可以完成归因，模型既没法确认，也没法更新，只能把这次异常当成一个悬而未决的例外留在记忆里。
一个悬而未决的例外不会自动消失，它会持续拉低用户对"我能不能预测这个系统"的信心——即使只是一次孤立事件，只要没有解释，用户就没有办法判断这类情况下次还会不会发生、发生时该怎么应对。
怎么研究
这条现象与人因领域研究已久的自动化意外（automation surprises）高度重合——操作者在自动化系统做出未被理解的举动后，报告"不知道它为什么这样做""搞不清它接下来要干什么"。相关研究常通过分析事故报告与飞行记录，识别自动化系统行为与操作者预期出现分歧、且分歧之后缺乏及时反馈说明的时间窗口，把这类窗口标记为解释缺口存在的证据。
常见自变量：系统行为的复杂程度、系统是否在做出异常行为的同时提供任何归因线索。 常见因变量：操作者报告"理解系统行为原因"的比例、后续对系统的信任评分、错误归因或放弃使用某功能的发生率。
在界面研究里，这套方法常用于评估自动化程度较高的功能（自动保存、自动分类、算法推荐）在做出非典型举动时，界面是否留下了可供归因的线索——完全没有归因线索的功能，即使行为本身正确，也可能因为缺口本身而损失用户信任。
方法论注意点：这类研究大多来自高风险人因场景（航空、核电控制室），操作者受过专门训练、对系统抱有较高的性能预期；普通消费产品用户的容忍阈值和归因习惯可能不同，结论移植时需要保守。
边界
- 解释缺口只在用户确实注意到了这次异常结果的前提下才会出现；如果异常结果本身很不显著，用户根本没意识到发生了什么不寻常的事，也就谈不上后续缺不缺解释。
- 如果环境本身已经提供了足够的上下文线索能让用户自行归因（比如结果延迟出现，但界面上一直显示着进度条），缺口可能根本不会打开，不需要额外的显式解释。
- 这条描述的是缺口打开的那一刻发生了什么，不涉及缺口打开之后应该如何被填补、多快填补效果最好——那要看接下来发生了什么。这里讨论的是违背刚发生、缺口刚出现的窗口期：这个时候用户还没来得及为这次经历形成新的稳定信念，也是这个窗口期决定了后续填补是否还有效。
怎么落地
- 对每一个可能让用户困惑"为什么会这样"的系统行为，检查界面当下是否给出了任何归因线索——哪怕只是一句"因为网络较慢"这样的简单说明，也比什么都不给要好，完全的沉默才是缺口真正打开的地方。
- 优先排查那些结果与预期差距最大的行为点：差距越大，用户越难自行猜出合理原因，解释缺口出现的概率也越高，这些点应该被优先补上归因线索。
- 验证办法：记录一批用户在遇到非典型系统行为后的即时反应（口头或文字），统计其中包含"不知道为什么""这是什么意思"这类表述的比例；比例高的行为点，就是当前解释缺口最集中的地方。