及时解释与事后补充解释对模型修复的效果不同，及时性本身有价值
别名: just-in-time explanation · timely feedback · 即时解释
概念解释
同一句解释，紧跟着违背发生时给出，和延后一段时间——用户主动去帮助中心查、或者产品事后补一条公告——才给出，对模型修复的效果并不一样。及时性本身是一个独立起作用的变量，不是"反正迟早会解释"就等效的东西：越晚给出的解释，需要做的工作越多，效果通常也越弱。
机制
违背刚发生的那一刻，这次异常结果还清晰地留在用户的工作记忆里，被标记为"尚未解释、需要处理"的状态，用户对这件具体事情的注意力也处于短暂的高点——这是一个信息容易被接住的窗口。此时给出的解释可以直接挂到这个还新鲜、还带着待解标记的记忆痕迹上，模型更新几乎是一步到位的。
一旦这个窗口过去，几件事同时在起副作用：具体的记忆细节开始模糊或被重新解读，用户往往已经不再指望能得到解释，注意力也转移到别处；更关键的是，用户很可能已经自己找了一个临时的说法去搪塞这次异常，不管这个说法有没有说出口、有没有被意识到。这时候再给出解释，要做的不是"填一个空白"，而是先要把这个已经占了位置的临时说法请出去，然后才能把新解释放进去——同一句话，做的工作量变多了，效果自然打折扣。
怎么研究
这条通常通过控制解释呈现的时间点来验证：让被试经历同一个系统异常，分成"违背发生后立即给出解释"和"延迟一段时间后给出同样内容的解释"两组，比较两组随后对该异常的归因准确率与信任评分。
常见自变量：解释呈现的延迟时长、延迟期间用户是否被要求继续执行其他任务（占用工作记忆）。 常见因变量：延迟后被试对异常原因的复述准确率、对系统的信任评分变化、是否已经自行形成了一个替代性解释（可通过延迟组在收到官方解释前的访谈判断）。
在界面研究里，这套方法常用于评估错误提示与帮助文档该由谁承担解释职责——如果延迟组已经普遍在收到官方解释之前就形成了自己的说法，说明当前产品把解释职责放在了用户需要主动查找的位置，及时性被系统性地牺牲掉了。
方法论注意点：实验室里的"延迟"通常是研究者人为设定的固定时长，真实场景里用户是否会去主动寻求解释、多久去找，个体差异很大，实验室里测出的延迟效应曲线不能直接当作真实场景下的时间阈值使用。
边界
- 及时性的收益是有上限的，不是越即时越好——违背发生的瞬间如果强行插入解释，可能打断用户正在做的操作，产生的干扰成本要和解释缺口本身的成本一起权衡。
- 只有当违背本身对用户来说是足够显著、被主动注意到的，及时性才谈得上——如果用户根本没意识到发生了异常，提前给出的解释反而可能是在提醒一个原本不会被注意到的问题，收益要打折扣。
- 这条讲的是同一段窗口期内、及时程度不同的两种做法的效果差异，不涉及窗口期结束、模型已经在别的信念上定型之后再补解释的情形——那已经是另一种局面，及时性带来的优势在那种局面下不再适用，因为可修复的窗口本身已经关闭。
怎么落地
- 把解释和触发它的异常绑定在同一个交互时刻呈现：在异常结果出现的界面位置直接给出归因线索，而不是把说明放进用户需要主动点开的帮助中心或事后才发的公告。
- 对已知会触发困惑的功能，提前设计好"异常发生时应该显示什么"，而不是等用户反馈"看不懂"之后才临时补一条说明——补救本身已经错过了最容易起效的窗口。
- 验证办法：比较同一异常在"界面内即时提示"与"需要用户主动查找帮助文档"两种呈现方式下，用户在事后访谈里对该异常原因的复述准确率，差距越大，说明当前产品在及时性上损失的修复效果越多。