1. 从手写像素到描述意图UI 生产方式的拐点已经到来如果你做前端、做客户端、做小程序甚至只是偶尔帮朋友搞个后台管理页面你一定经历过这样的夜晚为了一个按钮的圆角、阴影、hover 态反复调 CSS为了一个列表的间距在 Figma 和 IDE 之间来回切换为了适配一个移动端断点把同一套布局重写三遍。这种工作不是没有价值但它的价值密度极低——你花 80% 的时间在翻译设计稿只有 20% 的时间在真正解决问题。自从有了 AI我就再也不想拼 UI 了这句话之所以能引起共鸣不是因为它夸张而是因为它精准地描述了一种生产方式的变化。过去我们拼 UI本质上是把视觉意图手工翻译成代码结构现在 AI 把这个翻译过程压缩成了一次对话、一段描述、一次生成。你不再需要记住flex: 1和min-width: 0的配合关系也不需要背box-shadow的四层参数顺序你只需要说清楚我要一个什么样的界面。但这里有一个巨大的认知陷阱很多人以为 AI 拼 UI 就是一句话生成一个页面然后复制粘贴就完事了。实测下来这种用法只能做出 Demo做不出产品。真正高效的用法是把 AI 当成一个懂代码的 UI 实习生——你负责定义结构、约束边界、验收结果它负责快速产出第一版、批量替换重复劳动、在你卡住的时候给出备选方案。这篇文章适合三类人第一类是被 UI 细节拖慢进度的全栈开发者第二类是想用 AI 提效但不知道怎么落地的独立开发者第三类是带团队的技术负责人想搞清楚 AI 在 UI 生产链路里到底能插在哪一环。我会从为什么 AI 拼 UI 会翻车讲起拆解提示词的结构化写法、组件库的配合策略、多轮迭代的收敛技巧最后给出一套可以直接抄作业的工作流。全程不吹不黑只讲我实际跑过、踩过、修过的经验。2. 为什么你让 AI 生成的 UI 总是差点意思2.1 不是模型不行是你给的信息维度不够大多数人用 AI 生成 UI 的流程是这样的打开对话框输入帮我生成一个登录页面然后看着输出结果皱眉——布局太丑、间距不对、颜色奇怪、没有响应式。于是得出结论AI 拼 UI 不靠谱。问题出在哪出在信息维度缺失。一个真实的 UI 页面至少包含六个维度的信息布局结构几栏、什么对齐方式、组件类型按钮、输入框、卡片、表格、视觉规范主色、圆角、阴影、字体层级、交互状态默认、hover、focus、disabled、loading、响应式断点移动端、平板、桌面、技术栈约束React 还是 Vue、Tailwind 还是 CSS Modules、组件库用哪个。你只给了登录页面四个字AI 只能靠猜。它猜的默认值可能来自训练数据里最常见的风格但那个风格大概率不符合你的项目规范。所以第一版输出差点意思是必然的不是模型的问题是输入的问题。我自己的做法是把提示词当成一份微型设计规范来写。不需要写很长但六个维度里至少要说清楚四个。比如生成一个登录页面的 React 组件使用 Tailwind CSS。 布局居中卡片最大宽度 400px垂直排列。 组件标题、邮箱输入框、密码输入框、登录按钮、忘记密码链接。 视觉主色 #2563eb圆角 8px卡片阴影柔和字体用系统默认。 状态按钮有 hover 变深、disabled 变灰、loading 显示旋转图标。 响应式移动端卡片宽度 100%内边距 16px。这段提示词不到 100 字但生成结果的可用率会从 20% 提升到 70% 以上。原因很简单你把猜的空间压缩了AI 把精力放在实现上而不是决策上。2.2 组件库是 AI 拼 UI 的作弊器但很多人没用对如果你问我 AI 拼 UI 最大的提效杠杆是什么我会毫不犹豫地说组件库 AI 的组合。单独用 AI 生成原生 HTML/CSS你得到的是能看但不好维护的代码单独用组件库手写你得到的是规范但慢的产出。两者结合才是真正的效率跃迁。但这里有个坑很多人让 AI 生成 UI 时不告诉它你用的是哪个组件库或者告诉了但没给版本。结果 AI 按自己的记忆生成了一套看起来像 Ant Design 但实际 API 对不上的代码你复制进去一堆报错修 bug 的时间比手写还长。正确的做法是在提示词里明确组件库名称、版本、以及你要用的具体组件。比如使用 Ant Design 5.x 生成一个用户管理页面。 包含Table带分页、排序、筛选、Search 输入框、新增按钮、编辑/删除操作列。 Table 的 columns 定义要完整包含 dataIndex、title、key。 操作列用 Space 包裹 Button删除按钮用 Popconfirm 二次确认。这样生成的代码基本可以做到复制即用因为 AI 知道Table的columns怎么写、Popconfirm的onConfirm怎么绑。你省掉的不是打字时间而是查文档、对 API、调样式的时间。我实测过一个对比同样一个带搜索和分页的表格页面纯手写含查文档大约 40 分钟AI 组件库含微调大约 12 分钟。差距不在生成速度而在返工次数。手写是一次性写对AI 是快速生成 少量修正后者的心理负担小得多。2.3 生成只是起点收敛才是真正的功夫很多人对 AI 拼 UI 的期待是一次生成完美结果这个期待本身就是错的。AI 生成的第一版价值在于给你一个可运行的起点而不是终点。真正的功夫在收敛——通过多轮对话把第一版逐步逼近你的目标。收敛的关键是每次只改一个维度。我见过有人一次性丢给 AI 十个修改意见把按钮改蓝、间距调大、字体换掉、加个 loading、表格改成卡片、颜色再深一点、圆角小一点、阴影去掉、加个图标、移动端适配一下。结果 AI 改了三项忘了七项你还得重新说一遍。正确的收敛节奏是第一轮确认布局结构对不对。第二轮调视觉规范颜色、间距、圆角、阴影。第三轮补交互状态hover、focus、loading、disabled。第四轮做响应式适配。第五轮接真实数据、处理边界情况。每一轮只聚焦一个维度AI 的注意力不会被分散你的验收也有明确的检查点。这套节奏看起来慢实际上比一次性提十个需求然后反复返工快得多。3. 把提示词写成微型设计规范结构化输入的实操方法3.1 一个可复用的提示词骨架经过大量实测我总结出一个提示词骨架适用于绝大多数 UI 生成场景。你不需要每次都从头写把这个骨架存下来改几个关键词就能用[技术栈] 生成一个 [页面/组件名称]。 布局[整体结构如居中卡片/左右分栏/顶部导航内容区] 组件[列出所有需要的组件及其层级关系] 视觉[主色、圆角、阴影、字体、间距规范] 状态[需要哪些交互状态] 响应式[断点行为] 约束[不要做什么如不要用内联样式、不要引入额外依赖]这个骨架的核心逻辑是先定结构再定细节最后定边界。结构错了细节再美也没用边界不清AI 会自由发挥引入你不想要的依赖。举个实际例子。我要生成一个数据概览卡片提示词是这样写的使用 React Tailwind CSS 生成一个数据概览卡片组件。 布局卡片内顶部是标题和图标中间是大号数字底部是环比变化。 组件标题用 text-sm text-gray-500数字用 text-3xl font-bold变化用带箭头的 span。 视觉白色背景圆角 12px阴影 shadow-sm内边距 20px。 状态数字加载时显示骨架屏变化为正显示绿色为负显示红色。 响应式卡片在移动端占满宽度桌面端固定 280px。 约束不要引入 chart 库不要用内联样式。生成结果直接可用我只改了一个间距值。这就是结构化输入的价值。3.2 视觉规范怎么描述才不抽象好看是一个无法执行的指令。AI 不知道你说的好看是极简风、拟物风、还是玻璃拟态。你需要把好看翻译成可执行的参数。我常用的翻译对照表模糊描述可执行参数现代感圆角 8-12px阴影柔和留白充足无边框紧凑内边距 8-12px行高 1.4组件间距 8px高级感深色背景 低饱和主色字重对比明显微渐变活泼圆角 16px主色饱和度高图标带颜色专业中性色为主主色仅用于强调边框清晰这张表不是绝对的但它能帮你把感觉变成参数。AI 拿到参数后生成结果的确定性会大幅提升。还有一个技巧给参考系。你可以说风格参考 Linear 的侧边栏或类似 Notion 的表格样式。AI 的训练数据里有这些产品的视觉特征它能理解你的意图。但注意不要直接说抄某某网站而是说参考某某产品的视觉语言这样更安全也更准确。3.3 技术栈约束说清楚不要什么比要什么更重要AI 有一个坏习惯喜欢帮你加东西。你说生成一个按钮它可能给你加个动画库你说生成一个表格它可能引入一个数据处理库。这些额外依赖在 Demo 里无所谓在真实项目里就是灾难。所以提示词里一定要有约束段落。我常用的约束语句不要引入任何额外依赖只用 [已声明的库]。不要用内联样式全部用 [Tailwind/CSS Modules/styled-components]。不要生成测试代码只生成组件本身。不要用 any 类型TypeScript 类型要完整。不要用已废弃的 API按 [版本号] 的写法来。这些约束看起来是小事但能帮你省掉大量清理 AI 垃圾代码的时间。我踩过最深的坑是让 AI 生成一个日期选择器它引入了一个我没听过的日期库结果打包体积多了 200KB。从那以后我的提示词里永远有一句不要引入额外依赖。4. 组件库配合策略让 AI 说你项目的话4.1 为什么AI 组件库比AI 原生更稳原生 HTML/CSS 的问题是没有约束。AI 可以自由发挥生成一套能跑但和你项目风格完全不搭的代码。你拿到后要么全盘接受破坏一致性要么大改失去提效意义。组件库的价值在于它提供了一套强约束。按钮只有几种 variant间距只有几档 size颜色只有几个 token。AI 在这个约束空间里生成结果的确定性高得多而且天然和你的项目风格一致。我做过一个统计在同一个项目里用 AI 原生 CSS 生成的组件平均需要修改 6-8 处才能合入用 AI 组件库生成的组件平均只需要修改 2-3 处。差距主要来自风格对齐和API 正确性。4.2 不同技术栈的配合要点React Ant Design / MUI这是 AI 最熟悉的组合生成质量最高。关键是告诉 AI 版本号因为 Ant Design 4 和 5 的 API 差异很大。另外Table 的 columns、Form 的 rules 这些复杂配置最好在提示词里给出示例结构AI 会照着填。Vue Element Plus / Naive UIAI 对 Vue 3 的script setup语法掌握得不错但要注意告诉它用 Composition API 还是 Options API。Element Plus 的el-table配置项很多建议在提示词里明确你要哪些功能分页、排序、多选、展开行。React Native / Flutter这两个领域的 AI 生成质量参差不齐。React Native 相对好一些Flutter 的 Widget 嵌套层级深AI 容易生成能跑但结构混乱的代码。建议把页面拆成多个小组件分别生成再手动组装。小程序 / UniAppAI 对微信小程序的 WXML/WXSS 支持一般容易混入 Web 的写法。建议明确说这是微信小程序用 WXML 和 WXSS不要用 div 和 class 选择器。4.3 组件库文档的喂法如果你用的组件库比较小众AI 可能不熟悉。这时候可以把组件库的文档片段贴进提示词。但不要贴整页文档太长会稀释注意力。我的做法是只贴你要用的那个组件的 API 签名和示例。比如你要用某个表格组件就贴组件名DataTable Props - columns: Array{ key, title, width?, render? } - data: ArrayRecordstring, any - pagination: { page, pageSize, total } - onPageChange: (page: number) void 示例 DataTable columns{cols} data{list} pagination{pg} onPageChange{handlePage} /这样 AI 就知道该怎么写了不会瞎猜 API。5. 多轮迭代的收敛技巧从能看到能用5.1 第一轮只验收结构不纠结细节第一轮生成后你的验收标准只有一个布局结构对不对。是不是你要的几栏组件位置对不对层级关系清不清楚如果结构不对直接说把左侧栏改成顶部导航或把卡片改成两列网格不要在这个阶段纠结颜色和间距。我见过很多人第一轮就开始抠细节这个按钮颜色不对这个间距大了 2px。结果改完细节发现结构要推倒重来前面的修改全白费。结构是骨架细节是皮肤先立骨架再贴皮肤。5.2 第二轮用对比描述调视觉调视觉时不要只说改好看点要用对比描述把主色从蓝色改成深灰参考 Linear 的侧边栏。间距太紧了整体放大 1.5 倍。阴影太重了改成几乎看不见的那种。圆角从 4px 改成 12px更柔和一些。对比描述的好处是AI 知道从什么改成什么而不是改成某个模糊的目标。这能大幅减少来回次数。5.3 第三轮补状态别等测试来提交互状态是最容易被忽略的部分。AI 默认生成的组件通常只有默认态没有 hover、focus、disabled、loading、error。这些状态如果不在生成阶段补上后面测试提 bug 时你还得回来改。我的做法是在第三轮专门说给所有可交互元素补上 hover、focus、disabled 状态按钮补 loading 状态输入框补 error 状态。一次性补齐比零散补效率高得多。5.4 第四轮响应式适配的断点思维响应式不要笼统地说适配移动端要按断点说移动端 768px单列布局卡片占满宽度导航折叠成汉堡菜单。平板768-1024px两列布局侧边栏收窄。桌面 1024px三列布局侧边栏展开。按断点描述AI 生成的媒体查询才准确。我实测过按断点描述的生成结果移动端可用率比笼统描述高出一倍以上。5.5 第五轮接真实数据时的边界处理最后一轮是把 mock 数据换成真实数据。这时候要提醒 AI 处理边界情况数据为空时显示什么加载失败时显示什么数据量过大时怎么分页或虚拟滚动这些边界如果不在提示词里说AI 默认不处理上线后就是 bug。6. 那些没人告诉你但一定会踩的坑6.1 AI 生成的代码看起来对但跑起来错这是最危险的坑。AI 生成的代码语法正确、结构清晰但可能用了不存在的 API、传了错误的参数类型、或者逻辑上有微妙的问题。比如它可能生成一个onClick{handleClick()}立即执行而不是传引用或者一个useEffect缺少依赖数组。我的应对方法是生成后先跑一遍再读一遍关键逻辑。不要因为看起来对就直接合入。特别是事件绑定、状态更新、异步请求这三类代码一定要逐行检查。6.2 样式冲突AI 不知道你的全局样式AI 生成组件时不知道你项目里有没有全局样式、有没有 CSS reset、有没有主题变量。它可能用了一个和你全局样式冲突的类名或者覆盖了你精心调过的间距。应对方法在提示词里说明你的全局约定。比如项目使用 Tailwind已配置自定义主题主色是 primary-500不要用硬编码颜色。或者项目有全局 CSS reset不要重复设置 margin: 0。6.3 可访问性a11y被系统性忽略AI 生成的 UI 几乎不考虑可访问性按钮没有aria-label图片没有alt表单没有label关联键盘导航不支持。这些在 Demo 里无所谓在产品里是硬伤。如果你在意 a11y在提示词里加一句所有交互元素要有 aria-label表单元素要有 label 关联支持键盘 Tab 导航。AI 会照做。虽然不能做到完美但比完全不做好得多。6.4 性能陷阱AI 喜欢过度实现AI 有时候会炫技给你加个动画、加个过渡、加个懒加载、加个 memo。这些在单个组件里没问题但在长列表或复杂页面里可能造成性能问题。比如它可能给一个 1000 行的表格每一行都加useMemo反而增加开销。应对方法在提示词里说不要做性能优化保持代码简单直接。需要优化时你再手动加。6.5 版本漂移AI 的记忆可能过时AI 的训练数据有截止日期它可能不知道你用的库的最新版本。比如它可能按 React 17 的写法生成代码而你用的是 React 18或者按 Tailwind 2 的类名生成而你用的是 Tailwind 3。应对方法在提示词里明确版本号并且在生成后检查是否有已废弃的 API。如果发现版本不对直接说用 React 18 的 createRoot 写法重写或用 Tailwind 3 的类名。7. 一套可以直接抄的 AI 拼 UI 工作流7.1 工作流全景把前面所有内容串起来我的完整工作流是这样的定义页面用一句话说清楚这个页面是干什么的。写提示词按技术栈 布局 组件 视觉 状态 响应式 约束七段式写。生成第一版只验收结构不纠结细节。收敛视觉用对比描述调颜色、间距、圆角、阴影。补状态一次性补齐 hover、focus、disabled、loading、error。做响应式按断点描述生成媒体查询。接数据替换 mock处理空态、错误态、加载态。检查代码跑一遍读关键逻辑检查版本和依赖。合入项目微调后提交记录这次提示词供下次复用。这套流程跑熟之后一个中等复杂度的页面比如带搜索、分页、增删改查的管理页从零到可提交大约 20-30 分钟。对比纯手写的 2-3 小时提效是实打实的。7.2 提示词模板库的积累提效的关键不是每次重新写提示词而是积累模板库。我按页面类型建了几个模板列表页模板表格 搜索 分页 操作列表单页模板多字段 校验 提交 重置详情页模板描述列表 关联表格 操作按钮仪表盘模板统计卡片 图表 最近动态登录/注册模板居中卡片 表单 第三方登录每个模板存好下次遇到同类页面改几个字段就能用。这是复利效应——你积累的模板越多新页面的生成速度越快。7.3 团队协作时的注意事项如果你在团队里推广这套工作流有几个点要注意统一提示词规范不然每个人生成的代码风格不一致review 成本反而增加。统一组件库版本AI 生成时版本不一致合入时冲突不断。建立 review 清单AI 生成的代码要重点检查事件绑定、状态更新、异步逻辑、a11y。记录踩坑案例把团队踩过的坑整理成文档新人直接看不用重复踩。8. 我对 AI 拼 UI 的真实看法用了大半年 AI 拼 UI我的结论是它不会取代 UI 开发者但会取代只会拼 UI的开发者。那些把 80% 时间花在翻译设计稿上的人价值会被压缩那些能定义结构、约束边界、验收结果、处理复杂交互的人价值会被放大。AI 最擅长的是从 0 到 0.7——快速产出可运行的初版。但从 0.7 到 1 的那段路仍然需要人来走处理边界情况、优化性能、保证可访问性、对齐业务逻辑。这段路 AI 目前走不好也不应该由它来走。我现在的习惯是能用 AI 生成的部分绝不手写需要判断和决策的部分绝不交给 AI。这个边界划清楚之后效率提升是自然的焦虑反而减少了。因为你知道自己在做什么也知道 AI 在帮你做什么。最后分享一个我最近的小发现把 AI 生成的组件和手写的组件放在一起对比前者往往在规范性上更好因为 AI 严格按组件库 API 来后者往往在贴合业务上更好因为你知道业务需要什么。最好的做法是用 AI 生成骨架和规范部分用手写补业务逻辑和特殊交互。两者结合才是当前阶段的最优解。