W
AI-Wiki
CONCEPT

生成式 UI

定义

生成式 UI（Generative UI）是指让 AI 根据用户的自然语言意图、后端数据和运行时上下文，动态生成界面结构的交互范式。它的目标不是只让模型回复一段文字，而是让对话 Agent、内部工具、IDE 或终端应用可以按需生成订单看板、数据卡片、表单、邮件、PDF、视频片段、3D 场景等可视化结果。 在本文语境中，生成式 UI 不是让 LLM 直接写 JSX、HTML、CSS 或完整前端代码，也不是让模型临时发明组件库。更准确地说，它是让模型输出一份可渲染的结构化界面描述，例如 json-render 所使用的 JSON Spec；真实的组件实现、像素渲染、动作执行和跨平台适配，则由开发者预先注册的组件与渲染器负责。 因此，本文讨论的生成式 UI 可以概括为：AI 负责在约束内组合界面，开发者负责定义可用材料、校验规则和渲染边界。

在本文档中的语境

本文采用 json-render 代表的一类“护栏式生成”范式来解释生成式 UI。json-render 是 Vercel Labs 开源的生成式 UI 框架，来源文章称其 GitHub Stars 为 17,280+，Forks 为 918，采用 Apache-2.0 协议，主语言为 TypeScript，仓库创建于 2026-01-14，并在 2026-09-20 仍处于高度活跃状态。 在这个语境下，生成式 UI 的核心不是“AI 会写前端”，而是“AI 能在开发者定义的界面契约内生成 JSON Spec”。开发者通过组件目录、schema、动作白名单和渲染器把边界设好；AI 只在这些边界内决定使用哪些组件、如何排列、绑定哪些数据、触发哪些已允许动作。 这种范式尤其适合 AI 应用和 Agent 产品：用户用自然语言提出需求，模型根据上下文生成界面描述，前端或其他输出端实时渲染。界面不再完全依赖固定页面、固定模板或人工拖拽配置，而是可以随 Prompt、后端数据和会话状态变化。

与传统静态 UI 和低代码的差异

传统静态 UI 通常由工程师预先写好页面结构和交互逻辑。用户看到的界面变化主要来自路由、状态、接口数据和预设条件分支；页面形态本身一般不会因为一句新的自然语言需求而被重新组合。 传统低代码平台通常通过拖拽、配置表单和固定组件模板来搭建界面。它比纯手写页面更快，但组件组合方式、页面结构和数据绑定仍主要依赖人工配置，生成能力受平台模板和拖拽流程限制。 生成式 UI 的不同点在于：界面结构可以由 AI 根据 Prompt、后端数据和上下文即时生成。例如，同一个对话 Agent 在一个问题中返回订单看板，在另一个问题中返回指标卡片、筛选按钮和明细列表；同一套业务数据也可以被生成成后台页面、PDF 发票、营销邮件或终端 TUI。 不过，本文强调的生成式 UI 并不等于无约束的自由生成。它不是让模型随意输出任何 HTML、JSX 或脚本，而是让模型在开发者批准的组件集合与 schema 中进行组合。

主要工程矛盾

生成式 UI 的根本矛盾是：模型擅长开放式生成和“涌现”，但界面产品要求确定、安全、可复现。 如果直接放任 LLM 生成 UI 代码，常见风险包括：

  • 幻觉组件：模型可能引用项目中不存在的 Card、Chart、Modal 或自造 API，导致运行时错误。
  • 样式崩坏：模型生成的布局、类名或样式可能与设计系统不一致，甚至在不同屏幕尺寸下不可用。
  • XSS 与注入风险：若模型直接生成 HTML、脚本或不受控属性，可能引入恶意脚本或危险事件处理。
  • 结构不可预测：每次输出的组件层级、字段名和数据结构都可能变化，难以做稳定校验、缓存、回放和流式渲染。
  • 框架绑定：模型若直接生成 React JSX，就很难无成本迁移到 Vue、Svelte、Solid、React Native 或终端渲染环境。 因此，生成式 UI 的工程目标不是最大化模型自由度，而是在个性化、动态性和工程可控之间取得平衡：把不确定性限制在“组合层”，把组件实现、动作边界、数据校验和渲染行为留给开发者。

json-render 的实现范式

json-render 将生成式 UI 拆成四个关键环节：Catalog、Schema、JSON Spec 和 Renderer。

1. Catalog：声明 AI 能使用什么

组件目录(Catalog) 是开发者提供给 AI 的组件白名单。它规定模型可以使用哪些组件、哪些数据绑定、哪些动作，以及这些能力如何被描述给模型。 例如，开发者可以只开放 Card、Metric、Button 三类组件，并只允许 setState 这类受控动作。模型即使“想”生成未注册组件，也不能通过后续 schema 校验。 在 json-render 中，开发者可通过 defineCatalog 定义 catalog，并基于 zod 约束可生成结构。来源文章给出的示例中，root 包含 children，elements 是一个 record，元素类型被限制为 Card、Metric、Button 等 union 分支；每个分支又分别规定 title、value、label 等字段类型。

2. Schema：把界面生成变成契约

Schema 是生成式 UI 的工程契约。它把“模型应该输出什么”从自然语言提示词变成可验证的数据结构。 在 json-render 的设计中，schema 会约束 JSON Spec 的字段、类型、组件名、动作名和可选能力。模型越界时，输出可以被挡回、修正或拒绝，而不是直接进入真实渲染层。 这也是它与直接生成 JSX 的关键区别：JSX 本身可以包含任意表达式和代码，而受 schema 约束的 JSON Spec 只能描述已允许的界面结构。

3. JSON Spec：AI 生成的是界面描述，不是前端代码

JSON Spec 是 AI 的主要输出物。它描述界面由哪些元素组成、组件如何嵌套、字段如何赋值、状态如何绑定，以及哪些动作在什么条件下触发。 JSON Spec 不直接等同于 HTML、JSX 或 Vue 模板。它更像一份中间层界面协议：既足够结构化，便于校验、存储、回放和审计；又足够灵活，允许 AI 根据用户意图动态组合不同界面。 在这种模式下，界面资产沉淀为可复用、可审计的契约，而不是散落在提示词和模型输出中的前端代码片段。

4. Renderer：真实像素由开发者控制

Renderer 负责把 JSON Spec 映射成真实 UI。开发者用 registry 将 catalog 中的组件类型映射到实际组件实现，例如把 Card 映射到 MyCard，把 Metric 映射到 MyMetric，把 Button 映射到 MyButton。 这意味着 AI 不负责“画”界面，也不拥有组件实现细节。它只能请求使用某个已注册组件，并填入 schema 允许的参数；最终怎么渲染、怎么适配平台、怎么处理交互，仍由开发者维护的组件与渲染器决定。 在 React 场景中，来源文章给出的使用方式是安装 @json-render/core 与 @json-render/react，定义 registry 后将 AI 生成的 spec 传给 Renderer，例如 <Renderer spec={spec} registry={registry} />。

流式生成与交互能力

json-render 内置 SpecStream，用于支持边生成边渲染。模型每输出一块 JSON，SpecStream 就可以逐块解析并推动界面渐进渲染，体验类似聊天产品中的打字机式输出，而不是等模型完整生成后才显示最终界面。 来源文章提到的能力包括：通过 createSpecStreamCompiler().push(chunk) 逐块解析；通过 catalog.prompt() 自动生成系统提示词并喂给任意 LLM；并保持输出严格匹配开发者定义的 schema。 json-render 还支持动态交互表达式，例如 $state、$cond、$template，用于数据驱动渲染；元素可带 visible 条件控制显隐；组件可以触发 setState 动作，并通过 watch 字段监听状态变化，联动其他动作。 这些能力使生成式 UI 不只是“AI 生成一张死图”，而可以变成带状态、条件显隐和受控动作的真实应用界面。

跨平台价值

生成式 UI 的重要价值之一是把“界面描述”和“具体渲染技术”解耦。同一份 JSON Spec 可以由不同 Renderer 映射到不同平台，而不要求 AI 为每个平台重新生成一套前端代码。 在 json-render 的案例中，同一套 catalog 和 schema 可以对接多种渲染目标：

  • React / Next.js：对应 @json-render/react、@json-render/next。
  • Vue 3：对应 @json-render/vue。
  • Svelte 5 / SolidJS：对应 @json-render/svelte、@json-render/solid。
  • React Native：用于移动端渲染。
  • Ink：用于终端 TUI。 更进一步，生成式 UI 的输出不局限于传统网页或移动端界面。来源文章还提到 Remotion 视频、React PDF 发票文档、React Email 邮件、Satori SVG/PNG 社交卡片、React Three Fiber 3D 高斯泼溅场景等非传统 UI 输出。 这种跨平台能力使界面资产从某个前端框架中抽离出来：今天可以在 React/Next.js 中渲染，明天可以换到 Vue、Svelte、Solid、React Native、终端或文档生成场景，而 catalog 与 schema 不必随框架一起重写。

典型使用场景

生成式 UI 的典型使用场景包括：

  • 对话 Agent 内嵌可视化：OpenClaw、Hermes Agent 这类对话式 Agent 不只返回文字，而是根据问题生成订单看板、数据卡片、指标摘要、筛选按钮和明细区域。
  • 内部工具自然语言搭建：产品或运营用自然语言描述“做一个管理后台”或“给我一个订单监控页”，工程师主要维护 catalog、组件实现和权限边界，从而降低迭代成本。
  • 批量内容生成：同一套 Spec 可以批量生成发票 PDF、营销邮件、OG 社交图，甚至 Remotion 短视频。
  • IDE 实时预览：通过 MCP 接入 Claude、Cursor、VS Code，并配合 Cline、OpenCode 等编码 Agent，AI 修改一句需求后界面即时重渲，缩短开发反馈闭环。
  • 终端 TUI：通过 Ink 在 CLI 中生成可交互终端界面，让 Agent 或开发工具在命令行里展示结构化结果。
  • 3D 场景生成：通过 Three.js 或 React Three Fiber 等渲染层，把自然语言需求转为受控的 3D 场景描述。 在私有化和数据主权场景中，生成式 UI 还可以与 Ollama、vLLM 等本地模型部署结合：模型运行在内网，界面边界由开发者定义，敏感业务数据不必离开组织内部环境。

细节与边界

生成式 UI 并不消除前端工程。开发者仍然需要设计组件、实现渲染器、定义 schema、维护动作边界、处理权限和数据安全。AI 只是把组件组合、布局选择和界面描述生成自动化。 生成式 UI 也不意味着可以把所有安全责任交给模型。schema 必须足够严格，组件必须避免危险属性透传，动作系统必须有权限控制，后端数据也需要按业务规则过滤。 在 json-render 的设计中，AI 的自由度主要体现在“从白名单中选择和组合组件”。它不能越过 catalog 使用未注册组件，不能调用未开放动作，也不应该直接注入脚本或任意前端代码。 如果 catalog 设计过窄，模型生成的界面会僵硬，难以满足复杂需求；如果 catalog 设计过宽、schema 过松，又会重新引入不可预测和安全风险。因此，生成式 UI 的落地质量高度依赖组件目录、schema 粒度和动作模型的设计。 与传统低代码相比，生成式 UI 更灵活，但也更依赖自然语言理解、提示词质量和模型输出稳定性。与直接 LLM 生成 JSX 相比，它自由度更小，但安全性、可预测性、可审计性和跨平台能力更强。

相关条目