解释过程与解释结果是两回事
别名: 过程解释 · 结果解释 · process explanation versus outcome explanation
概念解释
放射报告旁边写「模型沿肺野边缘扫描了高密度区」，和写「这份扫描被标为可疑」，听起来都像在解释。前者讲的是系统怎么走完这一步，后者讲的是这一步落到了哪个结论。过程解释与结果解释不是同一类话（process vs outcome explanation）：一个回答「它做了什么」，一个回答「它认为事情是怎样的」。
这条只拆这两类。事后编的故事算不算真机制、该解释的是这次决定还是整座模型，是另外的切口。
机制
人问「为什么」时，经常把两种需求叠在一句里。Miller 对可解释人工智能的综述指出，日常解释多是针对事件的对比：「为什么是这个结果，而不是另一个」。那是结果层。过程层回答的是路径：看了哪些区域、经过哪些规则、停在哪一步。两条路服务不同后续动作。知道路径，人可以判断系统是否走偏、要不要改输入再跑；知道结论的含义，人可以决定接受、改写还是转交人工。
界面若只给其中一层，缺口会被脑补成另一层。只给热力图，用户会以为那就是诊断；只给「拒绝」，用户会以为自己看见了审核流程。错配发生在需求与供给的层，不发生在字数多少。
怎么研究
把同一批输出配两种说明：过程描述（步骤、依据区域、规则触发）与结果描述（标签、分数档、建议动作），再让人完成两类任务——预测下一次同类输出、决定眼前这一份是否接受。自变量：说明类型、任务类型（预测路径 / 处置结果）。因变量：预测准确、处置一致性、主观「被解释了」评分。
Miller 的对照框架在这里用作任务分类，不是当作「解释一定更好」的结论。两种说明都可以让评分升高，必须用后续动作来拆开。
边界
对只需要执行指令的操作员，结果层往往够用，过程层会变成干扰。对要改输入再提交的申请人，没有过程就无法行动。过程描述若被写成流水账，看起来像过程、用起来仍是结果——因为它不支持任何中间干预。这条不讨论局部还是全局，也不讨论反事实「若改某个字段会怎样」。
怎么落地
- 先标清这一块 UI 回答的是哪一类问题。过程用步骤或「看了什么」；结果用结论与可采取的动作。不要用同一段话同时冒充两层。
- 需要用户改输入时，过程层必须落到可改的部分（缺了哪张单据），而不是模型内部的层名。
- 只需用户签字放行时，给结果层与后果，不给训练流程。
- 验证：遮住说明，问用户「你现在能做什么」和「你是否知道它刚才做了什么」。两问的答案应对应你实际提供的那一层；若用户用过程去回答结果问题，层已经混了。