当 Agent 成为设计系统的使用者

10 月 6 日，Figma Agent 正式结束 Beta。此次更新加入了 Guidelines，允许组件库维护者为设计库附加 Markdown、文本或 JSON 文件，将组件的使用规则、最佳实践、反例与例外写入其中。当设计师启用这套组件库并要求 Agent 生成界面时，相关说明会自动进入它处理任务的上下文。

团队可以规定红色只用于删除等危险操作，不能作为普通装饰色。这条规则并没有增加新的组件，也没有改变任何变量，却补充了一种仅凭资产无法获得的信息。红色在系统中为何存在，应该出现在哪里，又应当避开什么场景，都属于设计系统背后的判断，而不是组件本身的属性。

传统设计系统主要管理可复用资产。颜色被整理为变量，按钮被封装为组件，常见结构被沉淀为模式，设计师借此减少重复劳动并维持产品一致性。组件能够定义一个对象由什么构成、具有哪些状态、允许怎样配置，却很难独立说明它为什么存在，以及在何种语境中不该被使用。

过去，这部分空缺由设计师补足。团队成员能够结合业务背景理解“谨慎使用强调色”，也知道确认弹窗不该承担普通信息提示的职责。规范没有穷尽所有条件，评审经验、产品认知与长期协作形成的惯例仍能维持系统秩序。

Agent 接入设计系统后，这种依赖默契的机制开始失效。AI 可以准确调用组件、变量和样式，却未必理解团队为何作出这些选择。由此产生的偏差往往不在视觉表面。界面可能完全符合组件规范，颜色和间距也没有错误，但整个方案建立在不恰当的场景判断之上。它使用了正确的资产，却没有作出正确的设计决定。

Guidelines 补充的是组件之外的决策条件。组件继续回答系统提供了哪些能力，规则则说明这些能力应当怎样进入特定语境，哪些用法需要避免，出现例外时又该如何处理。设计系统管理的对象随之发生变化。它不再只维护界面的构成材料，也开始维护 Agent 选择和组织这些材料时所依据的判断。

这会改变设计规范的写法。面向使用者的文档可以保留一定的概括，因为读者能够借助经验补全语义。“适度强调”“保持简洁”“谨慎使用弹窗”对成熟设计师可能已经足够，对 Agent 却很难形成稳定约束。。

Figma 建议团队围绕使用场景组织规则，分别说明应该怎样处理、不应该怎样处理，以及作出这种选择的原因。存在例外的规则还需要写明例外条件。规范由此不再只是对设计成果的解释，也成为机器参与设计决策时可以调用的依据。团队原本通过评审、示范和协作经验传递的知识，需要被重新整理为较为明确的条件与边界。

设计系统的成熟度也不能再只由组件数量、覆盖范围和变量完整度衡量。一套资产完备但语义含混的系统，足以支持熟悉业务的设计师工作，却未必能够支持 Agent 稳定生成。组件之间如何选择，模式适用于哪些任务，视觉表达承担什么产品含义，这些过去散落在个人经验中的判断，会逐渐成为设计系统本身需要维护的内容。

当规则开始影响生成结果，它便不再是一份可以长期静置的说明文档。组件发生变化，相关规则需要同步更新。多个设计库同时启用，规则之间可能产生冲突。Agent 反复生成同一种错误，团队还要判断问题究竟来自组件命名、资产描述、Guidelines、当前提示，还是模型自身的理解能力。

过去，一条模糊规范造成的偏差通常会在评审中被逐个发现。进入 Agent 工作流后，同一处含混表述可能被迅速复制到多个页面。设计系统团队因而需要记录规则版本，抽查生成结果，并将异常案例重新纳入规范。维护重点也会从是否写过某条原则，转向这条原则是否足够准确、是否仍然有效，以及它是否确实改变了 Agent 的行为。

Figma Agent 同期还能够检查组件与变量、识别硬编码值、辅助生成文档，并将重复流程封装为自定义技能。这些能力降低了机械维护的成本，却没有减少设计系统团队的判断责任。机器可以扩大规范的执行范围，也会同步扩大规范缺陷的影响范围。原先能够留到评审阶段修正的问题，需要更早进入规则设计。