Guide · 使用教程
Figma Make 中文教程：从设计稿生成可交互应用并发布
从整理 Figma 设计上下文开始，完成 Plan mode、首轮生成、局部编辑、交互状态、响应式、代码检查、GitHub 交接和安全发布。
Figma Make 最有效的用法不是让 AI 从一句模糊描述猜完整产品，而是把已有设计、交互目标、数据边界和验收标准组织成可执行上下文。本教程用一个“团队项目仪表盘”作为案例：从 Figma 设计稿生成可交互应用，完成响应式、代码与安全检查，再发布给测试用户。
开始前请确认：Figma Make 的功能、席位和 AI credits 会随计划与管理员设置变化。Starter 或非 Full seat 可以试用部分能力，但团队文件、library、共享与发布可能受限。组织管理员也可以关闭 AI 或公开发布。
最终要完成什么
案例包含五个页面或状态：
- 登录页；
- 项目列表；
- 项目详情与任务；
- 空状态与错误状态；
- 手机端导航。
完成后应能点击登录演示、切换项目、创建测试任务、查看空状态，并在桌面与手机宽度下保持可用。这里先使用模拟数据，不接真实客户、支付或生产 API。
第一步：整理 Figma 输入
不要直接选中几十个页面。先建立一个专门用于 Make 的上下文区域，只保留：
- 一张代表整体布局的桌面页面；
- 一张手机页面；
- 按钮、输入框、卡片、导航和弹窗等核心组件；
- 默认、hover、focus、disabled、loading、empty、error 状态；
- 颜色、字体、间距、圆角和阴影 token；
- 三到五条不可破坏的品牌规则。
给图层和组件使用可理解的名字。删除过期方案、隐藏实验图层和真实客户信息。AI 上下文越大不一定越好，无关内容会增加 credits 消耗，也会让生成结果混淆。
如果团队已有 Figma library、Make kit 或 guidelines 文件，执行前确认版本。Make kit 可以把 npm package、Figma library 与规则结合，为生成过程提供更稳定的设计系统上下文。
第二步：写清产品和交互目标
好的 prompt 应该同时回答六个问题：
- 谁使用这个应用？
- 用户最重要的任务是什么？
- 哪些页面和状态必须实现？
- 数据来自模拟数据还是真实 API？
- 哪些视觉与组件规则不能改？
- 怎样判断结果合格？
可以直接复制下面的首轮提示词，再替换方括号内容：
根据我附加的 Figma 设计，创建一个可交互的团队项目仪表盘。
用户：5–20 人的小团队成员。
核心任务：登录后查看所属项目、打开项目详情、创建测试任务并查看状态。
必须实现：
1. 登录页，只做演示登录，不接真实认证；
2. 项目列表，包含 loading、empty 和 error 状态；
3. 项目详情，包含任务列表、负责人和截止日期；
4. 手机端导航；
5. 键盘可访问的弹窗和表单。
设计约束：
- 复用附加设计中的颜色、字体、间距和现有组件；
- 不新增品牌颜色；
- 不改变主导航的信息架构；
- 所有按钮包含 default、hover、focus 和 disabled 状态；
- 不使用真实客户数据、API key 或第三方受限素材。
请先给出实现计划，列出页面、组件、状态、模拟数据结构和验收检查，不要立即生成代码。
最后一句很重要：复杂任务先进入 Plan mode 或先要求计划，可以在生成代码前发现遗漏，也能减少整页返工。
第三步：审查计划再生成
检查计划是否包含：
- 页面与路由；
- 共用组件；
- 交互和表单状态；
- 响应式策略；
- 模拟数据字段；
- 错误与空状态；
- 无障碍要求；
- 不在范围内的后端功能。
发现缺项时只修改计划。例如要求“增加会话过期状态，但仍使用模拟认证”“项目列表必须包含 skeleton，不要用无限 spinner”。确认范围后再开始生成。
如果计划突然加入支付、真实邮件、生产数据库或公开分享，先删除这些范围。教程阶段的目标是验证体验，不是一次性承担所有生产风险。
第四步：检查第一版，不急着重生成
第一版完成后按固定顺序检查：
- 信息架构：页面与导航是否正确；
- 任务流程：用户能否完成登录、选项目、建任务；
- 状态完整性：loading、empty、error、disabled 是否存在；
- 视觉一致性：颜色、字体、间距和组件是否来自输入；
- 响应式：窄屏是否溢出，触控区域是否足够；
- 无障碍：键盘、焦点、表单标签、对比度是否可用。
不要因为一个按钮颜色不对就要求“重做整个应用”。先记录问题，按结构、流程、状态、视觉的优先级修复。
第五步：用 point-and-edit 做局部修改
选择具体元素后给出单一变化，并说明保持项：
只修改当前选中的项目卡片：
- 将标题与状态改为同一行；
- 保留现有字体、颜色和圆角；
- 手机宽度下状态移动到第二行；
- 不修改其他卡片、导航和页面背景；
- 补充键盘 focus 状态。
一次只处理一个组件或一个问题类型。局部修改后马上回归相关页面，确认 AI 没有同时改变共享组件的其他实例。
对重复问题，不要逐个修。若所有按钮 focus 都缺失，应修改组件或 guidelines，再重新检查全局。
第六步：补齐交互和数据状态
用模拟数据覆盖至少四类情况：
- 正常：3 个项目，每个有不同任务状态；
- 空：新用户尚未加入任何项目；
- 错误：数据加载失败，可重试；
- 边界：标题很长、成员很多、截止日期缺失。
提示词示例：
为项目列表增加可切换的模拟数据场景：normal、empty、error、long-content。
所有场景只使用本地模拟数据。
错误状态必须说明发生了什么并提供重试按钮。
长标题不能挤压状态标签，手机端允许换行。
不要添加真实 API、账号或外部追踪脚本。
真实 API 应在工程接管后连接。若必须在 Make 中验证 API，使用只读测试端点和最小权限密钥，并确认密钥不会进入浏览器 bundle、公开仓库或分享链接。
第七步：做响应式与无障碍检查
至少测试 360、768、1024 和 1440 像素宽度。检查导航、表格、弹窗、长文本、表单和触控目标。不要只缩放预览窗口，要真实完成核心任务。
无障碍最低检查：
- Tab 顺序符合视觉顺序；
- focus 样式清晰且不会被遮挡；
- 图标按钮有可访问名称；
- 输入框有 label，错误信息与字段关联；
- 弹窗打开后焦点进入，关闭后返回触发按钮；
- 颜色不是表达状态的唯一方式；
- 页面和按钮文案清楚描述动作。
AI 可以帮助补齐代码，但最终应使用浏览器和无障碍测试工具验证。
第八步：查看代码和依赖
进入代码编辑器，重点检查：
- 是否出现不需要的依赖或重复组件；
- API key、token、邮箱或内部 URL 是否写死；
- 模拟认证是否被误标成真实安全登录；
- 用户输入是否在危险位置直接渲染；
- 外部脚本、图片、字体和包的来源；
- 错误处理、loading 与状态管理；
- 构建脚本和环境变量说明。
可以要求 Make 解释代码而不修改：
解释当前项目的路由、状态管理、模拟数据、外部依赖和发布配置。
列出所有可能进入浏览器的环境变量。
只做解释，不修改代码。
对认证、支付、上传和管理员操作，不能只依赖 AI 解释，应由开发者实际阅读和测试。
第九步：导出到 GitHub
Figma Make 可下载代码 ZIP，也能推送到 GitHub。首次推送建议使用新的私有仓库或隔离分支，不要直接进入生产仓库默认分支。
推送后执行：
- 安装依赖并锁定版本；
- 运行 lint、类型检查、测试和生产构建；
- 搜索密钥、个人数据和内部 URL；
- 使用依赖与许可证扫描；
- 建立 pull request，由另一位开发者 review；
- 配置预览环境，不直接覆盖生产。
官方文档说明，外部 IDE 修改不会自动回流到 Figma Make。团队必须指定真相来源：原型冻结后通常以 GitHub 为准；需要更新设计时，再通过明确版本和截图同步，不要两边同时自由编辑。
第十步：安全发布
发布前在 Make settings 检查标题、描述、favicon、URL 和访问范围。Organization 与 Enterprise 可选择公开或组织内部受众；管理员可能关闭公开发布。密码保护适合有限测试，但预览与正式发布的访问规则可能不同，必须分别检查。
发布前删除：
- 真实姓名、邮箱、客户项目与内部文档；
- API key、测试密码和长期 token；
- 未授权图片、字体、图标与社区素材；
- 调试日志、内部链接和管理员入口；
- 不需要的分析或第三方脚本。
发布后从未登录浏览器打开链接，检查页面、元数据和访问权限。让一名未参与生成的人完成核心任务，并记录失败位置。
第十一步：控制 credits 和返工
每轮 prompt 都可能消耗 credits，复杂任务和大上下文通常更贵。降低总成本的方法：
- 首轮先计划，再生成；
- 输入代表性设计而非整个文件；
- 把验收标准一次写清；
- 使用局部选择做单点修改；
- 复用 Make kit、模板与 guidelines；
- 每轮先验证，再继续下一轮；
- 到达代码接管点后停止在两个环境重复修改。
同时记录 prompt、credits、结果、问题和修复。这样才能判断 Make 是否真的比传统原型与开发流程节省时间。
上线前最终清单
- 没有真实客户数据、密钥和测试密码；
- 页面、组件、状态和响应式符合验收表；
- 键盘、焦点、表单和颜色对比完成检查；
- 第三方素材、字体、依赖和生成内容可合法使用；
- GitHub 已运行测试、构建、扫描和人工 review；
- 认证、权限、支付和数据操作由服务端验证；
- 发布受众、分享链接和组织策略符合预期；
- 有错误监控、成本预算和回滚方案；
- 外部修改与 Figma Make 的真相来源已经约定。
最终建议
先用 Figma Make 验证用户流程和视觉，再决定哪些代码进入正式仓库。小步生成、局部修改、明确验收和及时交接，通常比一次要求 AI “做完整产品”更稳定。Figma Make 可以显著缩短高保真原型与第一版实现，但安全、代码质量、商业许可和生产运维仍由团队负责。
官方资料
常见问题
- Figma Make 可以免费使用吗？
- Starter 和部分非 Full seat 可以试用，但创建团队文件、使用 library、共享、代码和发布能力会因计划与席位不同。AI credits 和管理员设置也会影响可用范围。
- 应该把整个 Figma 文件都提供给 Make 吗？
- 不建议。选择代表性页面、核心组件、关键状态和明确规则，删除过期方案与敏感数据，通常能减少混淆、返工和 credits 消耗。
- Figma Make 生成的代码可以推送 GitHub 吗？
- 可以下载代码 ZIP 或推送 GitHub。外部 IDE 修改不会自动同步回 Make，因此团队需要约定设计冻结点和代码真相来源。
- 能在 Figma Make 中接真实数据库和登录吗？
- 可以构建相关功能，但生产认证、权限、数据库、支付与敏感数据必须由工程团队实施服务端校验、测试、监控和回滚，不能只看预览是否可用。
- 如何减少 Figma Make 的 AI credits 消耗？
- 复杂任务先规划，限制输入上下文，明确页面、状态和验收标准，用 point-and-edit 做局部修改，并复用 Make kit、模板与 guidelines。
- 发布 Figma Make 应用前要检查什么？
- 检查受众、组织发布策略、密钥、客户数据、第三方素材、无障碍、响应式、代码依赖和元数据；从未登录浏览器重新验证公开访问。
- Figma Make 可以替代开发者吗？
- 它能加快功能原型和第一版代码，但复杂后端、安全、性能、测试、数据治理和生产运维仍需要开发者及相关专业人员负责。