聊天窗口（Chatbot）是终极交互形态吗？
答案是否定的。如果用户查询航班状态，一段 500 字的文字罗列远不如一个直观的折线走势图、带有可选复选框的航班卡片来得直接。
纯文字的短板不在美观，而在认知负担：结构化信息被压平成线性序列，要靠用户自己在脑中重新组装。生成式界面的价值恰恰是把"呈现结构"的决定权交还给模型——模型像选择工具一样选择组件。想先建立对工具调用链路的整体认知，可读 MCP 到底是什么？从 AI 工具调用到 Agent 工作流，一文看懂 MCP。
Generative UI 核心工作流
借助 Vercel AI SDK 等前沿工具与 MCP 协议：
- 智能体在推演过程中不仅输出自然语言，还决定唤起特定的 UI 组件；
- 服务端通过流式协议直接将可交互的 React Server Component 序列化流发往前端；
- 用户在生成的界面上直接拖动滑块、点击筛选，其状态改动又作为新的输入事件反馈给智能体，形成极致丝滑的动态人机协同体验。
三种交互形态的分工对比
| 形态 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| 纯文字聊天 | 灵活度最高、实现成本最低 | 结构化信息表达力差 | 开放问答、摘要解释 |
| 生成式界面 | 信息密度高、交互状态可回流 | 需要预先定义组件集 | 筛选、对比、参数调节 |
| 传统固定表单 | 行为完全确定、易于测试 | 无法按上下文动态出现 | 合规审批、强约束录入 |
三者不是替代关系而是分层关系：固定表单负责骨架流程，生成式界面负责动态场景面板，文字负责解释与兜底。
落地生成式界面前先做四件事
- 组件白名单先行：模型只能从显式注册的组件清单中挑选，不允许自由生成 markup 结构，否则样式与安全边界都会失控；
- 状态回流定义为事件：界面上的每次操作都要序列化为明确的事件负载回传给智能体，这是它优于纯展示的核心，架构上属于人在回路范式中"用户对中间结果施加影响"的一环；
- 设计文字降级路径：流式连接中断或组件渲染失败时，应能降级为等价的文字输出；流式链路的拥塞与背压处理值得提前了解，可参考 流式交互与背压控制（Backpressure）：在高吞吐 MCP 通信中的架构实践；
- 记录组件选择理由：把模型"为什么选这个组件"的判断留在日志里，后续调优与责任追溯都有据可查。
常见问题速查
| 现象/疑问 | 原因/背景 | 处理/建议 |
|---|---|---|
| 生成的界面风格忽好忽坏 | 模型在自由生成结构而非选择组件 | 改为白名单式组件注册与约束输出 |
| 用户操作后智能体无响应 | 界面状态改动未作为事件回流 | 定义明确的交互事件负载与回传通道 |
| 刷新页面后组件状态丢失 | 组件状态只存在于流式会话中 | 持久化会话状态并支持恢复渲染 |
| 不确定某场景值不值得做 | 缺少场景分层标准 | 优先做"高频调参与比较"类场景 |
小结
判断是否值得投入生成式界面，标准只有一条：该场景中用户是"看和选"多于"读和懂"，且所需组件可以提前枚举，才值得做；否则坚持文字加固定表单。工程重心不在视觉炫技，而在组件边界、状态回流、降级路径三件事是否都立得住。