输出承诺问题：为什么流式自我纠正比原始错误更损害用户信任

用户向你的智能体提问。Token 开始流式输出。写到第三句时，模型写道“实际上，让我重新考虑一下——”并转向一个不同的答案。修改后的答案更出色。用户却关闭了标签页。

这就是输出承诺问题（Output Commitment Problem），它是已发布 AI 产品中被低估得最严重的 UX 失败案例之一。工程师思维将自我修正视为一项特性——模型注意到了自己的错误，这意味着系统正按预期运行。而用户感知思维则将其视为一场灾难——产品现场演示了其最初自信的断言是错误的。这两种解读都是正确的，且它们本身无法调和。

核心的不对称性在于，流式传输让思考过程变得清晰可见，而清晰的思考就是可审计的思考。一个静默地产生幻觉然后给出简洁最终答案的模型看起来很专业。而同一个模型，如果流式输出每一个不成熟的想法，看起来就像是在胡言乱语。答案的质量是相同的，但感知却截然不同。

用户锚定的是第一句话，而非最后一句话

在这里，“首因效应”（Primacy Effect）并非比喻。最近的一系列研究表明，LLM 本身在评估候选选项时也会表现出首因效应，更倾向于那些将正面形容词列在前面的选项。用户对模型输出的态度也是如此。流式响应的开头几句话设定了一个锚点，影响了后续的所有内容。

当开头的一句话被证明是错误的并被修正时，两件事会同时发生。首先，读者的工作记忆中现在有了两个相互竞争的断言，必须分辨哪个才是“真实”答案。其次，读者会根据“系统竟然需要修正”这一事实，更新他们对系统可靠性的先验认知。第二次更新比第一次更持久。用户记住“这个工具自相矛盾”的时间，会比记住具体哪个断言是正确的时间更长。

这就是为什么事后正确（Post-hoc correctness）并不是一种辩护。“但最终答案是对的”这种说法假设用户是用全新的心态去阅读最终答案。事实并非如此。他们在阅读时，首因锚点依然活跃，还带着一种新产生的怀疑，认为模型的自信度并没有经过校准。在一段明显经过修正的回复末尾表现正确，并不等同于真正的正确。

关于 AI 辅助决策的研究已经证实了这一点：用户遇到错误和正确预测的顺序会显著影响他们对系统整体准确性的感知。一个准确率为 95% 但先给出一个明显错误预测的系统，其感知准确度低于一个准确率为 85% 但开头干脆利落的系统。数学计算并不重要，顺序才重要。

流式传输并非免费——它是一种 UX 承诺

团队之所以采用流式传输，首要原因是为了降低延迟。首个 Token 的响应时间（Time-to-first-token）是一个真实的指标，等待 8 秒才看到缓冲完的响应会让人觉得产品坏了，而 8 秒的流式文本输出则不会。这是实实在在的。但团队往往忽略了流式传输也包含一个隐含的承诺：用户看到的每一个 Token，都是模型认可并负责的。

一旦你做出了这个承诺，中途的修正就会破坏它。用户对流式传输的心理模型是“AI 正在打出答案”，而不是“AI 正在大声思考，而答案在最下面某处”。当你的产品说出“实际上，让我重新考虑一下”的那一刻，你就暴露了这两者从头到尾就是两回事，而用户现在必须透过这个滤镜去重新审视你刚刚告诉他们的一切。

陷阱在于，随着模型能力的提升，这个问题往往会变得更糟，而不是更好。更强大的模型更有可能发现自己的错误；更强大的模型会产生更长、更复杂的输出，从而为流式中途修正提供了更多的空间。而且，更强大的模型往往通过 RLHF 固化了自我修正模式，因此修正行为并非偶然，而是一种训练出来的反射。你得到了一个能捕捉更多自身错误的模型，但其 UX 却以最具破坏性的方式展示了这些纠错过程。

先规划，后承诺

架构上的解决方法是将流式传输混为一谈的两个阶段分开：一个是模型可能进行自我修正的“探索阶段”，另一个是产生面向用户输出的“承诺阶段”。在探索阶段，模型可以做任何它需要做的事——起草、重新考虑、转向、重试。在承诺阶段，流式传输给用户的文本应该是系统准备好负责的内容。

具体操作如下：

• 大声规划，静默承诺，然后流式输出。 模型在第一遍生成一个计划或大纲。该计划不向用户展示（或者展示在一个界限清晰的“思考”区域——见下文）。一旦计划确定，模型就会生成最终答案，这就是流式输出的内容。用户看到的是打字动画，但内容不再是探索性的。
• 先生成再验证，而非边生成边修正。 使用独立的验证步骤在草案展示前对其进行检查。如果验证失败，系统在开始流式传输前重新生成。用户永远不会看到失败的草案。
• 在正确性可检查的情况下使用受限生成。 对于结构化输出（JSON、函数调用、引用），从一开始就将解码限制在有效输出范围内，而不是让模型随意发挥然后再纠偏。结构化输出的纠偏对下游用户来说几乎总是显而易见的。

这种做法的代价是首个 Token 的响应时间。你是在用延迟换取承诺。在实践中，这种权衡通常是值得的：晚到 2 秒但稳定的响应所带来的感知质量，优于立即开始但明显摇摆不定的响应。这是一个基于经验的断言，应该在你的产品中进行衡量，但先验结论应该是：承诺值得这几秒钟的等待。

优化界面的分类法

并非所有的流式变更（mid-stream changes）都是平等的。失败模式并不是“模型在屏幕上进行思考”——而是“面向用户的答案文本被撤回”。构建正确的产品意味着要清晰地划分这些界面，以便优化发生在用户已经预先达成共识、将其视为暂定内容的区域。

大致按对信任损害从大到小的顺序排列：

硬承诺（Hard commitments）。 作为响应呈现的最终答案文本。永远不应在流式输出过程中被撤回。这是承诺问题影响最严重的界面。

可舍弃的草稿（Dismissible drafts）。 用户在将其纳入对话之前可以看到并接受、重新生成或编辑的预览。修改草稿是符合预期的——这正是草稿的用途。

界定的思考区域（Delimited thinking regions）。 一个边界清晰的区块，通常是可折叠的，标记为“推理”或“思考”。目前的产品趋向于采用默认折叠、带有展开控件的方框。Claude、ChatGPT 和 DeepSeek 都推出了这种模式的变体，但在详略程度上各有默认设置。在思考区域内，自我纠正不仅被容忍，而且是被预期的——用户已经预先同意将其视为“正在进行的工作”。

规划步骤（Planning steps）。 枚举出的“我将首先执行 X，然后执行 Y”文本，通常以清单或待办事项的形式呈现。修改计划看起来是灵活应变的，而非无能，因为计划本就应该是变化的。

工具调用叙述（Tool call narration）。 “正在搜索文档……”、“正在运行查询……”——这些是会被实际结果替换的临时状态。在承诺的意义上，它们并不算真正的“输出”。

设计准则是：一个界面距离“最终答案”越远，它对修改的容忍度就越高。 当设计师让推理文本泄露到答案界面（推理变成了用户视为答案的一部分），或者当他们过于激进地隐藏推理，导致合理的修改无处安放，从而在答案中表现为撤回时，设计师就犯了错。

何时展示思考过程，何时隐藏

行业尚未就是否展示思维链（chain-of-thought）达成共识。DeepSeek 倾向于最大程度的透明。OpenAI 展示摘要。Anthropic 的产品将推理渲染在用户可以展开的折叠块中。这些做法没有一个是绝对正确的。选择取决于用户想要做什么。

当用户的任务是评判模型的推理过程，而不仅仅是消费输出时，请展示思考过程。研究助手、法律工具、在敏感系统上运行的代码智能体——在这些背景下，用户有专业义务进行验证，而看到推理过程正是他们验证的方式。隐藏它不仅显得傲慢，还会阻碍用户捕捉模型遗漏的错误。

当用户的任务是使用输出，而不是审计它时，请隐藏思考过程。消费者聊天、客服分流、草稿写作辅助——在这里展示推理会增加认知负担而不增加价值。用户必须费力地在模型的思考过程中搜寻他们想要的答案。将其折叠为简短摘要或完全隐藏才是正确的做法。

错误的观点是默认“始终显示”，因为这看起来更诚实。透明度和可用性并不在同一维度。一个暴露每一个微小思考细节的工具虽然透明，但令人疲惫，用户会学会像略过 Cookie 横幅一样略过推理块。这对信任来说更糟，而不是更好——现在用户已经习以为常，认为可见的推理区域是可以忽略的噪音，这使得它在真正发挥作用时失去了价值。

承诺破裂的运营信号

如果你想知道你的产品是否存在这个问题，请衡量以下指标：

• 单次回复的撤回率（Retraction rate per response）。 包含“事实上”、“等等”、“让我重新考虑”、“再三考虑”等词汇或等效原地编辑的流式回复比例。数值过高意味着你的模型正在用户可见的界面中进行自我修正。
• 完成前放弃率（Pre-completion abandonment rate）。 在当前流式传输完成之前，用户离开页面、重新生成或开始新消息的会话比例。如果在可见的修正语言出现后该指标飙升，则是信任受损的强烈信号。
• 第一段后重新生成率（Regenerate-after-first-paragraph）。 用户在流式传输结束后 N 秒内点击重新生成的频率。高比率表明第一段建立了用户想要逃避的锚点。
• 对修改后回复的差评（Thumbs-down on revised responses）。 与修正语言存在相关的反馈，并与没有修正语言的同等质量回复进行对比。如果质量相同的输出在包含流式修改时获得较低评分，你就直接证实了感知成本的存在。

这些指标的监测成本都不高，而且结合在一起足以让你确定工作的优先级。一个常见的模式是，工程驱动的团队将修改视为中性或积极的信号（“模型正在自我检查”），而用户指标却揭示了不同的情况。拥有数据能让你平息争议。

核心启示

流式传输让 AI 产品感觉响应迅速。它同时也让它们显得脆弱，因为可见的思考即是可见的不确定性，而用户会将不确定性解读为能力的不足。解决方法不是从你的系统中剔除自我纠正——你需要这种能力，它是你交付正确答案的方式。解决方法是将它从用户寻找承诺的界面移开，转入预设会发生修改的界面。

静默规划，在流式输出前进行验证，并且只输出你能保证的内容。在用户需要评判时展示推理，而不是在他们需要直接使用时。请记住，“最终答案是正确的”是一个必要条件但非充分条件——用户的信任是由他们所看到的序列建立起来的，一个精心选择的序列，哪怕首个 Token 稍慢，也每一次都能战胜那个速度飞快但语无伦次的替代方案。