说实话我以前很不喜欢“拼 UI”这三个字。如果你也是那种既要做业务逻辑、又要手写布局、还得跟组件间距较劲的人应该能懂我的感受——每次接到新需求脑子里先冒出来的不是功能设计而是“这排按钮又得居中”“这个列表又得兼容三种屏幕”“这个弹窗又得在 iOS 和安卓上长得不一样”。自从我开始把 AI 真正用进日常开发之后情况发生了明显变化。现在的我基本告别了手搓界面的阶段AI 生成的 UI 代码占了新页面代码量的七成以上剩下的三成时间拿来处理逻辑、调细节、做联调。这篇文章就聊聊我这一路试过来的真实经验。这标题写出来可能显得有点夸张但实际用下来确实没有再回到过去那种“每个像素都自己摆”的状态。我想写的是AI 到底帮我把 UI 开发中的哪些环节扛走了、哪些环节它扛不走、我和它现在是怎么分工配合的以及如果你也想这么干应该从哪里入手。1. 先聊聊“拼 UI”这件事本身它到底哪里让人崩溃1.1 手动拼 UI 的重复劳动到底有多重很多人以为写界面是一件“有手就行”的事情尤其是现在组件库这么丰富拉几个控件摆一摆就完事了。但真正做开发的人都知道UI 工作里最耗时间的不是“放控件”而是“调尺寸、对齐、间距、状态切换、边界情况”。一个按钮不是放上去就完事它需要有默认态、悬停态、按下态、禁用态、加载态有的还要适配暗色模式。这些状态在代码里往往意味着七八个属性每一处都要手动维护。我之前做过一个后台管理系统光是一个表格筛选区域里面包含了时间选择器、下拉框、关键字输入框、查询和重置按钮。就这一个区域在不同屏幕宽度下的换行规则、间距统一性、label 长度限制前前后后调了差不多一天。第二天产品经理跑过来说“这个筛选区的按钮能不能在 1366 宽的屏幕上不换行”于是又是一轮像素级微调。这种工作做多了之后我对 UI 的热情被消磨得很快而 AI 的出现恰恰是在这个环节帮上大忙的它不需要休息也不会因为连续改十次间距而烦躁。1.2 技术层面为什么“拼 UI”容易被低效拖垮再往深一层说UI 开发的低效不只是体力问题还有技术选型带来的分裂。现在前端生态里你要选 CSS、Tailwind、Sass、CSS Modules要分 Vue、React、小程序要面对 Flutter、SwiftUI、Jetpack Compose 这些跨端方案。每一套方案写 UI 的语法都不一样一个团队如果同时维护 Web 端和小程序端很可能同一套界面要写两遍。我用 Android Studio 做原生开发时写过不少 XML 布局文件。你看起来结构挺清晰但一旦页面复杂起来嵌套层级一深运行时的渲染性能就受影响很多人说的 “UI 界面卡顿” 就是这么来的。每次遇到这种问题要么调整布局层级要么改用 Compose 重写局部区域无论哪一条路都要动手改很多代码。AI 在处理这类问题时就有天然优势它可以把“减少布局层级”“转为 Compose 实现”“合并重复样式”当作一个明确的任务来执行直接输出可编译的代码而不是简单丢给你一段示例让你自己翻译。2. AI 生成界面从一句自然语言到第一版可运行页面2.1 我选型的几个主流路线现在用 AI 生成 UI 的话路线基本可以分成三类。第一类是直接用 AI 编程工具在 IDE 里通过对话生成代码。这类工具在你现有的项目上下文里工作能理解你用的框架、组件库和页面风格生成结果出来就能跑。我目前最常用的是这种方式因为它和现有工程的融合度最高不用把代码搬到别的平台再搬回来。第二类是专门的文生 UI 平台通过描述需求直接产出设计稿或代码。设计阶段挺好用能快速找感觉但生成的代码工程化程度一般样式命名风格、目录结构不一定符合你团队的习惯通常还要人工重构一遍。第三类是设计稿直接转代码。拿一张 Figma 设计稿或者一张截图让 AI 生成对应页面。这种路线在还原度上已经能做到相当高了但遇到动效、交互逻辑、特殊字体时还是会出问题。这三条路线不冲突。我实际工作中经常先走一遍第三条路线做快速还原再用第一条路线去迭代优化第二条路线主要用来给产品经理出 demo 看效果。综合下来AI 承担的工作量越多我手动“拼 UI”的时间就越少。2.2 一句提示词出界面的实测过程给你看我最近做的一个小工具页面的例子。需求很简单一个移动端个人中心页面包含用户头像、昵称、会员等级标识、余额和积分展示、功能列表入口、底部版本号。以前我写这种页面得先建布局文件再挨个添加控件然后调样式、找图标、处理不同屏幕适配怎么也得起一个晚上。这次我直接在 AI 编程工具里输入了一段自然语言用 Vue 3 Tailwind 写一个移动端个人中心页面页头是深蓝色渐变背景用户头像和昵称居中显示下方显示会员等级标签。中间区域用两个卡片分别展示余额和积分。功能列表分成两组每组四个图标入口。底部放版本号。所有间距参考移动端 750 设计稿使用 rem 适配。AI 生成出来的代码结构基本符合预期。头像区域用了 flex 布局居中两个数据卡片用了 grid 两列功能列表用了一个简单的 v-for 渲染适配逻辑也处理了。我大概花了十分钟微调图标和间距页面就能提交给前端同事进行视觉走查了。从实际结果看AI 不仅把“控件摆放”这件事干完了还顺手做了布局方案选择。这一点比人工手写还要稳定因为只要你提示词里给了约束条件它就会围绕约束输出很少出现那种“布局写了一半发现忘了加容器”的情况。2.3 提示词的写法与技巧很多人问我说为什么 AI 生成出来的界面总是一股模板味或者跟他想要的结构完全不一样。我观察下来问题大多出在提示词写得不够具体。如果你只写“帮我生成一个登录页”AI 当然只能按最常见的样式来写因为它不知道你的产品主色调是什么、按钮要不要圆角、密码框需不需要眼睛切换图标、错误提示要放在输入框下方还是统一弹 toast。我习惯把提示词拆成四个部分技术栈与文件结构、页面布局描述、组件与状态细节、视觉风格约束。技术栈部分必须写“用 Vue3 script setup Tailwind”或“用 Jetpack Compose 实现”不然它有可能给你返回一坨陌生的语法。布局描述部分要写清页面从上到下的模块顺序以及每个模块内部是横向排列还是纵向排列。组件与状态部分要说明哪些是可点击的、点击后触发什么、数据从哪里来。视觉风格部分可以给参考站点也可以直接描述“圆角较大、配色偏年轻化、主色是 #6C5CE7”。这样一段结构清晰的提示词生成结果的可用性会提升一大截。我现在基本不会让 AI 把整个页面一句提示词搞定而是把页面拆成头部、内容区、底部操作区、弹窗这几个子模块分别生成再手动拼装。听起来好像还是在“拼 UI”但拼的是 AI 生成好的组件而不是自己从头写布局效率完全不是一个量级。3. 真正落地时AI 如何接进工程化流水线3.1 组件化拼装与代码审查AI 生成 UI 的代码能不能进生产环境关键要看它能不能融入你已有的组件体系。我在 Unity 项目里做过 UI 数字滚轮效果这是一个比较偏门的交互组件。以前要自己写滚动惯性、数字对齐、回弹动画代码量不小。用 AI 辅助时我只需要把现有 UI 框架的使用方式、需要用到的动画接口、数字滚轮的行为约束描述清楚AI 就能生成一版可运行的脚本我再基于项目规范做一轮重构。这个过程中我更像是一个审查者而不是逐行手敲代码的实现者。不过这里要提醒一点AI 生成的代码不能直接无脑合并。“能用”和“符合团队规范”是两码事。我会先把 AI 输出的代码过一遍检查有没有多余的 import、有没有直接写死的高度宽度、状态管理是否遵循项目套路。一个常见的问题是 AI 喜欢在局部样式上偷懒比如直接把颜色值写进组件里而不是提取成主题变量这在后续做深色模式或者换肤时会很麻烦。3.2 设计稿转换从 Figma 到代码的还原实践最近这一波 AI 能力提升最明显的是“截图还原代码”这条路。以前我也试过一些标注工具但还原度始终做不到让人放心的程度。现在的 AI 模型在视觉理解方面强了很多能识别出页面里的卡片、列表项、Tab 栏、浮层等结构。实践下来我的流程是这样先把设计稿导出成清晰度较高的 PNG 图片上传给 AI 工具同时附上技术栈要求和页面说明。AI 返回代码后我第一件事不是去看视觉效果而是先看 DOM 结构和样式方案。结构上是否符合语义化样式上是否用了合理方案有没有把阴影写死、有没有用 flex 布局处理三列对齐。举一个实际案例一个原生安卓项目需要一个包含列表的详情页设计稿里有图片叠加、文字悬浮、底部操作栏固定。我让 AI 生成 Compose 版本一次性出来的代码在图片缩放和文字间距上出现了两个小问题但整体结构可以直接用。修这两处问题花的时间不超过二十分钟。要是我自己从头写从布局推算到状态管理怎么说也得半天。3.3 UI 自动化回归测试中的 AI 角色UI 开发不只是写代码还有回归测试。以前每改一次界面就要手动过一遍主要流程确认按钮位置没偏、弹窗能正常弹出、列表滑动没有卡顿。后来我引入了 Maestro 这类 UI 自动化工具。它的特点是可以用 YAML 描述用户操作流比如点击、输入、滑动、断言。痛点在于写这些 YAML 本身也是体力活。一个复杂的注册流程要写上百行命令而且 UI 一变选择器就要跟着调。AI 在这里又能发挥作用。把页面的源码或者可访问性树丢给 AI让它生成 Maestro 的流程脚本或者在我修改了 UI 之后让 AI 根据新旧代码差异自动更新断言选择器。这样我就把“UI 改动后的回归脚本同步工作”也交了出去自己只需要跑一遍确认结果。从效率角度来看UI 自动化这一步的收益甚至比生成页面更高因为它减少的是每天的重复劳动。页面生成是一次性的回归测试却是每个迭代都要做的。AI 帮我省下来的时间每周至少能攒出三到四个小时。4. AI 拼不出来的 UI边界与翻车现场4.1 复杂交互与性能场景里 AI 容易失控AI 再强也有明显搞不定的区域。交互密集型的界面就是第一类。举个例子一个包含拖拽排序、多选、快捷键、上下文菜单的任务面板。AI 能生成一个看起来很完整的界面但你一旦实测就会发现拖拽的占位样式不够顺滑、键盘操作的焦点管理缺失、多选时的 Shift 连选没有实现。这些行为逻辑往往是隐性的不会直接写在设计稿里。AI 没见过用户真实使用时那种“鼠标拖到一半又取消”的细节状态也没法通过一段提示词就理解你积压了三年的交互沉淀。所以在复杂交互模块中我的做法是让 AI 负责静态布局和基础交互我负责把状态机、手势逻辑、无障碍支持这些部分补完整。4.2 视觉一致性与设计规范的维护难题设计规范这件事AI 也没有很好的解决方案。一个成熟产品的 UI 一致性不只是“看起来差不多”还包括组件库里的每个按钮都遵循同一套圆角和阴影变量每个弹窗都复用同一个容器颜色全部从主题 token 读取。AI 生成代码时更倾向于“就事论事”。你让它生成一个弹窗它就根据提示词生成一个孤立的弹窗代码这个弹窗里的边距值、颜色值、圆角值可能是凭空给的。如果直接把它合入项目后续设计师改了主题变量这个 AI 生成的弹窗可能纹丝不动。我在项目里吃过这个亏后来不得不专门写了一份“AI 生成代码接入规范”里面明确要求生成结果必须引用设计系统的变量名而不是写死具体数值。4.3 兼容性和无障碍仍然是人工战场兼容性是另一个绕不开的坑。AI 学习的数据大多来自主流框架的最佳实践它不太了解你们公司还要支持的那些老版本浏览器、特定厂商的 WebView 内核、或者低于某个版本的安卓系统。UI 界面卡顿这一类问题在低端机上尤其明显AI 生成的代码往往没有考虑帧率、布局计算耗时、图片内存占用这些性能指标。无障碍支持也是 AI 目前基本不关心的领域。一个按钮如果只有图标没有文字标签AI 不会主动给这个按钮加上 contentDescription一个自定义的滑动条AI 也不会考虑用正确的 ARIA 角色或者无障碍操作接口去暴露给读屏软件。这些事情只能靠开发者在代码 Review 阶段人工检查。所以我的经验是AI 生成的代码占比越高我越要留出一部分固定时间专门做无障碍自查。5. 我当前的分工方式与工具组合5.1 日常项目的角色分配现在我做带 UI 的功能时分工比较固定。页面静态部分的初稿交给 AI 完成。不管是 Vue、React、Flutter 还是 ComposeAI 都能快速出活。我拿到手之后先做结构审查再补充业务状态和交互逻辑。纯展示型页面比如个人中心、设置页、数据看板AI 直接产出终稿的可能性很高。表单类页面AI 产出的结构基本没问题校验逻辑和提交逻辑我基本自己写因为这部分太依赖业务规则。列表页是 AI 比较擅长的场景数据展示、分页、空状态、加载状态这些常见的逻辑都能很好地生成。细节之处像下拉刷新动画、滚动加载触发时机我通常会手动调。5.2 我最依赖的几个 AI 辅助点回看这段时间的使用最离不开的有三个点。第一是 AI 改布局的能力。以前做响应式适配真的很烦特别是当你已经写了一版固定宽度的布局要改成自适应时要么逐个加媒体查询要么重写整个布局逻辑。现在直接让 AI 改它会把 flex 换 grid、把固定宽度改成百分比或 clamp 值一步到位省掉大量重复劳动。第二是虚拟数据生成。开发页面时为了看效果要造数据以前要手动写数组或找 Mock 数据源现在我直接让 AI 生成一份带业务含义的模拟数据字段结构完全按后端接口文档走省了不少时间。第三是 UI 代码解释与问题定位。接手别人的项目时看到一段看不懂的复杂样式我再也不会去翻 CSS 优先级规则或者打断点调试了。直接把代码复制给 AI让它解释每个选择器在做什么它能快速告诉我哪条规则覆盖了哪条哪个属性造成了布局异常。这个能力在排查线上 UI bug 时非常实用。5.3 给准备尝试的人几条建议如果你也想把 AI 用进自己的 UI 开发流程我有几条经验可以参考。不要在团队还没建立代码规范时就大面积铺开 AI 生成代码不然后续的维护成本会很高。先把主题变量、组件库、命名规范都定好然后让 AI 基于这些标准干活。不要一开始就用 AI 去生成特别复杂的页面。从一个表单、一个卡片列表这种小模块开始你才能慢慢摸清楚 AI 在你们技术栈上的脾性知道提示词要写到什么程度输出才稳定。另外重视代码审查的环节。AI 生成代码后至少要有一个熟悉项目的人过一遍确认没有奇奇怪怪的写法混入生产代码。这个过程不可省略因为一旦坏味道的代码被合入主干后面的优化成本是很高的。最后我想说的是AI 并不是让 UI 开发变成了零门槛的事情。它更像是一个特别有耐心的初级工程师速度快、不喊累但它需要你给它清晰的任务描述也需要你在关键环节把好关。我现在的实际体会就是交给 AI 的杂活越多我越有精力去处理真正需要判断力的交互设计、性能优化和用户体验问题。这个状态正是我之前一直想要的。