让体验升级！超全面的AI用户体验设计要素总结（下）

一、全文速览图

从 GUI 到 Agent 协作，用户体验设计正经历一场范式转移。本系列分享将从八个核心维度，系统对比传统纯 GUI 交互与“自然语言+Agent 协作”模式的差异，并探讨 AI 时代产品设计的新原则、新工具与新心智模型。

当界面从“固定容器”变为“动态服务”时，底层的构建块（组件）该如何重新设计？

最近在重构 AI 产品平台的设计组件库看到了 Google 提出的 Agent to UI （下称A2UI）理念，借用这个逻辑我对平台的新设计组件构建有了新的理解与认知。

 二、Agent to UI 理念

1. A2UI行为逻辑

1. Agent 生成“菜单”（声明式 UI 描述）：AI Agent 进行推理，并根据需要生成一个结构化的 JSON 文件，准确描述它想要的界面。
2. 数据投递：这份 JSON“菜单”通过现有协议，实时发送给前端应用。
3. 前端“烹饪”（原生渲染）：前端应用接收 JSON 后，会将其解析并映射为自己的原生 UI 组件来渲染。
4. 双向互动：用户在渲染出的原生 UI 上操作时，交互结果会回传给 Agent，Agent 可再据此生成新的 UI，形成动态交互循环。

2. 显著特征

1. 声明式设计：AI 只描述“我需要什么”和“我的意图”，而不是具体“如何一步步画出来”的代码，开发体验友好，性能有保障。
2. 多端通用：同一个界面可以用在不同地方。一份 A2UI 描述可以同时发送给前端（Web）、iOS 或 Android 应用去渲染，保证跨平台体验一致。
3. 流式更新：界面能像 ChatGPT 流式文本回复一样逐步生成和更新，无需让用户面对白屏等待

3. 流式 UI 的体验设计挑战与策略

A2UI 的一个重要特征是“流式更新”：界面可以像 ChatGPT 的流式文本回复一样，逐步生成和更新，用户无需面对白屏等待。但当 UI 组件是一个接一个“冒出来”的时候，用户的体验会面临一些比较明显的体验问题。

① 布局抖动——用户感觉自己“抓不住”界面

现象：Agent 先生成一个文本提示，然后追加一个按钮，再追加一个卡片，最后追加一个输入框。每增加一个组件，页面高度就变化一次，用户正在阅读的内容可能被“挤”下去，或者正在准备点击的位置突然移动。这永远找不到稳定的交互锚点。

设计策略：

1）预留骨架容器

在 Agent 开始生成某个区域的内容前，前端先渲染一个与最终内容预期高度相近的骨架屏或占位符。骨架屏可以基于组件类型预设高度（如卡片占位 120px、按钮占位 44px）。即使 Agent 流式返回，页面的总体布局框架在一开始就能估计。

2）渐进式锚定注入

关键操作组件（如“确认支付”按钮）应该在生成时就固定在一个独立容器中，后续追加的内容不能插入到它的上方。可以将界面划分为“动态内容区”和“稳定操作区”，操作区的组件一旦出现就锁定位置。

3）禁用自动滚动

当新的组件追加到对话流末尾时，不要自动将页面滚动到底部——除非用户明确处于“跟随模式”（如点击了“滚动到最新”按钮）。更好的做法是显示一个“有新内容”的提示条，让用户决定何时查看。

② 状态不连续——用户想“回去”却找不到路

现象：流式 UI 是单向追加的。用户看到 Agent 生成了一系列组件后，突然想修改之前的某个选择——例如在生成了座位图后，想换一个场次。但之前的场次选择组件已经被“埋”在对话历史的上方，用户要么向上滚动找到它并重新操作，要么通过自然语言说“换一个场次”。如果界面设计没有做好状态回溯，用户会感到迷失。

设计策略：

1）显式的“状态回溯”入口

在动态内容区域的顶部提供一个“显示/编辑已选参数”的折叠条，里面汇总了用户之前做出的关键选择（场次、人数、优惠券等）。用户可以一键修改任何一项，修改后 Agent 会重新生成后续组件。

2）可逆的流式生成

每个生成的组件都应该能够被“撤销”。当用户说“不对，换一个场次”时，Agent 不仅重新生成场次选择，还应该移除后续所有依赖于旧场次的组件（如之前的座位图），然后重新生成。前端需要支持按时间戳删除已渲染的组件。

3）快照与分支

支持保存“状态快照”。用户可以主动说“保存当前进度”，Agent 生成一个快照入口。之后用户可以随时回到这个快照，分支出一条新的探索路径。这在复杂决策场景中非常有用（如比价、选方案）。

③ 认知节奏紊乱——用户的大脑跟不上界面的变化

现象：人类处理视觉信息需要时间。当界面以流式方式快速添加多个信息块时，用户可能还在理解第一个卡片的内容，第二个、第三个卡片就涌了进来。用户被迫不断中断当前的思考，去扫视新内容，导致认知过载。

设计策略：

1）批量呈现而非逐条追加

Agent 并非必须逐条发送组件。对于高度相关的信息（如同一搜索结果的前 3 个选项），可以合并为一个组件列表（如“场次列表”），一次性渲染。将流式更新的粒度控制在“信息单元”级别，而非“原子组件”级别。

2）节奏控制：打字机效果与“继续”按钮

对于长对话或多步骤流程，可以让 Agent 在生成一组组件后“暂停”，等待用户点击“继续”或做出一个选择后，再生成下一组组件。这既符合对话的自然节奏，也给了用户消化信息的时间。

3）视觉分层：区分“主要”与“次要”流

将界面分为主对话区和辅助信息区。核心决策组件（如选择、确认）在主对话区流式生成；而辅助信息（如价格明细、政策提示）可以在侧边栏或折叠区安静地出现，不干扰主流程。

④ 加载与失败状态的处理——比流式文本更复杂

现象：流式文本出现加载延迟时，用户看到的是光标闪烁或逐字出现。但流式 UI 如果某个组件生成很慢（如查询座位图 API 耗时 2 秒），用户看到的将是一个残缺的界面——可能只出现了上半部分，下半部分一片空白。

设计粗略：

1）组件级超时与降级

每个组件独立设置加载超时（如 3 秒）。超时后，渲染一个“重试”占位符，用户可手动触发重试。不要让整个界面等待一个慢组件。

2）乐观渲染与回退

对于有默认值的组件，可以先用默认值乐观渲染，待真实数据到达后更新。例如座位图默认显示“中间区域高亮”，如果 Agent 最终返回的是“靠后区域”，再刷新。前提是这种变化不会让用户感到突兀（可用淡入淡出过渡）。

3）失败隔离

一个组件生成失败不应导致整个对话流不可用。设计规范：失败组件显示错误提示和“重试”/“跳过”按钮，其他已成功组件继续保持可交互。Agent 应能感知到某个组件失败，并主动提供替代方案。

4. GUI 组件库思考

从“语义”到“组件”的确定性映射

1. 品牌一致性：保证了 AI 生成的界面在视觉、交互和文案语调上与产品整体体验浑然一体，而不是拼凑出风格割裂的“弗兰肯斯坦”界面。
2. 提升可靠性：让 Agent 从预定义的组件库中做“选择题”（意图识别+参数匹配），远比让它凭空“作文”（生成代码）准确率高得多，且结果可预测。
3. 降低理解成本：一套设计精良的 Agent 组件库，本身就封装了对常见用户意图的理解。Agent 不需要理解日期控件的实现细节，只需知道 name="bookingDate" 的 date_picker 组件能满足“选择日期”的语义。

① 构建可持续迭代的 Agent 化设计系统

1. 独立演进：产品侧可以独立优化组件（比如改进日期选择器的交互），或新增组件来支持新业务，而无需重新训练或调整 Agent 模型，大大提升了迭代效率。
2. 沉淀“最佳交互路径”：可以将经过验证的高效交互模式（如复杂表单的分步向导、纠错提示等）封装为标准组件。Agent 调用它们时，自然就继承了产品积累的最优体验。

② 如何构筑

语义化分层：不要只给组件起技术命名（如 BottomSheet），要提供语义化的“意图别名”或分类。Agent 应能通过“选择”、“确认”、“输入”、“展示”等意图，去发现和匹配组件。

声明式属性集：每个组件都应暴露一套 Agent 可理解、可填充的属性。例如，一个 ConfirmationCard 组件可能需要 title, detail, primary_action_label, risk_level（危险操作标红）等属性。

从“原子”到“模式”：组件库需有层次。

1. 基础组件（原子）：按钮、输入框、开关。
2. 复合组件（分子）：一张信息卡。
3. 场景模式（有机体）：完整的机票预订表单、售后申诉流程。Agent 直接调用“电影票预定”场景模式，远比每次组合原子组件更高效、体验更一致。

为“不确定性”留有余地：组件属性中可包含“模糊提示”或“建议”字段，允许 Agent 在界面中展示“我为你找到了这些结果，但不完全确定”的状态，让用户拥有最终的判断和修正权。

③ 面向 Agent 的 UI 组件库 vs 传统 UI 组件库

5. 从“传统”到“Agent”：如何转换你的组件库

将现有的传统组件库升级为面向 Agent 的组件库，本质上是对组件能力的抽象化、语义化和契约化改造。

抽象为“契约”：核心是构建一个全新的、与框架无关的“组件目录”。这个目录就是 Agent 眼中的“菜单”：

1. 为每个组件（如 Button, DatePicker）创建一个唯一的 ID。
2. 用 JSON Schema 严格定义其可接受的属性，如 type, label, action 等。
3. 使用声明式的数据绑定语法（如{ "value": {"path": "/user/name"} }），将组件状态与一个全局数据模型解耦。

为 AI 设计“提示词”（Prompts）：编写“组件目录指南”，直接嵌入给 Agent 的系统提示词中。这份指南需要清晰说明每个组件在语义上对应哪些用户意图。例如，告诉 Agent：“当用户想选择一个时间点时，应该调用 DateTimeInput 组件。”

实现“渲染器”：这个渲染器是 A2UI 的心脏，负责解析 Agent 返回的 JSON 数据，并将其“翻译”成你现有的传统组件。A2UI 生态已经提供了对多种主流框架（如 React, Flutter）的原生支持，社区也涌现出像 AGenUI 这样的开源框架，让开发更为便捷。

完成前端应用改造：最后，需要将 A2UI 客户端的 SDK 集成到你的应用中，使其能够接收、解析 A2UI 的 JSON 数据流，并调用渲染器来动态生成界面。

面向 Agent 的 UI 组件库并非对传统组件库的简单扩展，而是一次设计范式的升级：其核心任务从关注“UI 长什么样”的视觉表现，转向了解决“AI 如何安全地描述 UI”这个根本问题。它不再是一个孤立的设计资产，而是成为了产品与 AI 之间的一种“共同语言”与“安全契约”。

6. 简单评估 A2UI 组件库（探索中版本）

① 意图映射准确性（AI 能否选对组件？）

核心问题：当 Agent 收到用户的自然语言指令时，它生成的组件 JSON 是否正确地反映了用户的意图？例如，用户说“帮我选一个靠窗的位置”，Agent 应该调用 SeatMap 组件（而不是 Dropdown），并附带高亮靠窗区域的属性。

② 渲染可靠性（前端能否正确呈现？）

核心问题：Agent 生成的 JSON 是否满足前端渲染器的约束？渲染器能否成功解析并展示原生组件？异常情况下如何降级？

③ 体验流畅度（用户感觉好用吗？）

核心问题：即使组件映射准确、渲染成功，用户在交互过程中的主观感受如何？操作是否自然、认知负担是否低？

7. 小结

以上是最近平台在设计 Agent 需求时，结合 google 提出的 Agetn to UI 的一些与 UI 相关的方法、思路总结，作为产品设计上，这个概念确实给我带来了很多新的思路与想法，在此分享给大家。

打造这样一套全新的 UI 组件库，需要我们设计师与开发者共同去定义一套组件的抽象规范，然后让前端能根据这套协议来实现动态渲染，最终形成一套 AI 可以准确理解并安全使用的“通用语言”。

三、从精确指令到模糊意图

从 GUI 到 Agent 协作，用户体验设计正经历一场范式转移。本系列分享将从八个核心维度，系统对比传统纯 GUI 交互与“自然语言+Agent 协作”模式的差异，并探讨 AI 时代产品设计的新原则、新工具与新心智模型。

纯 GUI 时代与 Agent 协作时代，信息在两个方向上流动方式的根本差异：一端是用户向系统下达的“指令”，另一端是系统向用户呈现的“反馈”。

这种差异，本质上是从“精确指令↔预定义反馈”的刚性信道，升级为“模糊意图↔动态生成反馈”的柔性对话。

1. 输入/输出性质的根本不同

2. 输入：从“操作翻译官”到“意图表达者”

在纯 GUI 模式下，用户是操作的翻译官。你需要把一个完整的意图（“我想看明天下午的《给阿嬷的情书》”）拆解成一系列离散操作：

点击“电影”tab → 找到《给阿嬷的情书》的入口 → 点击进入 → 点击“选座购票”按钮 → 选择“明天” → 筛选“下午” → 滑动列表找到目标场次 → 点击“选座”…… 每一步都必须精准，否则系统就会“懵”在原地。

这种输入的典型特征：

1. 只能使用系统定义好的语言：按钮、菜单、手势，每个都有固定语义。
2. 无法携带额外上下文：你无法在点击“支付”时，告诉系统“如果优惠券明天过期，就先用这张”。
3. 容错率极低：按错了按钮，系统立刻执行，理解不了你的“本意”。

而在 Agent 协作模式下，输入变成了意图的直接投射。你只需说：“帮我订两张明天下午的《给阿嬷的情书》，要中间靠后的座位，如果 IMAX 有连座就优先 IMAX，否则普通厅也行。” 这句话同时包含了：

1. 核心指令（订票）
2. 参数（影片、时间、人数）
3. 偏好（中间靠后）
4. 条件分支（IMAX 连座优先，否则普通厅）

Agent 接收的不是一个“操作”，而是一个带约束的任务目标。它先理解，再规划，遇到不明确的点会主动提问：“明天下午有两个 IMAX 场次，14:30 和 16:10，您更倾向哪个？”

这种粗粒度、模糊但语义丰富的输入方式，让用户从“如何让系统明白我”的认知负担中解放出来，回归到“我自己想要什么”的纯粹表达。

3. 输出：从“预定义的公告板”到“动态生成的任务看板”

纯 GUI 的输出，是一个设计师穷举出的“模版”。为了覆盖各种用户、各种状态，设计师会创建大量页面和状态，然后把它们打包成一个固定的 App。

1. 功能导向的：所有功能按钮都摆在界面上，不论你当前是否需要。用户在海量信息中自行寻找下一步该点哪里。
2. 静态的：即使数据变了，界面结构不变。你刷新一次页面，看到的还是那些菜单、那些按钮，只是列表里的商品换了。
3. 没有“语境智慧”：你在订单支付页面停留了 5 分钟，系统不会主动弹出一个客服对话框问“需要帮助吗？”，除非你点击“帮助”按钮。

而 Agent 协作的输出，是一个动态生成的“任务看板”。它只展示与当前任务直接相关的内容，并且 Agent 会根据对话的进展，实时拼装不同的界面组件。

这正是之前研究的 A2UI 所支持的“生成式 UI”：Agent 不是返回一个完整的“页面”，而是流式地发出一个或多个组件指令。比如在你确认场次后，Agent 可能只返回一个 SeatMap 组件和一个简短的提示 Text 组件，其他无关的导航栏、推广位、底部 Tab 栏在这个视图中都消失了——因为当前任务不需要它们。

这种动态输出有三个关键优势，直接对应我之前提到的“可省略”逻辑：

1. 信息层级随任务深度自然浮现：初期提供概览（场次卡片列表），决策点提供沉浸式工具（座位图），最终提供明确的操作出口（支付确认卡片）。信息从不超载。
2. 操作入口与信息合一：传统的“订单详情”和“取消订单”按钮可能在不同的地方。而 Agent 可以将订单详情卡片和一个“取消本次预订”的按钮放在一起，同时用文字说明“取消后座位将立即释放”。信息和行动一体化呈现。
3. 错误处理从“告知”变为“引导”：如果你选的两个座位中间被人抢先了一步，传统界面可能只弹出一个“座位已被选”的警告框，用户需要自己重新找。Agent 会说：“抱歉，刚才您选的 K8、K9 中间有一个座位已被占。我为您找到了另一个中间靠后的连续座位 L7、L8，要换成这个吗？” 输出不再只是一个结果通知，而是一个后续行动的邀请。

4. 输入与输出的融合：一个“订票”的例子

举例一个完整流程来串联输入输出性质的变化。

用户输入：“帮我订明天下午的《给阿嬷的情书》，两张，位置好一点。”
这句话是模糊意图。Agent 收到后，内部发生了一系列推理和数据查询，然后它生成了第一个动态输出——一个场次选择界面，包含三个卡片，每个卡片上明确标注了“14:30 IMAX厅 | 票价69.9 | 余座47”，并附有按钮“选择此场”。

这个输出不是预定义的，Agent 在生成它时做了以下事情：

1. 它自动过滤了上午和晚上的场次（因为用户说了“下午”）。
2. 它识别出 IMAX 厅可能更符合“位置好一点”的隐含诉求，但依然提供了其他选项。
3. 它没有展示复杂的影院信息、影片介绍，因为当前任务窗口是“选场次”。

用户点击第二个卡片（14:30 IMAX 厅），这是一个精确操作，但在这个协作上下文中，它的语义是“确认 Agent 的提议”。

Agent 收到这个精确操作事件后，生成第二个动态输出：一个被高亮推荐区域的 SeatMap 组件，以及一个实时更新的订单摘要栏。它通过数据绑定把已售座位、价格梯度这些后台信息注入座位图，让用户一目了然。

用户拖动地图查看不同区域，这是非结构化操作，建议保留。然后用户点击 K8、K9，客户端将 seats_changed 事件发回 Agent。Agent 实时更新摘要栏：“已选 K8、K9 | 合计 139.8 元”，并发现在支付前需要最终确认，于是追加了一个 Button 组件，variant: "primary",action: { name: "confirm_payment", requiresConfirmation: true }。

点击“确认支付”后，客户端弹出二次确认弹窗。用户点击“确定”，整个流程结束，Agent 生成最后一个输出：包含取票码和二维码的 Card 组件，并附带一句富有人情味的 Text：“祝您观影愉快！”

5. 对设计师的启示：从“制作静态页面”到“设计动态意图响应”

输入输出性质的改变，意味着设计产物的形态也变了。以前你的核心产出物是一个个具体的界面。而现在，你需要设计的是一套“输入理解规则”和“输出生成逻辑”：

1. 定义 Agent 能理解的意图集合：你的产品支持哪些高频任务？（订票、改签、咨询），每个任务的必要参数和可选偏好是什么？这决定了 Agent 的输入解析能力。
2. 设计“输出组件序列”的剧本：当用户说“我想退票”时，Agent 应该按怎样的顺序输出哪些组件？先输出订单列表供选择，再输出退款原因选择器，最后输出退款金额确认卡片。这就是一个输出剧本。
3. 为每个决策节点设计最佳的“生成式 UI”：在哪些环节用卡片列表，哪些用地图，哪些用表单？这与我们之前讨论的“交互过滤清单”直接衔接，是输入输出性质在你组件库设计中的具体落点。

最终，输入/输出性质的进化，让产品从一个“被浏览、被操作的静态工具”，变成了一个“能倾听、能思考、能根据对话实时组装的动态服务体”。而你对这一切的掌控，不再是对像素的精确摆放，而是对意图流转和界面拼装的规则设计。