★ FEATURED ARTICLE 1. 从手写像素到对话生成UI 开发范式正在被重写我做了快十年的前端和客户端界面从最早用 Photoshop 切图、Dreamweaver 拖表格到后来手写 Flex 布局、调 margin 调到凌晨三点再到组件库时代靠 Storybook 一个个对状态。说实话UI 这活儿从来不是难而是碎——碎到你明明知道长什么样却要花几个小时把像素、间距、圆角、阴影、hover 态、禁用态、空状态、加载态一个个码出来。直到我开始把 AI 真正嵌进 UI 生产流程才第一次有了再也不想回去手拼的念头。这篇不是工具软文也不是AI 取代设计师的焦虑贩卖。我想聊的是当一个有经验的开发者把 AI 当成 UI 生产管线里的一个环节而不是一个玩具时整个工作流会发生什么变化。核心关键词就几个——AI、UI、PSD、Codex、prefab。它们分别对应了设计稿输入、代码生成、组件资产化这三段链路。我会把每一段拆开讲清楚为什么这样接、中间会踩什么坑、哪些环节 AI 目前还靠不住、哪些环节它已经强到让我放弃手写。适合谁看如果你是会写代码但对 UI 效率不满意的开发者或者是懂设计但想快速把稿子变成可运行界面的产品/设计同学再或者你只是好奇AI 到底能不能真的把 UI 写出来这篇都能给你一套可复现的思路。我不假设你用什么框架React、Vue、Unity、Android 原生都行因为底层逻辑是通的把视觉意图翻译成结构化描述再把结构化描述翻译成组件代码最后把组件沉淀成可复用资产。AI 在这三步里能干的活比大多数人想的多得多。先说结论免得你看到一半觉得我在画饼AI 目前最擅长的是从明确输入生成第一版可运行代码最不擅长的是理解你脑子里那个说不清的审美。所以正确的用法不是让它替你做设计决策而是让它把你已经想清楚的东西以十倍速度落地。下面我按真实工作流顺序一段段拆。2. 设计稿到代码PSD 和截图到底该怎么喂给 AI2.1 为什么直接丢 PSD 给 AI 往往翻车很多人第一反应是我把 PSD 丢给 AI让它直接出代码不就行了。我试过翻车率极高。原因不在 AI 笨而在 PSD 这种格式本身对机器极不友好。一个 PSD 里可能有一百多个图层命名是图层 1 副本 3、矩形 27图层组嵌套五六层还有各种被隐藏的废弃版本、被栅格化的文字、带蒙版的智能对象。AI 拿到这种东西等于让一个从没见过你项目的人去猜哪块是按钮、哪块是背景装饰。更关键的是PSD 里没有语义。它只有像素和图层堆叠顺序。而代码需要的是语义这是一个可点击的按钮还是一个纯展示的标签这个容器是固定宽度还是自适应这些信息 PSD 里根本没有全靠人脑补。所以直接喂 PSDAI 只能给你一堆绝对定位的 div改起来比手写还累。我的做法是PSD 只作为视觉参考不作为生成输入。真正喂给 AI 的是我从 PSD 里翻译出来的结构化描述。这个翻译过程听起来多了一步但实际上它逼你把设计意图想清楚反而减少了后面返工。2.2 截图加结构化描述目前最稳的输入组合实测下来最稳的组合是一张干净的截图 一段结构化文字描述。截图让 AI 理解整体布局和视觉风格文字描述补上截图里看不出来的交互语义和约束条件。结构化描述我一般按这个模板写你可以直接抄页面登录页 布局垂直居中卡片卡片宽 400px屏幕小于 480px 时卡片宽度 100% 减 32px 边距 卡片内元素从上到下 1. Logo 图片高 48px居中 2. 标题文字欢迎回来字号 24px字重 600颜色 #1A1A1A下边距 8px 3. 副标题请登录你的账户字号 14px颜色 #666下边距 24px 4. 邮箱输入框placeholder邮箱地址类型 email必填 5. 密码输入框placeholder密码类型 password必填右侧有显示/隐藏切换 6. 登录按钮主色 #2563EB圆角 8px高 44px全宽loading 态显示 spinner 7. 底部文字链接忘记密码字号 13px颜色 #2563EB居中 交互提交时按钮进入 loading失败在表单顶部显示红色错误条这段描述大概两百字但它把 AI 需要知道的全部信息都给了层级、尺寸、颜色、状态、交互。AI 拿到这个生成的代码基本能直接跑改动用手指头数得过来。对比直接丢 PSD效率差的是数量级。提示描述里一定要写状态。空状态、加载态、错误态、禁用态——这些是 AI 最容易漏、也是手写时最烦的部分。你写清楚它就能一次生成全。2.3 用 Codex 类工具做描述到代码的转换这里就要提到Codex这类代码生成模型了。它的价值不在于帮你写代码而在于帮你把结构化描述稳定地翻译成符合你项目规范的代码。这两者差别很大。前者是通用能力后者需要你给它上下文。我的做法是给 Codex 喂三样东西结构化描述、项目里已有的一个同类组件作为范例、以及项目的样式规范比如用 Tailwind 还是 CSS Modules命名用 BEM 还是原子类。有了范例它生成的代码风格会和你项目一致不会一会儿用 styled-components 一会儿用内联样式。举个实际例子。我要生成一个数字滚轮效果这个在热词里也出现了Unity 和 Web 都有类似需求。我给 Codex 的描述是组件数字滚轮 行为数字变化时旧数字向上滚出新数字从下方滚入动画 300ms ease-out 结构外层容器 overflow hidden内部两行数字垂直排列通过 transform translateY 切换 约束支持 0-9 单个数字也支持多位数字逐位滚动它给我的第一版代码里动画用了 CSS transition 加 keyframes结构是干净的。但有个问题多位数字时它把每一位都包了一层导致间距不对。我补了一句每位数字宽度固定为 1ch位与位之间无额外间距第二版就对了。这个过程总共花了不到五分钟手写的话光调动画曲线就得二十分钟。2.4 生成之后必须做的一件事语义化重命名AI 生成的代码有个通病类名和变量名是描述性的但不够语义化。比如它会生成.container-1、.text-wrapper、.btn-primary-large-blue。这些名字能跑但维护起来是灾难。我养成的习惯是生成完立刻做一轮重命名把.container-1改成.login-card把.text-wrapper改成.form-field。这一步花不了两分钟但它决定了这份代码是一次性产物还是能进代码库的资产。很多人抱怨 AI 生成的代码没法维护其实问题往往出在这一步偷懒了。3. 组件资产化prefab 思维才是效率的真正杠杆3.1 为什么单次生成不够资产化才是关键如果 AI 只是帮你把每个页面单独生成一遍那效率提升是线性的。真正让我觉得回不去了的是组件资产化。这个概念在 Unity 里叫 prefab在 Web 里叫组件在 Android 里叫自定义 View本质是一回事把一段 UI 结构和它的行为打包成一个可复用的单元下次直接实例化改一处全局生效。AI 在这个环节的价值被严重低估了。大多数人用 AI 是生成一个页面而我是生成一个组件库。区别在于前者每次都要重新描述后者描述一次、生成一次、之后所有页面都从组件库里拼。举个具体场景。我要做一个后台管理系统有二十个页面每个页面都有表格、筛选栏、分页、弹窗。如果按页面生成我得描述二十次。但如果我先让 AI 生成一套组件——DataTable、FilterBar、Pagination、Modal——然后每个页面只是这些组件的组合那我的工作量从写二十个页面变成写二十段组合配置。3.2 把生成结果沉淀成 prefab 的具体做法我的流程是这样的第一步先让 AI 生成一个最复杂的页面。比如列表页因为它包含了表格、筛选、分页、操作按钮、空状态、加载态信息密度最高。第二步从这个页面里抽出可复用的部分。表格抽成DataTable筛选抽成FilterBar以此类推。抽的时候我会让 AI 帮我做一件事识别哪些部分是页面特有的哪些是通用的。它的判断不一定全对但能给我一个起点。第三步把抽出来的组件单独生成一遍这次带上完整的 props 定义和状态处理。比如DataTable的 props 包括columns、data、loading、emptyText、onRowClick、rowKey。这些 props 一旦定下来后面所有页面都按这个契约来。第四步也是最关键的一步建一个组件预览页。把所有生成的组件在一个页面里全部渲染出来每个组件展示它的所有状态。这个页面是我后续开发的字典我要用哪个组件先去预览页看它长什么样、支持哪些 props然后直接引用。这套流程跑下来我做一个新页面的时间从半天压缩到一两个小时而且风格绝对统一因为所有组件都来自同一个源头。3.3 prefab 的版本管理AI 生成组件后最容易忽略的坑这里有个坑我必须单独说AI 生成的组件会漂移。什么意思你今天让 AI 生成一个按钮明天又让它生成一个按钮两次的结果可能不一样——圆角差 2px、hover 颜色差一点、padding 不一致。如果你不做版本管理组件库很快就会变成一锅粥。我的解决办法是组件一旦定稿就冻结它的生成提示词。把生成这个组件的完整描述存成一个文件比如button.prompt.md里面写清楚所有规格。以后要改按钮改的是这个提示词文件然后重新生成而不是直接改代码。这样组件永远有一个唯一真相源。另外我会给每个组件写一个极简的测试用例。不是单元测试那种而是渲染出来长什么样的视觉快照。AI 改完组件后跑一遍快照对比颜色、间距变了立刻能发现。这个习惯帮我避免了好几次改 A 页面把 B 页面搞崩的事故。4. 那些 AI 目前还搞不定的 UI 细节4.1 审美判断AI 能生成对的但生成不了好的必须泼一盆冷水。AI 生成的 UI功能上通常没问题但审美上经常差一口气。它能给你一个符合规范的按钮但给不了你一个有品牌感的按钮。它能排出一个整齐的布局但排不出一个有节奏感的布局。这不是模型能力问题是信息问题。审美是大量隐性决策的集合为什么这个间距是 12 而不是 16为什么这个圆角是 6 而不是 8为什么这个阴影是两层而不是一层这些决策背后是品牌调性、用户心理、视觉平衡AI 没有这些上下文只能给你平均值。所以我的做法是AI 负责结构和功能人负责审美微调。生成完之后我一定会手动过一遍间距、颜色、字重、圆角。这一步不能省省了出来的东西就是AI 味——能用但没灵魂。4.2 复杂交互状态多状态叠加时 AI 容易顾此失彼单个状态 AI 处理得很好。但多个状态叠加时它就开始顾此失彼。比如一个按钮同时处于禁用 加载中 有 tooltip的状态AI 生成的代码可能只处理了其中两个。再比如一个表格同时有筛选生效 排序生效 分页在第 3 页 有选中行AI 很容易漏掉某个组合。我的应对策略是把状态组合显式列出来让 AI 逐个处理。不要指望它自己想到所有组合。我会在描述里写按钮状态矩阵 - 默认 / hover / active / focus - 禁用不可点击透明度 0.5 - 加载中显示 spinner不可点击宽度不变 - 禁用 加载中spinner 灰色透明度 0.5 - 带 tooltiphover 时显示禁用时也显示这样列出来AI 基本能全覆盖。你不列它就默认只处理最常见的两三个。4.3 响应式断点AI 的默认断点往往和你的项目不匹配AI 生成响应式代码时默认用的断点通常是 768px、1024px 这种通用值。但每个项目的断点体系不一样有的用 640/768/1024/1280有的用 576/768/992/1200。如果不对齐生成的代码在你的项目里就是错位的。我的做法是在提示词里显式声明断点体系并且给一个已有页面的响应式写法作为范例。这样 AI 会照着你的体系来而不是用它自己的默认值。这个细节很小但不注意的话每个页面都要手动改断点累积起来很烦。5. 把 AI 接进日常 UI 工作流的完整链路5.1 我的实际工作流从需求到上线的六步说了这么多原理我把完整链路串一遍。这是我现在的真实流程你可以直接参考需求理解拿到需求先自己想清楚页面结构、交互、状态。这一步不用 AI因为想不清楚的话AI 也帮不了你。结构化描述把想清楚的东西写成结构化描述就是我前面给的那个模板。这一步是核心描述质量决定生成质量。首版生成把描述 项目范例 规范喂给 Codex 类工具生成首版代码。语义重命名 状态补全手动过一遍改类名补 AI 漏掉的状态。组件抽取如果这个页面有可复用部分抽成组件冻结提示词进组件库。审美微调 响应式对齐手动调间距、颜色、断点确保和项目整体一致。这六步里AI 主要参与第 3 步部分参与第 5 步。第 1、2、4、6 步还是人主导。但就是第 3 步的加速让整体效率提升了三四倍。因为第 3 步原本是最耗时的码字环节。5.2 提示词模板我用了半年的那套我把我的提示词模板整理出来你可以直接改改用角色你是一个资深前端/客户端工程师熟悉 [你的框架] 和 [你的样式方案]。 任务根据下面的结构化描述生成组件代码。 项目规范 - 样式方案[Tailwind / CSS Modules / styled-components / ...] - 命名规范[BEM / 原子类 / ...] - 组件范例[贴一个已有组件的代码] - 断点体系[640/768/1024/1280] 要求 1. 生成完整可运行代码包含所有状态 2. 类名语义化不要用 container-1 这种 3. 响应式按上面的断点体系 4. 不确定的地方用注释标出不要瞎猜 结构化描述 [你的描述]这套模板的关键在项目规范和组件范例两段。没有这两段AI 生成的东西风格是飘的有了这两段它生成的东西基本能直接用。5.3 多 AI 协作什么时候该换一个模型热词里有多 AI 协作我实际用下来确实不同模型有不同擅长。有的模型对布局理解好有的对交互逻辑强有的生成的代码更简洁。我的做法是首版用最擅长的那个卡壳了换一个试试。比如布局类的问题某个模型总是把 flex 和 grid 用混我就换一个。交互逻辑类的问题某个模型总是漏状态我也换。这不是玄学是不同模型的训练数据分布不同。多试几个你会对什么问题找哪个模型有感觉。但要注意不要同时让多个模型改同一份代码。会乱。我的做法是一个模型生成首版人工改改不动了再换模型问而不是让它们互相改。6. 踩过的坑和几条硬经验6.1 别让 AI 碰你的设计系统变量这是我踩过最疼的坑。有一次我让 AI 生成一个页面它没用我项目里定义的设计变量比如--color-primary而是直接写了十六进制颜色#2563EB。当时没注意后来品牌色一改这个页面就成了孤儿颜色对不上。从那以后我定了一条死规矩提示词里必须明确写所有颜色、间距、字号必须引用项目设计变量禁止硬编码。并且生成后我会全局搜一遍十六进制色值和魔法数字发现硬编码就改掉。这个检查花不了一分钟但能省掉后面无数次返工。6.2 生成代码的看起来对陷阱AI 生成的代码有个特点看起来对跑起来也对但边界情况全错。比如一个列表组件正常数据渲染没问题但数据为空时它渲染了个空白没有空状态数据超长时它把布局撑破了没有截断数据加载中它什么都没显示没有骨架屏。这些边界情况AI 默认不处理因为训练数据里大多数示例都是正常情况。所以我的习惯是生成完先不看正常情况先看边界。空数据、超长数据、加载中、错误、权限不足——这几个场景挨个试一遍缺什么补什么。这个习惯帮我拦住了大量上线后才发现的 bug。6.3 关于AI 一键生成类工具的理性看待热词里有一堆AI 一键生成 UI的工具。我的态度是可以试但别指望。这类工具适合做原型、做 demo、做头脑风暴时的视觉参考但不适合直接进生产。原因很简单生产代码需要符合项目规范、需要可维护、需要处理边界而一键生成为了追求一键的爽感往往牺牲了这些。我的用法是用这类工具快速出几个视觉方案挑一个方向对的然后按我自己的流程重新生成一版符合规范的。它帮我解决从 0 到 1 的灵感我自己的流程解决从 1 到 100 的工程化。两者不冲突。6.4 一个反直觉的经验描述写得越细反而越快刚开始用 AI 生成 UI 时我总想少写点让 AI 自己发挥。结果就是反复改改到怀疑人生。后来我发现反过来描述写得越细总耗时越短。因为写描述花的那十分钟省掉的是后面一小时的来回沟通。现在我写描述的时间经常比生成时间还长。但整体算下来还是比手写快得多。因为写描述是想清楚的过程而想清楚本来就是必须的只是以前这个想清楚发生在写代码的过程中现在提前了。7. 我对这套工作流的真实体感用到现在我的体感是AI 把 UI 开发里最枯燥但最必须的那部分——把想清楚的东西翻译成代码——压缩了大概百分之七十的时间。但它没有压缩想清楚本身也没有压缩审美判断和边界处理。所以整体效率提升是显著的但不是十倍那种夸张更像是从一天一个页面变成一天三四个页面。最让我回不去的其实是心理上的变化。以前做 UI一想到要写那么多状态、那么多响应式、那么多重复结构就本能地拖延。现在我知道这些体力活有 AI 兜底我可以把精力集中在真正需要判断的地方——布局怎么排更合理、交互怎么设计更顺、视觉怎么调更有质感。这种把精力花在刀刃上的感觉才是我说再也不想拼 UI的真正原因。如果你刚开始尝试我的建议是别一上来就追求全自动。先从生成单个组件开始跑通描述到代码这一小段找到手感再慢慢扩展到整个页面、整个组件库。这个过程里你会踩坑但每个坑都会让你更清楚AI 能干什么、不能干什么。等你摸清了这个边界它就成了你手里最顺手的工具而不是一个需要你伺候的祖宗。
阅读完成 · 觉得有帮助？
