Figma Agent 功能在 AI 与画布之间嵌入设计规则

尽管这项技术的行为仍难以预测，Figma 推出了新的 Figma agent 功能，让团队能够更好地掌控 AI 输出。这次发布将 agent 与书面规范、设计库、代码源和可运行原型连接到同一平台中。

这不只是又一个助手获得了更多命令。Figma 正试图在生成式界面扩散到产品团队之前，定义 agent 周围的运行环境。它押注于：共享上下文、可见的工作过程和可执行的设计规则，比不受限制的生成能力更重要。

这一定位使 Figma 站在设计师与 Claude Code、Codex、GitHub Copilot 和 Cursor 等外部编程 agent 之间。Figma 不只在模型性能上竞争，还希望让其画布成为团队决定 agent 应构建什么的控制平面。

新的 Figma Agent 功能在生成前定义规则

Figma 正将 agent 控制权从个人提示词转移至共享的产品基础设施中。

该公司在其首届印度 Config 活动期间宣布了这一扩展工作流。核心新增功能是 Figma Specs，这是一种基于 Markdown 的工作区，用于记录产品需求、决策、参考资料和技术上下文。

规范既可以作为独立的 Figma 文件存在，也可以与画布上的工作并存。团队可以引用设计、FigJam 图表、代码层和其他材料，而无需把一切都简化成脱离语境的文字。

这种结构很重要，因为 agent 很少仅仅由于语言生成能力不足而失败。它往往缺少需求、视觉组件、代码实现以及团队既有决策之间的关联。

传统 Markdown 文件能够描述这些关系，却无法自动保留它们。链接会失效，图像会失去上下文，不同文件还可能给出相互矛盾的指令。

Figma Specs 旨在让这些连接成为原生能力。根据公司的发布概览，团队可以将粗略想法转化为详细规范，并通过 Figma 的 MCP server 将其交给编程 agent。

Model Context Protocol，即 MCP，是一种让 AI 系统能够连接外部工具和结构化上下文的标准。在 Figma 的实现中，它可在画布与受支持的开发 agent 之间传递产品信息。

该工作流始于 agent 编写代码之前。团队可以在规范中汇集需求、图表、设计参考和代码上下文，再在生成过程中使用这些材料。

相同的上下文也可支持代码层——这是一种由运行中的代码支持、位于 Figma 画布上的交互式原型。这样一来，原型可以与生成它的设计和决策一同接受检查。

Figma 还扩展了设计系统可提供的信息。团队可以为已发布的库添加书面指南，并连接来自 GitHub 仓库或 npm 包的代码源。

指南可以记录规则、首选模式、禁止使用的处理方式和实现细节。当启用相关库时，agent 可以读取这些材料。

代码源则增加了另一层基础支撑。它让 agent 能够访问已实现的组件，而不是被迫从截图或视觉画面中推断每一个界面元素。

这种组合形成了上下文层级。规范描述团队打算构建什么，设计库定义其视觉语言，代码源则展示元素如何在软件中运作。

agent 公告还强调了对设计库、代码库和指南的集中管理。Figma 表示，agent 在创建或编辑工作内容时可以查阅这一系统。

这些控制机制解决了生成式界面中反复出现的问题：模型可能生成一个看似可信的屏幕，却仍然忽视组织的组件规则、交互模式或无障碍实践。

精致的结果不一定是有效的产品结果。它可能看起来正确，却产生重复组件、不受支持的状态，或需要开发人员日后替换的实现工作。

Figma 的答案并非取消提示词，而是用属于团队、而非发起某一次聊天的个人的持久上下文来环绕提示词。

这改变了提示词本身的角色。它成为受治理工作区中的一项请求，而非 agent 与产品之间唯一的指令。

Figma Code Layers 将运行中的软件带到画布上

Figma code layers 让画布成为测试行为的场所，而不只是审阅视觉呈现。

作为此次发布的一部分，code layers 已从封闭测试进入公开测试。Figma 表示，该功能正在其各类套餐中逐步推出，不过不同账户获得访问权限的时间可能不同。

一个 code layer 包含由运行中代码支持的可用界面。团队可以将其置于传统设计画面旁边，复制它，测试不同方向，并检查交互状态。

这种区别很重要。传统原型可以模拟穿行于相连画面之间的路径，却可能无法代表真实组件的行为。

运行中的实现可以呈现加载行为、空状态、错误、响应式布局和复杂交互。这些细节常会暴露静态屏幕未能解决的产品问题。

code layers 指南列出了几种起点。用户可通过 Figma agent 生成图层、转换设计、导入代码，或从现有团队代码库开始。

设计师可以选择成熟的结账流程，并要求 agent 添加另一种配送选项。生成的 code layer 可以展示验证、加载、成功和失败行为。

随后，团队可以复制该版本，并在旁边测试另一种交互方式。产品经理、设计师和工程师可以在同一个共享文件中比较可运行的方案。

Figma 表示，更改可以回流到 code layer，并且在受支持的工作流中，也可回流到所连接的代码库。这一承诺比简单的设计转代码导出更具影响力。

导出通常只是交接产物。连接的 code layer 则旨在继续成为设计探索与实现之间迭代循环的一部分。

Figma 于 2026 年 6 月首次以封闭测试形式推出 code layers。其早期的画布预览支持 GitHub 导入、本地文件夹、模板、Figma Make 输出以及由 agent 生成的起点。

公开测试将这一模式带给更广泛的用户群体。这也将更大范围地检验：由代码支持的协作能否在经过精心挑选的团队之外发挥作用。

眼下的用例并非自动交付生成的代码，而是让代码足够低成本，从而可在产品探索阶段使用。

Figma 首席设计官 Loredana Crisan 表示，代码创建与实际发布之间的差距正在扩大。她告诉 TechCrunch，组织产出的代码增加了 17 倍，而发布量仅增加了 1.3 倍。

这些数据由公司提供，不应被视为独立的行业基准。尽管如此，它们解释了 Figma code layers 背后的策略。

生成的代码正越来越多地被用于探索那些永远不会进入生产环境的可能性。Figma 希望这类探索性工作发生在团队能够共同查看、讨论和完善的地方。

这重新定义了代码：它不再只是最终实现媒介，也是一种设计材料。产品团队可以利用可运行的软件，在投入生产架构之前明确自己应构建什么。

这种方式也承认，基于终端的 agent 会话通常难以共享。开发人员可以快速生成多个界面，但协作者事后可能只能收到一个链接或录屏。

这一过程将替代方案、提示词和结果背后的权衡隐藏起来。将可运行版本带到画布上，能让探索过程可见，也更容易受到质疑。

不过，可见性并不会让原型代码具备生产就绪性。团队仍需要工程审查、测试、安全控制、无障碍验证和可维护的架构。

因此，code layers 的价值取决于团队如何界定其输出。将其作为探索性产物使用，能够缩短反馈循环，同时不会假装生成的原型已是完成的软件。

真正的竞争是共享上下文对阵孤立的 Agent 聊天

Figma 押注于：受治理的上下文将比哪个 agent 能最快生成首个草稿更重要。

这个故事中的主要对手并非另一家设计供应商，而是将产品工作置于私密聊天、终端或彼此脱节的浏览器会话中的孤立 agent 工作流。

编程 agent 已经能够根据文字和图像生成界面。它们的速度在每个参与者依据不同指令和本地上下文工作时，带来了新的协作问题。

一位设计师可能附上最新的组件库。一位开发人员可能使用较旧的仓库分支，而产品经理则提供从另一份文档复制来的需求。

每个 agent 都可能给出看似合理的答案。但这些输出仍可能相互冲突，因为这些系统从未获得同一份事实来源。

Figma Specs 试图通过为上下文提供一个可见的归宿来减少这种碎片化。它让需求靠近其所引用的图表、设计、代码层和决策。

设计系统的扩展处理的是相关问题。Figma 希望 agent 不仅理解可用组件，也理解支配其使用方式的规则。

一个库可能包含多种按钮变体，却没有解释哪一种适用于破坏性操作。指南可以补足这种缺失的决策逻辑。

同样，访问代码源可以让 agent 了解某个组件是否已存在。这可以减少它生成一个视觉相似却行为不兼容的替代品的冲动。

Figma 现有的 agent 现已支持跨文件搜索、附加平台内容、引用库元素，以及并发运行多个提示词。其agent 文档还区分了内置 agent 与外部 MCP 客户端。

内置 agent 直接在设计文件中工作。外部 agent 可以利用 Figma 的写入画布能力，将代码库或其他 AI 项目中的内容带入平台。

这种区分让 Figma 能够支持多个 agent，而无需让单个助手承担每一项任务。该公司可以作为不断变化的模型与开发工具群之下的共享层继续存在。

据该公司称，其 MCP 支持现已新增 20 多个合作伙伴。已公布的名单包括 OpenCode、Dia、Meta Muse 和印度 AI 初创公司 Sarvam。

Figma 此前已将 Claude Code、Codex、GitHub Copilot 和 Cursor 列为可写入文件的外部 agent 示例。扩展后的合作伙伴支持使模型中立性成为平台策略的一部分。

这是一种可辩护的定位，因为模型排名变化很快。团队可能偏好用一种 agent 编写界面代码，另用一种进行研究、文档编写或图像生成。

Figma 并不需要赢下每一次模型对比，只要它能掌控共享的产品上下文。它需要让代理将 Figma 的文件、库和规则视为权威输入。

该公司的 MCP canvas update 明确展现了这一目标。技能可以指导外部代理如何执行工作流、安排步骤顺序，以及遵循团队惯例。

在这里，技能是一套可复用的指令，用于塑造代理的行为。它可以编码原本只会留存在某位员工提示词历史中的运营知识。

设计系统团队可以创建一项用于构建表单的技能。其指令可能要求使用获批的字段组件、无障碍标签、有文档记录的验证状态，以及特定的间距令牌。

外部编码代理随后便可在创建或更新资产时应用这些规则。Figma 的画布会展示最终成果，而更广泛的团队原本就在那里协作。

这类似于一个结构化的工程知识库，但其上下文直接附着于产品工件。区别在于，决策在何处变得可执行。

因此，新兴竞争的核心是编排。设计工具、代码编辑器、代码仓库和文档系统都希望成为代理获取可信上下文的场所。

Figma 的优势在于，许多界面决策已经存在于其画布上。但这一优势只有在平台能让这些决策与生产代码保持同步时才能成立。

可预测的代理仍依赖并不完美的输入

Figma 可以约束代理行为，但无法保证每条规则都完整、最新或被正确理解。

公司之所以引入这些控制机制，是因为生成式 AI 仍具有非确定性。同一请求在不同运行中可能产生不同的结构、细节和实现选择。

指南可以缩小这种差异，但无法消除它，尤其是在指令相互冲突或未覆盖新情况时。

团队可能要求代理使用首选组件，但其连接的代码仓库中存在两种实现。设计库可能标识了其中一个版本，但生产代码可能依赖另一个版本。

规格说明带来了另一项维护义务。一份结构良好的规格说明，只有在其要求反映当前决策时才有帮助。

过时的上下文可能使代理持续出错。这种失败比明显的幻觉更危险，因为输出看上去可能受到治理且值得信赖。

设计系统团队将需要为代理指令制定所有权规则。他们必须决定谁可以发布指南、连接代码源、解决冲突并批准变更。

Figma 正在预览通过映射和系统检查进行集中式设计系统管理。这些工具旨在揭示依赖关系和缺口，包括缺少的描述或交互状态。

这一管理层必不可少，因为代理访问会放大薄弱系统文档所带来的后果。过去，未被记录的组件更难被人正确使用。

如今，代理可以在数分钟内将这种误解复制到许多屏幕中。更快的生成会同时放大良好标准与被忽视的问题。

访问控制也带来另一项担忧。将代理连接到设计、规格说明、代码仓库和外部服务，会扩大包含专有产品信息的暴露面。

Figma 表示，MCP 能力受益于其安全性和可靠性控制。企业团队仍需审查权限、数据保留、连接的客户端以及代码仓库访问。

该平台允许管理员禁用 AI 功能，但现有控制对一些组织而言可能过于宽泛。根据 Figma 的支持文档，禁用代码层也可能会禁用其他 AI 功能。

团队可能希望基于项目敏感度、代码仓库、模型提供商或用户角色制定更细粒度的政策。治理的有效性将取决于这些控制机制如何发展。

采用情况同样尚不确定。设计师可能欣赏由代码支持的探索，但未必愿意维护代理指令或排查导入的代码仓库问题。

开发者可能会抵触那些看似可信、却与既有架构冲突的生成结构。产品经理可能创建细致的规格说明，而它们又会成为另一份需要同步的文档。

早期用户讨论已经提出了关于代码仓库导入、基础设施错误，以及 AI 功能是否分散了对长期产品需求关注的问题。这些个案并不能证明整体产品质量。

但它们确实表明了公开测试版必须检验什么。Figma 需要证明，代码层能够在真实代码仓库和日常团队约束下可靠运行。

该平台还面临概念层面的风险。将需求、设计、代码、内容和代理控制结合起来可以减少碎片化，但也可能让 Figma 本身更加复杂。

共享画布的成功前提是，每位参与者都能理解相关状态，而无需掌握每个底层系统。过多重叠的界面会在一个产品内部重现协调问题。

Figma 关于更高质量、更符合品牌规范的生成主张，也需要独立证据支持。该公司展示了上下文如何进入工作流，而非代理能多稳定地遵循这些上下文。

团队应衡量结果，而非想当然地接受这些主张。有用的指标包括组件复用率、无障碍缺陷、返工、审查时间，以及原型与生产代码之间的偏差。

核心问题不在于代理能否生成一个美观的屏幕，而在于该屏幕能否经受真实设计系统和代码库的检验。

Figma Specs 将平台扩展到设计文件之外

Specs 让 Figma 的代理战略成为一项更广泛的尝试，旨在于画布之前和之后掌握产品决策。

传统上，产品规格说明存在于文档工具、工单系统或代码仓库中。视觉工作随后转入 Figma，而技术实现则转移至其他地方。

每一次转移都会产生一个翻译步骤。需求可能丢失细微差别，设计可能偏离获批行为，而开发者可能对不完整的交接说明作出不同理解。

Figma Specs 挑战了这种分离。它将 Markdown 视为灵活媒介，同时把它嵌入 Figma 的视觉和技术工件网络中。

产品经理可以起草需求并引用 FigJam 图表。设计师可以连接相关屏幕，而工程师可以从 GitHub 添加代码上下文。

代理随后可以利用这些组合材料创建代码层，或通过 MCP 传递规格说明。规格说明成为活跃输入，而不再只是由人审阅的文档。

这扩大了 Figma 可覆盖的工作流。该平台不再局限于创建界面设计并将其交给开发团队。

它希望参与产品定义、原型制作、实现上下文和内容运营。每增加一个界面，都会使共享上下文对代理更有价值。

Figma 的 Payload 集成强化了这一方向。Payload 是一个开源无头内容管理系统，于 2025 年加入 Figma。

这项新集成将 Payload 与 Figma Make 连接起来，后者是该平台基于提示词的应用与网站构建工具。团队可以创建由数据支撑的体验并管理内容，无需将视觉原型与其内容模型分开。

Figma 表示，Payload 下载量在此前 12 个月中增长了六倍。这是公司自行报告的指标，并未揭示有多少项目使用了这项新集成。

尽管如此，这种组合解决了生成式网站的一项实际局限。当内容仍被硬编码，或与发布工作流脱节时，精美的页面价值就会降低。

Payload 提供内容存储、API、工作流和管理界面。Figma 表示，营销人员可以管理内容，同时开发者仍可访问开源框架。

这也进一步明确了为探索而构建与为发布而构建之间的区别。一次性的原型只需要足够的行为来验证一个想法。

生产网站则需要持久化内容、权限、数据结构和运营工作流。集成 CMS 让 Figma Make 更接近后一个类别。

公司谨慎地保留了退出路径。它表示，团队可以将基于 Payload 的工作移出 Figma，这对担心平台锁定的开发者很重要。

不过，可移植性必须通过实际项目评估。可导出的代码并不必然意味着在缺少生成环境的情况下也易于维护。

更广泛的战略同时给多个类别带来压力。文档工具承载规格说明，编码代理生成实现，而网站构建工具则结合视觉编辑与部署。

Figma 并非要用一种模型取代所有工具。它试图成为让这些工具输出得以连接的共享底层。

这一做法契合公司现有的协作模式。Figma 之所以成为产品团队的核心，是因为其文件支持多人编辑、评论、组件和共享库。

代理增加了一类新的参与者。与人类协作者不同，它们能够迅速修改大范围内容，并通过机器可读接口跨工具运行。

因此，该平台必须同时支持协作与约束。它需要让代理工作可见，同时限制错误指令的传播范围。

Figma Specs、代码源和指南是独立功能，但结合使用时，其价值会相互叠加。每项功能都解决了上下文问题的不同部分。

Specs 解释意图。库表达可复用的设计决策，而代码源则让这些决策扎根于实现。

代码层提供了一个可执行的场所来测试结果。MCP 则将这一流程与在其他地方运行的代理连接起来。

这就是 Figma 代理在公司新兴模式中的工作方式。它们并非只是接收提示词并生成一个屏幕。

它们运行于由产品上下文、共享规则、工作工件和人工审查构成的链条中。这条链条就是产品战略。

三个信号将显示 Figma 的代理战略是否奏效

下一项考验在于，受治理的代理工作流能否改善真实团队成果，同时不增加另一层维护负担。

第一个信号是公开测试版推出后代码层的采用情况。仅有访问权限并不能证明价值。

团队必须在画布上反复创建、复制、审查和优化可运行的原型。持续使用将表明，由代码支持的探索解决了真实的协作问题。

最有用的证据将比较采用前后的工作流。更短的审查周期、更少的交接修改，或对交互状态更好的呈现，都将支持 Figma 的论点。

被放弃的导入、不可靠的执行，或在外部工具中频繁重建则会削弱这一论点。公开测试版让 Figma 能够通过更大规模的用户群发现这些问题。

第二个信号是，设计指南和代码源能否减少代理错误。团队应看到更多获批组件的复用，以及更少的品牌或实现不匹配。

Figma 10 月的发布说明确认，代理可以读取库指南、搜索文件、附加平台上下文并支持自定义技能。这些能力确立了机制，而非结果。

决定性证据将来自反复的生产使用。一个成功的系统应能帮助代理遵循惯例，而无需用户在每条提示词中重复说明。

它还应当让冲突显而易见。如果设计库与代码仓库存在分歧，系统必须帮助团队识别哪一方才是权威来源。

否则，额外的上下文可能会增加歧义。一个代理可以获得更多信息，却反而更不确定该遵循哪条指令。

第三个信号是外部代理支持的发展情况。当团队能够在不重建设计上下文的前提下更换模型时，Figma 的平台论点会更有说服力。

对更多 MCP 客户端的支持能够带来分发能力，但兼容性必须超越基础写入权限。外部代理需要可靠地访问组件、变量、指南、图片以及代码关联关系。

Figma 表示，它正致力于实现与其 Plugin API 更广泛的功能对等。相关进展将决定外部代理会成为完整协作者，还是受限的导入工具。

竞争对手的应对同样重要。代码编辑器和开发平台可以深化自身的设计集成，而文档系统则可以让规范更便于代理理解。

如果这些工具能在不经由 Figma 路由工作的情况下保留上下文，团队可能会更偏好分布式工作流。Figma 必须证明，集中化能带来更清晰的决策，而不只是增加对平台的依赖。

对设计师而言，实际问题在于画布是否仍是进行判断的场所。代理应当加速变体制作和常规编辑，而不是让设计评审沦为输出内容清理。

对开发者而言，问题在于代码层是否保留了有用的实现上下文。生成的原型必须揭示其中的权衡，而不能被误认为已经过审查的生产代码。

对产品负责人而言，价值在于可追溯性。一项需求应当能够关联到塑造它的设计、原型、代码来源和决策。

Figma 的代理功能如今已为这套工作流提供了组成部分。未来几个月将揭示，团队能否在日常压力下让这些部分保持同步。

应将开放测试视为一次运营实验。选择一个边界明确的工作流，连接现有来源，明确所有权，并在扩展前衡量返工情况。

重要的问题已不再是 AI 代理能否绘制一个界面，而是你的团队能否说明该界面为何符合其标准，以及在不符合时如何纠正。