最近半年群里聊AI做UI的频率明显降下来了不是说不做了而是没人再拿着一张大模型通用对话去生成整页界面了。以前大家喜欢把需求一长串丢给在线大模型让它直接“写一个后台页面”现在更多强调的是单独为UI这件事训练一个小模型几B参数不接云只生成界面结构和组件能私有化能秒回还能绑定自己的设计系统。这篇文章就从“UI专用小模型”这条新路子展开。适合正在做前端基建、低代码平台、智能设计工具或者内部效率工具的团队参考也适合想搞清楚小模型能在界面生成里干什么的AI应用开发。下面我会把为什么需要它、训练数据怎么搞、如何部署到本地以及实际跑起来遇到的各种坑一次讲清楚。1. 为什么UI生成要单独训一个小模型1.1 一锅烩的通用模型做UI时真的很别扭先聊最直观的感受。通用大模型确实能写HTML、写Vue组件甚至能照着截图描述生成一版视觉稿但真正放在产品里用问题一个比一个明显。第一是慢。你让它生成一个完整的管理后台页面它要先编一大段HTML再补CSS有时还要拆几个组件文件生成时间几十秒不算夸张。交互式对话场景里用户改一个按钮文案都要等十几秒这个体验基本没法用。第二是贵。一个后台页面动辄上千token生成十几次创造一个原型成本立刻上来了。第三是隐私和合规。很多公司的设计规范、业务字段、内部系统页面根本不适合传到云端模型里尤其政务、金融、医疗这类场景数据出内网这件事就是红线。还有一个更隐蔽的问题是“风格漂移”。同一个通用模型今天生成的是带Tailwind类名的页面明天生成的是内联样式后天可能给你造一堆不存在的组件名。它对“你们公司的设计系统”没有任何记忆你必须在每一条提示词里反复描述一遍哪怕描述得很仔细输出也还是不可控。我在实际中见过最夸张的情况是同一个输入提示跑了三次三个版本的类名、间距、颜色体系都不一样拿去做验收的人都快崩溃了。所以痛点不是“能不能生成”而是“能不能稳定地、便宜地、可私有化地生成一套符合既有设计规范的UI”。1.2 小模型的机会恰恰来自“任务被收窄”很多人一听“小模型”就以为是砍参数、降能力。其实做垂直场景模型我最看重的一点是能不能把任务边界收窄。UI生成和通用的“聊天”“写文章”是完全不一样的活。界面这件事本质上是一个封闭集合的问题。你项目的组件库是有限的设计规范是有限的页面类型也是有限的。哪怕是B端产品翻来覆去也就是表单页、列表页、详情页、看板页、弹窗、抽屉。这些页面里的模块就那些表格、筛选器、统计卡片、步骤条、标签页。一旦任务边界收窄小模型就能用有限的参数把规律背下来。比如一个3B的模型它不需要知道怎么聊历史、怎么写菜谱它只需要记住“按钮组件叫什么名字”“表单字段有哪些类型”“页面布局怎么排”这完全可以做到。实际跑下来3B量级的底座模型在生成中后台页面结构时准确率并不比几十B的通用模型差很多时候因为专门微调过反而更贴近团队规范。更重要的是小模型可以本地部署。本地部署意味着数据不出内网、没有按token计费的后顾之忧、延迟可控甚至可以做成离线工具。私有的设计系统可以完整塞进去不用在提示词里偷偷摸摸地“描述一个类似Element Plus的表单样式”。模型就是你的设计系统本身。1.3 “UI专用”不等于“从零训练”再澄清一个误区UI专用小模型不需要从零预训练。哪怕你手里的数据量只有几千条也足够用LoRA方式去微调一个开源底座模型。为什么能这么轻量因为底座模型已经具备了语言理解和代码生成的基础能力我们只做“收口”这一步教它在固定格式下输出固定结构。正因为有了这个前提整个项目投入是可以控制的不需要买一堆显卡不需要攒几百万条数据。我这边实践下来一份清洗得还不错的几千条样本配合QLoRA在一块消费级显卡上十来分钟就能看到明显效果。如果是纯CPU训练时间会比较难熬但也不是不能做。总的原则就是把“训练”这件事从玄学变成工程流水线。2. 小模型生成UI的技术底座2.1 选底座模型参数不是越大越好做UI专用模型底座模型的选择没有想象中那么多讲究。我试过的组合里3B到4B量级的模型最合适。再大的模型量化后体积太胖部署麻烦而且在这个封闭任务里未必有质的提升再小的模型比如1B以下文法能力会明显下降输出容易碎。可以考虑的底座有这么几类底座型号参数量量化后体积实际体验Qwen2.5-3B-Instruct3B约2GBQ4中文理解好结构化输出稳定Llama 3.2-3B3B约2GBQ4英文物料强中文需要额外训练Phi-3-mini3.8B约2.5GBQ4代码能力强中文略弱Gemma-2 2B2B约1.5GBQ4轻量适合嵌入式端探索做中文业务系统我首选Qwen系列因为它对中文自然语言的理解更稳能少踩一些“语义偏掉”的坑。底座确定后不要改它的对话模板除非你非常清楚自己在做什么否则后续接各种推理框架时会踩模板不匹配的坑。2.2 输出格式比模型本身更重要很多新手做AI生成UI上来就让模型直接输出HTML代码。这样做不是不行但会让小模型的难度陡增。一份完整的HTML里既有结构又有样式又有内联事件变量多小模型学起来费劲还特别容易出现标签不闭合、类名乱写的问题。我建议先定义一套简化的UI DSL也就是让模型生成一种介于自然语言和目标代码之间的结构化描述。这里我把自己常用的一套JSON DSL简化一下展示出来{ type: Page, name: 订单管理, layout: vertical, children: [ { type: StatisticRow, items: [订单总数, 今日新增, 待发货, 退款中] }, { type: Form, columns: 3, items: [ { label: 订单号, component: Input, placeholder: 请输入订单号 }, { label: 状态, component: Select, options: [待付款, 已付款, 已发货] } ] }, { type: Table, columns: [订单号, 客户, 金额, 状态, 创建时间], rowActions: [查看, 编辑] } ] }这个JSON其实就是“界面骨架”模型只需要学会做两件事根据用户描述决定页面里有哪些块给每个块配置合适的组件和属性。然后交给一个固定的渲染器把JSON翻译成Vue、React甚至是低代码平台的DSL。好处非常明显组件的候选集来自你定义的白名单模型没法凭空造出不存在的组件样式细节从DSL里剥离掉模型不用去操心那些它处理不好的像素级问题结构JSON的合法性强方便做schema校验错了能直接反馈重新生成。表面上看多了一层转换实际模型变好训了下游代码也更可控了。2.3 训练数据真实页面就是最好的教材训练数据是做小模型最重要的一环。我的经验是别迷信“用大模型合成几万条数据”高级B端UI最实用的训练数据其实就在你自己的仓库里就是你团队已经做出来的页面。我把收集数据的思路拆成三种真实页面代码反解。从现有项目里抓Vue或React组件代码通过AST解析还原成DSL结构。这个过程半自动需要处理组件嵌套和路由页面但数据质量最高。低代码平台导出。如果你公司有低代码平台那更省事后台页面本身就是配置化的把配置导出成我们的DSL格式就行还天然干净。大模型辅助重建。拿一些历史需求文档或截图描述让大模型先生成一版人工修正成标准DSL后回收。这个适合补冷门页面的样本量。文案数据也是很重要的一块。同一个表格用户可能说“展示订单列表”也可能说“一个表格里面放订单信息”训练时要把这些不同说法都映射到同一个DSL上。这就需要做数据增强把DSL逆推回自然语言描述换个说法生成多份再组成训练对。我这里实际项目里采用了约8000条“自然语言DSL”的训练对其中真实页面反解占了六成低代码导出占两成剩下是大模型辅助修正的。数据质量是质变的关键宁可少、也要干净脏数据会让模型输出乱得你想哭。2.4 微调和偏好对齐数据准备好以后微调这一步其实没什么神秘感。直接用指令微调SFT做一轮让模型学会在用户描述后输出对应的DSL。之后再根据需求决定要不要做DPO对齐。SFT阶段要特别注意不要把所有训练样本都写在同一个system提示里要模拟真实调用时的上下文。例如系统提示固定一句话“你是UI生成模型只输出JSON”用户输入里再带上场景、屏幕尺寸、风格偏好。这样模型上线后遇到真实请求不会不知所措。DPO对齐这里多说一句。SFT学的是“照猫画虎”DPO学的是“哪个输出更好哪个更差”。我从SFT生成的样本里挑一些“看着合理但其实很烂”的输出和人工修正后的正确输出配对做偏好对齐。这个过程能让模型少干一些“模型自嗨”的事比如生成一堆不存在的组件名、把按钮塞进表格列头这类离谱行为。3. 实操记录从数据到可调用的本地UI生成服务3.1 构造第一版训练集先别贪多我的做法是先搭一个最小但完整的训练集跑通全流程。你可以拿30个页面每个页面拆出5种不同的用户说法比如“订单管理”“订单列表”“查看订单”“订单查询页”“后台订单页面”再配上对应的DSL大概150条数据就够了。对于没接触过这类训练的人我建议把这150条数据保存成JSONL格式每行一条样本包含三个字段{ instruction: 生成一个订单管理页面顶部4个统计卡片下方一个搜索表单和订单表格, input: , output: { \type\: \Page\, ... } }把instruction写成用户会说的话output写成标准DSL字符串。这里最好用真实需求里收集过来的话术而不是自己拍脑袋写一堆“请帮我生成一个…”的翻译腔。真实话术往往很口语化比如“搞一个统计展示栏下面跟表格”模型见多了才能扛住线上用户的奇怪问法。3.2 用QLoRA微调一个3B的UI模型拿到第一批数据后我通常直接选用QLoRA做参数高效微调。省显存而且对这个封闭任务来说效果足够好。核心代码大概是下面这个套路from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from datasets import load_dataset import torch model_name Qwen/Qwen2.5-3B-Instruct model AutoModelForCausalLM.from_pretrained( model_name, load_in_4bitTrue, torch_dtypetorch.bfloat16, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(model_name) tokenizer.pad_token tokenizer.eos_token lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model prepare_model_for_kbit_training(model) model get_peft_model(model, lora_config)训练参数方面我比较保守地使用学习率2e-4batch size 8跑3到5个epoch。数据量小第5个epoch开始就容易过拟合表现为训练loss很低但生成时只会背诵训练集里的输出。所以我的建议是先跑到3个epoch拿测试集看一眼如果输出还是乱的再往上加。这里有个容易被忽略的点max_seq_length不要设太低。生成一个完整的页面DSL可能超过1000token如果训练的截断长度只有512模型永远学不会长页面怎么收尾。我一般设成2048少于这个会出现“开头正常、后半截乱跳”的怪毛病。3.3 量化压缩与本地推理微调完的模型还在HuggingFace和Peft的架子路上直接业务调用太重。要往本地部署走最省事的是转成GGUF格式再用llama.cpp或者它周边生态跑。大概的转换流程是这样的先把LoRA权重合并回基础模型导出成一个完整的HF格式权重目录然后用llama.cpp提供的convert脚本把模型转成FP16版本的GGUF再拿llama-quantize压到Q4_K_M文件体积能缩到2GB上下。这一步做完模型就变成单文件了随便拷到哪台机器都能跑。启动推理时我一般用llama-server或者自建HTTP服务关键参数要小心上下文长度设为2048因为DSL输出比较长设短了会截断温度调到0.2甚至更低。很多人忽略温度这回事默认0.8去生成JSON结果就是结构经常发散。偏结构生成任务温度尽量低最好是不采样或只做top-k小范围采样。3.4 作为服务接入业务模型部署好以后直接给业务方一个HTTP接口就行。调用链路大概是前端把用户自然语言描述和页面上下文打包成一个POST请求后端组装提示词模板调用模型推理接口拿到模型输出后做JSON解析和schema校验校验不通过就抛回给前端提示“正在重新生成”或走一次简单的规则后处理通过校验的DSL交给渲染器直接渲染出页面预览。这个链路里最值得下功夫的是第4步的后处理。模型输出偶尔会出现组件名错误、层级嵌套不对、字段丢失之类的毛病。专门写一个校验器比反复调prompt更有效。别把希望全压在模型上小模型加规则兜底稳定性才能真正让人放心。4. 不同场景下的落地形态4.1 中后台表单页面小模型最容易出成绩的地方真要说哪类界面最值得先用小模型我首选中后台表单页、列表页、数据看板。原因很简单这类页面结构化程度极高组件都是现成的字段就是业务的字段模型学起来最轻松出活也最稳定。你有没有发现B端页面的规矩多但翻来覆去就那样顶部操作栏中间筛选条件下面是表格右侧或底部是分页和按钮。这些结构如果靠人工去拼熟练前端也要二三十分钟交给小模型一秒多就能拿到JSON骨架再人工微调一下字段顺序和默认值效率提升非常明显。低代码平台和表单配置工具是更合适的落地对象。把AI生成的DSL转成平台的配置协议用户在页面上还能继续拖拽改用户感知是“AI帮我搭了初版”但背后其实只是一个小模型加DSL转换器。这个方案不需要大模型API自己维护一套本地服务就能稳定跑非常划算。4.2 营销页和大屏可视化只能做“结构生成器”营销首页这类视觉创意要求很高的页面小模型就显露出短板了。它的知识库和审美上限摆在那里让它给你配一套高级质感的视觉样式难度很高。但也不是完全不能用把它当成“结构生成器”就很合适让模型根据文案脑暴出页面结构比如头图区、卖点区、案例区、客诉区怎么排然后在空白结构上让设计师填充视觉创意。人负责审美模型负责穷举结构。大屏可视化也有类似逻辑。大屏页面本质是网格布局里的图表拼盘不是每家公司的图表种类都很多。提前把图表组件和布局方式固化在DSL里让模型根据“网络延迟指标、CPU使用率、近一小时趋势”这样的输入自动匹配哪块放折线图、哪块放数字卡片准确率相当可观。4.3 移动端和嵌入式UI模型变小后新场景开始被解锁小模型变小的最直接受益者是端侧场景。之前大模型没法塞进移动App或者嵌入式工具链里现在3B量化后2GB左右很多主机端甚至边缘设备都能考虑了。像采用ESP32-P4这类芯片的产品如果设备端本身没有跑大模型的余量可以把小模型放在配套的桌面工具里输入一句产品需求直接生成LVGL或者自定义控件需要的界面描述代码再交叉编译到设备上。这件事最大的意义是让“UI模板生成”不再依赖网络。产品经理在现场给客户演示时本地笔记本上就有一个小模型说了一句“我需要一个充电桩状态显示页”几秒钟就出来一版结构该有的状态、数据、告警区域都在直接拿着去做方案沟通比临时拖拽设计快得多。对嵌入式、单片机这类开发周期紧的场景这种用法是实打实的加分项。4.4 AI Agent里的UI暴露问题另一种“小模型”形态最近挺多人聊移动端AI Agent的UI控制能力相关技术里有一个核心矛盾是Agent如果看到的界面信息太完整既浪费token又容易让决策漂移如果UI信息暴露太少又会变成瞎子不知道哪个按钮在哪。于是有些团队在探索“减少UI暴露”的方案想办法只给Agent提取关键的操作点。这里就蹦出另一个形态的“UI小模型”专门负责从屏幕截图或UI层级里提取结构化操作点比如“这是一个确认弹窗”“主要按钮在右下角”。它不负责生成完整页面负责生成页面里的“交互线索”。这正是小模型可以大展拳脚的地方任务极其单一输出结构固定对上下文要求很小本地端侧跑完全可行。未来UI生成和UI理解这两个方向会各自沉淀出不同的小模型供不同Agent组件调用。5. 实测过程中的踩坑笔记5.1 模型记不住设计系统遇到最多的问题是微调后模型还是偶尔“失忆”把Button写成Botton、把Table写成TableList或者突然冒出一个组件库根本不存在的组件。后来我用了三个手段叠加解决一是把组件名列表放进系统提示词并且要求模型“只能从候选里选”二是在DSL的schema校验里直接做组件名白名单过滤一旦出现非法组件名就自动替换成最相近的合法组件三是准备一份极少量、只有几个例子的few-shot让模型在固定格式里照着回答。到这里组件名乱造的问题基本被压住。5.2 JSON输出不稳定小模型生成带引号的JSON结构时偶尔会在嵌套大括号或转义引号上翻车。最常见的错误是少一个花括号、字段值带着多余逗号或者把JSON包在Markdown代码块里。我的解决方案是配合推理框架做的语法约束采样。open-source推理里有不少支持GBNF语法约束的方案直接把JSON Schema改成语法规则强制模型每一步采样都按合法token来走。实测效果立竿见影合法率能提高好几成。如果不想引入这么重的依赖至少在后处理时做一次容错解析比如自动补全缺失的右括号但正确率就不如约束采样来得稳。5.3 生成的UI布局“没有灵魂”模型生成的页面结构经常是“所有东西从上往下堆”看起来没什么问题但特别呆板。后来我在数据里人工加了一部分“双栏布局”“侧边栏内容区”的例子并显式在DSL里增加layout字段让模型意识到页面不是一条平铺的流水账。另一个好用的技巧是拆分生成流程第一遍只生成页面宏观布局第二遍再往每个区块里填充细节字段。这可以避免模型在生成长页面时“顾前不顾后”前半段还在正轨后半段就开始自由发挥。分步做虽然多一次请求但质量提升非常明显。5.4 速度、并发与量化取舍本地小模型速度再好也比不上云端集群。我实测3B量化模型在一颗普通桌面级CPU上生成一个1000token的页面DSL大概需要5到8秒如果机器里有显卡能压缩到2秒内。看起来很慢但考虑到它是本地部署的“离线生成器”不做高频并发这个延迟是可接受的。如果要做成公共后台服务就得考虑并发瓶颈。量化和推理进程会抢CPU我的经验是一个物理机最好只放一个模型实例其余服务放另一个节点。如果必须高并发就上多副本加排队比在一个进程里堆并发要可靠得多。5.5 评估不能只看“能不能跑通”最后也是最重要的一定要做自动化评估而不是每个生成结果都拿肉眼看。我把评估拆成了四层语义匹配模型是否识别出用户提到的关键业务字段比如“订单号”“金额”有没有出现在DSL里。结构合法性JSON能否被正确解析组件白名单是否通过。类型正确性Input、Table、Select这些组件是否用对了场景。布局合理性页面是否存在空的区块或者没有内容的大块白屏。跑完自动评估以后再抽一二十条让人工打标。人工主要看宏观体验自动主要拦截低级错误。这个机制上线后我迭代训练数据的速度大幅加快每次发现一批坏case就把它们修进训练集里模型质量是滚着往上走的。我自己的体会是UI生成这件事真正的门槛不在于模型本身而是你愿不愿意把组件、布局、验收规则抽成一套结构化的标准。只要这个标准立住了小模型的训练、部署、迭代都会顺很多远程背景下的碎片时间也够维护一个不错的私有模型。最后分享一个小技巧先让模型输出一份简化版的UI大纲再展开成完整DSL这一步能大幅减少结构崩塌的发生概率。如果你也在做类似的工具我建议可以优先拿到真实页面数据马上开始第一轮微调效果出来了再考虑要不要继续堆数据不迟。