1. 从手搓像素到对话生成UI 工作流的范式转移前阵子我在做一个中后台管理系统的迭代需求方丢过来一句话“把这个数据看板改得更有科技感一点下周一要演示。”放在两年前这句话意味着我要打开设计工具从网格系统开始重新排布卡片、调阴影、改圆角、导出切图再跑到前端工程里一个个替换资源、对像素、修间距运气不好还要跟产品经理来回拉扯三轮。但这次我的第一反应是先别急着开设计软件把需求描述丢给 AI让它先出几版结构草稿我再来做判断和收敛。这个转变不是一时兴起。AI 辅助 UI 生产这件事已经从“玩具级”走到了“能进真实项目”的阶段。核心逻辑很简单UI 的本质是结构 样式 状态三件事的组合而这三件事恰好是大模型最擅长处理的模式化信息。结构对应组件树的层级关系样式对应设计令牌颜色、间距、字号、圆角、阴影状态对应 hover、active、disabled、loading、empty 这些交互分支。过去这些全靠人手一个个写现在可以让 AI 先铺一版底稿人只负责审美判断和业务适配。这篇文章适合三类人看。第一类是前端和客户端开发者尤其是经常要自己兼 UI 的独立开发者或小团队第二类是UI 设计师想搞清楚 AI 到底能替自己省掉哪部分重复劳动第三类是技术管理者在评估要不要把 AI 工具引入团队的 UI 生产链路。我会把整套思路拆开讲为什么这么设计、每个环节的关键参数怎么定、实操时踩过哪些坑、遇到问题怎么排查。不吹不黑只讲能落地的东西。需要先明确一个前提AI 不是来替代审美的它是来替代重复劳动的。你依然要懂什么叫好的间距节奏、什么叫合理的视觉层级否则 AI 给你的东西你连好坏都判断不了。工具越强判断力越值钱这个道理在 UI 领域尤其明显。2. 整体方案设计为什么是“AI 出草稿 人工收敛”而不是全自动2.1 全自动生成 UI 为什么在真实项目里行不通网上很多演示视频看起来很美输入一句话AI 直接吐出一个完整页面配色高级、布局工整。但你真把它接到业务项目里问题立刻暴露。第一个问题是业务语义缺失。AI 不知道你这个表格里的“状态”字段有几种枚举值不知道“金额”字段需要右对齐且保留两位小数不知道这个按钮点下去会触发一个需要二次确认的危险操作。它只能根据通用经验猜猜出来的东西看着对用起来全是坑。第二个问题是设计系统不一致。一个成熟项目一定有自己沉淀的设计令牌和组件库。AI 默认生成的是它训练数据里的“平均审美”跟你项目里既有的品牌色、圆角规范、阴影层级大概率对不上。如果直接采用等于在项目里引入了一套外来设计语言后期维护会非常痛苦。第三个问题是状态覆盖不全。真实 UI 里最费时间的从来不是默认态而是各种边界状态数据为空时显示什么、加载失败怎么提示、超长文本如何截断、移动端窄屏怎么折行。AI 一次性生成的代码通常只覆盖了理想路径这些边界全靠人补。所以我的结论很明确AI 负责从 0 到 60 分人负责从 60 到 95 分。让 AI 干它擅长的模式化铺量工作人专注在业务逻辑、设计一致性和边界处理上。这个分工下效率提升是实打实的通常一个中等复杂度的页面从需求到可演示版本的时间能压缩一半以上。2.2 三种主流接入方式的取舍目前把 AI 接进 UI 工作流大致有三条路径各有适用场景。接入方式典型形态优势局限适合谁对话式生成在聊天窗口描述需求拿到代码或结构门槛最低灵活适合探索结果不稳定需要反复调个人开发者、快速原型设计工具插件在设计软件内直接生成图层或组件与设计流程贴合产出可视化依赖插件质量导出链路长UI 设计师代码内联助手在编辑器里根据注释或上下文补全上下文准确直接进代码库需要项目已有基础结构前端团队我个人的组合是前期用对话式生成快速试结构中期用代码内联助手补细节设计稿阶段用插件做视觉对齐。三条路不是互斥的而是流水线上的不同工位。比如做一个新的详情页我先在对话里让 AI 给出三版布局方案选定一版后把结构描述贴进编辑器让内联助手基于项目现有组件库生成代码最后再回到设计工具里微调视觉。这里有个关键判断如果你的项目还没有成型的组件库和设计令牌先别急着上 AI。因为 AI 生成的东西没有约束会越生成越乱。正确的顺序是先沉淀一套基础规范哪怕很简陋只要有颜色、间距、字号的基本约定AI 的产出就能被约束在可控范围内。2.3 提示词的结构化写法很多人用 AI 生成 UI 效果差根本原因是提示词太随意。“帮我做个登录页”这种输入AI 只能给你最平庸的答案。我摸索出一套结构化提示词模板实测下来稳定性提升非常明显。模板分四段角色与场景、结构要求、样式约束、状态覆盖。举个例子角色你是一名资深前端工程师熟悉中后台系统的设计规范。 场景为一个充电桩运营平台生成设备监控卡片组件。 结构卡片包含标题栏设备名称 在线状态标签、 主体区功率、电压、电流三个指标、 底部操作区查看详情、远程重启两个按钮。 样式主色 #1A73E8圆角 8px卡片阴影 0 2px 8px rgba(0,0,0,0.08) 指标数值用 24px 加粗标签用 12px 常规。 状态需要覆盖在线、离线、告警三种状态 离线时指标区置灰告警时状态标签变红并闪烁。这样写出来的提示词AI 产出的东西基本能直接用返工率大幅下降。核心心法是把你脑子里默认知道但没说出口的约束全部显式写出来。AI 不会读心你写得越具体它猜的空间越小结果越可控。3. 核心环节拆解从一句话需求到可运行组件3.1 需求转结构让 AI 先画骨架再填肉拿到需求后我的第一步不是让 AI 直接写代码而是让它先输出结构描述。这一步很关键因为结构错了后面样式再漂亮也是白搭。我会要求 AI 用缩进的文本树来描述组件层级比如Card ├── Header │ ├── Title (设备名称) │ └── StatusTag (在线状态) ├── Body │ ├── Metric (功率) │ ├── Metric (电压) │ └── Metric (电流) └── Footer ├── Button (查看详情) └── Button (远程重启)拿到这个树之后我会先做一轮人工审查层级是不是太深、有没有可以合并的节点、命名是否符合项目习惯。确认结构没问题再让 AI 基于这个树生成具体代码。这样做的好处是把“结构决策”和“代码实现”两个阶段分开避免 AI 一次性输出一大堆代码后你还要从代码里反推它的结构意图。提示审查结构树时重点看两件事——层级深度是否超过四层、是否存在语义重复的节点。这两类问题在 AI 生成的结构里出现频率最高。3.2 样式约束设计令牌怎么喂给 AI样式这块最容易失控。AI 默认会自由发挥颜色和间距导致同一个项目里出现五六种相近但不相同的蓝色。解决办法是把设计令牌以显式清单的形式喂给它。我通常会在提示词里附上一段类似这样的约束:root { --color-primary: #1A73E8; --color-success: #34A853; --color-warning: #FBBC04; --color-danger: #EA4335; --color-text-primary: #202124; --color-text-secondary: #5F6368; --spacing-xs: 4px; --spacing-sm: 8px; --spacing-md: 16px; --spacing-lg: 24px; --radius-sm: 4px; --radius-md: 8px; --shadow-card: 0 2px 8px rgba(0,0,0,0.08); }然后明确告诉 AI所有颜色、间距、圆角、阴影只能从这个清单里取不允许自创数值。这一条约束加上去之后产出的视觉一致性会有质的提升。如果项目用的是某套成熟组件库直接把它的主题变量贴进去效果更好。这里有个细节值得说间距体系我强烈建议用4 的倍数作为基础单位。原因不是玄学而是 4px 在绝大多数屏幕密度下都能整除不会出现半像素模糊。8px 作为最常用的间距16px 作为区块间距24px 作为大区块分隔这套节奏在大量项目里被验证过是舒服的。3.3 状态覆盖AI 最容易漏的那部分前面说过AI 生成的东西通常只覆盖理想态。所以我会在提示词里强制要求它列出所有状态分支并且逐个生成对应样式。以按钮为例至少要覆盖默认态default悬停态hover按下态active禁用态disabled加载态loading以数据展示区为例至少要覆盖正常有数据空数据empty加载中skeleton加载失败error 重试入口我一般会让 AI 先输出一张状态矩阵表确认没有遗漏后再生成代码。这个习惯帮我省掉了很多后期补状态的返工。表格长这样组件状态视觉表现交互行为按钮disabled透明度 40%禁用光标不可点击按钮loading显示旋转图标文字隐藏不可重复点击列表empty显示插画 引导文案提供新建入口列表error显示错误提示 重试按钮点击重新请求3.4 代码落地怎么和现有工程对接AI 生成的代码不能直接往项目里塞中间要做一层适配转换。我的做法是分三步走。第一步替换组件引用。AI 生成的通常是原生标签或它自己假设的组件名我要把它们换成项目里实际使用的组件库组件。这一步如果项目组件库成熟改动量不大如果项目是手写样式为主就要多花点时间对齐。第二步接入数据层。AI 生成的是静态结构我要把里面的假数据替换成真实的接口调用或状态管理。这一步要注意的是不要把请求逻辑写在展示组件里保持展示和数据的分离否则后期测试和复用都会很痛苦。第三步补充交互逻辑。按钮点击、表单校验、路由跳转这些AI 通常只给了占位需要人工补全。我习惯在补交互的时候顺手写单元测试尤其是那些有分支逻辑的交互测试能帮你提前发现边界问题。整个流程走下来一个中等复杂度的组件从需求到可提交代码大概两到三小时。对比纯手写时间省了差不多一半而且因为结构是 AI 铺的我反而有更多精力去打磨交互细节和边界处理。4. 实操全流程一个设备监控卡片的完整落地记录4.1 需求梳理与提示词编写需求原文是“做一个设备监控卡片显示充电桩的实时状态能看详情能重启。”信息量很少我需要先补齐隐含约束。我列了一份清单设备名称、在线状态、三个核心指标功率、电压、电流、两个操作按钮、三种设备状态在线、离线、告警。然后按前面说的四段式模板写成提示词。这里有个经验提示词里要明确技术栈。我写的是“使用 React TypeScript样式用 CSS Modules”这样 AI 生成的代码风格和项目一致省去转换成本。如果不指定它可能给你 Vue 的写法或者用内联样式后期改起来很烦。4.2 结构审查与调整AI 第一版给的结构里把三个指标各自包了一层容器导致层级到了五层。我判断这是冗余的直接让它合并成一层用 flex 布局排列。调整后的结构清爽很多。这一步我大概花了十分钟但省下了后面写样式时跟层级较劲的时间。审查时我还发现它把“远程重启”按钮和“查看详情”按钮放在了同一层级但重启是危险操作应该视觉上弱化并加二次确认。这个业务判断 AI 给不了必须人来补。我在提示词里追加了“重启按钮使用次要样式点击后弹出确认对话框”重新生成后符合预期。4.3 样式生成与令牌对齐样式生成阶段我把项目的设计令牌清单贴进去要求它只能用清单里的值。第一版产出后我检查了一遍发现它给告警状态用了一个清单外的橙红色。我把它纠正回--color-danger并强调“告警和错误统一用 danger 色”。这种小偏差如果不检查积累多了就会破坏视觉一致性。指标数值的字号我要求用 24px 加粗但 AI 一开始给的是 20px。我判断 24px 在卡片里更醒目符合监控场景“一眼看到关键数据”的需求坚持改了回来。这类判断没有绝对对错取决于你的使用场景但你要有明确的理由而不是凭感觉来回改。4.4 状态补全与边界处理状态补全是整个流程里最费心力的一环。我让 AI 先输出状态矩阵然后逐个实现。离线状态下三个指标要置灰并且不显示数值改为显示“--”告警状态下状态标签变红并加一个呼吸动画但动画要尊重用户的“减少动态效果”系统设置。这个细节 AI 不会主动想到是我在补状态时加进去的。超长设备名称的处理也值得一说。AI 默认没做截断设备名一长卡片就撑破了。我加了单行省略号并在 hover 时用 tooltip 显示全名。这种边界处理是真实项目和演示 demo 的分水岭演示看理想态上线看边界态。4.5 代码接入与自测代码接入项目后我跑了三类自测视觉走查对照设计令牌逐个核对颜色间距、交互走查每个按钮点一遍每个状态切一遍、边界走查超长文本、空数据、网络失败。三类走查下来又发现两个小问题加载骨架屏的动画时长和项目其他页面不一致以及错误重试按钮的点击区域偏小。都修掉之后才提交。整个流程从接到需求到提交代码实际耗时约两个半小时。如果纯手写我估计要四到五小时。省下来的时间我用来补了单元测试和边界处理整体质量反而比赶工手写更高。5. 常见问题与排查技巧实录5.1 AI 生成的样式和项目对不上怎么办这是最高频的问题。根本原因通常是提示词里没有提供足够的约束。排查顺序是先检查有没有把设计令牌清单贴进去再检查有没有明确要求“只能使用清单内的值”最后检查 AI 有没有偷偷用了它自己的默认值。如果三样都做了还对不上那就是 AI 对某个令牌的理解有偏差直接在提示词里点名纠正比如“主色必须是 #1A73E8不要用其他蓝色”。还有一种情况是项目本身就没有统一的设计令牌那 AI 对不上是必然的。这时候正确的做法不是继续调 AI而是先停下来把设计令牌梳理出来。磨刀不误砍柴工这一步省不得。5.2 生成的结构层级过深怎么处理AI 倾向于给每个逻辑单元都包一层容器导致 DOM 层级膨胀。我的处理原则是能用布局属性解决的不加容器。比如三个指标横向排列用父容器的 flex 加 gap 就够了不需要每个指标再包一层。审查结构树时凡是看到“容器里只有一个子元素”的情况基本都可以合并。层级过深除了影响性能还会让样式覆盖变得困难。你改一个间距可能要穿透好几层维护成本很高。所以我在结构审查阶段会刻意压层级目标是主内容区不超过四层。5.3 状态遗漏怎么系统性避免靠记忆去补状态一定会漏。我的方法是建一张状态检查清单每次生成组件后对照清单过一遍。清单按组件类型分类比如展示类组件查空态、加载态、错误态、超长态操作类组件查禁用态、加载态、成功态、失败态表单类组件查校验态、必填态、只读态。这张清单我用了大半年基本没再漏过状态。注意状态检查清单要根据项目实际情况维护每遇到一个新的边界场景就补一条进去。清单是活的不是写完就扔的。5.4 生成代码的可维护性怎么保证AI 生成的代码有个通病能跑但不好读。变量命名随意、逻辑堆在一起、缺少注释。我的做法是在提示词里加一条“代码需符合项目 ESLint 规范变量命名使用驼峰复杂逻辑加注释”。另外生成后我会做一轮人工重构把过长的函数拆开把魔法数字提取成常量。这一步不能省否则三个月后你自己都看不懂。5.5 排查速查表现象可能原因排查动作颜色对不上未提供令牌或未约束检查提示词是否含令牌清单层级过深AI 默认包容器审查结构树合并单子元素容器状态缺失未要求列状态矩阵补状态清单逐个生成代码风格乱未指定技术栈和规范提示词加技术栈和 lint 要求交互没反应只生成了静态结构人工补交互逻辑和事件绑定移动端错位未考虑响应式补充断点要求和折行规则5.6 几个踩过的坑第一个坑是过度依赖 AI 的审美判断。有次我偷懒没审查配色直接用了 AI 给的方案结果上线后被反馈“看着像十年前的网站”。AI 的审美是训练数据的平均值它不会给你惊喜只会给你安全但平庸的答案。视觉调性这种需要品牌感的地方必须人来定。第二个坑是提示词越写越长。我一度把提示词写到上千字结果 AI 反而抓不住重点产出质量下降。后来我学会分层核心约束放前面细节放后面不重要的直接删。提示词不是越长越好信息密度比长度重要。第三个坑是忘了让 AI 输出可访问性属性。按钮没有 aria-label图片没有 alt表单没有 label 关联。这些在演示时看不出来但上线后是实打实的体验问题。现在我固定会在提示词里加一条“补充必要的可访问性属性”。6. 工具链与协作方式的选型建议6.1 对话式工具和代码内联助手怎么配合对话式工具适合从零探索因为它没有项目上下文反而不会被既有结构束缚能给出更多可能性。代码内联助手适合在既有结构上补细节因为它能看到你项目里的组件和变量生成的代码更贴合。我的配合方式是新页面先用对话式工具出三版结构方案选定后把结构描述和设计令牌一起贴给内联助手让它基于项目现有组件生成代码。这样既有探索的灵活性又有落地的准确性。两者之间用一份结构描述文档做交接避免信息丢失。6.2 团队协作时怎么统一 AI 产出团队里每个人用 AI 的方式不一样产出风格就会五花八门。解决办法是沉淀一份团队级的提示词模板和设计令牌清单所有人共用。模板里固定技术栈、命名规范、状态要求、可访问性要求个人只需要补充业务相关的部分。这样产出的代码风格统一review 成本大幅降低。我们还建了一个AI 产出案例库把生成效果好和不好的案例都存进去标注原因。新人来了先看案例库能少走很多弯路。这个库不需要多正式一个共享文档就够了关键是持续维护。6.3 什么情况下不该用 AI有三种情况我会关掉 AI 自己写。第一种是高度定制化的视觉比如品牌活动页、有强插画风格的界面AI 给不了那种独特感。第二种是性能极度敏感的组件比如长列表、复杂动画AI 生成的代码往往有冗余需要手写优化。第三种是逻辑复杂的交互比如拖拽排序、多步表单联动AI 容易生成看似合理但边界漏洞百出的代码。判断标准很简单如果这个任务的核心难点在“模式化铺量”用 AI如果核心难点在“独特判断或复杂逻辑”自己上。工具是拿来放大能力的不是拿来替代判断的。7. 我个人的一些实际体会用 AI 辅助 UI 生产这一年多最大的感受不是“省了多少时间”而是工作重心的转移。以前我大量时间花在调间距、对颜色、补状态这些机械劳动上现在这些被 AI 接走了我的时间更多花在理解业务、打磨交互、思考边界上。这些恰恰是更有价值、更难被替代的部分。另一个体会是判断力变得更重要了。AI 能一秒给你十个方案但选哪个、改哪里、为什么改全靠你的判断。如果你自己审美和工程素养不过关AI 给你的东西你连好坏都分不清那工具再强也帮不了你。所以我的建议是用 AI 的同时别停下基本功的修炼两者是互相成就的关系。最后分享一个我一直在用的小习惯每次 AI 生成完我都会问自己一句“如果这是我同事提交的代码我会怎么 review”。用这个视角过一遍能发现不少自己偷懒放过的问题。AI 是助手不是背锅侠最终交付的质量责任还是在你身上。