跳转到内容
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 的一个坑