UI设计案例实测！教你用Skill跑通AI+Figma工作流！

一、全文速览图

最近，我做了一次用 AI 生成 Figma 页面的小实验。

最初的目标很直接：把已有的移动端设计页面交给 AI，再提供一份新页面的产品原型，让 AI 参照现有页面的视觉风格，生成一张新的设计稿。

听起来并不复杂，但真正开始以后，我才发现，“让 AI 看几个页面，然后照着画一个新页面” 和 “让 AI 理解一套设计体系，并持续生成可用页面”，完全是两件事。

二、第一次尝试：只把现有页面喂给 AI

一开始，我采用的是最直接的方式：

把现有 Figma 页面提供给 AI，再告诉它新页面有哪些字段，让它参照现有页面生成设计稿。

先看一下结果，左图是我给 AI 的 Figma 文件，右边是它根据原型中新字段生成的 Figma 文件。

结果并不理想，首先是生成速度非常慢，一个页面用了 50 多分钟；

AI 每生成一个区域，都需要重新理解页面结构、间距、字体、颜色和组件关系。按钮应该放在哪里、表单项应该用什么样式、页面底部操作区应该怎么排列，这些信息都需要在生成过程中反复推断。

其次，生成结果不稳定。

虽然最终页面看起来 “有点像” 原来的设计，但组件尺寸、字段排列、间距规则和状态样式经常出现偏差。有时同一个按钮，在不同页面里会被生成成不同高度；有时原本应该复用的状态标签，会被重新画成一个普通文本框；还有一些页面看似完整，实际上并没有使用设计系统里的真实组件。

这种方式最大的问题是：AI 每次都在重新学习同一套设计语言。

它看到的是页面的结果，却没有真正掌握页面背后的规则。

三、第二个误区：组件必须先有完美的命名规范

第一次尝试失败后，我产生了另一个判断：

是不是必须先把 Figma 里的所有组件整理好，统一命名，并配置完整的 Variant，AI 才能根据原型里的新字段生成页面？

这个判断听起来很合理。

如果组件能够被清楚地命名为 Button、Input、Tag、Radio、Upload，AI 自然更容易理解它们的用途。

但现实中的设计文件通常是这样的，有些组件叫 “按钮”，有些叫 “切换”，还有些直接叫 “Frame 6”“Frame 7”。同一个组件集下面可能有很多 Variant，命名中还混合着中文、数字和设计过程留下的临时信息。

如果必须等到所有组件完成标准化以后才能开始，那么 AI 生成设计这件事，很可能永远停留在准备阶段。

四、转折点：不要求组件先完美，而是先理解现有页面

这次尝试让我意识到：

AI 并不一定要求 Figma 组件拥有完美的英文命名。真正重要的是，能不能建立 “业务语义” 和 “真实组件” 之间的映射。

例如：

1. PrimaryButton、SecondaryButton 和 TertiaryButton，都可以映射到 Figma 中同一个 “按钮” 组件集，再通过 Variant 属性区分按钮类型。
2. CategoryTag 可以映射到 “状态标签 - 副文本” 组件集。
3. TextInputRow 可以映射到名称并不直观的 “Frame 6”。
4. TextArea 可以映射到 “Frame 7”。
5. ImageUpload 可以映射到 “上传图片”。
6. ProcessNode 可以映射到 “审批流节点”。

这意味着，组件原来的名字不一定准确，只要我们能够从现有页面中确认它的真实用途，就可以在 AI 使用的规则中，为它补上一层语义。

设计文件里的组件不需要先被全部重命名。

我们可以先扫描真实组件，识别它们在已有页面中的使用方式，再建立一份语义化的组件映射表。

五、不是继续 “喂页面”，而是把页面整理成 Skill

具体操作如下：

1️⃣ 放到 Figma 中的几个表单页，另外还放了几个列表页和详情页，都是重复度比较高的页面，并且放了命名不规范的组件，方便对应关系的链接，不用 AI 自己再去补充变体。

2️⃣在这些页面和不规范的组件下 AI 生成了 Skill，并安装。

3️⃣验证环节，输入原型中的字段，左图是上边其中一个表单页，右图是 AI 生成的，组件用的是我给的，间距很合理，Frame 的布局跟图层命名很规范。

这次真正跑通流程的关键，是没有继续让 AI 每次临场参考页面，而是把现有页面里隐藏的设计规则整理成了一个可重复调用的 Skill。

这个 Skill 被命名为 $xiaochengxu-mobile-ui。

它并不是一张页面模板，也不是一段固定的提示词，而是一套让 AI 理解和执行现有设计语言的规则。

其中主要包含四类信息。

1. 真实组件映射

首先扫描 Figma 文件中的真实组件和组件集，记录它们的 Component Key、Component Set Key、节点 ID 和 Variant 属性。

这里有一个很容易踩的坑：

组件集的 Key 和某一个具体 Variant 的 Key 不是一回事。

例如，PrimaryButton、SecondaryButton 和 TertiaryButton 都属于同一个 “按钮” 组件集。AI 应该先导入组件集，再通过 Variant 属性选择具体样式，而不是把某一个 Variant 当成整个按钮组件。

只有把这层关系理清楚，AI 生成的页面才能真正复用原有组件。

2. 字段语义映射

产品原型通常提供的是字段，而不是设计组件。

例如：

1. 合同名称是单行文本输入；
2. 合同说明是多行文本输入；
3. 合同类型可能是标签或选择器；
4. 是否续签可能是单选项；
5. 合同附件对应文件上传；
6. 审批进度对应流程节点。

Skill 的作用之一，就是先判断字段的业务语义，再选择合适的设计组件。

这样，AI 面对一个以前从未出现过的新字段时，不需要在现有页面中寻找一模一样的内容，只需要判断它属于哪一种字段类型。

这才是从 “复制旧页面” 走向 “生成新页面” 的关键。

3. 页面结构规则

除了组件，现有页面中还包含大量没有被明确写出来的布局规律：

1. 页面宽度是多少；
2. 卡片之间使用多大的间距；
3. 表单项如何分组；
4. 主操作按钮放在什么位置；
5. 移动端应该使用卡片列表，还是桌面表格；
6. 缺失数据应该显示 “-” 还是 “无”；
7. 详情页和编辑页应该采用什么结构。

这些规则原本分散在不同页面里。

把它们整理进 Skill 后，AI 就不需要每次重新猜测，而是可以按照固定的页面模式生成列表页、表单页、详情页和流程页。

4. 生成过程中的保护规则

为了避免 AI 在组件缺失时自由发挥，Skill 还加入了一些限制：

找不到真实 Component Key 时，要明确报告缺失，不能随便猜一个组件；组件集必须使用 Component Set Key，不能误用某个 Variant Key；没有原有设计依据时，不能自行创造桌面分页、空状态插画或新的视觉规范。

这些限制看起来保守，却能显著提升生成结果的稳定性。

AI 设计真正需要的，并不是更强的 “自由发挥”，而是更清晰的设计边界。

六、字体也暴露了本地设计与远程 AI 的差异

测试过程中还遇到了一个很典型的问题：字体。

原有页面使用的是苹方，但 Figma MCP 的远程执行环境无法加载本机的 PingFang SC。

设计师在自己的 Mac 和 Figma 桌面端里可以正常看到苹方，不代表远程 AI 环境也能够访问这套字体。

Figma 支持将字体上传到账号，供 MCP 使用，但这个功能需要付费方案，并且字体文件本身还涉及授权问题。

因此，最终在 Skill 中增加了一条明确规则：

现有 Figma 页面和未编辑的文字保持不变；以后由 AI 新建或修改的文字统一使用 Noto Sans SC，并按照 Regular、Medium、SemiBold 对应原设计字重。

这样既不破坏已有页面，也避免每次生成时因为字体加载失败而中断。

七、最终跑通的，不是 “AI 照着图片画图”

完成 Skill 后，整个流程发生了变化。

之前的过程是：

产品原型 → AI 查看几个参考页面 → 临场模仿 → 生成一张相似但不稳定的页面。

现在的过程变成了：

产品原型 → 识别字段语义 → 匹配真实 Figma 组件 → 应用页面结构规则 → 生成可编辑的设计页面。

这两种方式表面上都是 “根据原型生成设计”，底层逻辑却完全不同。

前一种方式更像视觉模仿。

后一种方式则是在执行一套被明确描述的设计系统。

八、我最大的认知变化

在这次尝试之前，我一直以为，要从原型直接生成设计，前提是设计团队先把组件库治理到非常规范：

所有组件都要拥有标准名称，所有 Variant 都要整理完整，所有页面都要符合统一模板。

现在我的看法发生了变化。

规范化当然很重要，但它不是启动 AI 设计流程的唯一前提。

即使现有 Figma 文件并不完美，只要里面已经存在足够多的真实业务页面，就可以先从这些页面中反向提取组件关系、字段语义、布局模式和设计边界，再把它们整理成一个专用 Skill。

换句话说，现有页面本身就是一套尚未被书面化的设计系统。

Skill 所做的事情，就是把这套隐性的设计经验，转化成 AI 能够理解和重复执行的规则。

九、这条流程真正有价值的地方

这次实验并不意味着 AI 可以完全替代设计师。

它更适合解决另一类问题：

当产品需要快速增加一个字段结构相似、设计语言稳定的新页面时，不再需要从零开始搭建，也不需要让 AI 每次重新理解整个设计文件。

设计师负责定义和校准规则，AI 负责按照规则完成大量重复性的页面组装。

当组件映射和页面模式逐渐完善以后，从原型到设计稿的过程就可以变成一条稳定的生产流程：

产品描述字段，Skill 理解字段，AI 选择真实组件，Figma 输出可编辑页面，设计师完成最终审核。

这次尝试让我确认了一件事：

从原型直接生成设计是可以跑通的。

真正的突破口，不是继续给 AI 喂更多页面，也不是等待组件库达到绝对完美，而是把已有页面中隐含的设计规则提取出来，做成一个可以持续迭代的 Skill。

当 AI 不再只是 “看页面”，而是开始 “理解并执行设计规则”，从原型到设计的流程才真正成立。