跳转到内容
Ryuyx's Blog
返回

不是测评,是拆解:各家大模型前端 UI 到底怎么做,用户感受到什么

先说重点

只拆解一件事。

各家大模型前端在过程态里,分别怎么表达“系统正在工作”。 用户又会因此感受到什么。

如果你在做 Agent 前端,这比排行榜更有用。

交互策略是稳定的。 比如有没有思考态。 有没有工具调用可视化。 有没有明确的完成信号。

这些是可以沉淀成设计方法的。

先看三个核心过程态

1)思考态

目标不是好看。 目标是降焦虑。

用户最怕的是空白。 所以思考态要明确告诉用户:系统活着,且在推进。

Shimmer / 流光效果:它不是装饰

流光效果的价值是“状态确认”。 用户需要一个持续、轻量、不中断阅读的反馈。

下面分别看三家实际产品的 shimmer 实现。

Kimi:动态扫光

光在跑,说明脑子在转。强调“正在思考,阶段在推进”。

正在思考中

用户问的是"为什么",不是"是什么"——先搞清楚意图。

这道题表面是数学,本质是一个图论问题……等等,不对。

重新推导一遍,第三步有个隐含假设需要验证。

找到了三篇相关论文,其中一篇结论和另两篇相反,先标记冲突。

整理思路,准备输出——结构:背景 → 核心逻辑 → 反例 → 结论。

z.ai(智谱):文字扫光 + 图标脉冲

扫光只作用于文字,图标独立呼吸脉冲。强调“正在分析,但不打扰正文”。

正在思考

用户问的是"为什么",不是"是什么"——先搞清楚意图。

这道题表面是数学,本质是一个图论问题……等等,不对。

重新推导一遍,第三步有个隐含假设需要验证。

找到了三篇相关论文,其中一篇结论和另两篇相反,先标记冲突。

整理思路,准备输出——结构:背景 → 核心逻辑 → 反例 → 结论。

DeepSeek:文字扫光

同一种思考展示风格,三家在动效细节上有不同的实现侧重。

正在思考

用户问的是"为什么",不是"是什么"——先搞清楚意图。

这道题表面是数学,本质是一个图论问题……等等,不对。

重新推导一遍,第三步有个隐含假设需要验证。

找到了三篇相关论文,其中一篇结论和另两篇相反,先标记冲突。

整理思路,准备输出——结构:背景 → 核心逻辑 → 反例 → 结论。

为什么很多产品不主动展示思考过程,而是让用户点击展开

这不是“藏起来”。 而是一次信息分层。

默认展开的思考过程,常见有三个副作用。

  1. 打断主任务。 用户大多数时候只要答案,不想先读一段机器自述。

  2. 拉高认知负担。 中间推理通常更长、更杂,和最终结论不在一个抽象层级。

  3. 增加误读风险。 草稿式推理里会有回退、试探、局部错误,普通用户容易把它当成“最终立场”。

所以更稳妥的做法是:默认给结果,过程按需查看。

这种“点击展开”本质上是在平衡三件事。

  1. 首屏效率。 先让用户快速得到可用信息,降低等待焦虑。

  2. 专业透明度。 需要深挖时,用户仍然可以看到过程线索、步骤和依据。

  3. 界面秩序。 把高频需求(看结论)放前面,把低频需求(审过程)放后面。

对 Agent 产品来说,这其实是一条实用原则。

默认对齐“任务完成”。 把“过程可审计”放在二级入口。 谁需要,谁打开。 既不黑箱,也不噪音。

2) 生成态

重点是节奏。

文字出现是连续推进,还是突发喷发,用户感受完全不同。

连续输出让人觉得可控。 突发输出让人觉得像黑箱。

文字流式输出的方式

三家在生成态的文字出现方式上也有各自的设计语言。

Kimi & DeepSeek:逐字流式出现

两者都采用逐 token 流式输出的方式,文字持续向前”生长”,每个 token 都在推进,体感是连续、可控的。不过在节奏上各有侧重:Kimi 更轻快,DeepSeek 更克制、强调稳定推进。

Kimi 生成中
我 给 自己 定了 十条 规矩 : 一秒半 内 必须 开口 , 说话 要 像 挤牙膏 一点 一点 给 , 代码 必须 整段 输出 , 句号 后 假装 思考 停一停 , 绝不 让 你的 浏览器 卡顿 , 你 说 停 我 就 停 且 能 续上 , 只 推送 新 内容 不 重绘 全文 , 写 长 东西 前 先 刷个 “ 加载中 ” 绝不 抢 你的 输入框 , 最后 —— 我 知道 什么 时候 该 闭嘴 。 说完了 , 再见 。
DeepSeek 生成中
我 给 自己 定了 十条 规矩 : 一秒半 内 必须 开口 , 说话 要 像 挤牙膏 一点 一点 给 , 代码 必须 整段 输出 , 句号 后 假装 思考 停一停 , 绝不 让 你的 浏览器 卡顿 , 你 说 停 我 就 停 且 能 续上 , 只 推送 新 内容 不 重绘 全文 , 写 长 东西 前 先 刷个 “ 加载中 ” 绝不 抢 你的 输入框 , 最后 —— 我 知道 什么 时候 该 闭嘴 。 说完了 , 再见 。

Qwen:分段渐显

不是一字一字滚出,而是以段落为单位逐段淡入,阅读压力更低。

Qwen 生成中
我 给 自己 定了 十条 规矩 : 一秒半 内 必须 开口 , 说话 要 像 挤牙膏 一点 一点 给 , 代码 必须 整段 输出 , 句号 后 假装 思考 停一停 , 绝不 让 你的 浏览器 卡顿 , 你 说 停 我 就 停 且 能 续上 , 只 推送 新 内容 不 重绘 全文 , 写 长 东西 前 先 刷个 “ 加载中 ” 绝不 抢 你的 输入框 , 最后 —— 我 知道 什么 时候 该 闭嘴 。 说完了 , 再见 。

3) 工具调用态

重点是透明度。

如果只看到“请稍候”,用户会不信任。 如果能看到“正在检索文档 / 正在调用搜索 / 正在解析结果”,信任感会明显提升。

工具调用态里,用户真正想看到什么

不是“系统很忙”。 而是“系统现在做到哪一步了”。

可以把工具调用可视化拆成三种常见形态。

  1. 步骤流(Step Timeline)。 适合多步骤任务。每一步有状态:进行中 / 已完成 / 失败。 用户体感:过程可追踪,等待更有确定性。

  2. 日志流(Log Feed)。 适合检索、爬取、执行这类高频事件任务。 用户体感:系统在持续工作,不是卡死。

  3. 结果卡片流(Result Cards)。 适合把“调用动作”和“调用结果”绑定展示。 用户体感:不仅看到了动作,还看到了价值产出。

一个实用细节: 把“错误步骤”单独高亮,并给“可重试”入口。 这比一句“调用失败”更能保住信任。

做 Agent 前端时,怎么选

不要问哪家最好。 先问你的场景。

场景A:知识工作台 / 长文阅读

优先策略:低干扰、弱动效、强层级。

换句话说,正文是主角,动效只做陪衬。

场景B:工具编排 / 多步骤执行

优先策略:强状态、强阶段、强可追踪。

用户需要知道每一步发生了什么。

场景C:面向大众的问答产品

优先策略:首屏反馈快,动效可感知,完成信号明确。

先解决“空白焦虑”,再优化深层细节。

一个可直接落地的过程态框架

你可以把过程态拆成四层。

  1. 状态文字层:正在思考 / 分析中 / 调用工具中。
  2. 动效层:流光、脉冲、波动。
  3. 结构层:阶段列表、当前步骤、高亮进度。
  4. 结果层:完成提示、来源、可追溯信息。

四层都在,用户基本不会迷路。

最后一句

过程态的本质,不是“炫”。

是“让用户知道系统正在做正确的事”。

当用户看得懂过程,他就更愿意等待,也更愿意信任结果。


分享这篇文章:

下一篇
iframe 里的页面为什么一直循环重定向?——SameSite Cookie 的一个坑