刚入行那几年我最怕听到的一句话不是需求又变了而是这个页面你帮我拼一下。拼 UI这三个字听起来轻巧做起来是把一个设计稿翻译成成百上千行 HTML/CSS再对着像素调间距、改圆角、补状态、适配屏幕。自从我把这部分工作交给 AI 之后过去那种挪一个按钮要连带改三处布局的日子算是彻底翻篇了。这篇文章就聊聊我用 AI 替代手工拼 UI 的真实过程包括工具选型、工作流设计、提示词写法还有一路上踩过的坑。不管你是前端开发、全栈工程师还是 UI 方向的设计师只要还在跟界面打交道这期内容应该能给你省下不少时间。1. 拼 UI到底拼的是什么1.1 那些年被 UI 支配的日子先回忆一下没有 AI 的时候一个普通后台管理页面的开发流程是什么样的。设计师丢过来一张 Figma 效果图上面是一个列表页左侧有侧边栏顶部是搜索区中间是数据表格右下角有分页按钮。光是把这张图翻译成结构化的前端代码就够忙活一上午。首先要拆分布局想清楚是 Flex 还是 Grid哪块是固定宽度、哪块要自适应然后要给每个元素起类名命名规范还得跟团队保持一致接着写 CSS挨个调 padding、margin、font-size最后还要处理 border-radius、box-shadow、hover 状态这些细节。一个同事在旁边笑着说这不就是体力活嘛。 确实拼 UI 在技术上没什么难度但它极其消耗精力而且特别容易让人进入一种面无表情地重复劳动的状态。更磨人的是改稿。设计师看完第一版说搜索框往右挪 8px你改完 margin她又说表格的 hover 背景色换成浅蓝你打开调色板选半天最后她说整体间距好像不太对你统一检查一下所有区块的 padding。这种连环微调一版接一版每一版都觉得自己在玩大家来找茬。我当时最真实的感受是我对写代码这件事的热情正在被无数个 8px 一点点磨没。1.2 一个页面的隐性成本清单很多人只看到了拼 UI 就是写标签和样式但实际上一张静态页面上线之前里面藏着大量看不见的成本。我把它列成了一张清单你对照着看自己是不是也踩过布局方案选择Flex 还是 Grid百分比还是 rem要不要考虑 calc()光这一项就要花不少时间权衡。响应式适配不同断点下重新排列元素、调整字号和间距验收时总有几个设备会意外崩掉。交互状态补全hover、active、focus、disabled、loading、empty、error一个组件七八种状态写起来全是重复劳动。浏览器兼容老项目里还得惦记 IE 时代的写法和兼容前缀庆幸现在这类问题少多了但偶尔还是会冒出来。设计还原度像素眼盯出来的细节一个圆角、一道阴影、一条分割线的颜色都要逐个对齐。命名与维护类名怎么取、样式怎么组织、要不要抽组件直接决定下次改版时会不会骂人。算完这笔账你会发现拼 UI 真正昂贵的不是写代码这个动作而是决策——每一次选择都要消耗注意力。AI 能替代的恰恰是这部分。它不需要犹豫给它一个需求描述它能直接给你一版合理的布局和样式把决策成本几乎降到了零。我后来之所以再也不想回到手拼时代就是因为这个成本差实在太大。2. AI 凭什么能替掉拼这个动作2.1 拼 UI 的本质是翻译想明白 AI 为什么能接手 UI 工作之前得先搞懂拼 UI 的本质。在我看来它就是一道翻译题把设计稿或者需求描述翻译成代码。设计稿里有视觉元素、间距、色彩、字体代码里有对应的标签、属性和样式规则两者之间存在一套约定俗成的映射关系。大多数情况下这种翻译是线性的、有规律可循的比如一个蓝色圆角按钮对应的就是button标签加上background-color: blue; border-radius: 8px;。这种规律性好翻译的工作恰恰是 AI 最擅长的。大模型的底层能力就是模式识别和内容生成你给它一段自然语言描述它能根据训练数据里的海量常见模式组合出一份大概率合理的代码。它不是真的理解美不美但它见过足够多的漂亮界面知道按钮一般在哪、导航栏一般多高、表格一般长什么样。不过得说清楚一件事AI 能替代的是把想法变成代码这个翻译环节替代不了的是判断这个想法对不对。哪怕你已经完全用 AI 生成 UI产品逻辑、信息架构、交互路径这些更高层的决策还是得你自己拍板。这个边界从第一天就要想明白否则后面容易出现AI 说行就行的失控状态。2.2 几种主流的 AI 生成 UI 路线我试下来现在用 AI 做 UI 大致有四种路线各有各的适用场景。第一种是对话式 UI 生成工具典型代表是 Vercel 的 v0 这类产品。你输入一句帮我做一个后台用户管理页面左侧导航右侧是用户列表和分页它直接给你吐出一整段可运行的代码通常基于 React 和 Tailwind 生态。这种路线的优点是拉齐了从需求到代码的整条链路缺点是对接现有工程时要花力气改造因为生成的代码往往自带一套样式体系。第二种是编辑器内的 AI 辅助编码。Cursor、Copilot 这类工具装在 IDE 里你在写代码的过程中用对话或补全的方式让 AI 帮你生成组件、补全样式。这个路线门槛最低不改变你现有的开发流程AI 只在你需要的地方介入。缺点是你要自己把需求描述清楚生成质量也取决于你上下文给得够不够。第三种是截图生成代码。把设计稿截图丢给支持视觉理解的大模型它根据图片信息反推出对应的 HTML/CSS。这个路线对还原度比较敏感适合已经有完整设计稿、想快速出静态页面的情况但目前对复杂布局和特殊效果的处理还不太稳定。第四种是设计工具内置 AI。Figma 等工具也在把大模型能力塞进设计流程里你可以在设计稿里直接用 AI 生成组件库、自动排版、一键出前端代码。这条路线的价值在于让设计和开发共用一套数据但目前成熟度参差不齐我在团队里推广的时候大家还是更习惯先出设计稿再让 AI 转代码。2.3 为什么说不想拼而不是不能拼标题里我说的是再也不想拼 UI注意这里的措辞是不想不是不能。为什么强调这个因为 AI 实际上还做不到百分百替代手写尤其是一些偏门布局和精细动效人工介入依然必要。但不想表达的是一个根本的态度转变当 AI 能把 80% 的重复界面工作做到七八十分的水平时我为什么还要把时间花在那 80% 上呢这就好比你有一台洗衣机它可能洗不干净领口袖口这种顽固污渍但你不会因为要手搓领口就拒绝把整桶衣服塞进洗衣机。你会做的是先机洗再把局部污渍拎出来手动处理。我现在写界面就是这个状态——AI 先把大框架搭好我再来补细节、调逻辑、处理那些它搞不定的部分。总工作量没有凭空消失但最耗神的从无到有阶段被砍掉了省下来的精力可以放在更有价值的业务思考上。3. 我的实战工作流从需求到 UI 上线3.1 第一版直接让 AI 出整页先拿一个最近做的项目举例吧。当时要给一个内部数据平台做新版的看板页需求是顶部放核心指标卡片中间是趋势图区域底部是排行榜表格。按照我过去的习惯这个页面从零手写至少得干一下午。这次我直接打开 AI 对话把需求打了过去。我给它的初始描述是这样写的做一个数据看板页面顶部四个指标卡片显示今日访问量、转化率、平均停留时长、订单数卡片要有图标和环比数据中间是一张折线图展示最近 30 天趋势底部是榜单表格包含排名、名称、数值、操作列。整体风格偏简洁现代用浅色背景卡片用白色带圆角阴影。大概等了几十秒AI 返回了一整套代码包括页面布局、卡片的复用组件、图表的占位结构样式用的是 Tailwind。说实话第一版的可视效果比我预期要好。指标卡片、间距、配色都像模像样唯一的明显问题是折线图它只写了占位区域没有真的接图表库。这也在预料之中——你不明确告诉它用什么图表库它大概率会用占位结构先应付你。这一步的经验是第一版的描述描述得越具体输出质量越接近你想要的效果。与其给一句给我做个看板不如把区块结构、数据维度、样式倾向全部塞进去。AI 就像一个新来的实习生你让它自由发挥它就发挥给你看。3.2 迭代修正用对话上下文把 AI 拉回正轨AI 生成的第一版几乎不可能一步到位真正磨人的是后续迭代。我用下来的感觉是AI 对话能记住上下文但它的记忆是有边界的你需要通过一轮轮指令逐步把结果引向理想状态。还是上面那个看板页。第一版出来之后我提了三个修改意见第一指标卡片的图标太大了缩小一点放到左上角文字左对齐第二折线图改用 ECharts数据先写死一个示例序列第三表格的排名列用数字序号前三名加个浅色背景标记。第二轮输出就明显好很多图标位置对了图表也真的接上了 ECharts只是示例数据的随机性比较强看起来不够专业。第三轮我又让它把环比数据的上升下降状态用绿色红色区分并加了箭头标识再让它给看板页补一个刷新数据按钮点击后模拟重新拉取数据。到这一步这个页面已经基本达到可用状态了。整轮下来花了二十分钟左右如果手写至少需要三四个小时。这里有个关键技巧不要一次性给 AI 太多修改指令。一次塞五六个诉求它容易顾此失彼改完 A 丢了 B。更稳的做法是一轮一两个核心诉求改完就检查确认无副作用再进行下一轮。这就像调整镜头焦距一点一点转比猛地拧到底要精准得多。3.3 把 AI 生成的 UI 接进真实工程AI 生成代码是一回事把代码接进项目又是一回事。很多人都卡在这一步AI 输出时用的是 Tailwind你项目用的是普通 CSS它默认从零搭了个单文件页面你的项目是组件化工程结构。这些问题不处理好AI 生成的代码就只能是预览好看、接入想哭。我的做法是提前给 AI 交代工程约束。在第一轮指令里就会加上类似这样的话项目使用 Vue 3 Element Plus页面组件在 src/views/dashboard/index.vue不要引入额外的 UI 框架图表用 ECharts。 这个前缀看着啰嗦但能减少大量后期返工。AI 很会顺从描述你告诉它边界它就会在边界内发挥。如果 AI 已经生成了偏离工程约束的代码也不用推翻重来。通常我会让它做一次结构改写指令是保持现有视觉布局不变把 Tailwind 类名改成普通 CSS 类名写到单独的 style 标签里把页面拆成三个子组件分别是 MetricCard、TrendChart、RankTable并在父组件中引用。 这种重构任务 AI 执行得很干净比人工复制粘贴调整要快得多。接入工程后还有一件必做的事跑一次构建和 lint。AI 代码在语法层面偶尔会出小错误比如漏了个括号、引用了未定义的变量。这些在对话预览里可能看不出来一跑编译就暴露。我的习惯是接到代码先npm run build一次有报错就直接把报错信息原样贴回给 AI让它自己修。实测下来AI 修自己代码的错误效率非常高。3.4 提示词模板直接可抄的三种写法既然说到提示词我就把在项目里反复验证过的三种模板放出来按场景取用。第一个是整页快速生成型适合从零快速出完整页面请帮我生成一个[页面类型]页面项目用的是[框架UI 库]。 结构要求[列出区块顺序和功能]。 数据交互[说明哪些是静态数据、哪些需要接口占位]。 样式要求[主色调、圆角风格、响应式要求]。 不要引入额外的依赖[图表/组件]统一使用[库名]。第二个是局部组件改型适合你已经有一个页面只想让 AI 生成或修改某个区块在现有的[页面路径]中帮我新增一个[组件名]组件。 功能说明[列出组件的字段、交互、状态]。 视觉参考[描述当前项目的风格点名参考哪个已有组件]。 输出要求组件直接放在[目标路径]样式沿用现有风格父组件中补上引用。第三个是设计稿转码型适合有截图和设计稿的场景下面是这个页面的设计稿截图。 请把它还原为[框架UI库]代码要求 1. 像素级还原布局和间距 2. 交互状态只写 hover 和 disabled 3. 图片资源用占位链接 4. 输出为单文件组件样式写在 style 中。这三套模板看着简单但每一句背后都有讲究。比如不要引入额外依赖能防止 AI 顺手给你装一个它觉得好用但你根本不需要的库输出为单文件组件是约束结构方便你后续接手调整。写提示词这件事本质和带新人一样指令越明确产出越靠谱。花五分钟把需求描述清楚省下来的是几小时的返工。4. 常见翻车现场与排查思路4.1 布局错乱AI 理解的居中和你想要的居中不是一回事AI 生成 UI 最先暴露的问题通常是布局错乱。这里面最典型的是居中这个词的歧义。你说文字居中它可能用的是text-align: center你说卡片居中它可能写的margin: 0 auto但如果你外面包了一个 Flex 容器这俩就打架了。还有更隐蔽的align-items: center和justify-content: center一个管垂直一个管水平AI 偶尔会搞混导致元素该横着排却竖着排。碰到布局问题我的排查顺序是先看外层容器确认它是 Flex 还是 Grid主轴方向对不对再看目标元素确认它的宽高约束、对齐方式和 margin 设置。绝大多数布局错乱都能在这两步里找到答案。如果你把报错的代码贴回 AI 对话补充一句检查外层容器的 Flex 主轴方向它通常能自己发现问题。4.2 业务逻辑缺失AI 默认生成空壳 UI这是我认为最需要注意的坑。AI 拼出来的是一个漂亮的壳子按钮点击没有任何行为表格数据全是写死的假数据弹窗关闭后没有回调。在用的时候它看起来很完整但接上业务后处处是洞。深层原因在于大模型是从视觉模式学习的它知道按钮长什么样但不知道你的按钮点击后要调哪个接口。所以在让 AI 生成 UI 的时候一定要在提示词里把交互行为说清楚。不能说加一个删除按钮要说加一个删除按钮点击后弹出确认框确认后调用 deleteUser 接口成功后刷新表格数据。有一次我让 AI 做一个批量操作栏它做了复选框和操作按钮但复选框的选中状态根本没有绑定到组件的数据模型里全选功能也是假的。我排查了很久后来发现它只是把视觉做了出来交互逻辑全是空的。自那以后我生成任何组件都会额外加一句指令所有交互都必须绑定真实的状态和事件不允许只有视觉没有逻辑。4.3 工程接入问题样式冲突与依赖冗余AI 生成的代码接进大型工程最常见的两类问题一是样式冲突二是依赖冗余。样式冲突的典型场景是AI 把类名起得很随意比如.container、.wrapper进了项目之后和现有全局样式撞车页面瞬间变得面目全非。解决思路是让 AI 在输出时加上组件级作用域比如 Vue SFC 里的 scoped或者在提示词里要求类名统一以页面名开头例如dashboard-card、dashboard-header。依赖冗余则是 AI 倾向于想到什么就 import 什么。它可能在代码里引入一个lodash的函数实际上你用原生 JS 几行就写完了也可能为了一个弹窗引入了整个antd。预防手段还是在提示词里明确不要引入代码中未使用的依赖并养成生成后扫一眼 import 区的好习惯。刚开始用 AI 拼 UI 的那阵子我吃过好几次这类亏后来干脆把这条写进了团队的 Code Review 检查项。4.4 性能拖后腿AI 生成的代码不一定快AI 生成的 UI 往往视觉达标但性能可能是隐患。最常见的情况是它在列表渲染里埋了不合适的写法比如一次性渲染几千行的表格没做虚拟滚动或者滥用 flex 嵌套导致 DOM 结构过深。虽然这类问题在中小页面上感知不强一旦数据量上来页面该卡还是卡。我做内部系统时遇到过一个案例AI 生成的最近 30 天趋势图在数据更新时直接替换了整个 ECharts 实例而不是调用 setOption 更新结果拖拽筛选时图表频繁闪烁、响应迟钝。修复方式也简单把问题描述给 AI ECharts 实例应该复用数据更新用 setOption 而不是重新初始化。 它很快就能改对。我的建议是AI 生成的代码接入工程后自己至少过一遍性能敏感区域不要默认生成即最优。5. 我不想再拼UI但我更在意这五件事5.1 视觉还原度的底线AI 拼 UI 省了时间但还原度这条底线不能放宽。对设计师或者产品经理来说页面好不好看、是否和设计稿一致直接影响对开发结果的第一印象。如果 AI 生成的界面风格凌乱就算功能全对验收时还是会被打回。我的做法是提前把设计规范喂给 AI。在生成页面之前先发一段项目样式规范主色 #2563EB辅助色 #F59E0B文字主色 #1F2937圆角统一 8px卡片阴影使用 shadow-sm间距基准 4px 递增。 这串信息会让 AI 的产出与现有设计体系保持一致。实测下来给足规范后 AI 的还原度能从勉强能看提高到基本达到验收标准。5.2 可维护性比一次性生成更重要AI 可以瞬间生成一版 UI但如果代码没法维护下个迭代就是灾难。我见过有人把 AI 生成的几百行代码原封不动塞进项目从没重构过等需求一变整块代码就像一个黑盒谁也不敢碰。维护性的核心是组件边界和命名清晰度。我现在的习惯是AI 生成页面后要求它把重复结构抽成组件每个组件控制在自己能读懂的规模内。哪怕组件只有一两个地方用到只要它有独立的语义比如指标卡片状态标签抽出来就是值得的。这样做的好处不仅是可读性更重要的是后续 AI 修改时能精准定位——你让它改指标卡片的图标位置它能直接找到对应组件而不是在一大坨代码里乱翻。5.3 与现有设计系统的兼容很多人忽略了一点AI 生成的 UI 再好看也要融入现有的设计系统才真正有用。如果团队有现成的组件库比如 Element Plus、Ant Design、Material UI那 AI 生成时就必须优先复用这些库的组件而不是自造车轮。我遇到过 AI 生成了一个完全自定义的下拉选择框交互细节和原有组件库完全不同接入后用户使用体验割裂最后还得换回标准组件。现在我会在提示词里写死下拉框、日期选择器、分页器一律使用项目 UI 库自带组件不要自定义封装。 这个约束往往能让生成的 UI 和项目里其他页面保持一致性Team 里的设计 review 也轻松不少。5.4 组件化的边界AI 拼 UI 时我建议给组件的拆分边界做个把控。组件拆得过粗一个组件塞满了整个页面的所有逻辑改一处就重新渲染全部拆得过细文件数量爆炸纯粹增加维护负担。平衡点在哪里我的经验是按数据域拆分一个组件负责一块独立数据比如用户卡片组件只管用户信息排行榜组件只管榜单数据它们之间通过 props 传参不共享内部状态。这个粒度既不会太碎也不会太粗。这个边界其实和 AI 的生成思路很匹配因为大模型倾向于一段描述对应一个组件你告诉它排行榜做成一个独立组件数据由父组件传入它就真能拆得干净利落。反而让它整个页面一把梭它也会给你一把梭来一坨代码。5.5 团队协作模式的变化最后想说一点可能不那么技术、但影响最深远的AI 拼 UI 之后团队里的角色边界开始模糊了。过去前端写页面、设计师出图、后端给接口分工线画得清清楚楚。现在我用 AI 可以独立完成从前端到界面的整条链路设计师也能用 AI 直接生成可交互的代码原型PM 甚至能自己用 AI 做一个页面 Demo 给用户测试。角色不再是一成不变的边界而是谁能用工具更快把手里的需求变成现实。这种转变对个人能力提出了新要求你不再只需要会写代码或者会设计更需要会指挥 AI。在团队里我现在花在写提示词和审查 AI 生成结果上的时间已经超过了手动写样式的时间。那些擅长把需求转化为准确指令的人正在成为新的效率节点。这不是坏事只是提醒我们技能树的重心要跟着工具一起迭代。写在最后的一点体会用过一段时间 AI 拼 UI 之后我最大的感受不是开发变快了这么简单而是工作心态发生了变化。以前接到一个布局复杂的页面第一反应是叹气因为知道又要和像素较劲一下午现在第一反应是兴奋因为可以很快看到一个大致的视觉稿然后像打磨一件半成品一样逐步完善。这个从从零开始到从半成品开始的转变带来的效率提升是几何级别的。最后再分享一个小技巧AI 生成的 UI 代码不要直接复制完就提交。我会先花三分钟做三件事——扫一眼 import 有没有多余的依赖检查交互事件是不是绑定了真实数据最后让它在浏览器里过一遍主要状态。这三分钟看着不起眼但能帮你避免后面花三个小时排查线上问题。还有一点遇到 AI 产出不满意的时候别急着换工具重来试着把它的代码或截图贴回去问一句你觉得你自己这个界面有什么问题你会发现不少模型对自己的产出还挺有判断力的改起来反而比从头再来更快。