"可解释"不是把提示词贴给用户
给 AI 功能加解释，最常见的做法是把系统提示词、检索片段、模型思考过程一股脑展示出来 ✗。
结果：用户看不懂、还可能泄露不该给的信息 ✗。
可解释的目标是"让用户能判断该不该信" ✔，不是"让用户看到内部实现" ✗。
该解释的三件事
- 结论依据：用了哪些资料（标题 + 出处），可点开看原文；
- 不确定性：哪里没有把握（资料没覆盖、结论依赖推断、数据可能过期）；
- 能做什么：不满意时用户能怎么改（换关键词、限定范围、要求只看官方来源）。
不该解释的三件事
- 系统提示词原文（既无用又是注入面，见红队那篇）；
- 模型内部推理（对判断可信度帮助很有限，还可能误导）；
- 内部路径与配置（日志、密钥名、服务名 —— 属于信息泄露）。
怎么表达"不确定性"（要具体，不要空话）
| 别写 | 改写 |
|---|---|
| 结果可能不准确 | 该结论来自 2024-03 的文档，之后可能有更新 |
| 仅供参考 | 未在资料中找到关于 X 的说明，以下为通用做法 |
| 置信度 0.72 | 3 条资料支持该说法，1 条与之不一致（已列出） |
要点：不确定性要指向具体来源与缺口 ✔，而不是加一句免责声明 ✗。
引用要能核对（不是装饰）
- 引用编号必须与证据表里的条目一一对应（见证据表那篇 ✔）；
- 做子串级校验：引用的原话确实出现在该来源片段里 ✔；
- 引用失效（来源被删/改）时要能标注出来，而不是静默保留 ✗。
什么时候该"不解释"
- 极简交互场景（一句话问答）—— 解释会让界面变重 ✗；
- 解释会暴露隐私或安全细节 ✗；
- 用户已明确表示"只要结果" ✔（提供"展开依据"入口即可 ✔）。
一条判据
好的解释应该让用户能做决定：信、不信、还是去核对 ✔。
如果读完解释他还是只能"感觉一下"，那这份解释只是装饰 ✗。
落地顺序
- 先做"结论依据 + 可点开原文"（收益最大）；
- 再做具体的"不确定性"表达；
- 最后做"用户能怎么改"的操作入口。