56 篇博文 含有标签「ux」

这份事后分析读起来像是一份幻觉报告。一名用户根据一份语气笃定的建议采取了行动，但结果证明该建议是错误的——这种错误在模型正常完成输出的情况下是不会出现的。然而，追踪记录显示模型并未完成输出。在预期的 800 个 Token 中，供应商连接在第 412 个 Token 时断开了。客户端的错误处理程序记录了这次失败。但随着 Token 的到达，持久化的部分消息已被写入对话历史，在用户的 UI 中看起来与其他完整的回答毫无二致。于是用户采信了它。支持团队将该工单归类为内容质量问题，花了整整两周时间才将其转交给平台团队。

这条链路中没有任何环节属于模型故障。模型对生成的 412 个 Token 表现得非常正确。失败的原因在于流式 UI 和持久化对话历史在“什么才算是一条消息”的问题上产生了隐秘的分歧。而正是这种流式传输本应缓解的故障模式，导致这一分歧成为了权威记录。

这是乐观渲染（Optimistic Rendering）与持久化存储之间的契约。大多数聊天产品只是从教程或框架中继承了这种模式，而从未将其视为一项契约，这种鸿沟最终表现为一系列看似模型 Bug 实则不然的尾部故障。

确认对话框是 AI agent 工具箱中最廉价的安全层。它由一个字符串、一个按钮和一个回调函数组成。提议增加这一功能的项目经理在散会时，坚信该 agent 现在是安全的。开发它的工程师用一个下午就把它发布上线了。负责审计的合规检查员勾选了通过选项。而那天早上第七次看到它的用户，在眼睛还没读完标题之前，鼠标就已经移到了“确认”按钮上。

不到一周，确认步骤就不再是一个决策点，而变成了一种节奏。Agent 问：“你确定要发送这封邮件吗？”，用户回答“是”，就像别人打喷嚏时随口回一句“保重”一样自然。终有一天，Agent 会提议一个真正错误的动作——错误的收件人、错误的金额、错误的语气——而用户会带着之前确认那六个正确动作时同样的自动化反应去确认它。邮件发出后，团队写下一份事后分析，称之为“用户操作失误”。

这不是用户错误。这是系统误把“点击”的存在当成了“同意”的存在。

你的流式智能体上的中断按钮点击率仅为 0.4%。产品团队看到这个数字，得出的结论是该功能正按预期运作——大多数生成内容不需要中断，实现方案没问题，发布吧，继续下一个任务。而实际的解读应该是，这个中断按钮教会了你的用户不要去按它。在使用产品不到一周的时间里，他们就发现按下停止键会丢弃已生成的片段、清除上下文，并把他们丢回到一个空的输入框中。他们学到的教训是：宁愿忍受一个糟糕的回答，也不愿冒着丢失整个对话脉络的风险。

这 0.4% 不是使用信号，而是厌恶信号。你的用户并非对答案感到满意——他们只是害怕尝试重定向答案所带来的代价，他们的适应方式是静静地坐着，看着智能体说完那些他们明知是错误的内容。工程团队将“停止生成”视为模型调用的取消。而用户将其视为“重定向，而非重启”。这两种定义从未达成一致，导致产品发布了一个在长对话中悄悄剥夺用户主动权的功能。

发布指标看起来很干净。回答质量提升了，引用率上升了，评估套件全绿。那个用基于 Agent 的检索器替换旧关键词搜索的团队发布了产品，赢得了胜利，然后转向了下一个项目。六周后，有人注意到该界面的周活跃用户数下降了 12%，但没人能找到性能回归。其实并没有回归。Agent 运行正常。用户离开是因为以前在 200 毫秒内就能给出答案的搜索框，现在需要 4 秒钟，而发布回顾中没有任何内容涉及到这方面的预算。

这就是延迟预算转移问题，而且几乎没有人会画出能捕捉到这一问题的组织架构图。搜索框不仅仅是一个函数调用。它是与用户神经系统签订的一份为期三十年的契约：输入、查看结果、扫视、点击。200 毫秒的响应并不是某个仪表盘上的性能指标——它是当结果送达时，用户的注意力仍然留在屏幕上的原因。当搜索框背后的团队用 Agent 循环替换关键词索引时，函数调用表面看起来是一样的，但新调用的 SLA 处于一个完全不同的范畴。延迟预算从拥有索引的团队转移到了拥有 Agent 的团队，又从拥有 Agent 的团队转移到了用户身上，而唯一参加会议的只有用户。

模型在第一句说“答案是肯定的”。到了第三段，它又改口说“实际上，经过反思，不——原因如下”。最终状态是正确的。但用户已经离开了。他们读了第一段，将其视为答案，并在模型完成修正之前就付诸行动了。你的评估认为该回答是正确的。但你的用户得到的却是错误的。

这是流式传输 UX 所隐藏的失败模式。逐字渲染（Token-by-token rendering）将每个区块都视为既定事实，但模型并没有“提交”（commit）的概念。在模棱两可的话语和结论之间没有边界，也没有信号表明“接下来的两段将推翻我刚才说的话”。界面将中间状态作为最终状态发布，且回答越长，这种差距就越严重。

我认识的一位产品经理，花了两周时间排查公司 AI 写作助手的流失激增。免费用户的会话长度骤降 30%，客服收件箱挤满了"你们的模型以前很聪明，现在变懒了"的各种变体，团队第一反应是把锅甩给同一周上线的模型升级。模型其实没有变。变的是财务在季度中途悄悄收紧了按用户分配的 Token 预算，应用在用户跨过新阈值时，正在静默截断系统提示词、丢弃工具调用、缩短回答。从用户的座位看，AI 退化了。从仪表板看，一切正常。两边都对，这就是失败模式。

这种模式现在到处都是。ChatGPT 免费版触达上限后会切到一个更小的模型，产品里除了"接下来一段时间回答可能会短一点"之外没有任何标识。Anthropic 的免费层行为类似。你在任何一家之上做功能，再叠加一层自己的按用户 Token 预算用来控成本，于是你串联了两道隐形悬崖——平台的，加上你的——而用户只看到一个聊天框，无从分辨自己刚才到底踩到了哪一道。

此刻,你的产品里有一位用户,体验远好于中位数用户。不是因为他付得更多,不是因为他在不同的订阅层,也不是因为他被分到了某个特殊的实验组。他通过耐心地试探,发现这个 AI 功能只要换种方式提问,就会给出漂亮的回答。他知道哪些动词能触发结构化输出。他知道一个词的追问会得到精简版本,一整句话则会得到展开版本。他知道某些话题如果不包装成假设性问题,助手就会戒备起来。这一切,你的网站上没有一处写过。他是逆向工程出来的。

有意思的不是这种用户存在,而是这种用户现在成了你的产品文档。你的 AI 功能跟用户之间签了一份契约——一份没公开的契约,完全编码在系统 prompt 里——而了解这份契约的唯一方式就是反复试验。只有一小部分用户有耐心去做这些试验。其余人拿到的是一个更糟糕的产品。

用户正在阅读 Agent 流式输出的推理过程。在 token 1200 附近,模型决定调用 send_email,然后 create_ticket,再 kick_off_deploy。用户看到部分输出并意识到 Agent 误解了请求,在停止按钮上慢了半秒。邮件已经发出,工单已经创建,部署已经在跑。停止按钮取消的是下一个 token,而非上一个 token 的后果。

Bug 不在取消处理程序里。Bug 是那个假设——从团队路线图上所有其他流式 UI 借来的假设——即"逐步渲染的输出"就是"逐步可逆的输出"。工具调用并不遵守这个契约。它们是时间点上的提交,流式层一边欢快地触发它们,响应的其余部分还在生成中,而取消按钮无法沿着线路追赶它们。

这是那种没人认领的失败模式,因为它存在于两个团队各自干净交付的接缝处。UX 团队上线了流式,因为用户研究中表现更好;平台团队上线了工具调用,因为框架支持。两个团队都没有开过会问:当响应已经离开大楼时,"停止"应该是什么意思?

模型已经向用户屏幕推送了 70% 听起来很自信的回答。接着，它即将进行的工具调用返回了错误、无结果或 429 错误。现在你必须在两种损失之间做出选择：让模型通过编造剩余部分来优雅地结束，或者在句子中间戛然而止，且没有体面的方式撤回。这两种都不是修复 —— 它们都是损害。

这是流式传输 UX 中没人考虑过成本的部分。流式传输被描绘成一种感知延迟的胜利：首个 Token 时间 (TTFT) 是核心指标，用户更早开始阅读，应用显得充满活力。但这种描绘忽略了你推送的每一个 Token 都是一种承诺。你发布了一个你还不知道是否正确的答案草稿，而你系统的后半部分还没有运行完毕。当它运行结束并产生分歧时，你的 UI 没有原生方法来撤回已经显示的内容。

你想要表现得诚实。你在智能体给出的每个答案旁边都标上了一个小小的 92%。当智能体第三次以 92% 的置信度给出错误答案后，你的用户就不再看那个数字了。他们并没有因此生气。他们只是学会了——就像人类在面对失灵信号时总会学到的那样——仪表盘上的指针并没有连接到引擎。数字还在那里。生成它需要消耗你的 token。但它不再能为任何人的决策提供参考。

这种失败模式是置信度校准（calibration）UX 研究不断重现的：呈现概率是一种信任承诺，而且这种承诺是单向的。一旦数字在用户的使用体验中被证明与正确性无关，这个分数就失去了意义——你为了展示它而投入的信任也随之崩塌。你无法在事后通过修正数字来挽回局面。这个数字现在只是个装饰品。

你的 AI 功能看起来很健康。周活跃用户持平或微涨,满意度评分为正,仪表板告诉你应该多做这类功能。PM 在下一轮规划会议上引用了这个指标,工程主管点头同意,路线图上又多了一个相邻功能。

然后有人按用户使用时长对图表进行分段,画面瞬间反转。老用户——那些在功能上线时就已存在的用户——每天都在深度使用它。首次用户在两次交互内就跳出了。那条"持平"的曲线其实是两个队列在相互抵消:一条向上倾斜的幂律曲线,和一条向下倾斜的流失曲线,加总成一个谎言。

一家中型 SaaS 公司的支持智能体正确处理了一起计费纠纷。它读取了工单，检查了客户账户，发现了重复收费，执行了退款，并发送了一封礼貌的确认邮件。每一步都是正确的。唯一的问题是时间戳：客户所在时区的凌晨 3:14。客户在睡梦中醒来看到退款通知，以为自己的信用卡被盗刷了，在公司有人醒来解释之前，就向银行提交了欺诈申诉。

在那个工作流中，没有任何环节是传统意义上的 Bug。智能体没有产生幻觉，没有选错账户，也没有算错退款金额。它只是完全不知道凌晨 3 点是一个告知别人资金变动的糟糕时间。这个模型读过的人类睡眠习惯相关文本比世界上任何人都多，但它的行为表现仍然像是在对待一个随时待命的服务端点，只要你调用它，它就是清醒的。