设计稿直接变可运行代码：Figma Code Layers 开放公测，Specs 让 agent 按你的设计系统干活

10 月 15 日，Figma 在班加罗尔召开了首届印度 Config 大会 Config India 2026。超过 30,000 人线上线下注册，这是 Figma 办过的规模最大的国际会议——印度已经是 Figma 除美国之外最大的用户市场，按日活算是全球第二。CEO Dylan Field 亲自到场，他在台上说了一句很说明问题的话：当代码正在变成大宗商品，设计就是越来越重要的差异化。

配合大会，Figma 当天在官方博客发布了《Build by Design: New Workflows for New Ways of Building》（发布时间 2026-10-15），一次性公布了一组面向 agent 的更新：Code Layers 从私测转公开 beta、全新的 Specs Markdown 规范编辑器、设计系统扩展、20 个 MCP 伙伴集成，以及把开源 CMS Payload 接进 Figma Make。这不是零散的功能更新，而是一整套「设计稿 → 规范 → agent → 代码」的新工作流。vibe coder 最关心的那段路——设计稿到可运行代码之间的翻译损耗——Figma 决定亲自把它产品化。

Code Layers 公开 beta：运行代码搬上画布

Code Layers 今年 6 月刚宣布私测，10 月 15 日就转入公开 beta，所有计划都能用。它的概念一句话：把运行代码带上 Figma 画布，让团队在画布上用代码做探索，而不是在 IDE 里孤岛式地写。

官方列了五种把代码带上画布的方式：把已有设计转成可交互的代码层、从本地文件夹上传、经 Figma MCP server 从第三方编码工具引入 coded prototype、从 GitHub 导入（代码层会和仓库保持连接），以及用 Figma 的 Chrome 插件把线上网站当前的样子抓下来变成代码层。这五种入口覆盖了一个原型从无到有的几乎全部起点：从设计出发、从现有代码出发、从 agent 生成的原型出发、从线上产品出发。

在画布上，代码层的好处是「版本可以并排摆」。你在编码工具里用 agent 迭代，很容易在第一个想法上就一条道走到黑；代码层让多个版本的原型同时待在画布上，团队可以复制一份试另一条路，不用在两个窗口之间来回切换。看中某个界面的视觉部分不想改代码？Extract designs 能把代码层里的某屏或某段流程抽出来变成可编辑的 Figma 图层。改完想同步回去也行：把更新 push 到分支，团队走 PR review 就能合进共享项目。

官方博客里放了几个客户案例，数据值得记下来。全球客户体验代理商 Merkle 把 code layers 用在从空白画布构思到迭代已有功能的整个流程里：迭代和功能开发快了 30%，交互说明之类的文档少了 50%。Cox Automotive 的高级产品经理 Lindsay Brechler 把一个 HTML 原型带进代码层对齐 stakeholder，因为每个版本都留在画布上，她可以随时从任意版本接着改。Rocket Money 的设计系统负责人 Derek Onay 在做基础屏幕组件时，用「设计转代码层」的方式早早定下交互和无障碍细节，避免问题流到用户手里才爆发。Checkout.com 的设计师 Kris Murphy 用代码层给潜在客户做 demo，速度比平时快约 50%，「code layers 是设计和开发之间正经的桥」。1Password 的首席体验官 Matt Davey 则说了句很 Figma 的话：画布真正的超能力，是把所有 UI 元素摆在一起看——「就像以前我们把网站所有页面打印出来贴在白板上」。

定价方面，博客写得很明确：Code Layers 会消耗 AI credits，但在付费计划上，11 月 4 日之前创建和编辑代码层免费。这是一个窗口期策略：先让所有人上手，11 月之后再按 AI credits 计费。agent 功能本身——画布上内嵌的 Figma agent 已经 GA——则是这套工作流的发动机，官方说新版 Figma MCP 在 agent 引导和服务器性能上做了改进，能减少错误和 token 消耗。

图 1：传统链路里设计稿到代码靠人工翻译、思考过程在原型链接中丢失；新链路把设计、运行代码和规范都留在画布上，经 MCP 带着全上下文交给 coding agent。

Specs：Markdown 原生的设计规范编辑器

这次发布里最值得细看的是 Specs。Figma 的判断是：随着团队越来越多地和 agent 协作，Markdown 无处不在，但 Markdown 文件之间彼此没有关系，也和它们所附着的项目没有关系，里面引用的图片、URL、其他 Markdown 文件，对协作者来说经常是黑盒。所以 Figma 造了一个「上下文的原生家园」——Specs。

Specs 是一个 Markdown 原生编辑器，用来记录公司的设计语言和规范。它的能力集中在「引用」上：可以引用画布上的元素，可以嵌入 FigJam 图、code layers 和设计稿。除了写规范，它还能干几件事：为生成新方向提供种子输入、做数据报告、写高保真 PRD，或者把上下文交接给 agent。你可以用 agent 把外部上下文带进来，和团队一起把粗糙想法打磨成详细 spec；也可以直接用 spec 起一个代码层，边学边改。

但 Specs 真正的杀手级用法，是它和 MCP 的组合：团队确认方向之后，把 spec 链接丢给 coding agent，对方经 Figma MCP server 一并拿到全部上下文——Markdown 正文、帧引用、图、代码层、Code Connect 片段。不用再把需求口头复述一遍，链接本身就是一份带上下文的任务书。官方还提到可以用 GitHub connector 辅助起草技术 spec，比如为一个打包配送功能写技术规格文档。Specs 从今天起在 web、桌面和移动端进入公开 beta，所有付费计划可用。

这一步的意义在于，它把「规范」从静态文档变成了 agent 可执行的输入。以前设计规范写在 Notion 里，agent 根本看不见；现在规范活在画布旁边，agent 经 MCP 直接读取，规范的约束第一次有了被自动执行的通道。

设计系统扩展与 20 个 MCP 伙伴集成

Figma 在博客里把逻辑说得很直白：设计系统一直是产品一致性的基础，而当团队开始越来越多地用 agent 做东西，这个基础变得更重要——给 agent 正确的模式和原则，它才能站在团队已经投入的 craft 之上继续盖楼。所以设计系统在 Figma 里能装的东西变多了：引入代码源（code sources）和指南（guidelines），让 agent 无论在哪干活都能读到设计系统。

具体有三块。第一，Guidelines 进入公开 beta：可以把指南加到已发布的设计库里，agent 更容易遵循既定模式。第二，code sources 进入 closed beta：从 GitHub 仓库或 npm 包导入代码源，帮助 agent 生成和编辑更贴合设计系统的组件和代码层。第三，一个专门管理设计系统的地方正在预览中：system map 帮你追踪变更和依赖，system check 会扫描设计系统里的缺口，比如缺失的描述和交互状态。Guidelines 公开 beta 和 code sources closed beta 都面向所有付费计划。

MCP 侧的更新同样密集。Figma MCP 现在支持从你已经在用的 AI 工具里直接生成代码层、操作 specs，还能创建视觉资产、运行已发布的 Weave workflow。官方说改进后的 agent 引导和 MCP 服务器性能降低了错误率和 token 用量。配合这次发布的，是 20 个新的 MCP 伙伴集成：

• OpenCode：给你的 coding agent 喂 Figma 设计系统上下文，生成更准确的代码，还能把原型送回 Figma 评审；
• Dia：在这款 AI 原生浏览器里探索想法，把 web UI 带进 Figma 变成可编辑的设计图层；
• JetBrains Junie：把 coded prototype 带回 Figma 变成代码层，和团队一起迭代打磨；
• Meta Muse：让小商家把在 Figma 里设计好的品牌带进 Muse，生成更多视觉物料、跑 Weave workflow；
• Sarvam：印度本土 AI 公司的 MCP 合作，配合 Figma 在印度的扩张。

还有一笔收购的落地：开源内容框架 Payload（去年加入 Figma）现在接入 Figma Make。过去 12 个月 Payload 下载量涨了 6 倍，是 NPM 上增长最快的开源 CMS。接入之后，营销团队不用进源码、不用等工程师排期就能管理网站内容，而且内容始终和设计系统绑定，准确呈现品牌；内容、workflow、API 和管理后台都在一处，Figma 负责托管，做出来的应用也可以带出 Figma。Payload 对所有计划开放，按账号分批 rollout。

图 2：Specs 的工作流——团队在 Markdown 规范里引用画布元素并确认方向后，一条 spec 链接经 Figma MCP server 把正文、帧引用、图表、代码层和 Code Connect 片段全部交给 coding agent。

观点：Figma 在回答「vibe coding 让思考变得 invisible」

这篇博客最有意思的一段不是功能列表，而是 Figma 对 vibe coding 的诊断。博客区分了两种建造：为思考而建造（building to think）和为交付而建造（building to ship）。AI 让前者变得极其便宜，但这条路往往是单人模式，容易隧道视野。博客原话是：当大家都在外面 vibe coding 原型，感觉像在孤岛里设计；现在的协作有时候就是分享一个原型链接或一段视频——你看得到结果，看不到是怎么走到这一步的。「我们在为思考而建造，但思考过程变得 invisible。」一位客户的总结更扎心：「快，快，快……然后慢。」

这是大厂第一次把 vibe coding 的代价说得这么透：快的是原型阶段，慢的是交付阶段，而中间丢失的正是「为什么这样做」的思考过程。Figma 的解法不是让 agent 写得更快，而是把思考过程留在画布上：设计稿、运行代码、规范文档互相引用，决策落盘成 shared decisions，spec 链接带着全部上下文交给 agent。以前「设计→代码」的最后一公里是人肉翻译，现在 Figma 把它做成了一条产品化的流水线——Specs 是任务书，MCP 是传送带，设计系统是护栏。

对 vibe coder 来说，这套东西的直接价值有两层。第一层是个人工作流：你不再需要在 Figma 和 IDE 之间二选一，代码层让你在画布上就能跑原型、并排比较、回退版本，思考过程自动沉淀。第二层是协作范式：以前你给 agent 的 prompt 是「做一个落地页」，现在你可以给它一条 spec 链接，里面有你确认过的方向、引用的设计帧、嵌入的交互图和代码片段。prompt 的质量上限，从「你多会描述」变成了「你的规范写得多清楚」。

当然，Figma 的算盘也很清楚：画布是它的主场。当所有人和 agent 的工作流都经过画布，Figma 就从「设计工具」变成了「人和 agent 的共同工作台」。30,000 人注册的 Config India，与其说是发布会，不如说是 Figma 在向它的第二大市场宣布：agent 时代的设计入口，它要自己定义。

三个还没回答的问题

第一，11 月 4 日之后，AI credits 到底多少钱？官方只说了付费计划在 11 月 4 日前免费创建和编辑代码层，之后走 AI credits。但 credits 的计价粒度、免费额度、一个中等团队每月的实际开销，现在都是未知数。窗口期策略很聪明，但团队要不要长期用，得先算一笔账——尤其当 code layers 的调用方从人变成 agent，消耗速度可能远超预期。

第二，agent 真能消化「全上下文」吗？Spec 经 MCP 带上的东西越多，传输和推理的 token 成本越高，这笔账谁来付、付多少，博客没提。更重要的是，上下文多不等于 agent 记得住、用得对。规范写得含糊，agent 就会带着含糊的上下文生成含糊的代码——Specs 把「规范质量」变成了整个链路的上限，而大多数团队的规范写作能力，还停留在「写给人看」的阶段。

第三，code sources 还是 closed beta，「支持更复杂代码库」没有时间表。博客说会逐步支持更复杂的代码库，但 GitHub 导入对仓库规模、私有依赖、monorepo 的支持程度现在都不清楚。对于真实工程项目，轻量原型代码库和生产代码库之间隔着一道墙，Figma 打算用多久、用什么方式跨过去，是决定这套工作流能走多远的关键。

无论如何，方向已经很明确：设计工具正在从「画图的软件」变成「给 agent 下任务单的软件」。Code Layers 公开 beta、Specs、20 个 MCP 集成，这一套组合拳说明 Figma 不想只做 agent 生态的旁观者。vibe coder 们以后抱怨「agent 不懂我的设计」之前，可能得先问问自己：你的规范，写进 Specs 了吗？

一手来源：Figma 官方博客《Build by Design: New Workflows for New Ways of Building》（2026-10-15 发布）、《Design Together with Code Layers on the Canvas》（2026-10-15 发布）、《Figma Deepens Investment in India With Largest International Config Yet》。