模型在第一句说“答案是肯定的”。到了第三段，它又改口说“实际上，经过反思，不——原因如下”。最终状态是正确的。但用户已经离开了。他们读了第一段，将其视为答案，并在模型完成修正之前就付诸行动了。你的评估认为该回答是正确的。但你的用户得到的却是错误的。
这是流式传输 UX 所隐藏的失败模式。逐字渲染（Token-by-token rendering）将每个区块都视为既定事实，但模型并没有“提交”（commit）的概念。在模棱两可的话语和结论之间没有边界，也没有信号表明“接下来的两段将推翻我刚才说的话”。界面将中间状态作为最终状态发布，且回答越长，这种差距就越严重。
流式传输是一种“读未提交”的 UI
数据库对此有一个专门的术语：脏读（dirty reads）。事务正在进行中，磁盘上的值尚未提交，而读取者看到的却是可能回滚的状态。业界很久以前就认定，在不告知用户的情况下显现脏读是一个 Bug —— 大多数数据库默认采用“读已提交”（read-committed），即只有在事务完成后你才能看到这些值。
流式 LLM 输出默认就是“读未提交”的。模型在生成时将其写入可见缓冲区，而读取者没有隔离边界。每个 Token 的视觉权重都与最终答案相同，因为在渲染时没有任何信号表明它是临时性的。对于那个使用接下来的 800 个 Token 来修正立场的推理模型，从 UI 的角度来看，它只是在输入更多的文字。
流式传输最初的理由依然成立：首字时间（TTFT）可以从 10 秒缩短到几百毫秒，感知延迟方面的优势是实打实的。TTFT 低于 1 秒可以保持用户的思路连贯。而 10 秒则是注意力的极限。因此，流式传输以隐形成本为代价赢得了感知竞争：用户在模型完成思考之前，就已经开始阅读并做出决策了。
在短回答中，这是不可见的。第一句话就是唯一的句子。但在任何长到足以包含修正的回答中，权衡就发生了逆转。模型在后续的 Token 中不断自我修复，而用户早已离开了。
矛盾从何而来
这不是流式传输的 Bug。矛盾根植于现代推理模型生成文本的方式中。流式传输只是在错误的时间让它们变得可见。
这种模式出现在多个地方。**修复错误（Restoration errors）**在思维链研究中已有充分记录：模型在第二步出错，在第四步意识到错误，然后默默修正，并像从未出错一样给出修正后的答案。即使最终答案正确，推理轨迹内部也是不一致的。**隐式事后合理化（Implicit post-hoc rationalization）**则更糟：模型通过一条路径确定了答案，然后构建了一个听起来很自信的理由，但这与它得出结论的实际路径并不匹配。单次回答内的自我矛盾 在评估套件中也屡见不鲜 —— 模型会在同一个段落中肯定又否定逻辑上互不兼容的主张，特别是当问题引导其模棱两可时。
推理模型，特别是那些被设计为“大声思考”的模型。它们的训练奖励在可见推理过程中的探索，包括撤回错误的中间立场。这正是你在私下深思熟虑时想要的行为。但当这种思虑被逐字流式传输到面向用户的界面时，这种行为就会造成破坏。
长上下文任务让情况变得更糟。回答越长，模型就越需要撤回、限定或反转。开头信心满满，三段之后却加上“然而，数据也显示……”的摘要，并不是一种奇特的失败模式 —— 它们是任何涉及权衡证据的任务的常态输出。
评估错过了它，因为评估看到的是完整回答
标准的评估流程是在生成完成后读取完整回答，并对照参考答案进行评分。最终状态的正确性是核心指标。按照这个指标，一个说“是 —— 实际上不是 —— 原因如下”的回答，与一个直接说“不，原因如下”的回答得分相同。
用户不会在生成完成后才阅读完整回答。用户阅读第一段，决定是否继续读下去，并经常直接离开。聊天机器人界面的眼动追踪显示，注意力集中在开头 —— 而这恰恰是最有可能被修正的区域。评估衡量的东西与用户收到的东西并不是同一种产物。
缺失了一个关键的质量维度：回答内部的一致性（within-response coherence） 。回答在流式传输过程中的任何时间点是否出现自相矛盾？如果用户在任何合理的截断点（第一句、第一段、中途）停止阅读，他们能否正确理解模型的最终立场？
这个指标的计算非常直接。获取流式回答，按句子或段落边界进行分割，然后询问裁判模型：每个截断点的结论是否与最终结论一致？如果一致性曲线下降后又回升，那么你的模型就在产生这种“自我修正”模式。下降的部分就是你的矛盾窗口。它持续的时间越长，带着错误答案离开的用户就越多。
引入这一指标的团队通常会不安地发现，那些他们最为推理质量感到自豪的回答，往往也是流式一致性最差的。思考周密的模型，其修正过程也是显而易见的。
弥合差距的模式 这里有四种实用的方法，实施成本大致呈上升趋势。
答案优先提示 (Answer-first prompting)。 最廉价的补救措施是改变响应结构：要求模型在给出理由之前先给出结论。“请用一句话说明你的最终答案。然后解释你的推理过程。” 这本质上是输出预填充 (output prefilling) —— 一种在多选题 (MCQ) 评估中有着悠久历史的技术 —— 应用于长文本输出。第一段成为了一个提交 (commit)；随后的理由不能在不产生自相矛盾的情况下撤回提交，而模型训练中会刻意避免这种矛盾。代价是由于模型在充分探索前就进行了提交，你会损失一些推理质量。但对于任何用户主要阅读第一句话的界面来说，这都是值得的。
延迟提交直到标记位 (Deferred commit until a sentinel)。 保持流式传输挂起，直到模型发出已知的标记 —— 如 <answer> 或章节标题 —— 然后才开始渲染。用户等待首字延迟 (TTFT) 的时间变长了，但收到的响应顺序与提交顺序一致。当基础任务确实需要模型在得出结论前进行深思熟虑，且你无法信任模型能以答案开头时，这是正确的模式。
双阶段流式传输 (Two-pass streaming)。 第一阶段是静默的：模型在内部生成，可以选择进行自我验证，只有在确定最终立场后，第二阶段才会将润色后的答案流式传输给用户。ReVISE 风格的框架和验证循环属于这一类。TTFT 会增加，但你用更差的感知延迟换取了一个稳定的响应，它不会在读者面前自我修正。对于高风险场景 —— 医疗、法律、金融 —— 这是唯一安全的默认选择。
UI 中的“修订”机制 (A "revising" affordance in the UI)。 如果你想保持快速流式传输和可见的推理过程，界面需要告知用户模型正处于思考中。通过视觉区分模棱两可或探索性的文字与已确定的答案。用删除线回滚矛盾的片段，而不是仅仅附加修正内容。这是成本最高的路径，因为它要求模型发出关于其自身提交状态的结构化信号 —— 目前的模型并不原生具备这种能力，因此你需要通过提示词工程和后处理在其之上构建。
正确的选择取决于用户如何使用响应。如果他们自上而下阅读并提早停止，那么答案优先是不可逾越的底线。如果他们阅读全文，你可以承担公开推理的代价。如果一个团队仅仅因为“感觉更快”就发布了流式功能，而没有做出这一选择，那么他们交付的 UX 感知质量会随着响应长度的增加而悄然下降。
这对交付流式功能的团队意味着什么 流式传输是一个带有推理后果的 UX 决策，而没有人为此评估过代价。默认的假设 —— 局部输出是暂时的，用户理解这一点 —— 是错误的。局部输出会被视为最终结果。在产品设计阶段仅因“感觉更快”而决定对每个响应都进行流式传输，这种影响会在模型生成的每一个长答案中累积。
将流式传输视为针对每个响应的选择，而不是全局开关。在用户会阅读全文的场景中，公开进行推理。在用户读完第一段就离开的场景中，先给答案。建立“响应内连贯性指标”并随着模型升级进行观察 —— 切换到更强大的推理模型可能会使该指标变差，而不是变好，因为更强大的推理者会进行更多修正。并且要接受，评分最终状态正确性的评估套件已不再能衡量用户收到的真实体验。
当模型推翻自己的第一句话时，它并没有撒谎。它是在屏幕上、在用户面前进行思考，而在探索和结论之间没有提交边界 (commit boundary)。界面的工作 —— 以及构建它的团队的工作 —— 就是将这个边界放在某个地方。如果你不选择放在哪里，用户会替你选择。他们会选择第一段。然后他们就会离开。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
