自从有了 AI我就再也不想拼 UI 了……这话听起来有点像标题党但干过前端、干过全栈的朋友应该能get到我的意思。我说的“拼 UI”不是指用设计软件拼视觉稿而是指那种打开编辑器面对着空荡荡的页面文件从零开始写结构、写样式、调间距、改圆角、适配宽度、对齐表单、处理加载态、空态、异常态……一套下来人已经麻了的体验。以前这是每个前端工程师和全栈开发者的日常AI 出现之后这套工作流的底层逻辑彻底变了不是“省了一点时间”而是“我再也不愿意回到那种方式了”。这篇文章想跟你聊聊我过去大半年把 AI 塞进 UI 开发流程里的真实经验用了哪些工具、踩了哪些坑、现在一个人怎么用 AI 把一个后台管理系统、一套营销落地页、一组业务组件从零拼出来。不管你是被 UI 折磨过的后端、正在学前端的新人还是想提效的独立开发者应该都能从这里找到能直接用的方法。1. 内容整体设计与思路拆解为什么 AI 拼 UI 这件事成立先说说底层逻辑。UI 开发这个活儿本质上是把设计稿或者脑子里的一套模糊想法翻译成浏览器能理解的结构化代码。这个过程里大约有七成是“确定性翻译”布局是 flex 还是 grid间距是 8 的倍数还是 4 的倍数按钮有几种状态表单有哪些字段……这些在成熟团队里往往已经被组件库和设计规范固定下来了剩下三成才是真正需要人肉判断的东西比如交互细节、异常状态、信息层级。AI 最擅长的恰恰就是那七成确定性工作。你给它一个清晰的描述它能直接从脑子里“见多识广”的代码记忆里调出一套符合主流实践的实现这比人从零开始敲快太多了。另一个关键点是现在 AI 拼 UI 的成熟度已经跨越了“能出代码”到“能出可用代码”的门槛。早期用 ChatGPT 生成前端代码经常是看起来像那么回事一跑就报错组件库版本对不上样式类名是猜的。但这两年模型迭代之后配合 Cursor、Windsurf 这类能读取整个项目上下文的编辑器AI 生成的代码已经可以做到直接粘贴进项目就能用甚至能自动匹配你项目里已有的设计变量、组件命名、API 结构。这意味着它不再是一个“玩具”而是一个真正能承担生产力角色的伙伴。我自己的实践思路可以总结成一句话**让 AI 干脏活累活让自己把精力集中在判断和打磨上。**具体来说就是分四层——第一层用 AI 生成页面骨架和基础组件第二层用 AI 处理重复性修改比如批量调整样式、统一间距、补状态第三层用 AI 做跨文件联动比如新增一个表单页它能顺带把路由、接口调用、类型定义一起补上第四层人来做最后的体验评审检查那些 AI 看不出来的东西——业务语义对不对、操作流程顺不顺、边界情况有没有覆盖。这套分工方式我实测下来效率比纯手工至少快三倍而且质量更稳定。2. 核心工具选型AI 拼 UI 的几种姿势和它们的适用场景很多朋友问我说AI 拼 UI 到底用哪个工具其实不存在一个万能答案关键在于你想让 AI 以什么姿态参与你的工作流。我按使用场景分了三类你根据自己的情况选就行。2.1 编辑器内联 AI日常开发的主力目前我用得最多的是 Cursor 和 Windsurf 这种 AI 原生的编辑器。它们的特点是能读取你整个项目的代码库理解你的目录结构、组件写法、依赖版本然后在你写代码的过程里实时给出建议。对于拼 UI 来说这意味着你写一个页面的时候AI 已经知道你项目里 Button 组件长什么样、设计变量叫什么、接口返回的数据结构是啥它生成的页面会自动贴合项目风格而不是给你一堆陌生的新东西。这类工具还有一个很实用的能力用自然语言直接改 UI。比如你做完一个列表页觉得表格太挤了直接在对话框里说“把 padding 统一改成 16px行高抬高一点每一行加个 hover 背景色”它就会精准地改到对应文件里而且只改该改的地方。这个体验非常接近“指挥一个熟悉你项目的初级工程师干活”前提是你得给它足够清晰的指令。2.2 设计转代码工具从视觉稿直接出页面第二类是 Figma to Code 和 v0 这类工具。它们的场景是你手里有一张设计稿或者一个憋了很久的产品想法希望快速得到一个能跑的页面原型。v0 这类工具厉害的地方在于你扔给它一句“帮我做一个 SaaS 后台的仪表盘页面包含数据卡片、趋势图、最近订单列表”它能直接生成一个完整、美观、可交互的页面还自带响应式适配。这特别适合产品初期探索、快速验证想法或者给后端同事做临时演示界面。我自己用的一个典型场景是接了个外包项目客户只给了需求描述没给设计稿。我直接用 AI 生成几版不同风格的页面让他选选完之后再精细调整。以前这一步需要找设计师出图至少一周现在一个下午能出好几版沟通成本也大幅下降。不过要注意这类工具生成的页面是“通用好看”如果要对接自己项目的设计规范还是需要做一轮适配改造不能无脑直接用。2.3 AI Agent自动执行完整任务再往上一个层级是 AI Agent比如 Cline 这类能自主完成多步骤任务的工具。你可以给它一个大目标“帮我实现用户管理模块包含列表、搜索、新增、编辑、删除的完整流程用项目里现有的组件接入 userApi”它会自己去读相关文件、设计数据结构、生成页面、改路由、补接口调用整个过程像是一个员工在干活你只需要在每个关键节点验收一下。这类工具最惊艳的场景是处理“跨页面、跨模块的联动需求”。以前改一个页面牵扯到七八个文件手工去改很容易漏掉一两个AI Agent 因为能自主扫描项目结构它会主动把相关的文件都找出来一起改。当然它也会犯错所以它的适用范围是“有明确验收标准的任务”而不是“需要大量模糊决策的任务”。这个边界你心里得有数。3. 实操过程与核心环节实现从零用 AI 拼一个后台页面光说理论没意思我拿一个最近实际做的“订单管理页面”完整走一遍流程看看 AI 是怎么被用起来的。这个页面是我们一个电商后台的一部分包含筛选条件、订单表格、分页、批量操作还有一个详情弹窗。我把每一步的操作、给 AI 的提示词、以及中途踩的坑都写出来你可以直接照着试。3.1 第一步让 AI 先梳理设计约束很多人用 AI 生成页面失败不是因为 AI 不行而是因为你自己没想清楚就开干了。生成出来的东西自然也不符合预期。我的习惯是先不急着让 AI 写代码而是让它帮我梳理约束条件。我会在对话里这样问我项目用的是 React TypeScript Ant Design 5设计规范里主色是 #1677ff 间距体系是 4 的倍数表格密度是默认的 middle。 我现在要做一个订单管理页面包含搜索区订单号、状态、时间范围、 订单表格订单号、客户、金额、状态、创建时间、操作列、分页、批量操作。 请先帮我列一下这个页面的核心要素和需要注意的边界情况。这一步的目的有两个一是验证 AI 对你项目的理解是否正确二是让 AI 帮你把可能遗漏的业务要素补齐。比如它会提醒你“批量操作按钮应该在选中行之后才置为可用”“时间范围默认应该是最近 30 天”“金额展示需要考虑小数位处理”这些细节。这些在需求不明确的时候非常有用等于让 AI 帮你过了一遍产品需求。3.2 第二步分段生成页面骨架约束确认之后就开始生成代码。我强烈建议不要一次让 AI 生成整个页面而是分成几块来每块生成完先看一眼结构再继续下一块。因为一次性生成的代码量太大一旦风格不对或者结构跑偏返工成本极高。我通常会分三次第一次生成搜索区基于上面的约束生成订单搜索区代码。要求 - 使用 Form Row/Col 布局一行最多 4 个字段 - 订单号用 Input状态用 Select选项待支付/已支付/已发货/已完成/已取消 时间范围用 DatePicker.RangePicker - 操作按钮区放查询和重置重置后要恢复默认时间范围 - 用 TypeScript 写类型定义 - 不用写业务请求逻辑接口函数用占位符第二次生成表格区接着生成订单表格区。要求 - 使用 Ant Design Table列配置写在 columns 数组里 - 金额列右对齐保留两位小数展示人民币符号 - 状态列用 Tag 展示不同颜色 - 操作列包含“查看详情”和“退款”退款按钮在已退款/已取消状态下禁用 - 加上 loading 状态和 rowSelection 批量选择第三次生成详情弹窗最后生成订单详情弹窗。要求 - 用 Drawer 而不是 Modal因为详情内容比较多 - 展示订单基础信息订单号、客户、金额、状态、商品明细列表、物流信息 - 物流信息没有的时候就显示“暂无物流信息”的空状态这样三段生成完之后把代码合并到同一个页面文件里逻辑清晰结构也可控。整个过程中 AI 生成的代码基本能直接运行偶尔会有一些小问题比如 import 漏了顺手补上就行。3.3 第三步让 AI 自我检查并补状态页面骨架搭完之后有一个非常关键的步骤就是让 AI 把各种状态和边界情况补齐。这一步是 AI 拼 UI 和传统模板工具最大的区别——它不只给你一个静态页面还能帮你把交互逻辑补全。我的提示词一般是这样的帮我检查这个订单管理页面看有没有遗漏以下状态 1. 搜索时 loading 状态 2. 表格为空时的 empty 展示 3. 批量操作按钮在未选择时的禁用状态 4. 时间范围选择后查询参数的处理 5. 分页变化和筛选条件变化时接口参数的联动 请逐条检查并给出需要修改的代码。这一步给的是什么其实就是把你脑子里那些“老手会注意到的细节”变成显式的检查清单让 AI 逐项核对。实测下来AI 对这类指令的执行准确度非常高因为它不需要创造性地设计东西只需要按给定的标准把遗漏补上。这个过程比你手工 review 一遍快得多而且覆盖面更全。3.4 第四步接入真实接口页面静态部分都搞定之后接下来就是把它接上真实的接口数据。很多人的做法是自己动手改因为觉得这块逻辑复杂AI 做不了。但实际上 AI 在接入接口这块也挺靠谱的关键在于你得把接口的细节告诉它。我一般是直接把后端同事给的接口文档片段贴给它这是订单列表的接口定义 GET /api/orders 参数: page(页码), pageSize(每页条数), orderNo(订单号), status(状态), startTime, endTime(时间戳) 返回: { code: 0, data: { list: OrderItem[], total: number } } OrderItem 的字段: id, orderNo, customerName, amount, status, createdAt 请帮我实现页面里接口调用和状态管理的部分。然后 AI 会生成一套完整的接口调用逻辑包括参数组装、loading 管理、分页重置的边界处理、错误提示等。这一步它的完成度相当高因为这是标准的数据请求模式属于它训练数据里见过无数遍的内容。你只需要核对一下字段名对应关系是否正确基本就能跑通了。3.5 第五步整体联调和视觉打磨最后一步是联调和打磨。我一般会在浏览器里把页面每个状态点一遍发现问题就直接截图或者描述给 AI让它改。这里有一个非常好用的技巧描述问题要具体到“文件组件现象期望”。别只说“这页面不好看”要说“表格列之间的间距太大了把 columns 里的 padding 整体从 16px 改到 12px”。AI 很擅长执行这种精确修改但很不擅长猜测“你觉得什么样算好看”。另外关于视觉打磨有一点个人心得AI 生成的页面视觉上是够用的但离“精致”还差一口气。这口气通常体现在细节上——hover 状态的过渡动画、加载骨架屏的闪烁节奏、空状态的插画和文案、弹窗关闭时的微交互。这些我会自己手动补一点点因为花不了多长时间但对整体质感的提升非常明显。我的做法是让 AI 保证“能用、规范、完整”自己在“有温度、有细节”的地方出手。4. 常见问题与排查技巧实录AI 拼 UI 踩过的坑AI 拼 UI 不是一个零事故的过程我踩过的坑能列一箩筐。这里挑几个最有代表性的连同排查方法一起整理成一张速查表希望能帮你少走点弯路。问题现象根本原因排查与解决思路生成的代码引用了不存在的组件属性模型对组件库版本的记忆停留在旧版本在提示词里明确写“基于 Ant Design 5 的 API不确定的 API 先去查官方文档”页面代码能跑但布局乱成一团忽略了父级容器的宽度和滚动上下文让 AI 先检查页面根容器的布局约束再生成内部结构AI 修改一个地方连带破坏了其他功能修改时没有掌握完整上下文使用编辑器的 Apply 模式而不是全文件覆盖或者去改动前先 commit 一份响应式适配在移动端完全崩掉只考虑了桌面端的布局逻辑单独让 AI 针对移动端检查一遍明确要求“断点 768px 以下重新布局”生成的代码风格和自己的项目不一致没有在约束里说明项目代码风格让 AI 先读项目中已有的一个页面文件要求“保持同样的写法和风格”反复修改之后页面状态逻辑混乱状态提升和组件拆分不合理让 AI 画出一个组件关系和数据流说明而不是让它直接蒙头改4.1 组件库 API 幻觉问题这是最典型的一个坑。AI 对常见组件库的 API 了解很多但它记忆里的版本和你项目里实际的版本可能不一样。在 Ant Design 4 和 5 之间很多组件的用法发生了变化比如 Menu 的 children 改成了 itemsModal 的 visible 改成了 open。如果 AI 按旧版本的写法生成代码虽然语法上对但一跑就报错。解决方法其实很简单在项目里放一份当前组件库的版本说明或者在每次对话里带上“基于当前项目 node_modules 里的实际类型定义来写”。更强力的做法是让 AI 直接读 node_modules 里组件库的 .d.ts 类型声明文件我实测过这个方法能彻底根治 API 幻觉问题代价只是多花几秒钟让它扫描。4.2 AI 改一发动全身的问题用 AI 改代码最烦的情况是你让它改一个按钮的样式结果它把整个页面的布局都重新排了一遍。这通常发生在你选择“让 AI 重写整个文件”的场景里因为 AI 会基于它自己的理解重新生成内容导致和之前的手改完全脱节。我的建议是小的修改用编辑器的局部编辑功能让 AI 只输出需要改的那一段代码大的重构才让它重新生成文件。另外每次改动之前先看一眼 diff确认它没有动不该动的地方。如果发现 AI 频繁越界就在系统提示里加一句“只修改我提到的部分其他代码保持原样不要动”实测能减少七成左右的无谓改动。4.3 视觉细节不可控的问题AI 拼 UI 出来的东西初看往往都像模像样但你要是盯着看会发现一些奇怪的地方两个按钮高度不一样、表格行高忽大忽小、同一层级的文字大小不一致。产生这些问题的原因是 AI 在生成代码时是从“整体想象”出发的而不是从“像素规范”出发的所以它不会主动保证所有细节的严格统一。面对这类问题最实用的解法是建立项目的设计 token 体系并且明确告诉 AI 只用这些 token 对应的值。比如你定义 spacing-base: 4px、font-size-sm: 12px、font-size-md: 14px然后在提示词里说“间距只能使用 spacing-base 的整数倍字号只能使用 font-size 这几个值”。这样 AI 生成的代码天然符合规范视觉一致性会好很多。如果你的项目还没有设计 token趁着用 AI 重构的机会建一套收益远大于成本。4.4 AI 生成代码过度“花哨”的问题很多 AI 生成的 UI 代码有一种通病过度设计。它喜欢给按钮加渐变、加阴影、加动画、加各种 hover 特效恨不得一个列表页都做出大厂首页的质感。这在做后台系统的时候其实是个灾难——不仅视觉上显得杂乱还会影响渲染性能和可维护性。我在提示词里一般会加一句死话“这是一个后台管理系统界面应该克制、清晰、高效不要使用渐变、阴影、动画等装饰性效果保持接近 Ant Design 默认风格的朴素感。”这句话虽然简单但真的能显著改变输出结果。对于不同场景你可以在提示词里提前定好视觉基调后台系统要“克制”营销页面要“有视觉冲击力”工具类应用要“信息密度优先”。AI 对这类风格指令的理解相当到位比你事后一句句改要高效得多。5. 经验与体会AI 拼 UI 对我的工作方式带来了哪些改变工具层面的东西聊完了说点更个人的体会。AI 拼 UI 这件事表面上改变的是效率本质上改变的是我和“UI 开发”这个工作之间的关系。以前写页面我脑子里想的是“这个字段放这里合不合理、这个按钮要不要加个图标”现在的我想的是“这个页面的核心交互是不是简洁、这个状态的处理是否符合用户心智”。说白了AI 帮我把“怎么实现”变成了一句话的事于是我有了更多精力去思考“为什么这么做”。这也带来一个分工上的变化我现在极少从零手写一个页面但我会花更多时间做代码评审。AI 生成的代码我要看一遍、跑一遍、点一遍确认逻辑和边界没有遗漏。这个过程让我对项目的掌控并没有减弱反而因为省去了重复劳动有更多余裕去关注那些真正影响质量的地方。用一句话总结就是AI 不会替你思考但它能把你从打字员这个角色里解放出来。另外还有一个小变化是试错成本降低了。以前做一个新页面从构思到落地需要谨慎再谨慎因为每写一行代码都是时间成本。现在有了 AI我可以在几分钟内生成三个不同版本的布局方案放到浏览器里实际对比后再决定留哪个。这种“随手试”的玩法让很多以前不敢动的重构都变得非常轻松。比如我最近把一个老项目的表格全部换成了虚拟滚动版本以前这种活儿要专门排一两天这次用 AI 辅助一晚上就搞完了而且中途还对比了两种实现方案的性能表现。最后想说AI 拼 UI 这事儿最关键的其实不是工具而是你传递给 AI 的信息质量。你把上下文给得越清楚、约束定得越明确、验收标准列得越具体AI 的产出就越接近你想要的结果。这背后其实是另一种能力的锻炼——把你脑子里模糊的想法变成一句一句清晰的、可执行的指令。从这个角度说能用好 AI 的人本质上还是那个“懂产品、懂交互、懂实现”的人只是打字的手可以歇歇了。我没撤销自己的编辑器但我的键盘确实用得比以前少了。