产线上的模型把一张图像判成不合格，工程师凑过去问为什么。屏幕上回一张热力图，几块区域被染成深色。图是出来了，讨论却卡住了：深色只说明这些像素对输出有影响，没说清是什么样的纹理、在什么光照下、以哪种组合构成了判据。
它回答的是“敏感”，不是“因为”
常见的归因做法，例如梯度、注意力权重、局部代理模型，测量的其实都是同一件事：输入动一点，输出会怎么变。这是敏感度，不是因果链。它能告诉你模型在看哪里，不能告诉你模型在想什么。把两者混为一谈，是很多解释需求落空的起点。
这也解释了为什么同一张图，换一种归因方法，深色区域就挪了位置。方法之间并不矛盾，它们只是从不同角度切同一块蛋糕。麻烦在于，看图的人往往默认自己看到的是唯一答案。
先证明解释本身可信
如果一个解释换个随机种子就变了样，它作为证据的价值就有限。所以在把可解释性接进流程之前，值得先问几个笨问题：重复跑几次，结论稳不稳？输入加一点噪声，解释会不会翻转？换一版模型，解释的变化和性能的变化对得上吗？这些问题没有漂亮答案，但它们决定了解释是能用于排查，还是只能用于汇报。
工程上常见的做法是把解释和决策一起存档：输入、输出、归因结果、当时的模型版本。等到事后追查，至少能确认当时看到的是什么，而不是靠回忆重建。
向谁解释，决定了它长什么样
同一个模型，面对的人不同，需要的解释也不同。调试的人要的是反常样本和异常激活；做审核的人要的是边界条件和失效范围；终端用户想知道的往往不是机制，而是一个能对上自己经验的说法。这三者很难用同一套输出满足。把可解释性当成一种产品能力，而不只是一个技术指标，讨论才容易落到实处。
有些东西解释不了，也不该硬编
当模型依赖的是高维、分布式、在人类语言里找不到对应词的表示时，硬要生成一段通顺的说明，风险是造出一个听起来合理、实际与计算过程无关的故事。这种叙事对使用者是安慰，对追责是干扰。承认“这里只能给出相关性，给不出机制”，比包装一个完整解释更诚实。
更务实的边界是：在需要人做最终判断的环节，解释是辅助；在需要自动化闭环的环节，解释的作用是监控与回归测试，而不是说服。
回到那张热力图。它其实有用，只是用途被说错了：它是排查的入口，不是结论。可解释性真正难的地方，不在算法能不能画出图，而在我们是否愿意先界定清楚：这张图给谁看，用来支持哪个决定，以及当它和人的直觉冲突时，谁说了算。