信任校准曲线：用户如何学习（误）信任 AI

大多数 AI 产品都以同样的方式走向终结。演示（Demo）很成功。测试用户赞不绝口。你发布了产品。然后，在大约三个月后，会话时长（session length）下降，功能闲置，你最活跃的早期用户开始绕过 AI，直接使用底层工具。

这不是模型质量问题，而是信任校准（trust calibration）问题。

“过度信任 → 失败 → 过度修正”的生命周期是 AI 产品采用率最可靠的杀手，而且如果你理解发生了什么，这几乎是完全可以预防的。研究已经很明确，失败模式是可预测的，设计模式也已经存在。大多数团队在看到留存曲线并想弄清楚出了什么问题之前，都会忽视这一切。

无人提及的三阶段生命周期

对 AI 系统的信任遵循一个可预测的轨迹，这在数十年前的人因研究（human factors research）中已有记录，并在现代产品数据中反复得到证实。

阶段 1：初始的过度信任（算法赞赏）

新用户对 AI 的信任建立速度比对人更快，而在出现错误后撤回信任的速度也更快。这种不对称性——对未测试系统的“算法赞赏”（algorithm appreciation），以及在看到失败后的“算法厌恶”（algorithm aversion）——在行为研究中已得到充分证实。用户将 AI 的自信解读为胜任能力。界面显示“我有 94% 的信心”，用户在没有任何基准来衡量 94% 在实践中意味着什么的情况下，就校准了他们对该数字的依赖。

自动化偏见（Automation bias）加剧了这一点。对临床决策支持系统的研究表明，在 AI 辅助的情况下，遵循错误的 AI 建议的比例比对照组高出 26%。放射科医生会撤回正确的诊断，以匹配错误的 AI 建议。开发者在没有审查的情况下接受存在安全漏洞的代码建议。第一阶段不仅仅是被动信任，而是主动的轻信。

阶段 2：刺耳的失败

在某个时刻， AI 会出现明显的、产生后果的错误。不是那种用户察觉不到的微妙错误。而是在重要的语境中，明显、露骨且令人尴尬的错误。

研究表明，单次高显著性错误（high-salience error）是信任崩溃最强有力的预测因子——其影响程度超过了所有其他测量变量，包括系统的实际准确率记录。失败不一定要频繁发生，但必须是出人意料的。用户不会追踪基础概率（base rates）；他们追踪的是显著性。一次令人难忘的失败比一百次默默正确的建议更有分量。

这就是核心的不对称性：信任通过反复成功的交互缓慢建立，但通过单次突出的失败迅速瓦解。你得到的不是成比例的信任减少，而是不成比例的崩溃。

阶段 3：过度修正到信任不足

在刺耳的失败之后，用户不会重新校准到适当的怀疑。他们会过度修正。即使在模型表现良好的任务上，他们也会开始忽略 AI 的输出。他们在所有地方都增加验证步骤，甚至是针对低风险的建议。他们会根据几周前的一次事件告诉同事“它不可靠”。有些人甚至完全停止使用该功能。

这种模式——算法赞赏后的算法厌恶——正是 74% 的公司报告尽管投入巨大仍难以实现和扩大 AI 价值的原因，也是为什么只有 6% 的组织在核心业务流程中完全信任 AI 智能体（AI agents）。产品奏效了，但信任循环没有。

为什么你对“信任”的心智模型是错误的

大多数工程师将用户信任视为一个单一的刻度盘：用户要么信任 AI，要么不信任，并根据准确率来更新这个刻度盘。这在三个重要方面是错误的。

信任是特定领域的，而非全局的。 被 AI 代码建议“坑”过的用户，并不会一律不信任同一工具的代码解释或文档。但大多数 AI 产品不会在领域粒度上跟踪信任。他们衡量总体使用情况，从而错失了信任在某些子空间正常而在其他子空间崩溃的信号。

用户不追踪基础概率。 用户依赖的正确模型应该是：“我按照在这个领域估算的准确率比例来遵循 AI 建议。”而实际的模型是：“我会一直遵循 AI 建议，直到出了问题，然后我就不听了。”用户运行的不是贝叶斯更新（Bayesian updates），而是启发式模式匹配（heuristic pattern matching），而且这些模式深受近因效应和显著性的影响。

自动化懈怠（Automation complacency）削弱了人类的独立能力。 这是一种潜伏的失败模式，不会出现在任何短期指标中。在代码、写作或分析中严重依赖 AI 建议的用户，会逐渐失去在这些领域的独立判断力。GitClear 对 1.53 亿行 AI 辅助代码的数据分析发现，与人类编写的代码相比，其代码变动率（churn rates）高出 41%——这是一个信号，表明开发者正在接受他们无法独立评估的建议。当 AI 出错时，他们抓不住。当 AI 不可用时，他们的能力就下降了。你创造了依赖，却没有创造可靠性。

“校准信任”（Calibrated Trust）的真实含义

在可靠性工程中，当一个概率模型的陈述置信度与其真实准确性相符时，它就是“经过校准的”：当它说 70% 时，它在 70% 的情况下是正确的。可靠性曲线会紧贴对角线。一个校准良好的模型即使在不确定时也是可用的，因为不确定性信号是诚实的。

同样的概念也适用于用户。当用户对 AI 的依赖程度与 AI 在该任务类型中的实际表现相匹配时，用户就拥有了“校准信任”。过度依赖（信任度超过了准确性所能支撑的范围）和依赖不足（信任度低于准确性所能支撑的范围）是对称的失败。两者导致的结果都比校准信任要差。

大多数 AI 产品都会产生失准的用户。问题在于，在任何特定时刻，这种失准是趋向于过度信任还是信任不足——这两者都会以不同的方式扼杀产品的采用。

一个较少被讨论的棘手之处是：LLM 本身就是失准的。研究显示，某些模型的预期校准误差（ECE）高达 0.726，而准确率仅为 23% ——表现出严重的过度自信。如果模型的置信度分数是错误的，那么向用户展示这些分数只会让用户的信任校准变得更糟，而不是更好。你实际上是在将模型的过度自信传播到用户行为中。

真正奏效的设计模式

CHI 2023 对 96 项关于信任校准的实证研究进行了调查，确定了证据最充分的干预措施。它们分为四个类别。

动态、情境化的置信度信息。 仅展示置信度是不够的。没有背景信息的置信度展示几乎总是会被误解。有效的方法是提供特定任务的置信度，它会根据具体的输入产生可见的变化，而不是静态地声明“AI 的准确率为 87%”。用户通过反复观察了解到置信度会根据输入特征而变化，从而开始相应地校准他们的依赖程度。一个 Google PAIR 原则是：倾向于使用定性的置信度级别（高/中/低），而不是数字百分比。“高置信度”比“87.4%”建立了一个更稳健的预期，后者暗示了模型并不具备的精确度。

主动披露局限性。 不要等待用户去发现 AI 做不到什么。在第一次失败发生之前，以具体的术语预先告诉他们。“这个助手在 X 方面表现良好，但在 Y 方面会犯错”比让用户通过糟糕的体验来发现这一点更能保护信任。研究结果是反直觉的：主动披露局限性会增加信任而不是减少信任，因为它使系统的置信度声明变得更加可信。

使信任响应成比例的错误设计。 大多数 AI 产品的失败表现形式都是单一的：输出错了，用户不开心。设计良好的失败状态会区分“AI 不确定并给出了信号”与“AI 很自信但错了”。前者应该是被预期和接受的；后者则需要进行信任修正。如果用户无法从产品的行为中区分这些情况，他们就会将所有的失败都视为系统根本不可靠的证据。

明确的范围边界。 表现最差的 AI 产品通过其界面设计暗示了其能力。一个接受任何查询的 Copilot 暗示它可以很好地回答任何查询。范围约束——明确的任务类别、输入验证、“最擅长”指南——在 AI 有机会意外失败之前就设定了用户预期。

让情况恶化的组织性失败

产品团队通常使用工程指标来衡量 AI 质量：评估准确率、延迟、单次请求成本。这些指标对信任生命周期毫无贡献。一个在评估集上准确率为 85% 的模型，如果那 15% 的错误分布在非常显著、高风险的时刻，而不是低显著、常规的任务中，仍然会导致信任崩塌模式。

没有人去修复的失败模式是：拥有模型的同一个团队也拥有信任指标，而这两者都是根据模型性能来定义的。用户信任校准需要工程团队通常不具备的行为监测手段——会话放弃率、功能绕过率、手动覆盖时间、首次失败后的回访率——而产品团队通常也不会构建这些。结果导致了一个鸿沟，即每个人都在优化的指标（模型准确率）与真正预测留存率的指标（用户信任校准）是正交的。

做得好的组织会将这些测量层级分开。他们独立监测模型准确率和用户信任校准，并将两者的背离视为需要调查的产品失败。

信任恢复是可能的——但需要设计意图

让大多数研究人员感到惊讶的实验发现是：通过精心设计的解释进行信任恢复，不仅能将信任恢复到失败前的水平，甚至可能超过它。如果用户收到了关于 AI 为什么失败的连贯、诚实的解释，并结合了它在邻近案例中表现正确的演示，那么这些用户产生的信任感可能比从未见过失败的用户更高。

其机制在于，失败使系统的置信度声明变得可信。在失败发生之前，系统一直在告诉用户“我对此很有信心”，而没有任何对比。在经过良好解释的失败之后，用户有了一个校准参考点：“当系统出错时，它的行为与正确时不同。”

这意味着失败是一个机会，而不仅仅是负资产。问题在于，你是否像设计成功体验一样，用同样的用心去设计了失败体验。大多数团队都没有做到。

为长期发展而构建

那些交付持久 AI 产品的团队，他们交付的模型并不一定比竞争对手更好。他们在显式地管理信任生命周期。

这意味着：在首次使用前设定准确的预期，而非过高的期望。将 AI 的不确定性在上下文中显性化，而不是埋没在文档里。设计能够维持适当信任的失败状态，而不是让信任彻底崩塌。将用户信任校准作为一项产品指标来追踪，而不是从总体使用情况中推测。并且愿意限制 AI 表现出的功能范围，从而确保界面所做的承诺正是模型实际能够兑现的。

信任校准并非软性的产品问题。它是让技术领先的 AI 真正被采用的机制。信任校准曲线是一个设计问题。大多数团队甚至还没有开始着手解决它。