# Figma 首批 FDE 要教会 Agent 读懂客户的设计系统

> 招聘启事写明这不是销售或服务岗：MCP 服务器和 Code Connect 都已就绪，每家企业的上下文仍要有人搭建。

原文: https://fdetimes.net/zh/analysis/figma-founding-fde-team-agent-ready-design-systems/

Figma 在 Greenhouse 上发布的前线部署工程师（FDE）招聘启事说得很直白：这是产品与工程部门的资深/Staff 级工程岗位，不是销售，也不是服务。Figma 还表示，这是公司的第一支 FDE 团队，属于创始团队。

一家设计工具公司组建一支驻扎客户现场的工程师团队，听上去有些奇怪。原因在于启事里写明的使命：让企业设计系统适配 Agent，使 AI 工具生成的代码贴合设计系统、忠于设计稿。

这句话值得细读。它揭示了 AI 领域 FDE 工作的走向：客户需要的不再只是一次 API 集成，而是一层专为本组织构建的上下文。只有既懂代码、又懂客户团队的人，才能搭起这一层。

## 产品已经有了，还缺什么？

看 Figma 现有的工具，基础设施已相当完整。根据开发者文档，Figma MCP 服务器把 Figma 接入 AI 工作流。它不只读取设计数据：Agent 还能通过 MCP 客户端直接在 Figma 中创建和编辑内容。

其次是 Code Connect，它是代码库与 Dev Mode 之间的桥梁。按 Figma 的说法，它通过复用客户的真实组件，让生成的代码与客户代码库保持一致。文档还提到，Agent 在 Figma 中构建和编辑内容时，可以把设计系统当作唯一可信来源。

6 月举办的 Config 2026 让 Figma 又向代码迈进一步。Code Layers 把代码放上画布，按 Figma 的描述，设计师现在可以直接在 Figma 里编写可交互的代码。据 Classmethod 的总结，Skills 功能让团队把自己的设计工作流和惯例打包成可复用的 Agent 指令。

但这些工具有一个共同的短板：它们只是容器。Code Connect 自己并不知道，客户仓库里哪个 `Button` 组件对应画布上的哪个组件。

Skills 自己也不知道，某家银行的设计团队什么时候用 warning 变体、什么时候用 danger 变体。这些上下文存在于每个组织成员的脑子里，没有哪个产品能开箱即带。

**要点:** Agent 的水平，取决于有人肯花力气为它构建多少上下文。

## “适配 Agent”在实践中是什么样子？

设想一家公司有内部的 React 组件库，Figma 文件里有一个“Button/Primary”组件。没有映射时，Agent 通过 MCP 读取设计稿，生成一个光秃秃的 `` 标签，颜色是写死的十六进制值，内边距用像素设定。看起来没问题，却完全没用到设计系统。

建好 Code Connect 映射后，Agent 就知道要从客户的组件库导入 ``。再加一个 Skill，记下“表单的主按钮始终放在右侧，绝不并排放两个主按钮”这样的惯例，生成的代码不仅组件用对了，用法也符合这家组织的实际习惯。

从第一种状态走到第二种，就是 FDE 的工作。要读懂客户的仓库，和设计团队坐下来挖出他们从未写下的惯例，编写映射和指令，再在真实界面上测试结果。

下表把产品文档与招聘启事中的使命放在一起对照。右栏是对各层工具在客户侧所需工作的推断，并非 Figma 公布的清单。

| 产品层 | 产品提供什么 | FDE 在客户处要做什么 |
|---|---|---|
| MCP 服务器 | 从 MCP 客户端读取设计数据并写回画布 | 接入客户使用的 AI 工具，决定 Agent 可以写什么、写在哪里 |
| Code Connect | 代码库与 Dev Mode 之间的桥梁 | 把画布上的每个组件映射到客户仓库中的真实组件 |
| Skills | 可复用 Agent 指令的容器 | 挖出设计团队未成文的惯例，转化为指令 |

中间一栏对所有客户都一样，右边一栏则因客户而异。正是这部分无法复制的工作，让一家产品公司必须招聘驻场工程师。

## 为什么必须是资深工程师？

启事要求具备 5 年以上端到端构建生产环境软件的经验，并有相当长的时间嵌入客户或合作伙伴团队工作。岗位还需要经常出差，与战略客户面对面协作。

从这个人要做的决策就能看出原因。共享组件映射错了，Agent 生成的每个界面都会跟着出错。

给 Agent 开放一家大公司画布的写权限却不设边界，可能毁掉整个团队的文件。这类决策需要亲手交付并运维过真实系统的人来做。

还有一个原因，藏在“产品与工程”这几个字里。第一支团队往往是产品学到最多的地方：每当 FDE 不得不反复编写同一类映射或指令，就是在提示产品团队下一步该自动化什么。

服务工程师把活干完就行，产品工程师还要把经验带回来。

## 瞄准这个岗位，该练什么？

核心技能是在现有系统上为 Agent 构建上下文，而不是写出精巧的提示词。

最好的练法是把这份工作缩小了做一遍：选一个带 React 组件库的开源设计系统，映射几个组件，写好惯例指令，然后让 Agent 把同一个界面做两遍，一遍有上下文，一遍没有。

然后量化。分别统计两次运行中，有多少界面元素用了组件库里的组件，有多少是写死数值的原生 HTML。

不要只数组件，因为界面即使组件用对了，仍可能破坏设计系统。还要检查颜色和间距是否来自组件库的 token，还是仍然是十六进制值和手敲的像素值。

接着检查变体：删除账户按钮被 Agent 做成 `variant="primary"` 而不是 danger 变体，这种错误靠数组件是发现不了的。

假设第一次运行 20 个元素中只有 3 个同时满足三项标准，第二次有 17 个：这样的数字写进简历或作品集，比任何一句“具备 AI Agent 经验”都更有说服力。

阅读任何公司的 FDE 岗位描述时，都可以拿 Figma 这份启事作参照：岗位在组织的哪个部门，什么级别，是不是创始团队，要不要嵌入客户团队工作？这几句话决定了你会是驻场的产品工程师，还是售后实施团队的一员。

第一支团队今天手写的映射和指令，很可能会逐步内置到产品中。现在加入的人，将决定哪些工作值得自动化，这个位置值得争取。

**本周动手试试:**

- 选一个带 React 组件库的开源设计系统，为 5 个组件编写 Code Connect 映射，然后对比有无映射时 Agent 通过 MCP 服务器生成的代码。
- 把手头项目中的 10 条设计惯例（间距、变体用法、什么情况用哪个组件）写成 Agent 可复用的指令。
- 重读三家公司的 FDE 岗位描述，标出说明岗位所属部门、级别以及需要嵌入客户多长时间的句子。

## 信源

- [Forward Deployed Engineer – Figma (Greenhouse)](https://job-boards.greenhouse.io/figma/jobs/6158162004)

- [Figma MCP server – Figma Developer Docs](https://developers.figma.com/docs/figma-mcp-server/)

- [Code Connect – Figma Developer Docs](https://developers.figma.com/docs/code-connect/)

- [Everything announced at Config 2026 – Figma Forum](https://forum.figma.com/product-updates-3/everything-announced-at-config-2026-55221)

- [Figma Launches Code Layers, Motion at Config 2026 – CMSWire](https://www.cmswire.com/digital-experience/figma-launches-code-layers-motion-at-config-2026/)

- [Summary of Figma's New Features Announced at Config 2026 – Classmethod](https://dev.classmethod.jp/en/articles/figma-config-2026-recap/)