前两年只要接到带界面的需求我心里就开始进入“拼 UI 模式”。从设计稿到能跑起来的页面中间那段时间纯粹是在做体力活把一个区块拆成组件不停堆容器、调间距、整状态。自从我把 AI 接进这一段流程之后工作方式直接换了个方向现在接到新界面需求第一反应是“怎么把需求描述得更像人话”而不是“要拼多少个组件”。这篇文章就把我这几个月的真实用法、提示词、踩坑和取舍标准一次性说清楚。1. 拼 UI 的日子到底有多烦1.1 真正让人崩溃的不是写代码是对齐和状态不少刚入门的朋友觉得“拼 UI”就是写布局真正干过的人才知道布局本身花不了多少时间耗时间的是那些看不见的细节。我印象最深的一次是在后台系统里做一个筛选栏。需求很普通一个输入框、一个下拉框、两个日期选择器、一个查询按钮要求在一行内整齐排布并且在小屏上自动换行。听起来几分钟就搞定实际做的时候我在那儿折腾了两个小时。问题出在几个地方下拉框和输入框的高度差两像素日期选择器的弹层被表格容器裁剪按钮在换行之后的对齐方式又跟设计稿不一样。这些单个拎出来都不难难的是它们绑在一起出现你修完右边左边又塌了。这种体验真的很消磨耐心尤其是同一类问题在不同页面反复出现的时候。另一个让我不想碰“拼 UI”的理由是状态管理。一个稍微复杂一点的表单加载状态、校验状态、提交状态、重复点击的状态都得处理。界面代码本身长得差不多但每个页面的业务字段不同你总得为每个页面重新写一遍这一堆默认逻辑。写多了就会觉得UI 开发的价值明明应该体现在交互和体验上结果每天大部分精力都花在了这种重复劳动里。1.2 组件库能救一半剩下的一半才折磨人用组件库当然能省不少事这也是最主流的做法。我一开始也是组件库的忠实用户表格用成熟的表格组件表单用现成的表单布局省下了很多选择题。但组件库也有一个很现实的问题它能覆盖标准场景覆盖不了“有点特别”的页面。举个例子一个充电脑电桩管理后台左侧是充电桩状态列表右侧要放一个实时功率曲线的展示卡片底部还有一组告警日志要按时间线排布。组件库不会为这种业务场景内置布局你还是得自己写外层容器、自己定栅格规则、自己处理异常状态。等我写完这个页面大概 70% 的时间都用在了“把组件拼成页面”上真正有意义的业务逻辑反而只占一小部分。那段时间我就在想如果有一种方式能让我直接描述“我要一个什么样的界面”让代码自动生成我就能把省下来的时间花在业务流程和用户交互上。1.3 转折点我第一次用一句话换回一整个页面用 AI 写 UI 的起因其实很土。有个小项目需要一个移动端订单确认页设计稿都没有产品就在聊天里说了一句“跟上一个订单页差不多多了个优惠券选择和配送时间”。我懒得从零敲就试着把这句话复制给 AI补了一句“用 Vue3 和 Element Plus 生成移动端布局优惠券和配送时间放在卡片里”。十几秒之后一个结构完整的页面代码出来了。那一刻谈不上惊艳因为细节还差得远但整个骨架、布局、基础状态都齐了。我在它基础上改了大概四十分钟就把页面交给了验收。放在以前这个页面从零拼起来怎么也得两小时。后来我又陆续试了表格页、表单页、图表页发现 AI 在 UI 这个领域确实不是花架子它是一种能把“重复劳动”和“创造性劳动”分开的新工具。2. AI 生 UI 的实质变化从“拼”变成“提需求”2.1 我的第一个 AI 生成页面还原度比我想象的高当时我抱着半信半疑的态度试了一个比较典型的后台页面左侧菜单顶部面包屑中间一个数据总览卡片区再往下是明细表格。我给的提示词大概是这样生成一个 Vue3 TypeScript Element Plus 的后台页面。 布局如下 顶部是面包屑导航显示“首页 / 数据中心” 下面是一行 4 个指标卡片分别是今日订单、成交金额、新增用户、退款率 再下面是一张表格列表字段包括时间、订单号、用户手机号、金额、状态、操作 表格右上角放一个“导出报表”按钮。 卡片和表格要有合适的间距和圆角整体风格简洁。AI 生成的版本确实让我有点意外。四个指标卡片宽度自动分配了表格列字段全对状态列还自动用上了不同颜色的tag连导出按钮的图标都给我放好了。整体属于“能用但还需要调”的程度但方向完全正确。我只需要把请求方法接上真实接口再改几个字段显示格式化就能提测。这种还原度带来的核心变化是我不用再从空白文件开始搭架子了。我只需要拿着产品需求把它翻译成 AI 能理解的页面诉求剩下的事情是审核和修改而不是创作。这个思维转变比 AI 本身能用多少次更重要。2.2 一个常规 UI 生成流程可以拆成三步用了几个月之后我把 AI 生成 UI 的流程总结成三步拆解、生成、收敛。拆解是把一个完整页面拆成若干个能独立描述的区域。比如一个报表页拆成筛选区、指标卡片区、图表区、表格区。每个区域单独生成比让 AI 一口气生成整个页面要稳定得多。生成是把每个区域的需求描述清楚包括布局、组件、字段、事件和状态。收敛是把生成结果拿到真实设计规范和代码规范里做归一化重命名变量抽出公共样式接上真实的 API。这三个步骤听起来很普通但真正做到位AI 产出的代码可用率会非常高。我见过很多抱怨 AI 生成的代码没用的人问题基本出在第一步和第三步要么让 AI 一次性生成十个区块结果中间必乱要么生成完不管直接用结果看到硬编码的假数据就觉得 AI 不行。2.3 不要指望 AI 直接交出成品它的核心价值是底稿真正用过一段时间之后我对 AI 生成 UI 有一个冷静的判断它不是替你完成工作而是替你省掉从 0 到 1 的时间。它的产出更像一份高质量的底稿你需要做的是在这份底稿上做艺术加工和工程化处理。打个比方以前写一个页面像自己从买材料开始做饭洗菜切菜炒菜全包现在用 AI 就像点了一份半成品到家你只需要按自己的口味再加工。半成品当然不能直接上桌但它的价值在于把大量备菜过程替你完成了。所以我在团队里一直强调AI 生成 UI 之后一定要做工程化改造而不是把代码往代码库里一扔就不管了。这个改造的质量才决定最终项目的质量和可维护性。3. 一个真实项目拆解查水电表移动端页面3.1 我实际给 AI 的提示词长什么样说了这么多抽象的概念拿一个我最近上线的真实案例来拆。业务背景是物业工作人员需要在手机上查看每户的水电表数据并录入当前读数原来这个功能是做在 PC 后台里的现在要拆出来做成移动端 H5。接到这个需求后我没有先写代码而是先写了一份非常具体的提示词生成一个移动端 H5 页面用 Vue3 Vant 组件库TypeScript 编写。 页面标题水电表抄表。 页面功能 1. 顶部显示当前小区名称和抄表员姓名 2. 中间是一个住户信息卡片包含房号、业主姓名、联系电话、水表编号、电表编号 3. 卡片下方是两条录入项本次水表读数、本次电表读数要求用数字输入框单位分别是 m³ 和 kWh 4. 底部放一个“提交记录”按钮点击后先做必填校验然后弹出确认对话框 5. 页面背景色是浅灰 #f7f8fa卡片用白色圆角样式间距保持 12px 6. 下拉刷新整个页面内容放在一个可滚动容器里。这种描述方式比我以前随口说“帮我生成一个抄表页面”要有效得多。因为我把布局顺序、组件类型、字段名、单位、操作流程、颜色值、间距都写进去了AI 没有多少自由发挥的空间。3.2 从“能看”到“能上线”的工程化改造过程生成代码确实能看但我拿到手之后还是做了不少改造这个阶段才是真正考验工程能力的地方。第一件事是提取数据。AI 生成的时候把住户信息和读数都写死在页面里我要把它们改成从接口读取。我拆出一个useMeterStore的组合式函数负责加载住户信息、提交读数、处理错误提示页面组件里只保留展示逻辑。第二件事是处理表单校验。AI 写了一个很简单的非空判断但实际业务要求电表读数不能小于上次已提交的读数。我加了一道校验逻辑在提交前对比上次读数和当前读数如果当前读数更小就用轻提示直接拦住并提示抄表员重新核对。这部分是 AI 生成不出来的因为业务规则只存在于我的脑子里。第三件事是样式收敛。全局设计规范里按钮的主色是#1989faAI 默认用的也是这个色值但圆角大小是它自己拍的板。我统一把圆角改成了 4px把卡片内边距收敛成统一的 spacing token。改完之后整个页面的视觉节奏明显整齐了很多。这一套改造下来我真正从头写代码的工作量大概只占原来的三成。剩下的七成被 AI 替代了但我并没有轻松多少因为审查和修改同样需要深度参与。只是我的精力从“写布局”转移到了“定规则”。3.3 我自己的验收清单哪些必须人肉盯每次 AI 生成完 UI我会按下面这张清单过一遍缺哪块补哪块检查项AI 能做必须人肉确认整体布局结构较好是否与信息架构一致字段展示较好字段名和单位是否准确表单校验一般业务规则和边界条件接口对接不做完全人工设计规范一致性一般色值、圆角、间距、字体无障碍访问较差焦点顺序和屏幕阅读器标签性能较差长列表渲染和接口请求时机这份清单现在被我打印出来贴在工位上。说实话最有价值的几条都是人肉盯的项。AI 可以把页面做得很好看但业务逻辑、接口语义、无障碍体验这些还是得靠懂行的开发者把关。4. 哪些 UI 不能无脑交给 AI4.1 状态复杂、依赖业务规则的交互还是得自己画AI 在处理“看起来不错”的界面方面表现出色但遇到状态多变的交互组件它的表现就没那么靠谱了。举个我真实踩过的例子我让 AI 生成一个“多步骤提交向导”一共三步第一步填基本信息第二步上传附件第三步确认提交要求每步可以回退且回退时保留之前填写的值。AI 生成的代码表面上每一步都对但第一次回退再前进之前填的附件列表就丢了原因是它的状态管理写得过于简单。这种问题特别难排查因为表面上看不出错代码结构也挺清晰只有真实操作到那个分支才会触发。对于这种业务逻辑复杂、状态依赖强的组件我现在一律自己写核心逻辑顶多让 AI 帮忙生成静态骨架然后我手动把状态机和步骤流转补进去。4.2 性能敏感区域长列表和过渡动画另一个我不让 AI 自由发挥的领域是性能敏感区域。长列表的虚拟滚动、树形表格的懒加载、无限滚动分页这些场景一旦处理不好页面会卡顿。AI 生成的列表通常没有性能概念它就是老老实实渲染全量数据数据一多直接就卡住。我记得有个需求是做一个设备运行日志页单次可能返回上千条日志。我让 AI 生成了一次列表页它用了一个很朴素的v-for把数据全渲染出来滚动起来肉眼可见的掉帧。后来我自己换成了虚拟滚动组件又加上了分页加载才把体感拉回来。从此以后凡是跟“大数据量展示”沾边的页面我只用 AI 生成结构真正的数据加载和渲染性能方案一律人工设计。过渡动画也一样。AI 生成的动画选择往往比较大众可能在有的页面适用但和你的交互意图不匹配。动画这种事牵扯到交互反馈的节奏感机器生成的“标准答案”很难带来手感。4.3 设计规范的一致性AI 不读你的规范文档需要你主动喂如果你的团队有成熟的设计系统那 AI 生成完的每个页面基本都需要一套“校准”流程。它可以知道 Element Plus 有哪些组件但它不知道你们团队对按钮圆角、主色色阶、栅格间距的具体要求。最典型的案例是我们团队规定所有弹窗的标题字号必须是 16px按钮主色指定为#2B5BFF页面最小留白是 16px。AI 生成出来的代码经常会给标题 18px、按钮默认色、留白 12px。这不是 AI 水平不够是我没把这些规范写进提示词里。所以我后来会在项目配置阶段就整理一份“风格锚点”把设计 token 全部列出来每次生成页面的时候直接复制到提示词里。次数多了以后AI 在生成结果里对这些 token 的尊重程度明显高了很多。5. 提示词工程在 UI 场景里的具体玩法5.1 一次只生成一个页面不要甩整张设计稿很多人在用 AI 生成 UI 时有一个误区把一整张包含四五个页面的设计稿截图扔给 AI让它全生成出来。结果往往是一团糟因为单次上下文容量是有限的AI 处理不了那么多信息最后输出时要么漏掉细节要么自己编造一些并不存在的元素。我的做法是“按区块拆按页面并”。比如一个管理后台有 10 个页面我不会一次性生成全部而是一次生成一个页面。一个页面里如果包含复杂的图表和表格我也会拆开先让 AI 单独生成图表区域的代码调试通过后再生成表格区域的代码最后我用一个容器组件把它们合并起来。这么做还有一个额外的好处每次生成的任务颗粒度小我审查的成本也低。如果整个页面一次生成出了问题我很难定位是哪一块的提示词写得不到位如果分区块生成哪个环节错了直接重新生成那一个区块就行。5.2 建立一份“风格锚点”让它成为每次生成的默认配置所谓风格锚点就是把 UI 生成过程中必用的视觉参数和交互偏好写成一个可复制的文本块每次写提示词的时候带上去。我自己的风格锚点大致长这样页面风格要求 - 主色#2B5BFF辅助色#00B578#FF6F00 - 背景色#F5F7FA卡片背景#FFFFFF - 圆角卡片 8px按钮 6px输入框 4px - 间距区块间距 16px卡片内边距 16px元素间距 12px - 字体使用系统默认字体栈不做特殊字体加载 - 交互所有按钮要有 loading 状态和 disabled 状态 - 空数据列表页面必须考虑空状态展示不能白屏 - 语言代码中使用 TypeScript组件使用组合式 API。每次生成前把这套锚点配上AI 的输出风格会稳定很多。我最开始没用这套东西的时候同样的页面需求隔三天生成一次出来的代码长得像两个人写的。有了风格锚点之后它生成的代码风格基本保持在同一个调性上我审查起来也轻松。5.3 迭代式返工像带新人一样带 AI我见过很多人用 AI 生成 UI一次不满意就重新生成结果第三次生成出来的跟第一次完全是两个方向。这里的问题出在大家把生成当成了“一次性输出”而不是“多轮对话”。更有效的办法是先把整体结构生成出来然后在同一段对话里逐步提修改意见。比如第一轮按上面的要求生成页面 第二轮把表格操作列的两个按钮合并成一个下拉菜单 第三轮卡片间距从 16px 改为 12px标题改为 15px 加粗 第四轮增加一个“暂无抄表记录”的空状态组件。同一段对话的优点在于AI 会保留前几轮生成的上下文它知道当前页面长什么样你提修改意见时它是在“改动”而不是“推倒重来”。这样就避免了多次生成带来的随机性。这个过程就像带一个刚上手的前端新人第一步给方向第二步看结果第三步给调整意见第四步验收。只不过这个新人的执行速度比真的新人快得多。6. 我踩过的坑和现在的底线6.1 像素级强迫症让 AI 背了不该背的锅刚开始用 AI 生成 UI 的时候我犯过一个比较蠢的错误为了让 AI 输出版本无限接近设计稿我一轮接一轮地让它调像素左边对齐了右边又差两像素改完间距字体又歪了。来回折腾了七八轮最后我手动改了五处样式就全部搞定。那次之后我总结出一个经验AI 生成的界面视觉方向可以要求但像素级细节不要追求通过“重新生成”来修正。设计稿和最终实现之间有太多上下文信息AI 看不到设计稿你描述得再精确它也只是在凭概率推算。与其反复让它猜还不如自己把手伸进去按 F12 改两下速度更快结果也更可控。我的底线是AI 负责把布局、结构、组件选型、状态骨架搭好视觉细节的打磨交给浏览器调试工具人工完成。这条底线让我省了很多时间也少了很多没必要的沮丧。6.2 我现在对 AI 生成 UI 的验收底线结合这几个月的实操我现在对 AI 生成 UI 的验收底线大概是三条。第一生成的代码必须能直接跑起来不能出编译错误如果 AI 生成代码时依赖了不存在的组件我不会浪费时间去修会直接让它重生成。第二业务逻辑不能写在页面组件里必须抽到独立的组合式函数或 service 层这个靠 AI 自觉很难通常需要我手动抽取。第三涉及用户输入的组件必须有基本的校验能力和状态反馈不能有一个裸奔的按钮。只要这三条通过我就认为这版 AI 生成结果可以进到人工精修阶段。至于样式美观度反而是最不着急的一环因为那本来就是浏览器调试工具最擅长解决的问题。6.3 这个变化对我工作方式最直接的影响说到最后我其实不太关心“AI 未来会不会取代前端开发”这个问题因为替代的逻辑不是按岗位来的而是按任务来的。AI 已经把“拼组件、调样式”这类任务消化了大半那我自然就把时间挪到更有价值的地方去梳理业务状态、设计交互反馈、优化渲染性能、做无障碍适配。现在接到新页面需求我心里默认的流程是“先想怎么描述再让 AI 生成然后我做工程化审查”。这个流程的爽点在于我再也不会因为页面数量多而感到麻木了因为每一张页面的主体代码生成速度极快我的精力花在了真正需要判断力的事情上。这种工作方式的转变在我看来比 AI 本身更能提高生产力。