开发者需要的是调试信息，终端用户需要的是行动依据，二者不可共用一份解释

概念解释

工程面板上的激活图、损失、特征维度名，能帮开发者判断模型是不是在看错地方。把同一张面板发给申请人，他无法用它决定补哪一页材料。开发者要的是调试信息，终端用户要的是行动依据，两份解释不能共用（developer vs end-user explanation）。

不是深浅不同的同一篇文章。是两种合格标准。

机制

调试的合格标准是：能否定位故障、复现、改模型或数据后再测。行动的合格标准是：能否在自己可控的范围内选下一步——补材料、改输入、接受、转人工。材料不同。激活图满足前者，几乎从不满足后者；「缺收入证明」满足后者，对定位哪一层梯度爆炸没有帮助。

共用一份的常见理由是省事：反正都叫解释。省事把调试词汇泄漏到当事人界面，用户会把层名、权重当成自己的义务去理解，并在理解失败时把错归到自己。Miller 把解释看成面向听众的交流；听众换了，合格答案一起换。局部还是全局改变的是范围，不改变听众。

怎么研究

同一输出分别做成调试包（张量名、激活、损失贡献）和行动包（可核对事实、可采取的动作），交给开发者与申请人两类人，各做本职任务：找出注入的故障 / 决定补什么。自变量：材料类型、是否允许两类人看到对方的包。因变量：故障定位时间、行动相关度、把调试词汇误当成个案理由的次数。

开发者在行动包上的失败，和申请人在调试包上的失败，要分开报。不能用「专业人士都看懂了」宣布终端版合格。

边界

内部工具的用户就是开发者，调试信息就是行动依据，共用成立。申请人若恰好是该领域的模型工程师，仍应按申请人任务供行动包，调试包另开入口——任务不是身份。监管审计可能需要第三份材料，既不是调试也不是对当事人的动作指导。这条不处理透明度该有多长。

怎么落地

• 做两套表面：工程后台与当事人说明。默认互不跳转；需要时用明确的「开发者视图」而不是把张量名写进拒信。
• 当事人说明里的名词必须能映射到他能改或能核对的对象。映射不上的维度名删掉。
• 评审解释功能时分两场：一场只请会修模型的人，一场只请会收到结果的人。一场通过不算另一场通过。
• 验证：遮住身份，只看文案，问「读完能修模型吗」和「读完知道自己下一步吗」。两个「能」出自同一段，多半有一段是假的；拆开重写。

延伸

• 同组：L5.02.1 局部解释说明单次输出 · L5.02.2 全局解释说明整体行为倾向 · L5.02.3 用户在不同场景需要不同层级 · L5.02.4 局部解释支持用户对单次结果的接受或申诉 · L5.02.5 全局解释支持用户判断是否值得继续依赖这个系统 · L5.02.6 由若干局部解释归纳出的整体印象常常是错的 · L5.02.7 特征重要度是相关性排序，不能被读成因果说明
• 相邻：L5.05 透明度的适度原则 · L5.01 可解释性的类型 · L5.08 反事实解释
• 站内检索：developer vs end-user explanation · debugging information · actionable grounds