我以前最烦的不是业务逻辑是拼 UI。一个页面需求下来切图、对间距、调颜色、做 hover、适配窄屏一套流程走完大半天没了。更难受的是验收时被指着屏幕问“这个按钮是不是歪了1像素”。过去这大半年我把这套活儿陆陆续续全部交给 AI 之后整个人轻松了一个量级。这篇文章就聊聊我为什么从“手搓 UI”变成“只提需求”以及如果你想复制这条路径背后有哪些不能忽略的细节、工具和坑。这个内容不是写给只想看“AI 能自动生成一个漂亮页面”的围观群众的而是写给真正靠代码吃饭的前端开发、全栈工程师、独立开发者和一部分转型中的 UI 设计师。AI 拼 UI 这件事说到底是把“从设计稿到代码”这条机械链路交给模型但前提是你得懂结构、懂约束、懂验收。下面我按自己的实战经验从旧日痛点一直讲到现在的完整工作流和踩过的坑尽量把能直接用的都拿出来。1. “手搓 UI”的旧日时光那些年我们拼过的布局和样式1.1 “拼 UI”拼的到底是一堆什么活很多人以为拼 UI 就是照着设计稿写 HTML其实真正的工作量远不止这些。我复盘了一下一个普通后台页面的 UI 工作至少包含这么几块切图与标注还原从设计稿里量尺寸、取颜色、导图标一不留神就漏掉一个 hover 状态。间距与排版微调字号、行高、边距肉眼看着没差一像素一像素地试。组件封装与状态整理按钮的 loading、disabled、hover、active 至少四个状态一处处写到代码里。响应式适配同一个页面要在 1440、768、375 三档宽度下都不破版。主题与深色模式一套样式写两遍变量名都要提前规划好。动效与交互相接弹窗进出场动画、表单校验提示、表格排序按钮、空数据占位全是琐碎活。这些项目单个拉出来都不难但合在一起就是纯粹的体力消耗。尤其是“间距微调”我调过最久的一次是侧边栏图标和文字之间的 4px 对齐前前后后改了七八轮最后发现是设计师在 Figma 里多留了一层透明容器。这种时间花得毫无价值。1.2 为什么这些活儿最容易消磨耐心拼 UI 这件事最大的问题不是难而是碎。它要求你在短时间内高频切换上下文上一分钟在看设计稿的圆角值下一分钟要去查 CSS 的兼容性写法再下一分钟又要处理父容器溢出问题。每切换一次大脑就要重新加载一遍相关记忆耗神程度远比写业务逻辑高。另外一个很磨人的点是“牵一发动全身”。一个弹窗里加了关闭按钮可能同时影响三个页面一个表格列宽改了筛选弹层的位置又会偏。尤其在老项目里样式互相覆盖、全局选择器满天飞改一处崩两处是常态。这种不可预测性让人就算只做一个小改动也必须先全量排查一遍等于每一分钟都在给自己做回归测试。1.3 拼 UI 的隐性成本不只是时间问题时间成本只是表象更贵的其实是心态成本。连续调几个小时的样式之后晚上回家看到编辑器就想吐第二天再也不想碰那个页面。有几个项目我甚至因为 UI 细节太多拖到最后一两天才集中处理质量自然惨不忍睹。还有一层隐性成本是“技术价值被稀释”。你花了两天把界面做得精致像素级但业务功能一点没动周报里能写什么如果做的是内部后台这种工作往往被认为是“应该的”既没有需求变更带来的挑战也没有性能优化带来的成就感。这也是我后来下定决心重构工作流的最直接原因——不是 UI 不重要而是“手动拼 UI”这件事本身太不值钱。2. AI 凭什么接得住“UI 需求”拆一拆底层逻辑2.1 多模态模型让 AI 同时“看得见图”和“写得出码”过去几年代码生成模型能根据文字写函数但你说“帮我做个登录页”它只能给你一堆抽象代码因为你没给它看设计稿。现在的大模型已经具备多模态能力它可以同时接收“一张截图 一段文字需求”然后输出结构完整的 HTML/CSS 代码。这背后的关键是模型在图与代码之间建立了语义映射看到卡片知道是 Card看到输入框知道是 Input看到深色背景和圆形按钮能推断出设计风格。我实测下来这种能力在“还原常见页面结构”上非常靠谱。你甩给它一张后台列表页截图它能自己判断出表头、工具栏、分页器、状态标签这些元素分别用什么组件。这已经不是一个只会翻译代码片段的工具而是一个能理解“界面意图”的助手。2.2 大模型自带组件库记忆为什么它天生有“审美常识”一个容易被忽略的事实是大模型训练数据里包含了海量开源代码和设计系统资料。Bootstrap、Material Design、Ant Design、Tailwind CSS 这些框架的源码和文档模型早就“吃过”了。所以当你让它生成一个界面时它输出的结构往往不是胡写的而是混合了它见过的成千上万个真实项目的“统计最优解”。这个特性有利也有弊。好处是哪怕你只有一句“做一个简洁的仪表盘”它也能输出一个看起来像样的布局。坏处是它默认输出的风格可能是“训练数据里最常见的风格”而不是你们公司设计规范里的风格。如果你们团队用的是 Arc Design、Business Theme 这类偏门设计语言直接让 AI 生成它大概率会自创一套。这个问题没有捷径只能靠提示词里写清楚约束或者给它喂设计规范文档。2.3 关键认知AI 做的是“意图级还原”不是“像素级还原”我用了大半年 AI 拼 UI最深的一个体会是AI 不是像素级工具它是意图级工具。你说“左边一个品牌区右边一个表单区”它能够输出一个合理的左右分栏结构但你要是纠结“品牌区的 logo 距离左边到底是 32px 还是 36px”它没有这种精度也不该有。想清楚这一点之后我的工作方式就变了。以前我是“照着设计稿逐像素翻译”现在我是“用自然语言描述页面结构与行为让 AI 先产出可用骨架再由我补精确控制和业务逻辑”。这个思维转换才是真正告别“手搓 UI”的分水岭——你不再把 AI 当成一个“自动完成像素翻译”的机器而是当成一个“理解了你的产品意图”的协作伙伴。3. 从一句话到可运行界面我现在的 AI 辅助 UI 工作流3.1 一套稳定跑通的五步流程我现在的 UI 产出流程已经固化了核心分五步需求归纳把页面用途、目标用户、核心操作、技术栈整理成 3-5 句话。AI 生成初稿把需求连同参考图或设计稿一起发给模型明确输出组件代码。人工结构审查我只看布局结构对不对不看像素细节。重点检查容器层级、组件划分、响应式方案。迭代约束把“表格要有分页”“弹窗关闭要重置表单”“窄屏要隐藏侧边栏”这类硬性要求逐条补给它让它二次返工。状态与交互接入AI 完成视觉结构后我自己或者让它继续编写交互逻辑、接入状态管理、补齐边界状态。这套流程里人最重要的工作在第一和第三步。需求梳理得越清楚AI 第一次输出的可用度越高结构审查做得越仔细后面返工的成本越低。我在第二步通常能拿到一个覆盖 70% 需求的初稿剩下的 30% 就是那些“AI 不理解业务规则”的部分。3.2 提示词模板让 AI 一次听懂的写法很多人在 AI 拼 UI 上翻车问题不在 AI在提示词写得像“帮我写个页面”。我对比过多次之后总结出一套适合 UI 生成的模板你是一名资深前端工程师请根据以下需求生成一个可用的【页面名】 - 页面用途用户在这里【完成什么任务】 - 设计风格【简约/圆角/黑白灰/科技感】主色为【#xxxxxx】 - 技术栈【React Tailwind CSS】 - 布局要求【居中卡片式左侧品牌区右侧表单区窄屏自动隐藏左侧】 - 状态要求包含【loading、disabled、校验错误】三种状态 - 交互要求【提交成功后跳转首页失败后提示原因】 - 输出要求完整组件代码 关键注释禁止使用 position: absolute这个模板容易获得好效果的秘密在于两点一是给了模型“角色和场景”它知道该用前端工程化的标准来回应二是每条约束都足够具体能让模型在每次生成时都带上这些限制条件而不是第一次给了后面全忘。如果你有设计稿截图直接贴在需求文字前面效果会再上一个台阶。3.3 一次真实迭代从登录页到后台订单管理页面拿我最近做的内部订单管理页举例。第一次给 AI 的需求是“做一个订单管理页面包含筛选区、订单表格和分页器技术栈 Vue3 Element Plus”。初稿出来之后表格有了、分页有了、筛选区也有但问题很明显筛选区没有展开收起逻辑订单状态列用的是英文表格在窄屏下横向滚动失效。我第二轮提示词是追加约束“筛选区做成可展开收起默认收起状态列映射为中文标签表格宽度小于 900px 时允许横向滚动并固定首列”。AI 很快出了第二版这次结构基本达标。第三轮再补“加载中要显示骨架屏”“表格空数据时显示空状态插画和新建按钮”它也能快速处理。三轮下来一个中等复杂度的后台页面我从无到有拿到一个能接后端接口的 UI 框架总共花了不到四十分钟。这在以前光是把设计稿还原到能看至少就得小半天。3.4 工具组合与选型思路我试过 ChatGPT、Claude、以及几个国内产品结论是没有哪家绝对最好关键在于“会不会二次对话”。对我而言AI 拼 UI 的体验由三件事决定模型代码能力、上下文长度、对图片的理解力。代码能力强决定初稿质量上下文长决定迭代时它记不记得住前面的约束理解图片决定设计稿还原度。前端框架和样式方案上我同样验证了一个结论当样式方案越“原子化”AI 的生成一致性越好。Tailwind 这种直接在类名里写样式的方案比传统的 CSS Modules 更容易让模型保持风格统一因为它在输出节点时就会顺便带上颜色、间距、圆角的取值。如果是传统 CSSAI 虽然也能写但经常出现 class 名乱起、样式互相覆盖的问题。4. 不同 UI 战场上的 AI 实测Web、移动端与 Unity 的差别4.1 Web 页面最成熟也最顺手的主场Web 端是 AI 拼 UI 体验最好的领域信息密度、组件种类、布局模式都足够标准化。落地页、表单页、仪表盘这类常见页面AI 生成的初稿可用度普遍在七成以上剩下需要人改的无非是品牌化细节和业务状态。我尤其推荐把“仪表盘类页面”当作 AI 入门的第一个练习项目因为它信息模块多、图表占位多、响应式要求明确AI 很容易把网格布局铺得整整齐齐。配合 Tailwind 之后你甚至能让 AI 连深色模式都一次写出来只需在提示词里加一句“同时输出 light/dark 两套主题变量”。4.2 移动端容易被系统规范卡住移动端和 Web 的最大区别是系统交互规范强约束。AI 生成一个 iOS 风格的表单页很容易但它不知道返回手势、安全区、键盘避让这些细节怎么处理。如果你只丢一句“生成一个移动端个人中心页”拿到的代码大概率没有适配灵动岛安全区也没有考虑底部小黑条遮挡。我的做法是在提示词里加一层“平台约束”“适配 iOS使用自动布局顶部考虑状态栏与灵动岛底部预留 Home Indicator 安全区表格行高不小于 44pt”。加了这层约束之后AI 输出的结构里会自动带上 safe-area-inset 相关处理整体可用度提高非常明显。换句话说移动端不是不能用 AI而是你得比 Web 端多写一层“系统感知”。4.3 游戏 UI 与 Unity能写框架别指望一步到位热搜词里能看到不少人在问 Unity UI 框架和 Curved UI 的用法我也在几个小游戏项目里试过 AI 的参与方式。坦白说游戏 UI 和传统界面开发差异很大因为它依赖 Canvas、Anchor、RectTransform 这些引擎概念AI 并不擅长脑补编辑器里的可视结果。但它并不是没用。我的实测结论是AI 非常适合生成 Unity 里的 UI 脚本骨架和控件层级注释。你给它描述“背包界面包含格子、滚动区、详情弹窗”它能输出一份 Canvas 结构建议和对应的 C# 脚本结构省去你查 API 的时间。但真正的布局调整还是得回到编辑器里看效果。游戏 UI 想要“复制 Web 端那种爽感”目前还不现实它更适合被当成一个“结构顾问”。4.4 专业控件与小众框架AI 最怕没见过的 API还有一类场景容易被忽略公司内部用的小众 UI 库比如基于 jQuery 的 EasyUI DataGrid或者一些商业化的自定义控件包。AI 第一次遇到这些库经常会一本正经地“发明”API而且你一眼很难看出来直到运行报错才发现。我踩过几次之后总结出一个办法把对应组件库的官方文档节选直接贴给 AI并且在提示词里写“请严格基于你收到的文档内容生成代码不要使用你没有见过的 API”。只要给了文档上下文AI 对这些小众控件的处理能力立刻提升一个台阶。它的问题从来不是学不会而是“没有上下文时会猜”你要做的就是帮它补上下文。5. 别急着上生产AI 生成 UI 代码的典型坑与修复办法5.1 布局毒瘤滥用绝对定位和魔改 marginAI 拼 UI 最常见的翻车点就是它为了“快速还原视觉稿”大量使用position: absolute或者负 margin 来硬拉位置。这样生成的界面在固定尺寸的截图里看起来没问题一旦窗口拉伸所有元素就各跑各的整个页面直接“解体”。我处理这个问题的办法是在提示词里明确写“布局优先使用 Flex 和 Grid禁止使用绝对定位”。此外拿到初稿后我会先全局搜一下absolute、!important和margin: -这些都是危险信号的代名词。出现就要求 AI 重构而不是手动修一处漏一处。5.2 “看着像”和“能交互”是两回事AI 生成的按钮经常没有点击反馈表格没有排序弹窗关闭逻辑缺失。这不是模型笨而是它默认你把“交互”单独安排给它了。它产出的本质是“视觉结构”事件绑定、状态联动都得靠人补充。对策是在需求阶段就把交互写全。我自创了一个“交互穷举法”把页面上的每个元素从静态改过一遍列出它的 hover、focus、active、disabled、loading、empty、error 这些状态然后全部写进提示词。虽然这会让第一次沟通变长但后续返工次数会直线下降。5.3 响应式与深色模式模型最容易“失忆”的地方AI 有个很让人头疼的习惯第一次生成时你明确要求了响应式过了两轮迭代之后它可能把之前的约束忘得一干二净返回一个固定宽度为 1200px 的页面。深色模式更夸张新一轮对话只要你不提它默认只给你浅色主题。与其反复提示不如在每次追加需求时都重复一遍核心约束或者干脆在提示词模板里留一个“不变约束区”把响应式、深色模式、禁止绝对定位这些常驻要求写在一起。我是直接把这段做成输入框草稿每次新建对话先粘进去再开始聊新需求。这样虽然多花十秒但避免了“对话久了大纲跑偏”的隐形风险。5.4 性能隐患“界面卡顿”大概率来自 AI 代码热搜词里有“UI界面卡顿”正好戳中 AI 生成代码的一个重灾区。AI 写列表时默认会把所有数据一次性 render写图片时默认不会加loadinglazy写动画时默认会做高频率重绘。这些代码在数据量小的时候没事数据一涨页面马上卡成 PPT。我的修复习惯是给 AI 加性能阈值“当列表超过 50 条时使用虚拟滚动”“图片一律添加懒加载”“遮罩层动画只使用 transform 与 opacity”。如果 AI 不会虚拟滚动那就让它生成“数据分批渲染”的结构由人来接一个现成的虚拟列表组件。毕竟 AI 拼 UI 的目标是让你更省力性能问题攒到最后反而是更大的负担。5.5 上生产前的“AI 代码审查清单”每次 AI 生成的 UI 代码在提交之前我都会按下面这份清单过一遍检查项具体检查内容典型 AI 遗留问题布局方案是否以 Flex/Grid 为主大量 absolute、固定宽高语义化是否使用语义化标签全是 div可访问性差组件化是否可拆分为独立组件一个文件几百行难维护状态管理UI 状态是否与业务数据分离loading 混在业务 state 里响应式断点是否覆盖常用尺寸只在某个宽度下正常性能是否处理长列表和图片懒加载一次性渲染全部数据无障碍是否有键盘操作与读屏标签按钮没有 aria-label依赖注入是否用了项目已有组件库自造轮子样式冲突这份清单本身不需要执行得多完美它的核心价值是逼你在“无脑接受 AI 输出”之前踩一脚刹车。拼 UI 可以交给 AI但“这个页面能不能上生产”的判断永远得自己来。6. 不再“拼 UI”之后开发者的角色正在变成什么6.1 工作时间从“做界面”变成“说清楚界面”把这套流程跑顺之后我明显感觉到自己的时间分配变了。以前一天 8 小时六小时在写样式现在这个时间被压缩到了三分之一剩下的大头变成了定需求、写约束、审查结构。这种转变的本质是我从“施工者”变成了“产品经理 架构师”。这个过程一开始并不适应因为我习惯了打开编辑器就有事干。但跑了几个项目之后我发现“说清楚界面”这件事比想象中难也更重要。你提出的约束越精确AI 的产出越靠谱反之一句“做个好看的后台”只能换来一个平庸的模板页。表达能力正在取代手写速度成为新的效率分水岭。6.2 与设计师的协作方式也在变化以前设计师给我设计稿我会照着“抠像素”现在我会跟设计师讨论“意图”。比如某个卡片要圆角还是直角、某个状态要不要加空插画、某个交互的边界条件是什么。设计师的交付物从“施工图”变成了“对齐意图的沟通图”。这种协作方式对设计师也有要求。设计稿信息越完整状态类型越齐全AI 生成出来的代码就越接近终态。如果设计师只给了一张静态图没有空态、加载态、错误态那么 AI 生成的代码也只会是一张“静态图”最后这些缺的状态还是得靠开发自己补。6.3 新人还需要学基本功吗我的答案是需要很多人担心 AI 拼 UI 会终结前端新手学习动力我的观点恰恰相反基本功是使用 AI 的前提。你只有自己手写过浮动的坑、理解 Flex 和 Grid 的差异、知道状态管理为什么不能乱塞才能真正看出 AI 代码里的问题。不然的话你只会“看着好像没问题”然后带着一个到处是坑的页面上线。我给新人的建议是先手动拼三个完整页面再开始用 AI。这三个页面能帮你建立“代码结构感”当你有了“结构感”之后AI 就是你的加速器没有这个感觉AI 就是你的幻觉制造器。任何时候判断力都比生成速度值钱。6.4 下一步多 AI 协作与 AI Native 研发范式这次把 UI 交给 AI只是我整个工作流变革的第一步。现在已经有团队在探索“多 AI 协作”模式一个 AI 出 UI一个 AI 出业务代码一个 AI 写测试再由人来编排和验收。这种模式下开发者更像一个指挥而不是每个声部都亲自演奏的人。热搜里提到的“AI Native 研发范式实践手册”其实也指向同一个方向人负责定义意图与验收标准AI 负责把意图翻译成代码。UI 只是这个范式里最先被攻克的环节因为它的模式相对固定、反馈直观、验证成本低。下一步业务逻辑、测试用例、甚至架构设计都会陆续被纳入这条链路。对我个人来说先把 UI 这一环跑通正是通向更大范式变革最合适的入口。最后分享一点个人体会自从把拼 UI 交给 AI 之后我不觉得技术退步了反而觉得自己在做开发的初心被找回来了。UI 是产品的一层皮肤真正值钱的永远是需求洞察和架构判断。如果你也想试试这条路建议从下周一个新页面开始先用 AI 出一版初稿再自己改一轮。你很快会体会到“不想拼 UI”的轻松但也会更明白为什么“不想拼”和“不会拼”是两码事。