解释内容需要落在用户已有模型的概念上，笼统道歉无法填补缺口
别名: diagnostic message · generic apology · 归因内容
概念解释
"抱歉出错了""遇到一点问题"——这类话确实是一句解释性的表态，但它填不上解释缺口，因为它不携带任何可归因的原因。真正能填补缺口的解释，需要落在用户已经具备的概念上——比如用户本来就知道"网络"这个概念，"因为你的网络暂时中断"就能直接被用来更新模型；如果给出的说法本身引入了用户从没听过的新概念，效果和一句空洞的道歉没有本质区别，因为用户依然没有可以用来推导、预测下一次的东西。
机制
缺口能被填上，靠的是新信息能不能被用来重新推导出同样的结果——如果下次遇到类似情况，用户能不能凭这条解释判断会不会再发生。一句笼统的道歉里没有任何可以拿来推导的内容，它只是承认了"有异常发生"，这件事用户自己早就知道了，不需要系统来确认。
一条真正有效的解释要求把原因映射到用户已经拥有的概念上，这样新信息才能挂靠在已有的知识结构里，直接被拿来用；如果原因本身需要先解释一个全新的技术概念，用户要先理解这个新概念才能理解解释本身，等于在填补一个缺口的同时凭空制造了另一个更靠前的缺口——这类"技术上准确但用户接不住"的解释，实际效果和一句空洞道歉相差无几，因为它同样没有真正进入用户能使用的推理链条。
怎么研究
这条对应界面研究里对错误提示诊断性（diagnosticity）的评估：给用户呈现同一个错误场景的不同版本提示——完全通用的提示（"出错了，请重试"）、给出具体原因但使用系统内部术语的提示、给出具体原因且使用用户已有概念的提示——比较三者在恢复任务、后续预测任务上的表现差异。
常见自变量：提示是否给出具体原因、原因的措辞是否使用用户已有概念还是系统内部术语。 常见因变量：用户从错误中恢复所需的操作步骤数与时间、后续预测任务的准确率、对同类错误提示的信任评分。
方法论注意点：判断"用户已有概念"依赖对目标用户群体既有知识的准确假设——同一句解释对熟悉网络基本原理的用户和完全不熟悉的用户，诊断性可能截然不同，评估时不能只用一批用户的反应代表全部用户群体。
边界
- 只有当真实原因在用户已有概念里确实存在对应词时，这条做法才可行；如果真实原因本身没有日常对应物（某个内部服务超时），直接照搬技术术语没有意义，需要先做一层简化或类比，而这层简化本身要单独判断是否准确、是否会引入新的误解。
- 这条讲的是解释内容要满足的条件，不涉及解释呈现的时机——内容再对，如果给得太晚，效果依然会打折扣，那是另一层问题。
- 诊断性不是越详细越好。给出的原因超出用户能用得上的范围（列出一整条技术排查链路），多余的部分不会提升诊断性，只会增加阅读和理解成本，稀释掉真正有用的那一句话。
怎么落地
- 为每一类会触发困惑的异常结果，先列出目标用户大概率已经具备的相关概念（网络、存储空间、权限、时间），把真实原因往这些概念上靠，而不是直接把内部错误码或技术术语搬到界面上。
- 对没有日常对应物的真实原因，设计一层准确的简化说法，而不是回退成笼统道歉——简化不等于放弃解释，只是换一种用户能接住的方式说同一件事。
- 验证办法：把改写后的解释拿给目标用户测试，问"如果这个问题再发生一次，你觉得是为什么、你会怎么做"，能准确复述原因、能给出合理应对方式的比例越高，说明这条解释的诊断性越强；含糊其辞或只能重复"我不知道"的比例高，说明解释内容还没有真正落在用户能用的概念上。