解释需指向可修改的原因
别名: 可行动的解释 · 解释的可修改性 · actionable intelligibility
概念解释
解释的价值标准不是「让用户听懂」，而是让用户能行动。一条合格的解释指出的原因，应当是用户可以修改的东西——某条规则的条件、某个阈值、某个设备的安装位置。这叫可行动的解释（actionable explanation）。
反面例子是智能家居里常见的措辞：「根据智能算法判断，已为您关闭加湿器」。这句话解释了行为，但指出的原因（智能算法）不是一个用户能干预的对象——用户听完只确认了自己无能为力。可行动的版本会写成：「室内湿度已高于你设定的 60% 上限，加湿器关闭；阈值可在××设置中调整」——原因（湿度阈值）既可核查，又可修改。
区分的判据很简单：读完解释后，用户知道下一步能做什么吗？知道去哪里做吗？
机制
解释处在一条闭环里：行为显形 → 寻找原因 → 理解 → 决定是否干预 → 行动。可行动性决定闭环的最后一环能否闭合。
指向可修改原因的解释，把「理解」直接接到「修改入口」：原因本身就是系统的可配置对象，解释因此兼具诊断与调试接口两种身份。用户得到的不只是这次发生了什么，还有「下次想让结果不同，拧哪个旋钮」——控制感由此而来。
指向不可修改原因的解释（「算法判定」「模型置信度不足」）在认知上完成了理解，在行为上堵死了出口。反复几轮之后，用户学到的东西是「问也白问」，解释通道被弃用，系统的行为重新退回黑箱——可理解性投入的效果归零，还赔上了信任。
这里还叠着一层问责性（accountability）：系统把原因定位到自己内部的哪个可配置环节，等于承认该环节可被追究。拒绝给出可修改原因的系统，事实上是在声明「出问题也不归你管」。
怎么研究
- 解释类型学的延伸：可理解性研究整理的 why / why not / how-to 问题类型里，how-to 类（「怎么让它不这样」）与控制感的关系是这条知识点的直接理论来源——解释问题工具包明确把「可干预性」列为设计维度。
- 解释—干预转化实验：给被试同一意外行为的两种解释（描述性 vs 指向可配置原因），度量其后能否完成一次针对性修改、修改耗时与求助率。终端用户编程（end-user programming）研究里，把解释作为规则编辑入口的界面沿此思路评估。
- 实地相关证据：智能家居长期部署研究中，用户面对不可修改原因解释时表现出的「习得性放弃」——不再尝试调整、绕开系统——可作观察性佐证。
方法论注意点：实验里「能否完成修改」容易被界面易用性混淆——解释可行动但编辑器难用，测出来仍是失败。评估要把解释的可行动性与修改入口的可达性分开度量，否则归因错误。
边界
- 并非所有原因都可修改。 物理约束（传感器精度、信号覆盖）与安全约束（防误触的锁定）真实存在。此时解释的义务不是说谎或含糊，而是说清为什么不可改，以及可行的替代动作是什么——「不可改但可绕行」仍是可行动的解释。
- 可行动不等于立刻行动。 多数时候用户读解释只是为了确认系统没坏，不会去改任何东西。可行动性的价值在故障与不满意时刻兑现，但代价（解释里维护实体链接、保持解释与配置同步）是常付的——这笔账要算在哪些动作上，见上一条的「罕见动作才解释」。
- 粒度有隐私边界。 解释要给出能定位到可修改层面的最小信息即可，不必倾倒全部内部细节；超出必要的那部分既是负担也是暴露面。
怎么落地
- 解释里出现的每个可配置实体（规则、阈值、时间窗）都链接到它的编辑处：解释是修改入口，不是公告。
- 解释模板区分两类结尾：「你可以改」（附入口）与「系统约束」（附原因与替代方案），禁止用第三类含糊措辞（「智能优化」）收尾。
- 解释引用真实配置值（「你设的 60%」）而不是复述抽象规则名——用户要能核对自己的设置与行为的关系。
- 验证办法：给用户看十条真实解释，统计「读完知道下一步做什么、去哪里做」的比例；再抽取近期一次不满意行为，测从读解释到完成针对性修改的耗时。比例与耗时不达标，解释就还停在公告层面。