核心技术栈与架构基础
大语言模型
代码生成的核心离不开大语言模型。 Figma Make 的核心驱动是 Claude Sonnet 4.5（最新版本）和早期的 Claude 3.7 Sonnet 模型。
根据 Figma 的博客说他们选择这些模型的原因在于这两个模型在在代码生成和复杂推理任务上表现最优。
比如在 SWE-bench 验证评估中的顶级表现，能够处理超过 30 小时的复杂多步骤任务，并具有出色的计算机使用能力。
设计数据解析管道（Design-to-Context Pipeline）
Figma Make 支持使用 Figma 设计文件作为输入，进行提示和应用创作。
这方面的能力来自其多层次的设计数据提取，以此为基础来增强 LLM 的理解能力。其层次结构主要体现在下面三个方面：
-
1. 结构化元数据提取：系统从 Figma 设计文件中抽取完整的布局、组件层级、自动布局约束、颜色令牌、字体和间距变量。 这个过程远超简单的图像分析，因为它能够收集语义级的设计意图信息。 -
2. Model Context Protocol（MCP）集成：Figma MCP 服务器为 LLM 提供三类主要工具，使 AI 能够获得超越视觉层面的设计上下文： -
• get_code：提取组件代码结构和变体 -
• get_variable_defs：获取所有设计令牌和变量定义 -
• get_image：捕获组件截图用于布局理解 -
3. 设计系统对齐：如果通过 Code Connect 建立了设计与代码的映射关系， MCP 服务器可直接提供代码文件路径和变量命名，使生成的代码自动遵循项目的架构模式。
代码生成管道和多模式输入处理
前面提到，Figma Make 支持多种输入模式，每种都经过不同的处理流程：
-
• 从 Figma Design 导入：直接接入现有设计文件，保留完整的设计元数据和组件结构 -
• 图像上传：处理设计图片、线框图或任何视觉参考 -
• 自然语言 Prompt：从零开始的文本描述生成
Prompt-to-App 转换引擎
我们拿最简单的 Prompt 输入举例，系统将用户 Prompt 与设计上下文结合，通过以下步骤生成代码：
-
1. 用户输入详细的 Prompt，包含任务描述、设计元素、交互行为和约束条件 -
2. Claude 模型结合提供的设计元数据理解设计意图 -
3. 生成器自动推断响应式布局、交互流程和状态管理逻辑 -
4. 输出对应框架（React 等）的代码
特定元素级编辑（Point-and-Edit）
Figma Make 实现了基于位置的精确编辑机制：
-
• 用户可指向预览中的任意元素并描述变更 -
• 系统定位对应的代码节点并进行局部修改 -
• 支持快速调整颜色、间距、字体、圆角半径等视觉属性 -
• 使用 go to source功能快速跳转到控制特定元素的代码
当然，不只是 Prompt 编辑，Figma Make 的画布也融合了设计能力，可以让设计师直接在画布上进行元素级的编辑。
运行时与预览环境
还有值得一提的是其运行环境：基于浏览器的 Node 运行时。
Figma Make 运行在自定义的浏览器 Node.js 运行时环境中，该环境与本地开发环境有重要差异：
-
• 具有特定的库导入配置，不同于标准 npm 安装 -
• 包含自定义的 Tailwind 加载机制 -
• 提供额外的 CSS 预处理，这些在代码导出时不会完整包含
也就是说，看起来和本地开发环境一样，导出来也有 package.json 文件，但还是有着不同，这也是你为什么有些提示词不会生效。
React/JSX 代码生成
当前 Figma Make 主要输出 React 组件（.tsx 文件），使用 Tailwind CSS 作为默认样式解决方案：
-
• 生成的代码包含特殊的版本标记（如 @1.2.3），允许运行时动态加载库 -
• 支持状态管理和条件渲染的完整 React 模式 -
• 预览环境自动处理依赖注入和编译
作为原型开发工具，这些功能和限制足够了，但是如果想把生成的代码用于生产环境，还需要做一些额外的工作来适配你自己的项目配置。
状态管理与交互流
即使作为原型，也不只是一个静态页面就能满足的。 Figma Make 内置状态管理机制来支持复杂的交互：
-
• 状态记忆化：保存用户交互后的组件状态（如切换状态、输入值） -
• 状态共享：在不同帧之间保持匹配对象的一致状态 -
• 滚动位置保存：记住页面的滚动位置，返回时恢复 -
• 支持变量绑定和动态数据渲染
设计系统与代码一致性
Figma Make 支持 设计系统 以及 设计库集成，也就是说可以实现完全符合你设计规范的原型应用：
同时用户可将现有 Figma Design 库的组件粘贴到 Make 中作为视觉参考：
-
• Figma Make 自动匹配库组件的样式和间距 -
• 生成的代码遵循设计系统的视觉规则而无需额外说明 -
• 通过 Point-and-Edit 可将泛型组件替换为特定的库组件变体
变量与令牌映射
同样的，系统会将设计令牌自动映射到代码中，包含：
-
• 提取的设计变量（颜色、间距、圆角等）映射为 CSS 变量或 Tailwind 类 -
• 保持设计系统中的变量名称和结构 -
• 支持深色主题和多主题变体的自动生成
这样一套组合下来，生成的应用几乎就可以以假乱真。如果是从零开始的项目，你甚至直接对接后端之后就可以上线使用。
协作与集成能力
Figma Make 作为 Figma 平台的原生组件，默认支持实时多人协作，这也是基于 Web 实现的 SaaS 软件的天然优势。 可以给团队成员带来如下好处：
-
• 团队成员可同时在同一 Make 文件中工作 -
• 支持即时代码和设计的同步更新 -
• 消除跨工具切换的上下文损失
与 Figma Design 的双向集成
最新功能 Copy Design 允许将 Make 输出带回设计画布， 也就是说你用 Prompt 生成的应用可以直接在 Figma 设计器中让设计师进行修改：
-
• Make 预览可直接复制为可编辑的 Figma 图层 -
• 保留结构层级而非导出为静态截图 -
• 允许设计师进一步迭代和优化
数据与 API 支持
另外还有一些功能我看看文档看到的，自己也没有使用过，比如 可集成实时数据源：
-
• 支持外部 API 集成（如天气、股票价格等） -
• 可使用 CSV 文件导入自定义数据集 -
• 支持浏览器硬件访问（摄像头、麦克风输入等）
Prompt 工程最佳实践
官网也给出了适合 Make 的 Prompt 最佳实践：结构化 Prompt 设计。
定义了一个有效的 Figma Make Prompt 应包含五个关键维度：
-
1. 任务（Task）：清晰的行动描述（如「使此按钮触发动画」） -
2. 上下文（Context）：设计在产品流程中的位置和用途 -
3. 关键设计元素：应包含的重要特性和交互 -
4. 预期行为：用户交互的具体响应方式 -
5. 约束条件：设备类型、布局限制、视觉风格
以及如何使用提示词开发一个复杂的项目：分解为可管理的步骤：
-
• 初始 Prompt 应包含尽可能多的细节以最小化后续迭代 -
• 后续修改应采用增量方式逐步优化 -
• 对于大型项目，可显式要求 Make 为每个功能元素创建独立代码文件 -
• 如果初始生成效果不理想，重新开始通常比多次修补更高效
文件导出与本地开发
最后大家觉得 Make 生成的效果不错，可以把代码下载到本地进行开发，如果用于生产的话， 还是需要一些特殊处理来获得更好的工程特性：
-
• 使用 Vite 等现代构建工具配置本地项目结构（这个默认就是，尽量不要更改） -
• 需要覆盖运行时特定的库导入路径（移除我们前面提到的版本标记） -
• Tailwind CSS 配置需调整以匹配 Make 的预处理输出（这个可以让 AI 来帮你修改）
限制
虽然其对于设计的还原度很高，但是还是存在一些限制，比如：
-
• 代码输出主要针对 React/Tailwind，暂不直接支持 Vue、SwiftUI 等框架 -
• 生成的代码与设计的双向同步仍在完善中
最后
Figma Make 非常适合使用了 Figma 生态的用户，特别是对于项目快速上线来说有很大帮助。
你的 设计系统 越完善，一次性生成的代码质量就越高，越符合你的设计规范。
当然，如果你没有使用 Figma 来进行 UI 设计，Figma Make 对你来说就完全不必要。
毕竟我们说到 Make 的设计和优点，都是为其生态服务的。如果没有 Design，对于大家来说也就是一个玩具，还要改造他的代码或者你的项目， 意义不是很大。不如直接用 Claude Sonnet 4.5 来的实在。