1. 从“拼像素”到“说需求”UI 工作流的真实转折点“自从有了 AI我就再也不想拼 UI 了”——这句话我第一次在团队里听到时还以为是某个前端同事在开玩笑。直到我自己接手一个后台管理系统的改版用传统方式画了三天 PSD改到第四版时甲方说“整体风格再活泼一点”我才真正理解这句话背后的情绪。拼 UI 这件事本质上是在用人力对抗不确定性间距调 2px 还是 4px、圆角是 6 还是 8、阴影透明度 15% 还是 20%这些决策本身没有绝对对错但每一个都要人来做、来对齐、来返工。AI 介入 UI 生产之后变化最大的不是“画得快了”而是决策的起点从像素前移到了描述。你不再需要先打开设计工具、建画板、拉参考线而是先用一段结构化的文字把界面意图讲清楚让模型生成第一版可看的稿子再在此基础上做收敛。这个转变听起来简单但它直接改变了三类人的工作方式独立开发者不用再为“没有设计师”发愁前端可以自己出可用的初稿设计师则从重复劳动里被解放出来把精力放在设计系统和交互逻辑上。这篇文章想聊的不是“AI 能不能做 UI”这种泛泛的话题而是把“AI 辅助 UI 生产”这条链路拆开讲透提示词怎么写才不空泛、生成结果怎么落到真实工程里、PSD 和代码之间怎么衔接、prefab 这类预制体思维为什么关键、以及我在实际项目里踩过的那些坑。关键词里出现的 AI、UI、PSD、Codex、prefab基本覆盖了从描述到落地的完整路径我会按这条路径一段段展开。不管你是刚接触 AI 辅助设计的新手还是已经用过几轮但总觉得“生成的东西没法直接用”的老手下面这些内容应该都能对上你的实际场景。2. 提示词不是许愿池把界面意图翻译成模型能吃的结构2.1 为什么“帮我做个好看的登录页”必然翻车很多人第一次用 AI 生成 UI输入的是“帮我做一个好看的登录页”然后拿到一张配色诡异、布局随机的图就得出结论说“AI 做 UI 不行”。问题不在模型在于这句话里没有任何可执行的约束。UI 本质上是约束的集合屏幕尺寸、栅格系统、组件层级、状态、交互反馈缺一个都会让结果发散。模型不知道你说的“好看”是极简还是拟物是深色还是浅色是移动端还是桌面端它只能按训练数据里最高频的模式去猜猜错是必然的。我后来总结出一个可复用的提示词骨架把界面描述拆成五层场景层、布局层、组件层、样式层、状态层。场景层说清楚这是什么产品、给谁用、在什么设备上布局层定义整体结构比如“顶部导航 左侧菜单 主内容区三栏”组件层列出具体元素比如“搜索框、数据表格、分页器”样式层给色彩、圆角、间距、字体的倾向状态层补充空态、加载态、错误态。这五层写下来通常两三百字但生成质量会有质的差别。2.2 一个可以直接抄的后台列表页提示词拿一个典型的后台数据列表页举例我实际用的提示词大概是这样组织的场景B 端后台管理系统面向运营人员桌面端 1440px 宽度。 布局左侧固定 220px 导航栏右侧主区域顶部 56px 工具栏下方为数据表格。 组件工具栏含标题、搜索输入框、日期范围选择、新建按钮表格含复选框列、 名称列、状态标签列、更新时间列、操作列底部含分页器。 样式浅色主题主色 #2563EB圆角 8px卡片阴影轻微字体系统默认无衬线。 状态需要体现空数据状态和加载骨架屏两种变体。这段提示词的价值在于它把“我要什么”变成了“模型能逐条核对什么”。生成结果出来后我可以逐项对照导航宽度对不对、工具栏高度对不对、状态标签有没有、分页器在不在。哪一项不对就针对那一项补一句约束重新生成而不是整张推翻重来。这种逐项收敛的思路比一次性追求完美要高效得多。2.3 提示词里的“负向约束”同样重要除了告诉模型要什么还要告诉它不要什么。我踩过的一个坑是生成的后台页面里模型自作主张加了一堆装饰性插画和渐变背景看起来很“设计感”但完全不符合 B 端工具类产品的调性。后来我在提示词末尾固定加一段负向约束不要使用装饰性插画和人物图片不要使用大面积渐变和玻璃拟态不要添加提示词未提及的额外模块表格行高不要超过 48px这几条加上之后生成结果的“可用率”明显提升。负向约束的本质是排除高频但不符合场景的模式模型在缺乏明确指令时倾向于选择视觉冲击力强的方案而工具类产品恰恰需要克制。提示提示词不是一次写完就固定的建议把它当成一个持续迭代的配置文件。每遇到一次“生成结果跑偏”就把对应的约束补进去几轮之后你会拥有一套属于自己的高质量提示词模板。3. 从生成稿到工程稿PSD、代码与 prefab 的三岔路口3.1 生成的是图交付的是结构AI 生成的 UI 稿无论看起来多完整本质上还是一张扁平的视觉结果。但真实项目要的不是图是结构图层要分组、组件要复用、样式要能改、状态要能切换。这就是为什么很多人拿到生成稿之后觉得“没法用”——因为从图到结构之间还缺一道翻译工序。这道工序做得好不好直接决定了 AI 生成的内容是“参考图”还是“可交付物”。我的做法是生成稿只作为视觉基准不直接进工程。拿到稿子后先在设计工具里按组件粒度重新组织图层把重复出现的元素按钮、标签、输入框抽成组件把颜色、圆角、间距抽成样式变量。这一步看起来是额外工作但它让后续的修改成本从“改十处”变成“改一处”。AI 帮你省下的是从零到一的时间而从一到可维护仍然需要人来建立结构。3.2 PSD 在这个链路里还有没有位置关键词里出现了 PSD说明很多人仍然在用 Photoshop 作为 UI 生产工具。我的看法是PSD 在 AI 辅助链路里依然有用但角色变了。它不再是“从零绘制”的主战场而是精修和交付的容器。AI 生成初稿后如果团队协作流程依赖 PSD可以把生成稿导入 PS利用图层样式、智能对象做细节打磨再导出切图给开发。但要注意PSD 的图层命名和分组如果混乱开发拿到之后一样是灾难所以导入后第一件事就是规范图层结构。如果你的团队已经转向 Figma 或类似工具那 PSD 更多是历史资产的归档格式。我实际的做法是新项目直接用在线设计工具老项目需要复用时才把 PSD 里的组件重新整理成可复用资源。不要为了“统一格式”而强行把所有东西塞回 PSD工具是服务于流程的不是反过来。3.3 prefab 思维为什么它比“画得好看”更重要prefab预制体这个概念来自游戏引擎指的是把一组配置好的对象打包成可复用的模板。放到 UI 生产里prefab 思维的核心是任何出现两次以上的界面元素都应该被定义为可配置的模板。AI 生成 UI 时如果你在提示词里就按 prefab 的方式描述比如“按钮有三种变体主按钮、次按钮、文字按钮”生成结果的结构性会好很多。我在一个 Unity 项目里做过对比同样是用 AI 生成设置面板A 版提示词只描述“一个设置页面”生成结果是一堆散乱的控件B 版提示词明确说“每个设置项是一个 prefab包含标题、说明文字、开关控件三部分”生成结果直接就是可实例化的结构。后者的返工量比前者少了大概六成。prefab 思维的价值不在于技术实现而在于它强迫你在描述阶段就想清楚复用边界。交付形态适合场景AI 介入程度主要返工点纯视觉稿概念验证、风格探索高可直接生成结构缺失难以复用PSD 精修稿传统设计交付流程中生成后精修图层混乱切图繁琐组件化设计稿中大型产品迭代中高生成后组件化样式变量需手动对齐prefab 结构游戏、跨端复用场景高提示词即结构需提前定义复用边界这张表不是让你二选一而是帮你判断当前项目该停在哪个阶段。概念阶段停在视觉稿就够了进入开发就必须往组件化和 prefab 方向走。4. Codex 与 AI Agent把描述直接变成可运行界面4.1 Codex 类工具到底在解决什么问题Codex 这类工具的核心能力是把自然语言描述转成代码。放到 UI 场景里它解决的是“设计稿到代码”之间那段最枯燥的翻译工作。传统流程里前端要对着设计稿量间距、取色值、写样式一个页面几百行 CSS 是常态。有了 Codex 类工具之后你可以直接把组件描述喂给它让它生成结构化的 HTML/CSS 或组件代码你只需要做校对和微调。但这里有个关键认知Codex 生成的是起点不是终点。它生成的代码通常能跑但未必符合你项目的规范——命名风格、目录结构、状态管理方式都可能对不上。我实际用下来的经验是把 Codex 当成一个“写初稿很快但需要 review 的初级开发”它产出的代码必须经过人工审查才能进主干。审查的重点不是“能不能跑”而是“符不符合项目约定”。4.2 让 Codex 产出可用代码的三个前置条件第一个条件是技术栈要明确。你不能只说“生成一个列表页”要说“用 React TypeScript Tailwind CSS 生成一个列表页组件”。技术栈不明确生成结果就是四不像。第二个条件是组件边界要清晰告诉它哪些是独立组件、哪些是容器它才会按组件化的方式组织代码。第三个条件是样式约定要给出比如“间距使用 4 的倍数”“颜色使用 CSS 变量”否则它会硬编码一堆魔法数字。我踩过的一个典型坑是让 Codex 生成一个带表单验证的页面结果它把验证逻辑和 UI 逻辑混在一个文件里几百行代码没法维护。后来我改成先让它生成“纯 UI 组件”再单独生成“验证逻辑 hook”最后组装代码质量立刻上了一个台阶。这个经验说明AI 生成代码的质量很大程度上取决于你给它的任务粒度。4.3 AI Agent 在 UI 链路里的位置AI Agent 比单次代码生成更进一步它能根据目标自主拆解任务、调用工具、迭代结果。在 UI 场景里Agent 可以做到读取设计稿 → 识别组件 → 生成代码 → 运行预览 → 根据报错自动修复。这个闭环听起来很美好但实际落地时Agent 的自主性越强你对它的约束就要越明确否则它会在错误的方向上越走越远。我的做法是给 Agent 设定明确的“检查点”每完成一个组件就停下来让我确认而不是一口气生成整个页面。这样虽然交互次数多了但返工成本低。另外Agent 生成的代码一定要进版本控制每次迭代都有记录出问题可以回滚。把 Agent 当成一个需要管理的协作者而不是一个许愿机这个心态转变很重要。5. 那些没人告诉你的坑AI 做 UI 的真实翻车现场5.1 生成结果“看起来对用起来错”这是最常见也最隐蔽的坑。AI 生成的界面在视觉上往往很完整但交互细节全是漏洞按钮没有 hover 态、输入框没有 focus 态、加载状态缺失、错误提示没有位置。原因是提示词里通常只描述了静态布局没有描述状态变化。我现在的习惯是在提示词里强制要求输出状态清单明确列出需要哪些状态生成后再逐个核对。5.2 样式变量对不上设计系统如果你的项目已经有设计系统AI 生成的结果大概率会对不上——它用的色值、间距、圆角都是自己猜的。解决办法是在提示词里直接给出设计系统的 token比如“主色使用 --color-primary间距使用 --space-2 到 --space-8”。如果设计系统 token 太多至少把最核心的十几个给出来。这一步不做后期对齐样式的成本会吃掉 AI 省下的所有时间。5.3 组件命名和目录结构混乱AI 生成代码时组件命名往往很随意Component1、MyButton、List这种名字满天飞。进项目之前一定要重命名按项目约定来。目录结构同理AI 不知道你的项目是按功能分目录还是按类型分目录生成的文件位置通常需要手动调整。这些看起来是小事但积累起来就是技术债。5.4 过度依赖生成丧失判断力最后一个坑最要命用久了 AI 之后自己反而不思考了。生成什么就用什么不再去判断间距是否合理、层级是否清晰、交互是否顺畅。AI 是放大器它放大你的判断力也放大你的懒惰。我的建议是每次生成结果都问自己三个问题这个布局在真实场景下合理吗这个交互用户能理解吗这个样式符合产品调性吗三个问题有一个答不上来就说明你该停下来想想了。注意AI 生成的 UI 稿在正式使用前务必检查可访问性包括对比度是否达标、点击区域是否足够大、键盘操作是否可用。这些细节模型通常不会主动考虑但它们是产品能否上线的硬指标。6. 把 AI 嵌进日常一套可复用的工作流6.1 我的日常 UI 生产流程经过大半年的磨合我现在的工作流大概是这样先用结构化提示词生成视觉初稿快速确认方向方向对了之后把初稿拆成组件清单逐个用 Codex 生成组件代码代码进项目后用设计系统的 token 替换硬编码样式最后跑一遍状态检查清单补齐交互态。整个流程里AI 承担的是“从零到一”和“从一到代码”两段人承担的是“方向判断”和“质量把关”。这套流程跑下来一个中等复杂度的页面从描述到可运行代码大概能从传统方式的两三天压缩到半天左右。压缩的不是思考时间是重复劳动时间。省下来的时间我用来做更重要的事梳理交互逻辑、检查边界情况、优化设计系统。6.2 团队协作里怎么用如果是团队协作AI 生成的内容一定要有明确的交接规范。我的做法是生成稿必须附带提示词原文这样别人知道这版是怎么来的改的时候有据可依生成的代码必须过 lint 和 review不能因为是 AI 写的就降低标准组件必须登记到组件库避免重复生成。这几条规矩定下来之后团队里 AI 的使用效率明显提升也不会出现“每个人都在重复造轮子”的情况。6.3 什么情况下不该用 AI不是所有 UI 都适合 AI 生成。高度定制化的品牌页面、需要精细动效的营销页、涉及复杂业务逻辑的表单这些场景 AI 生成的初稿往往离可用状态很远改起来比自己画还慢。判断标准很简单如果这个界面的核心价值在于视觉独特性或交互复杂度AI 的边际收益就低如果核心价值在于信息组织和结构复用AI 的收益就高。后台系统、工具类页面、标准化表单这些是 AI 的主场。7. 关于工具选型和长期习惯的几点个人体会工具层面我的建议是不要追新。Codex 类工具、AI Agent、各种生成式设计工具底层能力差异没有宣传的那么大真正拉开差距的是你的提示词质量和工程规范。与其花时间试十个工具不如把一个工具用透把提示词模板打磨好。我自己用的工具换过几轮但提示词骨架和检查清单基本没变因为它们沉淀的是方法论不是工具特性。习惯层面有两个动作我坚持了很久收益很大。一个是维护自己的提示词库把每次好用的提示词存下来按场景分类下次直接改参数复用。另一个是维护翻车清单每次生成结果出问题就记一笔写清楚现象和原因下次生成前先过一遍清单。这两个习惯看起来笨但它们让我的 AI 使用效率在几个月里翻了一倍不止。最后说一句实在话AI 让拼 UI 这件事变得不那么必要了但“理解界面为什么这样设计”这件事AI 替不了你。工具越强判断力越值钱。把省下来的时间花在提升判断力上才是这波变化里最划算的投资。