从“不想拼 UI”到“真香”我用 AI 辅助界面开发的完整工作流先声明一下我不是来唱反调的也不是来吹“AI 马上取代前端”的。我就是个做了七八年 Web 和客户端开发的普通开发者这几年大大小小的项目也做了十几个从后台管理系统到面向 C 端的 H5、小程序都碰过。今天想聊的是我自己从“死磕 UI 代码”到“用 AI 协作写界面”这段真实经历里的思路转变、具体做法和踩过的坑。如果你也干过这种事——为了一个弹窗的圆角在浏览器里调了半小时参数因为两个按钮没对齐又重新排了一遍 flex 布局或者每次拿到设计稿都想把设计师拉黑——那你应该能懂我在说什么。是的这种事我以前经常干干到一度怀疑自己是不是不适合干这行。但自从我把 AI 系统地引入到 UI 开发流程之后情况开始变了。先说结论AI 不会帮你自动把设计稿变成完美像素级还原的页面但 AI 可以把“从设计意图到可用代码”的中间过程压缩一大半。真正拉开效率差距的不是 AI 能跑多快而是你会不会把需求拆解成它听得懂的话以及你懂不懂怎么验收它产出的代码。1. 先聊聊“拼 UI”这件事为什么让人心累1.1 传统 UI 开发的问题不是“写代码”而是“翻译”很多非技术岗的朋友可能以为前端程序员的工作就是把设计稿“画”成网页。如果你也这么想那说明你低估了这个过程的复杂程度。设计稿是静态的、理想化的而页面是动态的、充满边界的。一个按钮在 Figma 里是华丽的渐变加投影到了真实浏览器里要考虑的却是点击状态、加载状态、禁用状态、文字溢出、屏幕适配、键盘弹起遮挡……这些问题没有一个是设计师会替你提前想好的。换句话说“拼 UI”的大部分精力不是花在“把样式写出来”上而是花在把高保真设计“翻译”成一套健壮、可维护、能应对边界情况的界面系统。这个过程里面布满了隐性成本一个输入框在移动端的 focus 样式、一个列表在数据为空时的占位、一个弹窗在连续快速点击时的防抖——每一样都像鞋子里的小石子走的时候不觉得积累多了真要命。以前我做中后台项目一版页面下来少说得两三天。其中真正“设计”的时间可能只有半天剩下的时间全在跟 CSS 纠缠为什么这个 flex 布局在 Safari 里和 Chrome 里表现不一样为什么表格在数据多了以后出现滚动条把表头顶歪了为什么明明设置了z-index: 999弹窗还是被遮住了这些问题用搜索引擎能搜到答案但你首先得知道自己该搜什么。所以我常说拼 UI 难的不是代码而是“把不确定的需求变成确定的界面行为”这一环。而这一环恰恰是 AI 目前最擅长协助的部分。1.2 效率瓶颈的本质重复劳动太多决策太少再往深挖一层传统手工拼 UI 的效率瓶颈其实是大量“重复劳动”占据了思考空间。每个表单页面的布局逻辑大同小异每个列表页的分页逻辑如出一辙每个弹窗的遮罩层和关闭按钮更是千篇一律。你写第一张表单的时候觉得新鲜写第五张的时候就只剩下麻木了。麻烦的是这些重复劳动虽然技术含量不高但仔仔细细写一遍很耗时间不写又会出问题。AI 的到来对我来说最大的价值不是“帮我把代码写出来”而是把这类重复劳动从我的工作台面上移走了。我不再需要亲自把时间耗在基础组件拼装上而是可以把省出来的精力放到交互设计、性能优化、状态管理这些真正影响产品质量的地方。我甚至可以说AI 让我重新找回了做界面开发的“设计感”——因为我不再是代码搬运工了而是变成了那个对最终结果负责的人。2. AI 辅助 UI 开发的核心思路2.1 一句话概括我现在的干活方式AI 负责“铺量”我负责“验收”在说具体工具和步骤之前得先把思路理清楚。我见过不少朋友用 AI 写页面翻车原因几乎都是同一个期望 AI 一次生成完美代码然后一把梭直接用。结果 AI 给的代码跟设计稿差得离谱或者能跑但漏洞百出于是得出结论“AI 不行还得手写”。我的经验恰好相反。我从不指望 AI 一次生成“完美”的代码我指望的是它快速生成一个“正确骨架”的代码——结构合理、命名清晰、覆盖了大部分基础场景的骨架。然后我在这个骨架上做局部修改、补齐边界情况、优化交互细节。这个过程有点像一个经验丰富的老厨师带徒弟徒弟先把菜备好、切好、按步骤下锅师傅最后调味、看火候、摆盘。你说师傅重不重要重要。但如果没有徒弟师傅一天也炒不了几桌菜。AI 就是那个手脚麻利的徒弟我是掌勺的师傅。这个思路听起来简单但真能落地的人不多。很多人卡在“不知道该怎么指挥徒弟”也就是提示词写得稀碎需求描述得含含糊糊。AI 猜不到你想要什么它只能根据你给的信息尽力给一个“最可能正确”的结果。你给的信息越准确它产出的东西就越接近你的预期。2.2 选择适合 UI 开发的 AI 工具市面上的 AI 编程工具我前前后后试过不少像 GitHub Copilot、Cursor、V0、通义灵码、讯飞星火、文心快码等等都有接触。实话讲没有哪一款是“全知全能”的每款都有自己的脾气和适用场景。我自己目前的主力工具是 Cursor 加通义灵码的组合前者用来进行深度代码生成和重构后者用来做一些快速问答和代码解释两者搭配着用效率最高。选工具的时候我总结出了三个最实用的判断标准上下文理解能力能不能记住项目里的技术栈、目录结构、组件命名规范。这会直接决定生成代码的风格和接口是否贴合你的项目。生成代码的完整度是写几个零散的函数片段还是能补齐整个页面的完整结构。后者显然更省力。修改迭代的便利性能不能针对已有代码做局部修改而不是每次都要整文件重写。在真实项目里我更看重第一点。因为中后台项目的技术栈、组件库、路由规则基本都是约定好的如果 AI 不了解这些约定它生成的代码往往是“美丽废物”——单独看每一行都对但放进项目里怎么都不对劲反而要花额外时间去改。2.3 没有捷径但有路径UI 开发的标准 AI 工作流我把自己在用的这套流程固化成了四个步骤几乎适用于所有类型的界面开发任务需求描述把设计稿里的关键信息转译成文字越具体越好。骨架生成让 AI 生成页面的整体结构和主要布局代码。局部迭代针对细节交互、样式调优、状态逻辑逐块让 AI 修改直到自己满意。人工验收把代码放进真实环境里跑一遍检查边界情况和异常表现。这四个步骤里第一步和最后一步是必须由人完成的中间两步可以放心大胆地交给 AI。有意思的是很多人第一步就做不好。不是因为他们不懂设计而是因为他们太习惯“看图说话”反而不知道该怎么把图里的信息翻译成文字。接下来我就拿一个真实案例把这四步完整跑一遍给你看。3. 实操一个真实后台页面从需求到落地3.1 需求场景做一个“用户管理”列表页方便演示就拿后台管理系统里最常见的“用户管理”页面来说。设计稿大概是这样的左侧一个侧边栏顶部一个顶栏右侧主区域是一个用户表格表格上方有几个筛选条件框和一个“新增用户”按钮表格下方有分页。一个非常典型的 CRUD 页面看起来好像很简单但要手工写出来光是不出错这一点就够让人头疼的。如果换成以前我的套路是打开一个旧的类似页面复制粘贴然后改改字段和接口。但这样做的坏处很明显改完之后页面上可能残留老项目的样式问题而且代码风格混杂后面维护的人会很想骂人。现在有了 AI我的做法完全不一样。3.2 第一步把设计稿“翻译”成需求描述我把自己写提示词的“套路”拆给你看。一个高质量的 UI 生成提示词至少得包含下面四个关键信息基础信息项目类型、技术栈、使用的组件库。比如“这是一个后台管理系统的用户管理页面技术栈是 Vue 3 Element Plus”。布局结构页面由哪些区块组成区块之间是什么关系。比如“顶部是搜索区包含用户名、手机号、状态三个筛选项和一个搜索按钮下方是操作区右侧有一个新增按钮再往下是表格区和分页器”。交互逻辑点击、输入、选择之后会发生什么。比如“搜索按钮点击后调用接口刷新表格数据新增按钮点击后跳转到新增页面”。字段明细表格需要展示哪些字段大致的数据格式。比如“表格列包含用户名、手机号、状态、注册时间、操作操作列里有编辑和删除两个按钮”。把上面这些串起来我当时实际用的提示词长这样请生成一个用户管理列表页面技术栈为 Vue 3 Element Plus TypeScript。 页面主体布局采用 el-container内部是 el-main。 搜索区域包含 1. 用户名的输入框placeholder 为“请输入用户名” 2. 手机号的输入框placeholder 为“请输入手机号” 3. 状态的选择框下拉选项全部、正常、禁用 4. 一个“查询”按钮点击后触发 refresh 方法重新拉取列表 操作区域在表格上方右侧包含一个“新增用户”按钮 表格列依次是用户名、手机号、状态用 el-tag 展示、注册时间、操作编辑、删除按钮 表格下方是分页支持 pageSize 切换和页码切换这段提示词看起来平平无奇但它把你脑子里的“页面长什么样”有效变成了文字。你把这段文字扔给 AI 之后它基本能给你撸出来一个能跑的雏形。有人可能觉得“这我还不是要自己想好AI 也没多聪明啊”。但请注意想清楚页面结构原来就是我自己该干的事现在我只是把它写成了文字而已省掉的是我亲自去写那些重复的模板代码的时间这已经很值了。3.3 第二步拿到 AI 生成的骨架代码之后先别动先跑起来看效果AI 生成完代码之后我强烈建议你先别急着改。第一件事是把它放进项目里跑起来看一眼实际渲染的效果。这一步能筛掉很多一眼假的问题——比如布局塌了、组件没引入、样式没生效等等。这里有个小技巧如果项目里还没有安装对应的组件库先装好再让 AI 生成代码。不然 AI 会默认你一切环境都准备好了生成出来的代码在运行时会疯狂报错你还得反过来排查是不是 AI 写错了浪费时间。还有一点要提前确认AI 生成代码里引用的接口和工具函数项目里到底存不存在。以前我用 AI 生成带请求逻辑的代码时它经常顺手给我编一个request工具函数或者api模块出来。你要是没注意直接复制运行页面直接白屏报错。解决办法是提前告诉 AI 项目里已有的请求函数名和路径宁可多写几行说明也别让它自由发挥。3.4 第三步局部迭代把“能看”变成“好使”骨架跑起来之后真正的打磨工作才开始。这时候我是这么跟 AI 协作的一次只抛给它一个问题绝不一口气把所有要求全塞进去。比如我会这样逐步精细化调整“表格里的状态列把展示方式从普通文本改成带颜色的 el-tag正常显示成绿色禁用显示成灰色”“查询区域和表格之间间距太大了把搜索区域的外边距调成 0用内边距撑开”“分页器改成左对齐而不是默认的居中对齐”“新增按钮点击之后跳转到 /user/add 路由这个路由已经存在”每次只提一个要求的好处是AI 能明确知道你指哪一个区域生成的结果更精准而且不容易把其他已经写好的地方改坏。有人可能会觉得这样一个个改太麻烦但实际操作起来一个要求从发出到拿到修改结果也就十秒二十秒的事比你自己定位元素、改样式、刷新预览还是快得多。而且这种局部迭代的方式天然避免了一大类问题——“AI 改一个地方的时候顺手把别的逻辑弄乱了”。3.5 第四步人工验收重点关注边界场景页面能跑、能看、交互也符合预期之后最后一关是人工验收。我做 UI 开发这么多年自己给自己定的验收清单已经固化了在这里分享给你空数据状态表格没有数据时页面能不能正常显示“暂无数据”而不是出现一片空白或者报错数据加载状态接口慢的时候有没有 loading 提示表格有没有在加载中显示骨架屏或者加载动画异常数据处理如果一个字段的值很长比如用户名特别长表格是否会换行或者撑破布局移动端适配虽然后台系统一般不主攻移动端但宽度缩小到一定程度时页面布局会不会崩掉这些细节AI 生成的代码通常考虑不到或者说它没动力去考虑。原因很简单它没见过你的真实数据不知道你后端接口会返回什么稀奇古怪的东西。所以这一步必须你来把守。说实话就算以后 AI 再进化几个版本我也不会把这一步完全交给它。界面是用户和产品之间的桥桥稳不稳最终还是得人工踩一踩才知道。通过上面这个案例你应该能感受到AI 生成的不是最后成果而是半成品。它的意义在于帮你跑完了从 0 到 80 分的路程剩下 20 分由你来补足。可别小看这个变化很多项目死在从 0 到 80 分这一段路上了太耗费纯手工的时间了。4. 我踩过的坑和常用的“避坑指南”4.1 坑一提示词里不加技术栈让 AI 随便发挥这是我最初犯的错误之一。有一阵子我图省事直接丢给 AI 一句“帮我写一个用户列表页面”结果它默认用的是 React Antd 技术栈。可我那会儿用的明明是 Vue 2结果生成的代码根本没法用。后来我学乖了每次在提示词的开头就固定写清技术栈和版本比如“Vue 3 TypeScript Vite Element Plus”这句话相当于给 AI 划了一条工作边界后面生成的内容基本就规规矩矩了。4.2 坑二生成的样式没生效就以为是项目环境有问题有一次我让 AI 给一个按钮加上 margin 间距结果页面纹丝不动。排查了大半天最后发现是项目里有个全局样式文件设置了元素重置把那个默认间距覆盖掉了。从那以后我就记住AI 生成的样式有时会被项目里的全局样式影响不生效不代表代码写错了更可能是被优先级更高的规则盖住了。排查这种问题的时候F12 打开控制台看最终的计算样式比自己盲猜强得多。4.3 坑三让 AI“自由发挥”做一些决策性的设计改动一开始我贪方便会让 AI 顺手帮我把某个按钮的样式“优化一下”或者把某个模块“设计得更美观一些”。这类描述对 AI 来说太模糊了它做出来的东西经常风格诡异跟页面整体气质不符。后来就改成涉及观感、风格、品牌这些主观判断的东西我都自己拍板绝不让 AI 替我决定。AI 比较适合做偏执行的任务比如“这里的间距改成 16px”“这个文字颜色换成 #333”这类指令明确清楚执行起来几乎不会出错。4.4 坑四一次让 AI 做太多事结果代码乱成一锅粥有一次我贪多让 AI 一次性“把列表页改成支持多选、批量删除、右侧新增工具栏并加上行内编辑”结果生成的 300 多行代码直接把我整懵了里面三分之二的逻辑都是错的。这次教训之后我严格执行“一次只改一点”的原则把大需求拆成五六个小需求每改完一个就跑一下测试确认没问题再继续下一个。虽然看起来多花了几步操作但实际上出错率大幅下降整体速度反而更快了。4.5 避坑小技巧养成代码审查洁癖AI 生成的代码我从来不会直接信任。每次拿到代码必做三件事第一快速扫一遍整体结构看有没有明显的重复代码或者死代码第二搜索一下可疑的硬编码例如奇怪的日期格式、ip 地址、测试账号等等见到就删第三运行起来把主要的交互路径都点一遍包括正常操作和异常操作。这个过程听起来繁琐但三分钟以内就能搞定能保证你最后提交到项目里的代码是干净的。这也是我对自己代码库的基本要求——不管代码是手写的还是 AI 生成的最终对质量负责的都是我。5. AI 辅助 UI 开发的下一步和一点个人心得写到最后聊聊我现在的整体状态吧。我从“不想拼 UI”到现在“用 AI 拼 UI但拼得开心多了”中间其实没有太大的技术跃迁更多是心态和习惯上的转变。我开始把 AI 当成一个随时在线、不会觉得麻烦的初级工程师而不是一个提词机或者魔法棒。这种预期调整之后用 AI 做 UI 开发变得踏实了很多它写得不好我知道怎么指挥它改它改错了我知道怎么定位问题它搞不定的我自己补上就是了。如果你现在也正被 UI 开发折磨得心烦意乱我建议你可以从一个最简单的页面开始尝试这套流程——比如先做一个登录页把结构描述给 AI跑起来看效果再逐步调整。不用一步到位也不需要一开始就用最新的工具。先把“跟 AI 协作”这层心理障碍打破后面的事情就好办多了。我自己下一步的计划是想把 AI 往后端接口对接和联调环节再深挖一下争取把从“拿到设计稿”到“前后端联调完成”的整个流程再压缩一半时间。这个目标看起来不小但说实话放到几个月以前我想都不敢想。现在觉得说不定真能成。这次先分享到这儿。后边如果把这套流程跑得更熟练了有了新的心得和踩坑经验再回来继续聊。