Figma Make:以设计系统为上下文入口的 prompt-to-app,回路终点是托管 URL 而非你的仓库
figma-make
Figma Make 是 prompt-to-app 这条赛道里唯一以「你已在维护的设计文件」为第一上下文的:挂载 team libraries、组件、variables 与 styles,打包成 Make kit 供团队复用;编辑用 edit tool 点选元素、draw tool 圈画区域、annotations 逐元素下指令,把「我说的是哪个按钮」从文字描述变成视觉指点。但回路终点是 Figma 托管的 URL(AWS + Cloudflare),不是你的 GitHub 仓库——有 code editor、能导出代码,却没有 PR→CI 这条路。成本按 credits 计:Professional Full seat 3,000/月、中等 app 约 75+/次、plan mode 另计一次,额度是「几次对话」而非「几个 app」。发布即公开且无法限制访问,预览内拿不到摄像头/麦克风,第三方素材权利归你。
- 置信度
- 厂商宣称
- 只有官方模型卡/发布会,无独立复测
- 关键指标
- 上下文入口
- 厂商宣称 · 2026-09
- 成熟度
- 产品
- 研究 → 演示 → 产品 → 生产
编辑判断Make 在 code 域里的位置很特殊:它不是从需求出发,而是从你已经在维护的设计文件出发。v0 / Lovable / Base44 的第一句话是 prompt 或 PRD,Make 的第一个上下文是 team libraries、组件、variables 与 styles,再打包成 Make kit 发给团队复用。对已经把设计系统当资产在养的团队,这条入口省掉的是「把设计翻译成文字描述」这一整段损耗,而没有见到别家做到同等深度。这是把它列进 code 域的理由,也是它拿 design 纵轴的原因。
第二点是它把「指哪改哪」做成了产品原语:edit tool 点选元素改属性、draw tool 圈画区域进 prompt、annotations 给单个元素下指令。UI 迭代的沟通成本大头一直是「我说的那个按钮是哪一个」,Make 用视觉指点替代了文字描述,这一条在文档里有明确对应,不是宣传语。
但有一条必须讲清楚的边界:它的回路终点是 Figma 托管的 URL,不是你的仓库。v0 走 PR→merge→部署且分支保护照常生效,Make 有 code editor、能导出代码,却没有「连你的仓库、开 PR、过你的 CI」这条路。所以它适合设计侧自证与原型交付,不适合替代工程交付链。另外预览里拿不到摄像头与麦克风,要验证媒体采集必须先发布到公网——这会改变验证顺序。发布即公开且无法限制访问、第三方素材的权利责任归你、内容治理由 Figma 单方裁定,这三条对商用交付都是要过一遍的。
成本口径值得单独提:credits 按 seat 归属、月度重置、不结转不可转让,Professional Full seat 3,000/月,而官方给的中等复杂度示例是 75+ 一次,plan mode 还额外计一次。额度是按「几次对话」算的,不是按「几个 app」算的,把它当无限用会在月中撞墙。官方没有任何公开的正确性基准,数字全是近似值且随模型优化变动,因此卡片置信度记 C 级(厂商宣称),尚未复测。
它到底交付什么
Figma 官方对 Make 的定义是「an AI-driven, prompt-to-app tool」:把想法和已有的 Figma 设计变成可交互的 app,通过对话来 ideate、迭代、改进。交付物有两层——一层是 Make 文件里的真实代码(带代码编辑器,可以自己粘代码进去再对话改),另一层是发布出去的一个网址(组织内可见,或公开到公网,也可绑自有域名)。
它和 v0 / Lovable / Base44 的起点不同:那三者从一句话或一份 PRD 开始,Make 从你团队已经在维护的设计文件开始。文档明确写了可以把已有的 designs、components、Community 内容和别的文件挂到 prompt 上,并且 Make kit 允许把 npm 包、从设计库导入的 variables 与 styles、以及「这些资产该怎么用、怎么表现」的 guidelines 一起打包发布给团队。这条「设计系统当事实来源」的入口,是它在 design 纵轴上的真实位置。
agent 能力边界(按官方文档逐项核对)
| 能力 | 实际行为 | 可核验点 |
|---|---|---|
| 上下文挂载 | 点 + → Add context,粘设计 URL;也可拖入图片、文本文件;还能把 frame / component 直接粘进聊天框 | ⛔ 文档明确:不要把 Figma 文件 URL 粘进 prompt,模型会去解读 URL 本身而不是它指向的文件,产出常常跑偏 |
| 联网取数 | 搜索当前信息,或抓取指定 URL 的内容,把 app 锚在真实数据上 | 与 v0 的「带可点击来源」同类,但文档未说明是否给引用链接 |
| 指点式编辑 | edit tool 点选预览里的具体元素,用 Figma Design 风格的属性面板改(字体、文字间距等),或直接 prompt | 把「改这一处」从描述坐标变成指它一下 |
| 画与批注 | draw tool 在预览上圈画并把该区域加进 prompt;annotations 给特定元素下指令 | 视觉指令替代文字描述 |
| 并发对话 | 单个 Make 文件里可同时跑多个 chat,一个还在跑就能开下一个 | 不用等一轮结束 |
| plan mode | 先产出结构化计划,人批准后再点 Build;计划与构建是两个独立计费动作 | 官方口径:计划本身多花 credits,但一次到位能省掉后面的返工 prompt |
| 版本历史 | 可回到早先版本继续改 | 非破坏性迭代 |
| 多人协作 | Starter 与 Full seat 建的 Make 文件是 multiplayer,能看到别人在打字/在看,有查看权的人能留评论,可同时改生成的代码 | Dev / Collab / View seat 建的文件不能分享,因此也无法协作 |
| 后端 | 可给 app 加 backend 存数据:跨浏览器保持状态、登录界面、读写文本与图片、存 secrets 与 API key | 不是纯前端 demo |
| 代码编辑器 | 可粘自己的代码进去,再用对话迭代 | guidelines.md 也在里面,用来固定语气与版式结构 |
发布链路,以及它和 v0 的关键差别
发布后的 app 托管在 AWS,域名与路由由 Cloudflare 提供;发布处于 beta 期间不额外收托管费。默认不被搜索引擎收录(可在设置里改可见性),没有自带 analytics 面板(可填 Google Analytics ID,或往 head/body 里塞别的统计片段),SEO 是自动优化但不提供定制项。删掉 Make 文件会自动下线已发布的 app,文件数据一并删除。
这里有一条必须说清的差别:v0 的回路终点是你的 GitHub 仓库(PR → merge → 部署,分支保护与 review 照常生效),Figma Make 的回路终点是Figma 托管的一个 URL。Make 有 code editor、也能 export code(Full 与 Dev seat 可导出),但官方文档里没有「连你的仓库、开 PR、走你的 CI」这条路径。所以它更像「设计侧自成一体的发布」,不是「把代码交回你的工程体系」。选型时这一条比生成质量更先决。
另一条容易误解的能力是「回到 Figma Design」:你可以把预览复制成设计图层再粘进 Figma Design。但文档写明——这是单向的:在 Design 里改这些图层不会回流到 Make 文件,图层也不会自动挂上你的设计系统。把它当成「拿一份快照去和团队讨论」是对的,当成双向同步是错的。
与 Figma MCP server 的分工
Make 常被和 Figma MCP server 混为一谈,两者是不同的东西:MCP server 是把 Figma 的上下文喂给你自己在用的编码 agent(VS Code / Cursor / Windsurf / Claude Code / Codex),远程端点是 https://mcp.figma.com/mcp(官方推荐),桌面端跑在本地 Figma app 里(主要面向组织与企业的特定场景)。它能让 agent 直接写回画布:在 Figma Design 与 FigJam 里创建、修改 frame、component、variables、auto layout,以你的设计系统为事实来源——这条能力目前仅远程 MCP 支持,beta 期间免费,官方说明将来会变成按用量付费。还有一个反方向的用法:让 MCP client「起个本地服务器跑我的 app,把 UI 抓进一个新的 Figma 文件」,即把线上真实 UI 收进设计文件。Skills 则是在 MCP 工具之上打包好的 agent 级指令(告诉 agent 该用哪些工具、按什么顺序用、结果怎么用),不改 MCP 能力本身,可从 Figma Community 与 GitHub 上的 community-resources 仓库获取。
换句话说:Make = Figma 内部的 prompt-to-app;MCP = 把 Figma 接进你已有的 agent。前者产出托管网址,后者产出你自己仓库里的代码。想要「代码落在我的工程体系」的团队,该看的是 MCP + 自己的 harness,而不是 Make。
席位与计费(决策前必看)
| 项目 | 口径 |
|---|---|
| 谁能完整用 | 付费计划的 Full seat。Dev / Collab / View seat 只能在 drafts 里试用 |
| 建文件位置 | 只有 Full seat 能在 folders / teams 里建 Make 文件;其它 seat 只能在 drafts |
| 分享与发布 | 只有 Full seat 能分享、能发布。Starter 计划想发到公网,必须同时发到 Figma Community |
| 导出代码 | Full 与 Dev seat 可导出;Collab / View 仅在 drafts |
| 团队库样式上下文 | Starter 用不了(team libraries 是付费功能) |
| credits 额度 | 按 seat 归属、每月重置、不结转、不可共享或转让:Full seat 在 Starter 500、Professional 3,000、Organization 3,500、Enterprise 4,250;各计划的 Dev / Collab / View seat 一律 500。Starter 用户与 View seat 另有 150/天 的上限,当天用完次日恢复 |
| 单次消耗 | 费率表口径为 2026-08-25。Make 属「agentic 功能」按变动计费,官方用 2026-02 的默认模型给示例:简单 app ≈30+ credits,中等 ≈75+,逻辑或交互复杂的 ≈100+;并明说这些数字只是近似(模型非确定性) |
| 消耗变量 | 三个:模型选择(Make 里有多个模型,各自定价,有的贵不少)、任务复杂度(prompt 触发多少 action)、上下文体量(挂的文件、设计库、聊天历史越大越贵) |
| 教育版 | K-12 教育用户目前不可用;高等教育与 bootcamp 教育用户可用 |
把 credits 额度对着单次消耗算一下就有数:Professional 的 3,000/月,按中等复杂度 75+ 一次算,大约 40 次生成;而 agent 式工具的真实用法是「生成一次 + 改五六轮」,plan mode 还要额外扣一次。所以额度是按「几次对话」计的,不是按「几个 app」计的。管理员可以买额外 credits、按人头设上限。
边界与失败模式
- 预览里拿不到摄像头与麦克风:官方明说预览上下文不支持,只有发布后的版本才能申请。凡是要验证音视频采集的功能,你必须先发布到公网才测得了——这条会直接改变你的验证顺序。
- 发布即公开:发到公网后任何拿到 URL 的人都能访问,且无法限制访问已发布版本;默认不被搜索引擎收录只是降低了被发现的成本,不是权限控制。组织管理员可以整体关掉发布开关。
- 第三方内容的权利风险落在你身上:文档明写 Make 可能把互联网上的字体、代码包、图片纳入你的 app,发布前确保你有权使用是你的责任。对要商用交付的团队,这是需要走一遍法务的点。
- 设计回流是单向的:预览复制成图层进 Design 之后不回流、不自动挂设计系统。指望「代码改了设计自动跟着变」的团队会失望。
- 挂载设计有硬性前提:必须是 component 或放在 frame 里;多个设计想用于同一个 app 时,官方建议一次只挂一个。这限制了「把整套设计系统一次性喂进去」的想象。
- 没有公开的正确性基准:官方给的是功能清单、席位矩阵和 credits 表,没有任何可读的质量数字。卡片置信度因此记 C 级(厂商宣称)。
- 内容治理由 Figma 单方裁定:已发布内容受 Figma 的 Acceptable Use Policy 约束,被举报且判定违规会被下架,申诉靠回邮件。对承载客户交付物的场景,这是一条需要评估的运营风险。
- beta 口径随时会变:发布功能仍在 beta,「托管不额外收费」「自定义域名 2025 年前免费」「写回画布 beta 期间免费,将来按用量付费」这些都是有时间边界的说法,别当长期成本模型。
我们的复现计划
要把这条从 C 级提到 A 级,需要跑三件事:第一,拿同一份已有 Figma 设计,分别用 Make(挂设计)和 v0(截图 + prompt)各生成一遍,比对还原度与返工轮次,验证「设计系统当上下文」到底省下多少轮;第二,实测 credits——同一任务在不同模型档位、不同上下文体量下的真实消耗,以及 plan mode 的额外开销,给出「一个中等 app 的真实单位成本」;第三,验证发布链路的约束:预览拿不到摄像头/麦克风是否真的只能发布后测、默认不收录的开关是否如实生效、删除文件是否确实自动下线。这三项跑完之前,卡片上的读数请按「厂商说的」理解。