ARTICLE · 1238324
设计师AI工具 Figma Agent、Figma Make 和 MCP 到底该怎么选
设计师AI工具 Figma Agent、Figma Make 和 MCP 到底该怎么选一个常见的设计任务是这样的。 产品经理刚把需求文档发过来，希望设计师当天给出两个方向，第二天拿一个可以点击的版本去做内部评审。开发也在群里问，组件能不能直接复用，交互状态什么时候能补齐。 设计师打开 Figma，工具栏里已经不止一种 AI 能力。Figma Agent 可以直接修改画布，Figma Make 可以从提示生成可交互的产品，MCP 又能让外部编码 Agent 读取设计文件。三个工具都能缩短制作时间，接手的环节却不一样。 2026 年 5 月，Figma 推出了原生 Design Agent。一个月后，它又加入自定义 Skills、外部连接器、生成式插件和 Shader。Figma Make 已经从提示生成原型走向可发布的应用，MCP 则在设计稿和代码之间传递组件、变量与实现信息。 对设计师来说，最实用的判断方法很简单。先看这一次要交付的是设计稿、可操作的原型，还是能够进入开发流程的设计流程。 一个设计需求，为什么会同时遇到三种 Figma AI 工具 一个设计师要改版会员中心。旧页面已经在 Figma 里，新的权益说明来自产品文档，评审时还需要演示开通和取消订阅的完整过程。开发希望尽早知道哪些组件可以沿用。 这项任务里同时出现了三种产物。 第一种是可继续编辑的设计稿。页面结构、组件实例和变量关系都要保留，后续还会有多轮调整。Figma Agent 适合处理这一部分。 第二种是可以点击和运行的体验。评审者需要亲自走完订阅流程，看看弹窗、等待和失败状态是否合理。Figma Make 更适合把设计意图变成可操作的原型。 第三种是交给开发的完整流程。工程师需要知道这个按钮对应代码库里的哪个组件，间距使用哪一个变量，页面在不同状态下怎样变化。MCP 负责把这些信息带到编码工具里。
三个工具会出现在同一个项目里，因为它们接手的是不同阶段。设计师先把当前要解决的问题说清楚，选择就不会太难。 
一个设计需求中的三种 Figma AI 交付物 直接修改设计稿时，先用 Figma Agent 一个常见任务是把十二个页面里的旧按钮换成新组件，同时调整文案，再补一套深色模式。过去要逐页检查，漏掉一个状态，评审时就会被翻出来。 Figma Agent 直接工作在设计画布上。设计师可以从某个图层发起指令，让它修改选中的页面，也可以同时生成几个方向。它还能调用文件里已有的组件、变量和样式，批量处理重复编辑。 这类能力适合三种工作。第一类是替换和整理，包括统一命名、更新组件和填充真实内容。第二类是扩展现有设计，比如补充空状态、错误状态或移动端版本。还有一类是处理反馈，Agent 可以整理评论，再根据选定意见生成新的设计版本。 使用时不要只写一句“帮我优化这个页面”。这句话给了 Agent 很大的活动范围，也把验收标准留空了。更稳妥的指令需要写清修改对象、保留内容和完成条件。 例如，先选中会员中心的三个页面，再要求 Agent 使用指定组件库，把主要操作统一成同一种按钮，保留现有信息结构，同时补出加载失败状态。修改完成后放到新的分区，不覆盖原稿。 设计师还可以先做一页示范，让 Agent 沿用它的间距、字体层级和组件选择。Figma Agent 会优先参考近期使用的组件，也支持指定某个组件库，或者通过引用组件和变量缩小选择范围。 这一步的目标是让 Agent 在一块明确的画布里工作。范围越清楚，设计师后面收拾残局的时间越少。 
Figma Agent 在画布中批量修改组件 快速验证交互想法时，Figma Make 更合适 评审会上，负责人问了一句，用户取消订阅以后会看到什么。静态稿里只有开通成功页面，设计师只能一边翻图，一边口头解释返回路径和确认弹窗。 需要验证流程时，Figma Make 更合适。它可以根据提示和已有设计生成高保真、可交互的原型，也能继续通过对话修改页面和行为。设计师可以导入现有的 Figma 设计库，让生成结果沿用团队的颜色、排版和基础样式。 Make 的价值出现在那些必须运行起来才能判断的问题上。一个表单填错以后怎样恢复，一次支付需要经过几个状态，筛选条件改变后列表怎样响应，这些问题只看静态页面很难发现。 给 Make 的输入也要从页面描述走向行为描述。除了告诉它要做一个订阅页面，还要交代用户从哪里进入，完成什么操作，成功后去哪，失败时保留哪些信息。涉及数据的原型，可以说明数据结构和几种典型结果。需要演示真实读写时，Make 还支持连接 Supabase。 设计师可以先用 Make 做一条主流程，把交互跑通，再把关键页面带回 Figma Design 精修。也可以先在 Design 里确定视觉方向，随后送进 Make 检查行为。Figma 官方给出的工作流本身就允许两个方向来回切换。 原型能运行以后，评审会少掉一部分口头说明。团队面对的是同一个操作过程，讨论也更容易落到具体状态。 
Figma Make 验证可交互流程 设计稿需要进入开发环节时，再使用 MCP 设计师交付了一个新的筛选面板。开发照着页面写完后，按钮高度差了几像素，颜色变量也没有使用组件库里的正式值。两边都没有偷懒，信息在传递过程中还是丢了。 Figma MCP Server 解决的是设计上下文如何进入开发工具。接入 MCP 后，Cursor、Claude Code、Codex 等 Agent 可以读取 Figma 里的组件、变量、样式和选中图层，再结合代码库生成实现。 截图只能告诉模型页面长什么样。结构化的 Figma 文件还能告诉它哪些元素属于同一组件，哪个属性是变量，页面用了怎样的自动布局。Code Connect 进一步把 Figma 组件映射到代码库中的真实组件，编码 Agent 就不用重新猜一遍。 设计师想让 MCP 发挥作用，文件本身要经得起读取。 这些工作原本就属于良好的设计交付。Agent 进入流程以后，它们还会直接影响生成代码的质量。设计文件越清楚，开发工具得到的上下文越可靠。 
MCP 将设计上下文带入开发工具 Figma Agent 和 Figma Make 可以怎样配合 一个设计师先用 Make 做出活动报名原型。流程已经可以运行，视觉却比较粗。页面复制回 Figma Design 后，他希望统一组件、重新处理层级，再补一套平板布局。 这时可以让 Figma Agent 接手画布修改。Agent 负责调用设计系统、整理图层和生成不同布局，设计师完成选择和精修。交互方向确定后，再把设计送回 Make，继续检查表单提交、页面跳转和失败恢复。 另一条路径从设计稿开始。 这套组合适合需求仍在变化的阶段。设计师可以很快把一个想法做成可讨论的东西，又能保留对图层和组件的控制。 两种工具之间来回时，最好固定一个主版本。Make 里的行为变化和 Design 里的视觉变化都要记录，避免两个文件各自向前走，最后没人知道哪一份才是当前方案。 
Figma Agent 与 Figma Make 的双向迭代 MCP 如何减少设计稿与最终产品之间的偏差 页面上线以后，设计师发现空状态没有实现，长文本把卡片撑坏了，移动端还沿用了桌面端的间距。开发按主页面完成了任务，那些藏在其他分区里的状态没有进入他的实现范围。 MCP 可以把更完整的设计结构带进编码 Agent。工程师选中一个流程或给出节点链接后，Agent 能读取相关画面、变量和组件信息。设计师写下的交互说明和组件映射，也能跟着进入实现过程。 Figma 目前提供两类很关键的连接能力。Usefigma 让外部 Agent 直接创建和修改画布内容，Generatefigma_design 可以把正在运行的网页转成可编辑的 Figma 图层。前者让外部 Agent 直接介入设计画布，后者又能把真实产品带回画布检查。 这让团队有机会建立一条往返路径。设计师交付完整状态，开发用 MCP 获取上下文，功能完成后再把实际页面导回 Figma，对照检查缺失状态和组件偏差。 MCP 无法自动保证还原质量。设计系统没有映射，变量使用混乱，交互状态也没画出来，Agent 得到的只是更完整的一团混乱。团队应该跟踪几项朴素的结果，包括正式组件复用率、设计验收发现的问题数量，以及从交付到第一次可用版本花了多久。 当这些数字持续改善，MCP 才算真正缩短了交付过程。 
设计稿与实际产品的对照验收 哪些设计工作仍然需要设计师亲自完成 Agent 很快生成了三个结账页面。颜色和间距都符合设计系统，第三个方案看起来也最完整。设计师走了一遍流程，发现优惠券入口被放在付款之后，用户已经错过修改订单金额的机会。 Agent 可以把画面做完整，设计师仍要判断这个流程是否帮助用户完成任务。 这种判断来自研究材料、业务条件和对具体场景的理解。模型可以读取这些资料，也能按照指令检查页面。碰到目标冲突时，仍然需要设计师决定先保住什么。注册步骤更短，可能会减少用户信息。风险提示更明显，也可能打断购买。这里没有一条组件规则能直接给出答案。 设计师至少要完成五项检查。 Figma Agent 还能总结评论、模拟不同角色的反馈。这些意见可以帮助设计师发现遗漏，不能代替真实用户研究和团队评审。设计师要知道材料来自哪里，也要分清建议与证据。 Agent 节省下来的时间，适合用来补状态、走流程和验证判断。产出页面的速度已经很快，判断哪一版值得留下仍然需要设计师负责。 
设计师对关键流程作出判断 设计师怎样为真实项目选择工具组合 周一早上，团队要在周三之前完成一个新功能演示。已有设计系统，需求只确定了主流程，开发希望评审后立刻开始实现。设计师没有必要在三个工具之间平均分配时间。 先看下一步要交给谁。 如果下一步仍由设计师继续修改，先使用 Figma Agent。它适合在现有文件里生成方向、补充状态和处理重复编辑。 如果下一步要交给产品负责人或用户试用，使用 Figma Make。它能把页面变成可操作的流程，帮助团队尽早发现行为问题。 如果下一步准备进入开发，接入 MCP。前提是组件、变量和代码映射已经整理到能够被 Agent 理解的程度。 
根据交付物选择合适的 Figma AI 工具 一个较完整的项目可以这样组合。Agent 先帮助设计师扩展方案，Make 负责验证关键流程，方向确定后再通过 MCP 把设计上下文送进开发工具。功能完成以后，把真实页面带回 Figma 做一轮检查。 团队还要提前看账号和成本。Figma Agent 目前仍处于开放测试阶段，正式开放后会消耗 AI credits。Figma Make 已经按照请求复杂度和所用模型计费。大范围推广之前，可以先选一个页面数量有限、组件比较完整的项目，记录节省的时间和新增的返工。 选择 Figma Agent、Figma Make 和 MCP 时，工具名称不用背得很熟。先确定你要修改什么，下一位协作者需要拿到什么，再选择离这份交付物最近的工具。
常用元素尽量使用正式组件 颜色、间距和字体使用变量 页面结构通过自动布局表达 关键交互和异常状态写进标注 图层名称保持可理解，减少无意义的默认命名
在 Figma Design 里确定页面结构和基本视觉方向 让 Agent 补齐状态，处理批量修改 把设计送到 Make，生成可以操作的版本 根据评审结果回到画布继续调整
用户的主要任务有没有被放在合适的位置 页面是否覆盖等待、失败和权限受限等状态 Agent 有没有选错组件或绕开设计变量 交互能否在真实数据和设备条件下成立 最终方案是否满足无障碍和开发约束
