当 Google 的 AI Overview 建议用户在披萨酱中加胶水，并为了消化健康而吃石头时，这不仅仅是让产品团队蒙羞——它暴露了我们在思考 AI 可靠性方面的系统性鸿沟。失败的原因不仅在于模型错了。失败的原因在于模型在高度受关注的情境下“自信地”犯错，而且没有为被误导的用户提供任何补救路径。
对 AI 系统的信任并非逐渐流失。研究表明，它遵循一种“悬崖式”崩塌模式：一个明显的错误就能导致信任度大幅下降，并产生可衡量的影响。只有 29% 的开发者表示他们信任 AI 工具——尽管采用率攀升至 84%，但这一比例比前一年下降了 11 个百分点。我们正在构建人们虽然在使用但并不信任的系统。当你的产品发布了代表用户行动的智能体 (agentic) 功能时，这种差距就显得至关重要。
本篇文章讨论的是工程师和产品构建者在错误发生“之后”应该做什么——而不仅仅是如何预防错误。
2024 年初，谷歌的图像生成工具开始产生历史上不准确的结果，应对之策来得迅速：暂停所有人物图像生成功能。这一暂停持续了数月。想将该功能用于合法用途的用户毫无选择。等到功能重新上线时，采用率也很低——仅对一小部分订阅用户开放，受到严格限制，且声誉包袱尚未完全卸下。过度纠正本身成了一个新问题。
这是大多数团队在 AI 功能公开失败后都会掉入的陷阱。直觉没错——如果某个东西在造成伤害，就应该停止——但执行方式却错了。彻底下架功能，或者堆砌铺天盖地的护栏让其形同虚设，并不能重建信任。这只会表明你不知道如何负责任地运营 AI，也无法分辨那 0.1% 的错误输出与 99.9% 的正常输出之间的区别。
大多数团队会先发布他们最大胆的 AI 功能。那个功能通常是他们研发了六个月、演示效果极佳、且让领导层倍感兴奋的作品。但它在生产环境中失败了——算不上灾难性的，但足以让用户感到不安——于是，随之而来的每一个 AI 功能都会继承这种怀疑。即使团队后来修复了最初的问题，接下来的整整一年里，他们依然会纳闷为什么采用率始终停滞不前。
这就是“第一个 AI 功能”的问题。你首先发布的内容建立了一个先例，这种影响在技术问题解决很久之后依然存在。用户对 AI 的信任建立在第一次失败之上，而非第一次成功。你发布功能的顺序比任何单一功能的质量都更重要。
一个贷款审查工具标记了一份申请。审查员点击“解释”，得到了四个整齐的要点：过去六个月的收入波动、信用额度使用率超过 70%、最近的地址变更、两个信用记录较少的被抚养人。这些理由读起来就像一位细心的核保人员写的。审查员批准了覆盖操作并继续。
令人不安的部分是：模型从未利用这些信号做出决定。它们出现在解释中，是因为它们是那种 可以 证明标记合理性的因素——而不是因为标记源自它们。实际的计算是一种模型无法表达的狭窄潜在特征模式，加上一些解释中从未提及的相关性。这些要点是事后合理化（post-hoc rationalization），其编写目的是为了可信，而不是为了真实。
这就是空洞解释问题（hollow explanation problem），它与幻觉（hallucination）不同。该解释中的每一个单独主张在事实层面可能都是正确的。但用户的问题——你为什么这么决定？——被虚假地回答了。
模型有知识截止日期。用户不知道它是什么。产品在几乎所有情况下都不会告诉用户。当用户问了一个正确答案在三个月前已经改变的问题时，助手会给出一个言之凿凿的错误答案——这并非因为模型失效了，而是因为产品从未提供一种方式来标记这种信息鸿沟。你与用户之间的信任契约是隐性的、不对称的，并且每当世界发生变化而你的 UX 假装没有变化时，这种契约就会被悄然打破。
主流模式是将截止日期视为一个注脚：一段埋藏在帮助中心里的披露文本、一个无人阅读的 /about 页面，或者在第一周就被关闭的一次性工具提示。这种定位是一个 bug。知识截止日期不像“上下文长度”那样是模型的一个属性。它是一个 UX 界面——经过工程化、设计和演进——将其视为次要因素，会导致交付的产品在用户无法审计的语调下，围绕自身的无知进行编造。
用户向你的智能体提问。Token 开始流式输出。写到第三句时，模型写道“实际上，让我重新考虑一下——”并转向一个不同的答案。修改后的答案更出色。用户却关闭了标签页。
这就是输出承诺问题（Output Commitment Problem），它是已发布 AI 产品中被低估得最严重的 UX 失败案例之一。工程师思维将自我修正视为一项特性——模型注意到了自己的错误，这意味着系统正按预期运行。而用户感知思维则将其视为一场灾难——产品现场演示了其最初自信的断言是错误的。这两种解读都是正确的，且它们本身无法调和。
核心的不对称性在于，流式传输让思考过程变得清晰可见，而清晰的思考就是可审计的思考。一个静默地产生幻觉然后给出简洁最终答案的模型看起来很专业。而同一个模型，如果流式输出每一个不成熟的想法，看起来就像是在胡言乱语。答案的质量是相同的，但感知却截然不同。
麦肯锡 2025 年的调查发现，75% 的业务负责人正以某种形式使用生成式 AI —— 但近一半的人已经遭遇过严重的负面后果。这种差距并非模型质量问题，而是信任问题。而缩小这一差距的最快路径不是更多的评估（evals）、更好的提示词（prompts）或新的前沿模型，而是向用户准确展示智能体（agent）做了什么。
大多数工程团队将审计追踪视为事后才考虑的事情 —— 就像你为了 GDPR 合规或 SOC 2 认证而临时接入的东西，然后将其锁在只有运维人员（ops）查看的内部仪表盘中。这是错误的做法。当用户能看到智能体调用了哪个工具、检索了哪些数据，以及哪条推理分支生成了答案时，会发生三件事：采用率上升，支持工单减少，并且模型错误能比任何后端警报提早数天显现。
大多数 AI 产品复盘都聚焦于同一个故事：模型错了，用户发现了，信任瓦解了。修复方法显而易见——提高准确率。但有一种更隐蔽的失败模式，复盘很少能捕捉到，因为标准的准确率指标无法反映它：模型是正确的，但原因却是错误的，而那些检查了推理逻辑的高级用户再也没有回来。
称之为“过度声明陷阱”（overclaiming trap）。在这种失败模式下，正确的最终答案是由捏造的、事后修补的或结构不合理的推理链支撑的。它比普通的错误更危险，因为它看起来像是成功，直到你最专业的用户开始悄悄离开。
两家公司的两个产品团队，各自构建了同一款 AI 写作助手。相同的模型，相近的功能面貌，相当的准确率指标。一个团队在上线时迎来创纪录的激活率，另一个团队则在三个月的沉寂推广和一次尖锐的全员大会质疑后，悄悄下线了这个功能。
那家苦苦挣扎的公司在工程复盘中聚焦于显而易见的变量：延迟、准确率、交互打磨。但这些因素都无法完全解释这道鸿沟。真正的关键变量是信任——更具体地说，是这个 AI 功能能否借用足够多的既有信任，换来在证明自身价值期间犯错的权利。
信任转移（Trust Transfer），是决定一个 AI 功能能否落地生根的无形力量。而大多数正在打造 AI 产品的团队，从未为此进行过明确的设计。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
