TalkToFigma MCP：让 Cursor 通过 WebSocket 直接读写 Figma 画布

一个让 AI 直接动手改设计的 MCP 服务

大多数 AI 辅助设计工具只停留在生成建议或导出标注。TalkToFigma 走得更远，它通过 Model Context Protocol 把 Cursor、Claude Code 这类编码代理接到 Figma 画布上，让代理能读取节点信息、修改文本、调整布局、创建元素，甚至传播组件实例的覆盖。这套方案的目标用户很明确：在 Figma 里维护设计系统、同时用 AI 编码代理写前端代码的工程师。他们希望设计文件与代码实现保持同步，而不是手动复制设计 token 或逐个改文本。项目作者是 Sonny Lazuardi，仓库里没有正式 release 记录，所以它更像一个活跃的实验项目，而不是经过版本化发布的成熟产品。

三段式架构：MCP 服务器、WebSocket、Figma 插件

项目结构分成三个部分。`src/talk_to_figma_mcp/` 是 TypeScript 写的 MCP 服务器，它向 AI 代理暴露一组工具，比如 `get_selection`、`set_text_content`、`create_frame`。`src/cursor_mcp_plugin/` 是运行在 Figma 里的插件，负责实际执行画布操作。中间层是 `src/socket.ts`，一个 WebSocket 服务器，用来转发 MCP 服务器与 Figma 插件之间的消息。数据流大致是这样：代理调用 MCP 工具，MCP 服务器把请求通过 WebSocket 发给 Figma 插件，插件在 Figma 环境中完成操作并返回结果。这个设计绕过了 Figma 插件 API 对网络请求的限制，因为插件本身不能直接监听任意端口，但可以主动连接 WebSocket。代价是本地必须有一个常驻的 socket 进程，而且 Figma 插件需要手动打开并加入频道。

安装步骤与配置项：从 Bun 到 Cursor 的完整链路

README 给出了三条安装路径。快速方式是先安装 Bun，然后运行 `bun setup`，它会自动把 MCP 服务器写进 Cursor 当前项目的配置。接着运行 `bun socket` 启动 WebSocket 服务器，最后从 Figma 社区页安装插件。手动配置 Cursor 时，需要在 `~/.cursor/mcp.json` 里添加一个条目，指定命令为 `bunx`，参数为 `cursor-talk-to-figma-mcp@latest`。本地开发则把参数改成 `bun` 加上仓库里的 `src/talk_to_figma_mcp/server.ts` 路径。Figma 插件可以本地加载：选择 Plugins > Development > New Plugin，然后 Link existing plugin，指向 `src/cursor_mcp_plugin/manifest.json`。Windows 加 WSL 的用户需要修改 `src/socket.ts`，取消 `hostname: "0.0.0.0"` 的注释，否则插件无法连接。整个流程涉及三个独立进程，任何一个没启动都会导致代理操作静默失败。

工具清单：覆盖读、写、布局、组件四大类操作

MCP 服务器暴露的工具按功能分组。文档与选区类包括 `get_document_info`、`get_selection`、`read_my_design`，这些是代理理解当前画布状态的基础。文本修改类提供 `scan_text_nodes`、`set_text_content` 和 `set_multiple_text_contents`，其中扫描工具声称支持智能分块以应对大型设计。布局类工具如 `set_layout_mode`、`set_padding`、`set_item_spacing` 都针对自动布局框架，这意味着如果你的 Figma 文件没有使用 auto layout，这些工具很可能无效。样式类包括 `set_fill_color`、`set_image_fill`，后者支持本地文件路径、URL 和 base64 数据。组件类除了 `create_component_instance`，还有 `get_instance_overrides` 和 `set_instance_overrides`，用于从一个实例提取覆盖属性并批量应用到其他实例。工具数量超过三十个，但 README 没有给出每个工具的参数细节，实际使用时需要依赖 MCP 服务器返回的 schema。

批量文本替换与实例覆盖：社区贡献的真实用例

项目最吸引人的地方在于两个由社区贡献的功能。批量文本内容替换由 @dusskapark 实现，演示视频展示了如何一次性更新多个文本节点，这对本地化或内容刷新很有用。另一个功能是实例覆盖传播，同样来自 @dusskapark，它允许用户从一个源实例提取覆盖，然后应用到多个目标实例。这在设计系统里很常见：一个按钮组件在不同页面有不同文案或颜色，手动修改每个实例很繁琐，这个功能把差异提取出来再批量应用。但要注意，这些功能依赖 Figma 的组件实例机制，如果设计文件没有正确使用组件，覆盖传播就无从谈起。README 没有说明这些工具如何处理嵌套实例或变体（variants），这类复杂情况很可能需要代理自己探索节点树。

局限与失败模式：依赖网络、插件手动连接、无版本管理

这个项目有几个明显的边界。第一，它需要一个本地 WebSocket 服务器持续运行，而且 Figma 插件必须手动打开并调用 `join_channel` 加入频道，这打断了全自动流程。第二，所有操作都发生在当前打开的 Figma 文档上，如果文档没有加载，代理的读取工具会返回空或错误。第三，MCP 服务器通过 `bunx` 运行，但 socket 服务器需要单独启动，README 没有提供一键启动两个进程的脚本，容易漏掉其中一个。第四，仓库没有发布任何 release 标签，main 分支上的代码随时可能变化，依赖 `@latest` 包的用户可能遇到不兼容更新。最后，Figma 插件的权限模型是用户授予的，代理能调用的工具受限于插件在 Figma 中获得的权限，但 README 没有列出插件请求了哪些权限，这需要用户自行检查 manifest。

替代方案对比：Figma API 与官方 MCP 的差异

与 TalkToFigma 最接近的替代方案是直接使用 Figma REST API 配合自定义 MCP 服务器。Figma API 可以读取文件、获取节点信息、甚至通过 dev resources 获取样式 token，但它不能修改设计文件，只能读取。所以如果你只需要让代理理解设计，Figma API 就够了，不需要在本地跑 socket 和插件。另一个方向是 Figma 官方的插件 API，它允许修改画布，但需要人工编写插件逻辑，无法直接让代理动态调用。TalkToFigma 的独特之处在于把修改能力包装成 MCP 工具，让代理可以像调用函数一样操作画布。但这也意味着它比纯读取方案更复杂，多了一个 WebSocket 桥接层。如果你的工作流只需要设计到代码的 token 同步，用官方 API 更简单可靠；如果你需要代理实际执行设计修改，TalkToFigma 是目前少有的开源选择。

维护成本与许可证：实验性质决定升级风险

项目使用 MIT 许可证，这意味着你可以自由修改和分发，但没有任何担保。仓库没有 release 记录，最后一次推送是 2026 年 7 月，说明开发仍在进行。维护成本主要来自三方面：Bun 作为运行时不是所有团队都熟悉；WebSocket 服务器需要手动管理，没有进程守护或容器化配置；MCP 工具的参数 schema 可能随 Figma API 变化而调整，你需要关注 main 分支的提交。升级路径不清晰，因为 `bun setup` 安装的是 npm 包版本，而本地开发指向仓库源码，两者可能不同步。如果 Figma 更新了插件 API 或 MCP 协议，这个项目需要及时跟进，否则代理调用的工具可能失效。在采用前，建议检查项目的 issue 追踪器，确认最近是否有未解决的兼容性问题。

编辑结论

TalkToFigma 适合那些已经在 Figma 中建立组件库和自动布局体系、并愿意用 Cursor 或 Claude Code 驱动设计改动的团队。它不适合需要精细像素控制或离线工作的场景，因为所有操作依赖 WebSocket 连接和 Figma 插件运行。采用前应先验证三点：你的 Figma 文件是否启用了自动布局，因为多数布局工具依赖它；你的设计流程是否接受代理直接修改画布，而不是仅生成建议；以及你是否能接受 Bun 作为运行时依赖，因为 setup 和 socket 命令都基于它。项目采用 MIT 许可证，社区贡献了批量文本替换和实例覆盖传播功能，但仓库没有发布版本记录，意味着你需要从 main 分支或 npm 包获取代码，升级时需自行跟踪变更。

官方来源

1. grab/cursor-talk-to-figma-mcp on GitHub
2. Issues
3. License: MIT
4. Project website
5. README