devgo.cn你点下发送按钮，AI 助手转圈八秒才出结果。团队复盘时，算法工程师摊手说推理贵、模型慢，前端说等后端返回，产品经理只能把锅甩给“大模型时代”。但这个归因很可能错了——问题根本不在模型推理的八秒，而是你按下按钮后那 400 毫秒内界面毫无反馈。1982 年，IBM 研究员 Walter Doherty 和 Ahrvind Thadani 发表了一篇论文《The Economic Value of Rapid Response Time》，把“系统响应时间”和“操作员每小时完成的事务数”画成曲线，发现一个反直觉的拐点：当响应时间低于 400 毫秒，用户生产力提升的速度远超“省下的等待时间”本身。因为他们测的不是机器，而是人的注意力——人会在等待中丢失思路，被迫重新拼装上下文。这个阈值后来被 Jakob Nielsen 改写成网页三大时间极限（0.1 秒瞬时感、1 秒思维流动、10 秒注意力边缘），也一次次在电商数据里被验证：Deloitte 2020 年报告显示，0.1 秒的速度提升能让零售转化率平均提高 8.4%。但到了生成式 AI 时代，很多团队直接判定“400 毫秒是老黄历”，因为模型一次要跑好几秒。原文作者戳破这个误解：Doherty 阈值测的是“人愿意持续握住一个念头的时间”，它从未失效，只是被 AI 拆成了两段——**确认（acknowledgment）**和**答案（answer）**。一次生成式交互其实是两个事件穿同一件衣服：系统是否听到你（确认），以及回答是否合格（工作）。阈值跟谁走？跟确认走。现代聊天工具的确认动作——把你输入的 prompt 回显到线程里、把按钮变成 loading、在答案将要出现的位置放一个骨架屏——在普通手机上 50 毫秒就能完成，完全不需要等模型。但大多数产品把这两段混成一个计时器，盯着“首 token 时间”（time to first token，即模型开始输出第一个字之前的时间），然后得出“交互以秒计”的结论，据此设计交互。这正是作者称之为“拿模型的测量指标当界面的测量指标”的错误。界面有自己的预算，和推理成本无关。AI 模型被允许慢八秒，但发送按钮后的初始反馈时间不被允许。在企业软件里，这个错误会放大。微软 2025 年的遥测数据《Breaking down the infinite workday》显示，Microsoft 365 用户平均每个工作日收到 117 封邮件和 153 条 Teams 消息，每两分钟被打断一次。如果 AI 辅助的确认延迟一秒，乘以一天 270 个被打断的瞬间，就是每天四分钟的无反馈点击。消费者聊天软件容忍一个慢回合，但企业软件里的用户面前有一整条任务队列。Google 的交互到下一帧（Interaction to Next Paint，INP）标准甚至更严格：针对真实访问的 75 分位，要求 200 毫秒以内视为良好。你的输入框早就被这条标准管着，无论背后的模型做什么。流式输出（streaming，即逐字吐出答案）是很多团队最先想到的解法——让文字边生成边显示，长回答读起来像对话而不是等待。但它解决的是错误问题。Luke Wroblewski 早在 2013 年就在《Mobile Design Details: Avoid The Spinner》里指出，用户真正感受到的失败发生更早：按下去没反应、输入框清空后空白一片、推理模型花十五秒决定怎么开场时聊天窗口空荡荡。流式把等待变成阅读，但改变不了“没有内容可读的那半秒”。更麻烦的是，首 token 前的间隙会随路由变化漂移——打开深度思考、切换到更大模型、加上检索步骤，都会拉伸这段空白，而界面毫不知情。确认是唯一能稳住的东西。流式里还藏着一个更隐蔽的欺骗：系统已经卡住但进度条还在假装动，或者旁白讲述它根本没在执行的步骤。用户会原谅慢，但有被操纵的感觉时绝不原谅。所以，正确的做法是把一次 AI 交互拆成两个时钟、两套规则。第一只时钟从用户点击（回车、点按钮、触屏）开始，到界面证明“听见了”为止——回显 prompt、改变按钮状态、放好骨架。目标 100 毫秒，400 毫秒是上限。这是纯前端工作，有个硬数字，监督预算（supervision budget，即用户保持注意力去检查模型是否出错的预算）在这里花掉或省下。第二只时钟从请求发出到答案可用为止，人们可以等很久，只要等待“买”到了东西——没人会放弃一个四分钟研究跑出来的值四分钟的报告。真正破坏体验的不是时长，是沉默：没有回执、没有进度、不知道在买什么。第二只时钟的主宰规则不是快，而是诚实。Ben Shneiderman 在 1985 年的八条黄金法则里就有“提供有信息量的反馈”，这条在 AI 时代依然有效：展示真实状态，全程允许取消，乐观提交（optimistic commit，先按用户意图执行再后台验证）时要给出明确的回滚入口。这套思路能直接用在哪里？任何带 AI 助手的工具，尤其是企业协作、客服、开发者平台：聊天框、生成代码、写文档、数据分析。落地时先量一下“按下到界面确认”的时间，用性能工具测真实用户的 INP，别只看模型延迟。坑在于：确认动作不能是假动画，它必须伴随真实的可见变化；推理路由一变，要重新测确认区间。一句话，AI 产品慢的锅多半不在模型，而在你让用户在黑暗中等了多久。
内容与图片版权归原作者所有 · 原文: https://uxdesign.cc/stop-blaming-the-model-for-slow-ai-heres-how-to-design-for-it-doherty-s-threshold-as-a-guideline-5fa6d52e23fc?source=rss----138adf9c44c---4