42 篇博文 含有标签「ux」

打开你的智能体产品，开启 VoiceOver，然后发送任意提示词。如果你使用的是典型的带有内联推理过程的流式 UI，那么你在接下来的 30 秒内听到的内容并非你的产品。那是一股汹涌的局部 token 流、单词中间的重排、无人播报的状态变化，以及一段视力正常的用户选择查看、但盲人用户却无法逃避的推理独白。在舞台上演示效果极佳的界面，对于屏幕阅读器来说，是一场以语音形式发起的拒绝服务攻击。

这是 AI 团队中没有人会运行的审计。设计评审批准了流式动画。评估套件测量了回答质量。延迟仪表盘追踪了首个 token 响应时间。但这些工具都没有注意到，让某一群体感到产品快速且贴心的功能特性，却让另一群体完全无法使用。这种疏忽正开始出现在亲自诉讼申请中——过去十年一直在处理针对电商网站无障碍投诉的联邦法院，现在看到的 AI 界面相关投诉正急剧增加，据一家追踪机构报告，仅在 2025 年，同比增幅就达到了 40%。

第一代 AI 助手表现得很礼貌。你输入，它们回答。第二代则不再等待。它会观察你的日历、扫描你的收件箱、阅读你的代码库活动，并在你提出任何要求之前就抛出“你应该知道这个”之类的打扰。这种宣传极具吸引力，演示也令人着迷。但一旦这些功能上线，留存曲线却并不理想。

发布会幻灯片上没人会放这样一个数字：用户对来自所有渠道的未经请求的 AI 更新有一个每日上限，总和大约只有三到五个。如果一个主动式智能体在一周内发出了第十条通知，那么用户在周五就会将其静音，并在下个月将其卸载。这不仅是一个 UX 打磨问题，更是整个主动式 AI 领域的架构盲区，它值得拥有一个名字：通知预算（notification budget）。

用户对 AI 功能的校准（calibration）是你交付的最昂贵的东西之一。这耗费了他们数周的注意力：学习哪些提示词有效、模型在何处可靠、何时需要复核，以及哪些内容应完全忽略。然后，一次显而易见的失败——生成的报告中出现错误数字、用户粘贴到演示文稿中的幻觉引用、或者是他们根据一个自信但错误的建议采取了行动——都可能在一次会话中让这一切化为乌有。恢复曲线是不对称的。用户的先验预期（prior）是“这是可靠的”，而这次更新并不是作为一个数据点出现的。它更像是一种背叛。

测量 DAU 的团队在数周内看不到任何异常。用户出于习惯继续打开应用，运行几次查询，不对输出结果采取行动，然后悄悄地停止使用。等到参与度指标（engagement metrics）出现波动时，导致这一结果的信任事件已经发生了两个月，团队中甚至没人记得当时发布了什么。

打开任何采用固定订阅制的 AI 产品的单用户成本仪表盘。其形状总是一样的：一条长长的、几乎无法产生显著影响的扁平尾部，以及顶部一个细长的尖峰—— 5% 的账户消耗了 80% 的推理预算。这个尖峰对处于两端的两类用户都是隐藏的。重度用户不知道自己在补贴其他人——他们以为价格就是那个价格。轻量用户不知道他们可以要求更多——他们以为限制就是那个限制。

仪表盘始终保留在工程团队内部，因为产品经理担心暴露它会吓跑用户。但事实恰恰相反。隐藏成本的团队最终会推出无声的限流、隐藏的模型降级以及导致用户认为“这产品坏了”的答案截断。而那些将成本作为刻意的 UI 界面（而非后台管理页）展示出来的团队，则能将同样的成本上限从流失驱动因素转变为商业化杠杆。

这就是 AI 钱包。它不是一个账单页面，而是一个产品原语（product primitive）。

一名用户向你的购物智能体询问“150 美元以下、足弓支撑良好的跑鞋”。智能体尽职地返回了 12 个选项，但它们表现为单个聊天气泡中一长串超出视口的子弹点文本。用户滚动屏幕，找不着看到哪了，然后输入“只显示 Asics”——此时，你的智能体重新运行了整个搜索，而不是过滤它已经拥有的结果集。三轮对话后，用户正在通过一次一个提示词来发明一种查询语言，而你的产品感觉就像一个披着聊天气泡外壳的命令行。

这是我不断看到团队在交付时陷入的失败模式。他们在用户实际上想要的分面搜索（faceted-search）产品之上构建了一个聊天产品。模型没问题。检索也没问题。问题出在 UI 上，它的形态不适合这项任务。

我能给出的最简短的结论是：聊天是一种输入模态，而不是输出模态。智能体的职责是将用户意图转化为结构化查询。一旦结果集超过三项，正确的做法是渲染 UI，而不是继续说话。

推理模型会输出思维链（chain-of-thought）轨迹，因为这是它的计算方式。产品团队在 UI 中渲染该轨迹，是因为隐藏它感觉像是丢掉了用户付费购买的 token。这是两个不同的决定，而产品端几乎没有人意识到他们做了第二个决定。于是，轨迹变成了面板，面板变成了功能，功能有了文档页面。六个月后，有人在季度回顾中问，为什么支持队列里全是用户在反驳推理过程，而不是针对答案本身。

推理轨迹本质上是调试输出。它的存在是为了让工程师了解模型为什么选择某个工具、在日期上含糊其辞，或者在段落中间悄悄切换了角色。在没有经过设计审查的情况下将其推给终端用户，等同于在生产环境中留下 console.log 调用并称之为“透明度”。它看起来像个功能，渲染成本几乎为零，但它会以团队构建的任何仪表盘都无法显示的方式悄悄削弱信任。

行动前先询问的 AI 系统显然更可靠。它们能避免不可逆的错误，在误解扩散前将其暴露出来，并在第一次真正的尝试中生成更高质量的输出。

问题在于，这一原则的大多数实现都是 UX（用户体验）的灾难。它们不是问一个好问题，而是问三个平庸的问题。那些本只需要澄清十个词指令的用户，最终陷入了五轮审讯式的对话，这比直接做错任务然后再修正还要耗时。可靠性带来的优势消失殆尽，取而代之的是用户的放弃。

这是一个设计问题，而不是模型能力问题。模型完全有能力提出精准、高价值的问题。缺失的是一种强制收敛的架构约束：一种将多轮澄清视为需要通过工程手段解决的故障模式（Failure Mode），而不是一种可以依赖的特性的规则。

每个构建 AI 产品的团队都面临同一个路口：AI 应该为人类提供建议，还是自主行动？这个问题听起来很有哲学意味，但答案实际上是可以量化的——而且弄错代价高昂，往往在上线六个月后才会显现，那时你的覆盖率指标看起来很好，但用户信任分数已经在悄悄崩溃。

Klarna 在 2024 年初用一套自主 AI 系统替换了 700 名客服人员。到 2025 年，CEO 承认他们"走得太远了"，并悄悄开始为复杂案例重新招聘人工客服。该 AI 在一个月内处理了 230 万次对话，将问题解决时间从 11 分钟缩短到不到 2 分钟。数字看起来很漂亮。但根本问题——金融产品的客户服务需要同理心和判断力，而不仅仅是解决速度——在所有偏离常规路径的场景中，以下降的满意度形式滞后显现。

贷款申请被拒。候选人在招聘流程中被过滤掉。医学影像工具将某张扫描标记为异常。在每一种情况下，AI系统都做出了一个至关重要的决定——而用户毫不知情其背后的原因。

构建这些系统的团队往往花费数月时间调整精确率、召回率和输出质量。他们进行A/B测试，迭代提示词，最终交付了一个94%准确率的模型。但他们从未构建那个告诉用户发生了什么的层。这就是解释债务：在没有归因、置信度信号和申诉机制的情况下发布AI决策所积累的代价——这些要素本可以让决策具有可解释性。

当 Google 的 AI Overview 建议用户在披萨酱中加胶水，并为了消化健康而吃石头时，这不仅仅是让产品团队蒙羞——它暴露了我们在思考 AI 可靠性方面的系统性鸿沟。失败的原因不仅在于模型错了。失败的原因在于模型在高度受关注的情境下“自信地”犯错，而且没有为被误导的用户提供任何补救路径。

对 AI 系统的信任并非逐渐流失。研究表明，它遵循一种“悬崖式”崩塌模式：一个明显的错误就能导致信任度大幅下降，并产生可衡量的影响。只有 29% 的开发者表示他们信任 AI 工具——尽管采用率攀升至 84%，但这一比例比前一年下降了 11 个百分点。我们正在构建人们虽然在使用但并不信任的系统。当你的产品发布了代表用户行动的智能体 (agentic) 功能时，这种差距就显得至关重要。

本篇文章讨论的是工程师和产品构建者在错误发生“之后”应该做什么——而不仅仅是如何预防错误。

用户与 AI 助手进行了一个小时的长代码会话。他们建立了规范，分享了代码库上下文，并详细描述了一个多文件重构方案。接着，在第 40 条消息左右，AI 开始给出忽略其“已知”一切的建议。它推荐了一个用户二十分钟前已经拒绝的方案。当被追问时，它显得很困惑。

没有显示任何错误。没有出现任何警告。模型只是静默地丢弃了较早的消息，以为新消息腾出空间——而用户得出的结论是，该 AI 不可靠。

这不是模型失败。这是产品设计失败。

大多数团队都以相同的方式发现了同步 UI 的问题：用户点击"生成报告"，然后浏览器标签页陷入沉默长达四十秒。没有加载动画，没有进度提示，只有一个冻结的按钮。一半用户刷新页面并重复提交。另一半用户认为产品出了故障，直接关掉标签页。

根本问题不在于智能体的延迟——而在于 LLM 驱动的智能体所处的时间尺度，打破了同步请求-响应 UX 所有内置的假设。单次 GPT-4o 调用平均需要 8–15 秒。一个搜索网页、读取三份文档、写初稿再格式化输出的多步智能体，可能需要两到四分钟。你无法通过优化智能体来让这感觉变快，必须重新设计后端与 UI 之间的契约。