Figma给AI铺路:1个季度省3万返工钱

设计师画好了图，程序员照着写代码，中间总要来回扯皮几十次。这个「设计转代码」的断层，Figma 想用一个新东西填上。

10 月 15 日，Figma 在印度的首届 Config 大会上发布了 Figma Specs，一个用 Markdown 写「设计说明书」的工具，还顺手把「设计直接转代码」的 Code Layers 放进了公开测试。

先看它解决什么问题。一个产品的设计图，看起来只是一张画，背后藏着一堆没写出来的规则：这个按钮点下去要干嘛？API 挂了显示什么？手机端的布局用哪套组件？

以前这些规则散在设计师脑子里、聊天记录里、没更新的文档里，程序员要猜，猜错了就返工。Figma Specs 就是把这些规则写成一个文档，跟设计图并排放在一起，人和 AI 都能读。

老陈在一家做 SaaS 的小公司当设计负责人，团队就一个前端。以前最怕的就是「设计交付」这个环节：设计师觉得图已经画得很清楚，前端却总说「不知道这里怎么处理」。

有了 Specs，他把每个页面的规则写成 Markdown，前端对着文档写，返工次数从「每个页面五六次」降到一两次。

他算了笔账：一个迭代周期省下十几天的来回沟通，折合成人力，一个季度能省 3 万元上下。团队本来打算再招一个前端，现在这一个就够用了，一年又省下 18 万元的工资预算。

这事背后真正改掉的，是「设计意图」的丢失。过去设计和代码是两个世界：设计在 Figma 里，代码在 GitHub 里，中间靠截图和口口相传。

Specs 加 Code Layers，等于把这两个世界打通：设计图里能直接放代码，代码能引用设计规范，AI 还能在这两者之间自动搬运。设计意图第一次有了一个「不会丢」的载体。

第二层才是关键。为什么强调「人和 AI 都能读」？因为下一个参与写代码的，很可能不是人，而是 AI Agent。你让 AI 帮你把设计转成前端，它最缺的不是能力，是「上下文」：这个按钮的业务规则、这个空状态怎么处理、这个组件能不能复用。

Specs 把这些上下文喂给 AI，它生成的代码才不会跑偏。换句话说，Figma 在给「AI 编程」铺路：先把设计意图结构化，AI 才能接得住。

不过门槛也清楚：Code Layers 还在公开测试，Specs 也是逐步开放，不是所有账号都能立刻用。而且它不能替你判断业务逻辑对不对，生成出来的代码还得人审一遍。它省的是「翻译」的活，不是「判断」的活。

Figma logo

往深了看，这次更新还有个更大的信号：Figma 想从「设计工具」升级成「产品开发的中枢」。它已经把去年收购的 CMS 工具 Payload 接了进来，又扩了 20 多个 MCP 合作伙伴，包括 OpenCode、Grok Bot 这些 AI 工具。

逻辑很清楚：光有设计图不够，得把设计、代码、内容、AI 全部串在一个工作流里，才能卡住「从想法到上线」的整条链路。对团队来说，这意味着以后围绕 Figma 会长出一个更完整的协作生态，而不是只当它是画图的地方。

那它值不值得你现在用？如果你在的团队是「设计多、开发少、还天天为交付扯皮」，答案值得关注。判断标准很简单：你的团队一个月在「设计转代码」上要返工几次？超过三次，就该试试 Specs。

不过也别把它当成「点了就出成品」的魔法。Code Layers 生成的是「起点代码」，能跑、能交互，但离能上线还有距离：性能、安全、边界情况，这些还得工程师补。指望它替代前端，现阶段不现实；指望它省掉最烦人的「翻译」和「来回对齐」，是现实的。

老陈那团队的体验是：返工少了，但该有的代码评审一样没少。他们一个 5 人的产品组，以前一个月要开 4 次对齐会，现在砍到 1 次，省下的会议时间够每人多写 20 份需求文档。

要动手的话，三件事可以马上做。

第一，打开 Figma，看看你的账号有没有 Specs 和 Code Layers 的入口，有的话先建一个最小页面的 Specs 试试。

第二，挑一个你团队最近返工最多的页面，把它没写清的规则用 Specs 写下来，看能不能减少下一次沟通。

第三，别指望它一步到位，先把它当「设计文档的规范工具」用，跑顺了再往代码生成上靠。

一句话：设计和代码之间的墙，不会因为 AI 更聪明就自动消失，得先有人把意图写清楚，AI 才接得住。

传乘AI工具站已经把 Figma 收录了，想对照它这次更新的细节，可以点击“阅读原文”进去看。