前端这个圈子最近被一句话搅得不安生“前端已死”。每次 GitHub 热榜上冒出类似论调底下评论区必有一场混战。但这次的情况有点不一样和这个话题一起冲上热榜的还有一个叫 AionUi 的新项目。它不是又一套组件库也不是低代码拖拽平台而是首个开源“生成式 UI”框架思路很直接——让 AI 在运行时直接“手搓”界面而不是在开发阶段帮你补全代码。我第一次看到这个概念时也愣了一下。因为过去我们聊“AI 写前端”聊的其实是让模型生成代码片段最后还是要人工复制粘贴、跑工程、调样式本质是“辅助开发”。AionUi 想做的事更激进把界面描述、逻辑绑定、渲染执行全部搬到运行时让 AI 根据当前用户、当前场景、当前数据动态生成一套可交互的真实界面。也就是说前端页面不再是一份静态产物而是 AI 在用户打开页面的那一刻现场画出来的。这篇文章不打算做夸夸其谈的项目介绍。我把它拉下来跑了一圈翻了源码结构也踩了几个坑。下面我会按“它到底解了什么题、核心原理怎么设计的、怎么接进现有项目、关键参数怎么调、问题怎么排查”这条线把 AionUi 讲明白。想尝鲜的可以直接照着操作对“前端已死”这个话题有疑惑的看完大概也能有个自己的判断。1. “前端已死”与生成式 UI这个框架到底解了什么题1.1 为什么社区突然开始喊“前端已死”“前端已死”不是一个技术判断更像一种职业焦虑的爆发。表面原因是 AI 编程助手写页面越来越快几个提示词就能生成一个带交互的 React 组件深层原因是业务后台、中台系统这类“CRUD 页面”高度重复无非是列表、表单、弹窗、详情换个字段名和接口地址就能复用。这种焦虑真不是空穴来风。我见过不少团队做一个内部管理系统一个月里 80% 的工时都花在“把一个 JSON 字段映射到表单控件”“给表格加个筛选”“处理一下空状态”上。这些活技术含量不高但需求变化频繁甲方今天加一个字段明天改一个状态前端就得跟着改一轮。如果 AI 能自动把这些页面生成出来那传统的“切图仔式”前端确实没有生存空间。但“前端死了”这个结论又下得太早。因为重复页面只是前端工作的一部分真正难啃的骨头在于“不确定的需求”和“没想清楚的交互”。AionUi 这种项目出现之后反而让这个问题更清晰了 AI 能干掉的是“确定性重复劳动”而“判断需求到底合理不合理、生成的结果对不对、边界情况怎么兜住”——这些仍然是人的工作只是工作形式变了。1.2 生成式 UI 和低代码、组件库的本质区别AionUi 官方把定位写得很清楚它不是低代码平台也不是智能组件库。我第一次看项目 README 时以为它又是一层“拖拽布局 可视化配置”的封装但读完全部文档和源码核心模块才知道这三者完全不是一回事。先看传统组件库。它提供的是“积木块”比如各种按钮、表格、弹窗。开发者在代码里手动拼装这些积木工作量大但可控性最强。问题在于拼装过程是纯手动的AI 只能帮你写胶水代码拼出来什么样还是你说了算它不负责“决定界面上应该出现什么”。再看低代码平台。它解决的是“拼装效率”问题把组件拖到画布上、配置属性、绑定数据源最终导出一份页面描述。但这份描述是静态的、提前定义好的同一个列表页模板永远是同一个样子不同用户看到的内容只体现在数据不同结构和逻辑不会变。AionUi 的生成式 UI 往前多走了一步。它把“界面本身就是一种数据”当作核心前提。AI 在运行时接收请求上下文包括用户角色、当前操作目标、数据模型结构然后动态生成一份 UI 描述框架再把这个描述渲染成真实 DOM。同一个页面普通用户看到的是简化表单管理员看到的是带批量操作按钮的管理视图新用户看到的是引导式分步表单——这些页面不是预置的不同模板而是 AI 根据实时信息“现算”出来的。我画过一张对比表方便理解三者差异维度传统组件库低代码平台AionUi 生成式 UI界面来源开发者手写代码拖拽配置后静态生成AI 在运行时动态生成可定制粒度组件级所有页面需人工编排页面模板级配置项决定形态描述层动态推断按上下文即时调整个性化能力需自行开发逻辑一般依赖内置方案天然按用户、场景、数据区分扩展成本新页面需开发新代码需维护模板组件需维护生成规则和校验约束这张表不是说 AionUi 就能完全替代前两者。生成式 UI 的短板也相当明显它引入了一个“不可完全预测”的层生成结果可能出现结构漂移、样式混乱、交互逻辑错误。为了让 AI“手搓”出来的界面不至于失控框架需要一个非常严谨的约束体系。AionUi 吸引我的地方就是它对这套约束体系的设计。2. AionUi 的设计思路与核心原理2.1 运行时生成AI 不只是写代码而是直接生成渲染描述要理解 AionUi首先得抛弃“AI 生成代码”的惯性思维。传统 AI 编程工具是生成 React/Vue 源码再让编译器或构建工具处理成页面。AionUi 走了另一条路让模型直接输出一个结构化的 UI 描述 JSON这个 JSON 不是 HTML也不是 JSX而是框架自己定义的一套 DSL叫 AUI Schema。举个最简单的例子。一个登录按钮在传统组件库里你要写Button typeprimary登录/Button在 AionUi 的运行时里模型输出的可能是这样一段描述{ type: button, props: { variant: primary, content: 登录 }, events: { onClick: auth.login } }这里有两个关键点。第一模型输出的不是代码而是数据。代码要编译要构建要处理依赖数据则可以直接解析。UI 描述和渲染逻辑被彻底分离模型只负责“决策”——页面上该有什么、长什么样、绑定什么动作渲染层负责“执行”——把描述变成真实可控的组件树。这个过程发生在运行时用户请求到浏览器之后AI 才开始生成界面所以叫“运行时手搓 UI”。第二事件绑定是声明式的。auth.login不是一段内嵌函数而是一个指向“动作注册表”的键。框架初始化时开发者会把真实的业务动作注册进去比如registerAction(auth.login, loginHandler)。AI 生成界面时只需要通过语义化名称来引用动作不需要也不允许直接输出可执行代码。这从机制上杜绝了“AI 生成了一段恶意脚本”这类安全问题。这个设计我觉得非常聪明。代码生成最难控制的就是“任意性”——模型可能写出你从未见过的 API 调用、奇怪的样式覆盖、危险的内联脚本。AionUi 用 DSL 把模型的输出能力关进了一个笼子里结构是有限的动作名称是受限的样式是走设计令牌的。模型有自由度但没有无法无天的自由。2.2 核心模块拆解渲染引擎、适配层与动作注册表AionUi 的仓库目录不算复杂核心模块大概有五个。搞清楚这五个模块的职责基本就掌握了这个框架的运作逻辑。第一个是 Schema 校验器。所有 AI 返回的 AUI Schema 在进入渲染流程前都会先过一遍定义好的 JSON Schema 校验。这一层非常重要因为大模型偶尔会输出格式残缺的内容。校验器会检查字段完整性、嵌套层级深度、属性值合法性。比如某个节点声明了grid布局但没提供columns配置校验阶段就会直接给模型返回一个错误信号让它重新生成一个合法的描述。第二个是布局引擎。AionUi 自己实现了一套轻量级网格布局系统不依赖第三方栅栏库。这个引擎能识别 Schema 里的区块、面板、栅格结构并自动计算宽度比例和响应式断点。之所以不用现成的组件库布局系统是因为生成式 UI 需要更强的动态调整能力——当 AI 中途插入一个新区块时现有布局要能自动重新排列而不是渲染出一个错位的页面。这类动态布局需求传统栅栏系统处理起来非常吃力。第三个是渲染适配层。AionUi 并不直接渲染原生 DOM而是采用“适配器”模式默认支持 React但设计上可以接入 Vue、Svelte 甚至小程序。适配层把 Schema 节点映射到具体组件的渲染函数。官方默认提供了一套基于设计令牌的组件集合组件不多胜在风格统一。你也可以把自己的业务组件注册进适配层让 AI 生成的 Schema 落到你的设计体系上。第四个是动作注册表。前面提到的auth.login这类键就存放在这里。每个动作可以声明需要的参数结构AI 生成界面时如果计划绑定动作就必须从 Schema 中携带符合声明的参数上下文。例如登录动作声明参数为{ username: string, password: string }模型就要在设计表单时让这两个字段的name指向对应的数据路径。第五个是会话记忆模块。AionUi 会缓存每次生成的 UI 描述、用户后续的修正操作以及用户行为反馈。这个模块服务于“迭代优化”它不是无脑记录历史而是按“场景 角色 目标”来打标签。同样一个用户在“查看订单”场景下强调过“表格密度要紧凑”在下一次生成相关页面时这个偏好就会被注入到生成上下文中。2.3 为什么选择“手搓”而不是“套模板”可能有人会问让 AI 基于几百个模板去匹配一个最接近的页面不是更稳妥吗为什么非要让它现场手搓我在实际试用前也有同样的疑问但跑了多个场景之后发现“模板匹配”这条路根本走不通。核心问题是模板本质上是过去经验的快照而 AI 生成界面的真正优势在于处理“没有先例”的需求。举个实际例子。我模拟了一个“项目风险预警工作台”的需求左侧一个时间线展示最近的风险事件中间是一个按概率排序的风险矩阵表右侧需要根据当前选中风险动态展示应对策略。这是一个很典型但每家业务都不一样的管理页面模板库不可能预置一个结构完全匹配的模板。用模板匹配的方法最终无非是把三个已有模板硬拼在一起页面上全是冗余组件和无效操作。用 AionUi 生成时我只需要把数据模型和用户目标描述清楚AI 自己就决定用timeline、table、panel三个节点搭建整体结构并在表格行选中时自动在右侧面板注入对应的详情描述。整个过程没有“套模板”那种笨重感它更像一个懂业务的开发者在根据需求画原型。当然完全自由生成必然带来稳定性质疑。AionUi 的应对策略不是放弃生成而是给“手搓”加上四条约束线结构深度限制、组件类型白名单、数据字段来源限定、样式令牌唯一性。所有 Schema 节点必须引用框架内已注册的组件类型不允许出现自定义动态组件名字段绑定只能指向数据上下文中真实存在的路径样式相关属性只能从设计令牌里取值比如spacing: md而不是padding: 37px。这条约束线保证了模型无论怎么“自由发挥”产出的页面都还在一个可接受的视觉和结构范围内。3. 快速上手在现有项目里接一个生成式界面3.1 环境安装与初始化AionUi 目前发布在 npm 上包名是aionui支持 React 18。安装没什么特别的和装普通依赖一样npm install aionui初始化时需要一个适配层声明指定当前项目用的运行时。以 React 为例在入口文件里做一次初始化import { createRuntime, reactAdapter } from aionui; createRuntime({ adapter: reactAdapter(), actions: { auth.login: async (params) { /* 登录逻辑 */ }, order.fetch: async (params) { /* 拉取订单 */ } }, schemaVersion: 1.0 });createRuntime返回的是一个全局单例运行时对象页面里任何组件都可以通过一个 Hook 来调用生成能力import { useAion } from aionui; function DynamicPage() { const { generate, render } useAion(); // ... }这里注意一个点动作注册的代码必须是纯逻辑函数不要在函数里直接操作 DOM。动作的实际执行结果只应该通过返回值传给运行时由运行时负责更新界面。一开始我没注意在动作里直接document.getElementById改样式结果触发了运行时状态同步的警告界面卡了半秒才刷新。后面仔细看文档才知道所有界面变更要走 Schema 重生成通道不能靠命令式 DOM 操作。3.2 写一个最简单的动态表单安装和初始化之后最值得跑的第一个例子是动态表单。因为表单是结构化程度最高、也最能体现“动态生成”价值的场景。假设你的业务需要一个“创建工单”的表单字段有标题、描述、紧急程度、指派对象。不写死任何组件直接用generate接口让 AI 生成async function loadOrderCreateForm() { const schema await generate({ goal: create a work order, dataModel: { title: string, description: text, priority: [low, medium, high], assignee: user }, constraints: { components: [input, textarea, select, userPicker], layout: vertical-form } }); render(document.getElementById(root), schema); }generate接受一个描述对象框架会把它包装成系统提示词发送给模型。关键在dataModel和constraints这两块前者告诉模型有哪些数据字段后者告诉模型可以用什么组件、按什么布局来组织。这两个参数直接影响生成质量后面第 4 节我会专门说怎么调。如果一切正常几秒后页面里会出现一张纵向排列的表单包含四个字段。比较有意思的是AionUi 生成的表单不会很死板——它通常会自动把description字段渲染成多行文本域把priority渲染成带颜色标签的下拉选项如果有已注册的用户选择器组件它还会优先使用。这些“选择组件”的决策不是模板里的硬编码而是模型根据字段类型推断出来的。3.3 绑定数据源与真实后端接口动态表单能生成只是第一步真正的业务页面必须和真实数据打通。AionUi 的做法是通过动作注册机制把“界面行为”和“数据请求”拆开。比如工单提交按钮AI 生成 Schema 时会把按钮的onClick指向ticket.create这个动作。你在初始化时已经注册过它actions: { ticket.create: async (formData) { const res await fetch(/api/tickets, { method: POST, body: JSON.stringify(formData) }); return res.json(); } }运行时会在表单数据满足字段约束后调用动作动作返回值会被当作“行为结果”注入上下文中。随后模型会基于行为结果决定下一步——是弹出成功提示、刷新列表还是展示一个新生成的结果页。这个“行为 - 结果 - 再生成”的闭环是 AionUi 最核心的使用模式。实际接后端时有一个细节值得留意数据模型描述不一定非得和接口字段完全一致。例如后端创建工单接口要求ticket_title而不是title你可以在动作注册时做映射而不必要求 AI 生成的表单字段名对齐后端字段。模型生成的是“界面字段名”动作函数中是“业务处理逻辑”中间这道桥由开发者掌握。4. 实践中的关键参数与调优记录4.1 生成粒度的权衡整页生成 vs 组件级生成AionUi 最容易被忽视的调优参数是生成粒度。它可以一次性生成整页 Schema也可以只生成局部的组件块。我在实践里发现不同场景应该用不同粒度没有哪个选项是永远正确的。第一次尝试时我基于 AionUi 构建一个完整的数据看板直接让它整页生成效果确实惊艳——页面结构和配色都很统一动态数据也能正常展示。但这个方案在“局部调整”时很痛苦。用户提出只想改一下筛选区把日期范围选择改成两个独立的下拉框。如果整页重新生成AI 可能会顺手改掉其他区域的布局原本的表格密度、图表类型都被动调整了用户就会觉得“这页面怎么每次打开都不一样”。后来我改成混合粒度方案页面骨架用一次整页生成把结构固化下来后续交互变化只针对局部区域做组件级生成。这相当于给 AI 划定了“作业范围”它只能修改指定区域其他部分保持上一个人工确认过的 Schema 不变。AionUi 提供了 patch 机制通过generateByPatch接口只对某个 Schema 节点做局部覆盖。const patched await generateByPatch({ targetPath: page.main.content.filterArea, description: replace date range picker with two independent selects, allowedComponents: [select] });这种控制粒度在实际项目里非常宝贵。生成式 UI 最大的争议就是“不稳定”而控制生成边界正是解决不稳定问题的关键手法。建议所有接生产环境的团队默认都采用“整页骨架 局部生成”的组合而不是放任每一次用户请求都重新生成整套页面。4.2 反馈回路用户修正如何让下一次生成更准上手跑通流程之后我还专门测试了 AionUi 的反馈机制。因为生成式 UI 一旦上线用户每一次操作其实都是对 AI 决策的一次隐式评分。及时发现并利用这些信号是持续提高生成质量的关键。框架提供了一套事件采集接口可以监听三类信息用户行为、显式修正、结果反馈。用户行为最常见的是“用户把表格从卡片视图切到列表视图”“用户拖拽改变了某列宽度”“用户关闭了某个不常用的区块”。这些操作本身不表示生成结果是错的但反映用户偏好。显式修正更直接例如用户在生成的表单里删掉了某个多余字段或者手动把按钮从右上角移到左下角。结果反馈主要指表单提交成功/失败、接口报错、异常操作。我让这些信号都进入会话记忆模块然后用一个简单明细表来观察效果用户操作系统提取的偏好对后续生成的影响把详情页从单栏改为两栏密度偏好横向利用优先同一场景优先输出多栏布局删掉“创建时间”字段字段偏好该角色不需要创建时间后续该角色页面不再包含创建时间多次打开折叠面板信息层级偏好辅助内容收拢生成时默认折叠非核心信息提交表单报错两次校验偏好数据须更严格约束生成时主动增加必填标记和前端校验这套机制跑起来之后最直观的感受是同一个页面三次请求生成的界面会呈现收敛趋势而不是随机波动。理论上来说用户反馈越多后续页面就越贴近他们的心智模型。想用好这个能力关键是要在初始阶段就对用户做分类——至少区分角色和场景否则偏好信号会互相污染。4.3 生成速度与体验优化运行时的灵魂是“快”生成式 UI 的软肋也恰恰是“慢”。AionUi 默认是接口调用模型我本地实验时用的模型在普通网络下返回一份复杂页面 Schema 大概需要 2 到 5 秒。如果不做任何优化用户点开页面就得盯着白屏好几秒体验上是不可接受的。想减少等待时间有几个手段比较有效。一个是缓存。AionUi 的会话记忆模块里其实带了 Schema 缓存前提是你给场景相同且数据模型相同的请求开启缓存开关。同一类页面第二次请求时直接命中缓存返回上一次的人工确认版本几乎是秒开。缓存策略需要仔细斟酌如果一个页面会因当前用户不同而不同就必须把用户角色和权限作为缓存 key 的一部分否则就会出现越权数据泄露的风险。另一个是降级策略。可以把界面生成分为“即时首屏”和“深度生成”两个阶段。首屏先生成一个尽量简单的骨架页比如一个标题加一个加载区这个骨架可以走模板几乎零延迟真正包含全部内容的完整 Schema 在后台异步生成生成完毕后再软渲染替换。这有点类似 SSR 加水合的思路用户感知到的耗时会大幅降低。还有一个偏门但很有效的经验严格限制组件类型的候选数量。模型在选择组件时候选组件越少决策就越快。AionUi 支持在调用时传入components白名单尽量只放当前场景可能用到的组件不要图省事把全部组件都开放。实测下来把候选组件从 30 个压缩到 8 个生成耗时能减少接近一半而且生成结果的准确度反而更高因为模型不用在大量无关组件里耗费精力。5. 我在实际踩坑中总结的排错清单5.1 常见问题速查表跑 AionUi 这段时间我前前后后处理过不少问题整理成一份速查表基本覆盖了新手会踩的主要坑。现象根本原因解决办法页面渲染空白但无报错生成 Schema 为空或校验未通过开启调试日志检查模型返回的原始 JSON确认生成参数里的数据模型是否合法表单提交后无反应动作名称绑定错误或动作未注册检查 Schema 中onClick的值是否在初始化 actions 中存在查看动作函数是否抛异常页面每次刷新布局都变化整页生成模式下未缓存 Schema开启场景缓存对高复用页面切换到“骨架 局部生成”模式生成结果包含未注册组件组件白名单未生效检查constraints参数是否传入框架对缺失白名单时会使用默认全量集合用户偏好没有在后续生成中体现会话记忆未开启或未按场景分类确认初始化参数开启记忆检查是否给场景标签传入了稳定的场景名称动作执行后界面不更新动作函数中直接操作了 DOM动作必须返回结果并交由运行时处理不应当手动修改页面元素移动端布局错乱生成时未声明目标设备类型在生成参数中明确添加device: mobile让模型采用响应式结构AI 生成的表单缺少校验规则数据模型中字段约束信息太弱在数据模型里补充required、maxLength、pattern等约束描述5.2 几个容易忽略的细节排错清单之外还有几个细节虽然不至于让页面崩溃但对生产环境来说非常关键。第一个是 Schema 版本管理。AionUi 的所有 Schema 只是一种 JSON 数据它应该像接口协议一样做版本管理。如果某个页面由人工确认过并缓存后来框架升级改了 Schema 结构旧缓存和新渲染引擎之间就可能出问题。我现在的做法是给每份 Schema 加一个版本号字段运行时在渲染前比对当前版本和缓存版本不一致就强制重生成。这个机制不复杂但能避免很多隐蔽的线上问题。第二个是模型生成安全。AionUi 有动作注册表机制上已经限制了可执行操作但数据提示词里如果掺入了不安全的指令模型依然可能在生成文本字段时输出“看起来像用户输入”的脚本内容。这些内容如果被后端接收后又原样渲染到页面上就是典型的注入隐患。建议在自己的渲染层二次过滤一遍富文本字段不要指望模型输出永远安全。第三个是降级体验。生成式 UI 依赖模型服务如果模型服务超时或返回格式彻底不可用线上页面不能跟着一起挂。我在初始化时配置了 fallback 方案一旦生成接口失败就立即加载一个预先写好的静态页面保证用户还能完成核心任务。这块在文档里着墨不多但我觉得对任何想在生产环境用 AionUi 的团队都是必选项。最后一个也是我最想强调的不要一上来就追求“全界面动态生成”。生成式 UI 适合用在需求变化频繁、用户差异明显的场景比如工作台、审批页、个性化报表。而像登录页、结算页这种需要强流程控制和高稳定性的核心页面老老实实手写组件反而是更负责任的选择。先用 AionUi 解决一部分高价值痛点让团队积累运行时生成的运维经验再逐步扩大范围才是更稳妥的路线。我在实际跑这个项目时最大的感受不是“前端要完了”而是“前端要做的事变了”。以前我们大部分精力花在把设计稿翻译成代码以后可能更多精力要花在“定义生成规则、约束 AI 行为、处理边界分支”上。从这个角度看AionUi 这类框架反而让前端岗位的技术含量更高了——一个只知道写静态页面的人确实会被 AI 取代但一个懂得如何设计方案、如何约束模型、如何评估生成结果的人在 AI 时代会更有价值。最后分享一个小技巧如果你准备在自己的项目里引入生成式 UI先别急着选框架或者深入源码花一下午把团队最容易重复开发的三个页面列出来针对这三个页面想清楚数据模型和动作注册表的结构。这份准备工作的价值远大于你后面读十篇文档。