Figma AI三分法：原型与MCP-知了AI

过去一年里，我见过太多团队在 Figma 里”用 AI”，结果约等于在 Figma 里多开了一个对话框。设计师让 AI “把这个页面做得更好看一点”，AI 返回一堆似懂非懂的图层堆叠，然后双方互相失望。问题不在模型，而在把三种完全不同的活儿塞进了同一个入口。

Figma 这两年的 AI 能力其实已经分化成三条独立的路径：Figma Make 负责把想法或者现有设计跑成可交互的原型与 Web 应用；Figma MCP Server 把设计上下文（组件、变量、token、Spec）喂给外部代码智能体；Figma Agent 直接站在画布上，按你的指令修改图层。三条路径的输入形态、验证方式、失败代价都不一样。

这篇文章要讲的”三分法”，就是把这三种能力各自钉在它最擅长、最便宜、返工成本最低的位置上。说起来像方法论，其实落到操作层面非常具体：什么时候该开 Make、什么时候该切到 IDE 里挂 MCP、什么时候该在画布里跟 Agent 说一句”选中这个 Frame，把间距改成 8 的倍数”。

先讲结论：三分法的本质是按“变更成本”分工

很多介绍 Figma AI 的文章会把功能列成一张长长的清单，然后告诉你”这些都很强”。这种写法对读者没有帮助，因为真正的困难从来不是”不知道有这个功能”，而是”不知道这个场景该用哪个”。

为什么按功能清单分工是错的

按功能分工的隐含假设是：功能之间可以互相替代。用 Figma Make 也能改画布（它能把预览带回画布变设计图层），用 Agent 也能做个能点的原型（让它在画布里堆几个 Frame 加拉线），用 MCP 也能生成界面代码。看起来三条路径哪里都能去，于是选择就变成了”哪个顺手用哪个”。

但实际项目里，这三条路径的变更成本曲线完全不同。我用一个真实经历说明：一个 B 端数据看板项目，设计评审会上运营说”表格行高再紧一点、筛选器挪到右上角”。这种改动在画布里由 Agent 执行，三十秒；用 Figma Make 重新生成一版预览，五分钟且可能连带改坏别的部分；推给代码智能体改 React 组件，那是半小时加一次 PR。同一句话，三条路径的成本差了六十倍。

变更成本的三层结构：视觉层、逻辑层、代码层

所以三分法的底层逻辑是一句话：让每一种 AI 去干它那一层”改了最便宜”的活。

层级	变更内容	失败代价	最便宜的路径
视觉层	间距、颜色、文案、组件替换、自动布局	几秒钟重来，肉眼可验	Figma Agent 直接在画布上改
逻辑层	交互流程、状态切换、数据联动、页面跳转	几分钟，需要点击验证	Figma Make 跑可交互原型
代码层	组件实现、样式映射、真实 API 对接	小时级，需要 CI 与评审	Figma MCP 喂上下文给代码智能体

这张表的读法是从上往下：越往上，改起来越便宜、验证越快；越往下，改一次越贵，但下游价值越大。三分法的纪律就是——绝不在上层的问题还没收敛时，提前进入下层。设计意图没定，就先去写代码，是最贵的一种浪费。

一句话记忆法

如果只记一句话，我会这样总结：Make 负责”能不能跑”，MCP 负责”跑得像不像”，Agent 负责”长得对不对”。三个问题分属三个时间点：探索期问能不能跑，交付期问像不像真实产品，打磨期问细节对不对。顺序反了，成本就翻倍。

分工决策表：拿到一个任务，30 秒选对入口

下面这张表是我在团队里实际用的版本，按”你手上有什么”倒推入口。它的好处是不要求你先理解 Figma AI 的全部能力，只要求你回答两个问题：手上有没有已成型的设计？产出要交给谁？

你的起点	你要的产出	给谁看	推荐入口	关键动作
只有一句话想法，没有设计稿	能点、能跳转的原型	产品、运营、老板	Figma Make	写结构化提示词，先跑主流程
已有 Figma 设计稿，想验证交互	可交互原型	评审会	Figma Make	选中 Frame 作为输入，生成后拉回画布
已有设计稿，要在画布上微调	改好的设计图层	设计师自己	Figma Agent	对象—目标—约束三段式提示词
设计定稿，要写真实代码	组件代码 / PR	工程师	Figma MCP	配远程 MCP，选中 Frame 转代码
已有组件库，要保证代码复用	用真实组件的代码	前端架构师	Figma MCP + Code Connect	先建立 Code Connect 映射
需求复杂，多人协作	清晰的 Spec	整条链路	figma-spec skill + Agent	先写 Spec，再让 Agent 回写决策
线上页面要变成可编辑设计	设计图层	设计师	MCP 代码转画布	确认组件映射质量再导入

这张表里有两行容易被忽略，我单独强调：“已有设计稿，要在画布上微调”请务必走 Agent 而不是 Make。Make 会重新生成，重新生成意味着不可预测，不可预测对一个已经通过评审的设计稿来说是灾难。“已有组件库”那一行请务必加 Code Connect，否则代码智能体会输出一堆长得像你的按钮、但不是你那个按钮的 div。

Figma Make：把想法跑成能点的东西

Figma Make 的定位是”从提示词到可交互原型与 Web 应用”。它接受两类输入：一句描述，或者你已有的 Figma 设计。输出是可以真实点击、有状态、有页面切换的东西，而不是静态画板。

Make 最适合的三类场景

第一类，需求澄清型原型。产品经理嘴上说”做一个审批流”，团队里三个人脑补出三个版本。这时候用 Figma Make 花十分钟跑一版出来，比开一小时会有效得多。原型的目的不是好看，是让分歧显形。

第二类，交互路径验证。比如注册流程有四个分支，每个分支的失败态怎么提示、能不能返回、返回后状态保不保留。这些东西在静态稿里画不出来，只能点着看。Make 的强项就是这种”流程感”。

第三类，高保真演示。给外部客户演示时，一个能点的东西和一个 PPT 的说服力差一个量级。这里要注意一点：Make 产出的是演示品，不是交付品，别让客户以为那就是最终产品。

Make 不该接的活

反过来，有三件事我会明确从 Make 手里拿回来。一是像素级还原，Make 生成的东西间距通常需要人工校；二是已有设计稿的小修小改，重新生成的代价远高于直接改；三是需要复用你们组件库的页面，Make 不保证输出你手册里的组件，除非你走”预览拉回画布”这条路再替换。

提示词怎么写：四段结构比”描述得漂亮”更重要

我见过的失败提示词，九成是”太文学”。比如”做一个让人感觉愉悦的记账应用”，这种输入模型只能猜。有效的提示词是工程文档式的，我固定用四段：角色与场景 → 页面清单 → 数据与状态 → 约束条件。

第一段：角色与场景

写清楚谁用、在什么设备上、什么环境下用。不说”用户”，说”每天通勤时用单手操作手机记账的上班族”。这一段决定了信息密度和触控尺寸。

第二段：页面清单

把页面和跳转关系列成清单，一行一个页面。Make 对清单式输入的处理明显好于散文式。每个页面后面括号注明”入口”和”出口”，相当于给它画了张流程图。

第三段：数据与状态

这是最容易被漏掉、也是决定原型”像不像真的”的一段。要写空状态、加载状态、错误状态、超长文本状态。原型评审时被问得最多的永远是”如果没有数据呢”。

第四段：约束条件

颜色只用哪几个、圆角统一多少、字体用什么、不要做哪些东西。约束越具体，模型跑偏的空间越小。

【角色与场景】
- 用户：25-35 岁上班族，每天通勤地铁上单手操作
- 设备：iPhone 15 视口 393×852，触控目标不小于 44px

【页面清单】
1. 首页（入口）：本月支出总额 + 最近 5 笔记录 → 点「+」进记账页，点记录进详情
2. 记账页：金额输入、分类选择、备注 → 保存后返回首页并置顶新记录
3. 详情页：单笔完整信息 → 可删除，删除后返回首页
4. 统计页（底部 Tab）：按分类的环形图 → 点击分类跳转到该类明细

【数据与状态】
- 空状态：首页无记录时显示插画 + "记下第一笔"按钮
- 加载态：列表用 3 条骨架屏，不超过 800ms
- 错误态：保存失败时顶部 Toast，保留用户已填内容
- 长文本：备注超过 20 字截断加省略号

【约束条件】
- 颜色：主色 #1F6FEB，背景 #F7F8FA，文字 #1A1A1A / #6B7280
- 圆角：卡片 12px，按钮 8px
- 字体：系统默认，标题 20/600，正文 15/400
- 不要：不要做社交分享，不要做多币种，不要加引导页

这套模板的关键在于可验证。跑完之后你可以逐条对照，缺哪条补哪条，而不是凭感觉说”感觉不太对”。

在本地代码库上跑 Make（Beta 的用法与预期管理）

Figma Make 现在支持在本地代码库上运行，这是 Beta 阶段的闭测能力。它带来的变化是：生成的预览可以直接跑在你们真实的项目结构里，用你们真实的组件和样式变量，而不是一个空白环境。

实际使用时心态要放平。这是一个闭测功能，意味着文档不全、行为可能变、遇到问题大概率要靠自己摸索。我的建议是先在独立分支上试，不要直接在主干跑，也不要指望它一次性理解你们那套祖传的构建配置。先让它跑通最简页面，再逐步加复杂度。

把预览拉回画布：从”生成的网页”到”可复用图层”

这是 Figma Make 最被低估的一步。原型跑完、评审通过之后，很多人就把那个预览丢在一边，然后设计师从头画一遍。正确的做法是把预览带回 Figma 画布，变成设计图层（design layers）。

带回来的图层是真正可编辑的设计对象，不是截图。这意味着它继承了 Figma 的一切能力：自动布局、变量绑定、组件化。重建的时候，关键动作是复用手册里的组件——把 AI 生成的”看起来像按钮的矩形”替换成你们真正的 Button 组件，把散落的颜色值绑到语义变量上。

我把它总结成一个三步操作：先带回，再替换，最后绑变量。带回只用了两分钟，替换和绑变量才是一小时的工作量，但这一小时换来的是一个可以进入设计系统的产物，而不是一个孤儿页面。跳过这一步，你就得到了一个看起来很棒却完全无法维护的资产。

Figma MCP：把设计上下文喂给代码智能体

如果说 Make 解决的是”想法到可点”，那 MCP 解决的是”设计到代码”之间那道老墙。这道墙存在了很多年，本质问题是：代码智能体能读你的代码，但读不懂你的设计；设计师能给你设计，但给不出结构化的约束。

设计上下文到底是什么

“设计上下文”这个词被用得很泛。在 Figma MCP 的语境里，它至少包含五层东西：图层结构与命名、组件与变体、设计变量（颜色、数字、字符串）、样式与 token 的对应关系、团队的 Spec 文档。

这五层的重要性是递减的吗？恰恰相反。图层的宽高和坐标，代码智能体看一眼就能猜个大概；真正让它输出”像你们写的代码”的，是后面几层。这也是为什么单纯的”截图 + 描述”永远做不出生产级代码——它丢掉了最贵的那部分信息。

远程 MCP 还是桌面端 MCP：默认选远程

Figma MCP Server 有两种接入方式。远程接入地址是 https://mcp.figma.com/mcp，推荐使用，不需要装桌面端，功能最全。桌面端 MCP 主要面向组织/企业的一些特定需求，使用方需要 Dev 或 Full 席位。

维度	远程 MCP（推荐）	桌面端 MCP
接入地址	https://mcp.figma.com/mcp	本地桌面客户端提供
是否需要装桌面端	否	是
功能完整度	最全，含写画布等能力	覆盖有限
席位要求	按常规权限	需 Dev 或 Full 席位
适用对象	绝大多数团队与个人	有特定合规诉求的组织/企业

我的建议很直接：没有明确的企业级特殊诉求，一律用远程 MCP。远程方案少一层本地进程，团队里所有人的配置一致，新人接入只需要一份 JSON。

接入配置：三个客户端的最小可用配置

远程 MCP 是标准的 HTTP 类型服务。下面是 Claude Code、Cursor、VS Code 三种常见客户端的配置写法，改动很小，但格式差异经常让人卡住。

// 1) Claude Code（命令行添加）
claude mcp add --transport http figma https://mcp.figma.com/mcp

// 2) Cursor（~/.cursor/mcp.json 或项目 .cursor/mcp.json）
{
  "mcpServers": {
    "figma": {
      "url": "https://mcp.figma.com/mcp",
      "transport": "http"
    }
  }
}

// 3) VS Code（.vscode/mcp.json）
{
  "servers": {
    "figma": {
      "type": "http",
      "url": "https://mcp.figma.com/mcp"
    }
  }
}

配完之后，在对话里让它”读取当前选中的 Figma Frame 并生成 React 组件”，能拿到图层信息就说明通了。Codex、Gemini CLI、Copilot CLI、Warp 等客户端也是同样的思路，差别只在配置文件的位置和键名。

五类能力：从读上下文到写画布

Figma MCP 的能力我按”方向”分三类、按”粒度”分五项，实际使用时最好把它们看成两条流水线：读方向（Figma → 代码智能体）和写方向（代码智能体 → Figma）。

读方向其一：读取设计上下文与代码

这是最基础也最高频的能力。智能体可以读取选中区域的结构、命名、组件引用、变量绑定，也可以读取相关的代码文件。价值在于，它让”这个按钮用的是什么间距”这种问题不再需要人来翻译。

读方向其二：选中 Frame 转代码

选中一个 Frame，让智能体把它转成组件代码。这里有个经验：Frame 选得越小，结果越好。整页结构交给它，它会给出一坨嵌套 div；单个卡片、单个表单交给它，往往达到可以提交 PR 的水准。我的习惯是自上而下拆，每次只转一层。

读方向其三：读取 FigJam 与 Make 资源

Figma MCP 能读取 FigJam 里的白板资源，也能读取 Figma Make 的资源。前者在需求梳理阶段很有用——白板上的流程草图可以直接变成上下文；后者让”Make 里跑出来的原型”可以直接被代码智能体接手，形成连续链路。

读方向其四：download_assets 拿到真实文件

这一项经常被误解。它返回的是真实可导出的文件——SVG、PDF、JPG，而不是截图。区别在于矢量可缩放、可再编辑、可进构建流程。图标做 SVG、交付物做 PDF、预览图做 JPG，按需指定即可。别再用截图代替导出了，那张截图在代码里是个死图层。

写方向其一：写画布（Remote MCP 专属，Beta）

这是最容易被吹过头的功能。写画布允许代码智能体把改动写回 Figma，但它是 Remote MCP 专属能力，需要配合 skills 辅助，而且处于 Beta 阶段，目前免费，未来会按用量收费。

我对它的判断是：能写不等于该写。让它把一个已有的、结构清晰的页面按规则批量改几十处，效果好；让它从零搭建一个复杂页面，你会得到一个结构混乱、命名随意、层级混乱的产物，后续清理成本高于手绘。真实的可用边界在”批量、规则明确、结构简单”这一侧。

写方向其二：代码转画布

反过来，把线上或者本地正在跑的真实 UI 变成可编辑的设计图层。这在接手遗留项目时特别好用——线上界面没有设计稿？直接把它变成设计稿。前提是组件映射质量要过得去，否则你会得到一堆散碎的图层。

Code Connect：解决”生成的代码不是你那个按钮”

如果只做一项投资，我会选 Code Connect。原因很朴素：代码智能体最大的浪费不是写得慢，而是写出来的东西不能用。它给你一个手写的 button，样式一模一样，但你们团队用的是 <Button variant="primary" />，那一百行手写的 CSS 就是纯负债。

Code Connect 的作用是让生成的代码复用真实组件：你告诉 Figma “这个设计组件对应仓库里的那个代码组件”，之后生成时它会直接引用。下面是一个映射文件的示意结构。

// 文件位置：组件代码同目录下 Button.figma.tsx
import { figma } from '@figma/code-connect';
import { Button } from './Button';

figma.connect(Button, 'https://www.figma.com/design/<file-key>/<file-name>?node-id=12-3456', {
  props: {
    // 设计侧变体 → 代码侧 props
    variant: figma.enum('Style', {
      Primary: 'primary',
      Secondary: 'secondary',
      Ghost: 'ghost',
    }),
    size: figma.enum('Size', {
      Small: 'sm',
      Medium: 'md',
      Large: 'lg',
    }),
    disabled: figma.boolean('Disabled'),
    // 文本层 → children
    children: figma.string('Label'),
  },
  example: ({ variant, size, disabled, children }) => (
    <Button variant={variant} size={size} disabled={disabled}>
      {children}
    </Button>
  ),
});

建立映射之后，再让 MCP 生成代码，输出的就是 <Button variant="primary" size="md">提交</Button> 这样干净的一行。这是设计上下文真正产生复利的地方——一次投入，长期受益。

figma-spec skill：让需求先变成可执行的规格

Figma 还提供一个 figma-spec skill（目前处于开放测试），可以读写团队的 Spec。它的价值在于把”口头需求”变成”文档化需求”，并且让 Agent 把决策与发现写回 Spec。

我把它用作链路的起点。以前是产品写需求文档、设计师画图、工程师看代码，三份东西各自演进，最后谁也不知道谁是对的。现在是先用 figma-spec skill 把需求写清楚，Agent 在执行过程中把决策和发现回写进 Spec，Spec 本身成了单一事实来源。

# 规格模板：登录模块 v1.2（写在团队 Spec 中）

## 目标
支持邮箱密码登录、第三方登录、找回密码三条路径，首屏到登录成功不超过 3 步。

## 对象
- Frame：Login / Desktop-1440（node-id=12-3456）
- 组件：Input、Button、Divider（均为设计系统 v2.3）

## 约束
- 输入框高度统一 40px，圆角 8px，错误态边框 #D93025
- 主按钮宽 100%，与输入框间距 24px
- 不允许新增颜色 token，只用语义变量 color/text/* 与 color/bg/*

## 状态清单
- 默认 / 聚焦 / 填充 / 校验失败 / 提交中 / 成功跳转
- 第三方登录：排队中、授权失败可重试

## 验收
- [ ] 所有颜色均绑定语义变量，无硬编码色值
- [ ] 错误文案在 320px 宽度下不换行截断
- [ ] 键盘 Tab 顺序与视觉顺序一致

## 决策记录（Agent 回写）
- 2026-10-28：第三方登录按钮采用图标 + 文字，因可访问性评审要求可读文本。
- 2026-10-29：校验失败态改为输入框内联提示，替代顶部 Toast，减少视线跳转。

注意最后的”决策记录”。这一块是整份 Spec 最值钱的部分，因为它记录的是为什么，而不是是什么。三个月后接手的人，看代码能知道是什么，只有 Spec 能告诉他为什么。

Figma Agent：按“对象—目标—约束”改画布

Figma Agent 是原生在画布上的智能体，它基于你的组件与 token 去探索方向。注意这个定语——基于你的组件与 token。这意味着它的产出质量，上限由你的设计系统质量决定。设计系统混乱的团队，让 Agent 改画布会得到一份更混乱的产物。

为什么”帮我改好看点”必然失败

画布上的智能体面对的是一个巨大的搜索空间：几百个属性、几十个图层、无限种组合。”好看”这个目标在这个空间里没有梯度，模型只能随机挑一个方向走。你收到的结果感觉不对，但说不出哪里不对，于是再改一句”再精致一点”，循环往复。

三次这样的循环之后，设计师会得出”AI 改画布没用”的结论。其实不是没用，是目标函数没定义。三段式提示词就是为了补上这个目标函数。

三段式的第一段：对象——精确到图层

对象段要回答”改哪里”。含糊的说法是”这个页面””这一块”，精确的说法是”选中 Frame 下的 Card 组件实例，不含底部操作栏”。三个要素：范围（哪个 Frame / 哪个组件）、边界（不含什么）、数量（全部还是仅某几个）。

对象写清楚还有一个隐含好处：它强迫你先在画布上把范围选出来。选中动作本身就是一种确认，避免了”它改了我没想让它改的地方”。

三段式的第二段：目标——可验证的结果

目标段要回答”改成什么样”，而且必须是可验证的。可验证的意思是：改完之后，你可以用一句话判断对错，不需要审美争论。

“更现代”不可验证，”把圆角从 16 改成 8、卡片阴影改为 1px 描边”可验证。”更有层次”不可验证，”标题字号从 20 提到 24、正文颜色从 #1A1A1A 降到 #6B7280″可验证。原则很简单：把形容词翻译成属性名和数值。

三段式的第三段：约束——不能动的东西

约束段要回答”什么不能碰”。这是三段式里最容易被忽略、但最能减少返工的一段。至少要覆盖三件事：不能改的属性（比如自动布局方向）、不能新增的东西（比如新颜色、新字体）、必须遵守的规范（间距用 4 的倍数、只用语义变量）。

有个反直觉的观察：约束写得越严，Agent 的产出反而越接近你想要的。因为约束实质上是在缩小搜索空间，把”无限种改法”压缩成”几种改法”，模型的概率分布就集中了。

完整模板：一段可以直接复制使用的三段式提示词

【对象】
- 范围：当前选中的 Frame「Pricing / Desktop」，包含其中 3 个 Plan Card 实例
- 边界：不改顶部导航、不改底部 Footer、不增删任何 Card
- 数量：3 个 Card 全部应用

【目标】
1. Card 内边距：上下 24px → 32px，左右 24px → 28px
2. Card 圆角：16px → 12px；边框由 1px #E5E7EB 改为 1px #E5E7EB + 0 2px 8px rgba(0,0,0,0.04)
3. 价格文字：字号 36 → 40，字重 700，用变量 typography/price
4. 中间推荐 Card 增加「推荐」标签，位置右上角，距边缘 8px
5. 三个 Card 之间的间距：24px → 16px

【约束】
- 必须保留现有自动布局（垂直方向），不得改为绝对定位
- 不得新增任何颜色，只能用现有变量：color/bg/default、color/border/subtle、color/text/primary
- 所有间距必须是 4 的倍数
- 文案一个字都不改
- 组件实例不得打散（Detach）
- 完成后列出每一处改动，并标注是否有超出上述范围的操作

最后一条”完成后列出每一处改动”是关键。它把 Agent 从”黑箱执行者”变成了”会汇报的执行者”，你验收时不需要逐层点开，看它自己的清单就够了。如果清单里出现了你没要求的东西，说明约束没兜住，回去补约束。

三个反例：这样写一定会返工

反例一：目标不可验证

【反例】把这个定价页做得更高级、更有呼吸感，参考一下 Linear 的风格。

问题有三：没有对象边界（价格页还是整个落地页？）、目标无梯度（”高级”不是属性）、”参考 Linear”是外部引用，Agent 只能猜你说的 Linear 是配色还是排版。改完你大概率会说”不是这种感觉”，但说不出具体哪里。

反例二：只给目标，不给约束

【反例】把三个卡片的间距调小一点，圆角改小，加个阴影。

缺少约束的后果是 Agent 会”顺手”做一些合理但你不想要的事：打散实例、换成绝对定位、加一个新的阴影 token。改动看起来没错，但你的设计系统被污染了。等你发现的时候，已经有十几个 Frame 用了那个野 token。

反例三：对象过于宽泛

【反例】优化一下整个设计稿的排版。

这是最危险的一种。”整个设计稿”可能包含二十个页面，Agent 会找一个它觉得最合理的统一规则去套，比如把所有标题都调成同一字号。结果是它确实优化了，但把页面之间的层级关系抹平了。范围越大，越像在掷骰子。

什么时候别用 AI 改画布：四条边界

这一节可能比前面所有操作技巧都重要。我见过太多团队因为不设边界，把 AI 用成了技术债制造机。

边界一：设计系统本身在变的时候

Agent 基于你的组件与 token 工作。如果设计系统正在重构（变量重命名、组件合并、间距体系调整），这时候让 Agent 改画布，等于在一个移动的地基上盖房子。它会用旧 token 覆盖新 token，你事后排查的成本比手改高得多。设计系统冻结期之外，不要让它动结构。

边界二：关键转化路径与品牌资产

边界三：需要审美判断的原创工作

三段式提示词的强项是”从 A 改到 B”，这在本质上是执行。而”这个页面应该是什么气质”属于判断，判断依赖对产品、用户、竞品的整体理解，这不是提示词能补的。原创的主视觉、新手期的落地页第一屏，这些地方人的价值最高，Agent 只能当参考。

边界四：没有 Spec、没有验收标准的任务

这条边界是给团队用的。如果一件事连验收标准都写不出来，说明需求本身没想清楚。这时候让 Agent 动手，它只会把一个模糊的需求变成一个模糊的实现，并且消耗掉团队对 AI 的信任。先写 Spec，再动手——这也是为什么会用 figma-spec skill 的团队，Figma AI 的产出质量明显更稳定。

闭环工作流：设计 → 代码 → PR → 回画布

前面三部分讲的是单点，这一节讲串联。三分法真正发挥威力，是在它变成一个闭环的时候。

第一段：设计——用 Spec 定意图

起点不是画图，是写 Spec。用 figma-spec skill 把对象、目标、约束写成可执行条款。这一步的产出直接就是后面三段提示词的素材来源——你会发现写 Spec 写得清楚的人，三段式提示词也写得好，因为它们是同一件事的不同颗粒度。

第二段：原型——Make 验证，拉回画布

Spec 定完，用 Figma Make 跑一版可交互原型，重点是验证流程和状态，而不是视觉。评审通过后把预览带回画布变成设计图层，然后把组件替换成手册里的真实组件、颜色绑到语义变量。这一步之后，你手上就有一份既经过流程验证、又符合设计系统的设计稿。

第三段：代码——MCP 喂上下文，Code Connect 保复用

切换到 IDE，通过远程 MCP 让代码智能体读取设计上下文。顺序建议是：先转单个组件、再转区块、最后转页面。Code Connect 映射在第一次就要建好，否则前面几轮生成的代码都得推倒重来。

这里有个细节值得强调：让智能体生成代码时，明确要求它先列出它读到的 token 与组件映射，再开始写。这一步能提前暴露它是否真的读到了设计上下文，避免它凭截图脑补。

第四段：PR——让评审带上画布链接

PR 里附上 Figma 的 Frame 链接，评审人可以在同一处对比设计意图与实现。对于视觉走查，这比截图对比准确得多，因为链接指向的是最新版本，而截图会过期。

第五段：回画布——发现差异反哺设计

代码合入后，产物不一定和设计完全一致：可能是实现受限，可能是设计本身有疏漏。这时候用 MCP 的代码转画布能力，把线上或本地跑着的真实 UI 转成可编辑图层，再对照原稿找差异。

差异分两种，处理方式完全不同。如果差异源于实现妥协，那就回画布调整设计，让设计说真话；如果差异源于设计疏漏，那就更新 Spec，并把这次发现写进决策记录。这一步让闭环真正闭上了——不是流程闭合，而是认知闭合：下一次再做类似页面，Spec 里已经有前车之鉴。

成本与用量：把 Figma AI 当预算管

Figma 的 AI 用量按 AI credits 计费，企业版可以按团队或部门分配。这件事在生产环境里会真实影响你的使用方式。我的做法是把 credits 当预算管，而不是当免费资源用。

具体分三档：探索档（Make 跑早期原型、Agent 试探方向）花得多但单价低；生产档（MCP 生成代码、Code Connect）花得少但要保证质量；整理档（批量改画布、代码转画布）单价最高，尤其写画布未来会按用量收费，别用它做本该手做的整理工作。

常见误区与纠偏

最后把几个我反复看到的误区集中说清楚。

误区一：以为三个入口可以互相替代

它们能做的事有重叠，但成本曲线不同。重叠区域里选哪个，答案永远是”选变更成本最低的那个”。

误区二：以为 MCP 能写画布就不需要设计师

写画布目前的真实边界在”批量、规则明确、结构简单”。让它从零设计一个页面，你会得到一个需要大修的半成品。它的定位是执行器，不是设计者。

误区三：以为提示词越”专业”越好

恰恰相反，这张场景下最有效的提示词是工程文档式的：清单、数值、边界。形容词越少，结果越稳。

误区四：跳过 Spec 直接动手

这是复利最大的一个误区。Spec 写清楚一次，后面每一步都受益；不写，每一步都要重新解释一遍意图，而且解释得不一致。

FAQ

Q1：Figma Make 生成的原型能直接交给开发吗？

不建议。Figma Make 的产出是演示品，目的是让人理解流程和状态，不是生产代码。正确的路径是把预览带回画布变成设计图层，再通过 Figma MCP 让代码智能体基于设计上下文生成代码。中间这一步的组件替换和变量绑定不能省，省了就等于把 AI 生成的临时结构带进了代码库。

Q2：远程 MCP 和桌面端 MCP 到底该选哪个？

默认选远程，地址是 https://mcp.figma.com/mcp，不需要桌面端，功能最全。桌面端主要面向组织/企业的特定需求，且需要 Dev 或 Full 席位。只有当你们有明确的合规或企业内部系统对接要求时，才考虑桌面端。团队里最省事的做法是全员统一用远程配置，一份 JSON 复制过去即可。

Q3：MCP 写画布能用在正式项目里吗？

可以用在正式项目里，但要限定场景。它需要配合 skills 辅助，处于 Beta 阶段，目前免费，未来按用量收费。我建议只用于”批量、规则明确、结构简单”的改动，例如把二十个 Frame 的圆角统一从 16 改成 12、把一批图层按规则重命名。让它从零搭建复杂页面，得到的结构通常需要大修，反而更贵。

Q4：Code Connect 需要每个组件都建吗？

不需要全部建，优先建高频组件：Button、Input、Card、Modal、Table 这几类。判断标准是”生成代码时最常被写成手写 div 的那些”。建之前先确认设计组件与代码组件的 props 语义对齐，如果设计侧的变体命名和代码侧完全对不上，先把命名统一，再建映射，否则映射文件本身会成为新的债。