Figma AI不是一个包办全部设计与开发工作的按钮。要快速试一个可交互方案，重点看Make；要让代码智能体理解现有设计，重点看MCP提供的设计上下文；要重复使用团队规范，再看Make kits。先确定结果要留在设计画布、Make文件还是代码仓库，才能选对入口。
如果还不熟悉基础工作区，可以先查看Figma功能与入门教程；已经确定使用Figma的团队，则应把精力放在下面几条不同的工作链路上。
1. Figma AI、Make与MCP分别做什么
| 要完成的任务 | 主要入口 | 得到的内容与后续位置 |
|---|---|---|
| 从需求或设计快速验证界面 | Figma Make | 可交互预览及相应代码，在Make继续对话或修改 |
| 让代码助手读取已有页面的结构 | Figma MCP server | 设计、布局、变量和组件等上下文，交给连接的开发工具使用 |
| 按团队已有组件和规则生成 | Make kits | 结合代码包、设计库样式和规范的生成基础 |
| 在设计文件中维护正式稿件 | Figma Design及具备相应权限的画布操作 | 可维护的设计图层和团队规范，不要只保留预览链接 |
同一块界面可以在这些入口间流转，但它们并不是同一种文件。能点击的网页预览、能编辑的设计图层、能合并到项目的代码，应该分别检查。
2. 用Make验证任务，先给页面关系再给视觉要求
根据Figma Make创建文件说明，可通过描述、设计附件和持续对话生成交互内容，并继续编辑预览或代码。开始时先告诉它用户要完成什么、从哪里进入、操作后到哪里；品牌色和圆角放在这些约束之后。
制作一个阅读清单流程：用户选择题材后进入推荐列表，可以收藏书籍；列表为空时提示调整偏好。先实现选择、继续、返回和收藏反馈。不要接入真实支付，不要编造用户已有书单。视觉沿用所附设计中的字体和按钮样式。
第一次生成后只走一条完整路线：选择题材→继续→查看推荐→返回修改。若“返回”重置了所有偏好，应该直接要求保留已选值，而不是再发一句“优化体验”。有结构的Figma附件也比只有截图更容易说明组件和布局关系。
3. Make kits用于约束重复生成
多个文件反复出现不一致的按钮、颜色和布局时，问题往往不是提示词不够长，而是团队规则没有进入生成上下文。Make kits官方说明提供了连接代码包、设计库样式与使用规范的方式。适用席位与套餐也在该文档中列出，建立流程前先确认团队可用范围。
- 把“主要操作使用哪一种按钮、何时禁用”写成规则，避免只提供一张品牌视觉图。
- 先用一个包含表单、错误状态和长文案的页面测试规范是否被采用。
- 修正规则后再次生成同类内容，观察错误是否减少，再向团队发布。
仅把组件库名称写进提示词，不足以证明生成结果已经使用真实组件。检查组件引用、属性和样式来源，才能区分“长得相似”和“已经复用”。
4. MCP连接设计与代码，仍需要清楚的修改范围
Figma MCP官方文档已经同时介绍读取设计上下文和写入画布的能力。实际能用哪些工具，取决于连接方式、权限与客户端支持，因此不能简单写成“只能读”或“所有代码助手都能任意改稿”。
开发任务可以这样拆：先指定一个设计节点和目标组件，再要求助手读取布局与变量；说明项目中已经存在的Button、Input等组件位置；最后检查生成的差异。这样比“把整个项目全部写出来”更容易定位问题，也减少另造一套组件的机会。
按照指定的课程卡片实现界面，复用项目现有Button与主题变量。先列出设计中能确认的间距和状态，以及尚缺的接口字段；确认后只修改课程卡片相关文件。
5. 从方案到交付，检查三种一致性
- 任务一致：预览中的主要操作、返回和错误反馈与需求对应，不止默认页面看起来像。
- 组件一致：字体、变量、组件属性和交互状态符合团队约定，避免每页生成一套新的实现。
- 实现一致：放进真实工程后能够运行，数据与权限按项目规则处理，差异经过评审。
对于已经进入代码仓库的结果，可参考从现有代码生成有检查价值的单元测试，为输入校验、状态变化和关键逻辑补上断言。测试要验证预期行为，不能只证明生成文件能被导入。
6. 常见问题
Make生成的界面就是正式设计稿吗？
不能只凭外观这样判断。正式稿还需要可维护的结构、团队组件和明确版本；Make预览更适合验证运行与交互。先确认接下来是设计师改图层，还是研发改代码，再选择保留与交接方式。
MCP连接成功，为什么结果仍不符合规范？
连接成功只说明工具可以访问相应上下文。还要看是否选对节点、是否提供组件映射、是否明确项目约束。用一个组件排查，通常比一次生成整站更有效。
最开始应该试Make还是先接MCP？
还在确认方案时先试Make；已有设计和代码工程、准备实现具体功能时再接设计上下文。若团队每次生成都偏离规范，再把规范整理进可复用的kit。
