피그마 에이전트가 캔버스에 들어왔다 — 잘 쓰려면 프롬프트보다 디자인 시스템부터 정리하세요 대표 이미지

cdn.sanity.io

Figma Agent 来到画布中——先整理设计系统，再写提示词

Figma Agent 的第一个结果只是设计稿；只有在确认组件和语义变量后，它才会成为团队的设计。设计

The Figma design agent is here

Work with the Figma agent in design files

AI workflows collection: Best practices to help Figma AI understand your design system

界面出来了，可以直接交给开发人员吗？

例如，即使让 Figma Agent 快速生成了支付界面设计稿，检查按钮时也可能发现它不是团队组件，而是一个新图形。即便看起来是同一种蓝色，也可能连接到了错误的语义变量。对于运营设计系统的团队来说，这类后续整理往往比生成速度更令人担心。

Figma Agent 一个实用的变化在于，它不再只交付一张图片，而是在设计人员工作的设计文件中创建可编辑图层。你可以基于选中的图层提出请求，在 Agent 工作时直接修改其他部分，或者在不同框架中并行探索多个方向。

不过，在同一画布上工作并不意味着它会自动理解团队的规则。这正是在写长提示词之前，需要整理 Agent 将要引用的已发布库和组件结构的原因。

先在一个界面中测试是否遵循库规范

第一次尝试不必覆盖整个新产品。一个状态明确的界面，例如登录或支付界面，就足够了。复制原始界面，并按以下流程同时确认结果是否可编辑以及结构是否准确。

创建测试用框架。
在 Figma Design 文件中复制一个现有界面，并选中该框架中的图层。修改文件需要 Full seat 和编辑权限。
从选区打开 Agent。
点击 Agents 或按下 Cmd/Ctrl+Enter，即可针对选区开始编写提示词。如需继续对话，请从设计文件左侧导航区域打开 Agents。
将已发布的库作为上下文连接。
在提示词框的 Add context 中添加团队库；对于所需组件、变量和样式，输入 @ 后从列表中选择实际项目。如果最近修改过库，请先重新发布，确保引用到最新内容。
同时说明允许范围和所需状态。
如下所示，限制只能使用已连接的库，并要求将三个方向分别创建在独立框架中。不要原样发送方括号中的内容；请输入 @，然后从列表中选择团队实际使用的组件和语义变量。

仅使用通过 Add context 连接的 Product UI 库，将选中的支付界面改为三种信息架构。为便于比较，请将每个方向创建在单独的框架中。仅使用[@ 选择的支付摘要组件]、[@ 选择的按钮组件]和[@ 选择的背景与文本语义变量]，不要创建新颜色或脱离库的组件。请在每个方向中展示 default、loading 和 error 状态。

以连接结构而非漂亮界面判断是否成功。
请检查三种变体是否分别以可编辑图层创建在独立框架中，是否使用了团队组件和语义变量，以及是否不存在硬编码值或缺少必需状态。在 Organization 或 Enterprise 计划中，还可以通过 Check designs 进一步查找错误颜色、其他库的元素，以及本应替换为变量的硬编码值。
只撤销错误的部分。
不需要的更改可以通过聊天中的 Undo 或 Cmd/Ctrl+Z 取消。若要比较前后结果，请先复制 AI 修改版，再还原原始版本。

请根据可见状态检查访问问题

如果根本看不到 Agents，请先确认管理员是否禁用了 AI 功能。官方帮助文档中有关适用计划和 drafts 的 seat 范围说明并不完全一致，因此同时检查当前账户 UI 和管理员设置会更稳妥。

如果可以聊天却无法编辑文件，请确认自己拥有 Full seat 和该文件的编辑权限。拥有 View、Dev 或 Collab seat 的用户，以及只读用户，也可以聊天，但文件编辑会受到限制。达到月度使用上限时，产品内会显示限额提示，限额会在每月重置。

提供 Agent 能够组装的高层级模块

优秀的设计系统如今既是供人使用的组件库，也是供 Agent 使用的工作界面。Figma 建议不要只罗列原子组件，而应提供卡片、页头这类已经包含间距、颜色和布局规则的高层级模块。这样可以减少 Agent 每次猜测小元素组合规则的负担。

需要准备的内容很具体：有意义的图层和组件名称、自动布局、明确的 component properties 和 variants、用途清晰的变量，以及通俗的说明。说明中最好写明“何时使用”“与相似组件有何不同”“需要哪些状态”。

整理顺序应从界面中经常使用的模块开始

与其从逐一优化所有按钮名称开始，不如先选择一个在实际界面中重复出现的模块，例如支付摘要卡片、搜索结果行或设置区块。整理并发布该模块的自动布局、属性、状态和语义变量后，再比较 Agent 的结果有多大变化，就更容易确认准备工作的效果。

你也可以使用 Agent 来整理系统本身。官方工作流介绍了文档草稿编写、组件、样式和变量的批量修改、从重复模式中提取候选组件，以及对缺失状态和不一致问题的初步审查。不过，这些结果同样是发布前需要人工确认的草稿。

界面相似，不代表系统得到了保留

一家独立设计工作室的测试显示，在连接库并明确要求使用后，结果有所改善，但仍发现按钮连接到其他语义变量，或文本颜色变量被用于分隔线的情况。还有一些结果在浅色背景上的对比度降低。

该测试基于一家公司的设计系统进行，未公开完整提示词、迭代次数或量化错误率。因此，不能泛化为所有账户和最新版本都会出现同样的错误。不过，它仍提供了一个有用的实务警示：视觉上相似的结果与可交接的结构，需要分别验证。

交给开发人员前，请检查四项内容。

团队组件的实例是否得以保留
颜色、间距和排版是否连接了正确的语义变量
是否具备 default、loading、error、disabled 等所需状态
是否混入了硬编码值和其他库的元素

如果存在问题，请只选中相关图层和变量来请求修改，而不要重做整个界面。

Design Agent 与 Make 的产出不同

如果目标是创建界面结构和视觉变体，Design Agent 是起点。它会生成和编辑 Figma Design 中的真实图层，因此设计人员可以在画布上继续完善。相比之下，Figma Make 专注于创建交互式应用和原型，并将其发布到网页。它还支持往返流程：将 Design 中整理的界面发送到 Make 以具体化交互，或将 Make 中的框架复制回 Design。

如果希望将外部编码 Agent 创建的内容导入 Figma 文件，远程 Figma MCP 服务器的 use_figma 工具提供的 write to canvas 是另一条路径。写入现有文件需要 Full seat 和该文件的编辑权限，导入后的结果必须直接在画布中检查。

不必同时使用这三项功能。使用 Design Agent 探索可编辑界面，使用 Make 验证可点击的交互，使用 MCP 连接外部代码工作与画布，按目的划分后就更容易选择。