为信任与校准而设计

实战手册 · 智能体体验与人机交互

为信任而设计，意味着把信任校准到恰当的程度，而不是越多越好。

值得信任的智能体，不是用户信任得最多的那一个，而是用户的信任程度与其真实可靠性相吻合的那一个。生产环境中代价高昂的失败，往往不是被低估的智能体（用户只是不再使用它），而是被过度信任、自信地给出错误结果还被照单全收的那一类。本文把信任当作一个需要主动设计的校准目标，并以置信度展示、历史战绩与摩擦力作为校准的仪表。

STEP 1

目标是校准，而非最大化。

每个智能体都被两种失败模式夹在中间。信任不足：用户事事复查，智能体的速度优势被抵消，产品最终被弃用。过度信任（人机自动化文献中称为自动化自满）：用户不再检查输出，于是智能体的错误径直流向后果。设计目标——这一术语从人机自动化研究沿用进智能体体验——是信任校准：用户感知到的可靠性，应当与实测可靠性相符，而且要按任务类型分别校准，因为一个擅长摘要却不擅长算术的智能体，其真实可靠性有两个不同的值，理应对应两个不同的信任水平。

"用户很喜欢"不是衡量智能体成功的指标。一个用户喜欢却从不核验的智能体，是一起潜伏中的事故。要衡量的是信任与可靠性之间的差距，而不是信任本身。

STEP 2

自信地犯错，是你能交付的最昂贵的输出。

错误的代价并不对称。一个有所保留的错误答案（"我不确定，但可能是 X——请核验"）的代价只是一次复查。而一个自信的错误答案，代价是全部下游后果，外加对未来每一次校准的侵蚀。这种不对称意味着：当流畅度与正确性脱钩时，流畅度反而是一种负债——大语言模型无论对错都能产出同样流畅的文字，因此流畅度不能成为用户判断可靠性的信号，可默认情况下它偏偏是用户唯一能拿到的信号。你的职责，就是给用户一个更好的信号。

把结论与置信度分开。用截然不同的视觉元素呈现二者，让用户无法从精致的措辞里读出确定性。
让不确定性可读，而非装饰。"低置信度：此数字为插值推算，并非检索所得"远胜于一个笼统的 62%。
把置信度锚定在可验证的底座上。有引用、有通过的检查或有工具结果支撑的置信度值得展示；而模型裸输出的一个概率往往校准不良，应当存疑对待。

STEP 3

只在置信度会改变某个决策时才展示它。

给每一条输出都贴一个数字，只是噪声，它会训练用户彻底忽略这个通道。只在用户面临一个决策、且其正确选择取决于置信度时才呈现它——接受还是核验、发送还是暂存、自动应用还是人工审查。在其他地方，宁可用一个二元的已验证 / 未验证标记，也不要一个虚假精确的百分比。

# Confidence is a routing input, not a UI ornament
if answer.has_citation and answer.check_passed:
    render(answer, badge="verified")
elif answer.confidence < 0.6 or answer.is_extrapolated:
    render(answer, badge="verify-before-use", expand_reasoning=True)
else:
    render(answer, badge="unverified")

上线前，先用真实标准答案校准你要展示的信号。如果标为"已验证"的条目有 15% 是错的，那么这个标记是在主动制造过度信任——比完全不加标记还糟。

STEP 4

信任是按领域、随时间逐步建立的，而非全局一次性授予的。

信任不是用户设定一次的标量，它来自对某一领域内可观测战绩的累积。把这份战绩做成一等的产品界面："起草了 240 条回复，你编辑了 6 条，0 条被撤回"是用户能据以推理的校准仪表。把它呈现在用户正在决定该核查多少的地方，并限定在当前任务类别——把所有任务平均出的全局准确率，恰好掩盖了校准所需的逐领域方差。

STEP 5

摩擦力是一种信任仪表——把它花在能产生校准的地方。

确认步骤、应用前的差异对比、"展示你的推理过程"，不只是安全机制，更是校准装置。把摩擦力施加在高后果、低战绩的动作上，能逼用户去看，而这正是校准真正发生的时刻。把摩擦力施加在高战绩、低后果的动作上则纯属征税——它训练用户不读就点过，而这种习惯随后会迁移到真正重要的动作上。摩擦力的分配应当与已证明的可靠性成反比、与后果成正比，绝不能一刀切。

STEP 6

什么时候根本不该展示置信度。

如果你的置信度信号没有用实测结果校准过，就不要展示它——一个未经验证的置信度数字并不能降低过度信任，只会把过度信任洗白成用户更加信任的东西。