1. 为什么要在 Cursor 里接 Figma设计稿到代码的断点在哪如果你平时用 Cursor 写前端大概率遇到过这种场景产品丢过来一个 Figma 链接你打开一看间距、圆角、阴影、字体层级全在画板上但落到代码里还是得靠肉眼量、手动抄。抄错一个padding就要来回对三遍改到后面自己都烦。Figma 配置 MCP 服务这件事本质就是把这个「肉眼量」的环节交给模型。MCP 全称 Model Context Protocol你可以把它理解成 Cursor 和外部工具之间的一条标准数据通道。Cursor 本身不会读 Figma 文件但通过一个跑在本地的 MCP 服务它就能拿到当前选中画板的节点信息、样式、层级结构然后按你的项目规范生成代码。这套流程适合谁我总结下来是三类人一是经常接设计稿的前端二是做设计系统、组件库的同学三是想用 AI 批量把画板转成页面骨架的人。不适合谁如果你的项目根本没有设计稿或者设计稿是随手画的草图那接进来意义不大模型拿到的信息本身就是乱的。这里要区分两个东西很多人第一次配会搞混。Figma 官方在 Cursor 的 Plugins 里提供了一个在线 MCP走的是 Figma 云端接口适合 Web 端设计稿而cursor-talk-to-figma-mcp是本地插件方案需要在 Figma 桌面端手动导入manifest.json通过本地 WebSocket 通信。两者不是替代关系是互补关系。本地这套的好处是能直接操作当前打开的文档响应更快也能配合 Skills 和 Rules 做更细的控制。我试过把两种方式混着用结果 Cursor 里同时出现两个 Figma 相关的 MCP模型会犹豫该调哪个。所以建议先明确你要的是本地实时读取还是云端链接解析。本文聚焦本地这套也就是manifest.json Bun Cursor 的完整链路。整个链路里有三个关键角色。Figma 桌面端负责加载插件、暴露当前文档Bun 负责跑cursor-talk-to-figma-mcp这个服务它启动后会开一个 WebSocket 端口并生成一个 channel 随机码Cursor 通过 MCP 配置连到这个本地服务拿到工具能力后就能读取设计数据。三者缺一不可而且顺序不能乱——先起服务再连 Cursor最后在 Figma 里确认插件弹窗还开着。理解了这条链路后面配置时遇到报错你就能自己定位是哪一环断了。比如 Cursor 里报连接失败可能是 Bun 服务没起Figma 里读不到数据可能是插件弹窗被关了导致随机码失效。下面按顺序把每一步拆开。2. 前置准备Bun 运行时与 cursor-talk-to-figma-mcp 环境搭建在写manifest.json之前得先把运行环境弄好。这套方案依赖 Bun不是 Node。Bun 是一个现代化的 JavaScript/TypeScript 运行时你可以把它当成 Node 的更快替代品它把运行时、包管理器、打包器都集成在一起了。cursor-talk-to-figma-mcp的setup和socket脚本都是按 Bun 写的用 Node 跑会出各种模块解析问题。安装 Bun 分平台。macOS 和 Linux 通用的一键脚本是curl -fsSL https://bun.sh/install | bashmacOS 如果你习惯 Homebrew也可以走官方仓库brew tap oven-sh/bun brew install bunWindows 用户注意官方推荐在 WSL 里跑上面那条 curl 脚本直接在 PowerShell 里执行 bash 脚本会失败。装完验证一下bun --version能打印出版本号比如1.1.x就说明运行时没问题。这里有个坑我踩过如果你机器上装了 nvm并且切过多个 Node 版本用npm install -g bun装出来的 Bun 有时会因为 PATH 指向旧 Node 的 bin 目录而不生效。表现是bun --version报 command not found或者版本号对不上。解决办法是优先用 curl 脚本装装完source ~/.bashrc或重开终端让 PATH 刷新。环境好了之后克隆项目git clone gitgithub.com:grab/cursor-talk-to-figma-mcp.git cd cursor-talk-to-figma-mcp如果你没配 SSH key用 HTTPS 也行但原作者提到 HTTP 克隆有时拉不下来我实测用 SSH 更稳。克隆完进目录执行初始化bun setup这一步会自动装依赖并且帮你生成.cursor/mcp.json的初始内容。注意它生成的是给 Cursor 用的 MCP 配置模板不是 Figma 的manifest.json两者别搞混。manifest.json在项目的src/cursor_mcp_plugin目录下是给 Figma 导入插件用的。初始化完成后启动 WebSocket 服务bun socket终端会打印出端口号和 channel 随机码类似3055和o3jmymg2。这两个值先记下来后面 Cursor 配置和 Figma 验证都要用。这个服务一旦启动就不能关关了 Cursor 那边立刻断连。建议单独开一个终端窗口挂着别和 Cursor 共用一个。到这一步Bun 环境、项目依赖、本地服务三样都齐了。接下来才是写manifest.json和导入 Figma。3. 可复制配置manifest.json 模板与 Cursor MCP 接入片段这一节是全文最核心的部分配置写错一个字就连不上。先看 Figma 侧的manifest.json。这个文件在cursor-talk-to-figma-mcp/src/cursor_mcp_plugin/manifest.json正常情况下克隆下来就已经存在你不需要从零写。但如果你要改插件名、改 ID或者想理解每个字段的作用可以对照下面这份模板{ name: Cursor MCP Plugin, id: cursor-mcp-plugin-local, api: 1.0.0, main: code.js, ui: ui.html, editorType: [figma], networkAccess: { allowedDomains: [*], reasoning: Local WebSocket communication with cursor-talk-to-figma-mcp } }几个字段说明一下。name是插件在 Figma 里显示的名字随便改不影响功能。id是插件唯一标识本地开发用任意字符串即可不要和已发布的插件冲突。main和ui分别指向插件的逻辑文件和界面文件这两个文件名必须和目录里实际文件一致改错会导入失败。editorType限定只在 Figma 里可用。networkAccess是较新版本 Figma 插件必须声明的字段因为本地 MCP 要走 WebSocket所以allowedDomains给*reasoning写清楚用途否则 Figma 会拦截网络请求。导入方式打开 Figma 桌面端顶部菜单Plugins→Development→Import plugin from manifest...然后在文件选择框里导航到src/cursor_mcp_plugin目录选中manifest.json。导入成功后 Figma 会弹出一个插件窗口窗口里会显示当前连接的 channel 随机码。这里有个必须强调的点这个弹窗不能关。随机码是动态生成的关掉再开就变了Cursor 那边拿的是旧码直接连接超时。我见过有人嫌弹窗挡视线随手关了然后排查半天以为是配置问题。再看 Cursor 侧的 MCP 配置。bun setup会生成.cursor/mcp.json内容大致如下你可以直接复制{ mcpServers: { cursor-talk-to-figma: { command: bun, args: [run, socket], cwd: /你的绝对路径/cursor-talk-to-figma-mcp } } }三个关键点。command必须是bun不是node。args是[run, socket]对应项目里的启动脚本。cwd要填你本地项目的绝对路径Windows 下路径分隔符用双反斜杠或正斜杠别直接粘单反斜杠。如果你不想让 Cursor 自己拉起服务而是手动bun socket已经跑着那这段配置也可以改成连接已存在的服务但最简单的方式还是让 Cursor 托管。配置写完后在 Cursor 里点Tools MCP再点New MCP Server把上面这段 JSON 粘进去或者直接编辑.cursor/mcp.json后重启 Cursor。Cursor 会尝试启动这个 MCP 服务状态变成绿色或显示已连接就对了。如果你同时要用 Figma 官方在线 MCP可以在 Plugins 里单独配置它和本地这套不冲突但建议一次只启用一个避免模型调用时选错工具。官方那套走的是链接解析本地这套走的是当前文档实时读取用途不同。配置阶段最容易出问题的是路径和运行时。路径写错Cursor 启动服务时直接报找不到目录运行时写成 node会报模块解析失败。这两类错误在下一节验证时都会具体讲。4. 验证请求从 Cursor 读取 Figma 文档信息确认连通配置写完不代表通了得实际发一次请求验证。验证的目标很简单让 Cursor 通过 MCP 读到当前 Figma 文档的信息如果返回了你画板里的内容说明整条链路是通的。操作顺序很重要。先确认bun socket服务在跑终端里能看到端口和 channel。然后确认 Figma 桌面端里那个插件弹窗还开着弹窗上显示的 channel 和终端里的一致。最后回到 Cursor在对话里输入类似这样的指令获取当前 Figma 文档信息如果一切正常Cursor 会调用 MCP 工具返回类似Connected to server in channel: o3jmymg2的提示后面跟着你当前 Figma 文档的节点信息、画板名称、图层结构等。看到这些内容就证明 Cursor 已经能读到设计数据了。这里有个细节channel 随机码一定要对上。终端里是o3jmymg2Figma 弹窗里也必须是o3jmymg2Cursor 返回里出现的也应该是同一个。三者不一致说明某一环拿的是旧码最常见的原因是 Figma 弹窗被关过又重新打开或者bun socket重启过但 Cursor 没重新连。验证通过后你可以进一步测试读取具体画板。比如在 Figma 里选中一个画板然后在 Cursor 里说「读取当前选中的画板样式」模型会返回该画板的尺寸、填充、圆角、字体等信息。这一步能过说明数据通道不仅通了还能定位到具体节点。如果返回的是空或者报错先别急着改配置按这个顺序排查一看bun socket终端有没有报错日志二看 Figma 弹窗是否还在、channel 是否一致三看 Cursor 的 MCP 状态是不是已连接。大部分问题出在前两步。验证成功后建议马上加两个约束文件不然模型容易乱来。一个是 Skills用来告诉模型处理 Figma 时的行为规范--- name: Figma UI description: 配合 Figma 使用的技能当用户使用 Figma 时触发 --- 1. 严格按照设计稿写代码 2. 根据项目结构增加页面不能随意发挥 3. 严格按照设计稿尺寸实现兼容不同屏幕 4. 遇到疑问先询问用户确认后再执行另一个是 Rules防止模型反向修改设计稿--- name: Figma Rule description: 严格限制 Figma 使用范围 --- 1. 禁止通过 Cursor 修改 Figma 设计稿 2. 禁止在 Figma 连接失败或未连接时自行设计 UI这两个文件放在项目的.cursor/rules或对应目录下Cursor 会自动加载。加完之后模型在读取设计稿时会遵守你的约束不会出现「设计稿没连上就自己画一个」的情况。5. 常见报错排查401、local proxy failed、reading choices 与 OAuth配置过程中报错是常态这一节把几个高频错误对照着讲方便你快速定位。401 Unauthorized。这个通常出现在你用了 Figma 官方在线 MCP 但没登录账号或者 token 过期。本地这套cursor-talk-to-figma-mcp一般不会报 401因为它走的是本地 WebSocket不涉及云端鉴权。如果你在 Cursor 里看到 401先确认当前调用的是哪个 MCP。如果是官方那套去 Cursor 的 Plugins 里重新登录 Figma 账号即可。local proxy failed。这个报错说明 Cursor 尝试启动 MCP 服务时失败了。常见原因有三个一是cwd路径写错Cursor 找不到项目目录二是command写成了node而不是bun三是 Bun 没装好或 PATH 不对。排查方法是在终端里手动进到项目目录执行bun run socket如果手动能跑起来说明是 Cursor 配置里的路径或命令有问题如果手动也跑不起来那是 Bun 环境的问题。reading choices。这个报错一般出现在模型调用返回结构异常时本质是 MCP 返回的数据格式和 Cursor 预期的不一致。常见触发场景是bun socket服务中途挂了Cursor 还在等响应拿到空数据后解析失败。解决办法是重启bun socket然后在 Cursor 里重新发起请求。如果反复出现检查项目依赖是否装全重新跑一次bun setup。OAuth 相关报错。这个主要出现在官方在线 MCP 的授权流程里。本地这套不涉及 OAuth。如果你看到 OAuth 报错说明你在用官方 MCP需要去 Figma 账号设置里重新授权或者在 Cursor 的 Plugins 面板里退出重登。除了这些还有两个非报错但很坑的现象。一是 Figma 弹窗被关随机码刷新Cursor 那边一直超时表现是请求发出去没反应。二是bun socket服务被终止比如你关了那个终端窗口Cursor 立刻断连。这两个都不是配置错误是运行状态问题保持服务和弹窗常开就行。另外提一下模型选择。Cursor 里如果选 Auto 模型遇到 Figma 这种需要多步工具调用的任务Auto 有时会判断「需求太大」而拒绝执行。建议手动选一个支持工具调用的模型比如 Composer 2 Fast实测响应比较快也能正常走 MCP 调用链。排查时养成看日志的习惯。bun socket终端会打印连接、断开、消息收发记录Cursor 的 MCP 面板也会显示服务状态。两边对照着看基本能定位到是哪一环断了。6. 长期使用建议把 Figma 接入纳入日常编码流配置跑通只是开始真正有价值的是把它变成日常习惯。我自己的做法是固定一套启动顺序先开 Figma 桌面端并导入插件再开终端跑bun socket最后开 Cursor 确认 MCP 已连接。三步都绿了再开始干活避免中途断连返工。如果你经常做「设计稿转代码」可以配合 Cursor 的 Plugins 里 Figma 官方提供的三个能力用。implement-design负责把画板落成代码流程是解析链接、拿设计上下文、截图、处理资源、按设计实现code-connect-components用 Code Connect 把 Figma 组件和真实代码组件对应起来适合组件库维护create-design-system-rules能为你的仓库生成设计系统规则让生成结果更贴合技术栈。这三个能力可以在 Plugins 面板里按账号启用和本地 MCP 配合使用。对于需要长期跑 Agent 任务、频繁调用模型做设计稿解析的场景可以考虑用 Coding Plan 这类按量方案比单次调用更划算适合把 Figma 接入纳入固定工作流的团队。日常只是偶尔转一两个页面的话按需调用就够了。最后留一个实用技巧把常用的 Figma 操作指令存成 Cursor 的快捷提示比如「读取当前画板并生成 React 组件」「对比设计稿和现有代码的样式差异」。这样每次不用重新组织语言直接调用效率会高很多。设计稿和代码之间的那道手工鸿沟配好这套之后基本就填平了。 
长河君 · 2026/10/7 7:19:20 · 阅读 1.2k Figma 配置 MCP 服务：manifest.json 与 Bun 环境下的 Cursor 接入实践
1. 为什么要在 Cursor 里接 Figma设计稿到代码的断点在哪如果你平时用 Cursor 写前端大概率遇到过这种场景产品丢过来一个 Figma 链接你打开一看间距、圆角、阴影、字体层级全在画板上但落到代码里还是得靠肉眼量、手动抄。抄错一个padding就要来回对三遍改到后面自己都烦。Figma 配置 MCP 服务这件事本质就是把这个「肉眼量」的环节交给模型。MCP 全称 Model Context Protocol你可以把它理解成 Cursor 和外部工具之间的一条标准数据通道。Cursor 本身不会读 Figma 文件但通过一个跑在本地的 MCP 服务它就能拿到当前选中画板的节点信息、样式、层级结构然后按你的项目规范生成代码。这套流程适合谁我总结下来是三类人一是经常接设计稿的前端二是做设计系统、组件库的同学三是想用 AI 批量把画板转成页面骨架的人。不适合谁如果你的项目根本没有设计稿或者设计稿是随手画的草图那接进来意义不大模型拿到的信息本身就是乱的。这里要区分两个东西很多人第一次配会搞混。Figma 官方在 Cursor 的 Plugins 里提供了一个在线 MCP走的是 Figma 云端接口适合 Web 端设计稿而cursor-talk-to-figma-mcp是本地插件方案需要在 Figma 桌面端手动导入manifest.json通过本地 WebSocket 通信。两者不是替代关系是互补关系。本地这套的好处是能直接操作当前打开的文档响应更快也能配合 Skills 和 Rules 做更细的控制。我试过把两种方式混着用结果 Cursor 里同时出现两个 Figma 相关的 MCP模型会犹豫该调哪个。所以建议先明确你要的是本地实时读取还是云端链接解析。本文聚焦本地这套也就是manifest.json Bun Cursor 的完整链路。整个链路里有三个关键角色。Figma 桌面端负责加载插件、暴露当前文档Bun 负责跑cursor-talk-to-figma-mcp这个服务它启动后会开一个 WebSocket 端口并生成一个 channel 随机码Cursor 通过 MCP 配置连到这个本地服务拿到工具能力后就能读取设计数据。三者缺一不可而且顺序不能乱——先起服务再连 Cursor最后在 Figma 里确认插件弹窗还开着。理解了这条链路后面配置时遇到报错你就能自己定位是哪一环断了。比如 Cursor 里报连接失败可能是 Bun 服务没起Figma 里读不到数据可能是插件弹窗被关了导致随机码失效。下面按顺序把每一步拆开。2. 前置准备Bun 运行时与 cursor-talk-to-figma-mcp 环境搭建在写manifest.json之前得先把运行环境弄好。这套方案依赖 Bun不是 Node。Bun 是一个现代化的 JavaScript/TypeScript 运行时你可以把它当成 Node 的更快替代品它把运行时、包管理器、打包器都集成在一起了。cursor-talk-to-figma-mcp的setup和socket脚本都是按 Bun 写的用 Node 跑会出各种模块解析问题。安装 Bun 分平台。macOS 和 Linux 通用的一键脚本是curl -fsSL https://bun.sh/install | bashmacOS 如果你习惯 Homebrew也可以走官方仓库brew tap oven-sh/bun brew install bunWindows 用户注意官方推荐在 WSL 里跑上面那条 curl 脚本直接在 PowerShell 里执行 bash 脚本会失败。装完验证一下bun --version能打印出版本号比如1.1.x就说明运行时没问题。这里有个坑我踩过如果你机器上装了 nvm并且切过多个 Node 版本用npm install -g bun装出来的 Bun 有时会因为 PATH 指向旧 Node 的 bin 目录而不生效。表现是bun --version报 command not found或者版本号对不上。解决办法是优先用 curl 脚本装装完source ~/.bashrc或重开终端让 PATH 刷新。环境好了之后克隆项目git clone gitgithub.com:grab/cursor-talk-to-figma-mcp.git cd cursor-talk-to-figma-mcp如果你没配 SSH key用 HTTPS 也行但原作者提到 HTTP 克隆有时拉不下来我实测用 SSH 更稳。克隆完进目录执行初始化bun setup这一步会自动装依赖并且帮你生成.cursor/mcp.json的初始内容。注意它生成的是给 Cursor 用的 MCP 配置模板不是 Figma 的manifest.json两者别搞混。manifest.json在项目的src/cursor_mcp_plugin目录下是给 Figma 导入插件用的。初始化完成后启动 WebSocket 服务bun socket终端会打印出端口号和 channel 随机码类似3055和o3jmymg2。这两个值先记下来后面 Cursor 配置和 Figma 验证都要用。这个服务一旦启动就不能关关了 Cursor 那边立刻断连。建议单独开一个终端窗口挂着别和 Cursor 共用一个。到这一步Bun 环境、项目依赖、本地服务三样都齐了。接下来才是写manifest.json和导入 Figma。3. 可复制配置manifest.json 模板与 Cursor MCP 接入片段这一节是全文最核心的部分配置写错一个字就连不上。先看 Figma 侧的manifest.json。这个文件在cursor-talk-to-figma-mcp/src/cursor_mcp_plugin/manifest.json正常情况下克隆下来就已经存在你不需要从零写。但如果你要改插件名、改 ID或者想理解每个字段的作用可以对照下面这份模板{ name: Cursor MCP Plugin, id: cursor-mcp-plugin-local, api: 1.0.0, main: code.js, ui: ui.html, editorType: [figma], networkAccess: { allowedDomains: [*], reasoning: Local WebSocket communication with cursor-talk-to-figma-mcp } }几个字段说明一下。name是插件在 Figma 里显示的名字随便改不影响功能。id是插件唯一标识本地开发用任意字符串即可不要和已发布的插件冲突。main和ui分别指向插件的逻辑文件和界面文件这两个文件名必须和目录里实际文件一致改错会导入失败。editorType限定只在 Figma 里可用。networkAccess是较新版本 Figma 插件必须声明的字段因为本地 MCP 要走 WebSocket所以allowedDomains给*reasoning写清楚用途否则 Figma 会拦截网络请求。导入方式打开 Figma 桌面端顶部菜单Plugins→Development→Import plugin from manifest...然后在文件选择框里导航到src/cursor_mcp_plugin目录选中manifest.json。导入成功后 Figma 会弹出一个插件窗口窗口里会显示当前连接的 channel 随机码。这里有个必须强调的点这个弹窗不能关。随机码是动态生成的关掉再开就变了Cursor 那边拿的是旧码直接连接超时。我见过有人嫌弹窗挡视线随手关了然后排查半天以为是配置问题。再看 Cursor 侧的 MCP 配置。bun setup会生成.cursor/mcp.json内容大致如下你可以直接复制{ mcpServers: { cursor-talk-to-figma: { command: bun, args: [run, socket], cwd: /你的绝对路径/cursor-talk-to-figma-mcp } } }三个关键点。command必须是bun不是node。args是[run, socket]对应项目里的启动脚本。cwd要填你本地项目的绝对路径Windows 下路径分隔符用双反斜杠或正斜杠别直接粘单反斜杠。如果你不想让 Cursor 自己拉起服务而是手动bun socket已经跑着那这段配置也可以改成连接已存在的服务但最简单的方式还是让 Cursor 托管。配置写完后在 Cursor 里点Tools MCP再点New MCP Server把上面这段 JSON 粘进去或者直接编辑.cursor/mcp.json后重启 Cursor。Cursor 会尝试启动这个 MCP 服务状态变成绿色或显示已连接就对了。如果你同时要用 Figma 官方在线 MCP可以在 Plugins 里单独配置它和本地这套不冲突但建议一次只启用一个避免模型调用时选错工具。官方那套走的是链接解析本地这套走的是当前文档实时读取用途不同。配置阶段最容易出问题的是路径和运行时。路径写错Cursor 启动服务时直接报找不到目录运行时写成 node会报模块解析失败。这两类错误在下一节验证时都会具体讲。4. 验证请求从 Cursor 读取 Figma 文档信息确认连通配置写完不代表通了得实际发一次请求验证。验证的目标很简单让 Cursor 通过 MCP 读到当前 Figma 文档的信息如果返回了你画板里的内容说明整条链路是通的。操作顺序很重要。先确认bun socket服务在跑终端里能看到端口和 channel。然后确认 Figma 桌面端里那个插件弹窗还开着弹窗上显示的 channel 和终端里的一致。最后回到 Cursor在对话里输入类似这样的指令获取当前 Figma 文档信息如果一切正常Cursor 会调用 MCP 工具返回类似Connected to server in channel: o3jmymg2的提示后面跟着你当前 Figma 文档的节点信息、画板名称、图层结构等。看到这些内容就证明 Cursor 已经能读到设计数据了。这里有个细节channel 随机码一定要对上。终端里是o3jmymg2Figma 弹窗里也必须是o3jmymg2Cursor 返回里出现的也应该是同一个。三者不一致说明某一环拿的是旧码最常见的原因是 Figma 弹窗被关过又重新打开或者bun socket重启过但 Cursor 没重新连。验证通过后你可以进一步测试读取具体画板。比如在 Figma 里选中一个画板然后在 Cursor 里说「读取当前选中的画板样式」模型会返回该画板的尺寸、填充、圆角、字体等信息。这一步能过说明数据通道不仅通了还能定位到具体节点。如果返回的是空或者报错先别急着改配置按这个顺序排查一看bun socket终端有没有报错日志二看 Figma 弹窗是否还在、channel 是否一致三看 Cursor 的 MCP 状态是不是已连接。大部分问题出在前两步。验证成功后建议马上加两个约束文件不然模型容易乱来。一个是 Skills用来告诉模型处理 Figma 时的行为规范--- name: Figma UI description: 配合 Figma 使用的技能当用户使用 Figma 时触发 --- 1. 严格按照设计稿写代码 2. 根据项目结构增加页面不能随意发挥 3. 严格按照设计稿尺寸实现兼容不同屏幕 4. 遇到疑问先询问用户确认后再执行另一个是 Rules防止模型反向修改设计稿--- name: Figma Rule description: 严格限制 Figma 使用范围 --- 1. 禁止通过 Cursor 修改 Figma 设计稿 2. 禁止在 Figma 连接失败或未连接时自行设计 UI这两个文件放在项目的.cursor/rules或对应目录下Cursor 会自动加载。加完之后模型在读取设计稿时会遵守你的约束不会出现「设计稿没连上就自己画一个」的情况。5. 常见报错排查401、local proxy failed、reading choices 与 OAuth配置过程中报错是常态这一节把几个高频错误对照着讲方便你快速定位。401 Unauthorized。这个通常出现在你用了 Figma 官方在线 MCP 但没登录账号或者 token 过期。本地这套cursor-talk-to-figma-mcp一般不会报 401因为它走的是本地 WebSocket不涉及云端鉴权。如果你在 Cursor 里看到 401先确认当前调用的是哪个 MCP。如果是官方那套去 Cursor 的 Plugins 里重新登录 Figma 账号即可。local proxy failed。这个报错说明 Cursor 尝试启动 MCP 服务时失败了。常见原因有三个一是cwd路径写错Cursor 找不到项目目录二是command写成了node而不是bun三是 Bun 没装好或 PATH 不对。排查方法是在终端里手动进到项目目录执行bun run socket如果手动能跑起来说明是 Cursor 配置里的路径或命令有问题如果手动也跑不起来那是 Bun 环境的问题。reading choices。这个报错一般出现在模型调用返回结构异常时本质是 MCP 返回的数据格式和 Cursor 预期的不一致。常见触发场景是bun socket服务中途挂了Cursor 还在等响应拿到空数据后解析失败。解决办法是重启bun socket然后在 Cursor 里重新发起请求。如果反复出现检查项目依赖是否装全重新跑一次bun setup。OAuth 相关报错。这个主要出现在官方在线 MCP 的授权流程里。本地这套不涉及 OAuth。如果你看到 OAuth 报错说明你在用官方 MCP需要去 Figma 账号设置里重新授权或者在 Cursor 的 Plugins 面板里退出重登。除了这些还有两个非报错但很坑的现象。一是 Figma 弹窗被关随机码刷新Cursor 那边一直超时表现是请求发出去没反应。二是bun socket服务被终止比如你关了那个终端窗口Cursor 立刻断连。这两个都不是配置错误是运行状态问题保持服务和弹窗常开就行。另外提一下模型选择。Cursor 里如果选 Auto 模型遇到 Figma 这种需要多步工具调用的任务Auto 有时会判断「需求太大」而拒绝执行。建议手动选一个支持工具调用的模型比如 Composer 2 Fast实测响应比较快也能正常走 MCP 调用链。排查时养成看日志的习惯。bun socket终端会打印连接、断开、消息收发记录Cursor 的 MCP 面板也会显示服务状态。两边对照着看基本能定位到是哪一环断了。6. 长期使用建议把 Figma 接入纳入日常编码流配置跑通只是开始真正有价值的是把它变成日常习惯。我自己的做法是固定一套启动顺序先开 Figma 桌面端并导入插件再开终端跑bun socket最后开 Cursor 确认 MCP 已连接。三步都绿了再开始干活避免中途断连返工。如果你经常做「设计稿转代码」可以配合 Cursor 的 Plugins 里 Figma 官方提供的三个能力用。implement-design负责把画板落成代码流程是解析链接、拿设计上下文、截图、处理资源、按设计实现code-connect-components用 Code Connect 把 Figma 组件和真实代码组件对应起来适合组件库维护create-design-system-rules能为你的仓库生成设计系统规则让生成结果更贴合技术栈。这三个能力可以在 Plugins 面板里按账号启用和本地 MCP 配合使用。对于需要长期跑 Agent 任务、频繁调用模型做设计稿解析的场景可以考虑用 Coding Plan 这类按量方案比单次调用更划算适合把 Figma 接入纳入固定工作流的团队。日常只是偶尔转一两个页面的话按需调用就够了。最后留一个实用技巧把常用的 Figma 操作指令存成 Cursor 的快捷提示比如「读取当前画板并生成 React 组件」「对比设计稿和现有代码的样式差异」。这样每次不用重新组织语言直接调用效率会高很多。设计稿和代码之间的那道手工鸿沟配好这套之后基本就填平了。