AI 功能的「可解释」：该解释什么、不该解释什么

可解释不是把提示词贴给用户。本文给出该解释的三件事、不该解释的三件事、不确定性该怎么具体表达、引用如何做到可核对，以及何时该不解释与一条判据。

"可解释"不是把提示词贴给用户

给 AI 功能加解释，最常见的做法是把系统提示词、检索片段、模型思考过程一股脑展示出来 ✗。

结果：用户看不懂、还可能泄露不该给的信息 ✗。

**可解释的目标是"让用户能判断该不该信"** ✔，不是"让用户看到内部实现" ✗。

1. **结论依据**：用了哪些资料（标题 + 出处），可点开看原文；

2. **不确定性**：哪里没有把握（资料没覆盖、结论依赖推断、数据可能过期）；

3. **能做什么**：不满意时用户能怎么改（换关键词、限定范围、要求只看官方来源）。

**系统提示词原文**（既无用又是注入面，见红队那篇）；

**模型内部推理**（对判断可信度帮助很有限，还可能误导）；

**内部路径与配置**（日志、密钥名、服务名 —— 属于信息泄露）。

| 别写 | 改写 |

|---|---|

| 结果可能不准确 | 该结论来自 2024-03 的文档，之后可能有更新 |

| 仅供参考 | 未在资料中找到关于 X 的说明，以下为通用做法 |

| 置信度 0.72 | 3 条资料支持该说法，1 条与之不一致（已列出） |

**要点**：不确定性要**指向具体来源与缺口** ✔，而不是加一句免责声明 ✗。

引用编号必须与**证据表**里的条目一一对应（见证据表那篇 ✔）；

做**子串级校验**：引用的原话确实出现在该来源片段里 ✔；

引用失效（来源被删/改）时要能标注出来，而不是静默保留 ✗。

极简交互场景（一句话问答）—— 解释会让界面变重 ✗；

解释会暴露隐私或安全细节 ✗；

用户已明确表示"只要结果" ✔（提供"展开依据"入口即可 ✔）。

> 好的解释应该让用户**能做决定**：信、不信、还是去核对 ✔。

> 如果读完解释他还是只能"感觉一下"，那这份解释只是装饰 ✗。

1. 先做"结论依据 + 可点开原文"（收益最大）；

2. 再做具体的"不确定性"表达；

3. 最后做"用户能怎么改"的操作入口。