一次方案评审里，模型给出判断，旁边附了一段听起来顺理成章的理由。房间里的人分成两拨：有人觉得这已经足够说明问题，有人追问，这段理由是模型真正的决策路径，还是事后补上的说法？这个场景几乎每次讨论可解释性都会出现。问题不在于理由好不好听，而在于它面向谁、解决什么疑问。
解释不是一份通用说明书
工程人员想看输入变化如何影响输出，业务人员想知道这次判断是否偏离常见情形，管理者关心责任能不能落到具体环节，外部使用者则想知道自己有没有被不公平对待。这些需求都叫解释，却很难由同一种图表或同一段文字满足。把可解释性当成模型附带的一份通用说明书，往往会让各方都拿到不痛不痒的信息。
看起来合理，和真的可解释，中间有距离
事后解释尤其容易让人放松警惕。模型先给出结果，再由另一套方法生成特征重要性或自然语言说明，这些说明能帮助人排查，也可能只抓住相关性。特征重要性不稳定、换个样本就变样，并不罕见；自然语言理由读起来顺畅，也不代表它忠实还原了内部计算。麻烦的是，人一旦看到像样的理由，就容易降低继续追问的意愿。
解释要放回工作流里检验
与其问“这个模型可不可解释”，不如问“在这个环节，谁需要拿解释去做什么决定”。如果解释用于发现数据漂移，就要看它能否稳定指向可疑输入；如果用于人工复核，就要看它能否暴露不确定性，而不是只给一个自信的结论；如果用于对外沟通，就要避免把局部解释包装成完整因果。可解释性在这里更像一套协作安排，而不只是一个技术指标。
- 解释是否说明了适用范围，还是把局部现象说成普遍规律；
- 同一输入在相近条件下，理由是否稳定，变化能否被追踪；
- 解释能否指出模型不确定或可能出错的地方；
- 人拿到解释后，是否知道下一步该复核什么、记录什么。
边界比承诺重要
可解释性不是给模型套上一层让人安心的外壳。复杂模型很难被完整翻译成几句人话，简单模型也不天然透明，特征一多，人同样会迷失。现实的做法是承认解释有边界：哪些结论来自模型，哪些来自人的补全，哪些只是待验证的假设。把边界写清楚，本身就是在维护可信。