自从有了 AI我就再也不想拼 UI 了。这话不是标题党是我最近半年的真实状态。以前我最怕接到的需求叫“照着稿子还原界面”听起来简单做起来全是功夫活。拼 UI 拼的从来不是最后那一眼的效果而是过程中大量重复的决策这块区域该用什么容器这两个元素之间是 12px 还是 16pxhover 时是变颜色还是加阴影空数据时页面该长什么样……单个决策都不难难的是它们堆在一起一上午抬头低头页面上还是那几个表单光标还停在某个像素上。现在情况完全变了AI 能承担其中很大一部分我只需要给它一个清晰的描述它先给我一版能看的界面我再按工程标准去改。这篇就把我自己从“手写 UI”切换到“AI 辅助生成 UI”的工作流和踩坑记录盘一遍给正在纠结要不要让 AI 接管界面开发的同行做个参考。不吹 AI 玄学只说真实落地时怎么用好它。1. 为什么我对“拼 UI”这件事彻底改观了1.1 拼 UI 到底在拼什么很多非前端同事以为拼 UI 就是“把图片放到页面里”只有实际写页面的人才清楚这活儿最耗心力的环节不是创意而是持续输出大量不出错的中等难度决策。每次写一个列表页要决定表头是否固定、操作列在窄屏幕下是收进抽屉还是变成图标、多行文本溢出是省略还是换行、校验错误提示应该出现在字段下方还是弹窗统一提示。以前我从早上开始调一个表单页到下午可能还没把校验状态全部铺完。等到晚上再看整屏的间距还是歪的。这不是能力问题是量的问题。交互状态多、边界条件多、设备宽度多任何一个都值得花时间但它们加在一起就会占据一天里最清醒、最专注的那段时间。现在回想拼 UI 的表面工作是排版和配色底层其实是“把设计规则稳定地翻译成代码”这恰恰是最适合交给 AI 的部分。它虽然做不到优秀设计师的审美高度但它能在几秒内给出一个结构完整、状态齐全的初稿把我从那些“不需要创造力但必须耗时”的工作里解放出来。1.2 AI 带来的最大改变不是“自动生成”而是“省掉低效沟通”我一直想纠正一个误区AI 帮你生成界面真正的价值不是省掉写 HTML 和 CSS 的那几个小时而是省掉了你和“一个空白文档”之间的大量来回。以前写页面我总得先把结构想清楚才敢动手因为从零生成界面实在太费劲。现在我会先给 AI 一段口语化描述哪怕描述里带有很多冗余信息它也能先给一个可运行的结果。这个结果通常不完美但至少是一个能讨论的实物。我可以在实物上改而不是从零开始脑补。用做菜类比以前是从洗菜切菜开始配料还要自己备现在是叫一份预制菜你只需要调味、装盘、确认火候。听起来简单实际上这改变了你做 UI 时最耗心力的那个环节——从“凭空生成”变成了“增量修改”。增量修改的心理负担比空白页小得太多。看到一个不完美但能跑的页面你心里想的不是“从哪开始”而是“这里挪一下、那里换一下”。状态完全不同。这也是我坚持在团队里推 AI 辅助 UI 的原因它降低了启动门槛让那些不怎么爱写样式的后端同事也愿意打开编辑器改两笔。1.3 适合用 AI 做 UI 的几类场景不是所有 UI 都适合让 AI 来生成。我试过几类场景整理出的实际感受可以看这张表场景适合程度我的实际体感内部后台较高结构要求稳定风格不重要AI 能快速生成大量表单、表格、筛选器营销活动页中等视觉要和品牌强绑定需要反复调提示词AI 容易做“飞了”移动端页面较高描述清楚平台规范后生成结果比 PC 端更稳导航模式固定复杂交互动效低涉及时间曲线、手势冲突、状态流转AI 生成的逻辑仍然很弱组件库建设中等适合生成单个组件示例但组件一致性需要自己维护补充一个适合场景产品还没定稿时的原型验证。当设计还在讨论信息架构时AI 能帮你把方案快速变成可点击的假页面比设计师一张张切图再沟通要顺畅很多。但涉及公司品牌识别体系、无障碍合规这类地方我建议别全交给 AI。适合与否的关键是看你是否愿意在结果之上做一轮专业的“校准”。愿意的话AI 能省一半时间不愿意的话后面返工带来的痛苦会更大。AI 更像一个快速出初稿的实习生它的产出质量取决于你愿意投入多少上下文和验收精力。2. 我现在的 AI 辅助 UI 工作流长什么样2.1 先有“描述层级”再谈生成用 AI 做 UI 最忌讳一句话“帮我做一个好看的登录页。”AI 不是不能理解“好看”但每个人对“好看”的定义差别太大。你眼里的高级感可能是极简留白AI 默认出来的可能是渐变背景加圆角大按钮。我在实际操作中把需求拆成四个层级分别是角色、结构、风格、约束。角色你希望 AI 充当什么类型的工程师。“你是熟悉 Vue3 和 Element Plus 的资深前端”这种设定会让输出包含正确的组件用法而不是手写一堆自定义 div。结构页面有哪些区块哪个是核心哪些信息需要优先呈现。结构不说清楚AI 只会给一个平均值哪个区块都不出彩。风格是偏 B 端的严谨感还是偏 C 端的活泼感最好用名词来锚定比如“类似管理后台的清爽布局间距遵循 8px 的倍数颜色不超过两个主色”。约束框架版本、组件库、不需要什么功能、使用什么语言、是否要响应式。约束给得越死后期返工越少。四层结构最大的好处是让我不再反复改提示词。以前我跟 AI 对话总是“再偏左一点、字体再小一点”这种反馈对 AI 来说是折磨因为每次都是微调但方向始终含糊。现在我会先定义清楚约束生成结果即使不完美大的方向也基本不会歪。2.2 一份可以直接抄走的提示词模板给你一份我实测过很多次的提示词模板可以直接复制改参数你是熟悉[框架/组件库]的前端工程师。 请生成[页面类型]的完整代码要求如下 1. 页面结构划分[主要区块及顺序] 2. 视觉风格[风格关键词 颜色偏好 间距偏好] 3. 交互状态需要包含[悬停/加载/空数据/错误]等状态 4. 技术约束使用[组件库]版本[版本号]不使用[不想要的东西] 5. 输出要求返回可运行的[文件类型]先展示结构再写样式这里多说一句“交互状态”这一项很多人会漏掉。AI 默认会把页面生成成“理想状态”有数据、无错误、宽度刚刚好。可实际页面里空状态、加载中、报错、权限不足才是开发大头。你提前在提示词里点出来出来的代码实用度会立刻提升一大截。如果你想要更细的视觉控制可以继续加规则- 间距一律使用 4px 的倍数 - 文字层级不超过 3 级 - 卡片圆角统一为 8px阴影统一使用同一颜色变量 - 所有按钮需要有 loading 状态和禁用态AI 一旦接受了这些像代码规范一样的约束它生成的 UI 就不会有“东拼西凑”的感觉反而像一个有强迫症的同事做出来的。2.3 工具组合生成初稿、转代码、再落地我现在常用的链路是一套组合不是单一模型。首先生成视觉初稿这一步我用文本生成设计稿或者图像模型先跑出几个方向主要解决“定风格”的问题然后把选中的初稿交给代码生成模型转成前端代码最后再进到工程里落地把里头的组件替换成项目自己的封装。这里面有个常见误区指望一个模型从需求描述一步到位生成可上线代码。实际做下来视觉模型和代码模型往往要接力。比如开源社区里已经有很多图像模型可以直接生成界面设计稿你完全可以当它们是界面方案生成器。虽然生成的图很多时候到不了“直接上线”的精度但当灵感生成器和风格探索工具效率很高。让我再把“多 AI 协作”这个思路展开说一下。现在 AI 圈子很爱聊这个概念我的理解非常简单有意识地让不同 AI 担任不同角色。一个出方案一个做代码 Review一个跑自动化回归测试。这样比你反复让同一个模型无限改稿要稳定得多。后面我会单独聊这块具体怎么排。2.4 用关键词和约束控制 UI 细节除了大方向细节控制也很重要。我常用几个“关键词级”的约束放在提示词末尾用来避免 AI 跑偏使用 8px 栅格所有可点击元素至少 40px 触控区域数据为空时展示占位图并给出引导按钮文本超长时用省略号而不是换行撑破卡片主要按钮只有一个其他都是次要操作这些约束本质上是把团队的设计规范直接喂给 AI。你给它的规范越多它生成的页面越能融入现有项目。它的默认输出是“没有规范时的平均方案”你的约束会把平均值拉高到团队的水准线上。3. 真实工程里的 AI 生成代码怎么落地3.1 从“能看”到“能用”中间隔着真实数据和状态AI 生成的页面单独打开浏览器截图看很漂亮但一旦放到真实项目里就很容易露馅。真实环境里有长文本、超长超小的实时数据、强弱网切换、用户权限差异这些极端情况 AI 生成的稿子通常只处理了“正常态”。所以我接到 AI 产物的第一件事不是检查设计细节而是先往里面灌真实数据把列表条数拉大把文字长度拉长把网络切成慢速看加载状态把接口返回改成空数组或超大数值。这个步骤我给它起了个外号叫“脏数据测试”也是我用 AI 做 UI 之后养成的习惯。举几个真实例子。AI 生成一个订单列表正常时排得很整齐一旦字段变多表格直接挤爆AI 设计的用户头像默认是正方形真实用户上传了偏长图片后如果没写 object-fit头像就会变形扭曲AI 生成的卡片布局在标题只有四个字时很好看换成一条四十个字的通知标题整个卡片比例就崩了。这些问题提示词里不一定管用但“脏数据测试”能立刻暴露。我这样看待 AI 生成界面的本质AI 擅长搭“理想模型”而工程擅长的就是处理“不理想”。你在落地时一定要把 AI 当成一个只会画标准图纸的人而你才是要在图纸旁边标注各种特殊情况的人。3.2 组件库和框架版本怎么和 AI 生成物对齐成也组件库败也组件库。AI 在生成 UI 代码时如果没约束组件库它很多时候会手写一堆 div 和 CSS 覆盖上去。这套代码在简短的 demo 里没问题但进到工程里就是祸根主题配色没法全局切换、暗黑模式支持不了、后续想把按钮样式统一改一遍得全站通查。因此在提示词阶段就应该把组件库名称、版本、甚至常用组件的 props 都喂给 AI。我在工程里会先把自己的组件封装层暴露给 AI给它几个使用范例让它照着写。如果项目用的是 Element Plus就在提示词里说按钮统一使用 el-button禁用态用 disabled 属性loading 状态用 loading 属性不要自己实现一个 button。这样生成的代码落到工程里几乎不需要大改。这里藏着一个核心心得AI 就像一个新人同事它能拿到多清晰的代码规范它产出的代码就能让你的后续少出多少问题。3.3 性能与卡顿AI 生成的页面为什么会变慢很多人在 AI 写 UI 后没有测性能页面一上线就卡。我排查过不少这类问题AI 生成的界面常见卡顿原因有三个。第一个是样式冗余。AI 会生成大量重复的 CSS 变量、大量无效的 margin 和 padding、不统一的阴影值视觉上差不多但浏览器需要花费额外时间去做样式计算。第二个是渲染负担。AI 生成的首屏内容里塞满了图片和动画在开发环境里看很丰富实际用户在低端手机上打开就会卡。第三个是布局抖动。页面里频繁触发布局计算尤其是数据列表用计算宽度或者 flex 嵌套过深时滚动起来很不流畅。我自己就遇到过一次生成的卡片列表一页 48 张卡片每张都加 box-shadow、圆角、背景渐变视觉上确实好看但低端设备上滚动直接掉帧。后来我把阴影和渐变样式拍平把卡片列表改成虚拟滚动才把问题解决。所以我的建议是AI 生成的 UI 上线前必须做一次“性能体检”最简单的办法是打开浏览器开发者工具看 Performance 时间线或者直接上真机滚动几屏看体感。发现问题也不用慌大多数卡顿都出在过度装饰上删掉多余样式就能恢复。3.4 交互状态和无障碍AI 最容易漏的部分悬停反馈、键盘导航、焦点样式、屏幕阅读器朗读顺序这些 AI 生成的代码常常整块缺失。提示词里提一句“包含交互状态”它确实会写出对应的 class但往往只是“视觉效果上的状态”而不是真实的可交互逻辑。比如 hover 时它会做按钮换背景色但不会做焦点可见的 outline 来支持键盘操作比如它不会关心移动端点击区域是不是太靠近相邻元素比如图片缺失时不会给 alt 内容一个降级方案。这些都需要开发者用一套统一规范去过一遍。我自己会把这一步做成清单逐项打钩是否有键盘可访问的焦点顺序是否支持高对比度模式移动端点击区域是否大于 40px触摸操作是否和页面滚动冲突图片是否有替代文本表单错误是否能够被屏幕阅读器识别有了清单AI 生成页面落地就没那么吓人。AI 出构架和主体样式人工做质量和细节收口这是我认为最理性的分工方式。4. 多 AI 协作与 UI 自测流程4.1 让不同 AI 扮演不同角色生成、评审、测试现在 AI 工具选择很多我把它们分成三个角色来用。生成角色负责产出重点是速度和方案覆盖我会同时让几个不同模型生成同一页面的不同方向拿到之后再挑一个基础继续深化。评审角色负责挑刺我会把生成好的代码交给另一个模型读一遍让它寻找能跑通的问题点是否有冗余逻辑、是否有安全的边界、是否有明显的性能浪费。测试角色负责自动化回归用真实工具去跑页面验证交互流程是否真的可用。这三个角色可以来自同一个模型家族也可以是不同厂商的产品关键是让它们互相挑刺。一个人写代码时经常会被自己的思路迷住但在两个 AI 之间来回评审时反而更容易发现疏漏。多 AI 协作的核心不是数量多而是职责分离让每一个 AI 只做它擅长的一件事。在搜索相关资料时我发现不少团队已经开始用这套思路组建“AI 小组”来应付复杂界面开发了。以前觉得 UI 是单打独斗的活现在更像组队协作只是队友全是机器人。4.2 用 UI 自动化测试给 AI 兜底自动化测试是我兜底的底气。Maestro 这类工具可以用非常简明的 YAML 描述用户操作流程比如“打开页面、点击按钮、输入文本、断言某个元素出现”。我现在页面生成完就用它写几条关键路径把核心操作跑通。它和 AI 生成 UI 是天生一对AI 写出来的东西功能正确性需要用真实操作来验证Maestro 的脚本又足够简单很多部分我直接让 AI 生成脚本。甚至可以说AI 生成页面AI 生成测试脚本我再跑一遍这套闭环已经把大量重复劳动消解掉了。我整理了一个常用的 UI 自动化回归检查表分享给同行参考检查项目的页面打开速度防止生成物里塞入过多静态资源导致首屏慢核心按钮可达防止导航层级过深用户找不到入口空数据时页面显示防止接口无数据时出现白屏或报错表单校验提示防止错误状态缺失用户无法理解输入问题关键布局断言防止响应式断点被 AI 改坏4.3 手动检查清单上线前我必过的 5 道关卡自动化覆盖不了所有细节该手动过的地方还是得过。我给自己建立了一个上线前的手动检查清单每一条都是踩坑总结出来的。第一道用真实分辨率检查。笔记本、平板、手机三个宽度都过一遍重点看文字溢出和按钮挤压窄屏最容易暴露 AI 生成布局的脆弱面。第二道检查暗黑模式。如果项目有暗黑模式AI 生成的硬编码颜色就会非常显眼浅色背景直接变成一团刺眼的亮块。第三道检查图片懒加载。AI 容易给所有图片都加上懒加载属性但首屏图片不该延迟加载否则初始视口会一片空白。第四道检查焦点顺序。Tab 键从头到尾走一遍看顺序是否符合视觉阅读顺序能不能用键盘完成全部核心操作。第五道检查边界状态。把接口断网、超时、返回空值、返回超长文本各跑一遍。这个清单让我在 AI 时代依然保持了对 UI 质量的掌控感。AI 帮我干掉了低价值的排版工作节省出来的时间正好用来做真正护住质量的事情。5. 常见翻车现场与排查思路5.1 AI 生成的代码报错或依赖版本对不上最典型的翻车现场是把 AI 生成的代码丢进工程结果组件库版本冲突或者某个类名在工程里根本不存在。排查思路通常是三步。第一步看依赖package.json 里实际的组件库版本和 AI 提示词里是否一致很多报错本质上是版本不一致导致的。第二步看引入AI 生成的引用路径往往带着多余的相对前缀或者使用了大写文件名逐一改成工程里实际存在的路径。第三步看 props不同组件库版本的 props 差别很大AI 写出来的新语法在这个版本里不存在改成兼容写法就通了。很多时候不是 AI 能力不行而是它生成时参考的版本信息滞后。我现在每次生成前都会主动把版本号写进提示词甚至把组件库文档里的示例代码贴一小段进去命中率立刻高了很多。这个习惯值得养成。5.2 布局裂开、文字溢出、图片变形第二轮常见问题是视觉崩坏。AI 写的样式在它自己生成的 mock 数据里正常真实数据一换就出事。排查思路也不复杂定位导致溢出的元素检查宽度、flex 比例、white-space 这三个属性图片变形通常是 object-fit 没写对给图片容器设置固定宽高比再加 object-fit: cover文字溢出则要看最小字号和布局压缩规则如果压缩到某个宽度就崩就直接给容器设置 min-width再配合水平滚动或换行策略。多说一句AI 时代做 UI不代表可以不懂 CSS。它写出的代码你不一定能全部理解但排查方向必须心里有数。把它当成一个思路提供者而不是最终仲裁者。我见过不少同行让 AI 改了几轮代码后越改越乱最后只能回滚重来就是因为自己看不懂发生了什么没法给出有效反馈。5.3 生成结果太“模板感”像默认主题这是很主观但也非常常见的问题。AI 生成界面默认会选最大众化的风格看多了会觉得所有 AI 做出来的东西都长一个样。我的破解办法是在提示词中提供“参考锚点”指定某个喜欢的字体、某个具体的配色来源、某种排版节奏或者让它把某个知名产品的设计语言拆解后迁移过来。提示词越具体模板感越弱。如果已经生成了但觉得普通也不用整个重来可以让 AI 替换视觉关键词。比如把“简洁白底”换成“暖灰底加粗标签加大圆角”往往改一轮就能脱离模板感。我自己比较偏爱的方式是给 AI 一张参考图让它基于参考图的设计语言重新组织页面结构效果比纯文字描述明显更有个性。5.4 多轮修改后越来越乱怎么回退和收敛这个问题我想特别提一下因为太常见了。AI 改界面容易越改越跑偏第一轮加了个边距第二轮又给某个区块加了背景第三轮直接加了动画结果整页从没精神变成了过度设计。我现在的方法是给每次修改做“版本记录”。在提示词里让 AI 每次都返回完整的最终代码而不是增量补丁同时在对话里保留上一版结构当前一版跑偏得太多就回到上一版重新给约束。这种“回退思维”是从版本管理工具里学来的在 AI 对话里同样有效。延伸地说AI 多轮对话时上下文是会“漂移”的。建议在关键节点直接开新对话把最终版本的代码作为新对话的初始信息再提出新的修改要求。这比在同一个对话里无限续写要清晰得多也能避免早期错误被长期保留下来。6. 写在最后我踩坑之后沉淀的几个习惯6.1 先描述边界再让 AI 发挥我最大的习惯变更是不再给 AI 留“自由发挥”的默认空间。先把边界说清楚哪些组件不能换、哪些状态必须有、哪些层级必须保留然后才让它去生成。看似限制了 AI反而让它生成的结果更稳定对我来说后期返工更少。比如生成一个数据大屏我会主动告诉它“地图区域统一使用暗色调不要用鲜艳高饱和配色”它生成的方案就会收敛在一个可接受的范围内。边界越清晰产出的不可控部分越少。6.2 AI 写 UI不等于你就可以不验收这一点我反复提醒自己工具再强负责人还是我。AI 的产出必须经过“真机加真实数据加真实用户路径”的验收才算完成。以前手写 UI 时我会不自觉地对每一个像素负责现在 AI 写了我反而更警惕因为它的错误往往藏在“看起来没问题”的地方。我也把这种验收意识教给了团队里的新人。有同事觉得 AI 生成页面很快就不太愿意做人工检查和边界测试结果上线后被真实用户抓到了几个很基础的问题。后来我把验收清单挂在团队文档里所有 AI 生成页面跑同一套流程问题少了很多。6.3 最后分享一个我实测有效的小技巧在提示词末尾加上一句“完成后请输出一份针对该界面的自检清单列出你觉得自己可能会遗漏的边界条件。”然后我会根据它给出的清单和 AI 反向讨论。你会发现当 AI 被要求对自己做检查时它往往能发现自己遗漏的加载态、空状态、键盘操作这些问题。这个方法比我手动逐条提示效率高得多因为很多边界条件我也不可能在第一轮就想全但 AI 的自检能帮我提前暴露掉一批常见问题。我试过很多次实测下来很好用。自从把 UI 交给 AI我的角色从“拼界面的手”变成了“定义标准的脑”。以前每天最耗神的排版、间距、状态铺陈现在都变成了给 AI 定规范、验收 AI 产物、处理真实数据带来的边界问题。这个转变并没有让 UI 这个岗位消失反而让我能从更上游的地方思考界面应该是什么样。如果你也正在纠结是不是要让 AI 来做 UI我的建议是大胆试但一定保留那个“验收者”的角色。学会给约束学会做质检你才能拿到 AI 真正的好处而不是被它的平均输出淹没。