Generative UI 与传统 UI：核心差异

核心区别

传统 UI 开发遵循一套直接的流程：设计师创建原型，开发者将其实现为静态模板，条件逻辑处理各种变体。用户可能看到的每一个页面，都是由人类明确设计并编码的。

Generative UI 颠覆了这个模型。你不再预先构建每一个可能的视图，而是构建一个组件库，让 AI 模型针对每次交互组合出合适的界面。UI 在运行时生成，而不是在构建时生成。

这听起来比较抽象，下面用一个具体的对比来说明。

真实案例：客户仪表板

传统方式

你需要设计并构建：

• 一个包含 6 个固定组件槽的仪表板模板
• 15 种不同的组件类型（营收图表、用户表格、漏斗图等）
• 一个让用户配置哪些组件显示在哪里的设置面板
• 适配每种组合的响应式布局

初始开发时间：在团队成熟、需求稳定的情况下，大约 3–4 周【估算】；每次新增组件类型时还需要持续维护。

关键约束：你只能向用户展示来得及构建的内容。任何不符合现有 15 种组件之一的新数据问题，都会得到"仪表板里没有这个功能"的回答。

Generative UI 方式

你需要构建：

• 同样的 15 个组件
• 一个自然语言提示界面："显示本季度的营收趋势和头部客户"
• 一个根据查询选择并排列组件的 AI 管道

开发时间：假设组件库已就绪、评估基础设施完善、提示词只需迭代一两次，AI 管道大约需要 1 周【估算；实际范围为 1–4 周，取决于组件质量和领域复杂度】。此后，每一个新的数据问题都能得到定制化的仪表板，无需额外开发——AI 用现有组件组合出答案。

渲染模型

这是两种架构在技术层面分歧最大的地方。

传统 UI 渲染： 在构建时（或 SSR 的请求时），服务端渲染一个预定义的模板。在用户看到任何内容之前，组件树就已经固定了。React、Vue 等框架默认都遵循这个模型。

Generative UI 渲染： 在请求时，系统会：

1. 将用户意图发送给 LLM
2. LLM 选择工具（组件）及其参数
3. 服务端渲染这些组件
4. 渲染结果流式传输到客户端

组件树在 LLM 做出决策之前是未知的。这个根本差异同时带来了能力（无限的视图可变性）和挑战（延迟、非确定性、成本）。

传统方式：
用户请求 → 服务端 → 预定义模板 → 客户端

生成式方式：
用户请求 → 服务端 → LLM 推理 → 组件选择 → 渐进式（流式）渲染 → 客户端
                               （这里增加 200–800ms——适用于 GPT-4o-mini / Claude Haiku
                                等级模型的短工具调用；旗舰模型处理长上下文可能需要 1–5 秒；
                                参见 artificialanalysis.ai 基准测试）

各自适用的场景

应使用传统 UI 的情况

界面定义明确且稳定。 登录页、导航、设置页和结账流程应该手工构建。用户在这些核心流程中期望一致性，且需求不会因每次交互而变化。

像素级设计精度至关重要。 营销页、品牌体验和关键转化漏斗需要精确的设计控制。Generative UI 引入的变量是这些场景不需要的。

性能要求极高，对延迟零容忍。 Generative UI 增加 200–800ms 的 AI 处理时间。对于需要即时响应的界面——搜索联想、实时协作、游戏 UI——传统渲染是唯一选项。

合规要求确定性输出。 在医疗、金融或法律场景中，每个界面元素都必须可审计和可复现，AI 生成的非确定性可能带来合规问题。你需要能精确展示用户在某个时刻看到了什么。

视图数量少且固定。 如果某个功能只需要 3 个页面，就直接建 3 个页面。对于小型、稳定的视图集，Generative UI 管道的开销不值得。

应使用 Generative UI 的情况

可能的视图数量庞大。 数据仪表板、分析工具和管理界面通常有几百种可能的配置。逐一手工构建是不现实的。Generative UI 能自然地处理这种组合爆炸问题。

用户查询难以预测。 支持工具、数据探索界面和内部业务工具会收到设计阶段未曾预想到的请求。Generative UI 能适应新查询，而不是返回"不支持"。

个性化深度很重要。 与其 A/B 测试 4 种布局，Generative UI 系统能创建根据每位用户的角色、数据和交互历史自适应的界面——无需为每种情况编写显式分支。

开发速度优先于设计精度。 对于内部工具、原型和 MVP 功能，Generative UI 能比完整的传统设计构建周期更快地产出可用界面。

你在构建问答或分析功能。 如果用户提出问题并期望获得可视化答案，Generative UI 正是为这种模式而生的。

混合使用的现实

在实际生产中，没有任何应用是 100% 生成式或 100% 传统的。最有效的架构同时使用两者：

传统 UI（手工构建）：
  - 导航外壳和顶部栏
  - 认证和引导流程
  - 设置和偏好
  - 核心 CRUD 操作
  - 营销和落地页
  - 支付和结账流程

Generative UI（AI 组合）：
  - 数据探索和仪表板
  - 搜索结果界面
  - 支持和帮助体验
  - 报告生成
  - 上下文工具面板
  - 分析与洞察

两者之间的边界往往取决于一个简单问题：这个界面对每位用户都一样，还是根据上下文而变化？ 如果变化显著，就值得考虑 Generative UI。

数据流对比

数据在系统中流动的方式有重要差异。

传统方式： 数据根据路由或查询参数获取，然后绑定到预定义的组件 props。数据结构在构建时就已知。类型安全实现起来简单直接。

生成式方式： AI 模型根据用户意图决定请求哪些数据。数据获取发生在工具的 generate 函数内部，由模型的决策触发。在模型运行之前，你不知道会获取哪些数据。

// 传统方式：数据流是预定义的（Next.js App Router）
export default async function DashboardPage({ params }: { params: { userId: string } }) {
  const data = await fetchDashboardData(params.userId);
  return <Dashboard data={data} />;
}

下面是生成式方式：

// 生成式方式：数据流由 AI 决定（Vercel AI SDK v4）
import { streamUI } from 'ai/rsc';
import { openai } from '@ai-sdk/openai';
import { z } from 'zod';

const result = await streamUI({
  model: openai('gpt-4o-mini'),
  prompt: userQuery,
  tools: {
    revenueChart: {
      description: 'Show revenue data as a chart',
      parameters: z.object({
        period: z.enum(['day', 'week', 'month', 'quarter', 'year']).describe('Time window'),
        metric: z.enum(['gross', 'net', 'mrr', 'arr']).describe('Revenue metric'),
      }),
      generate: async function* ({ period, metric }) {
        yield <Skeleton />;
        const data = await fetchRevenueData(period, metric);
        return <RevenueChart data={data} />;
      },
    },
  },
});
// 在 AI SDK v5+ 中：parameters → inputSchema；ai/rsc → @ai-sdk/rsc

技术对比

开发者体验

传统 UI 开发有几十年的工具积累：热重载、浏览器开发者工具、React DevTools、Storybook。调试直观——你可以设置断点并检查组件树。

Generative UI 增加了一层间接性。当某处看起来不对时，可能是：

• AI 选择了错误的组件
• AI 传入了意外的参数
• 组件在这些参数下渲染出错
• 工具 generate 函数中的数据获取错误

调试需要在正常 React 组件调试流程之外，额外检查 LLM 的工具调用日志。这个额外开销是真实存在的，应该纳入团队准备度的评估中。

挑战与风险

参数幻觉。 LLM 可能返回技术上通过 Zod 校验但事实上是捏造的数据（不存在的日期、虚构的价格、不存在的用户）。任何影响业务数据的工具，在使用参数前都必须在服务端进行验证——不要认为 schema 有效就等于数据真实。

常见误解

"Generative UI 意味着 AI 设计界面。" AI 从人类预先设计的组件中选取和组合。设计系统比以往更重要——它定义了质量的上限。

"Generative UI 只是输出更花哨的聊天机器人。" 有些实现从聊天开始，但完整的愿景更广泛。任何界面的布局、内容或组件组合由 AI 模型决定的，都符合这个定义——不仅限于基于聊天的交互。

"传统 UI 已死。" 远远没有。Generative UI 是补充性的，不是替代品。它处理的是手工构建不现实的界面变体长尾部分。

"Generative UI 更慢。" 相比缓存的静态渲染，到达第一个组件确实更慢。但对于需要用户在多个静态页面间导航才能获得完整答案的复杂查询，Generative UI 反而能更快地呈现完整结果。

做出决策

问自己三个问题：

1. 这个功能需要多少种可能的视图？ 如果少于 10 种，就用传统方式构建。如果超过 50 种，Generative UI 通常能节省大量时间【根据我们咨询经验中典型的盈亏平衡阈值估算；具体阈值取决于单视图成本和设计系统成熟度】。
2. 你能接受 500ms 的延迟吗（参考：Nielsen Norman Group 的"1 秒响应限制"表明，配合流式传输和骨架屏，较短的 AI 延迟是可接受的）？ 如果不能，选传统方式。如果能，Generative UI 是可行的。流式传输和骨架加载状态让大多数情况下的这段延迟感觉可以接受。
3. 你有扎实的组件库吗？ Generative UI 的质量上限由 AI 可用的组件决定。如果你的设计系统还不成熟，先在那里投资。

从 Generative UI 中获益最多的团队，都具备强大的设计系统、清晰的组件 API，以及可能的视图数量超出手工开发能力的具体用例。

想知道 Generative UI 是否适合你的产品？预约免费咨询，聊聊你的具体用例。