前两年我接了一个后台管理系统的私活五个页面光是把表格、表单、弹窗、侧边栏这些组件一个个拼起来就整整熬了两个通宵。从那以后我一直在想UI 这活儿凭什么非得靠人手一点点搓直到我把 AI 正式放进日常开发流程我才发现“不想手拼 UI”这句话不是矫情而是真实发生在我身上的转变。这篇文章不写空话我会直接把我怎么用 AI 生成页面、怎么改样式、遇到翻车怎么排查以及哪些工具值得一直留在工作流里全都摊开来聊一遍。不管你是老前端、刚入行的新人还是经常被拉去帮忙搭界面的产品和设计都应该能从里面捞到点能直接用的东西。1. 我为什么彻底放下了手拼UI的执念1.1 手拼UI的真实状态看不到头的重复劳动很多人一提“拼 UI”第一反应是觉得这是设计活儿不就是拖拖拽拽放几个组件嘛。等你真正做几个后台项目就知道了最难的从来不是单个组件长什么样而是大量组件之间的一致性、响应式表现、不同屏幕下的可用性这些全都压在你一个人身上。一个普通后台页面左侧导航、顶栏、筛选区、数据表格、分页器、操作弹窗一套组合打下来几百行模板代码是常态。你还要给按钮的对齐方式较劲、给弹窗的遮罩层级排序、给表格每一列定宽度一晚上下来大部分时间都在处理这种没营养但必须做的细节。这种工作最让人疲惫的地方在于它不产生积累。上次项目里调过的间距规范换个项目又要重新梳理一遍上上个项目踩过的表格列宽坑这个项目大概率还会再踩一次。说它是体力活吧它还带着一点逻辑判断说它是创造性工作吧它又几乎没有发挥空间。我那时候最常用的复制粘贴就是从旧项目里把一整段样式代码挪过来再手动改改变量名和颜色值本质上是拿时间换效率。1.2 第一次被AI的生成结果惊艳到真正让我心态转变的是有一天下午我在给一个客户做登录页和注册页。登录页还好中规中矩的居中卡片式布局注册页就有点讨厌了字段特别多还得分组展示不同分组的间距、必填项的标志、手机号和邮箱的校验反馈样式都得自己抠。我试着把需求写成一段描述丢给 AI没想到它几秒钟就给了我一个能用页面结构清晰字段分组也合理颜色、圆角、阴影都统一连校验状态的红字提示都帮我预留好了位置。那一刻我意识到AI 并不是在替我做“艺术创作”它是在替我做一部分重复的模式识别和代码翻译。我脑海里已经知道页面上应该有哪些元素、这些元素怎么排、交互怎么走只是以前必须用手一行行敲出来现在只需要把思路讲清楚AI 就能把骨架和大部分实现细节一次性补齐。省下来的时间没有消失而是被我用到了真正需要人来做判断的地方比如这个页面到底要不要加搜索、筛选字段暴露到哪一级、空状态和错误状态分别引导用户做什么。1.3 这条路究竟适合谁、不适合谁先说适合的如果你经常做中后台系统、信息展示类页面、营销落地页或者是在做产品原型和技术验证那 AI 拼 UI 的收益几乎是立竿见影。这部分页面的核心诉求是信息层级清晰、组件复用率高、视觉风格尽量统一AI 最擅长的恰恰就是从大量训练样本里学到这些约定俗成的好看结构。对非前端岗位来说更友好产品经理可以自己先拿 AI 出一版高保真原型后端同学也能在没人帮忙的情况下先搭出一个能看的界面。不适合谁也得说清楚如果你在做的是极其垂直的行业软件比如医疗影像界面、军工指挥大屏、有着严格无障碍规范和无障碍访问要求的系统AI 生成的内容只能当草稿后面的合规检查、特殊交互、键盘操作链路、读屏适配一件都少不掉。另外如果你的团队已经有一套非常成熟的设计系统里面有自定义设计令牌、复杂状态映射、几十个业务组件那 AI 更适合在局部区域帮你补代码而不是直接让它接管整站。盲目把 AI 生成的页面塞进高度定制化的现有体系里反而要花更多时间去拆除它的过度设计。2. AI拼UI的工具链与选型逻辑2.1 我现在完整的工作流程描述-生成-修正-集成工具只是一部分真正让效率起飞的是流程。我现在固定的工作流就四步描述需求让 AI 理解意图AI 生成第一版代码或页面人工检查并针对问题提出修正最后把它集成到项目里。描述这一步花的时间最多因为 AI 真的很吃“上下文明确”这一套。你给的信息越具体它给你的东西越接近可用状态。上来一句“给我做一个好看的后台页面”它给你一个看起来花哨但没法直接落地的模板你告诉它“我要一个订单管理页搜索区放订单号和状态下拉表格列需要展示金额和时间操作列要放查看和发货按钮”它给你的就是可以直接跑起来的东西。修正这一步也有讲究。不要每次说完“按钮不对”就完事应该指出“按钮和输入框没有垂直对齐可能是因为外层用了 flex 但没加 items-center请给出修复后的代码”。AI 改代码其实不笨但如果你给的反馈是模糊的它也只能猜猜错概率自然高。集成环节同样别掉以轻心无论是把生成结果粘进现有项目结构还是照着生成结果反向提取组件你都需要先确认这个生成版本使用的依赖、样式方案和你的项目是否一致别引入一堆根本没用到的库。2.2 常用工具组合与分工市面上的 AI 工具现在五花八门我的原则是“不追求一把梭而是让每个工具待在它最擅长的位置”。下面这个表是我这几个月实践下来比较顺手的分工方式。环节我常用的工具擅长场景需要留意的点整页生成v0、类似的 AI 页面生成器从一段提示词直接生成接近完整的页面多组件复合页面容易出现过度设计需要人工删减局部修改Cursor、VS Code 里接 AI 插件基于已有代码改布局、改间距、抽组件改完要确认不破坏其他模块不同的 AI 上下文理解能力差距大原型评审Figma AI 辅助快速把布局方案转成视觉稿统一层级AI 对品牌调性的把握很弱色彩和字体需要人工把关风格填空Claude、ChatGPT 等通用模型输出现成的设计变量、Tailwind 类名组合、CSS 代码抽象描述要写成可执行的要求不然容易得到一个“文科生答案”这里我想多说一句为什么整页生成我推荐 v0 这类工具而不是让通用聊天模型直接输出一大坨代码。因为页面生成类工具是面向 UI 场景做了专门优化的它能同时考虑布局结构、组件语义、配色关系生成出来的东西更像设计师给的高保真稿而不只是能编译的代码。通用模型当然也能写页面但对复杂表单、响应式栅格、状态切换这类细节理解和还原能力往往差一截更适合处理那些范围明确的小任务比如“把这段按钮改成图标加文字的形式”或者“用 Tailwind 重写这个卡片组”。2.3 为什么我不迷信“一键生成整站”刚接触 AI 生成 UI 的时候谁都会有一个幻想我把需求全说完AI 一口气把整个系统所有页面全部吐出来还自动接好接口和状态管理。我的实际经验告诉我这个幻想越早破灭越好。整站生成之所以不现实首先是因为“需求”在大多数真实项目里根本不是一个可以一次性描述完的静态集合它会在开发过程中不断变化。今天你觉得订单列表需要按金额排序明天客户就说其实按时间更合适等你把页面全量交给 AI 生成你会发现 AI 对这样一个庞大改动的理解并不连贯反而把你原来手动维护成本很低的部分搞复杂了。更重要的一点是AI 工具没有“项目责任感”它不存在长时记忆来维持你对技术方案的特殊偏好。今天它给你用 flex 布局实现明天同样的需求它可能就用 grid 写了东西都能看但代码风格前后割裂留给后来维护的人一个很乱的烂摊子。所以我现在更倾向于把项目拆成多个页面级任务让 AI 在限定的页面范围内自由发挥再在整体层面把握技术栈和样式规范的一致性。这相当于把 AI 当外包团队用你要做的不是让它替你思考架构而是给它足够明确的边界。3. 从一句话需求到可上线页面的全流程实操3.1 第一步写清楚“页面提示词四要素”要得到一个能直接用的结果提示词的颗粒度不能太粗。我给自己定了个“四要素”框架每次选页面都会照着这四样写页面类型、核心数据、操作路径、视觉基调。页面类型一句话说清比如“订单管理页”“用户详情页”“商品卡片列表”避免让 AI 把不同类型的页面元素混进来。核心数据是页面内必须出现的信息字段比如订单号、商品名、买家、金额、时间、状态把字段列出来能防止 AI 自己编出一堆页面里根本不需要的东西。操作路径描述用户在页面上能干什么比如“筛选”“重置”“新增”“查看详情”“发货”这一点决定了按钮和交互形态。视觉基调不用写得像散文给关键词就行比如“白底、主色蓝、卡片式、细边框、间距宽松”AI 就能基于常见设计习惯往靠谱方向靠。举个例子我最近让 AI 做一个订单管理页提示词大概长这样请帮我做一个订单管理页面技术栈使用 Vue3 Element Plus。 页面分三个区域 1. 顶部筛选区订单编号输入框、状态下拉、时间范围选择器、查询按钮、重置按钮。 2. 中间表格区列包含订单号、商品名称、买家、订单金额、下单时间、订单状态、操作。 3. 底部分页器。 视觉风格白底主色 #1677ff表格加边框操作列使用“查看”“发货”两个文字按钮。 状态显示待付款灰色、已付款蓝色、已发货橙色、已完成绿色。 先给出页面骨架代码不要加入多余装饰。这段提示词不算长但它把信息层级、字段范围、状态色彩都锁死了。AI 生成的页面基本能在第一次就达到“可评审”的状态而不只是“能看但没法改”的玩具。3.2 第二步让AI先出骨架再长血肉有经验的人写页面也不会一上来就纠结某个按钮的 hover 颜色肯定是先把整体结构摆出来再逐步往里填细节。AI 也是一样所以我会在第一次生成的时候刻意要求它“先出骨架代码不要加入多余装饰”。这样做有两个好处第一骨架阶段的代码更短变量命名和模块划分看得更清楚方便我审查第二避免 AI 在结构还没稳住的时候就开始堆阴影、渐变、动画这些视觉效果不然等你要改布局的时候会发现所有地方都缠绕在密集的修饰代码里越改越费力。骨架阶段拿到之后我会先确认几个关键问题数据数组的结构是否方便接真实的接口字段筛选区的查询逻辑是否绑定到了正确的方法名组件外层的容器宽度是不是用了固定值导致后面响应式改造的时候需要重写一遍这些点位确认没问题才进入第二步让 AI 在骨架基础上补充具体内容。比如给表格区补上分页组件、给搜索按钮接上点击事件、给不同状态值加上对应的标签样式。这一步我会按模块逐步给指令让 AI 一次只负责一块避免一次性改动太多导致后续无法准确定位问题。3.3 第三步用“问题预期”的方式让AI改细节这里是最多人吃亏的地方。很多同行用 AI 改 UI反馈就是“这里不好看”“那里对不齐”这等于把你自己该做的判断完全丢给客户。AI 不是一个能读懂你心思的设计合伙人对这种模糊指令标准回应就是换一个样式再试一次方向对不对完全靠运气。我现在写修正指令会强制自己套一个格式先描述问题再说预期效果必要时补充可能的原因。举两个我常用的修正模板问题页面上“查询”按钮和输入框底部没有对齐看起来一个高一个低。 预期所有筛选控件应该在同一水平线上高度统一为 32px。 请先检查外层是否使用了 align-items: center再给出修复后的代码。问题移动端下表格右侧的列会被容器截断出现横向滚动条。 预期在窄屏下隐藏次要列保留订单号、金额、状态和操作列。 请优先使用响应式列的方案不要给表格外层加 overflow: auto 一劳永逸。后面那一条其实体现了一个很重要的观念你要的不是让 AI 修好这一次的 bug而是让它在修复的时候采取一个你认可的可持续方案。如果你只说“表格滚动条问题”AI 很可能会用最简单粗暴的 overflow 方案来给你一个“修复成功”的错觉可这个方案下次遇到真正需要完整数据展示的场景的时候反而成了麻烦。把预期说清楚AI 的执行力才会收敛到对的方向上。3.4 真实案例一个订单列表页的从无到有我不喜欢讲纯理论给你还原一下我最常遇到的真实场景。项目是一个 B 端管理后台技术栈是 Vue3 Element Plus我要做订单管理列表页。拿到需求后我写四要素提示词让 AI 生成第一版。第一次结果整体还不错但我发现它默认把所有字段都平铺在表格里页面显得特别挤。我没有直接说“改好看点”而是告诉它订单状态这种高频筛选维度应该放到顶部筛选项里表格本身只展示核心信息地址这种长文本列可以隐藏需要在操作里点击“详情”再查看。AI 很快调整了结构并在表格列上加了一个更合理的展示逻辑。接下来我又让它处理了三个细节把时间列改成日期加时间的组合格式把金额列做右对齐并加上千分位把发货按钮放进一个下拉菜单应对“部分订单不支持发货”的未来逻辑。每一步都是单独给指令改完就验证没有一次性要求它全部完成。整个过程加起来不到四十分钟一个接近可交付状态的页面就出来了。这里面的工作量如果靠手写至少要几个小时而且还不算中间反复拉齐视觉细节的时间。4. AI拼UI常见翻车现场与我的排查清单4.1 布局硬伤溢出、塌陷、响应式失效AI 生成代码最常见的问题是布局层面的表现最典型的就是内容溢出。比如某个区域宽度算错了子元素把父容器撑破页面出现横向滚动条或者使用了固定高度的容器文字一多就溢出又或者是 flex 布局里忘了给子元素设置 min-width: 0导致文案太长时把兄弟元素挤到外面。排查这类问题有个很省力的办法就是打开浏览器开发者工具先看整体宽度链路从 body 往下逐层看哪一个元素的实际宽度超过了父容器的内容区。定位到具体元素后再判断是宽度设置的问题、flex 收缩策略的问题还是长文本没有截断的问题。响应式失效是另一个高频翻车点。AI 默认情况下更偏好桌面端视觉生成的容器宽度、字体大小、栅格列数很少考虑小屏。处理手段是在需求提示词里就加上一句“需要兼容 375px 到 1440px 的屏幕”并且在后续走查阶段使用浏览器设备模拟器逐档位过一遍。凡是那种用固定 px 值写死宽度的区块基本都要在移动端重调。你可以让 AI 改成 rem、% 或 clamp 之类的响应式单位但改完一定要回头验证每个断点因为 AI 经常会在改动单位的时候把设计间距的原始比例搞乱。4.2 样式软伤字号、间距、颜色不统一比布局硬伤更隐蔽的是样式软伤这类问题不仔细看还真发现不了。最常见的三个同级别的标题字号不一致同一页面上两个同样权重的小标题一个 16px 一个 18px卡片的内边距不统一有的 16px 有 20px状态色的明度差异太明显导致整体视觉失衡。出现这些问题是因为 AI 在生成不同模块的时候默认依据的训练数据不同可能这个模块学到的是一个风格模板另一个模块学到的又是另一个模板拼在一起就会露馅。我现在对付软伤的办法是先建立规则再审查。在提示词里固定声明“页面内所有卡片内边距统一为 16px正文统一为 14px主色唯一状态色使用同一套色板”然后用一个 CSS 变量表或者设计令牌文件去约束 AI 的输出范围。审查阶段也可以让 AI 帮我做个自动检查把页面里所有 font-size、padding、margin、color 抽出来列成清单我一眼扫过去就能发现哪个地方偏离了规则。这个思路本质上就是把你平时人工对设计规范的做法转变成给 AI 看得到的约束条件。4.3 状态死角hover、禁用、loading、空数据AI 生成的页面最大的问题不是静态样子而是很多交互状态它根本没考虑。生成的按钮有正常态和 hover 态但你可能不知道它的 disabled 状态样式是模糊的灰到什么程度、鼠标手势是否改变它不会主动告诉你。表格有数据行的时候很好看但空数据时会不会出现一个合理的空状态AI 默认往往是直接把表格留白既不提示用户也不引导操作。loading 状态就更是重灾区很多 AI 生成的页面在数据请求阶段就是一片空白用户会以为页面卡了。要修这些死角最好的方式是给 AI 一个“状态补全”指令告诉它请为这个页面补充加载中状态、空数据状态、按钮禁用状态、操作成功与失败的反馈提示。如果项目里已有现成的 loading 组件或骨架屏组件把组件名和用法也写进提示词这样才能确保生成结果直接复用项目基础设施而不是自己另造一套轮子。另外交互反馈的状态提示文案也要尽量具体比如“发货成功之后提示‘操作成功’并刷新列表”“删除时弹出二次确认弹窗”这些细节能让页面从“能用”变成“好用”。4.4 我沉淀下来的四轮走查习惯AI 拼 UI 不是生成完就收工后面一定要有几个固定动作。我现在每次拿到 AI 生成的页面都会走四轮检查每轮只看一个维度。第一轮查运行页面能不能跑起来控制台有没有报错组件有没有正常渲染。第二轮查结构各个区块的先后顺序是否符合预期信息层级是否清楚按钮是不是放在了它该在的位置。第三轮查视觉同级别元素的字号、间距、颜色是否一致内容有没有溢出深色和浅色背景下文字能不能看清。第四轮查状态hover、按下、禁用、加载中、空数据、超长文本截断一个都不能漏。这四轮检查看起来多其实每一轮花的时间都很短。真正花时间的反而是第五步把人叫来一起走查因为 AI 检查不出来的是产品逻辑上的不合理。比如一个筛选字段在业务上根本没有单独筛选的意义一个按钮放在那里会诱导用户做出有风险的操作这些都是 AI 无论怎么优化代码都无法发现的问题。所以 AI 真正替代你的是前面四轮检查里的执行部分第五轮依然是人来主导的判断工作。5. 关于AI拼UI的几句实在话5.1 AI省下来的时间该花在哪些地方更值用了 AI 拼 UI 之后我最大的感受不是“现在写页面快了”而是“我终于有空去关心那些以前没时间管的问题了”。过去写表单页我会把大量精力花在布局对不对、间距像不像设计稿上根本没空去深入思考这段业务流程到底应该怎么走。现在这部分工作被 AI 接走了我能把省下来的时间投入到交互逻辑、异常分支、性能优化和项目整体结构上。你会发现页面跑得快当然重要但更关键的是用户能不能零障碍地完成自己的目标产品逻辑是不是自洽的有没有哪些前置条件没考虑到。这些才是真正让一个项目走得更远的东西也是 AI 目前给不了你的判断力。我还养成了一个习惯每次 AI 生成完页面我都会花一点时间把生成代码里那些自己不满意的地方记录下来整理成几条可复用的修正指令。比如“右侧操作列不要只放文字按钮要放图标加文字”“卡片头部左侧放标题右侧放功能按钮”“表格列注意给金额做右对齐”。下次再遇到类似页面这些指令可以直接拿来用AI 的输出质量会越来越高。说白了你是在用自己的审美和经验给 AI 喂养一个越来越懂你的上下文。5.2 新手上路建议从改一个小组件开始如果你刚接触 AI 拼 UI我建议不要一上来就拿整站或者完整页面去试那样很容易因为反馈链太长而失去耐心。先从一个小组件开始比如让 AI 把一个普通按钮改成带图标的按钮把一张商品卡片改成横向布局把一段导航从横向排列改成侧边栏结构。这种小任务的边界很清晰AI 的成功率高你也能从中快速掌握“描述需求、获取结果、反馈修正”这个闭环的节奏。等你在小任务上建立手感之后再逐步挑战更复杂的场景比如一个包含搜索区、表格、分页器的完整列表页。每完成一个完整页面你就会积累一套对应的提示词模板和修正话术这些才是 AI 拼 UI 真正的护城河。工具本身是公开的谁都能用但你能不能把需求写清楚、能不能在 AI 犯错之后用一句话把它拉回正轨这才是拉开差距的地方。我自己也是从各种翻车现场里一路练过来的多踩几个坑不是什么坏事关键是踩完之后要愿意停下来总结把经验重新喂给自己的工作流。