1. 从“生成一张图”到“交付一套 UI”之间到底隔着什么“AI 设计”这个词现在被用得很泛。打开任何一个设计社区满屏都是“一句话生成一张海报”“输入提示词秒出界面稿”的演示。但如果你真的在团队里干过完整项目就会知道生成一张好看的图和交付一套能上线、能维护、能扩展的 UI完全是两码事。前者是灵感层面的爆发后者是工程层面的收敛。我身边不少设计师朋友最近都在焦虑同一件事AI 出图这么快我是不是要被替代了但真正上手用了一段时间之后大家的共识反而变成了另一个方向——AI 把“画图”这件事的门槛拉低了却把“判断”和“系统化”的价值抬高了。因为当生成变得廉价稀缺的就不再是那张图而是知道该生成什么、生成之后怎么筛选、怎么把它变成一套有规范、有组件、有状态、能交给前端落地的完整体系。这篇内容我想聊的就是这条链路从一个模糊的需求出发用 AI 辅助生成第一张概念图然后一步步把它扩展成一套完整的 UI 设计系统最后交到前端手里能跑起来。中间会涉及工具选型、提示词写法、组件抽象、设计规范、和前端协作的接口约定以及我自己踩过的那些坑。适合正在用 AI 做设计的设计师、想理解设计链路的开发者以及任何对“AI 到底怎么融进真实工作流”感兴趣的人。先把结论摆前面AI 在设计流程里的正确定位不是“替你做设计”而是“帮你把探索阶段的成本压到接近于零从而把省下来的时间投到系统化和验证上”。理解这一点后面所有的操作逻辑就都顺了。2. 第一张图之前需求拆解比提示词更重要2.1 为什么直接写提示词往往出不来能用的东西大多数人用 AI 生成 UI 的第一反应是打开工具敲一句“帮我设计一个电商 App 首页”然后期待奇迹。结果出来的东西要么是四不像要么是看着漂亮但完全没法用。问题不在工具在于你把“设计决策”这件事整个甩给了模型。一个真实项目里在画第一笔之前设计师脑子里已经跑过一轮拆解这个产品给谁用、核心任务是什么、信息层级怎么排、有哪些必须出现的元素、品牌调性偏冷还是偏暖、目标平台是移动还是桌面。这些决策如果不在提示词里体现模型只能靠训练数据里的“平均审美”来猜出来的自然是平庸的、放之四海皆可的模板。我的做法是在打开任何 AI 工具之前先花十分钟写一份“设计简报”哪怕只有几行。这份简报包含四个部分用户画像、核心场景、必须元素、风格约束。举个例子如果要做的是一个面向中老年用户的健康管理 App那“必须元素”里就得明确写上大字号、高对比度、少层级如果是面向设计师的协作工具那信息密度可以高、可以玩深色主题。2.2 把模糊需求翻译成结构化提示词的四个维度写提示词这件事本质是把设计简报翻译成模型能理解的结构。我总结下来有四个维度必须覆盖缺一个出来的结果就会跑偏。第一个维度是主体与场景。不要只说“一个页面”要说“一个移动端电商商品详情页用户从推荐流点进来主要动作是加购”。场景越具体模型对布局的推断越准。第二个维度是布局与层级。明确告诉它信息怎么排比如“顶部是商品大图轮播中部是价格和标题下方是规格选择底部固定加购按钮”。这一步其实就是在用自然语言画线框图。第三个维度是风格与调性。这里要避免“好看”“高级”这种虚词换成可感知的描述比如“极简、大量留白、圆角 12px、主色是低饱和的雾霾蓝”。第四个维度是技术约束。比如“适配 375 宽度”“使用系统字体”“符合移动端点击热区不小于 44px”。这些约束会直接影响生成结果的可用性。把这四个维度拼起来就是一段结构化的提示词。它比一句“帮我设计个页面”长得多但出来的东西可用度完全不是一个量级。2.3 一个可复用的提示词骨架我平时用的骨架大概长这样你可以直接改成自己领域的版本[平台与场景] 一个面向[用户画像]的[平台]端[页面类型]用户的核心任务是[核心动作]。 [布局结构] 从上到下依次是[模块1]、[模块2]、[模块3]底部[固定/非固定][关键操作]。 [风格约束] 整体风格[调性描述]主色[色值或描述]圆角[数值]间距[数值]字体[描述]。 [技术约束] 适配[尺寸][其他硬性要求]。这个骨架的好处是它强迫你在生成之前就把该想的想清楚。很多时候写着写着你会发现某个模块自己都没想明白要放什么那说明需求本身还没拆解到位这时候该做的是回去和产品对齐而不是让 AI 帮你猜。提示提示词写得越具体生成结果的方差越小。如果你发现每次生成差异巨大八成是提示词里“风格约束”和“布局结构”太模糊。3. 生成之后才是重头戏筛选、拆解与组件化3.1 为什么不能直接拿生成图去交付假设你现在已经生成了一张相当不错的界面图视觉上挑不出大毛病。但如果你直接把这张图丢给前端说“照着做”大概率会得到一堆抱怨。原因很简单一张静态图里没有状态、没有交互、没有边界情况、没有响应式规则。举个具体的例子。生成图里有一个按钮看起来是蓝色的圆角矩形。但前端需要知道这个按钮 hover 是什么样、按下是什么样、禁用是什么样、加载中是什么样、不同尺寸有没有变体、文字超长怎么办、在窄屏上会不会换行。这些信息静态图里一个都没有。如果设计师不补前端就只能自己猜猜出来的结果和设计意图往往对不上最后返工。所以生成图的价值不在于“它就是最终稿”而在于“它是一个高质量的起点”。接下来要做的是把它拆解成一套可复用的组件和规范。3.2 从一张图里抽出设计令牌设计令牌这个词听起来玄其实就是把设计里所有可复用的“原子值”抽出来变成有名字的变量。颜色、字号、间距、圆角、阴影这些都是令牌。从生成图里抽令牌的过程其实是一次反向工程。你盯着图问自己这个主色具体是什么值标题和正文的字号差多少卡片之间的间距是 16 还是 24把这些值一个个量出来、命名、归类就得到了一套最基础的设计令牌。我习惯用这样的命名结构类别-用途-变体。比如颜色是color-primary-default、color-primary-hover、color-text-secondary间距是space-sm、space-md、space-lg。命名一旦规范后面无论是做组件还是和前端对接沟通成本都会大幅下降。这里有个经验不要一上来就追求令牌的完备性。先抽最常用的那十几个用起来缺了再补。我见过太多团队花两周定义了几百个令牌结果实际用到的不到三分之一剩下的全成了维护负担。3.3 把界面拆成组件树抽完令牌下一步是把整张图拆成组件。拆的原则是“可复用”和“可独立描述”。一个卡片、一个按钮、一个输入框、一个标签都是组件。拆的时候要问自己这个东西在别的页面会不会再出现如果会它就该被抽成组件。拆完之后你会得到一棵组件树。顶部是页面往下是区块再往下是具体组件。这棵树其实就是前端的组件结构设计师如果能在交付时把这棵树画清楚前端会省掉大量理解成本。我通常会用一张表格来记录组件清单包含组件名、包含的令牌、有哪些状态、有哪些变体。这张表就是设计和开发之间的契约。组件名使用的令牌状态变体主按钮color-primary-default, space-md, radius-md默认/悬停/按下/禁用/加载大/中/小商品卡片color-surface, shadow-sm, space-lg默认/悬停横向/纵向标签color-tag-bg, color-tag-text默认/选中无这张表看起来朴素但它能挡掉后面 80% 的扯皮。3.4 状态和边界静态图永远不会告诉你的部分前面反复提到状态这里展开说。一个组件至少要考虑五种状态默认、悬停、聚焦、禁用、加载。如果是可交互的还要考虑按下和选中。这些状态在生成图里通常只体现了默认态剩下的得设计师自己补。补状态的时候有个技巧不要孤立地设计每个状态而是定义状态之间的“变化规则”。比如悬停态就是默认态的主色加深 10%禁用态就是整体透明度降到 40% 并去掉阴影。规则一旦定下来所有组件都套用同一套逻辑一致性自然就有了。边界情况同样重要。文字超长怎么办数据为空怎么办网络加载失败怎么办这些在真实产品里天天发生但生成图里永远不会出现。设计师如果不在交付时把这些画出来前端就只能自己发挥最后出来的东西五花八门。4. 让 AI 参与系统化批量生成与一致性控制4.1 用 AI 扩展组件变体而不是从零画当你有了基础组件和令牌之后AI 的用法就变了。这时候不该再让它“自由发挥设计一个页面”而是让它“基于已有规范生成某个组件的变体”。比如你已经有了一个主按钮现在需要它的加载态、禁用态、小尺寸版本。你可以把主按钮的描述和令牌值作为上下文喂给模型让它按同样的风格生成变体。因为有了约束出来的结果一致性会高很多。这个思路可以扩展到整个页面。当你需要设计一个新页面时不要从空白开始而是把已有的组件库和令牌作为约束条件让 AI 用这些“积木”来搭新页面。这样出来的结果天然就和现有系统兼容。4.2 一致性检查AI 也能帮你找不一致人眼在检查几十个页面的一致性时很容易疲劳漏掉一些细节。这时候可以让 AI 帮忙做一轮扫描。把设计稿的描述或者截图喂给模型让它找出“哪些地方用了不在令牌表里的颜色”“哪些间距不符合规范”“哪些圆角值不统一”。这个用法听起来有点反直觉因为大家习惯让 AI 做创造而不是做检查。但实测下来AI 在“找规律中的异常”这件事上表现相当不错尤其是当规范被明确写出来之后。4.3 提示词模板化把好用的提示词沉淀下来用 AI 做设计最浪费时间的动作是每次重新想提示词。我的做法是建一个提示词库把验证过好用的提示词按场景分类存下来。比如“移动端列表页”“桌面端表单”“空状态插画”各有一套模板用的时候改几个变量就行。这个库的价值会随着时间累积。团队里一个人调好的提示词其他人可以直接复用整体效率是叠加的。而且提示词库本身就是一种团队资产它把“怎么用 AI”这件事从个人经验变成了可传递的方法。注意提示词库要定期清理。模型在迭代有些老提示词可能在新版本上效果变差了留着反而误导人。5. 交付给前端设计师必须补上的那几块拼图5.1 设计稿之外前端真正需要什么很多设计师以为交付就是给一张 Figma 链接。但前端拿到链接之后真正需要的是几样东西完整的组件清单、每个组件的状态和变体、设计令牌的具体值、响应式断点规则、以及交互说明。交互说明是最容易被忽略的。比如一个下拉菜单展开动画是多久、缓动曲线是什么、点击外部关闭还是点击选项关闭、键盘能不能操作。这些如果不在交付时写清楚前端要么来问要么自己拍脑袋两种都费时间。我现在的习惯是交付时附一份“实现说明”用最朴素的语言把上面这些写清楚。不需要多正式一个文档就行。这份文档写起来可能花半小时但能省掉后面好几轮沟通。5.2 设计令牌怎么落到代码里设计令牌最终要变成代码里的变量才能被前端直接用。常见做法是维护一份令牌的源文件然后通过工具生成不同平台需要的格式。比如同一份令牌可以生成 CSS 变量、也可以生成 JavaScript 对象、还可以生成设计工具里的样式。这样做的好处是单一数据源。设计师改了令牌值前端那边同步更新不会出现“设计稿改了但代码没改”的经典问题。工具选型上社区里有不少成熟方案核心思路都是“一份源多端生成”。如果团队规模小用不上复杂工具也可以手动维护一份 CSS 变量文件设计师和前端约定好命名规则改的时候两边同步。虽然土但有效。5.3 和前端对齐“组件边界”的一次真实沟通我印象很深的一次协作是做一个数据看板。设计稿里有一个复杂的图表卡片包含标题、筛选器、图表主体、图例、底部操作。我一开始把它当成一个整体组件交付前端看完说这个没法做因为筛选器的逻辑和图表主体的逻辑完全独立硬塞进一个组件里会导致状态管理混乱。后来我们重新对齐把它拆成了三个组件筛选器、图表主体、操作栏外层用一个容器组合。拆完之后前端说清晰多了。这件事让我意识到组件边界不只是设计问题也是工程问题。设计师在拆组件时如果能理解一点前端的组合逻辑交付质量会高很多。一个实用的判断标准是如果两个部分的状态是独立变化的它们就该是两个组件。筛选器变了不一定影响图表数据图表数据变了不一定影响操作栏那它们就该分开。6. 那些没人告诉你但一定会踩的坑6.1 生成图里的“假精致”AI 生成的界面图有个通病我称之为“假精致”。远看很漂亮放大一看全是问题文字是乱码或者无意义的占位符、图标风格不统一、间距肉眼可见地不齐、颜色在不同区域有微妙偏差。如果你直接把这种图当设计稿交付前端会疯掉。所以生成之后必须有一轮“清洗”把占位文字换成真实文案、把图标统一成一套、把间距对齐到网格、把颜色收敛到令牌。这一轮清洗的工作量不小但它是把“灵感图”变成“设计稿”的必经步骤。6.2 过度依赖生成导致的设计同质化用同一个模型、相似的提示词生成出来的东西会越来越像。这是训练数据的锅模型倾向于输出“平均最优解”。如果整个团队都用 AI 生成最后产品会失去辨识度。对抗同质化的办法是把 AI 生成当作起点而不是终点在生成结果上做人工的“破格”。比如故意打破对称、引入一个不常见的配色、用一个有性格的字体。这些人工干预才是品牌感的来源。AI 负责效率人负责个性这个分工不能乱。6.3 提示词里的“隐藏偏见”提示词里的一些词会带来意想不到的偏见。比如你说“现代简约”模型可能默认给你冷色调、无衬线字体、大量留白。你说“专业”可能默认给你蓝色。这些默认值不一定适合你的产品但如果你不主动覆盖它们就会悄悄进入设计。我的做法是在提示词里主动写反直觉的约束。比如“现代简约但使用暖色调”“专业但避免使用蓝色”。这种反向约束往往能逼出更有意思的结果。6.4 版本管理AI 生成内容的可追溯性AI 生成的东西有个麻烦就是版本管理。你改了提示词重新生成出来一张新图但旧的那张可能还有用。如果不做记录过两天就忘了哪张是哪次生成的、用的什么提示词。我的做法是每次生成都记录三样东西提示词、生成时间、这张图的用途或评价。可以记在文档里也可以直接写在文件名里。这样回溯的时候有据可查。团队协作时这个记录更重要否则别人根本不知道你的图是怎么来的。7. 我对 AI 设计这件事的真实看法用了大半年 AI 辅助设计之后我的感受是它确实改变了工作方式但没有改变工作的本质。设计的本质是解决问题是理解用户、定义问题、权衡取舍。AI 在这些环节里能帮上忙但替代不了判断。它真正改变的是执行环节的成本结构。以前画十个方案要一天现在十分钟。省下来的时间如果用来做更多的方案那是浪费如果用来做用户验证、做系统化、做和开发的深度协作那才是把 AI 的价值用对了地方。对设计师来说现在最该练的能力可能不是提示词写得多花哨而是判断力——判断哪个方案值得深入、判断组件该怎么拆、判断哪些细节会影响落地。这些能力 AI 给不了但恰恰是它把执行成本拉低之后变得最值钱的东西。我现在的日常是用 AI 快速铺开探索面然后花大量时间在收敛和系统化上。这个比例大概是二八开AI 占二人占八。如果你现在的比例是反过来的可能得重新想想自己到底在为什么创造价值。