1. 从“拼UI”到“说UI”一个前端老手的真实转变“自从有了 AI我就再也不想拼 UI 了”——这句话我第一次在团队群里看到时差点以为是哪个刚入行的新人在发牢骚。结果点开一看是组里干了八年的老前端。他以前是那种连一个像素的间距都要跟设计稿死磕的人现在居然说不想拼 UI 了。我当时的反应是要么他疯了要么工具真的变了。后来我自己试了一圈才明白这句话背后的真实含义。它不是“AI 能一键生成完美界面”这种营销话术而是工作流的重心发生了转移以前我们花大量时间在“把设计稿翻译成代码”这件事上现在这件事的边际成本被压得很低真正值钱的部分变成了“描述清楚你要什么”和“判断生成结果对不对”。这篇文章想聊的就是这套转变到底是怎么发生的。我会从“拼 UI 为什么让人痛苦”讲起拆解 AI 介入 UI 生产的具体环节给出可以直接抄的提示词模板和验证流程再聊聊那些我踩过的坑——比如生成出来的代码看着能跑但布局一塌糊涂、组件复用率低到离谱、响应式完全没考虑等等。适合所有还在手写 CSS、手调 Flex 布局的前端、全栈、独立开发者以及想搞清楚“AI 到底能不能替代 UI 工作”的技术负责人。先说结论AI 不能替代你对界面结构的理解但它能把你从重复劳动里捞出来。前提是你得知道怎么用它以及在哪里不能信它。2. 拼 UI 这件事到底哪里让人崩溃2.1 重复劳动的本质设计稿到代码的“翻译损耗”很多人以为拼 UI 累是因为“写 CSS 麻烦”其实不是。真正累的是翻译过程中的信息损耗。设计稿里一个卡片标注了 padding 24px、圆角 12px、阴影 0 4px 12px rgba(0,0,0,0.08)你照着写写完发现跟设计稿还是不一样。为什么因为设计稿是静态的而界面是活的——文字长度会变、屏幕宽度会变、内容多少会变。我统计过自己以前做一个中等复杂度页面的时间分配大概 30% 在写结构40% 在调样式细节20% 在处理响应式和边界情况10% 在跟设计对稿。也就是说超过一半的时间花在了“对齐”上而不是“创造”上。这种对齐工作有个特点它必须做但做完之后没有任何沉淀。下次换个项目同样的卡片、同样的按钮你还得再来一遍。AI 介入之后变化最大的就是这 40% 的调样式细节。你把设计意图描述清楚它能把基础样式一次性铺出来你只需要微调。这不是“省时间”那么简单而是把你的注意力从“怎么写”转移到了“要什么”。2.2 组件化并没有解决所有问题有人会说不是有组件库吗Ant Design、Element Plus、shadcn/ui拿来就用怎么会累这话对了一半。组件库解决的是“标准组件”的问题但真实项目里大量存在的是非标准组合。比如一个带折叠动画的筛选面板、一个支持拖拽排序的标签列表、一个在移动端要变成抽屉的侧边栏。这些组件库不提供你得自己拼。而且组件库用多了会有另一个问题样式覆盖的复杂度指数上升。你为了改一个按钮的圆角可能要写三层选择器为了调整表格行高得翻半天文档找对应的 CSS 变量。这种“跟框架搏斗”的时间在 AI 辅助下能明显压缩——因为你可以直接把需求描述给它让它生成覆盖样式而不是自己去翻源码。2.3 真正让人不想拼的是“不可复用”我见过太多项目页面写了上百个但组件复用率不到 20%。每个页面都在重新造轮子只是轮子的颜色和尺寸略有不同。这不是开发者懒而是在赶工期的时候抽象是最先被牺牲的。你明知道这两个卡片可以合并成一个组件但合并要改 props、要处理差异、要测试不如复制一份改改快。AI 在这个环节的价值不是帮你写组件而是帮你识别哪些东西该被抽象。你把几个相似的页面结构丢给它它能告诉你哪些部分是重复的、可以抽成公共组件。这个能力在以前需要经验丰富的架构师来做现在一个中级开发者借助 AI 也能做到七八成。3. AI 介入 UI 生产的三个真实切入点3.1 从文字描述直接生成结构代码这是最直观的用法。你不需要画设计稿直接用自然语言描述界面让 AI 生成 HTML/CSS 或 JSX/Tailwind 代码。比如生成一个用户信息卡片包含头像圆形64px、姓名16px 加粗、职位14px 灰色、一行简介最多两行超出省略号右下角有一个“关注”按钮整体圆角 12px有轻微阴影。这种描述丢给现在的 AI基本能一次生成可用的代码。但关键在于描述的颗粒度。我试过只写“生成一个用户卡片”出来的东西完全不能用写到上面这个程度出来的代码改两行就能上。所以核心技能不是“会用 AI”而是能把界面拆解成可描述的属性。这里有个我常用的模板你可以直接抄生成一个 [组件类型]要求如下 - 布局[flex/grid/block]主轴方向对齐方式 - 尺寸宽度 [固定/自适应/百分比]高度 [固定/最小高度] - 间距内边距 [上下左右]外边距 [上下左右] - 圆角[数值] - 阴影[描述或具体值] - 字体标题 [字号/字重/颜色]正文 [字号/字重/颜色] - 交互[hover/active/focus 状态变化] - 响应式[断点及对应变化] - 技术栈[React/Vue/原生 CSS 方案]用这个模板生成结果的可用率能从 30% 提到 80% 以上。剩下的 20% 通常是响应式和边界情况需要手动补。3.2 从截图或设计稿反向生成代码另一个高频场景是设计给了 Figma 链接或者一张截图你要把它变成代码。以前的做法是量间距、取色值、手动写。现在可以把截图丢给支持视觉的 AI 模型让它直接输出代码。实测下来这个方式的准确率取决于截图的清晰度和界面的复杂度。简单的卡片、表单、列表准确率很高复杂的仪表盘、带大量图表的页面AI 容易漏掉细节。我的做法是分块处理把页面拆成头部、侧边栏、内容区、底部一块一块生成最后拼起来。这样比整页生成准确得多而且出错了容易定位。有个细节要注意AI 从截图生成代码时颜色和间距经常是“近似值”。它可能把 #F5F5F5 写成 #F4F4F4把 24px 写成 20px。所以生成之后必须跟设计稿核对一遍关键数值。我一般会让它把用到的颜色和间距单独列出来方便对照。3.3 在已有代码基础上做增量修改这是我觉得最实用的场景也是“不想拼 UI”的核心原因。以前改一个样式你要找到对应的文件、定位到具体行、改完还要担心影响别的地方。现在可以直接把相关代码贴给 AI用自然语言描述修改需求把这个卡片的阴影去掉圆角从 8px 改成 16px按钮从右对齐改成居中移动端下内边距从 16px 改成 12px。AI 会直接给你改好的代码。你只需要 review 一遍确认没有误伤其他样式。这种方式特别适合迭代阶段的微调效率提升非常明显。但这里有个坑AI 可能会“顺手”改掉你没让它改的东西。比如你让它改圆角它可能把边框颜色也调了。所以我的习惯是每次修改只提一个明确的需求改完确认无误再进行下一个。批量提需求虽然快但出错后排查成本高。4. 提示词写得好UI 代码差不了4.1 结构描述用“盒子思维”代替“视觉思维”很多人描述界面时习惯说“左边一个头像右边上面是名字下面是职位”这种描述对人没问题对 AI 就容易产生歧义。更有效的方式是用盒模型的语言来描述外层容器flex 横向排列align-items 居中gap 12pxpadding 16px。 左侧子元素固定 64x64圆角 50%。 右侧子元素flex 纵向排列gap 4pxflex: 1。 右侧第一行文字“张三”16pxfont-weight 600。 右侧第二行文字“前端工程师”14px颜色 #666。这种描述方式的好处是没有歧义。AI 不需要猜“左边”是多左、“右边”是多右它只需要按照盒模型一层层搭就行。我刚开始用 AI 生成 UI 时最大的问题就是描述太“视觉化”导致生成结果跟预期差很远。改成盒模型描述之后准确率大幅提升。4.2 样式约束把设计系统“喂”给 AI如果你所在团队有设计系统比如主色 #1677FF、圆角统一 8px、间距用 4 的倍数一定要在提示词里把这些约束写清楚。否则 AI 会自由发挥生成一堆“看起来还行但跟设计系统不搭”的样式。我通常会在对话开始时先给一段“系统提示”本项目使用以下设计规范 - 主色#1677FF辅助色#52C41A、#FAAD14、#FF4D4F - 圆角小 4px中 8px大 16px - 间距4px 的倍数常用 8/12/16/24/32 - 字体系统默认字体栈标题 16px/600正文 14px/400辅助 12px/400 - 阴影卡片 0 2px 8px rgba(0,0,0,0.08) - 技术栈React Tailwind CSS把这段放在对话最前面后续所有生成都会遵循这个规范。实测下来这样生成的代码几乎不需要再调样式直接就能用。4.3 交互状态别漏了 hover、focus、disabled新手用 AI 生成 UI 时最容易漏的是交互状态。你描述了一个按钮AI 给你生成了默认样式但 hover 什么样、点击什么样、禁用什么样全没写。结果就是界面“能看但不能用”。我的做法是在提示词里显式列出所有状态按钮组件 - 默认背景 #1677FF文字白色圆角 8pxpadding 8px 16px - hover背景 #4096FF - active背景 #0958D9 - disabled背景 #F5F5F5文字 #BFBFBFcursor not-allowed - focus外发光 0 0 0 2px rgba(22,119,255,0.2)这样生成出来的按钮才是完整的。虽然多写几行但省去了后面手动补状态的时间总体是划算的。5. 生成之后验证与修正的完整链路5.1 先看结构再看样式AI 生成的代码拿到手不要急着看样式对不对。先看 DOM 结构是否合理。我见过太多生成结果样式看着没问题但结构嵌套了七八层 div或者该用语义化标签的地方全用了 div。这种代码短期能跑长期维护是灾难。我的检查顺序是结构层级是否扁平一般不超过 4 层是否使用了语义化标签header、nav、main、section、button 等类名是否有意义不是 div1、div2 这种样式是否内联内联样式尽量少优先用 class响应式断点是否合理这五步走完基本能过滤掉 80% 的“看着能用但实际不能维护”的代码。5.2 用真实数据“压”一遍AI 生成 UI 时默认用的是“理想数据”——名字是两三个字、简介是一句话、列表是三五条。但真实场景里名字可能有十几个字、简介可能是一大段、列表可能有上百条。所以生成之后一定要用极端数据测一遍。我常用的测试数据超长文本一段 200 字的中文看是否溢出、是否省略空数据列表为空、头像加载失败看是否有兜底超多数据列表 100 条看是否卡顿、是否需要虚拟滚动窄屏320px 宽度下看布局是否错乱这一步能暴露大量 AI 生成时没考虑到的边界问题。我遇到过生成的卡片在超长文本下直接撑破容器也遇到过空列表时页面一片空白没有任何提示。这些问题不测是发现不了的。5.3 组件抽取从“能用”到“好用”的关键一步AI 生成的代码往往是“页面级”的一个文件里堆了所有东西。直接上线也能跑但复用性很差。我的做法是生成之后手动做一次组件抽取把重复出现的结构抽成组件把可配置的部分抽成 props把状态逻辑抽成 hooks 或 composables这一步 AI 也能帮忙。你可以把生成的两个相似页面贴给它问“这两个页面有哪些部分可以抽成公共组件”它会给出建议。但最终的抽取决策还是要人来做因为 AI 不了解你的业务上下文。6. 那些 AI 生成 UI 时一定会踩的坑6.1 布局“看起来对但一测就崩”这是最高频的问题。AI 生成的布局在标准屏幕宽度下看着没问题一旦屏幕变窄或变宽立刻错乱。根本原因是AI 倾向于用固定宽度和绝对定位而不是弹性布局。我的应对方式是在提示词里强制要求所有布局必须使用 flex 或 grid禁止使用固定宽度除非是头像、图标等确实需要固定的元素禁止使用绝对定位除非是遮罩、弹窗等确实需要脱离文档流的场景。加上这条约束之后布局的健壮性明显提升。6.2 颜色和间距的“近似值”陷阱前面提过AI 从截图生成代码时颜色和间距经常是近似值。这个问题在纯文字描述时也会出现——你说“浅灰色”它可能给你 #999也可能给你 #CCC。所以关键数值一定要显式指定不要用“浅灰”“大一点”“稍微”这种模糊词。我现在的习惯是所有颜色用十六进制所有间距用像素值所有字号用具体数字。虽然写起来麻烦一点但省去了后面反复调整的时间。6.3 无障碍属性几乎从不主动生成AI 生成 UI 时几乎不会主动加 aria-label、role、tabindex 这些无障碍属性。如果你的项目有无障碍要求必须在提示词里明确提出来所有交互元素必须包含适当的 aria 属性按钮需要 aria-label弹窗需要 roledialog 和 aria-modaltrue表单元素需要关联 label。不加这条生成出来的代码在无障碍扫描工具下基本全是红。6.4 响应式断点“一刀切”AI 默认的响应式策略往往是“小于 768px 就堆叠”但真实项目里断点要根据内容来定。一个三列布局可能在 1024px 就需要变两列在 640px 变一列。所以断点值也要在提示词里说清楚不要让它自己猜。7. 把 AI 嵌进日常工作流的几种姿势7.1 新页面先生成骨架再填业务逻辑我现在做新页面的流程是用文字描述页面结构让 AI 生成静态骨架HTML CSS手动把骨架拆成组件接入真实数据和业务逻辑用极端数据测试修正边界问题这个流程比传统方式快很多因为第 1 步和第 2 步以前要花大半天现在半小时就能搞定。省下来的时间可以用在第 3 步和第 4 步把业务逻辑和边界处理做得更扎实。7.2 老页面改造让 AI 先“读懂”再改改造老页面时我习惯先把相关代码贴给 AI让它总结这个页面的结构和样式逻辑。等它“读懂”之后再提具体的修改需求。这样比直接让它改要准确得多因为它有了上下文。比如我会先问“这个页面的布局结构是什么用了哪些主要的 CSS 类”等它回答完我再提“现在把卡片区域的间距从 16px 改成 24px其他不变。”这样它就不会误伤其他部分。7.3 设计稿走查用 AI 做第一轮比对设计稿和实现之间的差异以前靠人眼比对费时费力。现在可以把设计稿截图和实现截图一起丢给 AI让它列出差异点。虽然不能完全替代人工走查但能过滤掉大部分明显的问题比如间距不对、颜色偏差、圆角不一致等。我实测下来AI 走查能发现 70% 左右的视觉差异剩下的 30% 通常是需要结合交互才能发现的问题。作为第一轮过滤效率提升很明显。8. 关于“不想拼 UI”这件事我的真实体会用了大半年 AI 辅助 UI 开发之后我确实“不想拼 UI”了——但不是因为 AI 能替代我而是因为拼 UI 这件事本身的价值变了。以前拼 UI 是核心技能现在它变成了一个“描述清楚就能自动完成”的环节。真正值钱的能力变成了能不能把界面需求拆解清楚、能不能判断生成结果的质量、能不能在生成的基础上做抽象和优化。我现在的状态是打开编辑器的第一件事不再是写div而是想“这个界面该怎么描述”。描述清楚了代码自然就出来了。描述不清楚生成一百遍也是白搭。所以如果你问我 AI 到底能不能替代 UI 工作我的回答是它替代的是“翻译”环节不是“设计”和“判断”环节。而后者恰恰是区分普通开发者和优秀开发者的地方。最后分享一个我最近常用的技巧每次生成完代码不要急着用先让 AI 自己 review 一遍问它“这段代码有哪些潜在问题”。它经常能发现自己刚才漏掉的东西比如没处理空状态、没加 loading、某个地方用了固定宽度。这个“自检”步骤花不了几秒钟但能省去后面很多调试时间。