生成式 UI：概念、技术路径与智能座舱的可能性#

1.1 三大核心特征#

2.1 它不等于 D2C（Design to Code）#

D2C 的核心是把设计稿转成代码，发生在设计/开发阶段。
而生成式 UI 发生在运行时，关注的是当前交互过程中该呈现什么界面。

因此：

• D2C 是设计到开发的自动化工具链
• 生成式 UI 是运行时的人机交互范式

两者可以协同，但不是同一个概念，也不是上下级关系。

2.2 它不等于 AI App Builder#

Meoo、Lovable、Bolt 这类产品更接近 AI App Builder / Vibe Coding：
用户用自然语言描述需求，系统生成前端、后端、数据库甚至部署流程，最终产出的是一个可运行应用。

这类系统关注的是：

• 如何更快构建一个产品
• 如何降低开发门槛
• 如何把”想法”直接变成”应用”

而生成式 UI 关注的是：

• 用户此刻在执行任务时
• 系统是否应动态组织一个新的交互界面
• 界面如何随上下文实时变化

2.3 它也不等于”AI 直接写 HTML/CSS/JS”#

在 demo 场景里，模型直接输出 HTML/CSS/JS 并由浏览器渲染，看起来很直观。但在生产系统中，这种模式往往面临安全、稳定性、可测试性等方面的问题。第五章会对这类路径展开分析。

工程上更主流的做法是：

模型输出结构化描述，渲染层负责把描述映射成受控组件。

2.4 概念图谱#

把相关技术放进同一个视角来理解：

这个区分非常关键。很多产品会横跨多个环节，但在讨论技术本质时，不能把它们混为同一个概念。

4.1 意图理解与决策层（LLM / Agent Layer）#

这一层负责：

• 理解用户请求
• 判断当前任务目标
• 结合上下文规划交互流程
• 决定应该调用哪些工具
• 决定应该渲染什么类型的界面

它输出的理想结果不是任意代码，而是结构化描述，例如：

• 渲染一个结果卡片
• 展示一个比较表格
• 弹出一个表单
• 给出下一步行动按钮
• 触发一个多步骤流程

4.2 工具与服务层（Tool / Service Layer）#

这一层负责提供外部能力，包括但不限于：

• 搜索
• 数据查询
• 设备控制
• 地图与导航
• 多媒体处理
• 业务系统接口
• 本地能力调用

模型通过函数调用、工具协议或受控服务接口获取事实和执行能力，从而避免”仅靠语言模型猜测”。

值得一提的是，MCP（Model Context Protocol）等协议正在推动工具层的标准化，使搜索、设备控制、数据库访问等能力可以统一接入。没有可靠的工具层，生成式 UI 很容易退化成”会说话但不会做事”的界面幻觉。

4.3 渲染与执行层（Render Layer）#

这一层接收上层输出的结构化描述，并将其映射为实际 UI。

在工程实践中，主流方式不是执行模型生成的任意代码，而是：预置组件库、Schema 校验、JSON/DSL 驱动渲染、运行时状态管理、权限和安全检查。

因此，渲染层本质上是一个受控的 UI 执行环境。

1
// 前端组件渲染示例
2
const componentMap = {
3
  result_card: ResultCard,
4
  table: DataTable,
5
  chart: ChartView,
6
  form: FormContainer,
7
  action_button: ActionButton
8
};
9

10
function renderUIDecision(decision: UIDecision) {
11
  // 1. Schema 校验
12
  const validated = validateSchema(decision);
13

14
  // 2. 组件映射
15
  const Component = componentMap[validated.type];
16

17
  // 3. 安全检查
18
  if (!hasPermission(validated)) {
19
    return <FallbackState />;
20
  }
21

22
  // 4. 渲染组件
23
  return <Component {...validated.props} data={validated.data} />;
24
}

渲染流程：模型输出结构化描述 → Schema校验 → 组件映射 → 安全检查 → 渲染UI

5.1 代码生成型（Code Generation）——自由但不可控#

模型直接输出 HTML/CSS/JS 或 React 代码，由浏览器或运行时直接渲染。这种方式在 demo 场景中很直观，但在生产系统中面临：

• 安全风险：模型可能生成包含恶意脚本或越权操作的代码
• 稳定性不足：同样的 prompt 两次输出结果可能完全不同，界面行为不可预测
• 可测试性差：没有结构化边界，难以做自动化测试和回归验证
• 设计一致性难保证：每次生成的样式可能偏离品牌规范
• 性能和权限边界难控制：运行时代码的执行范围难以约束

因此，工程上这类方案更多停留在原型、D2C 和 AI App Builder等开发阶段场景，和运行时生成式 UI 属于不同的范畴。

5.2 容器化加载（Container / Route Orchestration）——安全但粒度太粗#

既然直接生成代码太自由、太不可控，一个自然的折中是让模型决定”加载什么”，而不是”生成什么”。

这类方式不是精细到组件级，而是由模型决定调用哪个页面、模块或小程序容器：

• 模型负责路由决策
• 预置模块负责完整业务承载
• 系统通过动态加载完成交互组织

安全性和稳定性确实好了很多——因为运行的是预置代码，而不是模型现场生成的。但它的粒度太粗：模型只能决定”跳到 A 页面还是 B 页面”，无法精细地调整页面内的组件组合、信息密度或交互方式。

它的优势在于便于复用现有业务模块、对企业系统友好、易与历史代码集成，适合审批流、表单流、业务流等粗粒度场景。

5.3 声明式组装（Schema-Driven UI）——当下最优解#

代码生成型太自由，容器加载太粗。工程上更成熟的实践是：让模型输出结构化描述，由渲染层在受控组件库中选择并组装。

其核心思想是：

• 模型不直接生成代码，而是输出组件类型、参数和数据
• 前端从预置的受控组件目录中选择并组装
• 渲染层负责 Schema 校验、状态管理和安全执行

这样既能保证安全边界清晰、设计一致性可控、可测试、可审计，又能实现足够灵活的界面组合。

这正是当前生产环境里最符合生成式 UI 本质的一条路线。

6.1 Web 端：最容易实验化，但不代表最适合工业化#

Web 端的动态加载和即时渲染能力，使其成为生成式 UI 最早被实验的平台。但真正进入生产环境后，Web 端需要面对和原生端类似的工程约束：可维护性、安全性、样式一致性、组件复用和质量控制。

因此，Web 端的成熟方案同样会收敛到受控组件 + 结构化生成的模式，而非持续依赖模型输出任意代码。

代表性实现是 Vercel 的 json-render：开发者预先定义允许的组件目录和 schema，AI 输出 JSON 树，框架负责受控渲染。核心是把生成式 UI 变成可控、可测试、可落地的开发范式。

6.2 移动端：更依赖预置组件和声明式映射#

由于原生端受编译机制、审核机制和性能要求约束，移动端很难接受模型直接生成并执行任意 UI 代码。

代表性实现是 Google 的 A2UI 协议 + Flutter GenUI：通过 A2UI 协议让 agent 输出声明式结构，由客户端使用自身原生组件系统完成渲染。核心目标是形成跨平台可复用的 agent-to-UI 通信机制。2026 年 4 月，Google 发布了 A2UI v0.9，并推出了 React Renderer，使其覆盖 Web（Lit、Angular、React）、移动端（Flutter）等多平台。

移动端的现实结论通常是：

AI 负责”选积木”，而不是”现场造积木”。

7.1 模型负责决策，前端负责落地#

这是一条基础性的工程原则。

• 模型负责判断”该显示什么”
• 前端负责决定”怎么稳定地显示出来”

不要把渲染控制权完全交给模型，否则系统很快会遇到一致性、安全性和可测试性问题。

7.2 优先输出结构化结果，而非任意代码#

成熟的系统通常让模型输出：

• 组件类型
• 参数
• 数据模型
• 行动按钮
• 状态变更指令

而不是直接输出一整段 HTML/JS。

7.3 组件选择受控#

模型应从预置组件目录中选择，而不是无限制生成。这确保了安全边界、设计一致性和可测试性。

7.4 文本解释和界面状态要分层#

界面负责呈现事实与操作对象，文本负责解释原因与建议。
不要把关键业务状态埋在自然语言里，否则很难追踪、也难以验证。

7.5 支持降级与兜底#

当模型失效、工具不可用、生成失败或上下文缺失时，系统需要能够退回到固定页面、文本回答、预置模块或人工确认流程。这在安全敏感或可靠性要求高的场景尤其重要。

8.1 为什么座舱是重要场景#

智能座舱的交互需求天然适合生成式 UI：任务导向强、上下文丰富、多模态明显、跨设备协同强。

举例：当用户说”有点困，找个地方休息并买杯咖啡”时，系统可以根据驾驶状态、地图位置、油量和历史偏好，动态组织一个任务界面，展示前方休息区、推荐咖啡点位、提供一键导航和语音确认。这种”任务式界面”将传统系统的多步操作（打开导航→搜索→退出→打开推荐→筛选→下单→返回）压缩为一次意图表达。

这张动态生成的任务卡片展示了：

• 顶部标题栏：显示任务类型和搜索范围
• 中间列表：前方3个服务区，含距离和咖啡品牌信息
• 底部操作区：一键导航、咖啡预订、语音确认三个快捷按钮

从工程实现看，模型输出结构化决策（如任务卡片布局、POI列表、操作按钮），渲染层从预置组件库中映射对应的原生组件，填充实时数据后呈现在屏幕上。

8.2 核心挑战与应对策略#

座舱端是限制最严格的场景之一，必须面对功能安全、信息安全、人机工程学约束、确定性时序、驾驶分心控制和本地计算资源限制等多重约束。因此，座舱中的生成式 UI 更适合采用声明式组装、受控组件系统、端云协同、分级自治和 fail-safe 机制等工程策略。

第一阶段：基建期#

借助 AI App Builder 快速验证原型，通过 AI 编程助手和 D2C 工具构建受控组件库，打磨意图识别与工具调用的准确性。核心是把组件库、意图理解、工具调用链路等基础设施准备好。

第二阶段：局部自治#

娱乐、信息、生活服务等非安全关键界面，可以在受控范围内根据用户意图动态组装。这是生成式 UI 第一次在安全边界内直面真实用户。

第三阶段：任务编排#

系统能围绕”出行任务”实时组织界面，多个模块联动，一次意图表达即可完成复杂操作。

第四阶段：低显性交互#

界面只在需要时出现，系统通过主动服务和环境计算完成任务，减少不必要的元素干扰。

10.1 行业现状#

值得关注的是，高德在 2026 年 4 月发布了 AGenUI，这是国内首个基于 A2UI 协议的座舱端生成式 UI 方案。它继承了 A2UI 的声明式结构与安全边界，同时针对导航、出行服务等座舱高频场景做了组件优化，为”地图服务 + 生成式 UI”的融合提供了可参考的工程路径。

目前，多数团队正优先建设意图理解、工具调用、组件系统与安全机制等基础能力。并非所有座舱功能都需要车规安全验证——娱乐、信息、生活服务等场景通过 WebView 承载或借鉴移动端方案，已经在逐步落地。

10.2 展望#

生成式 UI 代表一种新的交互范式：界面不再是静态页面，而是围绕任务在运行时被动态决策出来的交互载体。在座舱场景中，其价值不在于让界面”更炫”，而在于让交互更符合驾驶任务、更低干扰、更具情境感知能力。难点在于在真实约束下稳定地做出正确的界面决策。