一条帖子被系统拦下，申诉页给了一行理由：“违反社区规范，不予展示。”用户想知道具体是哪句话、哪个词触发的，页面给不出。这不是客服态度问题，是机制问题：分类模型输出的是一个分数，社区规范是人写的，两者之间没有天然的语言桥梁。
所谓可解释性，很多时候就是在事后搭这座桥。
解释是怎么被造出来的
常见的做法有一串：给输入里的每个词打分，看哪些贡献大；把注意力权重画成热力图；微调输入观察输出怎么变；再或者用一个更简单的模型去模仿复杂模型的行为。这些手段都有用，但共同点在于——解释由另一套计算生成，并不等于模型内部真的“想”过这些。
于是就出现一种微妙局面：解释看起来越顺眼，越值得警惕它是不是被优化成顺眼的。忠实度和可读性之间存在持续的拉扯，最贴近模型实际行为的解释，往往对用户最不友好；最容易读懂的，可能离模型真实的计算路径很远。把热力图当成“模型在看这里”，是一种常见的误读，它更像是对某层数值的一种投影，而投影的选择本身就带着人的偏好。
解释给谁看，决定了它长什么样
给工程师看的解释，是一张特征贡献图，用来定位问题；给普通用户的，是一句人话；给审计方的，是可复现的记录。这三者经常被混为一谈，结果谁都不满意。工程师嫌用户版太模糊，用户嫌工程版像天书，审计方则发现记录里缺了关键上下文。
我更愿意把可解释性看成一种沟通设计，而不只是算法附带的产物。它要回答的不是“模型怎么算的”，而是“在这个具体决定里，哪个输入起了作用，改动它会怎样”。反事实式的解释更接近这个目标：告诉用户改哪一处，结果可能不同。可惜它给出的建议常常不可执行，比如“把账号注册时间往前挪半年”，用户听完只能更困惑。
有些边界得先承认
还有一类系统，本质上难以逐条解释，比如参数规模很大的语言模型，一次输出背后是极长的计算路径。这时候强行生成一段解释，可能比不给解释更糟，因为它给人一种“已经查清楚了”的错觉。用户拿着这段解释去申诉、去追责，最后发现它只是又一个模型的产物。
比较实际的做法，也许是先把线画清楚：哪些决定必须能逐条说清，哪些只能在群体层面做统计说明，哪些干脆不该自动化。这条线画在哪儿，不只是技术判断，也是产品判断。一个不完美的解释，至少应该让人知道它不完美，而不是用流畅的措辞把不确定藏起来。
解释不是模型的附属说明书，它本身就是产品的一部分。做得好，用户知道下一步该怎么做；做得不好，再漂亮的理由也只是把问题往后推了一步。