AI生成UI：自由生成与配置模板渲染选型指南-平芜编程栈

1. 两条路线摆在面前时，先搞清楚它们到底在解决什么问题

做 AI 生成 UI 这件事，绕不开一个最根本的岔路口：你是让模型直接吐出一整棵界面树，还是让模型只输出一份结构化配置，再由前端代码去渲染？这个问题我在过去一年里反复碰到，几乎每个想给产品加"AI 生成界面"能力的团队，第一次技术评审都会卡在这里。

先说清楚这两条路线分别是什么。自由生成，指的是把用户的自然语言需求丢给大模型，模型直接产出可运行的界面代码或者界面描述结构，比如直接生成一段 JSX、一段 Vue 模板、一份 JSON 描述的组件树，甚至直接生成 HTML+CSS。配置模板渲染，指的是模型不碰具体代码，只负责把用户意图翻译成一份受约束的配置（比如"用表格组件、三列、带分页、字段是这些"），然后由一套预先写好的渲染器把这份配置变成真实界面。

这两条路线的差别，不是"哪个更先进"的问题，而是控制权和灵活度如何分配的问题。自由生成把控制权交给模型，换来的是理论上无限的表达能力；配置模板渲染把控制权留在工程侧，换来的是稳定、可预测、可维护。我在实际项目里两条路线都完整落地过，也踩过不少坑，所以这篇不打算给你一个"标准答案"，而是把选型时真正要看的几个维度拆开讲透，让你能根据自己的场景做判断。

这篇文章适合三类人看：一是正在做 AI 产品、需要决定 UI 生成方案的技术负责人；二是要动手实现这套东西的前端或全栈工程师；三是产品经理，想理解为什么"让 AI 直接画界面"听起来很美但落地时处处受限。不管你是哪一类，读完应该能对这两条路线的边界、成本、坑点有一个清醒的认识。

先给一个我自己的结论性判断，后面再展开论证：绝大多数面向生产的 AI 生成 UI 场景，配置模板渲染是更稳的默认选择；自由生成适合的是原型探索、一次性页面、以及你有足够工程能力去做后处理和校验的场景。但这个结论有前提，前提就是你的配置协议设计得够好。协议设计烂，配置模板渲染一样会变成灾难。

2. 自由生成路线的真实能力边界在哪里

2.1 模型直接产出界面代码，爽在哪里

自由生成最吸引人的地方，是它几乎没有表达上限。用户说"给我做一个深色主题、左侧固定导航、右侧卡片瀑布流、卡片带悬浮放大效果的页面"，模型可以直接给你一段能跑的代码。这种体验在 demo 阶段极其惊艳，我第一次跑通的时候也觉得"这就是未来"。

它的核心优势有三个。第一是冷启动快，你不需要预先定义任何组件库、任何配置协议，模型见过海量的前端代码，直接就能产出。第二是表达自由度高，用户想要一个从没见过的交互，模型可以现场编，不受你组件库的限制。第三是迭代直观，用户说"把按钮改成圆角、颜色换成品牌蓝"，模型直接改代码，所见即所得。

但这里有个关键认知：自由生成产出的"能跑"，和"能上生产"是两回事。demo 里跑通一段代码，和这段代码在真实项目里稳定运行、可维护、可测试、可回滚，中间隔着一整个工程体系。

2.2 为什么"能跑"和"能用"之间隔着一道墙

我拿一个真实案例说明。之前有个内部工具项目，我们让模型直接生成 React 组件代码。第一版效果很好，用户输入需求，模型吐出组件，前端动态编译渲染。但上线两周后问题集中爆发：

样式漂移：同一个"主按钮"，模型这次生成bg-blue-500，下次生成background: #3b82f6，再下次生成bg-[#2563eb]。视觉上看着差不多，但设计规范彻底失控，改一次品牌色要满项目搜。
依赖不可控：模型有时候会 import 一个项目里根本没装的库，或者用一个已经废弃的 API，运行时报错。
安全风险：模型生成的代码里偶尔会出现直接操作 DOM、内联事件处理器、甚至拼接字符串执行的情况，这在有用户输入的场景下是隐患。
无法测试：生成的代码每次都不一样，你没法写单元测试，回归测试无从谈起。
性能不可预测：模型可能生成一个没有做虚拟滚动的长列表，数据一多就卡死。

这些问题的根源是同一个：自由生成把"代码"当成了模型的输出，而代码是需要工程约束的东西。模型不懂你的设计系统、不懂你的依赖白名单、不懂你的性能预算，它只懂"生成看起来合理的代码"。

2.3 让自由生成可控的几种工程手段

那自由生成是不是就不能用？也不是。如果你确实需要它的灵活性，有几套工程手段可以把它拉回可控范围。

第一套是约束输出格式。不要让模型直接生成代码，而是让它生成一份受 schema 约束的 JSON，再由你的渲染器去渲染。等等，这不就变成配置模板渲染了吗？对，这就是两条路线的交界处——很多所谓的"自由生成"方案，本质上是在用自由生成的能力，产出配置模板渲染需要的配置。这个思路后面会详细讲。

第二套是代码后处理。模型生成代码后，过一遍 AST 解析，做几件事：把颜色值统一映射到设计 token、把 import 限制在白名单内、把危险 API 替换掉、把内联样式抽出来。这套东西工程量不小，但确实能把自由生成的产物规范化。我见过做得好的团队，会维护一个"代码规整器"，模型输出先过规整器再上屏。

第三套是沙箱执行。生成的代码在隔离环境里跑，限制它能访问的 API、能发起的网络请求、能操作的范围。这解决的是安全问题，但解决不了样式漂移和可维护性问题。

第四套是模板引导。给模型提供几个高质量示例（few-shot），让它模仿示例的风格和结构。这能显著提升一致性，但依然是概率性的，不能保证 100% 符合规范。

实测下来，这几套手段叠加使用，能把自由生成的可用性从"demo 级"提升到"内部工具级"，但要达到"面向 C 端用户的生产级"，成本会非常高。这也是为什么我前面说，生产场景默认应该考虑配置模板渲染。

3. 配置模板渲染为什么在生产环境更稳

3.1 把"生成"和"渲染"解耦的核心思路

配置模板渲染的核心思想一句话就能说清：模型只负责理解意图并输出配置，渲染器只负责把配置变成界面，两者通过一份协议解耦。

用户说"给我一个用户列表，显示姓名、邮箱、注册时间，能搜索，能分页"。模型不生成任何界面代码，只输出这样一份配置：

{ "type": "table", "props": { "searchable": true, "pagination": { "pageSize": 20 } }, "columns": [ { "field": "name", "label": "姓名", "sortable": true }, { "field": "email", "label": "邮箱" }, { "field": "createdAt", "label": "注册时间", "format": "date" } ] }

然后你的渲染器读到type: "table"，就去调你项目里那个已经打磨了半年的 Table 组件，把 columns 映射上去。整个过程模型碰不到一行真实代码，它只是在填一份表单。

这个解耦带来的好处是决定性的：

样式统一：所有界面都走同一套组件，设计规范天然一致，改品牌色只改一处。
可测试：渲染器是纯函数式的，配置进、界面出，单元测试好写。
可预测：模型输出的配置有 schema 校验，字段不对直接拒绝，不会出现"跑起来才发现问题"。
可维护：新增一种界面能力，只需要在渲染器里加一个组件映射，模型侧通过 prompt 或 schema 就能感知。
安全：模型输出的是数据不是代码，天然没有代码注入风险。

3.2 配置协议设计：这套方案真正的技术核心

配置模板渲染做得好不好，90% 取决于配置协议设计得好不好。协议设计烂，模型输出一堆它自己都理解不了的字段，渲染器天天报错，最后你会觉得"还不如让模型直接写代码"。

我总结了几条协议设计的实战原则。

原则一：协议要"模型友好"，不是"人类友好"。你给模型看的 schema，字段名要直白、枚举值要明确、嵌套层级要浅。比如align: "left" | "center" | "right"就比align: 0 | 1 | 2好得多，因为模型对语义化枚举的理解准确率远高于数字编码。我实测过，把数字枚举改成字符串枚举后，模型输出的字段错误率下降了大概四成。

原则二：组件粒度要适中。太细，模型要输出几十个字段才能描述一个表格，容易漏；太粗，一个type: "page"让模型自己编，等于没约束。我的经验是按"用户能感知到的功能单元"来切组件，比如表格、表单、卡片列表、详情页、图表，每个组件对应一类明确的业务场景。

原则三：留一个受控的逃生舱。再全的组件库也覆盖不了所有需求。协议里应该留一个type: "custom"或者type: "html"的口子，但要用白名单、沙箱、或者人工审核来兜底。完全不留口子，遇到特殊需求就卡死；口子开太大，又退化成自由生成。

原则四：版本化。协议一定会演进，今天没有的字段明天可能就要加。协议里带上version字段，渲染器按版本做兼容，模型 prompt 里也带上当前版本，避免新旧不匹配。

3.3 渲染器要做哪些"脏活"

很多人以为配置模板渲染就是写个 switch-case 把配置映射到组件，太天真了。真正生产级的渲染器，要处理一堆脏活：

字段校验与降级：模型输出的配置可能缺字段、类型不对、枚举值越界。渲染器不能直接崩，要有默认值和降级策略。比如pageSize缺失就默认 20，align非法就默认左对齐。
数据绑定：配置里描述的是"显示哪些字段"，但真实数据从哪来？渲染器要对接数据源，可能是 API、可能是本地状态、可能是模型同时生成的 mock 数据。
交互回传：用户点了搜索、翻了页、点了行，这些事件要回传给谁？渲染器要定义一套事件协议，把交互抽象成标准事件抛出去。
布局容器：单个组件好渲染，多个组件怎么排？要有布局容器组件（行、列、栅格、标签页），模型用这些容器组合出复杂页面。
错误边界：某个组件渲染失败，不能整个页面白屏，要有错误边界兜底。

这些脏活加起来，工作量往往比"让模型直接生成代码"大得多。但这是一次性的工程投入，投入完之后，每多支持一个场景，边际成本极低。而自由生成是每次都要处理不确定性，边际成本降不下来。

4. 选型决策：六个维度帮你判断该走哪条路

光讲原理不够，选型要落到具体判断上。我整理了六个维度，你可以对着自己的场景打分。

维度	自由生成更合适	配置模板渲染更合适
使用场景	原型探索、一次性页面、demo	生产系统、长期维护的产品
一致性要求	低，每次不一样也能接受	高，必须符合设计规范
组件复用	无所谓，每次新写	必须复用现有组件库
安全要求	内部使用、无敏感数据	面向用户、有数据安全要求
团队工程能力	强，能维护后处理和沙箱	中等即可，主要维护渲染器
需求可预测性	需求千变万化、无法枚举	需求集中在若干类业务场景

我拿几个真实场景套一下。

场景 A：给运营做活动落地页。运营要快速生成各种活动页，样式要好看、要能配。这种场景需求发散、生命周期短、对一致性要求不高，自由生成 + 后处理是合理的，甚至可以直接生成 HTML 让运营微调。

场景 B：企业内部管理系统。大量增删改查页面，结构高度相似，要复用现有组件库，要长期维护。这种场景配置模板渲染是压倒性优势，你甚至可以把常见的 CRUD 页面做成模板，模型只填字段。

场景 C：面向 C 端的 AI 应用，用户用自然语言生成自己的小工具界面。这种场景最纠结。用户需求发散（偏自由生成），但你又不能让他们生成的东西破坏你的应用、带来安全风险（偏配置模板）。我的建议是配置模板渲染为主，留一个受控的自定义组件口子，并且对自定义部分做严格沙箱。

场景 D：设计工具里的 AI 辅助生成。用户是设计师，要的是创意和多样性，生成的东西是给人看的不是给机器跑的。这种场景自由生成更合适，因为多样性本身就是价值。

一个实用的判断方法：问自己"如果模型这次生成的界面和上次风格不一致，我能接受吗？"能接受，自由生成的空间就大；不能接受，就往配置模板靠。

5. 混合路线：我实际项目里用得最多的方案

讲完两条纯路线，说点更实际的。我做过的大部分项目，最后都不是纯自由生成或纯配置模板，而是混合路线。混合的关键在于：用配置模板渲染做骨架，用自由生成做血肉。

具体怎么混？分三层。

第一层：页面结构用配置模板。页面的整体布局（导航、侧边栏、内容区、页头页脚）用配置描述，模型只决定"这个页面需要哪些区块、区块怎么排"。这一层强约束，保证整体框架一致。

第二层：区块内容用配置模板 + 有限自由。每个区块内部，优先用预置组件（表格、表单、卡片）。如果预置组件覆盖不了，允许模型生成一段受约束的配置，但配置的 schema 是固定的，只是组合方式自由。

第三层：特殊视觉用自由生成 + 沙箱。极少数需要特殊视觉效果的地方（比如一个自定义的数据可视化、一个动画），允许模型生成代码，但在 iframe 沙箱里跑，通过 postMessage 和主应用通信。

这套混合方案的好处是：80% 的界面走稳定路径，20% 的特殊需求走灵活路径，整体既可控又不失表达力。代价是架构复杂度上升，你需要同时维护配置渲染器和沙箱执行环境。

我在一个数据看板项目里用过这套方案。看板的整体布局、图表容器、筛选器全部走配置模板，只有图表本身的渲染配置（比如 ECharts 的 option）让模型自由生成。因为 ECharts 的 option 本身就是一份结构化配置，模型生成它既灵活又不会破坏页面结构。这个边界划得很舒服。

6. 落地时最容易踩的五个坑

不管选哪条路线，下面这几个坑我几乎每次都会遇到，提前说破能省你不少时间。

坑一：低估了 prompt 工程的量。很多人以为配置模板渲染就是"定义 schema + 写渲染器"，模型那边随便写个 prompt 就行。实际上，让模型稳定输出符合 schema 的配置，prompt 要反复打磨，要提供示例、要说明字段含义、要处理边界情况。我见过一个项目，渲染器两周写完，prompt 调了一个月还没稳定。

坑二：schema 设计得太理想化。设计 schema 的时候容易想"我要支持所有情况"，结果字段一大堆，模型记不住、输出错。正确做法是从最小可用 schema 开始，按真实需求迭代。先支持三种组件，跑通了再加。

坑三：忘了处理模型的"幻觉字段"。模型会输出 schema 里根本没有的字段，或者把字段名拼错。渲染器必须做严格校验，遇到未知字段要么忽略要么报错，不能默默吞掉。我建议在开发环境对未知字段直接抛错，逼着你去修 prompt。

坑四：没有做配置的持久化和版本管理。用户生成的界面配置要存下来，而且要能追溯"这个配置是哪次生成的、用的哪个版本的 schema"。不然出了问题没法复现，也没法做 A/B 测试。

坑五：忽略了流式渲染的体验。如果模型是流式输出配置的，你不能等全部输出完再渲染，那样用户要等很久。正确做法是边解析边渲染，配置流到一个组件就渲染一个组件。这需要你的配置格式支持流式解析，JSON 流式解析有现成的库，但要注意处理不完整的 JSON 片段。

提示：流式渲染配置时，一定要做"部分配置"的容错。比如一个表格配置只流出了一半，渲染器要能先渲染出已有的列，等后续列到了再补上，而不是等整个表格配置完整才渲染。

7. 一些关于模型选型和成本的实际观察

最后聊点工程之外但很实际的东西。两条路线对模型能力的要求不一样。

自由生成对模型的代码能力要求高。模型要懂前端框架、懂语法、懂最佳实践，这通常意味着要用能力较强的模型，成本也高。而且生成代码的 token 消耗远大于生成配置，因为代码本身就长。

配置模板渲染对模型的"理解 + 结构化输出"能力要求高，对代码能力要求低。模型只要能准确理解用户意图、并稳定输出符合 schema 的 JSON 就行。这意味着你可以用更小、更便宜的模型，甚至可以用经过微调的小模型。我实测过，一个配置模板渲染的场景，用中等能力的模型配合好的 prompt，效果和用顶级模型差别不大，但成本能降一个数量级。

还有一个容易被忽略的点：配置模板渲染的延迟更低。因为输出的是配置不是代码，token 数少，生成快，首屏时间短。对于交互式产品，这个体验差异很明显。

至于模型输出的稳定性，我的经验是：配置模板渲染的稳定性天然高于自由生成，因为输出空间被 schema 约束了。但前提是你的 schema 校验足够严格，并且对模型的输出做了重试和降级。我一般会做两层保险：schema 校验失败就重试一次，重试还失败就降级到一个默认配置，保证用户至少能看到东西。

关于成本，还有个细节：配置模板渲染因为输出短，同样的预算能支撑更多的生成次数，这对高频使用的产品很关键。自由生成如果每次都要生成几百行代码，成本会很快失控。