Figma Make 评测：从交互原型到 Web 应用，设计如何交付

如果产品构想已经有了 Figma 设计画框或设计系统，Figma Make 的优势最容易发挥出来。它可以构建可运行的 Web 应用，官方文档也列出了两种后端方案，但现在选择哪一种，会影响后续能否通过 GitHub 继续开发。用它验证已经设计好的产品体验很合适；在接入客户数据之前，则要先确定工程开发的后续路径。

本文所述公开功能与 AI 积分额度已于 2026 年 10 月 15 日核实。 本评测依据产品的现行公开文档，重点考察工作流程能否衔接，以及交付时有哪些限制。文中的操作示例是一份可供照着实践的需求说明，并非登录产品后的实测，也不代表对生成质量做过量化评估。

Figma Make 是什么？

Figma Make 能根据提示词和设计参考，生成由可编辑代码驱动的界面。你可以实际尝试搜索、填写表单、走完产品流程，而不只是查看静态效果图。它也能发布 Web 应用，并连接已存储的数据。Figma Design 仍是绘制界面的设计画布；Figma Sites 则是独立的建站工具。Make 负责的是另一件事：描述设计应该如何响应用户操作，再生成相应的交互行为。可以从 Figma Make 开始；官方创建指南 介绍了从输入提示词到查看预览的流程。

Figma Make 适合谁？什么情况下该选替代工具？

对于设计师或产品经理，如果手头已有通过评审的界面、共享组件，同事也习惯在 Figma 中评审，Figma Make 的优势就很明确。只有初步想法的创业者同样可以使用，但如果完全从一条空白提示词起步，就享受不到它的很多长处。

下表比较的是从什么材料开始、下一步由谁编辑，以及如何部署。这是对工作流程的判断，并不按各工具首次生成的画面有多好看来排名。

关于后端与代码能力的区别，可查阅 Figma 后端指南、Lovable Cloud、v0 全栈开发指南 和 Claude Design 的文档。

Lovable：先有应用需求，再考虑设计文件

Lovable 是一款应用构建工具，提供托管、数据库、身份验证和存储。如果创业者的起点是“客户需要提交请求，员工需要处理这些请求”，它值得列入候选名单。它的 GitHub 集成 支持从当前仓库分支同步回改动；当开发者加入项目时，这一点很有用。

需要权衡的是谁来承担后续运维责任。Lovable 的 Cloud 文档说明，迁往自有 Supabase 时，需要导出数据，并在新项目中重建数据库结构。选择它，应当是因为这种托管方式适合当前上线计划；至于以后可能发生的迁移，也要想清楚由谁负责。

v0 by Vercel：后续工作以代码为中心

Vercel 的 v0 可以构建全栈应用，默认采用 Next.js。这个 Web 框架将界面代码与服务端功能结合在一起，v0 的文档也涵盖后端端点和数据库连接。它同样支持导入 Figma 上下文，因此，能够接收 Figma 设计并不是 Make 独有的优势。

如果生成的应用会由工程师维护，而对方也希望从这套框架出发，优先考虑 v0。如果眼前要交付的是设计评审材料，还没有人准备接手应用代码，就不宜默认选它。关键在于预览通过评审之后，接下来要做什么。

Claude Design：探索范围不止产品 UI

Claude Design 可以制作界面原型及其他视觉作品，从代码和设计文件中获取设计系统上下文，并与 Claude Code 衔接。其当前产品页面还列出了 PDF、PowerPoint 和 HTML 导出能力。对于既需要原型、又需要配套说明材料的创业者，这种覆盖范围很合适。

如果创意需求从对话展开，后续工作也会在 Claude 或导出的文件中继续，可以选择它。如果团队的评审一直围绕已有的 Figma 画框进行，Make 则能更直接地利用这些资料。单有一个 HTML 导出文件，并不能解决账户、数据和部署由谁维护的问题。

想了解更多候选工具，可以查看我们的 AI 设计工具清单。

Figma Make 怎么用？

第一条提示词如果能把交互范围说清楚，Figma Make 就更容易发挥作用。“帮我做一个创业项目”会让模型同时猜产品是什么、界面该怎样设计；一套已有设计的预约流程，则能给你明确的判断依据，知道哪些可以接受、哪些需要修改。

Figma Make 教程：把预约画框变成可操作的原型

下面用一份示例需求展开：访客选择服务，再选择可预约的时段，最后提交申请。先用示例内容，不接入客户账户。最初要验证的是用户能否理解流程，之后再决定如何存储预约信息。

1. 1

   准备设计画框

   选中 Figma Design 中包含预约界面的画框。按钮文案应有明确含义，同时准备好希望原型呈现的已选、不可用和错误状态。复制画框本身。需要向模型提供准确的设计上下文时，Figma 建议使用结构化画框，而不是截图。

2. 2

   创建 Make 文件并附上设计参考

   在文件浏览器中打开 Drafts（草稿），点击 Make，将复制的画框粘贴到提示词中。也可以点击 Add context（添加上下文），在附件弹窗中附上设计或画框链接。应当让实际画框成为上下文，而不是只在对话里放一个 URL。

3. 3

   说明交互行为与实现范围

   要求 Make 保留所附设计，让访客选择服务和可预约时段，验证必填项，并显示确认信息。明确说明初版只使用示例数据，暂不接入后端。点击 Send（发送），生成预览。

4. 4

   逐一检查异常操作

   尝试漏填必填项后提交、选择不可用时段、选好时间后更换服务，以及从确认页返回。观察界面能否让用户理解发生了什么。按钮有响应只是起点，响应正确才有用。

5. 5

   只修改出错的最小范围

   在新的 Make 文件中，通过 Edit（编辑）选中元素，修改属性后点击 Apply（应用），或标注具体问题。修正交互行为时，先别同时大改视觉设计，这样才容易判断目标问题是否解决。

以上操作依据 Figma 的创建说明、附件指南 和编辑指南。较早创建的 Make 文件可能仍保留旧版编辑界面。

预约流程的 Figma Make 提示词示例

首次生成的提示词：“以附上的预约画框为视觉参考。构建访客选择服务和可预约时段、填写必要联系信息、查看确认结果的流程。使用虚构的示例内容。保留画框的信息层级和组件样式。暂时不要连接后端。说明哪些功能是模拟的。”

修改提示词：“所选服务发生变化时，清空之前选择的预约时段，并要求用户重新选择。保留现有布局和视觉样式。在时段选择控件旁显示行内说明。”

这里列的是生成前后的需求描述，并非已观察到的生成结果。如果初版在切换服务后，仍保留与新服务不匹配的预约时段，这条修改提示词针对的就是状态管理问题：前面的选择变了，应用记住的后续选择也必须相应更新。

细节检查同样要具体：查看文字换行、键盘焦点、不可用状态、较长的服务名称，以及窄屏布局。一张漂亮截图无法证明这些都处理妥当。评审者能完成任务，并理解某个操作为什么受限，这个原型才真正有价值。

Figma Make 设计系统：保留的不应只有颜色

Figma Make 如果能依据设计系统中的组件和规则工作，而不只是模仿一张完成稿，就会更有用。设计令牌是颜色、间距等属性的命名值；组件则是定义了行为、可重复使用的界面元素。使用了正确的令牌，并不代表使用了正确的组件。

用 Figma Make kits 组织设计系统资源

Figma Make kits 可以整合 npm 包、已发布组件库中的样式与变量，以及书面规范。npm 包用于分发可复用代码，因此 kit 除了提供视觉参考，也能提供实现层面的上下文。文档中的流程是 Settings → Create a kit → Assemble your kit，接着添加资源、编写规范、测试，再发布给同事使用。使用 kits 需要付费套餐中的 Full 席位。详见 Figma Make kits 指南。

生成流程之前，在应用的提示词区域点击 Select a Make kit，选择已发布的 kit。针对预约需求，如果已有通过审核的按钮、输入框和时段选择组件，就把它们纳入其中。接着说明使用规则：主按钮用于提交有效申请；不可预约的时段应清晰可辨，但不能被选中；校验信息应紧邻需要处理的字段。

这些规则比一句“符合品牌风格”更重要。生成的紫色矩形可能看起来像你的主按钮，却缺少禁用状态、焦点样式或无障碍标签。评审时要检查组件用得是否正确、交互语义是否清楚，不能只看强调色是不是熟悉的颜色。

前期配置也需要投入。Figma 的代码包要求 明确指出，包必须兼容构建环境，而且不能依赖外围工作区。如果现有组件依赖散落在大型代码仓库中的私有模块，应请工程师准备可用的包。

提取组件库，不等于完整保留设计令牌。 Make kits 指南说明，它会提取部分变量，用原始值生成简化的 CSS，不会保留变量的原有语法。应在规范中写清状态规则，并检查生成的样式，再判断原型是否完整继承了设计系统。

用 Figma Make 模板复用起始流程

Figma Make 模板适合复用同一种起始体验，kit 则负责提供可复用的设计系统上下文。可以先做出一套经过评审的预约基础流程，让同事基于它创建不同版本。Figma 将模板与其他分享和复用方式 一并列在文档中。

长期适用的项目规则写进规范；需要主动调用、重复执行的评审任务，则可以用自定义技能。对于已有成熟设计系统的团队，我们的 Figma Make 自定义技能设计系统包 提供了一套起始结构。请按自己的令牌和组件调整指令；最终评审仍需由人来判断。

让 Web 应用真正保存数据

Figma Make 的现行文档列出了两种后端方案：应用后端兼内容管理系统 Payload，以及数据库和后端服务 Supabase。后端负责存储信息，并处理可见界面背后的工作。它决定了你只是展示了一条预约确认，还是在访客关闭浏览器之后，员工仍能查到这条申请。

使用 Payload 时，先描述应用，再确认创建后端，之后就能通过 CMS 标签页中的内容管理界面管理记录。应用和数据均由 Figma 托管。Supabase 则需要单独连接，入口是 Make settings → Integrations → Supabase；它在 Make 中采用键值存储，以简单条目的形式保存数据，而不是创建一套由关联表组成的完整数据库结构。详见 Figma 后端文档。

沿用同一份需求，可以继续输入：“添加 Payload 后端，用于管理服务和预约申请。访客可以提交申请，员工可以管理申请。将公开的服务信息与私密的联系信息分开。实施之前，先说明访问权限规则。”

接着在管理视图中查看已保存的申请，刷新访客端页面，确认它读取了预期的已存储信息。还要检查未经身份验证的访客能否访问仅限员工查看的记录。这些是实现后应执行的验收检查，并不意味着生成结果已经满足这些要求。

提交预约申请与确保预订成功，是两种不同的产品承诺。 申请可以等待员工审核；确定预订则必须处理冲突提交、取消和可用时段变化。如果业务要求保证某个时段可用，在宣告流程完成之前，应先让工程师介入。

实际优势在于，你可以把界面与记录管理任务放在一起验证。但责任归属仍须明确：数据模型、权限和恢复流程，都需要有人做决定。生成的管理界面无法代替你作出这些业务判断。

发布应用之前，先确定谁来接手

Figma Make 可以直接发布应用，无需先经过 Figma Sites。在 Make 中点击 Publish（发布），设置标题，再发布应用，即可获得专用 URL，也可以配置自定义域名。后续修改需要更新已发布版本才能生效。详见 Make 发布指南。

对于预约原型，先明确受众是评审者还是潜在客户。评审者需要如实了解哪些行为只是模拟；客户需要的则是完整服务，包括清晰的确认信息、纠正错误的途径，以及真正处理申请的人。最终评审应使用部署后的 URL，检查访客实际看到的版本。

什么时候更适合用 Figma Sites 发布？

Figma Sites 适合通过可视化编辑来维护的营销网站。文档介绍的流程是：把 Figma Design 画框复制到 Sites 的断点布局中，调整响应式布局，然后发布。断点布局是为特定视口范围准备的布局。如果主要工作是编排和更新页面，这条路径就很合适。详见将设计移入 Figma Sites。

预约交互可以交给 Make；外围营销网站则可以考虑 Sites，前提是这种编辑方式适合负责维护的人。不要以为两者支持相同的迁出方式：Figma 的 Sites 发布文档 说明，目前无法导出网站代码以供外部发布。

交付给工程团队时，需要交代什么？

Figma Make 的代码编辑器支持下载 ZIP 文件。其现行 Git 工作流程文档 还介绍了克隆已授权 GitHub 仓库、在分支中工作，以及创建拉取请求的方式。拉取请求可以让工程团队在改动进入共享应用之前先做代码审查。这是不同的起步路径，各有要求。

交付代码时，还应一并交代预期行为、已知的模拟功能、数据归属、访问规则和未解决的问题。以预约流程为例，要明确它提交的是预约申请，还是已经确认的预订。否则，工程团队可能接到一个界面精致、业务规则却做错了的实现。

Figma Make 的 AI 积分怎么算？

团队协作使用设计系统时，建议选择 Professional 套餐的 Full 席位：它包含每月 3,000 AI 积分，而 Starter 为每月 500 积分，每日上限 150 积分。Make 使用共享的 AI 积分额度，消耗会随模型、任务和上下文而变化；席位积分每月重置，不结转。在决定之前，请查阅 Figma AI 积分使用说明 和 Figma 价格页面；积分额度不代表承诺能完成多少个原型。

哪些限制会直接影响选型？

Figma Make 的限制取决于所选的工作流程。无论认定“它做不了后端”，还是认为“整个产品都能交给它”，都不足以作为购买依据。

采用托管的 Payload 应用，目前就无法继续走 Git 流程

Figma Make 的 Payload 后端文档说明，使用 Payload 后端的应用尚不支持 GitHub 集成和本地代码库工作流程。文档还指出，目前 Payload 托管位置在美国东部。这些应当作为选型条件提前考虑，而不是等应用做完才发现。详见 Payload 的限制。

如果工程团队需要立即通过自己的代码仓库接着开发同一项目，选定 Payload 之前，就要验证是否有兼容的实现路径。计划在未来推出的功能，满足不了眼前已经排期的交付。

从 Figma Make 复制到 Figma Design，并不等于实时双向同步

Figma Make 的标准 Copy design（复制设计）操作，会把当前预览转成可编辑图层。这些图层是静态的，与 Make 文件断开，也不会自动关联设计系统，虽然可以匹配可用变量。详见 Copy design 文档。

复制出的设计适合评审和视觉探索。如果在画布上修改了时段选择器，就要明确这些改动如何回到实际运行的应用中。否则，设计评审和原型可能在不知不觉中指向两个不同的产品。

不同 Git 功能，不能混为一谈

Figma Make 另有独立的 Push to GitHub 功能。它会创建自己的仓库，并进行单向推送；后续推送可能覆盖在 Make 之外做出的修改。不能把这一限制套用到上文提到的较新仓库克隆流程上。

本地代码库工作流程 又是另一种独立选项。文档将其描述为限量封闭测试，需要 Mac 版 Figma Beta 桌面应用和获准参与的账户，也需要配置代码仓库。在承诺设计师可以直接修改现有生产应用之前，先确认团队实际能使用哪条路径。

已发布应用的密码，不会保护所有分享链接

Figma Make 的密码保护作用于已发布的应用；预览访问则遵循文件分享权限。向团队外部发送保密概念方案之前，应同时检查两者。发布权限与分享权限需要分别决定。详见发布与访问设置。

生成了交互，也仍然需要验收标准

复杂的业务情形还没解决时，Figma Make 就可能让整个流程看起来已经完成。对于预约示例，要评估相互冲突的申请、已取消的预约、存在无障碍问题的控件，以及可能误导用户的确认信息。这些是评审要求，不是本文实测发现的缺陷。

真正有用的上线标准是：“目标用户能够完成任务，负责人能够支撑后续结果。”仅仅做出逼真的效果图，这两个条件都还没有满足。

评测结论：先验证设计体验，同时选好后续运营与开发路径

对于已经拥有 Figma 设计资源、希望评估可运行产品体验的创业者、产品经理和设计师，Figma Make 很值得考虑。它的 kits、局部编辑和后端选项，能让讨论超越“这个页面看起来怎么样”。

如果接手的人无法沿着你选定的流程继续工作，选型结论就会改变。 托管的 Payload 应用可以适合内容管理或请求管理，但如果要立即交付给工程团队，当前的 Git 限制就很关键。如果希望从托管应用起步并通过 Git 同步，优先考虑 Lovable；如果开发者将沿 Next.js 方向接手，考虑 v0；如果需要更广泛的视觉探索，并在 Claude 中继续工作，则考虑 Claude Design。

下周就可以选一个有代表性的画框，做出最小但完整的交互，再请最终接手的人评审后续工作路径。把原型验收和交付方案一起确认，比继续生成更多页面更有意义。

常见问题

Figma 可以用来做什么？

在本文介绍的流程中，Figma Design 用来设计界面，Make 用来生成可运行的交互和应用，需要可视化建站时则使用 Sites。先确定要交付什么，再选择相应工具。

如何在 Figma 中新建文件？

如果要创建 Make 文件，在文件浏览器中打开 Drafts，然后点击 Make。附上设计画框，描述想要的交互行为即可。上文的操作步骤依据 Figma 官方文档中的创建流程。

Figma 是 UI 工具还是 UX 工具？

两方面都涉及。UI 关注用户看到和操作的界面，UX 关注用户完成任务的整体体验。Make 可以帮助你检查实际可运行的流程，但它是否解决了正确的问题，仍需你通过研究作出判断。

Figma Design 和 Figma Make 有什么区别？

Figma Design 是设计画布，Make 则生成由代码驱动、可以运行的界面。标准 Copy design 操作会把一个静态画面带回画布，转成可编辑图层，但不会自动同步之后的修改。

有没有比 Figma Make 更合适的工具？

取决于任务。需要托管应用和后端时，Lovable 是有力的替代选择；面向 Next.js 的工程开发流程，可以考虑 v0；需要跨格式的视觉探索，则可以考虑 Claude Design。Make 最突出的优势，是能够从现有的 Figma 设计和设计系统起步。

用户正在离开 Figma 吗？

本文没有衡量客户迁移情况。个别投诉或转用其他工具的案例，无法证明整体趋势。做选择时，应找出当前工作流程无法完成的具体设计或交付任务。

为什么说 Figma 在下滑？

这个问题可能指股价、采用情况，也可能只是某个人对产品的看法。它们都不能直接说明 Make 是否适合你的工作流程。本文不对市场表现作出判断，只评估文档所述的设计、后端与交付路径。

Figma 最大的竞争对手是谁？

没有一个竞争对手能够对应 Make 的所有使用场景。就本文讨论的选型而言，从应用需求起步可以考虑 Lovable，接着进行代码开发可以考虑 v0，通过对话完成视觉工作可以考虑 Claude Design。应围绕实际要完成的任务来比较。

Canva 和 Figma 哪个更好？

对于本文讨论的产品界面工作流程，选择 Figma。如果需要营销素材，可以参考上文链接的 AI 设计工具 综合比较，按交付物类型选择。本文没有对 Canva 与 Figma 的输出质量进行排名。

Figma Make 免费吗？

可以通过 Starter 试用 Make。文档列出的限制包括无法使用团队组件库样式上下文，以及向公开 Web 发布时需要同时发布到 Figma Community。涉及保密信息的团队产品工作，应评估付费 Full 席位的使用方式。详见 Figma Make 使用权限 及上文的积分额度说明。

确定采用这套流程之前，可以用 AI 业务工作流程审查清单 明确原型负责人、所需数据和交付安排。