Gen UI，AI 时代的前端未来之路

乘风gg
196 阅读11分钟

引言：传统前端凉凉了吗

最近一直看到各种前端已死，前端已死，但前端真的死了吗？反正我是头铁要为前端正名一下的，先说结论，我觉得没死，并且 AI 产品已经迎来交互范式巨大的改变，

注意，是巨大的改变。

一、传统 Web 和 AI Web 区别

在传统 Web 应用中，前端的代码是稳定的：UI 是预先设计好的、交互路径是确定的、数据结构是明确的、输入输出是可预测的。典型流程就是“用户操作 → 触发事件 → 更新状态 → 重新渲染UI”，这是一个完全的确定性系统，前端只需按部就班完成渲染即可。

但 AI 应用的出现，直接打破了这种稳定结构。让前端不得不面对一个“不稳定的世界”：用户输入是自然语言（而非固定按钮）、输出是多模态（文本、表格、UI结构）、交互路径是不可预测的。

那么这种 AI Web 是什么呢？有一个官方定义，叫 GenUI

“GenUI”是 Generative UI（生成式 UI） 的缩写。它指的是：由 AI 根据用户输入和上下文，动态生成可交互界面，而不只是返回一段文字。常见生成内容包括表单、卡片、图表、按钮、列表，甚至多步流程界面。

更直白一点说，AI 聊天是“你问一句，我回一段文本”；而 GenUI 是 “你说需求，AI 直接把适合当前任务的界面临时搭出来”，让你可以直接点按钮、填表单、看图表，再把这些操作继续反馈给模型，形成连续交互。

举个例子：

你问“帮我订一张明天下午去上海的高铁票”，传统聊天机器人可能只给你步骤说明；GenUI 则可能直接生成一个小界面，里面有出发地、时间、车次筛选、确认按钮，你在界面里操作后，AI 再接着完成后续步骤。

二、交互模式的改变

AI应用给前端带来的交互改变，不是“多一种渲染方式”，而是从“确定性交互”到“随机性交互”的彻底转变，具体体现在三个维度：

1. 固定 UI 到动态生成UI

传统前端的UI是“设计先行、开发落地”，页面结构、组件层级、交互逻辑都是提前固定的，用户只能按照预设的路径操作；而GenUI时代，UI不再是“预编码的静态资源”，而是“意图驱动的动态输出”，是 AI 基于用户的自然语言需求，动态生成完整可交互的界面

那 GenUI 和现阶段的个性化推荐算法页面有什么区别呢？对比如下：

对比维度个性化推荐算法（如淘宝、抖音）GenUI（生成式UI）
核心目标内容/商品千人千面生成适配用户意图的交互界面
方式输出内容序列，组件由人工预编码，仅排序内容输出完整交互系统，生成内容+编排布局+交互逻辑
交互界面结构固定不变用户意图驱动，界面随需求实时重构

简单来说，推荐算法是“固定界面里换内容”，GenUI是“根据需求换界面”，这是二者最核心的区别。

2. 确定性交互到随机性交互

传统前端的交互是“一一对应”的：点击按钮→固定逻辑→固定结果，全程可预测、可掌控；而GenUI的交互是“随机性”的：用户输入自然语言Prompt→模型推理→多种可能的UI输出，输出不再唯一。

3. 单一输入到多模态

传统前端的输入局限于表单、点击、简单文本，输出也只是固定页面；而 AI 时代的前端，输入变成了文本、语音、图像、文件等多模态形式，输出也涵盖了文本、表格、图表、UI结构等多种形态。

三、难点：确定性和概率性如何配合？

AI模型运行在“概率世界”：可以生成任意结构、任意内容，没有工程边界；而前端运行在“确定的世界”：组件是有限的、状态是可控的、稳定是必须的，二者会有点对立，难以配合起来。

而 GenUI的核心逻辑，就是在这两者之间搭建一座“桥梁”——不让模型生成代码，而是让模型输出“受约束的结构化语义”，前端基于语义渲染UI，既保留AI的生成能力，又守住前端的工程边界。GenUI不是“AI写代码”，而是“AI输出语义，前端渲染语义”。

四、json-render 实战

上面说的 AI Gen UI 的思想大家可能理解起来还是会蒙蒙的，它其实有有现成的库去实践， Vercel 开源的 json-render json-render.dev 下面是我写的一个例子，方便大家快速理解这种思想

场景化案例：AI 营收仪表盘生成

  • 场景角色：B端运营人员（无代码基础，不懂前端开发）

  • 核心目标：用自然语言快速生成可交互的数据仪表盘，支持数据查看、导出等操作，无需手动开发

  • 用户 输入：用户语音/文本指令：“帮我做一个营收看板，显示总营收、转化率、客单价，按日维度展示，支持导出Excel数据”

  • 处理流程（可调用工具）：

    1. 前端对用户输入进行结构化处理（语音转文字、提取关键信息），拼接 Prompt 并传递给大模型

    2. 模型根据 Prompt 和前端预定义的组件规则，输出受约束的 JSON（语义结构），不生成任何代码

    3. 前端基于json-render框架，解析 JSON 并渲染成可交互界面，同时绑定数据接口和交互事件

    4. 前端对 JSON 进行 Schema 校验，确保生成的界面符合工程规范，若不符合则触发兜底策略

第一步：定义组件 Catalog—— GenUI组件库的核心

用 zod 做 Schema 约束，明确告诉 AI “你只能用这些组件、这些属性”，

// 1) 组件 Catalog：告诉 AI 能用什么
const catalog = defineCatalog(schema, {
  components: {
    DashboardCard: { props: z.object({ title: z.string() }), slots: ['default'] },
    DataMetric: { props: z.object({ label: z.string(), value: z.string() }) },
    LineChart: { props: z.object({ xDataPath: z.string(), yDataPath: z.string() }) },
  },
  actions: {
    exportData: { params: z.object({ type: z.enum(['excel', 'csv']) }) },
  },
});

第二步：AI 生成约束JSON（语义中间层）

模型不会生成任何代码，只会输出符合我们定义的Schema的JSON结构。让AI输出语义，而非代码。将传统“PRD→设计稿→开发→测试→上线”的长周期，压缩为“用户意图→AI生成→实时渲染”的短链路，大幅降低设计与开发成本。

// 2) AI 输出：只生成 JSON，不写代码
{
  "root": "dashboard",
  "elements": {
    "revenue_dashboard": {
      "type": "DashboardCard",
      "props": { "title": "营收总览" },
      "children": ["total_revenue", "trend"]
    }
  }
}

第三步：前端流式渲染

JSON通过Streaming方式逐块返回，前端基于json-render框架，一边接收JSON，一边渲染UI——运营人员不需要等待完整的JSON返回，就能实时看到仪表盘的生成过程，体验更流畅。

这里有个关键细节：前端会对每一块返回的JSON进行Schema校验，若发现模型输出了Catalog中没有的组件或属性，会直接过滤，并提示用户“当前指令包含不可支持的功能，请调整”，确保界面渲染的安全性和稳定性。

所以整个流程是：模型管语义，前端管渲染，中间用JSON做隔离层，既发挥了AI的生成能力，又保障了工程的稳定性


// 3) 前端流式渲染：边收边画
const { spec, isStreaming } = useUIStream({ api: '/api/generate' });

return <Renderer spec={spec} registry={registry} loading={isStreaming} />;

最终的效果如下，我放上连接 **json-render.dev/playground*… UI ，绝对让你眼前一亮

Image

五、Gen UI 路线对比

我目前的项目中有一个对话机器人，里面就有用类似 json render 的方式去实现组件渲染。其他业务中也有传统的 Antd 组件库代码，这里我用 2 个层面做对比。

AI 直接输出代码与 AI 输出 JSON

方案设计思路优势劣势
模型直接生成代码LLM直接输出React/Vue源码，前端直接使用上手快、演示效果好，适合快速做Demo代码质量比较差吧，适合 Demo、新项目，也就是现在的 AI Coding
约束型JSON渲染（json-render）AI输出受控JSON（符合预定义Schema），前端基于JSON渲染UI安全可控、可校验、易集成现有工程、支持流式渲染、灵活性高，可定制化需前端提前定义Catalog和Schema，前期有一定的开发成本

传统 UI 与 Gen UI

对比维度传统组件库（如AntD）GenUI组件库
产品本质人工预制的静态积木/模版，固化封装的标准化界面单元可被AI理解、解析、编排的智能原料与能力规则
核心价值为开发者降本增效，统一基础体验，减少重复开发为AI划定能力边界，实现语义与界面的安全对接
使用方式开发者手动调用、拖拽组合，逻辑固定AI自主理解、自动编排

六、AI 时代前端新分层

基于json-render 的思路和我写聊天机器人的经验，我把新一代前端组件架构拆成5层，这也是我们内部标准分层，大家可以直接参考、复用。

1. 多模态输入层

统一处理用户的文本、语音、图像、文件等输入，将其转化为模型可识别的结构化数据。比如语音转文字、图像提取关键信息、文件解析（Excel/PDF）。

2. 上下文管理层

维护用户的对话历史、用户状态、系统能力暴露（比如告诉模型当前可用的组件Catalog），负责Prompt的编排和优化。比如用户输入“帮我做个营收看板”，这一层会自动补充“可用组件、数据来源、交互规则”等信息，让模型输出更精准的JSON，避免生成无效内容。

3. 模型层

负责模型调用、Streaming 处理（逐块接收模型输出）、中间状态反馈（比如“正在生成仪表盘”），支持多模型协作（比如文本模型+图像模型）。

4. 语义结构层

负责定义 JSON Schema、组件 Catalog、安全校验规则。接收模型输出的 JSON，进行校验和格式化，确保JSON符合前端工程规范，为UI渲染提供标准化数据。负责定义组件的动态参数、联动规则和迭代逻辑。

5. UI执行层

基于React/Vue等框架，将语义结构层的JSON，渲染成可交互的界面，负责状态管理、交互绑定、样式适配。比如将 JSON 中的 Card 组件，渲染成对应的指标卡片；将 Chart组件，渲染成对应的折线图，并绑定导出数据等交互事件，做过低代码产品的同学应该知道，这一层就很像前端渲染器层。

七、最后总结

过去我们聊前端，是组件、路由、状态管理；未来聊前端，是语义、生成、约束、编排。这种范式改变，比前两年的低代码平台要狠很多倍，它正逐渐改变前端开发的日常工作和各种 AI 产品的用户体验。

这套实现方式的关键，不在于“AI 能不能生成界面”，而在于“生成过程是否可控”。模型负责语义，前端负责约束与渲染，中间通过 JSON 建立协议层。

前端不再只是承接后端数据的展示层，而是成为 AI 生成结果的执行层和校验层。

它不是把前端交给 AI，而是让前端获得驾驭 AI 输出的能力。

最后想跟大家说：别再纠结“AI 会不会替代前端”，而是去想如何把 AI + 前端结合落地。祝大家都能乘上 AI 这趟车，发达暴富。

文章未完待续，下一篇会继续讲解 Gen UI 的缺点和实际如何落地到组件库里面。

欢迎大家关注我的公众号：深入浅出AI

55663d977f57f6cc6e888942ff5a99bb.jpg

avatar
文章
阅读
粉丝