“拼 UI”这三个字干过前端和客户端的人一看就懂——设计稿里一个按钮要调位置、调颜色、调圆角、调阴影、调悬浮态、调点击态来来回回折腾半小时最后发现字号差了 1px 没对齐。自从我开始把 AI 拉进这个流程最直观的感受是我终于不用再亲手“拼”每一块界面了而是把精力挪到了提需求、审细节、定调性这些更像人干的事上。这篇文章不聊那些玄乎的大模型原理就聊聊我在这段时间里用 AI 重做 UI 相关工作的真实方法、踩过的坑以及哪些事目前还得自己下场。我不是让大家把整个界面丢给 AI 然后什么都不管那是我试过之后最早放弃的思路。我更推荐的方式是把 UI 工作拆成“意图描述—AI 生成草稿—人工审查修正—人工联调”四个环节AI 负责从零到 60 分人负责从 60 分到 90 分。这个思路适用于 Web 页面、Unity 游戏界面、Android 客户端也适用于后台管理系统那种又碎又多的表格和表单页面。下面我把每一步的实操细节、提示词模板和翻车经历都写出来包括一个已经跑通的 Vue 后台页面案例、一个 Unity 数字滚轮控件的实现过程还有一个老项目里 EasyUI DataGrid 悬停提示文字的需求——这些恰好都是我这段时间被问得最多的几个场景。1. 手拼 UI 的苦其实都藏在看不见的工时里先说清楚我一直说的“拼 UI”到底指什么。很多人以为它只是照着设计稿写代码但实际上它是由一堆琐碎且高频的体力活组成的调整控件尺寸和间距、适配不同屏幕、处理文字过长截断、给表格加排序和悬停、给按钮补齐 disabled、loading、empty 状态以及最折磨人的——设计稿改了之后联动修改十几个文件。这些事没有多高的技术门槛却极其消耗精力而且它们不会写进任何需求文档里属于典型的“隐形工时”。我举个特别具体的例子。前阵子做一个管理后台的列表页设计稿里按钮组是“编辑、删除、导出”三个按钮并排。看起来特别简单对吧实际写起来你会发现编辑按钮得按照权限控制显隐删除按钮要弹出二次确认框导出按钮在导出过程中要变成 loading 态三个按钮的对齐方式行内 flex 还是 inline-block 在不同浏览器里表现还不一样。等你把这些全部处理完半天过去了。这种页面没有任何可炫耀的技术含量但它就是占用了大量开发时间。还有一类痛点是状态缺失。设计稿永远只画“正常情况”下的界面空状态、加载状态、错误状态、超长文本状态基本都不在图上。我以前做项目最怕的不是写复杂逻辑而是把这些状态一个个补全——每补一个状态就要重新看一遍布局会不会被撑破、文案是否合理、颜色是否协调。这些事情做得多了人会变得特别机械精力被切碎真正值得思考的交互逻辑反而没时间想。那 AI 为什么在这件事上特别有用因为“拼 UI”的本质是把一个已经存在的意图翻译成一组确定性的代码结构。意图描述越清楚AI 输出的初始版本就越接近可用状态。它不需要你告诉它所有细节只要给它一个角色设定、一组约束条件和一段需求描述它就能生成一版比大多数人手写第一版要完整得多的页面。这种能力不是替代了思考而是把我们从“从空白页开始”的恐惧里解放了出来先有了一个能跑的东西剩下的事情就变成修改而不是创造效率和心态都完全不一样。我也必须说句公道话AI 生成的初版并不能直接上线。我见过太多人让 AI 生成了一个漂亮页面兴高采烈地发群里展示结果一接入真实数据就各种错位。真正的价值在于以前从 0 到 60 分需要一整天现在只需要十分钟省下来的时间正好用来做后面从 60 分到 90 分的打磨而这个打磨过程才是人和 AI 之间的本质差异所在。2. 我把 UI 工作拆成四个环节AI 做前三段我做最后一段最开始我是把整个界面需求一次性丢给 ChatGPT让它直接输出一个完整页面。结果很稳定地翻车界面生成了但是用的是我不知道的组件库逻辑写了但是没有考虑接口数据结构样式确实好看但和我团队现有设计规范完全不是一套体系。后来我调整了工作方式把 UI 产出过程拆成四段每一段都由不同的人和工具配合完成这个流程我一直在用。四个环节分别是视觉草案生成、组件级代码生成、页面级组装与布局调整、最终人工验收与数据联调。第一个环节主要解决“长什么样”的问题我用 AI 绘图工具生成设计感预览图帮助对齐需求方的审美预期第二个环节解决“某个组件怎么写”的问题让 AI 生产单个按钮、表单、弹层、表格之类的局部代码第三个环节是核心我会给 AI 一个完整的页面描述包括技术栈、组件库规范、布局方式和伪数据让它组装出整页最后一个环节必须由人来完成因为只有人才知道真实的接口返回结构、权限模型和业务规则。这里面的关键逻辑是AI 最擅长的是“从自然语言到代码”的映射它了解 Vue、React、Unity、安卓等框架的常见写法和最佳实践覆盖面比你我都广。但它不了解你的具体项目——不知道你的按钮权限变量名是什么、不知道表格数据来自哪个接口、不知道设计规范里主色调的具体色值。所以我的做法是前三段 AI 负责用它的通用经验快速产出初稿到了第四段我把它的输出当作“一个水平不错的同事写的代码”逐行 review 后修改成符合项目架构的样子。这个拆法还有一个额外的好处它让我的项目有了一种标准化的 AI 协作接口。团队里不管是新来的实习生还是资深前端拿到同一个提示词模板生成的页面初始质量都差不多。以前新人写页面光是一个表格组件就能琢磨半天现在让 AI 给你一个 80 分的底子新人只需要沿着项目规范修正就行上手速度快了不是一星半点。我后面会给出一套我自己在用的提示词模板基本上覆盖了 web 页面的常见需求。需要强调的是这四个环节不是割裂的。视觉草案生成阶段虽然用的是绘图工具但它输出后的风格描述可以直接粘贴到代码生成环节的提示词里比如“浅色背景、蓝色主色调、卡片式布局、圆角偏小、留白充足”这样 AI 生成的代码风格和预览图会非常接近。这条通路我试过很多次比直接让大模型“看着好看就行”靠谱得多。3. Web 端实操用一段描述生成可用后台页面行得通我拿最近一个真实项目举例做一个订单管理后台页面。按照传统做法要先看设计稿、核对组件库、写表格、写搜索区、写分页、写状态标签预计得花一天。而我的实际耗时大概是三小时左右其中前 20 分钟是让 AI 生成初版后面大部分时间都在做审查修正和接口对接。我给 AI 的提示词原文大概是这个风格根据项目脱敏后的精简版本你是一个资深 Vue3 前端开发工程师使用 Element Plus 组件库。现在需要生成一个订单管理页页面结构包括顶部搜索区订单号、下单时间范围、订单状态三个筛选条件、操作按钮区导出按钮、订单表格列包含订单号、商品信息、金额、订单状态、下单时间、操作、分页器。订单状态需要用 el-tag 显示不同颜色导出按钮点击后模拟导出 loading。表格用 el-table数据用本地 mock 数组字段和真实接口保持一致orderId、productName、amount、status、createdAt。布局要求搜索区和按钮区放在同一行表格下方分页器右对齐。视觉风格浅灰背景、白色卡片圆角 8px、主色 #409EFF代码必须可直接运行并将 mock 数据单独放一个数组。这算是我实测下来很稳的提示词结构。它包含六个要素角色设定、技术栈与组件库、页面结构、数据字段与 Mock 方式、布局与视觉细节、可运行性要求。任何一个要素缺失输出质量都会明显下降。比如不提组件库它可能会给你写一堆自定义样式后期维护成本直线上升我就是因为这个返工过两次。初版生成之后有两个常见问题。第一个是布局问题搜索区内容太长时按钮被挤到下一行表格在窄屏下会出现横向挤出。处理办法是加明确约束比如“搜索区在 1440px 宽度下必须和按钮保持同行超出部分自动换行”。第二个是逻辑问题AI 给导出按钮写的只是 alert不是真正的 loading 状态切换。这块我会在下一次对话里单独要求它修正“导出按钮点击后设置 loading 为 true模拟 2 秒后置 false”。像这种小迭代一般两三轮就能把页面打磨到可用的程度。下面贴一段当时 AI 生成然后我修正后的核心代码不是完整页面只展示表格列和状态标签的处理思路template div classorder-page div classtoolbar el-input v-modelquery.orderId placeholder订单号 clearable / el-date-picker v-modelquery.dateRange typedatetimerange / el-select v-modelquery.status el-option label全部 value / el-option label待支付 valuepending / el-option label已支付 valuepaid / /el-select el-button typeprimary clickfetchList查询/el-button el-button :loadingexporting clickhandleExport导出/el-button /div el-table :datalist el-table-column proporderId label订单号 width180 fixedleft / el-table-column label订单状态 width120 template #default{ row } el-tag :typestatusMap[row.status].type {{ statusMap[row.status].text }} /el-tag /template /el-table-column el-table-column propcreatedAt label下单时间 width180 / /el-table /div /template这段代码看起来简单背后其实有个值得注意的坑。用户名的订单状态标签不能只写三种实际业务里可能还有“已取消”“已退款”“已关闭”等状态AI 初版不会主动列出所有状态。我建议在提示词里直接写全“订单状态包含 pending、paid、cancelled、refunded、closed其中 pending 显示 warning 类型paid 显示 successcancelled 显示 inforefunded 显示 dangerclosed 显示 info”。这样比自己生成后再补全要快得多。Web 端实操的经验就是这样提示词越具体输出越接近项目要求。但也要记住AI 生成的表格列可能没有考虑到固定列、溢出省略、空数据占位这些边界场景这部分只能靠人工 review 补上一轮。我通常的做法是生成之后先跑一遍然后用浏览器开发者工具模拟不同尺寸窗口逐个修复。4. 游戏和移动端的 UIAI 同样能帮你省大力气Web 页面之外Unity 客户端和 Android 端的 UI 工作也大量属于“拼”的范畴。最近我刚好用 AI 实现了一个 Unity 里的 UI 数字滚轮效果类似 iOS 的 picker整个过程中 AI 起到了很大作用尤其是生成核心计算逻辑和动画参数这一步。拆解一下这个需求本身界面上有一列可滚动的数字滚动停止后自动吸附到最近的一个数字上并高亮中间位置的选项。实现的基本组件就是 ScrollRect 一个垂直的 Content 列表每个数字是一个 Item再加上遮罩和中心选中线。工作量主要在三块动态生成规定范围内所有数字并排版、监听滚动结束事件计算目标索引并执行回弹动画、滚动过程中控制每个 Item 的缩放和透明度形成 3D 效果。这三块逻辑如果我纯手写至少需要半天还要调试各种边界情况。我给 AI 的提示词是“用 C# 为 Unity 编写一个 UI 数字滚轮组件基于 ScrollRect 实现支持设置 minValue、maxValue、defaultValue滚动停止后自动吸附居中使用 DoTween 做缓动Duration 为 0.3 秒Ease 用 OutQuad每个数字 Item 在滚动时根据距离中心的偏移量进行缩放和透明变化缩放区间 0.6 到 1.0透明区间 0.4 到 1.0”。AI 生成的脚本基础结构完全可用我再根据项目实际命名空间和 UI 层级做了一些调整。这里我要特别说一个经验Unity 的 UI 效果往往不是单靠逻辑就能实现的Curved UI 那种弧形菜单、曲面按钮效果更是如此。如果你在项目里用了 Curved UI 插件想让滚轮效果沿着弧面排布直接在提示词里加上一句“需要在 CurvedUI 场景下运行参考 CurvedUI 的 Raycaster 和 CurvedUISettings 坐标转换思路”。AI 会给你一个处理顶点位置偏移的思路甚至能生成一个基础脚本把平面 ScrollRect 的 Content 坐标转换成弧形坐标。虽然这个脚本大概率无法直接跑但 AI 相当于帮你查了一遍文档给出了具体的计算方向你自己实现起来就有明确路线了。Android 端这边同样可以用自然语言生成布局代码。最典型的场景是你需要写一个包含多个常用 UI 控件的设置页直接用 Android Studio 手写 XML 很繁琐尤其是 RelativeLayout 嵌套 LinearLayout 的时候。现在我会先告诉 AI“用 Kotlin Compose 实现一个设置页面包含顶部返回栏、用户头像区域、分组列表账号与安全、消息通知、通用设置、关于我们”。它生成出来就是一套完整的 Compose 代码我再把真实的点击事件、页面跳转和状态管理接上即可。移动端和游戏端的另一个大坑是 UI 的回收复用和内存占用AI 不太会主动帮你考虑。比如 Unity 里如果数字滚轮的 Item 很多用 ScrollRect 直接生成几百个对象会明显掉帧正确做法是数据复用或者只实例化可视区附近的几个 Item。我让 AI 生成初版后会专门加一次对话要求它补充“滚轮范围内数字较大例如 1 到 9999必须实现对象池或者只生成可视范围内 Item 的方案”。这个问题如果你不主动提AI 初版通常是直接循环实例化所以人工 review 一定要盯住性能相关代码。5. 表格和交互细节老项目里的零碎需求才是 AI 的主场比起一次性的整页生成我反而觉得 AI 在“表格和交互细节”这件事上价值更大因为这些需求特别琐碎又特别高频。举一个我在老项目里遇到过的例子项目用的是 EasyUI 的 DataGrid需求是鼠标移到表格标题上时显示提示文字并且提示内容要根据列从后台配置读取。这种需求如果自己手写流程是找到列定义位置、给 th 加 title 属性、再额外绑定 mouseenter 和 mouseleave 事件做自定义悬浮层、最后把后台配置的 metadata 映射到对应列上。逻辑不复杂但很枯燥而且涉及老框架的 API 时经常要翻文档。我用 AI 辅助处理分三步走。第一步让 AI 生成 DataGrid 列定义时的 formatter 思路在列头渲染时读取 metadata 描述作为 title。第二步生成一个通用的鼠标悬停事件绑定函数处理 tooltip 的显示位置避免超出屏幕边界。第三步把数据字典的映射关系表给 AI让它生成按列名 lookup 的辅助函数。最后我只需要把生成的函数接入现有页面的 onLoadSuccess 事件里即可。这里贴一段伪代码示例展示 AI 生成的悬停提示思路在 EasyUI DataGrid 里怎么落地table iddg classeasyui-datagrid stylewidth:100%;height:260px >