Figma：同一个 openai，两个 Figma 技能，两种完全不同的设计哲学

给 Agent 接上 Figma，最常见的幻想是“贴个链接就出代码”。openai 在 Smithery 上发布的两个 Figma 技能，恰恰是对这个幻想最冷静的回应。figma 是其中更不起眼的一个：7,309 次浏览，26 次安装，SKILL.md 全文不到一千字。但把它读完会发现，这份短文档的价值不在教你干活，而在教你“别乱干活”。

它的定位很特别。开篇第一句就写明用 Figma MCP server 做 Figma 驱动的实现，随后是一组 Integration Rules，也就是集成规则。规则这个词用得很准，它更像一份写进 Agent 工作流的纪律清单，而不是一份操作手册。全文没有任何示例，没有分步教程，只有六条必须遵守的流程和三条资产铁律。

我最初看到这个技能的时候，默认它和同组织的 figma-implement-design 是一回事。两个链接只差一个后缀，浏览数完全一样，都是 7,309。逐条比对 SKILL.md 之后才发现，它们是同一底层的两种截然不同的产物：一个把约束写成了规则，一个把流程写成了手册。

这篇文章会拆开 openai/figma 的六条规则，讲清楚 link-based prompting 这个容易被忽略的机制，再对比它的双胞胎技能。读完你应该能判断，这种“规则集”形态的技能，到底适合谁。

使用场景

先搞清楚它解决什么问题。文档给的使用前提非常克制：Figma MCP server 必须已连接，用户提供一个 Figma 链接，或者用 figma-desktop 在桌面端直接选中节点。除此之外它默认项目已经有设计系统，原文虽然用的是 preferred，但从后面的规则看，这其实是硬前提。

这一点和 figma-implement-design 完全一致。区别在于，figma 把这些前提当成规则的一部分来陈述，而不是当成前置章节。这种写法暗示了它的真实使用场景：它不是给人点开用的独立工具，而是作为规则文件内嵌进 Agent 项目，跟 AGENTS.md、CLAUDE.md 这类项目级指令放在一起。

还有一个信号值得注意：它的 References 指向两个文件，figma-mcp-config.md 负责配置和排障，figma-tools-and-prompts.md 负责工具目录和提示模式。这说明完整内容拆进了附带的 reference，SKILL.md 本身只保留最核心的约束。这种“规则在外，细节在附”的结构，是典型的企业级技能设计。

它的输入输出契约也值得留意。输入是一个 Figma 链接，或者桌面端的一次选中，输出是落在项目里的代码改动。中间所有环节都交给 MCP 和 Agent 消化，用户不需要理解 fileKey 和 node-id 的含义。这种契约的代价是，一旦链接指向的节点变了，整个实现基础就变了，所以文档才反复强调链接必须精确到 frame 或 layer。

适用对象其实很窄。适合已经跑通 Figma MCP、有成型组件库、并且希望 Agent 每次实现都遵守同一套约定的团队。对个人开发者或设计稿还在变动期的项目，这套规则的约束力反而会变成负担。

操作流程

核心流程是六步，文档用 do not skip 标成强制。第一步先跑 get_design_context，拿目标节点的结构化表示。这份数据至少覆盖五个维度：

• 布局属性：Auto Layout、约束与尺寸
• 排版规格：字体、字号、字重与行高
• 颜色值与设计 token
• 组件结构与变体
• 间距与内边距

这是唯一入口，文档明确说 never implement based on assumptions，不许基于假设动手。开工前先把数据拿全，比写到一半发现取不到数要省事得多。

第二步是处理数据过载。设计复杂时返回内容会被截断，解法是先跑 get_metadata 拿高层节点地图，定位需要的子节点，再逐个用 get_design_context 单独拉取。这个设计把“数据太大”从死结变成了可管理的操作，比一次硬拉全量数据聪明得多。

第三步是 get_screenshot，用同样的 fileKey 和 nodeId 生成视觉参考，文档称它是验证的真相源。第四步下载资源，这里藏着全文最硬的几条规则：MCP 返回 localhost 地址的图片或 SVG 就直接用，禁止引入新的图标包，禁止在提供了 localhost 源的情况下造占位符。三条规则同一个目的，防止 AI 自作主张替换设计资产。

第五步是翻译。Figma MCP 的默认输出通常是 React 加 Tailwind，文档明确说这只是设计的表示，不是最终代码风格。要把工具类换成项目自己的 token，复用已有组件，尊重项目现有的路由、状态管理和数据请求模式。第六步验证，对照截图逐项核对 1:1 的视觉和行为一致性。

翻译这一步的细节其实比看起来更讲究。文档要求先检查项目里有没有现成的按钮、输入框、图标包装组件，有就扩展新变体，没有才新建。它还要求把 Figma 的颜色映射到项目的 token 体系，比如 primary-500 这种命名，而不是直接复制十六进制色值。这两条规则合在一起，目标只有一个：让实现结果长得像这个项目自己的代码，而不是一份 Figma 生成的孤儿组件。

这六步里最独特的是文档反复强调的 link-based prompting。用法是复制 Figma 的 frame 或 layer 链接直接交给 MCP client，client 自己从 URL 里提取 node ID。文档还提醒，client 无法浏览 URL 本身，所以链接必须精确指向目标节点。这意味着整个技能的输入契约就是一个链接，成本低到极致。

洞察与反思

从文档推断，openai/figma 的设计哲学可以概括成一句话：先约束，再生成。六条规则里没有一条在教怎么写代码，全部在管“动手之前必须拿到什么、动手时不许替换什么、收尾时拿什么验证”。对 Agent 编码而言，生成能力从来不稀缺，稀缺的是对设计资产和项目约定的尊重。

link-based prompting 这个机制值得单独说。它把 MCP 的调用参数全部藏进了链接解析，用户不用记 fileKey 和 node-id 的格式，Agent 也不用手动拼参数。这层抽象让技能的使用成本降到了“发一个链接”这么低。从架构看，解析职责被放在了 client 侧，server 保持无状态，职责切分很干净。

把它和 figma-implement-design 放在一起看，对比尤其有意思。两个技能同属 openai，浏览数相同，但 figma-implement-design 有 30 次安装，是完整的工作流手册，含 7 步流程、双示例、最佳实践和常见问题清单。figma 只有 26 次安装，是精简的规则集。第三方技能评分站点 implexa 给两者的 SkillRank 分别是 6.3 和 8.3，差距主要来自完整度。

这背后其实是两种技能设计哲学：figma-implement-design 选择把一切讲清楚，降低使用者的理解成本；figma 选择把规则压到最薄，让 Agent 项目能直接内嵌。前者的读者是人，后者的读者是 Agent。同一份 Figma MCP 能力，一个写成教程，一个写成制度。

还有一个值得琢磨的细节：这些规则写给 Agent 读，但写得很像给人看的制度。文档用了 do not skip、IMPORTANT 这样的强标记，资产规则还连着三条 IMPORTANT 压阵。对 Agent 而言，重复和强调确实比温和建议有效，但对阅读它的人类开发者来说，这种写法也把优先级传达得明明白白。一份规则同时服务两种读者，这在技能文档里不多见。

局限也摆在明面上。26 次安装说明它远未成熟，规则有效性完全依赖 Figma MCP server 的稳定性，而配置和排障都藏在附带的 reference 文件里，不读那些文件，规则集就是空中楼阁。此外，它默认团队已有设计系统，这对组件库刚起步的团队基本等于没写。

还有一点容易被忽略：这套规则其实默认了输出语言。文档里反复出现 React 加 Tailwind 的字样，说明它是在一个具体的实现栈上沉淀出来的。如果你的项目用 Vue、Svelte 或者别的方案，规则依然成立，但你需要自己在翻译步骤里补上对应框架的约定。这既是限制，也是它真实用过的证据。

资源地址

总结

回头看，openai/figma 的价值不在功能，在姿态。它默认 Agent 会认真执行规则，所以每条规则都写得像军规：

• 不许猜：先拿 context 再动手
• 不许换：资产直用 localhost 源
• 不许占位：有源就不造占位符
• 必须验证：对照截图收口

这种信任假设本身就是一种设计选择，也解释了为什么它是规则集而不是教程。

如果你维护 Agent 项目，并且团队已经有 Figma MCP 和组件库，把它内嵌进项目规则文件试一轮，成本很低。如果你连 MCP 都还没接，那它对你的意义就是一份别人踩过坑之后的纪律清单，比流程本身更值得抄。

设计到代码的鸿沟，figma 的答案不是更聪明的生成，而是更严格的纪律。这句话，比这个技能本身更能代表 openai 的态度。