北京兰亭妙微 UI 设计公司，成立 16 年来，始终保持着对国内外优秀设计作品的学习与研究。我们持续追踪全球前沿的 UI/UX 设计趋势，从中提炼可落地的设计方法论，分享给同样热爱设计的你。

一、全文速览图

 

1. 为什么 AI 没有按照我的规范生成页面？
2. 为什么它明明知道有组件库，却还是没有用？
3. 为什么我已经有 Figma 组件、规范文档，甚至前端工程，AI 生成出来的页面还是很乱？

背后其实是同一件事：AI 时代，设计系统的使用者变了。

过去我们讲设计系统，主要是在服务设计师、研发和团队协作。

设计师通过它统一视觉语言，判断界面质量，维护设计一致性。

研发通过它复用组件，实现页面结构，保证代码可维护。

团队通过它建立共同语言，知道用什么、怎么用、怎么保持一致。

所以，传统设计系统里通常会有三类内容

1. Foundation：颜色、字体、圆角、间距、阴影、动效这些底层视觉规则。
2. 组件：按钮、输入框、图标、导航、弹窗、表格这些可复用界面单元。
3. 规范说明：组件适用场景、使用限制、注意事项和协作方式。

这些内容对团队协作当然非常重要。 但 AI 进入工作流之后，设计系统多了一个新的使用者：AI Agent。

它不只是“看规范”，而是要进一步去 读规则、选组件、拼页面、辅助检查。 它需要知道：

1. 规则在哪里；
2. 组件在哪里；
3. 当前页面该用哪个组件；
4. 页面结构应该怎么组合；
5. 生成后又该按什么标准验收。

所以，传统设计系统给人协作够用，但给 AI 执行还缺几层。

二、传统设计系统，为什么给 AI 还不够

我现在会把这个缺口概括成四件事。

1. 经验没有显性化

很多判断原本是设计师凭经验完成的。比如：

1. 什么场景用表格，什么场景用卡片；
2. 危险操作怎么处理；
3. 筛选条件很多时怎么组织；
4. 页面里哪些区块应该先出现，哪些可以后置。

这些对人来说是经验，对 AI 来说却不是默认知识。

你不写出来，它就不知道。

2. 规则没有集中化

有些规则在 Figma 里，有些在文档里，有些在组件说明里，还有一些藏在团队习惯里。

人可以靠上下文补齐，AI 很容易读漏、读散、读不完整。

最后看起来像“它知道一点，但又没完全知道”。

3. 组件没有索引化

很多团队其实已经有组件库了，但 AI 不一定知道：

1. 组件在哪里；
2. 各自适合什么场景；
3. 有哪些替代方案；
4. 同类组件之间应该优先选哪个。

它可能知道“这里有 Button”，但不知道什么时候用 Primary，什么时候用 Danger，什么时候还要加二次确认。

4. 结果没有可检查化

AI 生成页面之后，如果没有统一的验收标准，它也不知道：

1. 哪些地方算符合规范；
2. 哪些地方算生成偏差；
3. 哪里只是长得像；
4. 哪里才是真的调用了正确组件。

所以很多时候，AI 生成页面缺的不是灵感，也不是提示词不够好，而是缺少一套明确的执行依据。

它缺：

1. 上下文
2. 资产入口
3. 组件选择依据
4. 页面组合模式
5. 执行顺序
6. 验收标准

三、所以这件事，其实要拆成两步

到这里，这件事其实可以拆成两个层面来看：

第一，AI 先读什么。第二，AI 再怎么用。

第一步：搭底座

先让 AI 有东西可读。

这里包括：

1. 大规范
2. Token
3. 基础组件
4. Design MD
5. 初始 Skill

它们解决的是：AI 先理解这套系统的风格、命名、变量、组件和基础规则。

第二步：用底座

再让 AI 知道怎么调用这些资产。

这里包括：

1. 组件索引
2. 节点地图
3. 截图参考
4. 关键词
5. 组件映射
6. 页面模板
7. 选型规则
8. 执行顺序
9. 验收回填

它们解决的是：

AI 怎么找组件、怎么选组件、怎么组合页面、怎么检查结果。

所以前两个模块合在一起，其实是在补一套 AI 执行层。

这一层让设计系统变得：

1. 可读取：AI 能读大规范、Token、基础组件和 Design MD
2. 可检索：AI 能通过组件索引、节点地图和关键词找到组件
3. 可映射：AI 能理解 Token 到组件属性、Figma 到代码组件、Variant 到 Props 的关系
4. 可选型：AI 能根据页面区域和业务意图，列出候选组件、推荐组件和选择理由
5. 可执行：AI 能按顺序读取规则、判断类型、匹配模板、生成页面，并验收回填

四、几种常见咨询场景

说完背景，再回到大家最常来问我的几种情况。

1. 只有 Figma 组件，想让 AI 直接拼页面

很多设计师会说：

我已经有一套 Figma 组件库了，能不能让 AI 直接读取组件，然后帮我拼页面？

这个方向当然可以尝试。 但 Figma 组件更多描述的是 视觉结构、图层关系和基础状态，它不一定告诉 AI：

1. 这个组件适合什么业务场景；
2. 页面区块应该怎么组合；
3. 组件之间有什么优先级。

所以这种场景最容易出现的问题是：AI 看起来用了组件，但页面结构还是很散。

这时要补的往往不是更多单个组件说明，而是：

1. 组件索引
2. 页面模板
3. 区块规则
4. 组件选型规则
5. 生成后的验收标准

比如后台列表页，不只是 Button、Input、Table 的堆叠。

它还包括页面标题、筛选区、工具栏、表格、分页、批量操作、空状态和异常状态。

AI 需要知道这些区块怎样组成一个页面。

2. 已经有规范文档，但 AI 还是不按规范

还有一些团队已经写了规范文档，甚至整理了 Design MD，但 AI 生成结果依旧发散。

这通常是因为：文档只有描述，没有连接到真实资产。

比如文档里写：

1. 危险操作需要二次确认
2. 主操作使用主按钮

但 AI 并不知道：

1. 二次确认应该用哪个组件，是 Popconfirm 还是 Modal；
2. 哪个 Figma 组件对应主按钮；
3. 代码里应该引入哪个 Button；
4. type 应该怎么写。

所以 Design MD 不能只是说明书。

它还需要继续连接到：

1. Token
2. 组件索引
3. 页面模板
4. 组件映射
5. 验收清单

否则 AI 只是“看过规范”，但没有办法稳定执行规范。

3. 有前端组件库，但 AI 仍然自己写一套

也有团队已经有前端组件库，但 AI 生成页面时还是会：

1. 自造组件
2. 重复写样式
3. 绕开已有组件

这通常不是因为组件库没用，而是 AI 不知道怎么调用。

它需要知道：

1. 组件从哪里 import
2. 什么场景适合用
3. 什么场景不能用
4. 当前页面应该优先使用哪些组件
5. 生成后如何检查有没有自造组件

这种场景下，最重要的是：不要让 AI 一上来就直接生成页面。

一个比较稳定的顺序通常是：

1. 先读 Design MD
2. 再查组件索引
3. 判断页面类型
4. 匹配页面模板
5. 输出组件选型
6. 设计师确认
7. 生成页面
8. 验收并回填规则

只有这样，AI 才不是凭感觉写页面，而是在按照组件库规则生成页面。

4. Figma、文档、代码都有，但三者没有串起来

这是最常见、也最容易混乱的一类。

团队手里有：

1. Figma 组件
2. 规范文档
3. 前端工程

但它们之间没有明确关系。

比如：

1. Figma 里的 Primary Button，对应代码里的哪个组件？
2. Figma 的 Variant，对应代码里的哪个 props？
3. Token 对应哪些组件属性？
4. 页面模板在设计侧和代码侧是否一致？
5. Design MD 里的规则，最后落到哪个真实组件上？

如果这些关系没有整理出来，AI 会看到很多材料，但不知道该以哪个为准。

这时候不是继续堆更多文件，而是先建立连接：

1. 规则和组件的连接
2. Figma 和代码的连接
3. Token 和组件属性的连接
4. 页面模板和业务场景的连接
5. 生成结果和验收清单的连接

五、最后

AI 时代的设计系统，不只是多写几份规范。

它更像是在原有设计系统之上，补一层 AI 执行层。

当这些问题被补齐之后，设计系统才会真正从“给团队协作看的规范”，变成“AI 可以参与执行的工作流”。

 

转载自优设网

 

 

兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。