★ FEATURED ARTICLE 1. 从“拼 UI”到“说 UI”一个老前端的真实转变“自从有了 AI我就再也不想拼 UI 了”——这句话我第一次在团队群里看到的时候差点以为是哪个刚入行的新人在发牢骚。结果点开一看是组里干了八年的老前端。他以前是那种能把 Figma 标注精确到 0.5px、能手写 PSD 切图、能对着设计稿调一整天阴影的人。现在他居然说不想拼 UI 了这反差感太强了。我后来跟他聊了很久也自己上手试了几个月才慢慢理解这句话背后的真实含义。它说的不是“UI 不重要了”而是**“把设计稿翻译成代码”这件事的性价比正在被 AI 彻底重构**。以前我们拼 UI拼的是耐心、是像素眼、是对 CSS 各种诡异行为的肌肉记忆现在拼的是提示词、是对组件结构的理解、是对生成结果的判断力。这篇文章我想聊的就是这个转变。它适合三类人看一是每天还在和 PSD、Figma 标注搏斗的前端和客户端开发二是想用 AI 提效但不知道怎么落地的独立开发者三是做 UI 框架、组件库、设计系统相关工作的同学。我会把“AI 生成 UI”这件事从思路、工具、实操到踩坑完整拆一遍尽量让你看完就能上手抄作业。先给个结论AI 不是让你不拼 UI而是让你从“手工拼装”变成“结构描述 结果校验”。你省下的是重复劳动但你对布局、层级、状态、适配的理解反而要更深否则生成的东西你根本改不动。2. 为什么“拼 UI”这件事最该被 AI 接管2.1 拼 UI 的本质是“翻译”不是“创作”很多人把写 UI 当成创作其实大部分业务 UI 就是翻译工作把设计稿的视觉语言翻译成代码语言。设计稿里一个卡片有圆角、阴影、内边距、标题字号、副标题颜色、图标位置、点击态、禁用态。这些信息在设计稿里是“视觉”在代码里是“属性”。翻译过程高度机械但又极度依赖经验因为设计稿不会告诉你flex怎么嵌套、z-index怎么处理、overflow会不会裁掉阴影。AI 最擅长的恰恰就是这种“有明确输入、有固定映射规则、但组合方式多样”的翻译任务。你给它一张设计稿描述或者结构说明它能快速吐出对应的 JSX、Vue 模板、Flutter Widget 或者 Unity Prefab 结构。它不会累不会因为改了 20 版而烦躁也不会在凌晨三点把margin写成padding。2.2 传统拼 UI 的三大痛点AI 正好对症第一个痛点是重复劳动。一个中后台系统表格、表单、弹窗、卡片翻来覆去就那几种结构但每次都要重新写一遍。AI 可以基于组件库快速生成你只需要微调。第二个痛点是跨端一致性。同一套设计Web 端、移动端、桌面端各写一遍改一个圆角要改三个地方。AI 可以基于同一份结构描述生成不同端的代码虽然不能百分百直接跑但至少骨架和命名是一致的。第三个痛点是设计稿与代码的语义鸿沟。设计稿里叫“主按钮”代码里叫primary-btn另一个页面又叫btn-main。AI 在生成时会倾向于使用你给的命名规范只要你把规范写进提示词它就能保持统一。2.3 不是所有 UI 都适合 AI 生成这里必须泼一盆冷水。AI 生成 UI 目前最适合的是结构规整、状态明确、交互常规的界面比如管理后台、表单页、列表页、详情页、设置页。对于强视觉创意、复杂动效、游戏 HUD、数据可视化大屏AI 生成的结果往往需要大量返工反而不如手写快。我自己的判断标准是如果这个界面你能用“几个区块 几个组件 几种状态”描述清楚那就适合 AI如果它依赖大量视觉微调和动态计算那就先手写核心部分再用 AI 补外围。3. 核心工具链拆解从 PSD 到 Codex 到 Prefab3.1 设计稿输入PSD、Figma、截图都能用以前我们拿到 PSD 要手动切图、量距离、取色。现在 AI 工具可以直接读设计稿。常见做法有三种Figma 插件 AI很多 Figma 插件支持把选中图层导出成结构化 JSON再喂给 AI 生成代码。这种方式信息最全能拿到图层名、坐标、样式。截图 多模态模型直接截图丢给支持视觉的模型让它描述结构并生成代码。这种方式快但精度取决于截图清晰度和模型能力。手工结构描述最土但最稳。你用文字把布局写清楚比如“顶部导航栏左侧 logo中间菜单右侧头像下方两栏左窄右宽”。AI 对这种输入的理解反而最准确。我实测下来Figma 结构化导出 文字补充的组合效果最好。纯截图容易丢细节纯文字又太费人。3.2 代码生成Codex 类工具的正确打开方式Codex 这类代码生成工具核心用法不是“一句话生成整个页面”而是分段生成 人工组装。我通常这样操作先让 AI 生成页面骨架比如一个三栏布局的容器。再针对每个区块单独生成比如“生成一个带搜索、筛选、分页的表格区块”。最后让 AI 统一命名规范和样式变量。这样做的好处是每段代码都可控出问题容易定位。一次性生成整页往往结构混乱、命名冲突、样式互相覆盖。关于 Codex 的安装和接入网上教程很多核心就是配置好运行环境、登录账号、选择模型。需要注意的是不同模型对代码的理解能力差异很大生成 UI 代码建议选擅长前端框架的模型。如果遇到模型不支持或者加载组织设置失败通常是账号权限或配置项的问题检查配置文件里的模型名称和区域设置即可。3.3 组件落地从代码到 Prefab、Widget、Component生成代码只是第一步真正落地还要变成项目里的组件。Web 端就是 Vue/React 组件Unity 就是 PrefabFlutter 就是 Widget。AI 可以帮你生成组件的基本结构但组件的挂载、引用、事件绑定还是需要你在编辑器里完成。我的习惯是让 AI 生成“纯展示组件”也就是只接收 props、不处理业务逻辑的组件。然后我自己写容器组件负责数据请求和状态管理。这样职责清晰AI 生成的代码也更容易复用。4. 实操全流程从一句描述到一个可用的 UI 组件4.1 第一步把设计稿拆成“结构树”不要一上来就让 AI 写代码。先花五分钟把界面拆成树状结构。比如一个用户列表页页面容器顶部操作栏标题搜索框新建按钮表格区域表头数据行分页器弹窗区域新建用户弹窗编辑用户弹窗这个结构树就是你和 AI 沟通的“合同”。结构越清晰生成结果越可控。4.2 第二步写一段“AI 能听懂”的提示词提示词不要写“帮我写一个好看的表格”要写具体约束。我常用的模板是这样的请生成一个 Vue3 TypeScript 的表格组件要求 - 使用 script setup 语法 - 接收 data 和 columns 两个 props - columns 每项包含 key、title、width、align - 支持分页分页参数通过 props 传入 - 样式使用 scoped css颜色变量用 var(--color-xxx) - 不要引入任何第三方 UI 库 - 表格行支持 hover 高亮这段提示词里框架、语法、props 结构、样式方案、依赖限制都写清楚了。AI 生成的结果基本可以直接用最多改改变量名。4.3 第三步生成、预览、修正的循环AI 生成代码后不要直接复制进项目。先在一个空白页面里跑起来看看结构对不对、样式有没有崩。常见问题包括flex 方向反了、间距不对、溢出没处理、响应式没做。这时候你可以把问题反馈给 AI让它针对性修改而不是自己硬改。我一般会循环三轮第一轮生成骨架第二轮修样式第三轮补状态loading、empty、error。三轮之后基本就能用了。4.4 第四步接入真实数据和交互展示组件跑通后把它接入真实数据源。这一步 AI 帮不上太多因为涉及你的接口格式、状态管理方案、路由参数。但你可以让 AI 帮你写数据转换函数比如把后端返回的字段映射成组件需要的格式。4.5 第五步沉淀成项目模板每次生成完把好用的提示词和组件结构存下来。下次遇到类似界面直接改提示词就行。我现在的项目里有一个ai-prompts目录专门放各种场景的提示词模板比如“标准表格页”“标准表单页”“标准详情页”。新页面来了先找模板再微调效率比从零写高很多。5. 避坑指南AI 生成 UI 的常见问题和排查技巧5.1 生成结果“看起来对跑起来崩”这是最常见的问题。原因通常是 AI 只考虑了视觉结构没考虑运行环境。比如它生成了一个绝对定位的布局在固定宽度下没问题但你的容器是弹性的一拉伸就重叠。排查方法是把生成代码放到真实容器里用不同窗口尺寸测试重点看溢出、换行、层级。5.2 命名冲突和样式污染AI 生成多个组件时容易用相同的类名比如都叫.container、.title。如果项目没有 CSS Modules 或 scoped 样式就会互相污染。解决办法是在提示词里强制要求“类名带组件前缀”或者生成后统一加 scoped。5.3 状态缺失AI 默认生成的组件往往只有“正常态”没有 loading、empty、error、disabled。这些状态在实际业务里必不可少。我的做法是在提示词里直接列出需要支持的状态让 AI 一次性生成。5.4 过度依赖第三方库有时候 AI 会引入你项目里根本没有的 UI 库导致装包、版本冲突、样式不一致。提示词里一定要写“不要引入第三方 UI 库”或者“只使用项目已有的 xxx 库”。5.5 常见问题速查表问题现象可能原因排查方法解决建议布局错乱flex/grid 方向或嵌套错误在浏览器开发者工具看盒模型让 AI 重新生成布局部分样式不生效类名冲突或 scoped 问题检查生成的 class 是否重复加组件前缀或 scoped状态缺失提示词没写对照业务需求检查补充 loading/empty/error依赖报错引入了不存在的库看 package.json提示词限制依赖响应式失效没写媒体查询或弹性单位缩放窗口测试要求使用 rem/百分比/flex交互无反应事件没绑定或命名错误看控制台报错让 AI 补事件处理函数6. 我个人的经验体会用了几个月 AI 生成 UI 之后我最大的感受是它没有让我变懒而是让我把精力从“怎么写”转移到了“写什么”。以前我花大量时间纠结margin是 8 还是 12现在我把这些交给 AI自己去想这个页面的信息层级对不对、用户操作路径顺不顺、异常状态覆盖全不全。还有一个很实际的体会提示词的质量直接决定生成代码的质量。你描述得越像一份技术方案AI 给你的代码就越接近生产可用。你如果只丢一句“帮我写个页面”那出来的东西基本就是玩具。最后分享一个小技巧把 AI 生成的组件当成“实习生写的代码”来对待。你会 review 实习生的代码会改命名、补注释、加边界处理。对 AI 也一样。它负责快你负责对。这个分工一旦跑顺拼 UI 这件事就真的没那么痛苦了。
阅读完成 · 觉得有帮助？
