1. 先聊聊我为什么再也不想拼 UI 了前阵子接了个后台管理系统的前端重构二十多个页面一堆表格、表单、弹窗、标签页。换做以前我的流程大概率是打开设计稿量间距、切图、写样式然后在一个一个div和className里跟像素较劲。这活儿倒不是多难但真心磨人——同样的表格来来回回写四五遍每次只是改改列名和字段。但这次不一样。我把设计稿截图丢给 AI 工具加上几句需求描述一个能跑的页面骨架它直接给我列出来了。我做的只是微调、接接口、处理边界情况。以前一个页面要花大半天现在差不多一两个小时就能交初版。说实话第一次看到 AI 把我平时要写几百行的界面布局在几十秒内生成出来的时候我心里是既爽又慌——爽的是真的省事慌的是这玩意儿以后是不是要把我这行当给卷没了。但我冷静下来仔细用了几周之后发现事情没那么简单。AI 能帮你省掉大量重复的拼装工作但它不是万能的。它生成的东西经常有逻辑硬伤、样式兼容性问题、甚至完全不符合你项目的代码规范。你会用、会用对地方它是效率神器你盲目信任、无脑采纳它反而会给你埋一堆坑。这篇文章不是来吹 AI 的也不是来唱衰的我就想以一个实际做过项目的开发者的身份把这阵子用 AI 生成 UI 的真实流程、工具选型、踩过的坑和一些能直接上手的技巧好好盘一盘。2. 内容整体设计与思路拆解2.1 AI 生成 UI 的几种流派和底层逻辑先说原理。目前市面上所有AI 写 UI的工具本质上都在做一件事把自然语言或视觉输入转成结构化的前端代码。但具体路线分这么几类第一类是LLM 直接生成代码。也就是你告诉 GPT、Claude 这类大模型帮我写一个登录页它直接吐 HTML/CSS 或者 React/Vue 组件。这是最灵活、最通用的方式但问题在于大模型对视觉美感的理解很有限——它知道登录页该有输入框和按钮但它不知道什么配色好看、什么间距舒服。所以这类工具适合生成功能结构不适合直接当设计稿用。第二类是截图/设计稿转代码。你把 Figma 设计稿或者一张高保真原型图丢进去AI 通过视觉模型识别图层、组件层级关系再转成代码。这类工具对 UI 还原度最高但依赖设计稿本身的规范程度。设计稿图层乱七八糟的转出来的代码也乱七八糟。第三类是对话式 UI 生成平台比如 v0、Builder.io 这类垂直工具。它们结合了大模型的自然语言理解能力和预设的组件库、设计系统你描述需求它出界面而且能迭代修改。这类工具最贴近实际开发但通常需要一定的学习成本而且生成结果和你团队现有的代码架构未必兼容。我自己的实际体验是不要纠结于只用一个工具组合拳才是效率最高的解法。设计稿转代码用来起底稿LLM 对话用来调逻辑、补交互垂直平台用来验证交互方案。各有各的适用场景别指望一个工具包打天下。2.2 为什么传统拼 UI的方式效率越来越低传统方式也没那么不堪但是有几个天然的低效点一是重复劳动多。多数后台管理系统的页面骨架都差不多——左侧导航、顶部栏、中间的内容区放个表格、来个表单、配几个弹窗。换个业务字段你就要复制粘贴改一遍。这种活儿没有任何技术含量纯粹占时间。二是联调沟通成本高。写 UI 不只是写界面你还要跟后端对齐字段、跟产品对齐交互细节、跟测试对齐边界场景。这些沟通里有一大半完全可以由 AI 先帮你挡掉。比如 AI 根据接口文档生成模拟数据先保证页面结构和字段对上真正联调的时候问题就少很多。三是改稿成本大。产品改需求一行字的事你要改的可能是一整个组件的结构。AI 生成代码的另一个隐含好处是你让 AI 改比你手动在一坨纠结的 JSX 里精准替换要快得多。至少 AI 不会漏掉一个绑定值也不会改了 A 页面忘了同步 B 页面。我不是说人力拼 UI 没有价值而是说在当下的技术环境里把时间花在拼界面上ROI 真的不高。有那功夫不如去琢磨一下业务逻辑、交互优化或者去把构建流程、代码规范搞扎实——这些才是不可替代的部分。2.3 适合用 AI 生成 UI 的场景和不适合的场景用了几周我大概摸索出哪些场景适合交给 AI后台管理系统的标准 CRUD 页面表格、表单、筛选器、弹窗原型验证阶段的快速页面搭建营销活动页、落地页这类一次性、复用性不高的页面需要快速产出多方案对比设计稿的场景组件库的骨架搭建和基础样式补充不适合的场景也明确对像素级还原要求极高、品牌感很强的官网首页复杂交互动效和状态联动比如拖拽、手势、实时协作画布已有成熟组件库和代码规范的大型项目AI 生成的代码极容易破坏规范涉及复杂权限控制和数据安全的内部系统核心页面一句话总结AI 适合做从无到有的粗坯不适合也不应该直接承担精装修的活儿。把 AI 当实习生用给它最脏最累的土方工程然后你来做砌砖、水电和验收。3. 工具选型解析我实际在用的方案和取舍3.1 主流 AI UI 生成工具横向对比这阵子市面上冒出来一堆工具问的人也多我直接拉个表格梳理一下我实际用过的几款优缺点和适用场景都说清楚工具类型核心优势主要短板适合场景ChatGPT / Claude通用 LLM灵活、上下文理解强、能改逻辑视觉审美弱、缺乏预览调试组件代码生成、逻辑修改、代码解释v0垂直 UI 平台生成即预览、组件体系好、可迭代生成的代码风格偏重、学习成本不低原型方案探索、交互验证Figma AI 插件如 Figma MCP设计转代码还原度高、与设计稿强绑定依赖设计稿规范、代码质量不稳定设计稿转前端代码的初稿截图转代码工具如 Screenshot-to-Code视觉转码单张截图生成快、直观复杂页面结构还原差、可复用性弱临时需求、单页内还原参考代码生成插件如 Cursor FittenIDE 内嵌直接在编辑器里改、实时补全依赖模型能力、容易打断思路开发过程中即时生成、重构辅助这里面有意思的是 Fitten这阵子 Pycharm 和 VSCode 圈子里都在聊。它属于 IDE 内的 AI 插件不是在单独的网页里生成代码而是直接在编辑器环境里帮你补全、生成、改代码。对写 UI 的人来说好处是生成完马上就能在本地跑起来看效果不用来回切换平台。坏处是它更擅长接着你已有的风格写而非从零创造一个视觉惊艳的界面。3.2 为什么我最终选择了多工具组合而不是单押一个说实话我也试过只用一个工具走完全流程但每次都卡在某个环节上。这里有个底层原因UI 生成链路里需求理解、结构生成、视觉呈现、代码落地本质上是四个不同的任务没有哪个单一模型能在四个任务里同时做到优秀。比如说ChatGPT 对自然语言的理解和代码生成的准确性很强但你在它那儿生成一个页面看不到预览布局有没有错位、间距是否合理完全不直观。v0 的预览体验很好而且能对话式改版但它默认生成的是 Tailwind 某种特定组件体系的写法放到你已有的 Vue 或者 Ant Design 项目里结构风格全是冲突的。截图转码工具还原性不错可一旦设计稿不规范、图层命名混乱它生成的代码你根本没法维护。所以我的固定打法变成这样用v0 或截图转工具先出一版视觉草稿不做代码只看布局和模块排布是否合理把这个视觉稿的关键信息结构、模块、交互点用文字描述给ChatGPT/Claude让它按你项目的技术栈组件库、样式方案、目录结构生成代码生成的代码落到 IDE 里用Cline / Fitten做二次迭代改样式、补交互、修接口对接最后自己手动过一遍细节重点检查响应式断点、状态管理和边界条件。这套流程下来效率和质量的平衡是最好的。当然它也有个前提你自己得懂代码得有判断 AI 生成内容好坏的能力。这一点我必须劝一句——别刚入行就指望着全靠 AI 生成 UI它只会放大你的无知。4. 核心细节解析与实操要点4.1 提示词的设计这是 AI 生成 UI 的最关键一环很多人吐槽 AI 生成的界面太丑、太粗糙我看下来一半以上是提示词的问题。你让它写个登录页它当然给你个四平八稳的登录框——输入框、密码框、登录按钮完事。但你要是告诉它写一个极简风格的登录页背景为浅灰色渐变卡片式居中布局圆角较大自带品牌 Logo 区域支持记住密码和第三方登录快捷入口它产出的东西立马不是一个档次。总结几个我实测好用的提示词技巧第一给足上下文别让它猜。技术栈、组件库、样式方案、目标用户这些全写在提示词里。比如用 React 18 TypeScript 写样式用 Tailwind布局参考 Ant Design 的 ProTable目标用户是运营人员需要突出数据可读性。信息给得越具体代码越贴近你的需求。第二拆分任务一次只做一件事。别让它一口气把整个后台管理系统生成完让它先写左侧导航和顶部栏再写内容区的筛选表单再写表格列配置。每拆一次生成质量都会上一个台阶。第三让它先出方案再写代码。你可以问它这个页面你觉得应该包含哪些模块每个模块的核心交互是什么让它先帮你梳理结构确认思路没问题再让它生成具体代码。这一步能省掉大量来回改的功夫。第四用负面约束去引导。直接告诉它不要用圆角不要用阴影不要超过三种主色比跟它说设计得高级一点有用得多。AI 对抽象形容词的理解很差但对具体的行为约束执行得很好。我在这里放一个实际可复制的提示词模板用来生成一个数据列表页面请用 React TypeScript Ant Design 5 写一个用户管理列表页面。页面上方是筛选区域筛选条件包括用户名、状态、注册时间范围下面是表格区域列包括用户名、手机号、状态标签、注册时间、最后登录 IP、操作编辑/禁用/删除。状态用 Tag 组件展示禁用操作需要 Popconfirm 确认。表格数据用 mock 数组即可字段类型定义清楚。页面整体风格要清爽栅格间距使用 16px卡片无阴影、边框颜色 #f0f0f0。响应式只需要考虑 1280 以上宽度。实测下来这段提示词生成的代码基本可以直接用只需要在接口对接时把 mock 数组换成真实请求。4.2 设计稿转代码时的常见坑与预处理手段截图转代码的工具用起来爽但坑也不少。我自己踩得最深的一个坑是设计稿里看着合理的布局转出来的代码经常是用绝对定位和硬编码尺寸堆出来的。比如一张卡片居中、按钮贴右下角AI 可能直接给你position: absolute; bottom: 20px; right: 20px一旦页面宽度变化布局就散架。解决办法是在让 AI 转码之前先对设计稿做预处理确认设计稿的图层结构清晰避免过多嵌套的分组和自动布局把需要适配的断点写进提示词里明确告诉它哪些模块要响应式让它优先使用 Flexbox 和 Grid而不是定位如果设计稿里有重复出现的组件卡片、按钮、输入框先单独让它提取成组件再拼装到页面里。另外一个实用技巧不要直接把整页截图丢进去按模块截。很多工具在处理复杂整页时对下方内容的重构质量明显下降。你按模块拆分后分别生成最后自己拼装反而比一次生成整页更高效也更容易调样式。4.3 代码生成后的降噪处理AI 生成的代码还有一个普遍问题就是冗余。它会生成很多无关紧要的 wrapper 层或者写一堆用不到的 props、import、类型声明。直接提交到项目里过段时间你自己都看不懂为什么会有这么深的嵌套。我的习惯是生成后做一轮降噪删掉多余的div包裹层能用 Fragment 就不用多余的 DOM 节点合并重复的 className 定义变量命名统一把硬编码的色值、尺寸提取为主题变量把内联样式转成 CSS Modules 或 Tailwind 类名检查循环渲染的 key、事件绑定的依赖数组、异步请求的竞态处理。不是说我多爱写代码而是在实际项目里AI 生成代码的可读性和可维护性直接决定你后面要花多少精力去填坑。你不降噪后面接手的人——很可能是你自己——会骂娘。5. 实操过程与核心环节实现5.1 一个完整的实操案例从需求到成品页面我这阵子在做一个内部工具项目其中一个需求是做订单管理页面。我拿这个当案例把整个流程逐步拆出来给大家看。第一步需求分析。页面核心功能是订单列表的查看和筛选单条订单支持详情查看和状态变更。业务上需要展示的字段有订单号、商品名、用户 ID、支付金额、订单状态、创建时间。技术栈是 Vue 3 Element Plus项目统一使用 SCSS。第二步用 AI 做方案设计。我直接在对话里描述需求让它先给页面结构和交互方案。它输出的方案是顶部统计卡片一行总订单数、待支付、已发货、已完成下面是筛选器和表格。我看了下结构合理就让它继续生成代码。第三步分模块生成。我先让它生成统计卡片区域和筛选器再让它生成表格和操作列最后让它补了详情抽屉的内容。每个模块生成完我先在本地跑一下确认没问题再让它生成下一个模块。第四步接口对接。因为我这个项目已经有封装好的 API所以我不需要让 AI 写请求逻辑只需要告诉它接口的入参出参结构让它把 mock 数据替换成实际的api.getOrderList(params)调用方式。第五步手工打磨。这一步主要处理响应式折叠筛选区的展开收起、小屏下统计卡片的换行、空数据状态、加载骨架屏还有几个交互细节比如操作成功后刷新列表、状态变更的颜色统一。这些细节 AI 不是做不到而是你描述它们的时间成本已经够自己手动写完了。最终这个页面从需求确认到上线大概花了我两个下午。以前同样的页面光写 UI 结构就得一个整天还不算和产品对交互的时间。5.2 一个报表类页面的生成示例与优化过程再补充一个场景因为后台系统里除了 CRUD 就属报表分析类页面最多了。这类页面的特点是有图表、有日期范围选择、有指标切换布局复杂但又有固定套路。我尝试让 AI 生成一个销售分析看板需求是顶部 KPI 卡片四个销售额、订单量、客单价、退款率中间一个销量趋势折线图和一个类目占比饼图右侧一个排行榜列表。技术方案是 React ECharts。AI 的第一版生成结果KPI 卡片和排行榜都还行但图表部分它直接给我套了一个很粗糙的 ECharts 示例数据和业务完全不匹配。这时候我没有让它重新写而是做了几件事把图表需要的字段结构明确告诉它横轴为日期纵轴为销售额和订单量双轴数据用 mock 数组注意处理空日期补零让它把图表的通用配置tooltip、legend、grid单独抽成配置文件让它把 KPI 卡片的数值格式化逻辑千分位、颜色差做成交互函数。优化后的版本逻辑合理了很多。但图表的下钻联动、日期范围变化后图表刷新这些复杂交互最终我保留了手动实现。不是因为 AI 不行而是这些交互的边界条件太多用提示词描述清楚的时间成本已经超过直接手写了。这里的原则就是AI 生成边际成本低的常规部分手写边际成本高的定制逻辑。5.3 常用快捷键与配置技巧这里给大家分享一些能直接提升效率的小配置。如果你用 VS Code 和 Cline / Roo Code 这类 AI 编程插件建议先把项目的代码规范文档.cursorrules 或者项目说明文件喂给 AI让它了解你的代码风格。这比每次对话都写一遍用 Element Plus 4.x 版本、组合式 API 写法、样式用 SCSS要高效得多。如果你重度用 Claude 或 ChatGPT 网页版建议把项目中常用的组件结构、已有的几个典型页面代码存成固定的参考片段每次需要生成类似页面时先贴一个参考片段再用自然语言描述新的改动点。这一步能让 AI 更准确地模仿你团队已有的模式而不是自由发挥。还有一个小技巧如果你用 v0 这类平台探索方案生成完不要直接复制代码回去可以让它导出为可复制的 MVP 原型描述再拿着这个描述回到自己的代码生成流程里。这样你拿到的是方案思路而不是一堆需要适配的代码反而省去了很多转换成本。6. 常见问题与排查技巧实录6.1 问题速查表AI 生成 UI 时最常翻的车我整理了一下这段时间里自己遇到、包括身边朋友遇到的高频问题做成一个速查表现象根因解决方案生成页面布局僵硬全是绝对定位AI 没有良好视觉归纳能力提示词强制要求 Flexbox/Grid并拆模块生成样式风格跟项目完全不搭没有喂参考样式和组件库规范在项目级配置中补充代码规范或在提示词中粘贴 1-2 个已有组件代码组件代码结构臃肿、嵌套过深LLM 天然倾向多包一层明确要求结构扁平减少无意义包裹优先使用 Fragment接口对接时字段对不上生成时用的是 mock 数据先定义好类型和接口函数再把 mock 值替换成真实调用响应式布局失效视觉识别只在某一宽度下生效单独生成响应式适配提示词明确断点策略交互逻辑边界处理缺失状态切换、竞态、异步错误未覆盖让 AI 先列边界情况清单再逐项生成处理逻辑生成代码报错、缺依赖模型版本较旧或上下文里没交代环境检查报错信息把它喂回 AI 让其自修复6.2 排查思路AI 代码出问题时先从哪里入手AI 生成的代码报错我不建议你直接把报错信息丢回去让它改而是先自己看一遍搞清楚是代码本身的问题还是环境配置的问题。这两种问题的处理方式完全不同。如果报错是Cannot find module或者Module not found大概率是依赖没安装或路径引用不对。先检查 package.json 里有没有对应依赖没有就装上。如果是类型报错优先看是不是接口类型定义和 mock 数据结构不一致这种问题你把类型定义贴给 AI它一般能很快修好。如果是运行时白屏或者组件不渲染先看控制台有没有 React key 警告、Vue 的模板编译报错或者是不是Router嵌套顺序的问题。这类问题通常和 AI 的代码没有关系而是你对项目框架的路由结构没交代清楚。如果页面渲染了但样式乱了就检查 SCSS 模块的 class 命名是否冲突。因为 AI 生成的 class 名普遍很抽象比如card-container、header-wrapper在复杂项目里很容易和自己或别人的样式撞车。我自己的习惯是在 IDE 里先把 AI 生成的代码格式化一遍梳理出结构和关键 class 名再运行。格式化不是为了好看而是为了快速定位层级关系和代码块位置排查时能少走弯路。6.3 避坑提醒AI 处理 UI 时不能全信的三件事第一AI 对美观的理解能力远低于人类。它知道什么是极简但它不知道极简到什么程度是高级、到什么程度是简陋。色彩、排版、留白这些偏主观的审美判断AI 很难做对。所以视觉敏感的项目核心设计稿还是得人工或专业设计师把关。第二AI 会在你不知道的地方悄悄设最低标准。比如按钮可能没有 hover 状态表单提交没有 loading 状态表格没有空数据提示。这些细节 AI 默认忽略但真实项目里这些才是体验的关键。你需要主动在需求描述里点明或者生成后自己检查。第三AI 生成的组件往往不具备可复用性。它的优化目标是解决当前问题而非为相似功能抽象通用组件。你在一个页面里让它生成了搜索框到另一个页面里生成的可能完全是另一套写法。因此如果这个组件会在多个地方使用建议生成后手动抽成通用组件统一 props 和样式变量。6.4 一个另类的AI 辅助 UI思路直接让 AI 评测你的 UI这个思路挺有意思也是我最近发现的用法。你写完一版界面后把页面截图或代码粘给 AI让它以用户的视角挑毛病、提优化建议。比如你问它这是一张后台订单管理页面的截图请以运营人员的使用视角列出五个最影响效率的交互问题。 它给出的反馈经常能命中一些你忽略掉的点——表格字段顺序不合理、筛选器位置不够明显、关键数据没有突出显示……这些建议不一定每条都对但作为免费的产品评审它的性价比非常高。我甚至试过在改版前把新旧两版页面截图都丢给它对比让它列出旧的缺陷和新的改进点。它能帮我快速形成评审清单在给产品和团队过方案时节省大量时间。7. 我对 AI 拼 UI 这件事的一点逆耳看法最后聊点真心话。AI 生成 UI 最大的价值不在于让你不用写代码了而在于把那些最枯燥、最耗时的搭骨架工作从你的工作流里剥离出去让你有精力去做真正需要判断力的事情。我试过让 AI 独立完成整个页面而不做任何干预结果是它能用但不好用我也试过完全不使用 AI 手动从零写页面结果是我自己的时间被大量消耗在重复劳动上。两端的极端方案都不好中间的半自动 人工把关才是效率和质量的最佳平衡点。如果你是新手我的建议是不要一上来就依赖 AI 生成 UI。先自己完整地写一两个页面搞清楚 DOM 结构、CSS 优先级、组件生命周期、状态管理的调试方式。这样你才有能力判断 AI 给你的代码到底好不好、哪里容易出问题。没有这个基本功AI 生成的代码对你来说就是一堆随机字符遇到问题完全无从下手。如果你是有经验的开发者我也劝你别太早躺平。别把 AI 生成的东西直接丢给测试然后自己去干别的。UI 生成只是整个链路的第一公里后面还有需求对齐、业务逻辑、性能优化、技术债务等一系列问题等着你。你越是把 AI 用得好越要清楚它在整个链条里到底占哪一段——它解决的是把想法变成结构这一段而这个想法本身是否正确以及这段代码是否能在团队里长期演进永远是人的职责。说白了AI 让我不再拼 UI不是因为 UI 这件事不值得做了而是因为它把拼这个动作变便宜了。但拼出什么东西来、怎么拼才合理——这些事AI 只是协助拍板的人还得是我。