教程

Generative UI 入门指南

Generative UI 入门介绍——它是什么、为什么重要，以及如何构建你的第一个生成式界面。

Alex2026年3月29日12 分钟阅读

第一次看到模型把一个可用的图表——不是图表的描述，是真正的、可以筛选和实时交互的图表——流式传输进聊天窗口时，我感受到了一种久违的触动，就像第一次在浏览器控制台里用 fetch() 时的那种感觉。那些我一直当作独立 UI 任务来交付的东西，突然坍缩成了一次模型调用。

这篇文章写的就是这种"坍缩"。Generative UI 不是一个新框架；它是"模型输出"与"产品界面"之间边界的位移。下面我们来聊：它是什么，何时值得投入，何时不值得，以及如何自己构建一个最小但诚实的版本。

什么是 Generative UI？

Generative UI 是一种范式，在这种范式下，AI 系统生成可交互的 UI 组件——而不仅仅是文字——作为输出。它不是返回一段 Markdown 说"这是你的数据图表"，而是返回一个真正可交互的图表组件，用户可以筛选、排序和探索。

有个有用的区分：渲染 Markdown 的聊天机器人不是 Generative UI。模型从目录中选取、参数化并流式传输一个有类型的 React 组件，才是。区别在于：LLM 是在生产"文字供显示层格式化"，还是在生产"UI 运行时转化为组件的结构化意图"。

为什么重要

传统聊天机器人返回文字。Generative UI 返回界面。这个区别之所以重要，在于：

更高的信息密度 — 一个设计良好的组件传达的信息远多于几段文字
直接操作 — 用户与输出交互，而不仅仅是阅读
上下文操作 — 生成的组件可以包含按钮、表单和工作流

上手入门

构建你的第一个 Generative UI 应用，需要三样东西：

一个支持流式传输 UI 组件的框架——Vercel AI SDK 的 streamUI 原语是参考实现
一组 AI 可以组合使用的预构建组件（你的设计系统，或其精选子集）
一个理解你的组件 schema 的 LLM——任何支持函数调用的现代模型都可以；schema 比模型本身更重要

// 示例：定义一个返回 UI 组件的工具
import { z } from 'zod'

const tools = {
  showWeather: {
    description: 'Display weather information for a city',
    parameters: z.object({
      city: z.string(),
      unit: z.enum(['celsius', 'fahrenheit']),
    }),
    // 注意：这里的 `async` 是正确的——我们在内部 await fetchWeather。
    // 如果你想*流式传输*部分 UI（骨架 → 已加载），
    // 将签名改为 `generate: async function*` 并 `yield` 中间 JSX。
    generate: async ({ city, unit }) => {
      const data = await fetchWeather(city, unit)
      return <WeatherCard data={data} />
    },
  },
}

其中不那么明显的地方在第 3 行：参数 schema 是模型看到的内容。Zod schema 中的名称、描述和枚举值，无论你是否意识到，都在做提示词工程的工作。把 schema 当作提示词的一部分来对待，而不仅仅是类型系统的一部分。

面向工程经理：采用路线图与 ROI

如果你是在为团队而非个人项目评估 Generative UI，核心问题不是"演示酷不酷"——而是"在哪个节点上这件事开始有回报"。

第一阶段——单个高价值界面（1 名工程师，2–4 周）。 选择一个用户目前会从中跳出去查仪表板的聊天相关流程（分析、搜索结果、"给我看我的……"）。在功能标志后面上线。成功指标：旧流程的替代率，而不是参与度。

第二阶段——组件目录（2 名工程师，1–2 个月）。 将设计系统的一小部分（5–15 个组件）提升为模型可调用的工具，带有固定契约和快照测试。目录就是产品的护城河——竞争对手可以复制聊天 UI，但无法复制你那个有类型、有领域特性的组件库。

第三阶段——多界面推广（全团队）。 Generative UI 成为多个渲染目标之一。SSR、移动端和智能体间流量都消费相同的组件契约。

ROI 体现在哪里（以及哪里没有）： 当替代方案是为每种查询构建昂贵的定制 UI 时（BI 工具、运营仪表板、具有组合输入的配置页面），ROI 是真实的。当用户已经有了完全适用的静态 UI 时，ROI 不真实——在一个已经好用的表单前面加一个 LLM，几乎总是净亏：更高的延迟、更低的可靠性、更多的成本。

你真正需要的团队技能： 一名熟悉前端框架 + LLM 工具调用的工程师，一名习惯于组件 API 思维（而非页面思维）的设计师，以及一名能写出简洁工具描述的 PM。你不需要 ML 工程师。

面向高级工程师：生产模式

上面的 Vercel AI SDK 示例是"Hello World"。以下三件事是你在生产中会遇到的，快速入门不会教你的：

1. 目录是契约，不是建议。 一旦一个组件可以被模型调用，它的 props 就是公共 API 的一部分。破坏性变更的纪律同样适用。对组件 schema 进行版本控制，针对具代表性的模型输出运行快照测试，并把 schema 漂移当作发布阻塞项。

2. 流式传输 UI ≠ 流式传输文字。 使用 streamUI 时，你可以先 yield 一个骨架组件，等数据就绪时再用加载完成的版本替换它。陷阱在于：通过 React Server Components 在服务端渲染的组件无法访问只存在于客户端的状态。尽早决定每个组件是"仅 RSC"、"仅客户端"还是"有明确交接的混合"。混用而没有规则，会产生难以调试的 hydration 不匹配。

3. 失败模式不同。 传统 UI 在服务端失败时报错。Generative UI 在以下情况失败：(a) 模型选择了错误的组件，(b) 模型幻觉了一个 schema 接受但组件无法渲染的 prop 值，(c) 模型在两个工具之间陷入循环。你需要：工具调用分布的遥测数据、针对无法解析意图的哨兵"降级"组件，以及每次对话中工具调用深度的硬上限。

关于 Vercel + Tambo + Thesys C1 生态的生产级细节，请参见我们的完整 Generative UI 指南。

局限性与不应使用 Generative UI 的情况

诚实之言——很多团队都在第一个季度栽在这里：

延迟敏感的流程。 一次模型调用在 UI 的第一个字节之前增加 200–2000ms。如果用户期望 <100ms 的响应（搜索联想、表单验证），Generative UI 是错误的选择。
高风险的正确性场景。 纳税申报、医疗剂量、金融交易。组件契约保证的是渲染，而不是数据的正确性。一次路由错误的工具调用仍然是错误的答案。
形态固定的任务。 如果每个用户都看到相同的五个字段，就直接建一个表单。只有当输出的形态在不同查询之间有实质性变化时，Generative UI 的成本才是合理的。
没有设计系统的小团队。 Generative UI 能放大优秀组件库的价值，同时也会毫不留情地暴露其缺失。如果你的前端是逐页定制的，先建设计系统。
受监管的 UI 界面。 WCAG 审计、FDA 级别的设备界面、任何需要冻结 UI 以满足合规要求的场景。Generative UI 的整个意义在于 UI 会随每次查询变化——这是特性，不是缺陷，但它与"这个页面在 2031 年必须看起来跟现在一模一样"是不兼容的。