/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}
1. 项目概述：一个绕过Figma API限制的AI设计自动化方案
如果你正在尝试用AI助手（比如Claude、Cursor）来操作Figma，大概率已经碰过壁了。官方API的调用限制，尤其是免费计划每月仅有的6次调用，让任何有意义的自动化尝试都变得不切实际。我当初也卡在这里，不想为高昂的API配额付费，但又迫切需要一种能让AI理解并操作设计稿的稳定方式。于是，我动手搭建了 figma-mcp-go 这个项目。它的核心思路非常直接：既然API的路走不通，那就绕开它。通过一个本地的Figma插件作为桥梁，让AI工具能够直接与Figma桌面应用“对话”，实现无限制的读写操作。这不仅仅是省了钱，更重要的是，它打开了一扇门，让你可以真正将“用文字描述生成设计”和“将设计稿转换为代码”这两个流程无缝串联起来，形成一个完整的设计-开发自动化闭环。
这个方案适合所有被Figma API限制困扰的开发者、设计师和产品经理。无论你是想用AI快速生成界面原型，还是希望自动从设计稿中提取设计令牌（Design Tokens）和组件信息，亦或是构建一个能够根据反馈自动调整设计稿的智能工作流， figma-mcp-go 提供的这套无限制、全功能的工具集，都能成为你工具箱里的一把利器。它本质上是一个MCP（模型上下文协议）服务器，这意味着它能与任何支持MCP的AI工具集成，将Figma变成一个可由自然语言指令驱动的“智能画板”。
2. 核心设计思路：为什么选择插件桥接方案
2.1 传统API方案的瓶颈与成本陷阱
在深入技术细节前，我们必须先理解为什么要大费周章地另辟蹊径。Figma官方提供的REST API功能强大，但它的商业模式决定了其调用限制策略。对于绝大多数个人开发者和小团队来说，我们处于“Starter”或“View & Collab”计划，每月仅有6次API调用额度。这个数字在自动化场景下几乎可以忽略不计——一次完整的页面分析可能就需要多次调用。升级到“Pro”或“Org”计划固然能获得每天200次的额度，但每个编辑器席位每月至少12美元的成本，对于实验性项目或个人使用来说，依然是一笔需要斟酌的支出。
更关键的是，这种按调用次数计费的模式，与AI辅助设计这种高频、交互式的场景存在根本性冲突。AI工具在理解、修改、生成设计稿时，可能需要连续执行数十个甚至上百个细粒度操作（例如：遍历所有文本层、调整一组元素的样式、批量创建组件）。如果每个操作都对应一次API调用，成本会迅速失控，且很容易触发速率限制。因此，依赖官方API的方案，在成本和稳定性上都无法支撑起一个可靠的、可用于生产的AI设计自动化流程。
2.2 插件桥接：实现本地无限制通信
figma-mcp-go 的核心创新在于它完全避开了云端的REST API。其架构分为两部分：
整个工作流程是这样的：AI工具发出“创建一个矩形”的指令 -> MCP服务器收到指令 -> 服务器通过WebSocket将指令转发给Figma插件 -> 插件在Figma的上下文中执行创建矩形的Figma Plugin API调用 -> 插件将执行结果通过WebSocket返回给MCP服务器 -> 服务器再将结果格式化为MCP响应，返回给AI工具。
注意 ：这里有一个关键点，所有Figma的具体操作（如 figma.createRectangle ）都是在插件上下文中执行的。Figma Plugin API本身没有调用次数限制，因为它运行在用户本地的Figma应用内。这就完美绕开了云端API的配额问题。整个通信链路（AI工具 <-> MCP服务器 <-> Figma插件）都在你的计算机内部完成，无需经过任何外部网络请求，因此也不存在网络延迟或速率限制。
2.3 方案优势与潜在考量
这种设计带来了几个显著优势：
- 零成本与无限制 ：完全免费，没有调用次数、频率或并发数的限制，你可以让AI进行任意复杂的操作序列。
- 功能完整性与实时性 ：由于直接使用Plugin API，我们几乎能实现Figma桌面端所有可通过插件实现的功能，包括一些REST API可能不支持的底层操作。并且所有操作都是实时、同步的，AI可以立即看到操作结果。
- 隐私与安全 ：所有设计数据都在本地流转，不会上传到任何第三方服务器，对于处理敏感或未发布的设计稿来说，安全性更高。
当然，这种方案也有其适用边界：
- 依赖桌面应用 ：必须运行Figma Desktop（桌面客户端），并保持其在前台打开且加载了目标设计文件。无法用于无头（Headless）或纯服务器端的自动化场景。
- 插件安装 ：需要手动安装一次插件，这对终端用户增加了一个步骤，但在安全性上反而是个优点（用户明确授权了插件访问）。
- 性能与规模 ：对于极其庞大（成千上万个节点）的文件，频繁通过插件进行大量操作可能会比优化后的批量REST API调用稍慢，但对于绝大多数常规设计稿来说，性能差异感知不强。
3. 环境配置与工具集成详解
3.1 核心组件安装与验证
开始之前，你需要确保本地环境满足两个基础条件：安装了Node.js（版本14或以上，用于运行MCP服务器）和Figma Desktop（用于运行桥接插件）。安装过程本身非常简单，但有几个细节需要注意。
首先，通过npm或npx安装MCP服务器。推荐使用
