Figma AI 设计实战：用 3 个 Make 自定义技能锁定设计系统

Figma AI 设计为什么会交付“不像品牌”的成品？

送审版本几乎全都对了，而这恰恰是最危险的情况。一个早在品牌重塑时就将圆角锁定为 8px 的设计系统，按钮却用了 12px。主强调色渲染得近似 #18C5DA，肉眼看与客户的 #06B6D4 相差无几，但粘贴到 Figma 取色器里，偏差立刻暴露。做到第三个画面时，正文又用了 18px，而系统规定的是 16px。

问题不在我当天写的提示词，而在六条之前写的那一条。Figma Make 会在同一次会话里保留上下文，但设计系统规则离最初输入的位置越远，约束力就越容易衰减。等到调整第三版首屏方案时，模型已经开始自行补出“看起来合理”的 token 值。2026 年 5 月的发布说明直接点出了自定义技能要解决的缺口：把一组指令封装成可随时调用的能力，无需反复粘贴，也能嵌入每一条提示词。(Figma 2026 年 5 月发布说明汇总)

搭好下面这套技能组合后，我让 Make 按同一份 brief 又跑了一遍。按钮圆角：8px。强调色：#06B6D4。正文：16px。技能没有让 Make 变得更聪明，只是让它再也忘不掉规则。

先把规则说清：这套客户设计系统究竟要求什么？

本文使用的是一套真实的客户设计系统，以下 token 已做脱敏处理：

• 颜色：背景 #0A0E14，前景 #E6EDF3，唯一强调色 #06B6D4。没有第二强调色，不使用渐变。
• 间距：以 8px 为基准。只允许 8 / 16 / 24 / 40，不取中间值，也不超出范围。
• 字号阶梯：14 / 16 / 20 / 32 / 48。正文为 16，不用 18。
• 圆角：所有交互表面均为 8px，卡片为 0，不设例外。
• 按钮：一个组件、三种状态——默认、悬停、禁用。默认状态填充强调色；禁用状态使用 30% 不透明度的前景色。

一句笼统的“遵循我们的品牌规范”，会在上述每一项上失效，因为形容词留下了太大的发挥空间。“冷静、极简、单一强调色”可以形容上千套系统。模型不需要情绪板，它需要一张规则表。真正的目标，是让这个客户的每一次 Make 构建都按表校验，而不必由我在每个会话里重新输入。

Figma Make 自定义技能：3 个可直接使用的 .md 文件

Figma Make 的自定义技能，是遵循 Agent Skills 规范的单个 Markdown 文件。frontmatter 中的 name 会成为斜杠命令。技能按账号安装，在你拥有的所有 Make 文件中持续可用。还有一点很重要：文件必须自包含，不能使用 scripts/、references/ 或 assets/ 目录。模型要用到的一切，都必须直接写在指令里。(Figma Make 自定义技能帮助文档)

我过去反复输入的内容，有 90% 可以由下面三个技能覆盖。

/follow-ds-guidelines

把 token 表原样写进指令，不做解读，也不用形容词。

---
name: follow-ds-guidelines
description: Enforce the client design system on every generated frame.
---

You are building inside a locked design system. Use these exact values.
Do not improvise alternates, do not interpolate, do not soften.

## Color
- background: #0A0E14
- foreground: #E6EDF3
- accent: #06B6D4 (single accent, no secondary)

## Spacing (8px base)
- allowed: 8, 16, 24, 40
- forbidden: any value not in the allowed list

## Type ramp
- 14 / 16 / 20 / 32 / 48
- body is 16. never 18.

## Radius
- interactive surfaces: 8
- cards: 0

## Button (one component, three states)
- default: fill #06B6D4, foreground #0A0E14
- hover: fill #06B6D4 at 90% opacity
- disabled: foreground #E6EDF3 at 30% opacity

If a request would produce a value outside this table, return the closest
allowed value and flag the substitution in a comment.

/design-crit

这是一个审查技能。Make 会按照 token 表检查当前画面，并返回通过/不通过清单，用十六进制色值和像素值明确标出问题。

---
name: design-crit
description: Audit the current frame against the client design system.
---

Walk the current frame top to bottom. For every visual element, check:
- color hex against the allowed palette
- spacing values against the 8 / 16 / 24 / 40 scale
- type size against the 14 / 16 / 20 / 32 / 48 ramp
- radius against 8 (interactive) or 0 (cards)

Return a table:
| Element | Property | Found | Expected | Pass/Fail |

End with a one-line verdict: PASS if all rows pass, FAIL otherwise.
Do not auto-fix. The human decides which deviations are intentional.

/insert-sample-data

样例数据技能会填入客户批准的占位文案，避免 lorem ipsum 或模型虚构的公司名称混进评审版本，之后再被法务拦下。(2026 年 5 月发布说明汇总)

---
name: insert-sample-data
description: Replace placeholder text with approved sample data.
---

When asked for sample content, use only this set:

## Names
Sarah Chen, Marcus Okafor, Priya Raman, Diego Alvarez

## Company names (fictional, cleared)
Northwind Labs, Apex & Vine, Halcyon Group, Stratus Co

## Numbers
Use round numbers in product UI: 1,240 / 3,500 / 12,800.
Avoid revenue-shaped numbers unless asked.

Never use lorem ipsum. Never invent a real-sounding brand name not on this list.

三个文件，分别替代一类我以前总要重复粘贴的内容。

接入 Notion 连接器，让技能读取实时设计系统

如果设计系统已经冻结，/follow-ds-guidelines 里的静态 token 很好用。但客户只要更新一次 token——这迟早会发生——内嵌表格就会过期。解决办法是把技能与连接器配对，让 Make 直接拉取实时数据源。(Figma Make 连接器帮助文档)

这个客户的文件采用了这样的结构：设计系统集中放在一个 Notion 页面中，标题与技能一致，分别是 Color、Spacing、Type ramp、Radius、Button。我会在同一条提示词中同时调用技能和连接器。

Use the /follow-ds-guidelines skill, but pull the current token values
from @Notion "Halcyon – Design System v3" and override the inline table
where they differ. Then build the pricing section per the attached spec.

同一条提示词也能以相同方式从 Drive 拉取 PRD，例如 @Drive "Halcyon pricing PRD"；Make 会一次性组合设计系统与产品规范的上下文。(2026 年 5 月发布说明汇总)

我会按客户的实际情况取舍：一个季度都没变过的系统，把 token 内嵌进去；仍在频繁调整的系统，则由连接器提供。两种方式使用的是同一份技能 .md，变化的只有提示词。这是有意为之：我不想为每个客户复制出一堆技能，而是希望一个技能就能接受外部规则覆盖。

顺带说明，Figma MCP server 的 /prototype-to-figma 技能属于另一套入口。它为代码到画布的往返工作预装，用户无需自行编写。Make 自定义技能刚好相反：由你编写，存在 Make 内部，也不会触及 MCP 层。

实际踩坑：不确定性与团队共享成本

公告没有展开的地方有三个。

支持的模型比文档给人的印象更少。 自定义技能目前只支持 Figma Make 默认模型和 Claude Opus 4.7。如果团队已在 Make 中统一使用其他模型，技能不会生效，也没有醒目的报错，只会悄悄失去约束力。(Figma Make 自定义技能帮助文档) 团队构建出了问题时，我最先检查这一项，而不是直接排查“为什么圆角又错了”。

结果只是“往往”一致，并非每次完全相同。 这是 Figma 官方文档自己的说法。模型具有非确定性，所以面对复杂画面，/design-crit 偶尔会漏掉偏差，也可能把有意保留的例外标成问题。(Figma Make 自定义技能帮助文档) 我把审查技能当作快速初检，而不是最终签字。

真正影响执行的是共享成本。 目前自定义技能按账号管理。要把整套技能交给同事，必须导出 .md 文件，再由对方上传到自己的账号，尚不支持组织级发布。(Figma Make 自定义技能帮助文档) 对同时维护多个客户系统的工作室来说，这种摩擦不可忽视：每来一位新成员，所有在用技能都要手动安装；每次技能更新，也都要重新导出。解决方式很朴素，但确实有效：把 .md 文件纳入客户代码仓库的版本管理——我们的文件与设计 token 放在同一个 monorepo 里——并为发布打 tag。这样，上传时依据的是唯一可信源，而不是一条 Slack 消息。

如果你是设计师，正在评估这类按席位增加运营成本的平台，我也从同样的工作室运营视角分析过 Webflow 高级套餐的定价账：工具按表面功能定价，真正由你承担的却是底层集成摩擦。

最后的原则：什么交给技能，什么必须由人判断？

在 DVNC.studio 实际用了几周后，我定下了一条规则：凡是重复输入超过两次的内容，就应该做成技能。token 表、审查清单、样例数据约定、无障碍标注模板，这些都不需要创意，却一直在消耗时间。

必须留给人的，是判断。/design-crit 能指出某个数值不符合系统，却无法判断它究竟是错误，还是某个一次性营销页面有意采用的例外。技能擅长发现“这里的圆角是 12，预期为 8”，却不理解“这里之所以用 12，是因为活动创意需要更柔和的卡片，而且我们周二已经达成一致”。后者才是真正需要专业判断的工作。

下周二就可以这样开始：选出最常用的一套客户系统，打开一个 .md 文件，像我上面处理 Halcyon 那样粘贴 token 表，保存为 follow-ds-guidelines.md，上传为自定义技能，并用它跑一次真实构建。然后对输出调用 /design-crit，再手动与 token 表逐项比对。如果技能抓住了原本需要你发现的问题，它就替你省下了每位客户每周 1 小时的反复补写提示词时间。如果连明显问题都漏掉，应该修改的是 .md，不是提示词历史。