企业官网建设流程全解析

1. 为什么我会搞这套组合：设计师改稿痛点的场景还原

先说说我是怎么入坑的。前阵子接了一个紧急项目，视觉稿在 Figma 里已经改到第 17 版了，产品经理还在用飞书发"标题字再大一点"、"按钮颜色不够活泼"这种看着像人话、实际全靠猜的需求。更要命的是，每次改动都要求切图重新导出，前端那边拿到的新资源又经常跟标注脱节。

我当时第一反应是"有没有可能让代码直接去改设计稿"。对，你没听错，不是让设计师用代码，也不是让开发进 Figma 手动点，而是让 AI 助手通过协议直接操作设计稿里的图层、属性，甚至批量替换组件。这就是 Figma MCP 干的事——把 Figma 变成 Anthropic 那套 Claude Code 的"手和眼"。

我知道有人看到这儿会想：这玩意儿是不是又是概念大于实用？说实话，我第一次看到 MCP（Model Context Protocol，模型上下文协议）这个缩写的时候也是这个反应。但实际用了一周之后，我的结论变了：这套配置对"设计改稿频繁、设计开发协作混乱"的团队来说，价值远超预期。它解决的并不是"让 AI 替代设计师"，而是把重复性的属性修改、标注同步、切图导出这些脏活从人工流程里剥出来。

如果你属于下面几类人，这篇配置笔记大概率对你有用：

• 每天在 Figma 里反复改字号、改颜色、改间距的 UI 设计师。
• 需要自己提图、又要对标注负责的前端开发。
• 想用 Claude Code 做自动化，但一直卡在"MCP Server 怎么连"这一步的爱好者。
• 团队里负责工具链的人，想看看这套方案跟蓝湖 MCP、Playwright MCP 这些同类工具有啥区别。

我先拍个结论：整个流程跑通之后，一条自然语言指令就能完成"把首页主标题改成 32 号粗体、价格颜色改成品牌红、然后导出一套 2x 切图"这种组合操作，全程耗时大概二十秒。注意，这是真实的场景，不是演示 Demo。

下面我按"从零到一"的顺序把配置过程、踩过的坑、以及几个能直接用的小技巧全部摊开讲。不想看原理的可以直接跳到第 3 节抄配置，但我建议你把第 2 节看完，因为你不理解 MCP 的"求值顺序"，后面出问题了会完全摸不着头脑。

2. 前置认知：MCP 到底解决了什么问题，和传统插件、SDK 有什么本质区别

2.1 MCP 不是"Figma 插件"，它是"AI 的工具插槽"

先把这个概念掰清楚。Figma 官方早就开放了 Plugin API，社区里的插件少说也有上千个。但传统插件有一个致命限制：它们是给人点的，不是给 AI 用的。你要做一个"批量改字重"的插件，你得先去 Figma Community 搜插件、安装、然后在插件面板里填写参数、点运行。整个过程是"人给 AI 传话"。

MCP 换了个思路：它定义了一套通用的"工具发现-参数描述-调用执行"标准，让 AI（比如 Claude Code）能自己发现有哪些工具可用，知道每个工具的参数格式，然后直接调用。你可以把 MCP 理解成一个 USB-C 接口，Figma MCP Server 就是插在这个接口上的设备，Claude Code 是操作系统，它不需要知道设备里面的电路怎么走，只要按标准协议发指令，设备就能干活。

这带来两个关键变化：

• 第一，AI 可以"连续操作"。以前人用插件改完一个属性，还要再点一次插件改下一个属性。现在 AI 可以在一次会话里，先获取图层树，再逐层定位目标，再执行修改，最后导出资源，整条链路串下来，不需要人去中间环节插入操作。
• 第二，工具是声明的，不是猜的。MCP Server 会提供一个 JSON Schema，里面写清楚每个工具叫什么、要传哪些参数、参数是 string 还是 number。这比让 AI 去猜怎么调 REST API 或本地 SDK 要稳定得多。

2.2 Claude Code 在这个体系里的角色

有人会问：用 MCP 不是要配合 Claude Code 吗？能不能用别的？可以，比如 Cursor、VS Code 的 Claude 插件、甚至一些支持 MCP Client 的第三方工具都行。但 Claude Code 在这里有两个优势：

• 它是专门为"长链路编码任务"设计的，对一个命令的执行会有步骤分解和中断恢复，改 Figma 这种多步操作时不容易中途断片。
• 它的 CLI 工作流适合与 Git、Node、Python 脚本混用，方便把 Figma 改动和代码工程联动。

不过也提醒一句：Claude Code 仍旧依赖 Anthropic 的 API 或订阅额度。如果你的网络环境访问官方服务卡顿，那体验会打折扣。这个我不展开，大家自行评估。

2.3 "Figam MCP 可以直接切图吗"——热搜里最常见的问题

搜索热词里有一条很扎眼：figma mcp 可以直接切图吗。我直接给答案：可以，但跟你在 Figma 里手动选中图层按"导出"是两个逻辑。MCP 的切图是通过调用 Figma API 导出指定节点的图片资源，输出 PNG/JPEG/SVG/PDF 等格式。它能拿到你设置的导出参数，比如倍率、格式、切片区域，但它不会自动帮你判断"哪些图层应该组成一个切图组"，这活儿目前在 MCP 方案里还是靠你提前在 Figma 里把图层命名为带 @2x 或 /slice 之类的规范，或者让 AI 按图层命名规则去推断。

所以"能不能切图"和"切得好不好"是两码事。后面第 5 节我会给出规避切图翻车的图层命名规范，这里先记住一个结论：MCP 适合切"已经规范好的图"，不适合在屎山上硬切。

3. 环境准备：从 Node 到认证 Token，最容易翻车的三个环节

3.1 第一步：本机依赖和版本坑

Figma MCP Server 的官方实现是基于 Node.js 的（也有 Python 版，但 Node 版更新最勤）。所以最先检查的是 Node 版本。我一开始用的是 Node 16，启动 server 直接报错，提示需要 Node 18 以上。这个坑非常典型，因为 Homebrew 装的 node 可能版本老，而 MCP Server 用了较新的 fetch API 和结构化日志特性。

建议直接用 nvm 管理：

nvm install 20 nvm use 20 node -v

如果你没装 nvm，Windows 用户去官网下 LTS 版安装包即可。装完确认 npm -v 能正常输出。这里有个值得一提的细节：Claude Code 本身也会依赖 Node，所以推荐把 Node 统一装到 18+，避免出现 Claude Code 能启动但 MCP Server 起不来这种间歇性故障。

3.2 第二步：获取 Figma Token 的几个误区

MCP Server 要操作你的 Figma 文件，拿的是个人访问令牌（Personal Access Token）。在 Figma 网页端：点头像 -> Settings -> Security -> Personal access tokens -> Generate new token。注意两个点：

• Token 需要勾选 File content 相关的读权限，不然连获取文件树都失败。
• Token 生成后只会显示一次，复制到本地存好，别直接怼进 Git 仓库。

网上不少教程让你把 token 写进环境变量或者 MCP Server 的启动参数里，这个没问题，但你要搞清楚作用域。Figma Token 不像 GitHub Token 可以按仓库控制权限，它是全局的。也就是说，任何拿到了你 token 的进程，都能读你账号下所有有权访问的文件。所以别拿公司管理员账号去生成这个 token，权限务必最小化。

3.3 第三步：安装 Figma MCP Server

这里以官方或者社区维护较多的 npm 包为例：

npm install -g @somefigma/mcp-server-figma

安装完之后，先用 npx 手动测试一下能不能正常响应：

npx @somefigma/mcp-server-figma --transport stdio

如果命令行卡住或者直接报"Invalid token"，那说明 token 没配上。此时可以用环境变量方式临时指定：

FIGMA_API_KEY=你的token npx @somefigma/mcp-server-figma --transport stdio

手动模式正常后，再交给 Claude Code 接管。

注意：不同版本包的启动参数不同。有的包用 --token 加参数，有的用环境变量 FIGMA_API_KEY，有的还需要 --file-key 限定默认文件。你安装后务必先跑一下 --help 看看参数说明。

4. Claude Code 里配置 MCP Server：三种接入方式与配置文件写法

4.1 自动发现式配置（适合最新版 Claude Code）

新版 Claude Code 支持从.mcp.json自动加载 MCP Server。项目根目录放一个.mcp.json：

{ "mcpServers": { "figma": { "command": "npx", "args": ["-y", "@somefigma/mcp-server-figma"], "env": { "FIGMA_API_KEY": "你的token" } } } }

保存后重启 Claude Code，执行/mcp命令应该能看到 figma 显示 connected。这个方案的好处是配置随项目走，团队克隆仓库后不用重复配置 token（前提是 token 别直接明文提交，敏感团队用环境变量引用）。

4.2 全局配置（适合所有项目都能用）

如果你不想每个项目都放一份配置，那就写全局配置文件。Claude Code 配置路径通常是~/.claude/settings.json，在里面加：

{ "mcpServers": { "figma": { "command": "npx", "args": ["-y", "@somefigma/mcp-server-figma"], "env": { "FIGMA_API_KEY": "你的token" } } } }

有的版本改在~/.claude.json里，结构略有差异。建议全局配好之后，在任意目录开一个 Claude Code 会话，用mcp命令检查是否识别，别等到真正操作才发现根本没加载。

4.3 VS Code 插件路径（桌面党专用）

热词里有 figma mcp 和 vscode 配置 claude code，顺带提一句。VS Code 里装 Claude Code 扩展后，可以在扩展设置里指定 MCP 配置文件的额外路径。我的做法是：VS Code 插件读取的还是同一个.mcp.json，不单独维护。省心，也避免两处配置漂移。

4.4 启动失败的排查顺序

MCP Server 连接失败是最高频的问题。我建议按这个顺序查：

1. 先手动 npx 启动，看 stderr 输出有没有报错。
2. 确认 token 能单独访问 Figma API（用 curl 测试一下接口通不通）。
3. 确认 Node 版本 >= 18。
4. 在 Claude Code 里跑mcp查看报错详情，常见 error 是 ENOENT 找不到 npx（PATH 没传到 Claude Code 进程）、或 timeout（网络访问 Figma API 超时）。
5. 终极杀招：把 command 改成绝对路径，比如/Users/你的用户/.nvm/versions/node/v20.x.x/bin/npx。这个方法能解决七八成 PATH 问题。

5. 实战操作：用自然语言直接修改设计稿，我把话术和原理都拆给你

5.1 标准台词模板：AI 才能听懂的命令结构

MCP Server 连好之后，你给 Claude Code 的指令要遵循一个隐含结构，我总结成三段式：

• 范围指定：说明是哪个文件、哪一页、哪个 frame。
• 目标描述：要改哪个图层或组件，尽量用名称或路径描述。
• 属性修改：把"人话需求"翻译成具体的属性操作，如字号、字重、颜色、位置、布局。

举例，我想把首页 Hero 区块的主标题字号改大：

在文件 "Landing Page" 的 Page 1 里，找到名为 "Hero" 的 Frame，再把里面的 "MainTitle" 文本节点的 fontSize 改成 48，fontWeight 改成 700。

这种直接命令的方式成功率非常高，因为 AI 能调用以 get 开头的一系列工具去读文件树、搜索节点、再看节点的类型和现有属性，然后调用 patch 类工具去更新。

5.2 一个完整的"改颜色+改间距+导出资源"实战脚本

下面这段是我实际测试跑通的场景，完整记录一下：

第一步，获取文件树：

figma 文件 key 是 xxxx，帮我列出第一页顶层的 frame 名称。

AI 会调用类似 figma_get_file 的工具，返回结构化的 nodes。然后我继续：

打开 "价格区块"，把里面 "priceText" 的文字颜色改成 #E74C3C，然后把 "AddToCart" 按钮的上间距 marginTop 改成 24。

这里的关键在于 AI 能不能准确定位到priceText。如果图层命名不规范，就得告诉 AI 用文本内容来匹配，比如"找文本内容包含 $99 的那个 Text Node"。MCP Server 提供了搜索工具的话，这会快很多；如果没有，就得靠 AI 遍历子节点。

最后一步切图：

把 "价格区块" 这个 frame 按 @2x 导出 PNG，输出到 /tmp/price_section.png。

AI 会调用导出工具：

GET https://api.figma.com/v1/images/xxxx?ids=价格区块的节点ID&format=PNG&scale=2

拿到图片 URL 后，如果你本地配了下载工具，AI 还可能帮你把图片拉下来。没有也没关系，URL 可以直接丢给前端。

5.3 从"人话需求"到"代码指令"的翻译心法

很多人用了几次觉得"AI 改稿改不准"，多半是话术问题。记住一个原则：描述对象不要描述感觉。

• 错误说法："把标题改得大气一点"
• 正确说法："把 MainTitle 的 fontFamily 改成 Inter，fontSize 改成 56，字符间距 tracking 调成 -1%，同时把宽度设为 Frame 宽度的 90%"

如果你连 Figma 里的属性名词都不熟，那先补一点 Figma 的 API 对象模型基础。在 Figma API 里，文本节点有 characters、fontSize、fontName、textCase、lineHeight、letterSpacing 这些字段，矩形节点有 fills、strokes、cornerRadius，Frame 有 layoutMode、primaryAxisAlignSizing 之类。这些名词都是 AI 能直接改的字段。

所以下次你再想"这个黄色不够高级"，就先在图层面板里找到那块的 fills 颜色值，告诉 AI 一个具体的色号，让它全局替换，比让它"猜一个高级黄"要靠谱得多。

5.4 组件批量替换：这套方案最亮眼的地方

单个改属性只是热身，真正省时间的是组件实例的属性覆盖。比如你有 40 个卡片组件实例，需求是"所有卡片的按钮文案改成'立即购买'"。手动一个个改要刷半天，有了 MCP 之后，AI 会先找到所有实例节点，然后对每个实例覆盖buttonText这个 component property。

我在实测中让 Claude Code 干过这么一件事：

把这个文件里所有 PrimaryButton 实例的 label 属性改为 "立即咨询"，但购物车页面除外。

AI 的处理是：遍历全部页面 -> 找 PrimaryButton 组件实例 -> 按页面名过滤掉 Cart -> 修改实例属性。几百个实例瞬间完成，而且修改可以撤销。这在多人协作时非常有用，因为实例覆盖不会污染主组件，其他页面不会被动刀。

6. 避坑记录：我在这套配置上浪费过的 4 个小时

6.1 坑一：明明连上了，却说找不到文件

现象：MCP Server 显示 connected，命令也正常返回，但一问文件就说"File not found or permission denied"。

排查过程：一开始我以为是 token 权限不够，重新生成 token 也没用。后来发现是文件 key 搞错了——我在 Figma 网页地址栏复制的是一整串 URL，包含文件名和一堆参数，而服务器只需要 URL 里/file/后面的那段 ID。

解决：直接用文件 URL 可以省事，但前提是 AI 能识别；如果你给的是一个裸 key 更干净。这个坑最容易发生在你从 Figma 分享弹窗复制链接的时候，复制出来的是带团队 ID 的路径。切记只保留 /file/ 和 /design/ 之间的那串字符。

6.2 坑二：AI 把颜色值识别成了 0x 开头的十六进制

Figma 的 colors 属性在 API 里返回的是 r/g/b/a 浮点数，比如{"r": 0.8, "g": 0.2, "b": 0.1, "a": 1}。而我习惯说"色号 E74C3C"。AI 有时候会自己换算，但偶尔换算错误，导致改了之后颜色彻底偏掉。

解决办法：在指令里直接给出 API 格式的值，或者让 AI 先读取目标节点的现有 colors 结构再改。实测下来，让 AI"按现有格式更新，只把 r/g/b 三个值替换为 xx"最稳定。

6.3 坑三：自动导出图片 URL 未授权或者过期

Figma 的图片导出 API 生成的 URL 有时效性。AI 返回了一个 URL，你放了一会儿再打开，就提示过期。这一点官网没强调，但实际使用中确实存在。规避方法是：拿到 URL 后立刻让 AI 用本地的脚本/SDK 下载，或者用支持长时间有效期的导出参数。如果非要用短链，记得在同一个会话里完成下载。

6.4 坑四：改了之后协同团队不知道，版本管理脱节

这可能是最"工程化"的坑。MCP 能快速改稿，但它没有像 Git 那样的显式提交记录。如果团队里几个人同时在一个 Figma 文件里协作，你让 AI 改了一堆图层，别人根本不知道这些改动是怎么来的。

我的经验是：让 Claude Code 在每次批量修改前，先用版本历史工具记录当前版本号，并生成一段修改说明。Figma 的版本历史是自动记录的，但 AI 生成的修改往往是一坨操作，不如手动告诉它"在改之前把当前版本命名备份为 before_batch_change"。这样万一改崩了，可以直接回滚到命名版本。

7. 进阶玩法：结合 Playwright MCP、蓝湖 MCP 和工程化流程的联动思路

7.1 不止 Figma MCP：同类工具怎么选

热词里反复出现的蓝湖 MCP、Playwright MCP，本质上走的是同一套 MCP 协议，但应用场景各有侧重：

• Figma MCP：面向设计稿操作，适合改属性、导出资源、读图层结构。
• Playwright MCP：面向浏览器自动化，适合前端联调时验证页面效果。
• 蓝湖 MCP：面向设计与开发的交付衔接，更多是标注、切图、代码生成一类的协作场景。

我给一个选型建议：如果你的团队主要痛点是"改稿频繁"，优先上 Figma MCP；如果是"前端实现跟设计稿不一致"，那 Playwright MCP 的价值更大；如果是"设计交付规范混乱"，蓝湖 MCP 或类似的交付平台更合适。说实话，成熟的团队会把三套全接上，让 Claude Code 在图、码、测三个环节成为一个串联的助理。

7.2 与工程代码联动的简单示例

设想一个更完整的流程：Claude Code 里先通过 Figma MCP 读取设计稿的主色、圆角、间距 token，然后直接把这些值写入项目里的 Tailwind 配置或 SCSS 变量，再跑一遍本地构建，再用 Playwright MCP 打开本地页面截图对比。这个链路里每一环我都在不同项目跑通过，没有人肉的"根据设计稿手抄变量"环节。

实现这种联动不需要额外写平台，本质上就是让 Claude Code 在一个工作目录里同时持有 Figma MCP 的工具上下文和本地代码的执行权限。你只要不跨越安全边界（比如不把 Figma Token 写进代码仓库），整个流程是合法且高效的。

7.3 一些关于自动化的坦白

说了这么多好处，也得泼盆冷水。MCP 驱动的 AI 改稿目前还不是"万能手柄"。它最擅长的场景是属性明确、批量重复、路径清晰的改动；最不擅长的是"需要审美判断"的改动，比如"这个布局不够平衡""这两个元素视觉重心不对"。AI 没有眼睛，它对"好不好看"的理解仅仅来自文字描述。所以在我的团队里，我们的定位是：用 MCP 做执行，用人做决策。让 AI 去改千篇一律的圆角、字号、颜色变量，把设计师的时间省下来去调整真正需要美感的布局。

8. 我建议的上手路径和常见问题快查

8.1 从"读"开始，不要一上来就"写"

我见过太多人第一天就把 Claude Code 接上 Figma MCP，然后直接一句"把整个页面的 UI 重设计一下"。这种指令谁都接不住。我建议前一周只做只读操作：让 AI 列出文件树、统计组件使用次数、导出几个切图、对比两页的属性差异。只读操作不会破坏文件，还能让你摸清 MCP 的返回格式、token 配额和网络延迟。

等只读用顺了，再开始小范围写操作，比如改某一个 frame 里某个文本的颜色，确认无误再批量。

8.2 常见问题快查表

8.3 如果团队要落地，一定要先定图层命名规范

最后说个跟技术无关但比技术更重要的东西。Figma MCP 的实际效果上限，很大程度取决于你的图层命名规范。AI 按名字找节点，比按坐标找节点优雅得多。我们团队现在要求所有设计稿满足三条：

• Frame 命名用功能语义，比如 PriceSection、HeroBanner，而不是"Frame 138"。
• 文本节点哪怕只显示一句话，也要起名，比如 MainTitle、PriceText。
• 需要导出的图层统一带 @2x 或 @3x 后缀标识，方便 AI 识别切图目标。

有了这些规范，AI 定位节点几乎不会跑偏，批量修改的成功率会从六成直接拉到九成以上。

我在实际项目里把这套流程跑通后，最大的感受是：设计师不用再为"改个字号要导出三次"发火，开发不用再在标注和设计稿之间来回对账，甲方也不会再因为版本混乱而崩溃。它没有让设计工作消失，但确实把机械重复的那部分压缩到了极限。如果你所在团队每天都要处理大量琐碎的 UI 属性返工，照着这份配置走一遍，先跑通一个只读操作，再逐步扩大 AI 的权限范围，风险可控，收益却非常直接。