灰色小熊做前端的都知道，设计稿还原这件事，大头从来不是写代码本身，而是那些“看稿”的功夫——量一下间距、取个色值、确认字号字重，一个页面几十个区块，每个区块翻来覆去地核对，一上午就没了。我之前接过一个后台管理系统，设计稿里光按钮就十几种状态，手动对着 Figma 抠了一整天，改完一核对，还有三处字体粗细不对。后来我把 Cursor 和 Figma MCP 这套工作流完整跑通了，效果确实比我预期好不少——不是它把所有事都干完了，而是把“看稿”这件最耗体力的事交给工具了。这篇文章就把完整流程、踩过的坑、以及哪些环节必须人工介入，一次性讲清楚。
1. 设计稿还原为什么难：先搞清楚误差到底出在哪一环
1.1 传统还原流程里的三处信息损耗
手动还原设计稿这件事，表面看是“照着稿子写代码”，但真正干过的人都知道，误差不是写代码那一步产生的，而是从“看稿”到“动手”这个过程中就已经丢了信息。
第一处损耗在看标注。设计师在 Figma 里拖一个矩形，它的 x、y 坐标、宽高、圆角、填充色、阴影参数，这些数据在设计稿里是精确到一个像素的。但人眼去读这些信息的时候，经常是量个大概——间距是 16px 还是 18px，有时候真分不出来。等代码写出来，视觉上看着没差多少，但严格一比，就是差那 2 个像素。单个区块差 2px 看不出问题，一整个页面几十个区块叠起来，那种“说不出来哪里不对，但就是不像原稿”的感觉就来了。
第二处损耗在切图。老一套流程里，图标、背景图、插画都要从 Figma 里手动导出来，导完还得压缩、换格式、放到项目目录里，再在代码里引用路径。这个环节最容易出问题的不是技术，而是版本管理——设计师改了一版设计稿，你切好的图还在用旧版本，等发现的时候页面已经快做完了，只能回头重来。
第三处损耗在沟通。前端问设计师“这个按钮 hover 状态是什么颜色”，设计师说“你自己试一下”，或者“跟别的页面统一就行”。这种模糊地带多了，还原度就是一笔糊涂账。归根结底，手动还原是把一个“数据精确”的设计稿，通过人眼转成了“大概准确”的代码。
1.2 Figma 文件本身就是数据，MCP 是把数据递给 AI 的那只手
Figma 和普通的图片稿不一样，它的文件本质是一棵结构化的节点树。每个节点都有完整的样式属性——宽高、坐标、填充、描边、圆角、字体、行高、自动布局方向、间距、响应式约束，全部以 JSON 的形式存在。也就是说，“像素级还原”所需要的全部信息，设计稿里早就有，缺的只是怎么把这些数据喂给写代码的工具。
过去这个环节靠人肉读取，现在有了 MCP，流程就变了。MCP（Model Context Protocol）是一个开放协议，解决的是“AI 模型怎么安全地调用外部工具和数据”的问题。拿 Figma MCP 来说，它起的作用是中间人——Cursor 通过 MCP 协议向本地运行的 Figma MCP Server 发起请求，MCP Server 拿着你配置的 API Token 去访问 Figma 的文件数据，然后把结构化的节点信息返回给 Cursor。整套链路里，Cursor 拿到的不再是一张截图让它“猜”，而是设计稿的精确尺寸、颜色值、字体信息。
这就是为什么“像素级还原”这件事，搭配 MCP 比纯靠 AI 识图要靠谱得多。AI 看截图，本质上还是在猜，图被缩放一下、压缩一点，识别出来的数值就变了。但走 MCP 拿数据，是多少就是多少，设计稿标 16px，代码里就是 16px，不存在“猜”的环节。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手配置：给 Cursor 接上 Figma 的“数据源”
2.1 第一步：生成 Figma 只读 Token
配置 MCP 之前，先解决身份认证的问题。Figma API 的访问凭证是 Personal Access Token，在 Figma 网页端右上角头像菜单里找到 Settings，切换到 Security 标签页，往下拉能看到 Personal access tokens 区域，点 Generate new token。
生成的时候有几个选择要注意。Token 的过期时间建议选长一点，省得一个月后突然失效还得重新配置。勾选权限的时候，只勾 File content 的只读权限就够了，FS（File System）相关的权限、Dev resources 之类的都别开。这是安全习惯也是务实选择——MCP Server 只需要读设计稿，给它写权限徒增风险，而且某些 MCP Server 在权限过大的情况下反而可能触发 Figma 的风控。
生成之后是一串以 figd 开头的字符串，复制出来存好。注意，这串 Token 等同于你 Figma 账号的一把只读钥匙，不要贴到公开仓库里，也不要随手发到群里。如果你用的是团队项目，还需要确认当前账号能访问那个设计稿文件，不然 MCP Server 调 API 的时候会返回 403。
2.2 第二步：在 Cursor 中写入 MCP Server 配置
Cursor 里的 MCP 配置入口有两个。一个是全局设置：打开 Cursor，按 Cmd/Ctrl + Shift + P，输入 MCP，打开 MCP 面板，点右上角的加号新增 Server；另一个是项目级配置：在项目的 .cursor 目录下新建 mcp.json，这个文件里的配置会跟着仓库走，适合团队协作。
我通常建议用项目级配置，原因很实际：全局配置只在你本机生效，换了电脑或者同事拉取了仓库，MCP 就断了。项目级的 mcp.json 只要提交到 Git，团队里每个人都共用一套配置，新人拉下来就能跑。
配置文件的内容长这样：
json复制{
"mcpServers": {
"figma": {
"command": "npx",
"args": ["-y", "figma-developer-mcp", "--stdio"],
"env": {
"FIGMA_API_KEY": "你的figd_token"
}
}
}
}
这里面有几个细节需要解释一下。figma-developer-mcp 是 Figma 官方维护的 MCP Server 包，比早期的第三方版本稳定得多，命令参数也干净。--stdio 表示通过标准输入输出通信，这是 Cursor 默认支持的传输方式，不需要额外开端口。
如果你用的是 Windows 系统，npx 命令有时会启动失败，因为 Windows 下的命令解析方式和 Mac/Linux 不一样。这种情况下把 command 改成 cmd，args 改成 ["/c", "npx", "-y", "figma-developer-mcp", "--stdio"] 就能解决。这个坑非常隐蔽，报错信息往往只提示“MCP server failed to start”，不会告诉你其实是命令解析的问题。
2.3 第三步：验证 MCP 是否真的连通
配置写完之后，回到 MCP 面板，如果配置正确，能看到 figma 这个 Server 的状态变成了绿色的 Connected。但如果只确认状态是绿的，还不够。
我习惯做一次实际的连通性测试：新建一个空白的对话，直接问 Cursor：“你能读取 Figma 文件吗？请读取这个链接里的设计稿：https://www.figma.com/design/xxxxx/yyyyy”。注意，这里要用真正的 Figma 文件链接，不能随便编一个。
如果 MCP 链路是通的，Cursor 会调用 get_file 相关的工具，然后返回文件里的页面信息、Frame 名称、节点层级。如果只返回一个“无法访问该文件”之类的提示，先别急着怀疑 MCP 挂了，按顺序排查三件事：Token 是否有效、文件链接里的 File Key 是否取对、当前 Figma 账号有没有该文件的访问权限。这三件事排查完，90% 的连接问题都能解决。
3. 实战：从 Figma 链接到可运行页面的完整操作链
3.1 让 Cursor 先“读懂”设计稿再动手
MCP 连上之后，最容易犯的错误就是上来直接甩一句“把这个设计稿写成网页”。这么问不是不行，但效果不稳定。原因在于 Figma 文件的结构可能很复杂——一个团队文件里可能存了十几个页面、几百个 Frame，你不说清楚要还原哪个，Cursor 只能自己猜，猜错的概率不低。
我在实际使用中形成了一套固定的“开场”方式。第一步，先把设计稿链接发给 Cursor，让它用 MCP 工具读取文件，然后让它列出文件里所有页面和 Frame 的名称、尺寸、类型。这一步的目的是建立“共同语境”——让 Cursor 知道你要的是哪个画板，避免后面讨论的时候鸡同鸭讲。
| 询问方式 | Cursor 的典型反应 | 效果 |
|---|---|---|
| “把设计稿写成网页” | 从文件里猜一个最像的页面开始写 | 经常跑偏，找到的不是你要的那个页面 |
| “先列出所有页面和 Frame” | 返回完整的页面清单和尺寸 | Cursor 和你处在同一语境，后续指令能精准定位 |
这一步花不了多少时间，但能显著提高后面生成的准确率。如果文件特别大，节点很多，可以再补充一句“只关注首页相关的 Frame，其他页面先忽略”，减少上下文噪音。
3.2 生成整页骨架的 Prompt 模板与使用要领
读完设计稿结构之后，就可以开始真正生成代码了。我常用的一个整页生成 prompt 模板是这样的：
code复制读取这个 Figma 文件：https://www.figma.com/design/xxxxx/yyyyy
重点分析名为 "Home" 的 Frame。
任务：生成完整的 HTML + CSS 页面。
要求：
1. 整体布局使用 CSS Grid，列数、间距、断点严格按照设计稿的数值
2. 所有颜色、字号、间距、圆角、阴影必须从设计稿节点数据中提取，不要自行发挥
3. 图片资源先用占位图，但尺寸比例必须与设计稿一致
4. 输出为单个 HTML 文件，CSS 写在 style 标签里，方便直接预览
5. 先列关键样式常量（颜色变量、字体栈、间距体系），再写页面结构
这里最关键的是第三点和第五点。强制 Cursor 用真实的设计稿数值，能避免它“凭经验补齐”一些看似合理但实际跑偏的样式。而要求它先列关键样式常量，是为了让后续修改有个统一的入口，不然代码里到处是硬编码的 #333、16px，后面改起来非常痛苦。
生成完之后，先在浏览器里打开看一眼。这个阶段不建议追求一步到位，因为 Cursor 在生成整页时，对某些复杂组件（比如自定义下拉菜单、滑动条）的理解容易出现偏差。第一版的目标是“骨架正确”——整体布局的顺序、比例、色系对得上，细节后面慢慢修。
3.3 细粒度微调：如何追问才能把还原度从 80% 提到 95%
整页生成之后，真正花时间的是细节修正。这个阶段的关键在于提问方式。如果你的指令是“侧边栏宽度不对，改一下”，Cursor 大概率只能猜你要改成多少。但如果指令是“侧边栏宽度与设计稿不一致，设计稿中 Sidebar Frame 的宽度是 256px，请将当前侧边栏改为 256px”，命中率就高得多。
另一种高频场景是关于设计稿里的某个具体数值。你可以直接问：
code复制这个文件里，顶栏 Header Frame 的高度是多少？内边距是多少？请把当前代码调整到一致。
Cursor 会通过 MCP 重新读取设计稿节点，把具体数值返回给你，再自动改代码。这个流程本质上就是“人审稿、工具取数、AI 改码”，比你自己打开 Figma 慢慢量，或者截个图丢给 AI 猜，都要省事。
我整理过一组高频的微调指令，实测下来效果不错：
- “把页面容器宽度从 1280px 改为设计稿的 Desktop Frame 宽度。”
- “导航栏的字体大小请从设计稿中读取，当前是 16px，确认是否为 14px。”
- “卡片列表的间距统一改为设计稿中 Auto Layout 的 gap 值。”
- “这个区块的背景色在设计稿中是什么色值？请同步到代码。”
微调阶段的节奏，一般是一两个指令为一轮，改完刷新浏览器确认一下，再进入下一轮。不要一次性丢十几个问题给 Cursor，它处理不过来，而且后面的指令可能会覆盖前面的修改。
4. 像素级还原的三大翻车现场：布局、字体、响应式
4.1 自动布局和 margin/padding：理解 Figma 的设计逻辑
Figma 的 Auto Layout 是像素级还原里最容易出问题的地方。原因在于，Auto Layout 在 Figma 里是“弹性容器”的概念，它定义的是内部元素之间的排列关系，而不是绝对坐标。当 Cursor 通过 MCP 读取到一个 Auto Layout 节点时，拿到的是 direction（排列方向）、spacing（间距）、padding（内边距）、alignment（对齐方式）这些属性。
如果 Cursor 正确理解了这些属性，生成的 CSS 会非常干净——用 flex 或 grid 实现同样的排列逻辑，间距取的是 gap 值，内边距取的是 padding。但如果 Cursor 偷懒，把每个子元素都写成绝对定位的坐标，那生成的页面在固定尺寸下看着没问题，一旦拉伸或响应式适配，就全乱了。
我建议在 prompt 里明确加一句：“对于 Auto Layout 节点，使用 CSS Flexbox 或 Grid 等比实现，不要使用绝对定位。”这个要求能帮 Cursor 建立正确的代码心智模型。我在实践中遇到过一个典型的案例：设计稿里一个按钮组用 Auto Layout 排列，间距 8px，Cursor 第一版生成时用了 flex，效果完全正常；但另一个卡片组件因为节点结构复杂，它就给每个内部元素加了 position: absolute，结果页面一打开，卡片内容全部叠在一起。后来加了上面那句 prompt，再也没出现过同类问题。
4.2 字体渲染不一致：中文字体与本地缺失的解法
字体是设计稿还原里最容易被忽略、但影响最大的一个环节。设计稿里用的字体，你的电脑和浏览器里不一定有，尤其是中文字体。设计师用苹方（PingFang SC）做的稿子，在 Windows 上打开，系统会自动替换成微软雅黑，视觉效果立刻差一截。这还不是最严重的，更麻烦的是字体缺失可能导致 MCP 读取到的字体信息不完整，或者 CSS 里生成了本地不存在的字体-family，浏览器 fallback 之后和设计稿差距更大。
解决思路分两层。第一层是确保 Figma 里能正常显示设计稿的字体。热词里有人搜“figma安装字体”，其实就是这个问题——如果 Figma 客户端里字体缺失，设计稿本身就会显示成 fallback 字体，MCP 读取到的字体信息也会受影响。你需要在本地安装设计稿中用到的字体文件，或者用 Figma 的 Font Helper 工具让客户端能访问本地字体库。对开发者来说，最实际的方案是让设计师把常用的正文字体限定在系统默认字体栈内，比如中文用苹方/微软雅黑/思源黑体的组合，避免使用非常见商用字体。
第二层是代码侧的字体栈设置。生成页面时，我会要求 Cursor 使用一套跨平台的字体栈，而不是直接套用设计稿里的字体名称。比如设计稿里写的是 PingFang SC，生成代码时就写成：
css复制font-family: -apple-system, "PingFang SC", "Microsoft YaHei", "Segoe UI", sans-serif;
这样在 Mac 上会用苹方，Windows 上会用微软雅黑，视觉上最接近设计稿，又不需要额外加载字体文件。如果项目对品牌字体要求很高，就用 @font-face 引入 web font，但这会带来加载性能成本，需要权衡。
4.3 响应式还原：多画板、断点和设计标注的配合
很多设计稿不止一个画板，桌面端一个、平板一个、手机一个。MCP 可以读取所有这些画板的数据，但问题是 Cursor 在同一轮对话里通常只会聚焦一个画板，你让它“写一个响应式页面”，它可能默认只参考桌面端，然后用媒体查询自己猜平板和手机的样式。
我的做法是把响应式拆成两步。第一步，先精准还原桌面端，把布局、间距、字体全部按桌面画板的数据搞定。第二步，明确告诉 Cursor 去读取平板和手机画板，针对每个断点单独调整。比如：
code复制继续读取这个设计稿中的 Tablet Frame 和 Mobile Frame。
为当前页面添加媒体查询：平板断点 768px，手机断点 375px。
每个断点的布局、字号、间距，严格取对应 Frame 的节点数据。
这样处理的好处是，每个断点的还原都有据可查，不会出现“AI 自由发挥”的情况。但也要承认，移动端的还原比桌面端更依赖经验——Figma 的 Mobile Frame 可能只有 375px 宽，但真实手机屏幕有各种尺寸，375 只是一个基准。我一般会在代码生成后做一轮人工校验，在 DevTools 里拖一下视口宽度，看看 320px 到 414px 之间的表现是否合理，而不是只信设计稿里的那一个画板。
5. 配置与调用中的坑：从“工具注册不上”到“连接超时”
5.1 MCP Server 列表里工具消失的排查顺序
很多人第一次配置 MCP，遇到的第一个问题是：配置文件写了、Server 状态也显示 Connected，但对话里 Cursor 就是没有调用 Figma 的工具，或者工具列表里根本看不到。热词里“figma mcp 在 codex 中总是工具注册不上”反映的就是这类问题，在 Cursor 里同样会出现。
我的排查顺序是固定的。第一，确认 ServerStatus 是 Connected，不是 Failed。如果是 Failed，点开日志看具体报错，大部分情况是命令启动失败或环境变量没读到。第二，确认当前对话模型支持 Function Calling。Cursor 的某些模型配置下，MCP 工具可能不会被自动调用，这种情况下需要在 prompt 里明确说“使用 figma 工具读取设计稿”，或者检查模型的 Tool Use 开关是否打开。第三，把 Cursor 完全重启一次。MCP Server 的注册过程偶发异常，重启能解决相当一部分“工具消失”的问题。
这里有一个小技巧：在 Cursor 的 MCP 面板里，每个 Server 都有一个调试日志入口。日志里能看到工具有没有被成功枚举出来、调用时返回了什么错误。这个日志是解决所有 MCP 问题的第一手资料，比在网上搜报错信息快得多。
5.2 file key 与 URL：参数写错的典型症状
Figma 文件链接的格式是 https://www.figma.com/design/{fileKey}/{fileName}，MCP 工具需要的参数是中间那一段 fileKey，而不是整个 URL。有些 MCP Server 实现里，传入整个 URL 也能解析，但官方版 figma-developer-mcp 对 URL 的解析有严格限制，传错格式会返回类似 “Invalid Figma URL” 的报错。
这个问题还延伸出一个更隐蔽的场景：Figma 的多页面文件，同一个文件里有多个页面，MCP 读取时默认会返回所有页面，但如果你只想要其中一个页面，最好在 prompt 里指明页面名称。我遇到过一种情况，设计稿在文件里叫 “v2_final”，但另存了一份叫 “v2_final_final”，Cursor 读错文件后生成的页面完全对不上。这种低级错误，花 10 秒在 prompt 里明确页面名称就能避免。
5.3 Token 权限不足与网络问题：两个隐蔽坑
Token 权限问题和网络问题有个共同点：报错信息都很有迷惑性。Token 权限不足时，Figma API 返回的是 403 Forbidden，但在 MCP Server 的封装下，你看到的可能是 “Error calling Figma API” 这种宽泛的提示。解决方案是回到 Figma 设置页，确认 Token 的权限里勾选了相关文件类型的读取权限，并且 Token 本身没过期。
网络问题则更隐蔽。MCP Server 在本地运行，它访问 Figma API 需要网络连通，而且这个网络链路必须稳定。如果你所在的环境访问外网本身就不稳定，可能会出现“时好时坏”的现象——第一次调用成功，第二次超时，第三次又正常。这种问题很难从 MCP 日志里定位，因为它的根因在网络层。我的建议是：先确认其他外网请求是否稳定，如果连 Figma 网页端都加载慢，那就不是 MCP 配置的问题了。
关于这块我能给的最实际的建议是：如果遇到连接超时，先把问题拆开——本地能不能访问外网、Figma API 是否可正常响应、Token 有没有失效。这三个问题排查完，再回头怀疑 MCP 的配置，效率要高得多。
6. 这套工作流的边界：MCP 到底适合处理什么、不适合什么
6.1 我实测的工作效率对比
用一个 12 个区块、包含导航栏、卡片列表、数据表格和图表占位的 Dashboard 页面做测试，我对比过三条路径的耗时。纯手工方式，从量数据到写完页面，大概要 4 到 6 个小时，取决于设计稿的复杂程度和对业务的熟悉度。用 AI 看图生成的方式，大概 1 到 2 个小时能出第一版，但还原度在 60% 到 80% 之间，需要大量手动修正。用 Cursor + Figma MCP 的方式，30 到 40 分钟能出第一版，还原度在 80% 到 95% 之间，后续花 20 到 30 分钟微调，基本可以达到交付标准。
这个数字没有水分，但有个前提：设计稿的结构要清晰，命名要规范。如果设计稿里的图层命名全是“Frame 1”“Rectangle 2”这种，MCP 读取到的数据结构就非常难理解，Cursor 的正确率会显著下降。这也解释了为什么同样一套工作流，有人用得很顺，有人说“AI 写的代码没法看”——差距往往在设计稿本身的质量。
6.2 交互和状态逻辑：MCP 不会替你写
有一点必须说清楚：MCP 解决的是“样式还原”问题，不是“业务逻辑”问题。它能告诉你按钮的圆角是 8px、背景色是 #1890ff、悬浮时颜色变化，但它不知道点击这个按钮应该触发什么接口、提交什么数据、做哪些表单校验。
在实际项目中，我通常把 MCP 生成的页面当作“静态高保真原型”的起点。交互逻辑、数据绑定、状态管理、路由跳转这些，还是要靠人写。这里有个务实的建议：在项目早期就让前端和后端约定好接口数据结构，然后在给 Cursor 的 prompt 里把关键字段名称带进去，这样生成的页面结构会预留好数据接入的位置，后面改起来不用大动干戈。
6.3 同类工具横向对比：Figma MCP 与蓝湖 MCP、传统标注
蓝湖现在也提供了 MCP 能力，热词里有人搜“蓝湖mcp”，说明这类需求确实存在。从原理上看，蓝湖 MCP 和 Figma MCP 很相似，都是把设计稿的结构化数据喂给 AI 工具。但从我的实际体验看，两者有侧重点上的区别：Figma MCP 胜在设计稿本身就是数据，节点属性完整、更新即时；蓝湖 MCP 胜在标注信息更偏“交付侧”，比如已经标注好了间距、颜色、切图资源，对前端更友好。
如果是新项目、设计稿已经在 Figma 里管理，我推荐直接用 Figma MCP，少一层中间环节。如果团队已经重度使用蓝湖做设计交付，蓝湖 MCP 也是一个可行的选择。但无论选哪个，核心不在于工具本身，而在于设计稿的规范程度。设计稿不规范，再强的 MCP 也救不回来。
关于效率和边界的一些真实体会
整套流程跑下来，我最深的感受是：Cursor + Figma MCP 最值钱的地方，不是“一键生成网页”这个听起来很神的操作，而是把前端从“看图识字”里解放了出来。以前一个页面的还原，真正写 CSS 的时间可能只占三分之一，剩下三分之二全在设计稿和代码之间来回切换、量数据、对样式。现在这部分工作交给了 MCP 读取数据，人只需要做审核和关键决策。
但也别对它抱有不切实际的期望。它会犯错，会读错节点，会在某些复杂布局上给出不合理的实现方案。所以我的最终建议是：把它当成一个“读数据极准、写代码稍快、但需要人盯着的实习生”，而不是“全自动交付机器人”。你发给它的 prompt 越明确，它给你的输出就越接近你想要的结果；你对设计稿结构的理解越深，你就能越精准地指出它在哪一步跑偏了。这套工作流的本质，是把你的专业判断力，通过自然语言放大到代码生成的过程中。