过去几年里，我们习惯了一种交互方式：打开对话式 AI，输入问题，拿到一片 Markdown 格式的答案——列表、加粗、小标题。内容很完整，但你有没有遇到过这种时刻：让 AI 安排一场出差，它给了你一份条理清晰的行程单，甚至贴心地用表格排好了时间。然后呢？你还是得自己打开日历，把几个会议一条条敲进去；还得再去查航班、订酒店。那一刻你会明显感觉到，AI 在“生成答案”这件事上已经很强了，但用户要的其实不是答案，是“事情被办成”。
从把内容写出来，到一个真正能点、能选、能提交的界面，中间这段路，就是 Generative UI 想要解决的问题。
这篇文章我想聊聊它到底是什么、和传统生成内容的核心差异在哪、一条能落地的实现链路长什么样，以及我自己在动手之后撞上的各种墙和沉淀下来的判断标准。适合正在做 AI 应用的前端开发者、对交互设计感兴趣的产品同学，以及想搞清楚“AI 生成界面是不是噱头”的人。
1. 生成答案和生成界面，差别不在“界面”而在“可操作”
1.1 Markdown 是一种“宽泛答案”，界面是一种“精确行动”
先说一个容易被忽略的事实：Markdown 本身是一种很聪明的产物。它纯文本、零依赖、任何设备都能渲染，而且保留了基本的文档结构语义。问题是，它只能表达“读”的结构，不能表达“做”的动作。
一个行程安排的 Markdown 列表，本质上是一条信息流。你读到“9:00 和客户开会”，但你没法在这个列表上把会议改成 10:00，没法点一下某个酒店卡片直接发起预订，更不会有“保存按钮”的概念。所有后续动作，都得靠你手动翻译到另一个工具里去执行。换句话说：Markdown 把 AI 的思考结果交给了用户的眼睛，却没有交给用户的手。
而界面这个东西，从来不只是排版。一个界面里藏着三个维度：布局（内容怎么摆）、状态（现在处于什么阶段）、事件（用户点了之后发生什么）。当你要求 AI 生成一个界面时，其实是在要求它同时决策这三件事——它不能只告诉你“这里有一个按钮”，还必须告诉你按钮长什么样、点击后执行哪个动作、动作执行后界面如何变化。这就比“用文字描述一个方案”复杂了一个数量级。
1.2 布局、状态、事件：生成界面要同时决策的三件事
我把这三件事拆开说，你就能理解为什么 Generative UI 不是“把内容套进好看的模板”那么简单。
首先是布局。普通生成内容只需要决定文字顺序，而界面需要决定元素在二维空间里的排布。同样是“展示两个候选产品”，上下堆叠、左右分栏、还是做成可切换的 Tab，对用户的理解成本完全不同。模型如果选择了不适合信息密度的布局，用户会立刻感到“这个 AI 做出来的页面很怪”。
其次是状态。界面是有生命的，它必须知道自己处于什么状态。表格正在加载、表单校验失败、任务已经提交成功、列表被过滤到只剩两条……这些状态在传统开发里靠代码逻辑维护，但如果界面是 AI 生成的，模型必须在生成时就意识到“这个界面会被操作，操作之后它要演进成什么样”。
最后是事件。这是 Markdown 完全不具备的维度。界面上的每个按钮、输入框、选项卡背后都挂着一个行为。AI 不只是“画”出一个界面，还要把这些行为绑定到外部系统上——点“提交”要调哪个接口，改日期要触发什么查询。
所以你看，从 Markdown 到 Generative UI，表面上是从文字到图形元素的跃迁，实际上是 AI 第一次需要为“交互闭环”负责。它生成的不再是一个供人阅读的文档，而是一个供人操作的入口。
2. Generative UI 为什么是现在才火：三个外在条件刚好齐了
2.1 结构化输出能力成熟：模型终于能说“规格”而不是“故事”
Generative UI 并不是一个全新概念，早几年也有人做让 AI 直接输出网页模板的方案。但在大模型能力还不行的年代，你让模型生成一个“描述界面的结构化规格”，它给你的更像是一段带着幻想色彩的故事：颜色、布局、文案都描述了，但没法被解析成真正的控件。
这几年变化最大的，是模型的结构化输出能力。现在主流大模型已经能够在约束条件下稳定输出合法的 JSON 结构，你给它一个 JSON Schema，它能像一个听话的实习生那样按字段规范填空。这一点是 Generative UI 的地基：没有可靠的结构化输出，后面所有“界面即数据”的玩法都无从谈起。
另一个容易被忽略的进步是模型的上下文理解能力。早期 AI 只能根据你的一句话生成孤立页面，现在的模型能记住对话历史、理解页面状态、推断用户当前处在哪个任务流里。它能判断出“用户要求订酒店之后，下一步大概率是选择房型”，然后提前把这一步的界面结构准备好。这种对任务流的感知，才是 Generative UI 体验上质的提升。
2.2 组件化设计系统：界面第一次可以被当作积木而非画布
第二个契机来自前端行业自己的沉淀。过去十年，组件化思想几乎重塑了整个前端开发：按钮、卡片、表单、弹窗，这些被反复使用的元素被封装成标准化组件，配合设计系统，形成了一套“有统一规范、有明确参数、可组合”的界面积木。
这对 Generative UI 的意义是决定性的。试想一下，如果模型每次生成界面都要从零描述一个“圆角 8px、阴影 2px、背景色 #FFFFFF”的按钮，那生成结果必然千奇百怪，也没法保证视觉一致性。但有了组件化的基础，模型只需要说“这里放一个 primary 尺寸的 Button，文案是‘提交订单’”，渲染端就知道该画什么画。组件化相当于把“描述界面”这件事从绘画题变成了选择题和填空题，难度的下降是指数级的。
而且设计系统还天然附带约束：组件能接收哪些参数、哪些 props 合法，模型可以通过 schema 快速学会。于是，“让 AI 生成界面”就变成了“让 AI 从一本有边界的积木手册里挑选并组装”。
2.3 交互范式迁移：用户不再需要“读”界面，而是“用”界面
第三个条件可能不在技术范畴，但同样关键——用户的习惯变了。过去大家使用软件的路径是“先选一个工具，再在工具里操作”；现在的对话式 AI 让很多人习惯了一种新路径：“先用自然语言说清楚目标，再看 AI 给我什么”。
这种习惯转变带来了一种心理预期：用户希望对话结束之后，AI 不只是“回答我”，而是“帮我继续把事情做完”。“帮我订一个周五下午的会议室”这句话的终点不是一段文字，而是一个可以选时间段、看空闲、点确认的可操作面板。当用户开始期待这个闭环时，Generative UI 就不再是工程师的玩具，而成了产品体验的必需品。
三个条件叠加在一起，效果是化学反应式的：模型能输出规格，前端有组件可用，用户愿意接受对话式入口。这才有了“生成答案”向“生成界面”进化的现实土壤。
3. 让模型输出“界面蓝图”：一条亲测可行的落地链路
3.1 核心思路：把界面定义为数据，而不是让模型写代码
聊完了背景，进入正题。如果你要在项目里引入 Generative UI，第一步要做的不是选框架，而是定一个基本思路：不要让模型直接生成可运行的代码，而是让模型生成一段“界面蓝图”，由前端渲染器把蓝图变成真实界面。
为什么不直接让模型写 React 或 Vue 代码？我在一开始也踩过这个念头，验证之后发现至少三个问题：一是代码生成的安全边界很难控制，模型理论上可以输出任意语法，大到引入危险操作，小到语法错误导致整个页面崩溃；二是模型输出的代码风格不稳定，你不知道它今天会写 class 组件还是函数组件，渲染端根本没法统一接管；三是调试链路特别长——报错信息是模型的、组件是自己的、样式又是动态插入的，三方混在一起无法排查。
所以更稳妥的方案是定义一个“界面描述协议”。它介于自然语言和真实代码之间：结构清晰、字段固定、好校验、好渲染。我常用 JSON 作为载体，协议大概长这样：
{ "schema_version": "1.0", "root": { "type": "container", "layout": "vertical", "spacing": "medium", "children": [ { "type": "header", "title": "出差行程安排", "subtitle": "3月12日 - 3月14日" }, { "type": "date_range_picker", "key": "travel_dates", "label": "选择出差日期" }, { "type": "list", "key": "meeting_list", "items": [ { "title": "客户需求对齐会", "time": "10:00", "location": "A301" } ], "item_actions": ["view_detail", "navigate_to"] }, { "type": "button_group", "placement": "bottom", "buttons": [ { "label": "保存行程", "action": "save_itinerary", "variant": "primary" }, { "label": "清空重排", "action": "reset_schedule", "variant": "secondary" } ] } ] } }这段 JSON 里没有一行真实代码，但任何一个前端开发看了都知道它能渲染成什么样子。模型的工作是“选组件、配参数、排结构”，而不是“写实现”。这就是 Generative UI 和“AI 生成网页”最大区别：前者生成的是可解释、可约束的规格，后者生成的是无法审查的泥团。
3.2 组件注册表：给生成界面装上白名单
有了协议，下一步就是建立组件注册表。这是安全与稳定最关键的一道闸门。
我建议把系统里允许被 AI 调用的所有组件登记进一个白名单注册表。每个组件在注册表里要有清晰的信息：组件名、支持的 props schema、事件列表、以及渲染器代码的入口。模型在生成时只能从这个注册表里挑选组件，超过了就视为非法。这一步把“AI 生成界面”强制变成了“AI 在限定积木池里做组合”。
为什么必须这么做？因为 Generative UI 的风险本质上等同于“模型在执行代码”。如果它不需要白名单，直接吐一个组件名，而这个组件又恰好能读取用户敏感数据、或者调用更新操作，那后果很难追查。注册表的本质，是给生成过程套上一层“权限沙箱”——就算模型想越界，它也够不到不在注册表里的东西。
还有一个好处是视觉一致性。注册表里的组件背后是同一套设计语言，不管模型怎么组合，最终界面都不会出现风格漂移。我做 PoC 时深刻体会到，用户对“AI 生成界面”的容忍度其实很低——只要界面长得到处都不一样，第一反应就是“这不是我们公司的东西”。白名单能让你保持品牌一致性，同时也守住底线。
3.3 状态与事件：渲染器只是开始，运行时才是主角
拿到了蓝图、有了组件注册表，接下来面临的问题是：渲染器把界面画出来之后，这个界面能不能像一个正常页面那样工作？
很多人做 Generative UI Demo 时，到渲染这一步就停了。页面确实出来了，按钮也能点，但点了之后怎么办？没有下文。这其实是演示和产品之间的天堑。
完整的运行时必须处理三件事：事件路由、状态同步、局部更新。
事件路由是指界面上每个动作都要映射到真实的行为处理逻辑。比如“保存行程”按钮，前端拿到 action 名，去注册表查一下这个 action 对应的处理器是什么——可能是调用后端接口、可能是打开日历应用、也可能是切换到另一个生成界面。这里不建议把具体业务逻辑都写进模型生成的蓝图里，蓝图里应该只保留 action 的名称和必要参数，具体执行交给前端本地已注册的处理器。这样可以避免模型介入过深，也方便排查问题。
状态同步是指生成界面要能和业务系统的数据保持对齐。举个例子，AI 生成了一个“选择会议室”的界面，它是怎么知道哪些会议室是空闲的？答案是在生成时把相关数据作为上下文给到模型，界面渲染后通过接口实时刷新。这里要注意：状态同步不能只做一次性拉取，界面里的时间筛选、房间类型过滤等操作，都要实时触发数据回源。
局部更新是让用户信任动态界面的关键。用户点了“筛选”按钮之后，如果整个页面重新生成一遍，视觉上会有明显跳动，用户会立刻察觉到“这是个 AI 生成的不稳定页面”。正确做法是让蓝图支持局部节点更新：按钮点击后，只重新生成受影响的那部分子结构，其他区域保持不变。这需要你的渲染器具备差异渲染能力——它要能比对旧蓝图和新蓝图，计算最小变更范围，再执行更新。
说句实在话，现阶段市面上现成的 Generative UI 框架还很少，很多能力需要自己搭。我建议把重心放在运行时上：渲染器能用开源的方案就先开源的，但事件路由、状态同步和局部更新一定要自己设计成可扩展的模块，因为后期几乎所有复杂问题都出在这三层。
4. 稳定、安全、信任：把 Demo 变产品时撞上的三堵墙
4.1 稳定性：同一个诉求，两次生成两张脸
我在实际体验中最先撞上的墙是结果不稳定。同一个用户、同一个请求、模型服务的参数完全一致，但生成出来的两次界面布局就是不一样。第一次用的是上下结构的预览卡片，第二次变成左右分栏的表格形式。文字内容基本对，但结构漂移相当明显。
这种不稳定会带来几个后果：第一个是自动化测试没法写，因为页面结构不可预测，选择器都定位不到；第二个是用户会迷茫，上次用这个功能时界面长这样，这次长那样，学习成本直接被拉高；第三个是业务方不认可，他们希望“AI 生成界面”至少看起来像正经功能，而不是一个薛定谔的页面。
我后来总结出的应对思路是三层组合拳。第一，模型层面做 few-shot 约束，在 system prompt 里给出 3-5 个固定风格的蓝图示例，明确告知“所有输出必须严格模仿示例的结构风格”。第二，在后处理层做结果规范化，写一个校验器，对于布局类型、组件顺序、字段完备性做强制修正，发现不符合预期的直接打回让模型重新生成一次。第三，在业务层面给不同场景绑定“默认布局偏好”，比如表格优先、列表优先、表单优先，模型选择布局时只能在偏好范围内选，不能自由发挥。
这套组合下来，大体上能保证同一类请求的界面结构有八成以上的相似度。但我也得诚实地说，要做到像素级稳定，现阶段还是很难，只能靠约束范围不断缩小来逼近。
4.2 安全：AI 生成界面约等于受约束的代码执行
安全这堵墙，一开始我低估了。前面讲了组件注册表，这是我们应对的第一道防线。但光有白名单还不够，还有两类安全问题值得单独拿出来提醒。
第一类是参数注入。模型生成蓝图时，组件 props 里的数值是它自由填写的。它可能在一个显示区域塞入超长的文本，把布局撑爆；可能在数字字段填了负数或者极大值，导致渲染组件崩溃。所以渲染器里必须有一套运行时校验，对每个组件的 props 做 schema 验证，发现非法值就降级到默认状态，而不是直接抛异常。这个机制和接口入参校验是一个思路。
第二类是行动风险。界面上的按钮可能触发写操作——发邮件、提交订单、修改数据。AI 生成界面这个机制本身是无辜的，但如果某次生成结果错误地把“删除”按钮放在了显眼位置、或者把“提交正式订单”的按钮渲染成了主色调，用户很容易误点。我的建议是：蓝图协议里必须给每个 action 标注风险等级，渲染器根据等级决定按钮样式；高危操作还要在用户确认后额外弹出确认框。如果是首次生成的高风险动作，宁可禁用，也不让用户下意识就点了。
安全这种东西，做在暗处用户感知不到，但是少做一层，出问题的时候大概率是致命的。
4.3 信任与可解释性：动态界面会让用户失去掌控感
第三个墙比前两个更隐晦，它来自用户的心理层面。
传统的软件界面是静态的，用户知道这个页面为什么长这样，因为它每次来都一样。但 Generative UI 的界面是动态生成的，用户难免会想：你这个界面凭什么长这样？那些选项是怎么筛出来的？是不是漏掉了什么？
我做过一个小实验，把同一个任务分别用固定模板界面和动态生成界面展示给一批使用者。结果显示，动态生成界面的任务完成率其实更高，但用户的“掌控感评分”反而更低。深入访谈后发现问题出在透明度上——用户觉得固定模板是公司设计好的，可信；动态生成界面“像是一个不太熟的助手在自作主张”。
应对这个问题，我总结了几件事可以做。第一，给生成界面标记“来源”，比如界面上保留一个入口按钮“此页面根据您的需求定制”，点开能看到 AI 解释它为什么推荐这种布局和选项。第二，尽量在生成界面里保留一些“稳定锚点”，比如固定的页面标题栏、固定的返回键、固定的品牌元素，让用户感觉始终还是在这个产品体系里。第三，给用户控制权——程序生成的界面应该允许用户手动调整局部内容，比如自己删掉一个卡片、改一下排序规则。哪怕只是很小的操作自由度，都能极大提升掌控感。
说到底，Generative UI 往前走的阻碍，技术是一个层面，用户信任是更大的层面。
5. 边界在哪：Generative UI 是万能药，但不是所有界面都该用它
5.1 适合的场景：任务型界面、数据决策、表单流程
聊了这么多坑，也得把话说回来。Generative UI 不是万能药，但在某些场景它是真的香。我归纳了一个筛选原则：如果界面产生的价值在于“帮助用户完成任务、做出决策”，它就有被生成的价值。
排在第一梯队的是任务型界面。出差行程管理、活动报名流程、设备报修工单、任务分发面板——这些界面的共同点是用户知道目标、但不想花时间钻研怎么操作。AI 可以直接在对话里问清楚条件，然后生成一个带表单、带按钮、带状态反馈的操作面板，用户在这个面板里把事情办了，任务闭环。
其次是数据决策界面。比如用户问“帮我对比这两个套餐，哪个更适合我这种情况”。传统做法是给用户看一个大表格，让他自己读，然后自己比较。用 Generative UI，AI 可以直接生成一个对比组件，加上几个过滤滑杆，把“适合度权重”做成可交互控件，用户拨一拨就能看到推荐结果变化。这种体验完全值得动态生成。
还有一大类是表单流程。真实世界的表单有大量分支逻辑：选了 A 选项才会出现 B 字段，填了 C 字段才解锁 D 按钮。这些分支条件如果在开发阶段写死，要花大量人力；但如果交给生成式逻辑在运行时动态组织，效率会高很多。只要做好字段与数据流的校验，生成表单的实际落地价值非常大。
5.2 不适合的场景：品牌表达、情感共鸣、精细视觉
反过来，有一些场景我会主动劝退团队。品牌官网首页、大型营销活动页、需要强烈气质表达的视觉页面，这些一律不适合。
原因很简单：这类页面的价值密度不在于“完成任务”，而在于“传递感觉”。品牌首页的留白、动效、字体、层次，背后是一整套视觉策略，靠 AI 动态拼装组件很难做出真正的质感和独特气质。让模型生成品牌页面，结果往往是“看起来挺正常但毫无记忆点”——这在品牌传播里几乎是致命的平庸。
同理，需要极强情感共鸣的场景，比如公益募捐页面、纪念专题页，也不建议用 Generative UI。这类页面讲究叙事节奏和情绪引导，而模型生成的布局天然偏向理性和通用化。不是说生成式能力做不到极致，而是当下的成本收益完全不成正比。
5.3 我常用的判断标准：三类问题一次过滤
当你犹豫一个功能该不该上 Generative UI 时，可以先问三个问题：
界面结构是稳定还是易变？如果界面半年才改一次、模板调整频率极低，那用模板开发反而更简单。动态生成的价值在于结构经常需要按上下文变化，模板维护成本太高。
用户的重心是“看”还是“用”？如果用户是来阅读内容、感受氛围的，界面是内容容器，静态模板更可控。如果用户是为了完成一个动作、搞定一个流程，界面是操作工具，生成式的灵活度才有发挥空间。
一线业务方有多少种变化需求？如果你面对的运营或者业务方，每天都会提出“这里想多放一张卡片”“那个地方想根据用户类型换一种展示”，模板版本会滚雪球一样膨胀。而生成式的方案可以让业务方用自然语言描述变化，按上下文动态编织。当变化需求多到人力难以承担，就是 Generative UI 进场的时候。
用这三条过滤一遍，大部分“要不要上”的纠结都能理清。
6. 动手做一轮之后，我沉淀下来的判断标准和几个意外收获
6.1 做 PoC 时发现的几个反直觉收益
最初我接触 Generative UI，是单纯被“AI 画界面”这个概念吸引的。真正做了一个完整可用的 PoC 之后，收获却超出了“界面”本身。
第一个意外收获是对埋点体系的重构。传统界面的埋点依赖于开发者在写代码时手动添加事件上报，一旦漏加，数据就永远缺失。而生成式 UI 的蓝图本身是结构化的，每个组件节点天然自带路径信息。我能在渲染器层面做一次全局埋点代理：任何组件只要被渲染出来，它的曝光、点击、操作时长都会自动上报，不需要业务方额外埋任何一行代码。这让我第一次体验到“数据收全”的感觉——不是靠纪律，而是靠机制。
第二个意外收获是界面和 AI 规划能力的连接变得更紧密。传统开发中，“用户意图”这个信号是模糊的，我们靠猜测来做页面跳转。Generative UI 让界面生成的前一步天然多了一层“意图解析”：模型先理解用户要什么，再生成界面。那层意图理解结果可以顺路用来做推荐、做权限判断、做话术组织。界面本身变成了一个更大的智能系统的一部分，而不再是一座孤岛。
第三个收获更偏向工程体验：调试生成的界面比想象中舒服。因为所有界面都经过蓝图协议，我在调试时只需要看蓝图 JSON 就能定位问题——“哦，这里组件顺序错了”“这个字段缺了校验”。比起传统方式反复修改堆叠的模板代码，这种数据驱动的方式在排查问题时的直观程度高很多。
6.2 接下来真正值得关注的方向
最后聊几句我对这个方向未来的观察。
短期内最值得关注的是混合渲染架构。不太可能所有界面都交给 AI 生成，更大概率是主干界面保持静态模板，关键的任务节点和个性化区域用 Generative UI 做动态渲染。这个混合架构需要解决的工程问题不少：两种模式之间如何平滑切换、动态区域的边界在哪、状态如何共享。谁先把这套基建搭稳，谁就更可能拿到落地的红利。
中期来看，我认为“生成界面”会逐步进化成“生成完整交互系统”。目前大家主要在做单页面级别的生成，下一步是跨页面的流程编排——AI 不仅要生成一个界面，还要设计用户从第一步到第五步的完整路径，并且在路径推进中动态调整后续界面。这已经把生成式能力从“画页面”提升到了“设计产品流程”的层级。
从 Markdown 到 Generative UI，本质上是 AI 从“表达”走向“行动”的缩影。表达只需要打动脑子，行动需要触碰世界。触碰世界就要面对不稳定、安全、信任这些更现实的问题——但也是从这里开始，AI 才真的从副驾位置挪到了主驾位上。我自己还在持续打磨这套方案，后面有新进展再单独写一篇聊聊。
