从 Figma 到代码：拆解 AI 设计转开发的四层管线

把一群设计师关进同一个房间，问他们设计稿如何通过 AI 真正变成可运行的前端代码，得到的答案往往南辕北辙、且都底气不足。这并非你错过了什么内部备忘录——因为这份备忘录根本不存在。本文以 Claude 为例，把当前「设计转代码」的 AI 工具栈拆成几个独立层级，逐层讲清每个环节能做什么、不能做什么。

为什么演示很丝滑，落地却总翻车

社交媒体上的演示视频总是干净的：某人把 Figma 接上某个 AI 工具，输入一句话，几十秒内就生成一个可运行的界面。但当你在自己的真实项目上复现这套操作时，结果往往一塌糊涂，于是你怀疑是自己用错了方法。

事实上并不是你的问题。演示展示的只是某一层在理想条件下顺利工作的样子，而真实项目需要三到四层能力叠加在一起——而没有人会把完整的栈讲清楚，因为栈的内部正是混乱且半成品集中的地方。设计师之所以困惑，是因为没有意识到这些是处于不同阶段、需要不同技能的独立模块。

第一层：MCP，负责「连接」

MCP（Model Context Protocol，模型上下文协议）是当下频繁出现的新名词。先理解它的边界比记住全称更重要。

可以把 Claude（Cursor、Copilot 等同理）想象成一个极其聪明、但被关在密封房间里的人：它能推理得很好，但默认看不到你的文件、看不到 Figma、看不到你的工具，只能基于你粘贴进对话窗口的内容来工作。

MCP 的作用就是给这个房间开一扇门。它的概念类似 USB-C：用一种通用接口标准，让 AI 可以接入各种外部工具——插入 Figma 的 MCP，Claude 就能直接读取 Figma 文件；插入其他 MCP，则可以同时触达 Notion 等工具。MCP 只是线路，Claude 才是真正「理解」内容的主体。

实际效果

• 无 MCP 时：你只能截图后粘贴进对话，让 Claude 去「猜」画面内容。
• 接入 Figma MCP 后：Claude 直接读取真实文件，包括精确的颜色、间距、字体、布局层级等结构信息，而不是一张图片。

接入方式

Figma 目前提供三种官方 MCP，可通过 Claude 对话窗口的「+」连接器直接启用或按官方说明安装，无需自行开发。

MCP 的局限

它能读取你的设计值与结构，却读不到你的代码。它知道按钮的颜色和圆角，但不知道团队代码库里是否已存在可复用的真实组件。于是每次都会「安静地」生成一个外观相似的新元素——对于一次性网页足够，对于规模化产品则远远不够。

第二层：Markdown 文件，负责「记忆」

MCP 让 Claude 看见了你的设计，但它依然读不到你脑子里的规则——那些你从不写进 Figma、却每次都会默默遵循的设计决策。

Markdown（.md）文件就是用来承载这些规则与理由的地方：它只是一段纯文本笔记，写一次之后让 Claude 去读。Figma 文件保存了「看起来是什么样」，代码保存了「运行起来做什么」，只有这份笔记保存了「为什么这样设计」。它像你留给新加入的自由职业者的交接说明，例如：

• 「次要操作使用静音按钮。」
• 「同一屏内绝不出现两个高强调按钮。」

这些规则 Figma 文件里完全没有记录，只有这份笔记能传递给 Claude。

它是什么、谁来写

Markdown 是纯文本格式，保存为 .md 后缀，语法极轻量，人和机器都能直接阅读。通常不需要从零手写，而是让 MCP 先读 Figma 文件，由 Claude 据此起草包含颜色、间距、组件说明的第一版，再在对话中或手工精修。

它存在哪里

• 最简单：放在项目文件夹里。
• 在 Claude 工作流中：根文件命名为 CLAUDE.md，Claude 每次会自动读取它，因此无需重复解释。
• 进阶用法：CLAUDE.md 作为首页，指向更聚焦的子文件，例如 design.md（设计规则）、content.md（写作规则），Claude 会顺着引用链逐个读取。
• 大型团队：把这些文件与代码放在同一代码仓库里，让整个团队和所有工具共用同一份信息源。

小结：看清每一层，才能正确组合

当前 Figma 到代码的 AI 管线并不是一个端到端的产品，而是一组能力分散、需要手动拼装的层：MCP 解决「看见设计」的问题，Markdown 文件解决「传递规则」的问题。再往上还有组件库映射、代码生成等环节（原文因截断暂未展开），每一层都只解决了完整链路中的一小段。把它们视为独立模块、分别评估其能力边界，比指望某个工具「一键解决」更接近现实。