上周我把一个后台管理页的改版交出去了。不是甩给同事而是扔给 AI 生成第一版代码我只花半天做审查和微调——换以前这种“拼 UI”的活计从抠设计稿到调样式怎么也得两三个工作日。自从 AI 能直接生成 UI 代码之后我确认自己回不到那种逐像素拼页面的日子了。先说清楚我说的“拼 UI”不是画画是开发侧那堆把视觉稿变成页面的重复劳动把画布上的间距、字号、颜色、对齐关系一个像素一个像素地搬进代码再为不同屏幕尺寸想好怎么伸缩。这个过程信息密度低、规则明确、重复度高像把一张组装说明书抄成零件清单。以前团队里没人爱干这个但又必须有人干。现在 AI 对这类任务完成得相当好它不擅长的是业务逻辑和交互背后的取舍而这些恰恰是人在“拼完 UI”之后真正该做的事。这篇文章写给谁呢给那些被后台页面、活动页、表单页轮番轰炸的前端工程师给在小团队里身兼设计开发两职的杂役同学也给想用 AI 改善 UI 研发流程但不知道从哪里下手的团队。我会把自己从“手动拼 UI”切到“AI 拼 UI”的完整链路、选型思路、踩坑清单都摊开讲不会只甩几句“AI 真香”的结论。1. 从“拼 UI”到“不想拼 UI”这活儿的本质是被 AI 取代的重体力劳动要理解我为什么“不想拼了”得先搞清楚“拼 UI”到底在拼什么。很多没写过前端的人以为 UI 工作就是“把界面画漂亮”但在工程师视角里好看只是其中一小块更多精力烧在让页面结构和数据正确对齐上。1.1 “拼 UI”拼的是四件套开发一个页面的过程说白了就是四件事反复循环第一把设计稿里的位置关系翻译成布局代码这里要 flex 还是 grid间距怎么拆行内 margin 还是组件 props第二把视觉 token 固化进系统主色、次色、圆角、阴影、字阶散落在设计稿里得有人把它们收敛成变量第三把交互状态穷举出来一个按钮至少要考虑默认、悬浮、按下、禁用、加载、成功六种样子第四把响应式行为补齐同一个卡片在 1920、1440、768 和手机尺寸下得有四种表现漏了哪个都算事故。过去这四件事全是“人肉扫描仪”。设计师发来一张 Figma 稿我得盯着标注重叠的地方猜间距是多少遇到 dev mode 没开的设计稿就得更久。改一版又得重新跑一遍回归看看有没有因为某个 padding 调整导致导航栏换行。这不是技术深度问题纯粹是体力消耗但体力消耗恰恰是 AI 最适合替代的部分。1.2 为什么 LLM 能突然接管这个活儿前几年写代码生成工具也不少但都在“单组件生成”的水平打转你给它一个按钮描述它给你一段按钮代码再复杂一点的页面组合就乱套。转折点是多模态大模型成熟之后模型可以直接“看”图还能把图里的结构关系转成结构化代码这一步跨过去“截图到页面”就变成一条能落地的流水线。更关键的是UI 代码本身是低熵的。它不像分布式系统那样充满运行时的不确定性一个页面最终呈现在屏幕上的状态是静态的、可穷举的信息基本都在布局树和样式表里。大模型背过的开源前端代码足够多对“一个统计卡片通常长什么样”“一个筛选区一般怎么排布”这类常识掌握得比大多数人好。换句话说拼 UI 这种低不确定性、高重复度的编码任务正好卡在 LLM 最擅长的位置。我自己体会最深的是“枚举类”的 UI 工作。以前写一个表格组件光是空态、加载态、错误态、无权限态就能写掉半天而且没有任何挑战性。现在我把状态列表和要求丢给 AI它一次就能把四种态写完顶多我再花十分钟补一补切换逻辑。这种“重体力”的部分一旦被接管人对拼 UI 的反感就迅速下降——不是事情变少了而是那些让人烦躁的机械劳动消失了。传统做法和 AI 做法的对比我放在正文里方便你们一眼看懂变化到底在哪环节传统人肉拼法AI 拼法我的主观评价设计稿还原手动读标注、量间距截图直接转代码AI 初始还原度 75%-85%可接受视觉 token 沉淀逐个提取变量让 AI 按技术栈生成样式变量给好命名规范后很稳交互状态枚举人工穷举易漏用 prompt 让 AI 一次列全比人脑可靠仍需抽查响应式适配逐个断点调描述规则AI 补 media query复杂页面还得人工兜底回归测试手动点页面AI 生成 UI 自动化脚本效率和稳定性都提升表格是我实际用一个季度之后的真实打分不是理论推演。AI 拼出来的页面达不到“直接上线”的标准但绝对达到了“比人从零开始写更快”的标准。接下来聊具体怎么玩。2. AI 接管 UI 的四种主流玩法以及我的选型取舍说“不想拼 UI”不是一句情绪背后是有具体技术路径的。目前行业内 AI 参与 UI 生产主流就是四条路子截图直出、描述生成、局部改写、自动化回归。四条我都实际用过一段时间各自有非常明确的适用边界选错场景会非常难受。2.1 玩法一截图/设计稿直出代码第一版的原型利器把一张高保真截图或者设计稿丢给 AI让它直接产出一整页的 React、Vue 或者静态 HTML/CSS这是目前大家最常谈论的一种玩法。开源的 screenshot-to-code 类项目以及商业产品里带着视觉识别能力的生成工具思路基本一致图像编码进多模态模型模型识别出页面里的区块树、文本层级和视觉间距再套进你指定的技术栈输出代码。这个玩法最适合做“第一版”。我有一次拿一张产品 Dashboard 截图让 AI 输出 React Tailwind 版它产出的结构基本把顶部导航、KPI 卡片区、图表区、最新订单列表分对了整体视觉还原度在 80% 上下。第一版能到这个程度省掉的是从空白文件到骨架页面的两小时。注意我说的是“骨架”不是“成品”——图表库接入、真实数据联调、状态管理这些它不会帮你做但它把最耗神的排布问题一次性解决了。选型上我有个建议截图直出工具尽量选“开源优先”。开源的路径意味着你可以自己接入模型、改生成模板而不被某一个产品的生成风格锁死。商用工具在开箱体验上确实更好但如果你要长期面对多种技术栈或者体量小不想付高价开源方案更稳妥。2.2 玩法二一句描述生成整页方向对但要绑死约束不依赖截图直接写一段自然语言让 AI 生成整页代码。这种玩法听起来最“AI”但坑也最重。没有视觉参考时模型会自由发挥结果就是经常生成一个“看起来像那么回事但离产品预期十万八千里”的页面。AI 不像人一样会追问“这个页面的用户是谁、关键行动是哪个”它只能按照概率把最常见的页面结构拼给你。我实际使用下来的结论是要用描述生成整页必须先把约束写死。约束包括四类技术栈、组件库、设计 token、页面区块顺序。举个例子你写“用 React Tailwind shadcn/ui 风格生成一个数据概览页包含顶部四个指标卡、中间趋势图、底部数据表”这样的描述比“给我一个后台概览页”靠谱一百倍。AI 生成的自由空间收窄到“排版细节”上失败率会直线下降。这个玩法适合两类场景一是快速搭原型页面给业务方确认信息架构二是做内部管理系统的“够用就行”页面。低价值页面用描述生成高价值页面回头再精修这是性价比很高的策略。2.3 玩法三在已有组件上做局部改写日常最高频玩法如果你已经在维护一个成熟项目最常用到的其实不是“从零生成”而是“局部改写”把某个组件的布局调整把卡片列表改成表格把弹窗的交互拆成两步。这类需求和代码上下文强相关刚好是 AI 编程助手最擅长的场景。我的日常操作是在编辑器里选中要改的代码片段告诉 AI“这个表单的提交按钮在移动端太长了改成图标按钮并保持和原来 loading 状态一致”它给出的改动通常能直接复用现有组件和样式变量比截图直出更贴合项目实际。最关键的一点是局部改写必须提供“周围的代码约束”——只丢一段代码不够要把组件层级、引用的 props 类型、依赖的样式变量一起告诉它否则它会乱造。这玩法对我的意义最大因为它解决的是“存量页面的持续维护”问题。项目里的 UI 不是一次性建完就结束每个月都有新需求、新交互、新状态过去每次改动都要人肉翻样式源码现在 AI 能先接住一大部分。2.4 玩法四给 UI 装上自动回归的 AI 测试很多人忽略的一条路径AI 不仅能生成 UI还能生成验证 UI 的自动化脚本。过去前端 UI 自动化测试的门槛不低要写选择器、配环境、维护用例很多团队干脆不做。但现在 AI 可以用自然语言描述生成端到端脚本例如描述“登录后进入概览页点击营收详情应展示订单列表”AI 能直接产出 Maestro 或者 Playwright 的流程脚本。把生成 UI 和生成 UI 测试配套起来整个工作流才闭环AI 生成了页面马上也生成对应的主链路验证脚本跑一遍就知道这个页面“能看”之外到底“能不能用”。我特别建议项目里有 Maestro 这类轻量框架的团队试一下成本很低。四种玩法分别适合不同阶段我用一个表总结自己日常的选型逻辑玩法输入产出最适合的场景我在工作流里的位置截图直出设计稿/截图整页代码新页面第一版、活动页原型阶段描述生成文字约束整页代码低价值内页、临时页面快速搭建局部改写现有代码片段 描述局部代码改动改样式、改布局、加状态日常迭代AI 自动化测试自然语言流程测试脚本主流程回归、交付前检查质量关口四个路径拼起来就是一个“尽量不亲手从空白页开写 UI”的完整闭环。选型的时候不要贪多从你最痛的那个环节切入。我最痛的是“从零拼新页面”所以先上的截图直出和描述生成等项目跑起来局部改写和自动测试的比重会越来越大。3. 一次“不拼”实战从一张截图到一个可维护页面的完整链路光聊方法论容易让人觉得“道理我都懂但做不出来”我拿最近一次真实改版做样本把完整链路走一遍。这次的任务把一个数据概览页从旧布局升级成新版卡片式布局输入是产品经理给的一张参考截图没有任何设计源文件只有一段文字说明“要做成这个风格数据保留现有字段”。3.1 开工前先定边界与约束AI 最怕的不是要求多而是边界不清。第一阶段我先花二十分钟写清楚四件事技术栈约束、组件库约束、设计 token 约束、验收标准约束。技术栈固定为 React TypeScript组件尽量复用项目里已有的 StatCard、PageHeader、DataTable 组件设计 token 沿用现有的颜色变量和圆角变量验收标准是页面跑起来不报错、主流程数据能正常渲染、布局在 1440 和 768 两个宽度下不破。这一步非常关键。很多人抱怨 AI 生成的代码不能复用多半是没给它“项目上下文”。AI 不了解你项目里有自己的基础组件就会自己造一套类似的东西。把项目结构、组件列表、设计变量写进 prompt生成的代码才有融入现有项目的可能。我习惯在项目里维护一份UI_CONTEXT.md里面写着技术栈、目录约定、组件清单、样式变量一览让 AI 在改代码前先读这个文件。3.2 第一轮让截图变成能打开的页面我准备的 prompt 大概长这样角色资深前端工程师熟悉 React TypeScript Tailwind CSS。 任务将参考截图还原为一个可运行的页面替换现有 src/pages/Dashboard 下的内容。 约束 1. 必须复用项目内的 StatCard 组件不要新增同级卡片组件 2. 图表区域暂用占位不要引入新的图表库 3. 样式变量使用 src/styles/tokens.css 里的现有 token 4. 数据先按空数组处理但保留请求参数的类型定义 5. 页面需在 1440px 和 768px 下完整展示不出现横向滚动条。 输出要求完整代码并说明每个区块在截图中的对应位置。这个 prompt 其实就干了三件事给 AI 一个职业定位给 AI 看到截图把不可商量的约束列清楚。AI 生成的第一版并没有直接达到可用状态比如它确实复用了 StatCard但把间距写死成了 24px而不是读取设计变量页面的主标题层级也偏得和设计稿有点出入。这些都在预期内生成阶段的产出定位是“80 分骨架”。3.3 第二轮增量打磨视觉细节拿到第一版之后我不会一次性让 AI 把所有问题改完而是采用“一轮只改一类问题”的回合制策略。先集中处理间距和 token 问题prompt 大概是“第一版里的卡片间距没有使用 tokens.css 中的 --space 变量请统一改用变量并把区块间距修正为截图中的比例关系注意保留现有 flex 结构不动。”这样一轮下来代码改动量小审查成本低AI 也不容易把前面对的东西又改坏。回合制打磨是我在实战里总结出的最重要习惯。如果你一次性告诉 AI “间距不对、颜色不对、图表没接、数据没显示”它会陷入叠加式的错误修复经常修完 B 又弄坏 A。一次只改一类问题复查通过后把当前代码标记为“新基线”再跑下一轮整个过程会稳定很多。视觉细节通常要两到三轮第一轮统一 token 和间距第二轮调整响应式断点第三轮处理暗色模式预览。这三轮过去页面看起来已经和截图非常接近唯一的问题是没有真实数据——一个空壳页面。3.4 第三轮补上 AI 通常不会写的状态逻辑这是 AI 拼 UI 最明显的短板状态逻辑。AI 看到截图能还原布局但猜不出数据应该从哪里来、什么时候加载、加载失败怎么展示。这一轮我进入“人工主导”模式不再让 AI 全权负责而是提供一个我已经写好的 StatCard 组件示例让它照葫芦画瓢补齐页面里其他部分的状态export function StatCard({ label, value, status idle, trend }: StatCardProps) { if (status loading) return CardSkeleton /; if (status error) return CardError onRetry{reload} /; if (status empty) return CardEmpty label{label} /; return ( div classNamestat-card span classNamestat-card__label{label}/span span classNamestat-card__value{value}/span {trend TrendBadge trend{trend} /} /div ); }给 AI 一个“参照物”比描述一百句“请处理加载和错误状态”都有效。它看懂 StatCard 怎么处理多状态之后生成 DataTable 的空态、表格加载态时风格会保持一致。严格说这一步已经不只是“拼 UI”而是在和 AI 结对做工程化设计——人定状态协议AI 填充各状态的渲染内容。3.5 第四轮用 Maestro 证明主流程没断页面能看之后我会让 AI 生成主流程的自动化脚本。对于一个数据概览页主流程就是“进入页面 → 看到指标卡片 → 点击营收详情 → 进入详情页”。生成 Maestro 脚本时可以这样描述生成 Maestro flow启动应用后进入 Dashboard 页断言“本月营收”文本存在点击“营收详情”按钮断言“订单列表”标题出现。如果元素被遮挡先滚动到可见再点击。生成出的 YAML 骨架通常长这样appId: com.example.app --- - launchApp: {} - assertVisible: 本月营收 - tapOn: text: 营收详情 - assertVisible: 订单列表运行脚本之后十有八九会有一次失败原因往往是选择器识别不中、文案带空格、或者动画遮挡。把失败日志丢回给 AI让它看日志修正脚本通常两轮就能跑绿。这里我要强调一遍自动测试的目的不是证明 AI 生成的页面完美而是让你后续改代码时有个兜底网。没有这张网你可能每改一版都提心吊胆。整个链路走完从截图到可维护页面总耗时大约一个工作日其中人工深度介入的地方只有状态逻辑和最终审查。这个速度放在过去至少是两到三天的量级。合理吗很合理。4. 半年实测之后AI 拼 UI 的边界与五个最常见的坑写再多方法论坑才是最好的老师。半年里我和 AI 协作拼了不少页面踩过的坑五花八门真正影响交付质量的集中在五个。这五个坑有一个共同根源AI 的优势在“生成”薄弱在“判断”。它能生成一大堆看起来对的东西但缺少对“上下文完整性”的判断力。4.1 坑一视觉正确但逻辑空心最常见的现象AI 生成的页面截图级美观但你点按钮没有反应刷新后数据消失接口报错没有错误提示。因为模型的训练目标倾向于产出“正常状态”的界面加载失败、权限不足、后端异常这类非典型状态很少出现在它的默认输出里。如果直接把 AI 生成的页面交付业务方验收时大概率会在异常流程上栽跟头。应对办法是把状态逻辑的检查做成“交付前清单”每一个数据展示区是否覆盖加载、空态、错误态每个表单按钮是否覆盖禁用、加载、成功每个异步操作是否处理并发点击。这些项我直接写进 review checklist每次拿 AI 产出的页面逐条勾漏了就补补的时候再让 AI 按现有组件风格生成状态组件。4.2 坑二二次修改时的风格漂移有时候你会遇到一个非常恼火的情况第一轮让 AI 生成一个卡片风格统一很好看。第二轮说“帮我把卡片标题改成蓝色”它交回来的代码里不仅标题蓝了卡片阴影也变了内边距也变了。这不是幻觉而是模型对“局部修改”的理解和人类不同它倾向于重新生成一个“看起来符合要求的新版本”而不是做最小化改动。解决这个问题的关键是每次修改前明确给它一个“变更范围”指令例如“只修改 class 里的 color 属性其他代码保持原样不要重构现有结构”。如果项目里已经有严格的样式 token它会顺着 token 走。另一个更稳的办法是给 AI 展示当前完整代码再提修改不要让它从记忆里猜。4.3 坑三组件复用率低与代码膨胀AI 生成页面时最喜欢“把每个区块写成独立的小组件”从代码组织角度看很清晰但组件复用率其实很低——它不会主动去发现“这个卡片和页面里另一个卡片只差一个图标”于是每处都生成一套近似代码。一个页面下来重复的样式代码能膨胀三分之一到一半。我的处理方式第一轮生成之后专门做一轮“组件归一化”审查。把 AI 产出的代码丢回给它明确说“找出这三个区块的重复结构抽象成一个组件并用 props 控制差异点。注意不要改变渲染结果”。经过这轮抽象代码量通常能砍掉 30% 以上后续维护成本显著下降。4.4 坑四AI 的错有时只能靠人反向纠正有些时候 AI 会生成一段“报错代码”虽然看起来完整但你一跑起来就红屏。把报错信息喂回给它它能修但它可能修出一个新问题再报新错再修循环三次。我见过最夸张的一次AI 在修复一个 CSS 层级问题时连续给出了四轮彼此矛盾的方案最后我是自己动手查改了十分钟才稳定下来。这里有个经验AI 进入连续修错循环时最好停掉“让它自己猜根因”的模式改用“给它提供根因线索”的模式。例如把浏览器开发者工具里的堆栈、网络面板里的 404 地址、还有当前文件的 20 行上下文一起贴给它它的修复命中率会高很多。本质上人仍然是“问题定义者”AI 是“方案执行者”这个关系不能颠倒。4.5 坑五性能、无障碍、暗色模式这些“默认不生成”的项AI 生成的页面默认只保证“在正常浏览器下以正常方式显示”。它通常不会主动处理图片懒加载、长列表虚拟滚动、键盘导航焦点管理、ARIA 标签、暗色模式下颜色对比度这些工程属性。如果你负责的是一个对可访问性有要求的项目必须有专门的人来做这一层兜底。这方面我建议把它做成“二次增强任务”而不是指望 AI 一步到位。专门写一段 prompt“请检查当前页面的键盘操作路径为所有可交互元素补充 aria-label 和 focus 状态样式图片全部加 loadinglazy表单错误信息通过 aria-live 区域提示。”把增强项拆成独立任务逐轮执行相对容易控制。五个坑集中整理成一张速查表我贴在这里方便收藏坑典型表现应对策略逻辑空心页面好看但交互不可用交付前清单逐项核对状态逻辑风格漂移小改动引发样式大面积变化限定变更范围展示当前完整代码再改代码膨胀重复组件多体积增大单独做一轮组件归一化抽象修错循环连续多轮修改仍报错人提供根因线索后让 AI 定向修复默认属性缺失缺懒加载、缺 aria、缺暗色样式将增强项拆成独立任务逐轮补充这些坑不意味着 AI 拼 UI 不行只是告诉你AI 是很好的执行者但当好“验收者、约束制定者、问题定位者”仍然是人的核心职责。5. 当 AI 接手拼 UI前端和设计师会把力气用在哪里最后聊聊工作方式的变化。AI 能拼 UI 之后很多前端同学第一反应是“我是不是要失业了”我实际合作下来的感受恰恰相反——拼 UI 的体力活被接走之后岗位价值反而向更不可替代的方向转移了。5.1 前端从拼页面到设计协议前端这个角色的重心正在从一个“像素搬运工”变成“交互契约的守护者”。拼 UI 的活儿 AI 能接但“数据应该以什么结构流进组件”“按钮在多个业务场景下的状态由谁定义”“组件 API 如何设计才能让 AI 快速复用”这些决策仍然需要人来定。我现在最花时间的事情之一是把项目的UI_CONTEXT.md维护好组件协议、状态规则、样式变量说明。这份文档就是 AI 拼 UI 时的“施工图纸”文档越清楚AI 生成的代码越贴近项目标准。你也可以把它理解为“给 AI 的接口文档”——人的职责从写代码变成了写标准和做审查。5.2 设计师把规范变成 AI 能消费的上下文设计师侧的变化也很明显。过去设计交付物是“一张图”现在的有效交付物是“一张图加一套规则”。AI 能识别截图里的视觉结构但它不理解品牌背后的含义、为什么这个交互要这么设计。这些“为什么”恰好是设计师最该沉淀的内容。我合作的团队里设计师会维护一份设计决策说明包含主色传达的情绪、圆角系统的层级、动效的时长节奏。每次做新页面时这份说明和设计稿一起给到 AI生成的页面在“神似”层面会好非常多。设计师不再只是叠画布的人而是把设计原则翻译给 AI 的人。5.3 多 AI 协作生成模型与审查模型分开还有一个实操技巧值得分享用两个不同模型协作一个负责生成一个负责审查。生成模型的任务是“尽可能快地给出代码”审查模型的任务是“挑刺”——找出状态缺失、重复代码、语义标签遗漏、样式 token 没用对的地方。这个做法有点反直觉但它有效减少单一模型的“自我确认偏差”。我自己试过觉得效果不错生成走一个便宜的、速度快的模型审查走一个分析能力更强、上下文更长的模型。生成模型交第一版审查模型开批注清单我再决定哪些要改、怎么改。这比让同一个模型又写又审可靠得多也是所谓“多 AI 协作”最朴素的落地形态之一。5.4 给刚想踏进这条路的你三条建议如果你也想试试“不再亲手拼 UI”我给三条从半年实战里提炼的建议直接照做就行。第一别从复杂的核心页面开始。挑一个低价值的内部页面做实验比如列表页、表单页跑通截图直出到自动测试的完整链路建立信心再扩展到高价值页面。第二把 AI 生成代码当成第一版而不是最终版心里时刻有一张审查清单状态逻辑永远是人工检查的重点。第三花半小时写一份团队自己的UI_CONTEXT.md把你常用的组件、样式变量、项目结构告诉 AI。这半小时的投入会在之后的每一次生成中持续给你回报。我自己现在的状态是新页面第一版交给 AI日常小改动交给 AIUI 回归测试脚本交给 AI但我对每个页面都保留最终审查权尤其是在状态逻辑、可访问性、异常流程这三块。拼 UI 这件事我确实不想再亲手做了但我愿意把所有精力用来保证 AI 拼出来的东西是真正能被用户好好使用的产品——这大概就是工具升级的意义。真正的转变不是“人变成 AI 的监工”而是人把双手从泥瓦活里腾出来重新去做定义标准和打磨体验的事情。如果你也想少拼点 UI记住一句话AI 帮我们省下来的时间应该花在更值得的地方。