AI生成UI实战：从手拼页面到提示词驱动的效率革命

上个月同事找我要一个设置页的 UI我打开平时常用的那个对话窗口把需求跟参数直接丢给 AI十分钟后截图发过去他第一反应是你什么时候偷偷装了组件库。我说不是组件库是我是真的不想再手拼 UI 了。做前端这行的谁没被拼 UI折磨过。所谓拼 UI就是把设计稿还原成页面的过程量间距、调颜色、对字号、改圆角一个像素一个像素地磨。这东西本身不复杂但极其消耗时间和耐心尤其在项目多、迭代快、设计稿天天变的情况下拼 UI 能占掉一个前端工程师一半以上的工作量。而 AI 出现之后这类工作的生产方式发生了根本变化我不再是画图的人而是提需求的人。这篇文章不聊玄乎的 AI 理论也不放那种看起来很高端但根本跑不通的 Demo。我会把自己过去大半年用 AI 替代手拼 UI 的真实工作流、提示词模板、踩过的坑、以及仍然坚持手写的场景全部摊开来讲。适合谁被 UI 还原折磨的前端工程师、独立开发者、以及所有想用 AI 提效但不知道从哪下手的朋友。看完你至少能照着我的思路把自己手头的第一个页面用 AI 跑通。1. 从手写布局到AI出稿我过去半年工作流的真实变化1.1 以前是怎么拼 UI 的在 AI 还没进入我工作流之前一个典型设置页的还原流程是这样的先开设计稿把页面拆成结构树再根据结构写 HTML 骨架接着写 CSS 把布局撑出来最后处理各种状态hover、focus、disabled、空数据。一个 10 个控件的设置页顺利的话小半天不顺利的话——比如设计稿里有个不规则的 switch 开关、或者需要适配多种屏幕——那就说不准了。最烦人的是那些看起来简单但做起来莫名耗时的东西。比如一个输入框的校验提示要在错误时变红、在输入时消失、在失焦时重新出现还要配合不同的布局位置。写逻辑不难但每次都写一遍真的很烦。再比如列表页的加载状态、空状态、错误状态这三件套每新建一个页面就得重来一次。你说能用组件库能用但先得找到合适的组件、改它的 props、再适配当前设计稿的视觉风格未必比手写省多少。我试过用各种方式来加速搭自己的组件库、写代码片段插件、搞可视化搭建工具。都有效但都有一个共同问题——它们只能加速已知的UI 形态。遇到新页面、新交互你还是得从零开始。AI 出现之前我最深的感受是拼 UI 的瓶颈不是不会写而是写的量太大纯粹是体力和耐心的消耗。1.2 现在是怎么出 UI 的现在我的流程变成了这样打开对话窗口把需求描述清楚——页面类型、包含哪些区块、大致布局、视觉风格、技术栈、组件库——然后 AI 直接把代码生成出来。我拿到代码后跑起来看效果哪里不满意就继续提修改意见几乎不再从零手写布局。举一个真实的例子。上周要做一个通知中心页面包含通知列表、分类筛选、全部已读按钮、单条删除这四件事。我以前的做法是找设计稿、量间距、写组件前后至少三小时。现在我在对话里写了一段话用 React Tailwind 写一个通知中心页面顶部是分类 tab全部/未读/重要下面是用列表渲染的通知条目每一条有图标、标题、时间、摘要鼠标悬停显示删除按钮右上角有一个已读全部按钮风格参考 iOS 设置页浅色模式优先。 AI 大概用了四十秒生成一个可以直接跑的页面。我再根据实际视觉效果提了两轮微调总共不到半小时。这个变化最关键的并不是AI 写了代码而是我的角色变了我不用再关心这个布局是 flex 还是 grid、这个间距是 12px 还是 16px、这个按钮用不用圆角——这些事 AI 会按我最常用的风格默认处理。我只需要告诉它要什么和哪里不对。UI 这件事从体力活变成了验收活。1.3 实际省下的时间账要算清楚有人可能会说AI 生成的东西又不完美改来改去跟手写差不多。这话有道理但前提是你不会用。我用半年时间记录过一批页面从生成到上线的时间成本拿典型页面来对比页面类型手写还原平均耗时AI 生成修改平均耗时主要时间花在哪表格管理页含筛选/分页/操作列4~6 小时1.5~2 小时微调表格列宽、对齐、状态提示表单页10 个字段含校验3~4 小时1~1.5 小时校验规则表述、错误状态样式设置页分组/开关/弹窗2~3 小时40~60 分钟弹窗动画、分组间距仪表盘图表卡片布局5~7 小时2~3 小时图表配置、响应式布局整体算下来能省 60% 以上的时间。但有个前提——你得会描述需求并且会迭代。这就引出我在下一节要讲的内容为什么直接用 AI 拼 UI第一步最容易翻车。2. AI生成UI的第一课整页复制粘贴是最蠢的用法2.1 第一次用 AI 写界面的翻车现场我第一次尝试让 AI 生成 UI是在一个内部管理系统的详情页。当时我的操作朴素得可笑把设计稿截图传给 AI让它照着写一个页面然后直接把返回的代码整个贴进项目里。结果是什么页面确实出来了跟设计稿八分像但一跑就露馅设计稿里用的是一个自定义的日期范围选择器AI 默认给我生成了两个独立的原生输入框表格列的宽度完全没有按内容自适应数字多的列挤成一团最严重的是整个页面的状态管理是拿useState堆的十几个状态散落各处跟项目里已有的redux架构完全没法融合。改这些东西的时间加起来比手写还长。那一次我差点得出AI 拼 UI 就是个噱头的结论。后来我反应过来问题不在 AI 的能力而在我给了它一个无法执行的任务一张模糊的设计稿截图 一句照着写等于让一个刚入职的实习生在一无所知的情况下独立完成一个页面——不出问题才怪。2.2 为什么整页生成的代码往往没法直接用后来我总结整页生成之所以不靠谱核心原因有三个。第一** UI 代码不是独立的它要嵌进工程体系。** 设计稿上看到的是一个页面但实际项目中这个页面要依赖路由、状态管理、接口请求层、公共组件、全局主题变量。AI 不知道这些它会默认生成一套孤立可运行的代码搬进工程里必然各种不兼容。第二** 视觉细节的优先级被 AI 搞反了。** AI 在生成整页时为了像会把注意力放在背景色、字体、图标这些视觉元素上反而忽略了页面真正的骨架——数据结构、交互逻辑、边界状态。结果就是你拿到一个看起来还行但交互一塌糊涂的壳子。第三** 修改的粒度太粗。** 整页代码是一个耦合的整体你想要改某一个局部行为往往要牵动一大片代码。比如你想让表格某一列支持排序AI 之前生成的简单table就要重构。在这种代码上迭代成本远高于在拆散的组件上迭代。2.3 正确的打开方式让 AI 做组件而不是做整页所以我现在的用法彻底变了** 永远不让 AI 一次性生成整页而是按组件粒度去生成。** 一个页面拆成导航栏、筛选区、表格、弹窗、状态提示几个部分每次对话只做一件事做完一个验收一个通过之后再让 AI 组装。这样做的逻辑很简单组件是 UI 的最小交付单元它的职责边界清晰、依赖可控、容易修改。一个筛选区组件我只需要描述清楚有哪些筛选项、什么类型的控件、布局方向AI 就能生成一个相对独立、可复用、容易嵌入的代码块。就算它生成得不够好我改起来也只是改一个局部不会影响页面其他地方。再进一步我还会把项目里已有的设计规范喂给 AI主色调是什么、圆角半径多大、字体层级怎么分、常用组件长什么样。这些信息让 AI 生成的内容从一开始就跟工程体系对齐而不是生成之后再花力气去套。有人会觉得按组件生成很慢一次才写一个按钮、一个表格。但实际跑下来你会发现按组件生成的迭代速度是加法整页生成的返工速度是乘法。一个组件生成失败重新生成的成本是几分钟一个整页生成失败修 bug 的成本是几个小时。这笔账算一次就明白。3. 一套我自己打磨的AI UI提示词模板3.1 先说清楚你要什么角色、场景、约束很多人用 AI 生成 UI 效果差最大的原因是描述太简单。你给一句写个登录框AI 给你一个默认的、谁都能用的登录框然后你嫌它丑、嫌它没有特色、嫌它不符合业务场景——但你压根没告诉它这些约束。我把自己的提示词总结成一个公式差不多是五要素** 角色**AI 你是谁你要以什么身份来做这件事。比如你是一名资深前端工程师精通 Ant Design 的二次封装。** 场景**这个 UI 用在哪给谁用。比如这是企业内部工单系统的筛选区使用用户是客服人员需要快速操作不能有花哨交互。** 技术约束**语言、框架、组件库、样式方案。比如使用 React 18 TypeScript Tailwind CSS组件样式不要引入额外依赖。** 功能明细**把要的元素、交互、状态全部列出来宁可多列别少列。** 风格参考**给一个明确的视觉方向。最好是参考某某产品的设置页风格而不是好看一点。这里的关键是约束优先。AI 生成代码的自由度很大你给它的约束越多它越能贴着你的需求走。反过来你只给一句写个页面它只能根据概率生成一个最像页面的页面这种东西往往恰恰是最不适合你项目的。3.2 参考结构给 AI半成品比从零开始更高效还有一个提升生成质量最明显的技巧** 不要从零开始要把你已有的代码片段或结构骨架丢给它。** 我经常这么干项目里有一个已经很成熟的列表页组件我新页面要做一个类似的弹窗就把那个列表页的代码贴给 AI告诉它参照这个结构改成弹窗版字段换成 XXX布局改为两列。这种半成品引导的效果远好于从零描述原因也好理解AI 看到了你工程的真实写法、你的命名习惯、你的组件组织方式它生成的东西天然就跟你项目风格一致。这比任何口号式的保持一致都管用。我再提供一个可以直接抄的基础模板以 React 组件为例你是一名资深 React 前端工程师。请帮我生成一个用户选择器组件。 场景用于后台管理系统的表单中用户点击后弹出对话框按姓名/部门搜索用户支持单选。 技术约束React 18 TypeScript Ant Design 5禁止引入额外 UI 库样式使用 CSS Modules。 功能明细 1. 触发器是一个 Input 框只读显示已选用户姓名带清除按钮 2. 点击后打开对话框左侧是搜索表单姓名输入框、部门选择器右侧是用户列表 3. 用户列表使用 antd Table列包含姓名、部门、工号 4. 点击某一行选中并高亮底部确定按钮确认后回填到 Input 5. 打开状态下再次点击触发器应关闭对话框。 风格参考贴近 Ant Design 默认风格但删减边框使用浅灰背景区分内容区。 请输出完整组件代码并给出注释说明关键 props 类型。这种提示词生成的组件拿到项目里基本能直接用。注意工作量的分配大概是写提示词占三分钟AI 生成三十秒跑起来验收加修改十分钟。前面的三分钟决定了后面的十分钟值不值。3.3 迭代闭环用截图反喂而不是纯文字描述AI 生成 UI 的第一版很少是完美收官迭代是常态。但迭代的方式有讲究。早期我用纯文字提修改意见表格太挤了按钮看起来不对结果 AI 很难抓住重点来回几次就烦了。后来我换成截图反喂把渲染出来的页面截图发给 AI用图文字圈注的方式提要求。做法是本地跑起页面后用浏览器的截图工具或者直接按系统截图把视觉问题框出来再附上一句说明比如右上角两个按钮的间距太小与其他区域的间距不统一或者搜索框宽度应该撑满整个筛选区现在只占了一半。AI 理解图片的能力已经很强截图反喂的命中率远超纯文字。这里有一个注意点截图反喂的时候最好把** 对应的代码片段也贴带上**。AI 虽然能看图但它不知道截图对应你工程里的哪段代码。你把组件代码贴给它它才能真正定位并修改。我自己的习惯是截图 相关组件代码 一句话的问题描述三件套一起丢过去基本一轮就能改对。另外还有个小技巧交给 AI 改代码前先确认问题属于视觉还是逻辑。视觉问题间距、颜色、对齐AI 改起来又快又准逻辑问题事件触发时机不对、数据流转不对则需要你把上下文描述得更细甚至把相关的数据流代码一起贴进去。把这两类分开提迭代效率会明显高很多。4. 从生成代码到接管测试UI 自动化的进阶玩法4.1 让 AI 补组件测试用例当 UI 生成稳定之后我开始思考一件事既然 AI 把组件写得快那谁能帮我验证它写得对答案是 AI 自己。以前我写完一个组件至少得补几个基础测试用例正常渲染、空数据、加载中、交互事件。但手写这些用例很累而且很多前端工程师的习惯是线上出 bug 了才想起来补测试。现在我的做法是AI 生成组件的同时让它连测试用例一起生成。我现在用的提示词会在末尾加一句请同时为该组件生成 Vitest React Testing Library 的测试用例覆盖正常渲染、空列表、搜索触发、选中回填、重复打开对话框这五个场景。这个附加要求几乎不增加成本但效果非常好。AI 生成的测试用例可能不够完备但作为基础覆盖绰绰有余我再花五分钟补充或修改边界场景即可。4.2 用 AI 做 UI 走查与一致性检查这个玩法是我最近才跑通的强烈推荐给团队里有 UI 规范的人。以前做视觉走查靠人肉看这个页面的主色对不对、字体是不是用的标准字号、按钮圆角是不是统一。人肉走查的问题在于你的眼睛会被整体效果不错欺骗自动忽略那些细小的不一致——等上线之后设计师一截图问题全暴露了。我现在会让 AI 扮演视觉审查员。把项目的设计变量文件或者主题配置丢给 AI再把页面截图发过去让它对照检查主色是否与规范一致、间距是否符合 4px 栅格体系、字体字号层级是否正确、图标风格是否统一。AI 在这种规则明确的检查上表现得相当不错因为它不会累不会审美疲劳逻辑上跟你的规范文档完全对齐。实操的时候有个细节给 AI 的规范文档越结构化越好。不要丢一大段散文让它找重点而是把关键规则列成清单比如主色 #1677ff辅助色 #52c41a间距基准 8px圆角 4px/8px/12px 三档这类格式。规则越明确它检查得越准。4.3 多 AI 协作生成端与审查端分开如果你把 AI 既当代码生成器又当代码审查器很快会发现一个问题生成方和审查方是同一个模型它对自己的产出天然有护短倾向。你让它审查自己写的代码它很可能说这个实现是合理的。因为它的目标是尽量满足用户、给出正面反馈而不是挑自己的毛病。所以我后来的做法是把生成和审查拆成两个独立的对话窗口。一个窗口专门用来生成组件代码另一个窗口专门用来审查我给它的代码和需求挑问题。就算底层模型是同一个只要我把上下文分开、让审查窗口只看需求描述和代码它的挑错能力也会明显好于同一个对话里的自查。这里更像一种心理技巧但实际用下来效果确实不同。审查窗口我会加一句很直接的话你不需要修改代码只需要指出潜在的问题别客气乱提也行。它给的反馈往往能覆盖我没想到的边界情况。有条件的话也可以尝试让审查端用不同的模型跑一遍。代码生成和代码审查对模型的偏好其实不一样生成端要会发挥、懂审美审查端要严谨、爱挑刺。两个模型配合使用比一个模型干到底要稳得多。5. 边界感这些 UI 场景我依然选择手写5.1 高度定制交互与动效AI 生成 UI 再强有一个领域我还是坚持手写高度定制的交互动效。比如一个复杂的图表联动、一个多阶段动画、一个需要精确控制时序的过渡效果。原因不是 AI 写不出来而是动效这种东西的调试成本极高。AI 生成的动画代码经常看起来对跑起来不对——缓动函数差一点、触发条件不对整个手感就完全变了。而修动效需要反复调参、反复看效果这种反馈循环里最快的操作方式还是手写代码因为你能精确控制每一帧的行为。AI 能帮你搭框架但最后一公里的手感调优我选择人来做。比如一个抽屉弹窗AI 生成的代码可能用transition: transform 0.3s一把梭但真要做到跟设计稿一致你可能需要分两步先 fade 再 slide、内容区和遮罩层用不同的时长和缓动。这类细节描述给 AI它也能改但来回沟通的功夫我自己已经写完了。所以这些场景我的选择是让 AI 提供参考思路手写最终实现。5.2 数据密集型页面与性能敏感场景第二类我会手写的是数据密集型表格、长列表、实时更新的看板这类对性能要求高的页面。AI 默认生成的数据展示代码非常天真map一把梭数据多的时候也不做虚拟滚动、不做记忆化、不做分片渲染。你让它优化它也会给方案但性能优化这种东西没办法靠描述来保证必须靠实际的性能分析和 profile 数据说话。所以我在这类页面的做法是骨架和样式可以交给 AI但数据逻辑、虚拟滚动、缓存策略、批量更新这些核心路径必须自己写。说个直观的数字对比一个有 500 行数据的表格AI 生成的默认写法在弱机上切换筛选可能有 200ms 的卡顿手写虚拟滚动之后能稳定在 16ms 以内。这种数量级的差距AI 靠提示词是很难消除的因为它不了解你的实际数据量级和运行环境。5.3 团队长期维护的组件规范最后这个边界属于组织层面的一个团队要长期维护的公共组件规范我建议一定要人控不要放权给 AI。一个按钮组件看起来简单但它背后是团队的设计语言、无障碍标准、兼容性要求、各业务线使用约定的汇集。AI 可以很轻松地生成一个看起来不错的按钮但它无法理解为什么这个团队把 primary 按钮的左间距定成 16px——这个决策背后可能是某个特殊业务的妥协。如果让 AI 随意演进这类基础组件规范会很快失控。我的经验是AI 适合做消耗型的 UI——业务页面、一次性原型、内部工具这些需要快速交付、用完即走的东西不适合做积累型的 UI——公共组件库、设计系统、核心页面模板这些需要长期演进、跨团队协作的东西。前者让 AI 放开了跑后者老老实实走 code review。分清这两类你既能享受 AI 的效率又不至于被 AI 的平均化审美拖累团队沉淀。说实话从完全不信任 AI 拼 UI到现在凡是新页面先让 AI 出一版这个过程花了我不短时间。最早的时候我也觉得 AI 写出来的东西差点意思但后来我意识到关键不是让 AI 一步到位而是把任务拆到合适的颗粒度、给出足够清晰的约束、用迭代的方式逼近目标。现在我的日常工作里大概 60% 的页面级 UI 是 AI 起稿、我负责验收和修改的剩下 40% 涉及复杂交互和数据安全的部分我自己手写。比例不重要重要的是你把时间花在了真正需要人的地方。拼 UI 最消耗人的那部分已经被我彻底外包出去了之后每次看到永不重复造轮子之类的话我都会想现在连轮子都可以让 AI 先画个草图了我只需要说清楚我要去哪个方向。