周五下午三点产品经理丢来一句“首页视觉改了五点半评审”随后一个 Figma 链接砸进群里。你深吸一口气打开设计稿然后开始了那套熟练到让人麻木的流程量间距、取色值、切图标、导资源、写 CSS 还原。两小时过去评审会上的第一句话大概率还是“这里和设计稿不太一样”。这段经历我太熟悉了所以当 Claude Code 配合 Figma MCP 可以绕过大量重复工作、直接把设计稿数据交给大模型生成 HTML 时我就知道这条工作流值得好好写一写。这篇内容会完整讲清楚 FIgma MCP Server 是怎么把设计稿“翻译”成 AI 能读懂的结构化数据Claude Code 又怎么基于这些数据生成一套可以实际运行的 HTML/CSS以及我在真实项目里踩过的坑和总结出的实操参数。如果你是被切图、标注和“像素级还原”折磨的前端或者需要快速把设计稿变成可交互 Demo 的设计师和独立开发者这套流程能帮你把体力活压缩到原来的三分之一以下。1. 手动切图这件事为什么会成为瓶颈1.1 从设计稿到网页的完整链路传统的“设计稿转网页”链路看着不复杂实际每一步都是时间和耐心的双重消耗。设计师在 Figma 里画好界面只是开始前端拿到设计稿后要做的第一件事就是“读图”逐个查看 Frame、Group 和 Component把设计稿上的坐标、尺寸、圆角、颜色、字体大小等信息手动记录下来。一张中等复杂度的落地页图层数量动辄几十上百光读完这些信息就要花掉不少时间。第二步是切图和资源导出。图标要一张张导背景图要按 1x、2x 甚至 3x 的倍数导出有些设计稿里的资源命名还不规范导出来全是“Frame 3721.png”这种文件名拿到代码里还得重新映射成有意义的命名。这个过程没有任何创造性纯粹是体力劳动但你又不能跳过因为 CSS 需要这些资源才能还原设计。第三步才是真正写代码。把之前量好的尺寸翻译成 CSS 属性把导出的图片填进 background-image 或 img 标签。等页面写完了来回校对又是另一轮痛苦字体间距差了两个像素按钮在某个断点下没居中某个颜色在暗色背景上对比度不够……这些“小问题”一个接一个冒出来的时候人很容易烦躁因为你知道问题本身不难但它就是密集地消耗着你的时间和耐心。这套流程最大的问题不是哪一步特别难而是“重复性太高、信息损耗太大”。设计稿里的数据明明已经非常精确我们却在手动复制粘贴中转了好几手既慢又容易出错。我见过不少团队试图用组件库来缓解这个问题但组件库只能覆盖有限场景遇到需要“定制化还原”的页面时还是得走回手动流程。1.2 当 AI 能“看见”设计稿事情就开始变了痛点如此明显自然有人尝试用自动化方案来解决。过去几年出现过一些“设计稿转代码”工具但它们大多走的是“全自动生成整页”的路线生成的代码质量不稳定稍微复杂点的页面就崩所以一直没能成为主流。直到大模型的出现尤其是 Claude Code 这类具备强大代码能力的 Agent 形态工具出现这条赛道才真正出现了转机。转机并不来自某个炫酷的“一键魔法”而是来自一套叫 MCP 的开放协议。MCP 全称是 Model Context Protocol大意是“模型上下文协议”你可以把它理解成给 AI 装上的一排“万能读卡器”。没有这套协议之前AI 只能看文字、看图片想要它处理 Figma 设计稿你得先把设计稿截图喂给它但这会导致信息严重丢失——截图是位图AI 无法知道这个按钮的精确坐标是多少、那个文本的字号是多还是很淡的灰色。Figma MCP Server 解决的就是这个问题。它作为一个中间服务通过 Figma 的开放 API 把设计稿里的结构化数据提取出来包括每个图层的名称、类型、坐标、宽度高度、填充颜色、边框、圆角、字体、字号、字重、透明度等等然后按照 MCP 的协议暴露给 Claude Code。Claude Code 通过这个通道就能像“读本地 JSON 文件”一样拿到完整的 UI 数据基于这些数据生成 HTML/CSS 时就不再是“看着图片猜”而是“看着数据精确还原”。所以这套方案真正的价值点在于它把“人手读图”变成了“程序读数据”把“人写代码”变成了“AI 基于数据写代码”。手动切图时代最大的信息损耗问题被这套链路直接消解掉了。2. 环境准备把 Claude Code 和 Figma MCP 接起来2.1 安装 Claude Code 并完成基础配置在开始之前先把 Claude Code 准备好。Claude Code 是 Anthropic 官方推出的命令行编程助手不是那种聊天窗口式的工具而是直接跑在终端里的 Agent。它最核心的优势是能操作文件系统、执行命令、阅读项目目录像一个坐在你旁边、手能碰到键盘的结对程序员。安装方式取决于你本地的环境。最常见的路径是通过 npm 安装npm install -g anthropic-ai/claude-code前提是你本地已经有 Node.js 环境建议 Node.js 版本在 18 以上。如果机器上没有 Node.js或者你更习惯用原生安装方式也可以去官方文档看对应的安装脚本这里不展开。安装完成后在终端里输入claude启动。首次启动会引导你完成登录认证这里需要准备一个 API Key 或者订阅账号。如果你平时用 VS Code 比较多也可以在 VS Code 的终端里直接运行claude或者装对应的 VS Code 扩展让 AI 生成的修改直接在编辑器里显示 diff这对后续迭代调整体验会更舒服。模型选择方面Claude Code 默认会使用它的旗舰模型你的控制台里也可以看到每一次会话的 token 消耗情况。我建议在正式跑设计稿转 HTML 这类任务时保持默认的旗舰模型因为这类任务对指令跟随和代码生成质量要求比较高。日常小修小改再考虑切到轻量模型能省一些 token 开销。另外Claude Code 也支持配置兼容接口的方式但如果你不需要走这条路径用官方默认配置就足够稳定。注意Claude Code 会读取当前目录的上下文。建议在正式做项目时为每个页面建立独立的工作目录避免把无关文件塞进 AI 的上下文里影响生成质量和响应速度。2.2 配置 Figma MCP Server打通数据通道Claude Code 装好之后下一步要解决的是“让它能连上 Figma”。这里需要配置 Figma MCP Server。比较常见的实现是使用 Figma 官方或第三方提供的figma-developer-mcp这类服务包你可以在支持的注册表里搜索到。先到 Figma 里生成一个 Personal Access Token。登录 Figma 后进入个人设置页面找到“Security”或“Access tokens”相关的入口点击生成新 token。生成时需要注意权限范围的设置建议赋予文件读取权限不要勾选写入权限或删除权限最小化 token 泄露带来的风险。这个 token 是你访问 Figma API 的凭证后续 MCP Server 就是要靠它去拉取设计稿数据。拿到 token 之后在 Claude Code 的配置里添加一个 MCP Server关键配置信息大约是这样{ mcpServers: { figma: { command: npx, args: [ -y, figma-developer-mcp, --figma-api-key你的token ], env: {} } } }不同版本的 Claude Code 对 MCP 配置的入口可能略有差异有的是在项目根目录下维护一个.mcp.json有的在全局配置里管理。配置完以后启动 Claude CodeAI 会在初始化时尝试连接你配置的 MCP Server。如果连接成功你会在会话里看到对应工具已经可用的提示。连接完成之后最好做一次简单的连通性测试方法很直接直接让 Claude 输出当前 MCP 服务器下可用工具的名称或者直接给它一个 Figma 文件链接问它这个文件里有哪些页面。如果它能正确返回就说明整条数据通道已经打通了。我这里用了figma-developer-mcp作为示例实际你也可以选择其他社区维护的 Figma MCP 实现只要它符合 MCP 协议规范、能返回格式良好的组件树和样式数据即可。最后确认 token 是否能访问目标文件有一个隐藏条件Figma 文件的分享权限至少要是“任何拥有链接的人可查看”否则 MCP 拿 token 去请求 API 时会被权限挡住。2.3 用一个小例子验证链路是否连通别急着拿复杂页面开刀先用一个简单 Frame 测试整条链路。在 Figma 里新建一个页面放一个 400×300 的 Frame里面加一个按钮和一个标题给它们填上颜色、字号等基础样式确保这个文件有权限被 API 读取。然后在 Claude Code 里发起一句类似这样的指令“请读取这个 Figma 文件的所有页面结构列出每个图层的名称、类型、坐标和样式数据。Figma 链接是 xxx。”如果一切正常Claude Code 会通过 MCP 工具获取到设计稿的 JSON 数据并在回复里总结出你刚才创建的 Frame、标题和按钮的完整信息。这一步成功之后你才算真正拿到了“AI 读设计稿”的入场券。后续的所有自动化生成都是建立在这个数据连接之上。我第一次跑通这个验证的时候最大的感受是“原来 AI 读设计稿可以读得这么细致”——连按钮在不同状态下是否有不同填充色、文本的 line-height 是多少这类细节都能拿到。有了这些结构化数据后面让 AI 输出代码就变得水到渠成。3. 实操过程从设计稿到 HTML 的完整跑通3.1 先花 5 分钟整理设计稿后面会省 20 分钟很多人在第一次尝试这套流程时直接把一个几十个 Frame 的复杂设计稿链接丢给 AI然后期待 AI 一次性输出完美代码结果往往不理想。问题不一定出在 AI 身上而是设计稿本身的规范性连人看起来都费劲AI 自然更吃力。在把设计稿交给 AI 之前建议花 5 分钟做一个简单的“整理动作”。核心是检查命名和层级Frame 是否命名清晰关键按钮和区块是否用了有意义的英文名称是否存在大量嵌套混乱的 Group。如果你自己打开设计稿的图层面板能比较清楚地看出“这是头部、这是导航、这是卡片列表”那这份设计稿对 AI 来说就是友好的。反之如果图层全叫“Rectangle 7”“Frame 149”AI 虽然能靠坐标和样式推算但生成结果的顺序和语义化程度会差很多。第二个要注意的点是“一次只交一个页面”。如果你想生成的是一个完整的落地页可以按区块拆分成几次操作先让 AI 生成整体头部和导航再生成内容区再生成页脚。整页一次生成不是不能做而是当页面上有大量交互状态、弹窗、复杂轮播时AI 一次性输出容易出现上下文信息过长导致遗漏细节的问题。区块化生成再合并是我测试下来稳定性和可控性最高的方法。整理设计稿时还有一个容易忽略的点确认字体和资源。Figma 里如果用了某些特殊字体AI 生成 HTML 时默认会使用系统中存在的字体栈或者写上font-family里指定的字体名。如果设计稿用的字体没有 web 可用字体版本最后的还原效果会有偏差。建议在设计稿里对标题、正文等关键文本使用的字体做到心中有数提前准备线上可用的字体资源或 fallback 方案。3.2 用提示词驱动 AI 生成页面框架链路通了、设计稿也整理好了下面进入核心环节如何写好让 Claude Code 生成 HTML 的提示词。这一步非常关键提示词的质量在很大程度上决定了生成代码的质量。我给一个亲测有效的提示词结构你可以根据自己的项目做调整。核心思路是告诉 AI 你的角色、你的目标、你的约束条件、你的交付格式以及你希望它使用的技术栈和运行环境。我现在要基于一个 Figma 设计稿生成一个完整的落地页 HTML。 设计稿的链接是设计稿链接 请先读取该设计稿的数据分析其中所有页面和区块结构。 要求如下 1. 生成一个 HTML 文件内联 CSS 或外链 CSS 均可但依赖项越少越好。 2. 页面结构语义化优先使用 header、main、section、footer 等标签。 3. 严格依据设计稿的间距、颜色、字体和布局参数进行还原不要自行创新。 4. 页面需要适配移动端和桌面端建议以 mobile-first 的方式编写媒体查询。 5. 图片资源请用占位图或设计稿中标注的资源图标可以用内联 SVG 或 Unicode 字符。 6. 生成完成后先输出页面结构清单再输出完整代码。 另外如果设计稿中有你不确定的内容请用注释标记出来不要擅自猜测。可以看到这个提示词里我刻意强调了“不要自行创新”和“严格依据设计稿参数”。因为大模型在生成代码时有很强的“自由发挥”倾向——它很喜欢给你补一些设计稿里根本不存在的元素比如额外加一排小图标、加一个它觉得“很合适的响应式断点”。这些“好心”行为放在还原设计稿的场景下就是破坏还原度。当 Claude Code 读取完设计稿数据之后它会先输出一个结构清单大致是“头部导航区、Hero 区、功能卡片区、数据展示区、页脚”。看到这个清单先确认清单和设计稿是否一致如果不一致立刻让 AI 重新分析不要等到代码生成完才发现结构错了。确认结构之后AI 会基于读取到的坐标和样式数据生成代码。你可能会注意到AI 生成到某些地方时会主动提出疑问比如“设计稿中使用了一个图片组件但无法确定实际图片地址将使用占位图”。这个行为其实很优秀说明它在认真对待数据而不是瞎猜。对于真实项目你可以提前准备好图片资源的映射表或者把图片上传到公共 CDN把链接提供给 AI这样你的输出代码连图片都直接是“可用状态”。3.3 迭代提示词把样式细节打磨到位第一版代码生成出来后不要指望它就是终版。即便是最顺利的情况大概率也会有微调的空间。重点检查以下几类问题间距是否和设计稿一致尤其是 padding 和 margin 的值颜色是否准确Figma 里的有些颜色带透明度AI 可能只提取了 RGB 而漏掉了 alpha 通道文本是否换行排版正确响应式断点是否合理。找到问题后不要自己去改代码而是用“描述现象 引用设计稿数值”的方式让 AI 去改。举个例子如果你发现某个区块的内边距不对你可以这样说请检查“功能卡片区”的外层容器设计稿中它的左右内边距是 24px但当前代码里是 16px请修改为设计稿数值。另外这个卡片列表在移动端应该按单列展示请确认媒体查询断点设置是否正确。这种“指出差异 给出期望”的提示方式比空泛地说“不对重新生成”高效得多。因为 Claude Code 可以通过 MCP 重新读取设计稿数据把真实数值和自己的代码做比对而不是靠猜。还有一个小技巧对于比较精细的还原需求可以在提示词里让 AI 对关键节点做“双栏对比输出”比如左边列出设计稿参数右边列出当前代码使用的值这样你一眼就能看出哪里对不上。我第一次用这个方式排查一个灵动页时发现 AI 把一个按钮的字重从 medium 写成了 bold这种细节肉眼很难发现但一对比就暴露了。迭代过程中你会发现AI 对上下文的理解是累积的。当你提出第一次修改后后续再提出其他修改需求时它不会推翻之前的修改而是基于当前版本继续调整。这意味着你可以像带一个初级前端同事一样一点一点地把它“调教”到符合设计稿的程度。还有一个我在实践中觉得特别实用的点用完 Claude Code 之后把每次迭代的提示词和结果整理成一个经验文档。下次再遇到类似页面时直接告诉 AI“参考我上次对这类页面的处理方式”能显著减少来回沟通的轮次。但这步看个人习惯如果你追求一次到位直接把常用规范写进提示词模板里是最快的。4. 常见问题排查与避坑心得4.1 MCP 连接失败和数据读取异常的排查清单这套方案里最可能出现问题的环节其实是 MCP 的配置和权限而不是 AI 生成代码的能力。我整理了一张排查表基本覆盖了我自己遇到过的绝大多数情况。典型表现可能原因处理方法Claude Code 启动后提示找不到 figma 相关工具MCP Server 没配置成功或配置后未重启会话检查配置文件是否生效重启 Claude Code 会话用mcp list之类的命令验证工具是否注册成功读取文件时返回授权失败Figma token 权限不足或者文件链接权限设置过低重新生成 token确认勾选文件读取权限确保目标文件在 Figma 里的分享权限至少是“任何拥有链接的人可查看”能连接但读不到某个特定文件文件 ID 解析错误或文件在团队中设置了权限隔离确认文件链接中file/后面的 ID 是否正确确认你的 Figma 账号对该文件有访问权限MCP 返回数据后 Claude 输出很慢设计稿节点太多结构化数据过大超出上下文窗口在 Figma 里把页面拆分成多个 Frame 或 Page一次只让 AI 处理一部分节点使用 npx 运行 MCP 时每次都重新下载npx 缓存策略或网络问题提前全局安装npm install -g figma-developer-mcp配置里直接调用全局命令路径排查 MCP 问题的时候我建议先把 AI 本身抛开直接手动测试 MCP Server 能不能从 Figma API 拉到数据。MCP Server 本质上是调 Figma 的 HTTP API你在浏览器地址栏访问一下 API 返回的 JSON 链接能打开就说明数据源没问题问题大概率出在配置或权限上。4.2 生成结果和设计稿不像通常卡在哪如果数据和链路都正常但生成出来的页面就是“感觉不对”这时候要从设计稿本身的特征去分析。最常见的一个原因是设计稿里有大量嵌套的 Auto Layout 和 Component 变体AI 在解析时把某个组件的 padding 和 gap 值搞混了导致整体视觉差几个像素。这种问题不算严重通过前面提到的“双栏对比输出”就能解决。另一个常见原因是文本样式的丢失。Figma 里的文本支持多行、富文本混排、文字装饰等复杂属性MCP 提取数据时如果文本内容包含特殊字符、换行符AI 生成 HTML 时容易把段落结构打散。遇到这种情况我一般会在提示词里特别注明“保持文本段落完整不要因为换行符就拆分成多个 p 标签”。还有一个容易被忽略的问题设计稿使用的是 SVG 组件图标但 Figma MCP 读到的只是一个 icon 节点的位置和大小并不会给出这个图标的 SVG path 数据。所以 AI 生成的 HTML 里这些图标要么是空白占位要么是 AI 自己“编”了一个类似风格的图标。想要精确还原图标就需要单独处理图标资源要么在提示词里让 AI 用 Font Awesome 等图标库匹配语义要么自己准备好 SVG 代码喂给 AI。最后想特别提醒一点别让 AI“背锅”。有些页面布局本身就是开发层面的难题比如极端响应式、复杂交互动画、自定义滚动条、渐变叠加阴影等人类前端写起来都费劲AI 一次性完美的概率自然也不高。这类任务正确的打开方式是让 AI 完成基础代码留出明确的 TODO 和注释标记你再针对性地优化。把 AI 定位成“高质量初稿生成器”而不是“百分百交付机器人”心态会舒服很多产出质量反而不差。4.3 这套流程的适用边界和我的工作流建议用了一段时间之后我对这套流程的边界有了比较清晰的认识。最适合这个方案的场景是“信息展示型页面”营销落地页、官网首页、活动专题、后台管理系统的常规页面这些页面以文本、图片、卡片列表、表单为主视觉还原要求高但交互复杂度不高AI 生成的代码几乎可以直接用于生产。不太适合的场景包括含大量交互动画和时间轴逻辑的页面、需要复杂状态管理的应用级前端、大量依赖用户实时数据的 Dashboard。这些项目不是不能用 Claude Code而是你花在“描述需求”和“修正方向”上的时间可能接近自己手写的时间投入产出比不划算。我的建议是这类项目让 AI 负责“搭框架”和“写组件”核心业务逻辑仍然由人来控制。还有一个关于日常工作流的建议把“设计稿→HTML”这套流程尽量形成团队规范。比如在项目里维护一个固定的.claude/skills/目录把常用的设计稿处理要求写成一个 skill 文件这样 Claude Code 在对应项目里启动时能自动加载这些技能定义团队成员之间的生成逻辑也能保持一致。这比每个人各自写 prompt 再互相传阅要稳定得多。我在实际使用中发现这套流程对我最大的价值其实不是“省时间”那么简单而是它改变了我的工作顺序。以前我是先写结构、再调样式、最后抠细节现在我会先处理设计稿数据、明确提示词、把“页面要长什么样”这件事用结构化的方式描述清楚然后再让 AI 去生成。这个顺序倒过来之后我的注意力更多地花在了“确认方向”上而不是“机械执行”上返工率低了很多。最后再分享一个小技巧如果你经常要和 Figma 设计稿打交道不要只存某一轮生成的 HTML而是把生成过程中用到的提示词版本、设计稿链接、以及最终效果截图一起归档。这套“提示词-数据-代码-截图”的四件套素材库积累起来之后以后每接到一个设计稿转 HTML 的需求你都能快速找到最接近的模板和参考整体效率会再上一个台阶。