Figma 官方文章：
https://www.figma.com/blog/the-benefits-of-code-connect-in-mcp/

过去一年，AI Coding Agent 从设计稿生成前端代码的能力已经越来越强。

把一张 Figma 页面交给 AI，它已经能够识别布局、颜色、间距、按钮、表单和卡片，然后快速生成 React 等前端代码。

但这里一直存在一个非常现实的问题：

AI 可以看懂这个页面“长什么样”，却不一定知道你的团队实际上“怎么写”。

例如设计稿上出现一个 Tabs 组件。

AI 知道它看起来像 Tabs，也能自己用 div、button 和 CSS 写出一个视觉上十分接近的版本。

问题是，你们公司的代码库里可能早就存在一套经过长期维护的 Tabs 组件。

里面已经处理好了：

• 状态切换；
• 键盘操作；
• 无障碍；
• Design Token；
• 响应式布局；
• 类型定义；
• 交互逻辑；
• 设计规范。

如果 AI 不知道这套生产组件存在，它很可能重新写一遍。

页面看起来对了，但代码却没有真正进入团队原有的设计系统。

这正是 Figma MCP + Code Connect 想解决的问题。

Figma 在 2026 年 8 月 5 日公布了一组 Code Connect 在 MCP 工作流中的测试结果：给 AI Agent 提供真实生产组件上下文后，不仅最终代码质量提高，Token 消耗和任务执行时间也同步下降。

对于正在关注 Figma MCP、AI Coding、Design to Code、设计系统、Code Connect 和 AI Agent 前端开发 的团队来说，这组数据非常值得看。

一、先搞懂：Figma MCP 到底解决什么问题？

MCP，全称 Model Context Protocol。

放到 Figma 的场景里，可以简单理解成：

让 AI Coding Agent 不只是“看 Figma 截图”，而是能够读取设计背后的结构化上下文。

例如一个普通 AI 如果只看到页面视觉效果，它可能只知道：

这里是蓝色按钮；

这里有一个卡片；

这里有一个 Tabs；

这里的间距大约是 16px。

但通过 Figma MCP，Agent 能获得的内容会更加结构化，包括组件、变量、布局以及部分设计决策，而不仅仅依赖视觉猜测。

这两种方式的差别非常大。

只看视觉

AI：

这里看起来像一个卡片，我做一个差不多的。

获得设计上下文

AI：

这里使用的是设计系统中的 Card Component，并且对应指定的变量、布局和组件属性。

这也是 MCP 在 Design to Code 场景里的核心价值：

给 Agent 补上下文。

但即使有了 Figma MCP，依然还有一个问题没有彻底解决。

那就是：

Figma 里的组件，到底对应代码仓库里的哪个组件？

这时候就轮到 Code Connect 出场了。

二、Code Connect 是什么？

Code Connect 可以理解成连接：

Figma 设计组件 ↔ 真实代码组件

之间的一层映射。

例如设计师在 Figma 中使用：

Button / Primary / Large

而前端项目里真正使用的可能是：

<Button variant="primary" size="large">
  Continue
</Button>

对于人类开发者来说，如果长期参与这个项目，看到设计稿以后通常知道应该调用哪个组件。

但是 AI Agent 不一定知道。

它可能会自己生成：

<button className="primary-button">
  Continue
</button>

视觉效果甚至可能几乎一样。

但这两个结果对生产环境来说，意义完全不同。

第二种写法相当于绕过了团队已经维护好的组件系统。

Figma Code Connect 的作用，就是提前告诉 AI：

设计里的这个东西，对应代码库里的这个东西。

根据 Figma 官方说明，Code Connect 设置完成后，Figma MCP 返回给 Agent 的内容可以包含真实生产代码相关的代码片段，而不只是根据视觉设计生成出来的 React 表示。

这一步非常关键。

三、以前 Agent 从 Figma 生成代码，问题出在哪？

Figma 在官方文章中总结了几种非常典型的情况。

当 Agent 通过 MCP 获取设计信息、却没有 Code Connect 映射时，它可能会：

1. 自己重新创建一个组件；
2. 从设计系统里选错组件；
3. 最终找到了正确组件，但先进行了大量搜索和尝试。

这些过程都会带来额外的：

搜索、猜测、调试、修改和 Token 消耗。

举个非常简单的例子。

假设 Figma 中存在一个：

Segmented Control

没有 Code Connect 时，Agent 可能看到设计以后生成类似：

<div role="tablist">
  <button>Design</button>
  <button>Code</button>
</div>

然后继续补：

CSS、圆角、背景颜色、选中状态、间距、交互逻辑……

但是企业自己的组件库里可能早就有：

<SegmentedControl
  value="design"
  options={["Design", "Code"]}
/>

Code Connect 的意义就是让 Agent 更快知道：

不用重新造，这里直接用现成的。

Figma 官方展示的 Code Connect 示例正是这种区别：有 Code Connect 后，MCP 可以向 Agent 提供更加贴近实际设计系统的组件代码，而不是让 Agent 从基础元素重新组合。

四、效果有多明显？Figma 给出了三组关键数据

这次比较值得关注的不是概念介绍，而是 Figma 实际做了一组测试。

Figma 构建了一套评测流程，对同一批 Design to Code 任务分别测试：

不使用 Code Connect

和

使用 Code Connect

两种情况。

总共涉及 27 个测试案例，主要观察三个指标：

• Token 使用量；
• Agent 完成任务所需时间；
• 最终代码质量。

测试涉及两个 React 设计系统，包括 Figma 的 Simple Design System，以及规模更大的内部 Figma Pattern Library。测试模型包括 Claude Sonnet 4.5 和 Claude Opus 4.7。

最终得到的中位数结果非常直观。

1. Token 使用量降低 29.5%

使用 Code Connect 后：

中位任务 Token 使用量下降 29.5%。

为什么能省这么多 Token？

逻辑其实非常简单。

如果 Agent 不知道应该使用什么组件，它可能需要：

搜索代码库；

查看 node_modules；

搜索组件名称；

搜索 Icon；

读取相关文件；

尝试一个组件；

发现不对；

重新生成；

再修改 CSS。

这些操作每一步都需要上下文和 Token。

Code Connect 相当于直接告诉它：

就用这个组件。

Agent 少走很多弯路，自然也就减少 Token 消耗。

2. 任务时间减少 19.6%

Figma 的另一项结果是：

任务执行时间中位数下降 19.6%。

这与 Token 减少其实是同一个逻辑。

Agent 找组件、读文件、尝试实现、调试和返工的次数减少，最终完成任务的时间自然也会缩短。

在 Figma Pattern Library 的一个测试案例中，Code Connect 版本的 Agent 可以直接使用真实 Tabs 和 Button 组件，最终大约只用了基线任务 77% 的时间和 62% 的 Token。

对于大量运行 Coding Agent 的团队来说，这一点尤其重要。

因为 Agent 成本不仅仅是模型价格。

还包括：

运行时间、Token、工具调用次数，以及工程师等待和检查结果的时间。

3. 代码质量从 2 分提升到 3 分

Figma 使用了一个 1～4 分 Likert 评分体系评价代码质量。

主要评估：

• Correctness；
• Code Quality；
• Maintainability；
• Completeness；
• Best Practices。

最终结果显示：

代码质量中位数从 2 分提高到了 3 分。

也就是整体提升了完整 1 分。

按照 Figma 的评分体系：

2 分代表代码可以部分工作，但仍然存在比较明显的问题；

3 分则代表整体实现已经比较扎实，只存在少量问题或冗余。

这其实比单纯“页面看起来更像”重要得多。

五、Design to Code 最大的问题，从来不是“像不像”

过去评价 AI 从 Figma 生成前端代码，经常会看：

还原度有多高？

例如：

颜色是不是一样？

圆角准不准？

间距有没有偏？

页面截图像不像？

这些当然重要。

但真实软件开发还有另外一个标准：

这段代码能不能真正放进现有项目长期维护？

假设 AI 生成出来的页面和设计稿有 95% 的视觉相似度。

但是：

按钮是重新写的；

Tabs 是重新写的；

Modal 是重新写的；

颜色直接写 Hex；

Spacing 全是硬编码；

Icon 重新找了一套；

组件命名完全不同。

那么从设计系统的角度来看，它其实仍然是不合格的代码。

尤其是大型产品。

一个组件可能同时存在于：

官网、控制台、App、后台管理系统、支付页面和账户中心。

如果每次 AI 生成页面都重新实现一套，之后维护成本会越来越高。

所以 Design to Code 真正困难的并不是：

“AI 能不能把页面画出来。”

而是：

“AI 能不能按照这个团队真正的生产方式把页面写出来。”

Code Connect 正是在补这一层。

六、一个很典型的案例：Coinbase

Figma 官方文章还提到了 Coinbase Design Systems 团队。

Coinbase 的设计系统团队负责维护核心设计组件、Token 以及相关基础设施。

随着工程团队越来越多地使用 Agent 驱动的开发方式，他们开始使用 Code Connect，目的就是让 Agent 优先采用正确的生产组件，而不是重新实现。

Coinbase 前端工程师 Erich Kuerschner 使用：

相同设计；

相同 Prompt；

相同模型；

分别测试有 Code Connect 和没有 Code Connect 的效果。

没有 Code Connect 时，Agent 有时会自己拼一个类似组件。

例如原本应该使用设计系统里的组件，却可能根据视觉效果用其他基础组件组合出来。

而接入 Code Connect 后，Agent 能看到更准确的设计对应代码，以及指向正确设计系统组件的 import 信息。

这就是 Code Connect 很实际的价值。

不是单纯让模型“变聪明”，而是把团队已经知道的东西直接告诉模型。

七、为什么“上下文”会成为 Coding Agent 越来越重要的一部分？

这几年大家讨论 AI Coding，经常把注意力集中在模型能力上。

哪个模型写代码更强？

哪个模型 Benchmark 更高？

哪个模型上下文更长？

这些当然重要。

但进入真实企业项目以后，会发现另一个问题越来越突出：

再强的模型，也不会天然知道你公司的内部规范。

它不知道：

这个 Button 应该用哪个组件；

这个颜色应该引用哪个 Token；

什么时候应该使用 Modal；

什么时候应该使用 Drawer；

你们的表单验证习惯是什么；

目录结构应该怎么放；

组件命名规则是什么；

测试应该怎么写。

这些都属于：

组织内部上下文。

Figma 在总结这次测试时也特别强调，Agent 并不会自动知道一家公司的“好代码”意味着什么，需要给它明确、结构化的上下文。

从这个角度看，未来 Coding Agent 的竞争不会只有：

模型能力。

还会越来越看：

谁能给模型提供最准确的上下文。

八、Figma MCP + Code Connect 是怎么配合的？

可以把整个链路拆成三层。

第一层：Figma 设计

这里包含：

组件；

变量；

布局；

设计系统；

视觉状态；

设计稿结构。

↓

第二层：Figma MCP

MCP 负责把设计中的结构化信息提供给 AI Agent。

Agent 不再只是看截图，而是获得设计上下文。

↓

第三层：Code Connect

Code Connect 再进一步告诉 Agent：

这个 Figma Component 对应代码仓库里的哪个真实 Component。

Figma 官方对它的描述非常明确：Code Connect 可以告诉 MCP 哪个代码组件与 Figma 组件相匹配，以及 Agent 应该到哪里使用它。

最终形成：

Figma Design → MCP Context → Code Connect → Production Components → Coding Agent

这套链路才是真正有意思的部分。

九、设计系统的价值也被进一步放大

以前设计系统主要解决的是：

设计师和开发者之间的一致性。

例如：

统一颜色；

统一字体；

统一间距；

统一组件；

统一交互规范。

现在加入 AI Agent 以后，设计系统又多了一个使用者：

AI。

Figma MCP 可以把设计系统中的组件、Token 和设计信息暴露给 Agent，而 Code Connect 又进一步建立设计组件与生产代码之间的对应关系。

所以以后一个维护得好的 Design System，不只是方便：

设计师；

开发者；

产品团队。

还会直接影响：

AI 生成代码的质量。

这也是为什么设计系统越成熟的大型团队，反而可能越适合使用这类 Agent 工作流。

因为大量规范已经被结构化。

AI 不需要猜。

十、设计文件本身也需要越来越“AI Friendly”

有 MCP 并不代表所有 Figma 文件都自动适合 AI。

Figma 也特别提到：

MCP 能利用的仍然是你提供给它的上下文。

设计文件组织得越清楚，Agent 得到的信息就越有效。

例如官方建议：

图层名称要清晰

与其叫：

Frame 1337

不如直接叫：

nav-bar

或者：

product-card

使用真正的组件和 Token

如果设计师已经把组件 Detach，然后所有颜色和数值都手写，Agent 获得的设计系统信息自然会减少。

正确使用 Auto Layout

Auto Layout 不只是方便设计师调整布局，也能让 AI 更清楚元素之间的空间关系和响应式行为。

给交互增加说明

静态页面很难表达：

Hover；

Loading；

Disabled；

Transition；

动态数据；

交互逻辑。

这些仍然需要更加明确的设计上下文。

所以未来设计师整理 Figma 文件的意义可能会进一步提升。

因为你的文件不仅要：

让人看懂。

还要：

让 Agent 看懂。

十一、Code Connect 覆盖率越高，效果越明显

Figma 这次测试还有一个很值得注意的结论：

Code Connect Coverage 非常重要。

测试的两个设计系统覆盖程度并不相同。

Simple Design System 的 Code Connect 覆盖率很高，而 Figma 内部更复杂的 Figma Pattern Library 覆盖相对不完整。

Figma 发现：

设计中使用设计系统组件的比例越高，同时这些组件被 Code Connect 映射得越完整，Agent 的表现通常越好。

这说明 Code Connect 并不是：

装上以后立即让所有 AI 生成任务质量完全一致。

它需要团队持续建立：

设计组件 ↔ 生产组件

之间的映射。

因此对于大型设计系统来说，比较现实的方法可能不是一次全部连接完成。

而是优先处理：

Button；

Input；

Tabs；

Modal；

Card；

Navigation；

Select；

Form；

Table。

这些出现频率最高的核心组件。

随着映射覆盖率提高，Agent 可以复用的真实上下文也会越来越多。

十二、Code Connect 怎么开始使用？

根据 Figma 当前开发者文档，Code Connect 可以通过 CLI 等方式建立 Figma 设计组件与代码组件之间的映射。

Figma 推荐使用 Template Files 来连接设计组件和代码。

对于 CLI 方式，目前官方文档要求 Node.js 18 或更新版本，并需要配置具有相应 Code Connect 与文件读取权限的 Figma Personal Access Token。

Code Connect CLI 可以通过 npm 安装：

npm install --global @figma/code-connect@latest

随后可以在项目中配置：

figma.config.json

并使用 .figma.ts 或 .figma.js Template File 建立设计组件和真实组件之间的连接。

一个 Template File 的核心作用，可以简单理解为：

告诉 Figma：

这个设计组件是谁；

有哪些属性；

这些属性如何映射到代码；

最终应该展示或使用什么代码片段。

更值得注意的是，现在 Figma 甚至已经支持让兼容 Figma MCP 的 Coding Agent 辅助创建 Code Connect Template File：Agent 可以检查哪些 Figma Component 尚未建立映射、读取属性定义、查找代码库中的匹配组件，然后生成对应 .figma.ts 文件。

也就是说：

连“给 Agent 准备上下文”这件事，本身也正在被 Agent 辅助完成。

十三、这对设计师意味着什么？

很多设计师看到 MCP 和 Code Connect，第一反应可能会觉得：

这是开发工具。

其实不完全是。

当 AI Agent 越来越多地参与 Design to Code 时，设计师在 Figma 里做的决定，会更加直接影响最终代码。

例如：

组件是不是来自设计系统；

变量有没有正确使用；

Auto Layout 是否合理；

组件属性是否清晰；

设计文件是否规范。

过去这些问题可能由开发者在实现阶段进行一次人工“翻译”。

未来 Agent 自动实现的比例提高以后，一个不规范的设计文件也可能被快速复制到大量页面中。

所以设计师维护：

Design System、Component、Variable 和规范文件

的重要性只会越来越高。

十四、这对前端开发者意味着什么？

对于开发者来说，最明显的变化就是：

少做翻译，多做真正需要判断的工作。

以前从 Figma 到代码，中间经常要做大量人工转换：

找颜色 Token；

检查间距；

确认组件；

搜索设计系统；

核对组件 Props；

检查 Icon；

重新实现交互。

现在 Figma MCP + Code Connect 的方向，是尽可能把这些已经存在的信息直接交给 Agent。

开发者的工作重点则逐渐向：

业务逻辑；

架构；

状态管理；

性能；

异常处理；

安全；

Code Review。

这些更需要工程判断的部分移动。

十五、AI Coding 下一阶段，可能比拼的是“谁的上下文更好”

Code Connect 这次测试其实说明了一个很值得关注的趋势。

以前我们可能觉得：

模型能力越强 → 代码质量越高。

现在又增加了一条非常重要的关系：

上下文越准确 → Agent 越少猜 → 成本越低 → 结果越稳定。

Figma Code Connect 带来的并不是一个更强的基础模型。

模型没有因为 Code Connect 本身发生变化。

变化的是：

Agent 在开始写代码之前，知道的东西更多了，而且知道得更加准确。

这也解释了为什么 Figma 的测试中能够同时出现：

Token 降低；

执行更快；

代码质量提高。

因为 Agent 不再把大量计算资源浪费在：

猜组件；

搜组件；

重新实现组件；

最后再修组件。

十六、从 Design to Code，走向真正的 Design System to Code

过去很多 AI 工具宣传的是：

Design to Code。

把设计稿转成代码。

但 Figma MCP + Code Connect 展示出的方向更加具体：

Design System to Code。

区别就在于：

前者关注：

“把这个页面写出来。”

后者关注：

“使用我们团队正确的组件、Token 和开发规范，把这个页面写出来。”

两句话看起来差距不大。

但对于真正需要维护几年甚至十几年的产品来说，后者的重要性明显更高。

一个页面长得像设计稿，只解决了一次交付。

而组件、代码和设计系统保持一致，解决的是：

这个产品以后怎么继续维护。

结语

Figma MCP 与 Code Connect 这次最值得关注的，不只是：

Token 降低 29.5%。

也不是：

任务时间减少 19.6%。

更重要的是，它进一步证明了一件事：

AI Agent 要真正进入专业生产环境，仅仅“看懂页面”是不够的。

它还必须理解：

团队有哪些组件；

组件对应哪些代码；

应该使用什么 Token；

哪些规范必须遵守；

最终代码应该如何融入现有项目。

Figma MCP 负责把设计上下文交给 Agent。

Code Connect 则进一步把：

Figma 里的设计组件，与真实生产代码建立连接。

当这两部分结合以后，AI 从 Figma 生成代码的目标，就不再只是：

“看起来差不多。”

而是逐渐接近：

“真正使用这个团队的设计系统，把它写进现有代码库。”

对于正在使用 Claude Code、Codex、Cursor 等 Coding Agent，同时团队又拥有成熟 Figma Design System 的开发者和设计团队来说，这可能会成为非常值得关注的一条 AI Coding 工作流。

官方资料：

https://www.figma.com/blog/the-benefits-of-code-connect-in-mcp/