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 占二，人占八。如果你现在的比例是反过来的，可能得重新想想，自己到底在为什么创造价值。
