Figma：让 Claude 把设计变成可运行软件

设计平台面对的新矛盾：用户想要的不再只是画布

Figma 是全球使用最广泛的协作设计平台之一，设计师、开发者和产品经理在同一个画布上完成从概念到交付的全流程。长期以来，Figma 的核心价值在于"让所有人看到同一份设计"——但"看到"和"体验到"之间仍然隔着一道鸿沟。

静态 mockup 无法传达交互逻辑。一个带有悬停动效、响应式布局和条件跳转的产品方案，在设计稿上只能用箭头和批注来暗示。产品经理 Alex Mullans 描述了这种摩擦的典型场景："传统的设计-开发交接会产生大量往返——开发者拿回构建结果，说'这是我做出来的'，但它和原始设计意图并不一致。"这种往返不仅消耗时间，还让设计意图在每一轮传递中逐渐失真。

Figma 团队意识到，AI 代码生成能力的成熟为这个问题提供了一条新路径：如果模型能够理解设计稿的视觉结构和用户意图，并直接生成包含逻辑、动画和响应式行为的可运行代码，那么设计师就不必等待工程实现，产品经理也不必依赖设计师来验证想法。Mullans 表示 Figma 定期评估不同的 AI 模型，认为 Claude 持续提供了速度、准确性和用户意图理解的最佳组合。与此独立地，团队将 Claude Sonnet 视为一个关键突破点——代码生成质量第一次达到了足以支撑 Figma Make 产品愿景的水平。

模型选择：代码质量之外，还要有"设计品味"

选择 AI 模型时，Figma 面对的不是一个标准的代码生成评测问题。设计工具的用户对视觉输出有极高的审美预期——一个功能正确但视觉粗糙的原型，在设计师眼中几乎等于失败。一位 Figma Make 的工程师在官方材料中提到，早期的 AI 模型"很聪明，但缺乏品味和个性"，生成的设计"相当平淡"。

这意味着 Figma 的模型评估标准至少包含两个不常见的维度：一是生成代码能否忠实还原设计稿中的视觉细节（间距、色彩、层级关系），二是在用户只给出粗略描述时，模型能否自主补全合理的视觉方案。Figma 产品经理 Holly Li 的个人经历提供了一个侧面参照：她曾花 30 小时自学 React 来搭建个人网站，后来用 Claude 在一天内完成了全部代码的重构和改进，并添加了她此前无法自行实现的功能。这一经历说明 Claude 的代码生成能力足以让一位非专业开发者在已有代码基础上独立完成重构任务——但需要注意，这是在已有代码上的改进工作，而非从零开始的全新工程。

图 1

Figma 的模型评估与选择路径

值得注意的是，官方材料没有披露 Figma 评估了哪些竞品模型、使用了什么测试集或评分标准，也没有给出各模型的量化对比。"持续表现最优"是 Figma 团队的自述判断，而非独立第三方评测结论。

两条产品路径与模型迭代：从 Sonnet 到 Sonnet 4.5 再到 Opus 4.6

Figma 将 Claude 集成到两个产品场景中，分别解决不同阶段的问题。

第一个场景是 Figma Sites。设计师已经完成了网站的视觉设计，但需要为静态页面添加交互行为——比如选中一个按钮元素，用自然语言描述"鼠标悬停时添加倾斜效果"。Claude 根据描述生成代码，同时保留原始设计的视觉细节。这个场景的核心价值在于"增量"：设计师不需要从空白项目重新开始，也不需要学习前端框架，只需在已有作品上叠加交互层。官方材料未详细说明 Figma Sites 中 Claude 生成的代码与原有设计文件之间的技术接口方式（例如是否通过插件 API 或代码叠加层），这一系统边界细节未披露。

第二个场景是 Figma Make，定位更激进。用户可以从一段文字描述出发，也可以把 Figma Design 中的像素级 mockup 复制进来，Claude 将其转化为包含复杂逻辑、动画和响应式行为的功能性原型。Holly Li 描述 Figma Make 的定位是"从想法到真正的软件"——用户既可以从零开始，也可以从已有设计出发。

在模型迭代方面，Figma CEO Dylan Field 对 Sonnet 4.5 给出了具体评价。他表示团队"完全没有预料到 Sonnet 4.5 会把往返工作流改善到这种程度"（"We had no idea how much better this round trip would get with Sonnet 4.5"）。这一表述说明模型升级对产品核心体验产生了可感知的影响——用户把设计复制到 Make 中生成原型、再带回设计画布迭代的循环变得更加流畅。Figma 还通过实验性模型设置让用户访问最新模型（包括 Claude Opus 4.6），首席设计官 Loredana Crisan 表示该模型可以在首次尝试中将详细设计和多层任务转化为代码。

图 2

Figma Make 的设计-生成-迭代工作流

Figma 官方描述了一个"往返工作流"：用户把设计复制到 Make 中，生成可运行的原型，再把结果带回设计画布，与其他方案并排比较、继续迭代。这个循环意味着 AI 生成的结果不是终点，而是设计探索的中间产物——设计师始终保有对最终输出的控制权。官方材料还提到了两个具体的用户场景：一位设计师用 Figma Make 在一个周末制作了原型并向 VC 展示；另一位用户借助该工具让一个搁置已久的项目重新获得了公司内部的讨论。这些场景说明该工具在快速验证想法和推动内部沟通方面的实际用途，但官方未提供这些用户的详细背景或可量化的结果。

实施结构：角色、人机分工与系统边界

根据官方材料，Figma Make 和 Figma Sites 中的人机协作可以拆解为以下环节：

输入端。官方材料明确描述了两类主要输入角色：设计师提供像素级 mockup 或选中页面元素并附加自然语言描述；产品经理用自然语言描述产品流程。Mullans 在概括中还提到"工程师可以快速模拟界面"，但官方材料未将开发者作为独立输入角色详细描述其工作流。输入形式包括已有 Figma 设计文件、自然语言 prompt，或两者的组合。

生成端。Claude 接收输入后生成包含逻辑、动画和响应式行为的代码。在 Figma Sites 场景中，生成的代码叠加在已有设计之上；在 Figma Make 场景中，生成结果是一个独立的可交互原型。两个产品中 Claude 生成代码与 Figma 设计文件之间的技术接口方式（如 API 调用方式、代码注入机制）均未在官方材料中披露。Figma 通过实验性模型设置让用户访问最新模型（包括 Claude Opus 4.6），首席设计官 Loredana Crisan 表示该模型可以在首次尝试中将详细设计和多层任务转化为代码。

审查与迭代端。生成结果回到 Figma 设计画布，用户可以并排比较多个方案、手动调整、或重新输入 prompt 进行迭代。这一环节的控制权完全在用户手中。

图 3

Figma Make / Sites 的人机协作与往返迭代流程

官方材料没有披露以下关键实施细节：生成代码的正确性、安全性和可访问性如何测量；用户设计文件和 prompt 在 Claude 调用中的数据保留与权限隔离规则；当生成结果不符合预期时的系统级回退机制（区别于用户手动重试）；以及 Figma 内部对生成质量的监控指标。对于计划复现类似集成的团队，这些都是需要在自身实施中独立验证的环节。

效果与口径：个人叙述、产品承诺和未披露的规模数据

官方材料中出现了三组与效率相关的表述，它们的口径差异很大，需要分别理解。

第一组是产品级承诺："设计师、开发者和产品经理可以在几分钟内创建可工作的原型或应用，无需编写代码。"这是对 Figma Make 产品能力的概括性描述，没有附带样本量、任务复杂度范围、成功率或时间分布数据。"几分钟"是产品宣传语境下的表述，不能等同于所有用户在所有任务上的平均完成时间。

第二组是 Holly Li 的个人经历。她曾花 30 小时自学 React 搭建个人网站，后来用 Claude 在一天内完成了代码重构和改进。这两段工作的内容不同——前者是从零学习并建站，后者是在已有代码基础上重构——因此不能简单计算为"30 倍加速"。她还提到用 Figma Make 在五分钟内制作了一个新产品流程的原型，但这是单个个人的单次任务，没有对照组或重复测量。

第三组是跨角色参与的定性描述：Mullans 称"以电子表格和数据表思考的产品经理现在可以创建视觉原型来表达想法"。这是对 Figma Make 新工作流可能性的描述——即该工具在技术上允许非设计岗位用户制作原型——但官方没有披露实际有多少非设计岗位用户在使用这一功能，也没有给出采用率或活跃度数据。DataHub 判断：该表述说明 Figma Make 在技术上降低了原型制作的技能门槛，但能力描述不等同于已兑现的采用效果，前提是将"可以创建"理解为功能可用性而非实际使用率。

图 4

官方披露效果的口径与证据边界

总体而言，官方案例提供的是产品能力演示和个人体验叙述，而非经过控制变量的效率测量。这并不意味着效果不真实，但在引用这些数字时需要保留其原始口径。

迁移判断

Figma 的做法本质上是把 AI 代码生成嵌入设计工具的核心工作流，让生成结果成为设计迭代的中间产物而非最终交付物。这个定位决定了它的适用边界：当团队的瓶颈在于"从想法到可体验原型"的速度时，这条路径的价值最大。如果团队需要的是可直接部署的生产级代码，那么 AI 生成的原型仍然需要经过完整的工程审查、测试和重构——而这部分工作量官方材料没有讨论。DataHub 判断：Figma 作为设计工具平台，其用户对生成结果的容错度相对较高（原型本身就是用来探索和丢弃的），这与将 AI 生成代码直接用于生产环境的场景有本质区别，前提是将 Figma Make 的输出定位为探索性原型而非生产交付物。

Figma 的模型选择策略——定期评估、保留实验性模型入口、在新模型可用时快速提供给用户——对于任何将 AI 模型嵌入产品的团队都有参考价值。计划在自身产品中集成类似能力的团队，应当优先验证三件事：生成代码在目标技术栈中的还原度和可维护性、用户数据在模型调用链路中的隔离方式、以及当生成质量不达标时的降级策略。这三项在 Figma 的官方案例中均未详细披露，但它们决定了集成方案能否从演示走向生产。