AI GenUI 真正落地时，前端到底要做什么？

上一篇我写了一个观点：前端没有"死"，而是在 AI 时代进化成了"GenUI"范式。

很多同学看完以后，追问了我 2 个问题：

这东西到底能不能落地？
如果真能落地，前端到底要做什么？

所以这一篇，我不再继续停留在趋势判断上，而是往前走一步，跟大家聊三个最现实的问题：

GenUI 到底怎么工程化落地
它有哪些真实缺点和限制
传统组件库要怎么进化，才能真正适配 AI 时代

先给大家抛个结论：

GenUI 能落地，但绝不是"接一个大模型接口，让 AI 帮你生成页面 "这么简单。真正难的地方，不在"生成"，而在"怎么把生成这件事做成一个稳定、可控、可维护、可上线的工程系统"。

一、不是让 AI 随便生成页面

我敢说，很多人第一次接触 GenUI，脑子里都会冒出一个极其简单的方案：

用户说一句需求 → 模型直接生成 React / Vue 代码 → 前端把代码渲染出来 → 一个"AI 自动做页面"的系统就诞生了。

这个方案做 Demo 的时候，确实爽到飞起------输入"做一个营收看板"，几秒就出一个带图表、指标卡的页面，用来做技术演示、骗投资人，效果拉满。

但只要你往真实业务里走一步，就会发现问题一大堆，我随便列几个我实际落地时踩过的坑：

模型输出代码不稳定，同样的需求，两次生成的代码结构完全不一样
代码风格和团队现有规范脱节，后续维护成本直接翻倍
生成的代码很难接入现有组件体系
权限、事件、数据边界一团乱，比如按钮点击事件没绑定，敏感数据直接暴露，有 XSS 风险

所以我一直强调，GenUI 真正可行的路线，不是"模型直接生成代码"，而是：模型输出语义，前端渲染语义。

这句话看起来简单，但其实是整个 GenUI 工程化的核心，没有之一。

也就是说，模型不应该直接写页面源码，而应该输出一份受约束的结构化 JSON。这份 JSON 里，必须写清楚四件事：

用哪些组件（比如是指标卡还是表格）
每个组件传什么参数（比如指标卡的标题、数据路径）
数据从哪里来（比如从哪个接口、哪个字段取数）
哪些地方允许交互、可以触发什么动作（比如点击按钮导出 Excel）

然后由前端来做三件核心工作，把"模型的输出"变成"用户能用上的页面"：

校验这份 JSON 合不合法，防止模型输出"乱码"
把 JSON 翻译成真实 UI，对接现有组件库和业务逻辑
保证整个交互过程稳定可控，比如状态联动、异常回滚

所以线上真正可用的链路，从来不是"用户意图 → 模型写代码 → 渲染"，

而是：

用户意图 → Prompt 编排 → 模型输出 JSON 语义 → Schema 校验 → 渲染器执行 → 状态联动与交互闭环

二、不是生成，而是"可用"

市面上很多 Demo 或者 AI 生成代码的产品看起来都很厉害：输入一句自然语言，AI 马上生成几个指标卡、一个图表、一张表格，视觉上已经很像一个完整页面了。

包括我所知道的以下几家产品，其实压根没有维护性，面向的人员也不是程序员

bolt.new
Vercel V0
screenshot-to-code

下面这几个产品是面向程序员的，维护性会好一点

Builder.io
Locofy.ai
Anima
Figma to Code

但我想问大家一个问题："看起来像页面"，就等于**"真的能用吗"**，可维护吗？

答案显然是否定的。

比如你让 AI 生成一个营收看板，这件事本身并不难。但真正难的，是看板背后的"可互动"。

案例：营收看板 GenUI 落地实操

先跟大家说清楚这个案例的核心信息：

场景角色：运营人员（非技术）、前端开发、数据开发
核心目标：让运营人员通过自然语言，快速生成符合业务规范的营收看板，无需前端手动开发
输入：运营的自然语言需求（比如"生成近30天华东地区营收看板，包含总营收、营收趋势图、地区明细表格，支持导出Excel"）
处理流程：

运营输入需求，前端对需求进行简单预处理（提取核心关键词：时间范围、地区、组件类型、动作）；
前端将预处理后的需求，结合 Prompt 模板（包含组件白名单、参数约束），传给大模型；
模型输出结构化 JSON 语义（包含 MetricCard、LineChart、DataTable、ActionButton、Form 五类组件，及对应参数、数据路径、动作）；
前端通过 JSON Schema 校验 JSON 合法性，补齐缺失参数、过滤非法组件；
前端渲染器将 JSON 翻译成真实 UI，对接数据接口获取营收数据；
实现组件联动（筛选器切换地区，图表和表格同步更新）、动作触发（点击导出按钮，获取当前页面状态并调用导出接口）。

输出与校验：

输出：符合业务规范的营收看板，支持筛选、联动、导出等交互；
校验：前端校验（JSON 合法性、组件权限）、运营校验（视觉和功能是否符合需求）、数据校验（数据准确性，对接数据开发的校验接口）。

这个案例里，AI 只做了一件事：输出 JSON 语义。而所有"让看板能用"的工作，全是传统前端做的事情。

比如运营说"再加一个转化率趋势图"，模型只需要新增一个 LineChart 的 JSON 配置，但前端要做的是：新增图表组件渲染、绑定转化率数据路径、实现图表与现有筛选器的联动、保证图表样式和现有页面统一。

所以我越来越觉得，GenUI 的关键从来都不是"生成几个组件 "，而是"生成一个能运转的交互系统 "。如果组件之间不能通信，状态不能流动，数据不能闭环，那这个系统再炫，也只是一个"会动的截图"，根本进不了生产环境。

三、GenUI 落地时，前端最核心的 5 件事

结合上面的案例，我梳理了 GenUI 落地时，前端必须扛起来的 5 件核心工作，每一件都关系到项目能不能上线、能不能稳定运行。

3.1 核心工作拆解

1. 建立强约束层，防住模型的"不稳定性"

大模型输出不是数据库查询结果，它天生就带概率性------即使你给了统一 Prompt 和 Schema，也依然可能出现组件名不合法、props 缺失、输出不完整 JSON 等问题。

所以只要做 GenUI，前端必须先接受一个现实：模型输出永远不能被直接信任。不能直接当成可执行结果。

这就要求前端在中间加一层明确的约束机制，我目前落地时常用的有这几种：

JSON Schema 校验：定义组件、参数、数据路径的规范，不符合规范的 JSON 直接拦截
Catalog 白名单校验：明确告诉模型，只能使用白名单内的组件，避免生成非法组件
action 能力范围校验：限制模型能触发的动作（比如只能导出、刷新，不能删除数据）
默认值补齐策略：如果模型缺失非必填参数，前端自动填充默认值，保证页面正常渲染
非法结构过滤策略：如果 JSON 结构错乱，直接返回兜底页面，避免页面崩溃

以前前端主要防后端脏数据 ，未来前端还要防模型"脏语义"------这是 GenUI 时代，前端的第一个新职责。

2. 开发渲染器，把 JSON 变成可交互的 UI

渲染器是 GenUI 落地的核心载体，也是前端工作量最大的部分之一。它的核心作用，就是把模型输出的 JSON 语义，翻译成用户能看到、能操作的真实 UI。

这里要注意，渲染器不是简单的"JSON 转 DOM"，而是要对接现有组件库、业务逻辑、数据接口，还要处理各种异常情况------比如模型输出的组件不存在、数据路径错误、动作绑定失败等。

我建议大家不要一开始就做"万能渲染器"，先从最小可用版本做起：先支持固定的 3-5 种核心组件（比如指标卡、图表、表格、表单），跑通渲染、数据绑定、动作触发，再逐步扩展。

3. 处理状态编排，解决多轮对话的"混乱问题"

单轮生成是最容易做的，但真实场景里，用户会不断改需求------比如"把日维度改成周维度""再加一个转化率趋势图""默认筛选改成华东地区"。

这时候，前端就要面对一个核心问题：如何处理多轮对话后的状态更新？是全量重建页面，还是局部更新?之前用户手动点选的状态（比如筛选条件）要不要继承？模型生成的状态和前端当前状态怎么合并？

我目前的做法是，前端维护一个"页面状态池"，记录当前页面的组件配置、筛选条件、交互状态。每一次用户修改需求，模型输出的不是完整 JSON，而是"局部变更语义"（比如"修改 LineChart 的 x 轴维度为周"），前端根据变更语义，更新状态池，再局部刷新页面------这样既能保证状态不丢失，又能提升体验。

4. 改造组件库，让组件"能被 AI 理解"

很多团队现在都有自己的组件库，比如 AntD 二次封装、业务物料库 ，但这些组件库绝大多数都是"给开发者用的 "，不是"给模型用的"------文档是写给人看的，props 边界不清晰，组件彼此独立，没有统一的 AI 可读 Schema。

结果就是：组件明明很多，但模型根本不知道该怎么选、怎么配、怎么组合。

所以前端必须改造组件库 ，核心是给组件加一层"AI 可理解的协议"------比如定义组件的语义描述、参数约束、可触发动作、输入输出协议，让模型知道"这个组件能做什么、该怎么用"。

5. 优化流式体验，平衡速度与稳定性

为了提升用户体验，很多 GenUI 系统会采用 Streaming（流式返回）------用户不需要等完整 JSON 返回，就能边生成边看到界面。但这也会引入新的问题：分块 JSON 怎么拼接？不完整结构怎么校验？中间生成失败怎么回滚？页面局部更新怎么避免抖动？

前端要做的，就是在流式反馈、结构合法性和页面稳定性之间找到平衡点。我目前的做法是：先返回基础布局 JSON，优先渲染页面框架，再逐步返回组件细节 JSON，同时做"中间态渲染"（比如加载占位符），避免页面抖动；如果某一块 JSON 校验失败，直接回滚到上一个稳定状态，保证用户体验。

四、GenUI 落地实操

最近有些人问我："我们团队想试试 GenUI，该从哪里开始？"

我的答案是：不要一上来就做"万能动态页面引擎"，那样十有八九会做崩。更务实的方式，是先挑一个高标准化、低风险、可复用的场景，按以下 4 步落地，循序渐进。

第一步：先挑一个适合生成的业务场景

不是所有页面都适合 GenUI，优先选那些"结构相对标准、参数经常变化"的页面，比如：营收仪表盘、运营报表、查询表单、BI 分析页、客服辅助卡片。

这些场景有几个共同点：组件种类有限、页面规律明确、用户意图容易表达、工程风险相对可控，很容易形成 MVP，也更容易做出闭环。

但像下面这些场景，不建议一开始就做 ：高度定制的营销页、强交互动效页面、权限极复杂的核心后台、品牌视觉要求极高的页面，还有就是to C 的商品详情页，用户下单页面------这些页面对细节控制太强，不适合先用生成式方式切入。

第二步：先定义一套最小可用 Catalog

在接模型之前，前端先做一套最小能力清单，明确告诉模型：你只能用这些组件，只能传这些参数，只能做这些动作。

一个最小可用 Catalog 通常包含 4 部分：

组件类型：比如 MetricCard（指标卡）、LineChart（折线图）、DataTable（表格）、FilterForm（筛选表单）、ActionButton（操作按钮）
参数约束：比如 title 必须是 string 类型、valuePath 必须是合法数据路径、chartType 只能是枚举值（line/bar/pie）
可触发动作：比如 exportExcel（导出 Excel）、refreshData（刷新数据）、submitFilter（提交筛选）
布局规则：比如哪些组件允许嵌套、哪些组件只能作为根节点、哪些区域允许图表和表格混排

当然还有是否可见，可循环，是否允许子元素等等。这一步本质上是在做一件事：把前端组件能力，从"开发经验"整理成"模型可消费的语义协议"

第三步：先做静态 JSON 渲染器，再接模型

不要一开始就把问题交给大模型。建议前端先手写 JSON，做一套静态渲染器，把这些事情先跑通：组件树能不能正确渲染、props 映射合不合理、数据绑定通不通、action 能不能触发、状态联动有没有闭环。

只有静态 JSON 渲染器足够稳定，后面接入模型才有意义。否则你会把**"模型输出问题"和"渲染架构问题"**混在一起，最后查起来很复杂。

第四步：让模型只输出 JSON，不输出代码

等渲染器跑通后，再让模型接入。但一定要守住一个原则：模型只输出 JSON 语义，不输出 React / Vue 代码。

给大家看一个简化后的模型输出示例。

json 复制代码

{
  "page": "revenue_dashboard",
  "components": [
    {
      "type": "MetricCard",
      "props": {
        "title": "总营收",
        "valuePath": "summary.totalRevenue"
      }
    },
    {
      "type": "LineChart",
      "props": {
        "title": "营收趋势",
        "xDataPath": "trend.date",
        "yDataPath": "trend.value"
      }
    },
    {
      "type": "ActionButton",
      "props": {
        "text": "导出 Excel"
      },
      "action": {
        "name": "exportExcel"
      }
    }
  ]
}

JSON 结构要固定、字段可校验、行为受控、数据引用标准化。只要这几件事做到了，前端就能把模型输出纳入一个真正稳定的工程体系。

五、GenUI 的缺点，及前端的应对办法

我一直很看好 GenUI ，但它不是"银弹"。它很有潜力，也有非常明确的现实成本

1. 前期基础设施成本不低

GenUI 减少的是"重复写页面"的成本，但增加的是"底层协议建设"的成本。前端前期通常要投入在这些地方：Catalog 设计、Schema 建设、渲染器开发、Prompt 编排、状态协议设计、兜底和回退机制。

办法：优先选择标准化场景做 MVP，避免一上来就做全量功能；复用现有组件库和工具，减少重复开发。

2. 灵活性和可控性天然冲突

你越想让 AI 自由发挥，结果就越不可控；你越想要系统稳定可上线，就越要给它加边界。这个矛盾几乎不会消失。

办法：前端通过 Catalog、Schema 划定"边界"，在边界内给 AI 一定的灵活性；比如组件的样式、顺序可以让 AI 调整，但组件类型、核心参数必须符合约束。

3. 调试链路比传统前端更长

传统页面出问题，通常看代码、看接口、看控制台就行。但 GenUI 出问题时，可能要一路排查：用户输入是否有歧义、Prompt 是否带偏、模型理解有没有偏差、JSON 输出哪一步错了、Schema 为什么没过、渲染器是否兼容。

办法：前端搭建一套完整的日志监控体系，记录用户输入、Prompt、模型输出、校验结果、渲染日志，方便快速定位问题；同时做"异常兜底"，任何环节出错，都能返回一个可用的兜底页面。

4. 用户对稳定性的预期极高

用户第一次体验 GenUI 会觉得很聪明、很高级，但只要后面偶尔出现"生成失败、结构错乱、状态丢失"，都会打击用户的心情。

办法：前端优先保证稳定性，再优化体验；比如增加"二次校验"，再次生成，避免错误页面暴露给用户；同时做"状态备份"，用户每一次操作都备份当前状态，即使生成失败，也能回滚到上一个稳定状态。

六、总结：GenUI 时代，前端未"死"

聊到这里，我想再回到大家最开始的问题：GenUI 落地时，前端到底在做什么？

我的答案是：前端不再是"重复写页面的人"，而是"GenUI 工程化的核心推动者"------我们定义生成规则、维护组件 Catalog、设计 Schema、处理状态编排、优化用户体验，把 AI 的"概率性输出"，变成"可上线、可维护、可复用"的工程能力。

GenUI 不是让 AI 替代前端，而是让前端获得组织 AI 输出的能力。真正有价值的，不是谁能最快生成一个页面，而是谁能把"生成"这件事，做成一个有边界、可校验、可联动、可维护、可上线的工程系统。

而这套系统的核心，恰恰还是前端来做。

最后，我想大胆预测一下未来 3 年前端的变化。

UI 生成化会越来越常态化
传统组件库会内建"AI 可理解的协议"
前端的能力模型会从"手写页面"转向"制定规则"

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