设计稿直达代码：vibe 项目的 Figma→代码管线实战

vibe coding 最擅长的是把"一句话想法"变成"能跑的 demo"，最不擅长的，是把 demo 变成"看着像正经产品"的东西。逻辑 AI 能写，接口 AI 能调，但 UI 还原度这件事，决定了用户第一眼是觉得"这是个产品"还是"这是个玩具"。而设计稿到代码的最后一公里，恰恰是大多数一人开发者最痛的地方：要么自己手写 CSS 写到深夜，要么把截图丢给 AI，得到一版"神似但处处走样"的代码，再花三倍时间逐像素修回去。

2026 年 10 月，Figma 在 Config India 上把 Code Layers 推向公开测试，加上此前的 Specs（Markdown 上下文容器）、双向 MCP 服务和 Guidelines（给 agent 的设计规范），设计稿到代码第一次有了一条"官方修好的路"。这篇指南不讲 Figma 发了什么新功能——那是资讯的事——讲的是一条可复用的管线：从 Figma 文件准备、设计 token 沉淀、MCP 接入，到 AI 生成、视觉 QA 闭环，五个阶段每一步的输入输出、四个能直接抄的 prompt 模式，以及三个一定会踩的反模式。

先看清现实：管线修好了，但车还是得你自己开

先把预期摆正。Figma 官方的说法很克制：Code Layers 的目标不是替代你的代码编辑器，而是"让可运行的界面在变成产品之前，先在共享画布上可见、可讨论、可编辑"。翻译成独立开发者的话：它解决的是"设计意图"在传递过程中丢失的问题，而不是"写代码"本身。

目前这条管线的真实能力边界（2026 年 10 月）：

• 读：Figma MCP 服务器（远程地址 https://mcp.figma.com/mcp，所有付费计划可用）能把图层结构、组件、Variables、Auto Layout 规则以结构化数据交给 Claude Code、Cursor、Codex 等 coding agent。注意，它读的是结构，不是截图——这是整条管线的基石，也是第一个反模式的来源。
• 写：2026 年 2 月起 MCP 支持写回（Code to Canvas），在 Claude Code 里做好的界面可以推回 Figma 变成可编辑图层。10 月的更新又加了 20 多个 MCP 合作方（OpenCode、Dia、Sarvam 等），并允许从外部 AI 工具直接生成 code layer、读写 Specs。
• 约束：Specs 是 Markdown 写的项目上下文（PRD、技术说明、可引用画布元素），Guidelines 让 agent 每次 prompt 都先读一遍你发布的设计规范。Figma 的 CDO 在 TechCrunch 采访里承认：AI 现在产出的代码行数是过去的 17 倍，但发布次数只涨了 1.3 倍——"很多代码不是为上线写的，是为探索产品是什么写的"。约束，就是用来对付这种"探索性代码"的。
• 成本：Code Layers 在 2026 年 11 月 4 日前对付费计划免费，之后走 AI credits。用 agent 读 Specs 同样消耗 credits。这意味着管线本身有计量成本，瞎 prompt 是要花钱的——后面会讲怎么省。

一句话总结：管线负责"意图不丢失"，你负责"意图先存在"。如果你的 Figma 文件本身是一团乱麻（Rectangle 47、Group 12、随手堆的图层），MCP 读到的就是一团结构化乱麻，AI 生成的代码只会是"有条理的丑"。

五阶段管线：每一步的输入、输出和验收标准

图 1：五阶段管线。核心纪律是"上游输出即下游输入"——跳过任何一阶段，后面都要加倍返工。

阶段 1：设计准备——给 AI 一份"读得懂"的设计稿

这是最不性感、但 ROI 最高的一阶段。MCP 传给 agent 的是图层树，不是渲染图，所以图层命名就是给 AI 的注释。验收标准很具体：

• 所有可交互元素都有语义化命名（btn-primary、card-pricing-pro），而不是 Rectangle 47。agent 会把图层名直接映射成组件名和 CSS 类名，乱命名 = 乱代码。
• 重复出现的 UI 必须收拢为 Component（按钮、输入框、卡片、导航），变体用 Variants。否则 AI 会为每个页面各生成一套按钮样式，你的设计系统名存实亡。
• 布局用 Auto Layout 而不是绝对定位。Auto Layout 的规则（间距、换行、对齐）会被翻译成 flex 布局；绝对定位的图层，AI 只能猜，最后大概率变成一堆 magic number。
• 文字用 Text Style、颜色用 Variables。硬编码的色值在 MCP 数据里就是裸字符串，AI 不会知道 #0E7C6B 和 #0E7C6C 应该是同一个品牌色。

一个人做产品，这一步通常 1-2 小时。别省：后面每个阶段省下的返工时间都是这里的十倍。

阶段 2：Token 沉淀——把"长得一样"变成"用的是同一个"

设计系统的本质是"约束"，token 是约束的载体。做法：

• 在 Figma 里用 Variables 定义颜色、间距、字号、圆角四类 token（先从这四类开始，别一上来搞全套）。
• 让 agent 读 Variables 生成 tokens.css（CSS 变量）或 theme.ts（TypeScript 常量），提交进仓库。从此所有 AI 生成的组件都引用 token，禁止硬编码色值。
• 定期跑一次"token 审计"：让 agent 对比 Figma Variables 和 tokens.css，列出所有该用 token 却写了硬编码的地方。这是防止设计漂移最便宜的办法。

这一步的产出物（tokens 文件）是阶段 4 的"宪法"：prompt 里写一句"所有颜色和间距必须用 tokens.css 里的变量"，AI 生成代码的一致性会跃升一个档次。

阶段 3：MCP 接入——5 分钟的配置，一劳永逸的上下文

远程 MCP 服务器地址是 https://mcp.figma.com/mcp，Claude Code、Cursor、VS Code 都能接。两种接法：

• 远程服务：所有 Figma 计划可用，配置最简单，适合一人开发者。注意需要给 agent 授权访问你的 Figma 文件。
• 桌面服务：需要 Dev 或 Full 席位（付费计划），走本地 WebSocket，延迟更低，还支持"实时 UI 捕获"（把跑起来的页面抓回 Figma）。一人开发者通常远程就够了。

接好之后的工作流是"选帧 → 复制链接 → 粘贴给 agent"。关键细节：一次只喂一帧或一个组件。把整个 20 页的设计稿链接丢过去，agent 的上下文会被图层树淹没，输出质量断崖式下跌。粒度控制是这条管线里最重要的人工技能。

阶段 4：AI 生成——四个能直接抄的 prompt 模式

这是管线里 AI 干活的部分。经社区反复验证，以下四种 prompt 模式产出最稳定（按推荐顺序）：

• 组件生成："读取我的 Figma 文件，把 [某屏名称] 生成为 React 组件，所有颜色间距用设计 token，放到 [src/components/]。"——粒度最小，成功率最高，先从这里建立信任。
• 整页构建："根据 Figma 文件生成 [页面名] 及子组件，Figma 组件名映射为 React 组件名，token 样式，文件放到 [src/pages/]，TypeScript props 补全。"——在组件库已沉淀后再用。
• Token 提取："读取 Figma 文件的 Variables 和 Styles，生成 tokens.css（CSS 变量）/ theme.ts。"——阶段 2 的自动化版本。
• 设计系统审计："扫描 Figma 文件，对比已用 token 和 tokens.css 里定义的 token，列出所有该用 token 的硬编码。"——回归测试，迭代中定期跑。

纪律：永远先组件、后页面。让 AI 一次生成整站首页的，返工率极高——不是 AI 不行，是你一次给了它太多"自由发挥"的空间。组件级生成的代码，人工 review 5 分钟就能合入；页面级生成，必须配阶段 5 的视觉 QA。

阶段 5：视觉 QA——MCP 没有消灭走查，只是把它变便宜了

这是最容易被跳过的一阶段，也是"AI 味"的主要来源。AI 生成的 UI 有三类典型走样：间距"差不多"、字号"约等于"、响应式断点"随缘"。QA 流程：

• 跑起页面，截图，与 Figma 设计稿并排放（肉眼对比，不要只信自己的感觉）。
• 把差异描述喂回 agent 修（"导航栏间距比设计稿大 8px，按钮圆角应为 8px 不是 4px"）——描述越具体，修得越准。
• 确认后，用 Code to Canvas 把最终版推回 Figma：设计稿和代码从此是同一真相的两个视图，下次迭代不用重新"翻译"。

一人开发者的现实标准：首屏和核心转化路径必须像素级对齐，后台管理页、设置页这种低频页面，"神似"即可。把 QA 火力集中在钱和用户第一眼的地方。

对照：同一件事，传统 Handoff 要走三轮，MCP 管线走一轮

图 2：传统 Handoff vs MCP 直连。MCP 没有消灭走查，只是把 3 轮人工翻译压缩成 1 轮生成 + 人工终审。

值得展开的是"仍然要人"这一行。有工作室称这条管线把前端构建时间砍掉六到七成（个案数据，仅供参考），但省掉的都是"翻译"时间，不是"判断"时间。以下四种情况，AI 目前仍然需要人兜底：复杂动效与过渡、深色模式/多主题下的 token 映射、多断点响应式的细节、以及品牌调性这种"说不清但看得出"的东西。管线的价值是把人的时间从"翻译"挪到"判断"上，而不是把人挪走。

三个反模式：每一条都是真金白银的教训

反模式 1：截图投喂。把设计稿截图丢给 AI 让它"照着写"。截图丢失了全部结构信息——AI 看不到 Auto Layout 规则、看不到组件复用关系、看不到 Variables，只能靠视觉猜。结果永远是"第一眼像，第二眼全是问题"，而且修起来比手写还慢。有 MCP 就别用截图，这是 2026 年最不该犯的错。

反模式 2：一次性整站生成。"把我这个 20 页的 Figma 文件变成完整网站。"听起来很爽，实际是灾难：上下文爆炸导致 AI 开始"脑补"，不同页面的同名组件各写一套，token 引用随缘。正确姿势永远是"小步快跑"：token → 原子组件 → 页面 → 串联，每步都有人 review。

反模式 3：跳过 token 直奔生成。设计稿里颜色都是裸值，AI 生成的代码里也全是裸值。三个月后你想换个品牌色，要改 47 个文件。Token 沉淀是整条管线里最便宜的保险，2 小时的工作量，保的是整个产品的可维护性。

成本账：这条管线到底贵不贵

给一人开发者算笔账。Figma 侧：Code Layers 在 2026 年 11 月 4 日前付费计划免费，之后按 AI credits 计量；远程 MCP 读取设计数据目前不额外收费（以 Figma 官方定价页为准）。AI 侧：MCP 上下文是按 token 计费的，一个中等复杂度的页面帧，结构化数据大约几千到上万 token——用 Claude/GPT 级模型，一次生成的成本通常在几毛钱人民币量级。真正的成本大头是返工：prompt 写得烂、一次喂太多、跳过 QA，每一次返工都是双倍 token + 你的时间。所以这条管线最省钱的用法恰恰是最"笨"的用法：小粒度、多 review、token 先行。

实战走一遍：定价卡片组件的完整对话

理论讲完，走一遍真实的。假设你的 Figma 里有一个定价卡片组件（Pro 档），已经按阶段 1 整理好：组件名 PricingCard，变体 plan=pro，颜色全部走 Variables。

第 1 步：沉淀 token。打开 Variables 面板，复制文件链接丢给 agent：

"读取这个 Figma 文件的 Variables，生成 tokens.css，只包含颜色、间距、字号、圆角四类，用 CSS 变量，命名按 --color-brand-500 这种层级。"

你会得到类似这样的文件（示意）：

:root {
  --color-brand-500: #0E7C6B;
  --color-text-primary: #1F2A44;
  --space-md: 16px;
  --radius-lg: 12px;
  --font-size-title: 20px;
}

人工检查一遍命名是否合理，提交进仓库。从这一刻起，所有后续 prompt 都加一句"只用 tokens.css 里的变量"——这是整条管线里性价比最高的一句话。

第 2 步：生成组件。在 Figma 里选中 PricingCard 组件，复制链接：

"读取这个 Figma 组件，生成 React + TypeScript 组件 PricingCard.tsx。要求：所有颜色/间距/字号引用 tokens.css 的变量；props 包含 plan、price、features 数组、ctaText；样式用 Tailwind 类名，但色值必须走 CSS 变量。"

第 3 步：视觉 QA。跑起来截图，和 Figma 并排看。你大概率会发现一两处"差不多"：比如特性列表的行高、勾选图标的大小。把差异描述喂回去，越具体越好：

"特性列表行高比设计稿小 4px，勾选图标改为 16px，卡片阴影用 --shadow-card token。"

第 4 步：回写。确认无误后，用 Code to Canvas 把最终渲染推回 Figma。设计稿里的 PricingCard 和代码里的 PricingCard 从此同源，下次改设计直接走同一条管线。

整个过程 20-30 分钟。关键不是速度，是每一步都有可检查的中间产物：tokens.css、组件文件、截图对比。管线里任何一步跳过检查，债都会在后面连本带利还回来。

Specs 写什么：给 agent 的上下文说明书

管线跑顺之后，你会发现 prompt 里总在重复同一类背景信息：品牌调性、目标用户、技术约束、"不要用什么"。这些东西就该沉淀到 Figma Specs 里——它是画布上的 Markdown 文档，agent 每次干活前都会读。一个一人开发者够用的 Specs 只需要四节：

• 设计语言：品牌色怎么用、圆角/阴影的性格（"克制、少装饰"比"好看"管用）、深色模式规则。
• 组件契约：按钮有几种、分别什么时候用；表单校验的交互规范；空状态/报错状态的统一写法。
• 技术约束：技术栈（Next.js + Tailwind）、token 文件位置、"禁止硬编码色值"这类硬规则。
• 反模式清单：你过去踩过的坑（"不要用渐变背景""弹窗必须有关闭按钮"），写下来，agent 就不会再犯。

Specs 的维护纪律：每次视觉 QA 发现"这类问题下次别再犯"，就加一条进 Specs。它是你和 agent 之间的"团队规范"，只不过团队只有你一个人。配合 Guidelines（发布到设计库、每次 prompt 自动读取），约束就从"靠你每次叮嘱"变成了"基础设施"。

什么时候不要用这条管线

诚实地说，有三种情况传统手写（或纯 prompt 生成）更合适：第一，你根本没有设计稿，只有一个模糊想法——先让 AI 用 v0 这类工具出几版视觉探索，定调了再进 Figma 管线，别为了"流程正确"先画两周图。第二，营销落地页这种"一次性"页面，设计即代码（直接在 v0/Lovable 里调）更快，不值得建 token 体系。第三，高度定制化的营销动效站，AI 生成的动效代码质量目前还不如手写，管线省的时间全花在调动效上了。

管线的甜蜜点是：有相对稳定的设计语言、需要长期迭代的产品型项目——SaaS、工具、后台、移动端应用。一次性页面用一次性方法，长期产品建长期管线，别搞反。

一页纸检查清单

• 图层命名：无"Rectangle N""Group N"，组件名即代码名
• 组件化：重复 UI 已收拢为 Component + Variants
• 布局：Auto Layout 覆盖主要页面，无大面积绝对定位
• Token：颜色/间距/字号/圆角四类 Variables 已定义，tokens.css 已进仓库
• MCP：远程服务器已接通，一次只喂一帧
• 生成顺序：token → 原子组件 → 页面，prompt 用四模式之一
• QA：首屏与转化路径截图对比走查，终版回写 Figma
• 成本：大粒度生成前先估 token，返工是最贵的消费

最后说一句：这条管线最大的变化不是"更快"，是设计稿第一次成了"可执行的真相"。以前设计稿是"希望"，代码是"现实"，两者之间的 gap 靠人肉填。现在 MCP 让两者读同一份结构化数据，gap 变成了可自动化、可测试、可回滚的东西。对一人开发者来说，这意味着你终于可以"只维护一份真相"——改设计就是改代码的输入，而不是改完设计再祈祷代码跟上。