Figma正在把设计师的工作方法，变成AI可以调用的Skill

一、全文速览图

最近这几个月看 Figma 的更新，我一直有一个感觉。

一个词出现得越来越频繁了。

Skill。

2 月，Figma 已经开始把 Claude Code、Codex 这类编程 Agent 和自己的 Canvas 连起来。

3 月 24 日，Figma 正式宣布，第三方 AI Agent 可以直接进入 Figma Canvas 工作。

5 月 20 日，Figma 自己的 Design Agent 上线。

到了 6 月，Design Agent 又开始加入更多上下文、外部工具和 Skills。

然后 7 月 1 日，Figma 干脆专门发了一篇文章，聊他们内部到底是怎么用 Skill 的。

图 1｜Figma Agent / Skill 时间线：从接入 Canvas 到把工作流沉淀为 Skills。

图 2｜Figma 官方《Got skills?》文章页面（2026 年 7 月 1 日）。来源：Figma Blog

单独看，每一个好像都只是 Figma 又更新了一个 AI 功能。

但如果把它们全部连起来看，我觉得事情就有点不一样了。

Figma 现在搞的，已经越来越不像是在做一个「AI 帮你画图」的功能。

它更像是在搭一整套新的设计工作方式。

而 Skill，可能就是里面非常关键的一块。

Skill 这个词最近很火，但其实没那么玄乎。

你可以把它理解成一套提前保存好的工作方法。

以前我们让 AI 帮忙做设计的时候，经常得写一大串东西。

这个按钮要用现有组件。

颜色别自己乱写，要调用 Variables。

布局按照团队已有的规范。

做完以后再检查一下 Auto Layout。

如果下一次又要做类似任务，你可能还得再跟 AI 解释一遍。

Skill 干的事情，就是把这些反复出现的要求、步骤和判断提前写下来。

以后不用每次重新教。

Figma 自己对 Skill 的定义也很直接，它是一组可重复调用的指令，你教给 Agent 一次，以后就可以直接在聊天里调用。官方甚至总结了一条很简单的判断标准，如果你的团队每次都用差不多的方法做一件事，

那这件事很可能就适合做成 Skill。

所以我自己会这么理解，Prompt 更像是这一次你告诉 AI 怎么做。

Skill 更像是你把一套工作方法教给它，以后遇到类似事情都这么干。

这两个东西听起来只差一点。

但一旦进到真实团队工作流里，区别其实挺大的。

因为 Prompt 更多解决的是一次结果。

Skill 开始碰的是，团队到底怎么工作。

图 3｜Prompt 解决一次结果；Skill 保存可复用的团队工作方法。

图 4｜Figma Skills 体系：画布能力与重复工作流逐步组合。

我顺着这个思路去翻了一下 Figma 现在的官方文档，发现他们其实已经做出一整套东西了。

比如有用来直接操作 Canvas 的 figma-use，也有新建文件、Code Connect、生成设计系统、从代码重新构建设计稿等不同方向的 Skill。Figma 还把 figma-generate-library 和 figma-generate-design 作为完整示例开放出来，给团队继续改造成自己的工作流。

这里面有一个东西，我觉得特别值得设计师看一下。

就是 figma-use。

为什么？

因为以前我们看到很多 AI UI 工具，说一句话，它啪一下给你生成一个页面。

确实很爽。

但生成完以后，经常又会遇到一个很实际的问题。

这东西到底是不是我的设计稿？

很多时候它只是一张图，或者是另外一个环境里的页面。

你真正要拿回来继续设计，该改组件改组件，该重新搭 Auto Layout 还是得重新搭。

figma-use 做的事情不太一样。

它可以让 Agent 直接往 Figma 文件里面创建和修改真实内容。

Frame、Component、Variable、Auto Layout。

甚至可以直接调用你们现有设计系统里的组件和变量。

最后出来的不是一张「看起来像 Figma」的图。

它就是 Figma 里的真实对象，你可以继续选中、修改、检查和往下做。

图 5｜Figma 官方 Code to Canvas 工作流页面。来源：Figma Learn

这个变化我觉得挺有意思。

因为 AI 开始从「帮我生成一个设计结果」，往「进入我的设计环境里帮我工作」走了。

而且再往后看，会更明显。

比如 figma-generate-design。

它可以从已有代码里的页面出发，再结合 Figma 里的真实组件、Variables 和 Styles，把整个页面重新搭回 Figma。

Web 应用甚至还可以参考正在运行页面的截图，去匹配真实的比例和间距。

这解决的是一个非常真实的问题。

很多团队都有过这种情况。

一开始设计稿是一版。

产品做着做着，开发改了一点。

上线以后又改一点。

半年后你再打开 Figma。

……

设计稿已经成考古现场了。

线上是线上。

Figma 是 Figma。

谁也不知道哪个才是真的。

现在 Figma 在试图让代码和 Canvas 之间不再是单行道。

代码里的真实页面可以重新回到 Figma，设计师再继续修改；而 Canvas 中的设计上下文，又可以重新被 Agent 带回代码工作流。Figma 在今年关于 MCP 和 Code to Canvas 的一系列更新里，其实一直都在强化这条路线。

图 6｜代码、Canvas 与设计系统之间开始形成可往返的闭环。

然后还有一个更狠的。

figma-generate-library。

它干的已经不只是做一个页面了。

Figma 官方给出的流程里，它会先看你的代码库和现有 Figma 文件，然后一点点建立 Token、Variable Collection、文字和效果样式、组件页、Variant、Auto Layout，最后还会继续做 Code Connect、命名检查和 QA。

而且这不是一口气蒙头生成到底。

中间还会停下来让人 Review，再继续下一阶段。

看到这里的时候，我自己的感觉是，这个方向已经明显变了。

以前大家比的是，

谁能让 AI 更快给我画一张 UI。

现在 Figma 开始处理的，是更麻烦、也更接近真实团队的事情。

组件怎么用。

Token 怎么同步。

设计系统怎么和代码对应。

代码改了以后设计怎么办。

设计改了以后开发又怎么办。

这些东西其实一点都不性感。

你拿来做一个十秒钟的产品 Demo，也没有 Prompt 一下生成一个炫酷页面那么炸。

但真正在公司里做过产品的人应该会知道。

这些才是每天最磨人的东西。

图 7｜Figma 官方 Design Agent 应用示意：Agent 在画布内调用样式、生成工具并检查设计。来源：Figma Blog

但说真的。

看到这里，我觉得都还不是 Skill 最有意思的地方。

真正让我开始觉得这东西可能会改变设计工作方式的，是 Figma 今年 7 月分享的几个内部案例。

他们有一个 Skill，是模拟 CEO Dylan Field 的反馈方式。

做法大概是把过去他的评论、设计反馈和相关信息交给 Agent，让设计师在真正进入 Review 之前，先用这个 Skill 给自己的设计做一轮压力测试。

他们的 UX Writing 团队也做了自己的 Skill。

专门去检查大小写、标点、语言规范这些重复性的东西。

还有一个 Skill，会故意站在第一次使用产品的新用户角度，重新检查整个体验，看看有没有熟悉产品的设计师自己已经看不见的问题。

图 8｜反馈、UX Writing、新用户视角与团队 Ritual，可逐步沉淀成 Skill。

这个就有意思了。

因为前面我们讲的那些东西，都还是AI 帮你建 Frame、AI 帮你做组件、AI 帮你同步设计系统。

到了这里，它开始碰另外一个东西了。

人的经验。

一个好的设计师工作几年以后，真正值钱的东西其实很少全部写在什么文档里。

更多时候是一堆藏在脑子里的判断。

这个页面信息是不是太满了。

这个 CTA 看着就是不对。

这个组件理论上能这么用，但我们产品里最好别这么用。

这个流程产品经理觉得没问题，但新用户第一次进来八成会懵。

以前这些东西，只能靠一个老设计师坐在你旁边，一轮轮 Review 慢慢传给新人。

现在我就在想。

如果一个高级设计师十年的经验，可以慢慢拆成一套套判断规则、检查流程和案例。

那里面到底有多少东西，是可以被沉淀成 Skill 的？

当然，我这里说的是一个方向，不是说今天把某个大佬的文章全部丢进去，就复制出了第二个大佬。

没这么简单。

Skill 自己也不是一个确定性的程序。

Figma 官方特别提醒过，即使使用同一个 Skill，由于底层模型本身具有非确定性，每次得到的结果也不一定完全一样。

图 9｜Figma 官方说明：Skill 提高一致性，但模型仍具有非确定性。来源：Figma Learn

但它至少打开了一扇门。

团队的经验，开始可以被 Agent 调用。

这可能比生成一张图重要得多。

回过头看过去两三年的 AI 设计工具，会发现大家其实一直在卷同一件事情。

一句话出 UI。

一句话出网站。

一句话出代码。

模型越来越强以后，第一张图确实越来越漂亮。

但团队真正开始使用以后，一堆老问题还是会回来。

这是我们的组件吗？

符合 Design System 吗？

品牌字体怎么没用对？

开发手里的版本跟设计稿又不一样了怎么办？

AI 做的页面挺好看，但我们产品压根不是这个视觉语言怎么办？

所以现在再看 Figma 这条 Agent + MCP + Skill 的路线，我觉得它真正想回答的问题已经不是AI 能不能设计。

而是，AI 能不能按照我们的方式设计。

这两个问题差非常远。

前一个比的是模型能力。

后一个开始涉及设计系统、上下文、流程、团队经验和判断标准。

Figma 今年 6 月介绍 Design Agent 时也一直在强调类似的事情，一个 Agent 是否真的理解你的工作方式，关键在于它能不能获得项目、品牌和团队工作方法相关的上下文，而 Skill 则进一步把一些反复出现的思考方式和工作流保存下来、共享出去。

所以我有时候觉得，未来 AI 设计真正卷起来以后，大家比的可能不会只是哪家模型第一张图画得最好。

而是哪一个 Agent 最懂你，懂你公司的 Design System，懂你的品牌，懂你的产品，懂这个团队什么时候用什么组件，懂设计 Review 的时候重点看什么，甚至懂某一个Leader 每次最在意的那几个问题。

到那时候，设计师的工作方式可能也会发生一个挺有意思的变化。

以前我们积累作品集，后来积累组件库，再后来开始认真搭 Design System。

AI 起来以后，很多人又开始攒自己的 Prompt。

再往后呢？

可能真的会多一个东西。

Skill Library。

图 10｜设计师资产从作品集、组件库与 Design System，走向 Prompt 库与 Skill 库。

比如一个 Skill 专门检查设计稿、一个专门检查设计系统有没有跑偏，甚至你自己最擅长的某一种设计方法，也可以慢慢被拆成一套 Agent 能理解的工作流程。

这些今天都还处在非常早期的阶段。

很多东西也肯定没有想象中那么丝滑。

但我觉得这个方向已经值得设计师提前关注了。

因为回到开头那个问题。

为什么 Figma 最近突然这么频繁地讲 Skill？

我现在的理解是，不是因为 Skill 这三个字有多新。

而是当 Agent 真正开始进入生产环境以后，光有一个聪明模型已经不够用了。

你还得告诉它，你的团队是谁、你们过去做过什么决定、你们认为什么样的设计才算好、遇到一件事情的时候，你们习惯按照什么步骤解决。

以前这些东西，很多都散落在文档里、组件库里、设计师脑子里。

现在，它们开始有机会变成 Agent 可以直接使用的东西。

这一步如果真的走下去，我觉得还是挺有意思的。

以前设计师把经验留在脑子里。

后来，我们把规范装进了 Design System。

再下一步，也许就是把自己的工作方法，装进 Agent 里。

而那个装进去的东西，很可能就叫 Skill。

文章提到的可用Skill：

官方仓库：https://github.com/figma/mcp-server-guide

下载之后，让 Claude Code、Codex 等 Agent 自己解压并放到对应的 Skills 目录里即可。