Figma Config 一次更新五项，设计和代码双向打通

 

昨天，Figma 在印度班加罗尔又举办了一场 Config 大会，推出了一系列 AI 功能，设计和实现，同时进行。

CEO Dylan Field 在主题演讲上发布了一批新功能，这批功能的主题是Build by design，正如字面意思，把代码、设计规范、需求文档和网站内容接进了 Figma，对应推出了代码图层（code layers）、设计指南（Guidelines）、Code sources、Specs，以及接入 Figma Make 的 Payload，同时更新了 Figma agent 和 MCP。

Dylan Field 在 Config India 主舞台

Dylan 开场先讲了 Figma 一直以来的一个判断，Design is the differentiator，设计是拉开差距的地方。agent 会写代码之后，谁都能做产品，而且做得很快，产品之间的差别最后要靠设计拉开，这也是 Figma 创立时的出发点。

与此同时，做产品的方式也变了。过去的流程是一条直线，先在 Figma 里画设计稿、做原型，确定之后再交给开发写代码。

现在 agent 几分钟就能把一个想法写成代码，越来越多的团队在想法还不成熟的时候，就先让 agent 做出一个能运行的版本，对着这个版本判断哪里不对、自己真正想要的是什么。Dylan 把这个阶段叫做 building to think，也就是为了把想法想清楚而做。

想清楚之后，要做出能上线的产品，就要讲究精确和细节，这个阶段是 building to ship，为了上线而做。

协作设计和用代码搭建同在画布

这次，要让这两个阶段都能在 Figma 里完成，Dylan 把这个目标叫做 full stack creative canvas，一张从设计到代码都能完成的创作画布。很多设计师向 Figma 反馈，在终端和 IDE 里用 AI 写代码，感觉不像在自己家里，所以 Figma 想给设计师、团队和 agent 做一个"家"，设计稿、代码和 agent 都放在同一张画布上。

画布上的代码原型

第一个更新是代码图层。Figma 团队内部已经用了几个月，这次进入公开测试，从发布当天开始，接下来几周会陆续开放给所有用户。有了代码图层，设计师可以直接在 Figma 的画布上用代码做原型。做出来的原型可以运行，能点击、能操作，和团队的设计稿放在同一张画布上，同事也能直接在原型上留评论。

画布上可以点击操作的代码图层

这几年很多设计师都在自己一个人用 vibe coding 做原型，协作的方式是把原型链接发到 Slack 里，或者录一段 17 分钟的屏幕录像发给同事看。同事能看到最后做出来的结果，却看不到这个结果是怎么一步步做出来的。

用了代码图层之后，做好的原型会和做的过程中留下的各种尝试一起留在画布上，同事能看到这个原型是怎么一步步改出来的。团队成员看到哪个想法有启发，可以直接复制过来改一改，朝新的方向继续做下去。

在画布上新建代码图层，一共有四种方式。第一种是选中设计稿，让 Figma agent 把它转成代码图层。第二种是在自己常用的编码 agent 里，通过 Figma 的 MCP，把做好的原型创建成一个代码图层。第三种是把 GitHub 上的仓库克隆成代码图层，目前只支持 GitHub Cloud，GitHub Enterprise Server 和其他代码托管系统还在接入。

第四种是 Figma Chrome 扩展新加的 Capture Code，可以把一个网页抓取下来，作为代码图层粘贴到画布上。

Capture Code 把网页抓成代码图层

用 Capture Code 抓取下来的网页，用的是这个网站真实的 CSS 文件，所以页面上的 CSS 动画和鼠标悬停效果都能正常运行。实际工作中，对于已经上线的产品、却拿不到源代码的时候，或者只想拿线上版本当起点快速改一改的时候，可以用这种方式。

从 GitHub 克隆来的代码图层，在新的代码面板里能看到它克隆自哪个分支、现在在哪个分支上。设计师可以从仓库拉取最新的改动，也可以把自己的改动推送上去让同事看到，改完之后还能直接创建 PR。

代码面板里的分支和 PR 操作

拿到一套设计稿的时候，经常分不清里面哪些是新做的、哪些只是为了看起来真实放进去的填充内容。Extract designs 可以把代码图层当前的状态或者某几个元素提取出来，也可以把一整条操作流程录下来，把里面的关键页面都转成可以编辑的设计图层。这样文案设计师可以直接在设计图层上修改文案，其他人也更容易参与进来给反馈。

Extract designs 提取关键页面

比如一个买卖物品的应用，下单之后有一步是"正在寻找送货员"，原来这一步的页面比较平淡。可以让 agent 用 Figma Motion 给这一步的几个设计图层做动画，比如扫描周边寻找送货员、货车变成纸箱，还有一个带彩色纸屑的成功状态。

货车变纸箱和成功状态动画

因为这些设计图层是从代码图层里提取出来的，下方会出现一条工具栏，提示设计已经修改过。点击"更新代码图层"，设计稿上的改动连同 Motion 里定义的动画，都会同步回代码图层。

点击更新代码图层

每个代码图层都有一个全屏的代码编辑器，可以直接查看和修改代码文件，在 review 标签里查看每次提交改了哪些代码，还有一个终端，可以直接操作运行代码的沙盒环境。

全屏模式下还能同时开好几个和 agent 的对话。比如在处理动画的时候，发现手机的刘海挡住了应用的 logo，就可以新开一个对话，让 agent 加上 iOS 的状态栏，不用等前一个任务做完。

新开一个对话让 agent 改状态栏

代码图层可以像普通图层一样复制，几个不同的方案并排放在画布上比较，团队成员可以在每个方案上留评论。

三个代码图层在画布上并排比较

两个团队各自改了不同的地方时，可以把两个代码图层合并起来。比如一个代码图层里新加了一个按钮，引导用户填写送货地址，另一个代码图层里做好了送货动画。同时选中这两个代码图层，用语音告诉 agent 把按钮加到带动画的那个代码图层里，agent 就会生成一个同时包含两边改动的新代码图层。

选中两个代码图层让 agent 合并

这样的代码图层适合发给更多相关的人看。选中这个代码图层，像普通的 Figma 原型一样点击右上角的演示按钮，再点分享原型，拿到的链接只会打开这一个原型，文件里的其他内容仍然是私有的。

只分享这一个原型

接下来几个月，代码图层还会支持更复杂的代码库，非常期待！

给 agent 写指南

代码图层里的原型大多是 agent 生成的。那设计师看到这些原型，肯定最关心的还是一个那些很细节、很规范的问题，比如原型里的圆角，用的是不是自己设计系统里的变量。所以 Figma 可以连接真实代码库了。

第一步是把代码库和 Figma 的设计库连起来。在组件库文件里打开资源面板，这里可以连接 GitHub 仓库，也可以连接公开或私有的 npm 包。

授权 GitHub 账号，选中对应的代码仓库和 main 分支，保存之后，用户在 prompt 里附上这个设计库文件时，agent 就能把代码里的组件导入到它创建的代码图层里。这个功能叫 Code sources，目前在小范围内测，很快会进入公开测试。

给设计库连接 GitHub 仓库

只有代码还不够。团队对设计系统该怎么用，有一些具体的规则，可以写成 Markdown 文件，作为设计指南上传到设计库里，用来引导 agent 按团队的方式使用设计系统。

设计指南这次已经开放公开测试。上传之后，只要在 prompt 里附上这个设计库，agent 生成界面时就会用上库里的代码组件，也会按照这些规则来做。

给设计库上传 Markdown 设计指南

有没有设计库，生成出来的界面差别很明显。比如同样让 agent 做一个列表页，用来浏览本地二手市场的商品，带筛选和排序，左边生成时没有附上设计库，右边附上了，右边的界面明显更接近这个品牌自己的设计风格。打开右边代码图层的对话记录，可以看到 agent 在导入设计库，调用代码仓库里的组件。

左无设计库，右附设计库

生成结束后，切到轮廓模式，界面上用紫色标出来的部分，都是 agent 用上的 Figma 组件。

Cmd+Y 轮廓模式标出用到的组件

很多团队的设计系统不止一个设计库，Figma 准备做一个统一的地方，把多个设计库和代码源放在一起管理。其中 System map 是一张依赖关系图，展示设计系统的结构，各个来源之间怎么连接、各自包含哪些内容。

System map 和检查结果总览

System check 会扫描所有设计库里的 token、样式、变量和组件，找出需要改进的地方。比如检查结果里会列出写死数值的文字样式、缺少描述的组件，还有可能缺失的交互状态。目前的检查规则还比较少，Figma 计划之后可以让团队自己定义规则，再往后，检查出问题之后可以在设计文件里一键把写死的数值替换回变量。

System check 列出待改进的样式

用 Specs 写上下文

Markdown 在 2004 年由 John Gruber 和 Aaron Swartz 发明，本来是用来给网页写带格式的文字。最近几年 Markdown 随着 AI 的发展开始流行起来，因为人和 agent 都很容易读写这种格式，Markdown 慢慢成了人和 agent 之间传递上下文的通用格式。

很多上下文用完就丢了，比如和 agent 的聊天记录，但有一部分会成为后面所有工作的依据，需要别人一起参与、反复修改。这时候 Markdown 的限制就出现了，一个文件和哪些文件有关联、来自哪个项目，文件本身看不出来，里面的链接也只是一串人看不懂的地址。Specs 是 Figma 为这类上下文做的一个新的存放位置。

一份带表格、流程图和代码的 spec

把一个 Markdown 文件从桌面拖到画布上，这个文件就成了一份 spec。spec 可以放在画布上，也是一种可以单独存在的新文件类型。spec 支持多人协作，常见的 Markdown 格式都能用，待办列表、提示框、从 FigJam 复制的表格、代码块都有，章节可以折叠、也可以调整顺序。

Markdown 文件拖上画布变成 spec

新建 spec 还可以按 D 键，或者点 Figma Design 和 FigJam 工具栏上的 Specs 图标，也可以让 agent 通过 MCP 把外部的数据整理成一份 spec。

spec 里还能嵌入任何 Figma 文件，不管是 Make 做的应用、一套幻灯片还是设计稿，嵌进来都能实时预览和操作。

在 spec 里嵌入 Figma 文件

spec 里的内容也可以来自 Figma 以外的工具。比如一个买卖物品的应用要上线送货功能，产品团队写好的 PRD 放在画布上，里面还有一个没解决的问题，送货功能先在哪个城市上线。

Figma 团队内部平时用数据分析工具 Hex 看使用数据，在 Figma agent 里加上 Hex 连接器，就可以让 agent 找出应用使用量最高的城市、写成一份 spec，同时把画布上展示送货地图的代码图层，换成真实的数据和地点。

agent 生成的 spec 里按城市列出了使用量和交易量，还有不同品类商品的表现，结果是班加罗尔的使用量最高。

agent 用 Hex 数据写出城市分析 spec

代码图层里的代码都是原型代码，原型代码不等于生产代码。原型要真正上线，工程师还要考虑数据模型、能不能扩展、新角色的生命周期，以及上线和监控的方案。这些内容可以写在工程团队的技术 spec 里，也可以从一次 FigJam 工程评审里拿来一张图，比如卖家、买家和送货员之间送货流程的设计图，直接拖进 spec，设计图就会自动适应 spec 的宽度。

把 FigJam 流程图拖进 spec

画布上的任何内容都能放进 spec，流程图、设计 frame，甚至设计系统组件的实例都可以。

比如要把送货功能的设计稿交给工程师实现，画布上可能已经有三份材料。一是设计团队从代码图层里提取出来、工程师加了标注的最终设计稿。二是一个展示送货地图的代码图层，设计师在里面仔细调好了交互细节，比如地图缩放时哪些地点会合并成一个点，新的地点出现时用什么动画、动画的快慢节奏是什么样的。

三是设计系统团队为新组件写的技术 spec，说明什么时候用新组件、什么时候用旧组件。

选中所有这些内容，让 agent 用提前配置好的一个 skill，就能生成一份写给 agent 看的实施计划。交给 agent 实现之前，可以先把这份计划放大检查一遍，发现不对的地方就留评论。拿不准的地方，可以提醒熟悉这块的工程师来看，对方能直接进到 spec 里实时修改。

用 skill 生成实施计划

评论也可以交给 agent 来读，agent 会在同一个评论串里给出修改建议。评论串的记录所有人都能看到，人和 agent 可以在同一个地方一起讨论，spec 的不同部分也可以同时开好几个讨论。

agent 在评论串里回复并修改 spec

最后一步是复制这份 spec 的链接，发给 Codex。以前用编码 agent 实现功能，要在 prompt 里贴一堆 Figma 文件的链接，现在只要一个链接。这个链接背后，是前面整理好的全部材料，包括 agent 生成的实施计划、工程师加了标注的最终设计稿、调好交互细节的送货地图代码图层、新组件的技术 spec，还有从 FigJam 拖进来的送货流程图。

Codex 通过 Figma 的 MCP，读到 spec 本身和 spec 里引用的这些设计稿、代码图层。设计稿里用到的组件，Codex 会通过 Code Connect 找到代码库里对应的设计系统组件来实现，设计师在代码图层里调好的动画时长、间距和动效参数，Codex 也一起读到。

复制 spec 链接，切到 Codex

Specs 从发布当天开始在网页端、桌面端和手机上陆续开放公开测试，接下来几周所有人都能用上。

Make 自带后端

一个功能的代码上线之后，还不等于真正推出了。比如送货功能上线之后，首页要介绍送货，要招募送货员，首发城市的落地页要更新、要做本地化，还需要一个后台来管理这些内容，这类工作通常要用到 CMS，也就是内容管理系统。

Payload 是一个开源的 CMS，最早是创始人 James Mikrut 业余时间做的项目，现在是 npm 上增长最快的开源 CMS。Figma 去年收购了 Payload，并接入了 Figma Make。

在 Make 里写 prompt 时，如果 agent 判断这个应用需要后端，就会把 Payload 直接搭建到应用里，配好数据库、内容和素材管理、用户登录和管理后台。

Make 里用 Payload 管理网站内容

比如市场团队可以把前面写好的几份 spec 交给 Make，生成一套推广送货功能的新页面，首页开始介绍送货，还多了一个管理后台的标签页。点击发布按钮，整个带数据库和文件存储的全栈应用就上线了，全部运行在 Figma 上。

Make 里点击发布，网站上线

网站上线之后，后续的维护和管理也不用另外找工具，在 Make 生成的这个网站自带的 Payload 后台里就能完成。比如首发城市班加罗尔的落地页做好了本地化，页面上有一张送货员申请表。在网址后面加上 /admin 登录，就能进入 Payload 的管理后台，里面有专门为送货员申请做的仪表盘。提交一份测试申请，这份申请马上就会出现在数据库里，带着运营团队审核需要的全部字段。

负责接收、存储和跟踪每份申请的数据模型，是 Figma agent 建的，申请提交之后，应用还会自动发出邮件和通知。这些功能 agent 不用从零开始写，直接在 Payload 的基础上搭建就行。

/admin 后台里的送货员申请统计

在同一个后台里，市场同事可以修改页面、更新文案、调整 SEO、新建页面、管理素材，不用再给开发提工单。Payload 同时管理内容和素材，照片、视频、PDF 都能分文件夹存放，加上标签和元数据。

在 Payload 后台修改文章标题和标签

还可以把 Figma Weave 的工作流接进 Payload，在后台里选一个工具、填好 prompt，就能为每个城市的落地页生成风格统一的视频，这个工作流已经为不同城市生成了十来条视频。

在 Payload 里用 Weave 生成视频

Payload 是开源的，可以连接 GitHub、在本地开发、部署到任何地方。用 Payload 做的网站和内容也不会绑定在 Figma 上，以后不想放在 Figma 里了，可以把整个应用和里面的内容一起迁移出来，部署到别的地方继续运行。

agent 和 MCP 的更新

前面这些工作流里，具体的操作大多是 Figma agent 完成的。Dylan 特别说明，Figma 做这个 agent，是为了让设计师能做到的事情尽可能多，并不打算用它取代设计师。 现在已经有客户用 Figma agent 处理重复的工作、用设计系统生成基础的页面。

Figma agent 介绍页

通过 Figma 的 MCP，别的 AI 工具可以读取 Figma 里的设计稿，也可以把做好的内容写回 Figma。这次 MCP 新增了 skill.md 指引和生成图片的能力，也能生成代码图层，把 spec 写进 Figma 或者读出来。Dylan 还在台上专门喊话，六个月前用过 Figma MCP、觉得还差点意思的人，一定要再尝试一次，这半年 MCP 进步得非常多。

MCP 新增的三项能力

演讲最后，Dylan 说 Figma 想帮大家 work at the speed of thought，按想法的速度工作，让想法不再受过去那些限制。他又回到了"Build by design"这个主题，AI 可以帮人把产品做出来，但要做出好的产品，还需要做产品的人有自己的意图，需要手艺、用心和创造力。

本文内容来自 Figma Config India 2026 主题演讲，配图取自演讲视频和 Figma 当天发布的产品文章。