Codex 为什么能在 Figma 里接管一部分设计工作？

从设计状态空间、程序生成到闭环验证，理解 AI 设计 Agent 的底层机制

👋嗨，我是范米花儿，这段时间一直在输出、讲课、培训、答疑基础AI工具问题，感觉自己的知识量停滞很久了，所以还是想休息一段时间、去学习。

最近在学习很多AI的底层逻辑，也会让AI帮我输出教程，原文很枯燥、有很多技术知识，所以适当压缩了内容，部分分享给大家。

背景

现在，我们已经可以让 Codex 读取 Figma 页面、查找组件与变量、创建原生节点、调整 Auto Layout，并根据反馈继续修改设计稿。

底层是：

Codex 将设计需求转换成一系列可以读取、执行和验证的结构化操作。

它能够接管一部分设计工作，依赖四个条件：

设计文件可以被结构化读取
设计操作可以被工具化执行
设计规则可以被形式化约束
设计结果可以被持续验证

当一项设计任务同时具备这四个条件，它就开始从手工操作问题，转化成 Agent 可以处理的系统问题。

一、哪些设计工作可以被 Agent 接管

先看整体：Agent 更容易接管目标明确、对象可定位、规则可表达、结果可验证的设计工作。

例如：

使用现有组件搭建页面；
将页面颜色绑定到变量；
批量迁移旧组件；
补充组件状态；
根据模板生成业务页面；
检查页面是否违反设计规范。

这些任务都有明确的起点和终点。

Codex 可以读取当前设计状态，理解目标，规划操作顺序，再通过工具逐步修改文件。

另一类任务仍然依赖较强的设计判断：

产品应该呈现什么品牌气质；
多个业务目标冲突时如何取舍；
当前交互方式是否真正适合用户；

这类问题的目标需要持续探索，评价标准也可能在设计过程中发生变化。

所以，Codex 当前更容易接管的是设计工作中已经可以被形式化的部分：

目标明确
对象可定位
操作可执行
规则可约束
结果可验证
失败可恢复

二、Figma 为什么能成为 Agent 的工作环境

Codex 可以修改 Figma，首先因为 Figma 文件本身就是一份结构化数据。

设计师看到的是画布中的页面，而Agent 读取的是一棵由节点组成的 Scene Graph，也就是场景图。

一个页面内部可能包含：

Page
Frame
Text
Component Instance
Icon
Image

每个节点都拥有自己的：

类型；
Node ID；
父子关系；
位置与尺寸；
Auto Layout 属性；
Fill、Stroke 和 Effect；
组件引用；
变量绑定。

因此，一份 Figma 文件同时包含四层信息：

结构层

结构层描述页面由哪些节点组成，以及节点之间如何嵌套。

例如，一个任务列表可能包含外层容器、列表标题、筛选按钮和多个任务项。

Agent 可以通过父子关系判断这些内容属于同一个模块。

几何层

几何层描述尺寸、位置、间距、对齐、Hug、Fill 和布局约束。

它决定一个模块怎样占据空间，以及内容发生变化后，页面应该怎样重新排列。

视觉层

视觉层描述颜色、字体、圆角、阴影、图片和矢量内容。

它决定最终画面怎样呈现。

语义层

语义层来自节点名称、组件类型、Variant、变量含义和设计规范。

它可以告诉 Agent：

这个节点属于主按钮；
这个颜色是风险提示色；
这个组件是指标卡；
这个变量代表正文主色。

Codex 对 Figma 的修改，本质上是对节点结构进行变换：

创建节点；
删除节点；
修改属性；
移动节点；
改变父子关系；
替换组件实例；
绑定变量；
重组布局。

这和 Codex 修改代码存在相似的底层逻辑。

代码由文件、函数、类型和依赖构成；

Figma 由页面、节点、组件、变量和布局关系构成。

两者都可以被表示、查询和修改。

三、自然语言怎样变成设计操作

当设计师说：“把三张指标卡改成两列布局，保留现有内容，并继续复用原组件。”

工具无法直接执行这句话。

Codex 需要先把需求转换成一组明确条件：

操作对象是指标卡容器与三张卡片。
目标变化是从三列改为两列。
必须保留的内容包括卡片数量、文字内容和组件引用。
允许改变的是父容器布局、卡片宽度和换行方式。
验收条件是最终形成两列，内容保持完整，组件没有被打散。

接下来还要完成三个步骤：

Grounding：找到真实节点

“指标卡”只是语言中的概念。

Codex 需要结合节点名称、层级、组件类型、几何位置和截图，将它对应到真实 Node ID。

这一步一旦出错，后面的规划和执行即使完全正确，也会修改错误对象。

设计文件中的语义命名、组件结构和页面层级，会直接影响 Grounding 的稳定性。

例如，同一个文件中可能存在多个名为 Card 的节点。

Agent 需要继续判断：

它位于哪个页面；
属于哪个父容器；
是不是组件实例；
是否位于用户描述的右侧区域；
是否和截图中的目标模块一致。

Planning：确定操作顺序

Codex 需要判断任务依赖。

它可能先定位目标容器，再读取当前布局，然后检查子节点数量与组件关系，之后修改父容器，再调整子节点尺寸，最后检查组件引用并获取截图验证。

复杂设计任务通常无法通过一次工具调用完成。

当目标组件不存在、变量缺失或文件结构和预期不同，Agent 还需要重新规划。

例如，原计划是复用已有 Task Card，搜索后发现文件中没有这个组件。

Agent 就需要重新决定：

使用基础 Card 和 List Item 组合；
先创建新组件；
或者暂停操作并提示缺少资产。

Program Generation：生成工具程序

最后，Codex 会把计划转换成一系列结构化工具调用。

每次调用都包含：

使用哪个工具；
修改哪个节点；
传入哪些参数；
希望得到什么结果。

因此，Codex 的设计能力可以理解为一条转换链：

自然语言需求

→ 目标与约束

→ 真实设计对象

→ 任务依赖关系

→ 工具调用程序

→ Figma 状态变化

四、MCP 在其中承担什么角色

MCP 负责将 Codex 和 Figma 连接起来。

它向 Codex 描述：

当前可以读取哪些设计信息；
可以调用哪些工具；
每个工具接受什么参数；
执行后会返回什么结果。

在这套系统中，三者的职责可以这样拆分：

Codex 负责理解、规划和判断。
MCP 负责传递信息与工具调用。
Figma 负责保存并修改真实设计状态。

MCP 给了 Codex 观察和改变 Figma 的接口。

它不会替 Agent 决定应该使用哪个组件，也不会自动判断最终设计是否合理。

真正形成设计执行能力的，是模型推理、任务规划、对象定位、工具接口、设计约束和结果验证的组合。

五、设计系统为什么决定 Agent 的稳定性

没有设计系统时，Codex 面对的是一个巨大的设计空间。

它需要自行决定：

使用什么颜色；
多大间距；
什么圆角；
如何构建卡片；
选择哪种按钮；
页面如何排列。

每个维度都存在大量可能性，结果很容易漂移。

当文件中已经存在完整的 Token、变量、组件、Variant 和页面模板时，任务会变成有限范围内的选择：

颜色从语义变量中选择；
间距从规定档位中选择；
按钮从组件库中选择；
状态从 Variant 中选择；
页面从模板和已有模式中组合。

不同资产承担不同约束。

Design Token 限制可使用的设计值。
Variable 提供稳定的语义引用。
Component 限制节点结构。
Variant 限制状态组合。
Template 限制页面布局模式。
Design MD 描述使用规则。
Skill 约束 Agent 的执行流程。
Code Connect 对齐设计组件与代码组件。

从 Agent 的角度看，设计系统的核心价值是缩小搜索空间。

AI 不需要每次重新发明一个按钮或卡片。它可以在团队已经定义好的合法集合中选择和组合。

所以，AI 时代的设计系统还需要承担一个新角色：

成为机器可以查询、理解和执行的设计约束环境。

六、为什么 Codex 需要反复读取和修改

真实 Figma 文件可能包含多个页面、数千个节点、组件库、变量模式和历史结构。

Codex 很难一次读取全部信息。

它通常处于部分可观察环境中，每次只能看到当前任务相关的一部分内容：

局部节点树；
某个页面的截图；
一组组件；
一部分变量；
之前的工具执行结果。

因此，它需要持续执行闭环：

读取当前状态

→ 选择操作

→ 修改 Figma

→ 重新读取

→ 判断误差

→ 继续调整

这也解释了为什么复杂任务很少一次完成。

早期节点定位错误、上下文缺失或布局判断错误，都可能向后传播。

成熟的 Agent 需要持续维护：

当前已经确认的事实；
仍然存在的约束；
已经完成的操作；
尚未验证的结果；
失败后的替代方案。

Codex 的能力来自持续观察和修正。

七、验证系统才是自动设计的关键

工具返回“执行成功”，只能证明操作已经完成。

它无法证明设计已经做对。

设计 Agent 至少需要四层验证。

结构验证

结构验证检查：

节点层级；
组件实例；
变量绑定；
Auto Layout；
父子关系；
是否出现重复节点。

几何验证

几何验证检查：

尺寸；
间距；
对齐；
换行；
溢出；
Hug 和 Fill；
响应式关系。

视觉验证

视觉验证通过截图检查：

视觉层级；
色彩关系；
内容遮挡；
页面密度；
素材比例；
与目标设计的差异。

语义验证

语义验证检查：

组件选型是否符合业务；
状态颜色是否正确；
信息层级是否合理；
页面是否完整回答需求。

只有加入这些验证，Agent 才能形成真正的执行闭环：

执行

→ 检查结构与视觉

→ 定位差异

→ 重新规划

→ 继续修改

一项任务越容易定义“什么叫做对”，越容易被 Agent 稳定接管。

八、进入真实生产环境还需要可靠性

一次成功生成页面，只能证明系统拥有能力。

要让 Agent 长期参与真实设计生产，还需要解决几个问题。

幂等性

相同任务重复执行时，不能持续创建重复页面、组件和变量。

系统需要先判断对象是否已经存在，再决定创建或更新。

事务与恢复

复杂操作执行到一半失败后，需要继续完成、补偿修改或恢复到安全状态。

否则，文件会停留在半完成状态。

状态同步

Agent 在执行前，需要确认节点是否仍然存在，文件是否已经被设计师修改。

并发冲突

当设计师、自动化任务和多个 Agent 同时操作文件时，需要判断如何合并或阻止冲突。

修改追踪

团队需要知道 Agent 修改了什么、依据了哪些规则、哪些节点发生变化，以及怎样撤销。

结语

Codex 可以在 Figma 里接管一部分设计工作，依赖的是一套完整的技术链路：

Figma 提供结构化设计状态

→ MCP 暴露读取和修改能力

→ Codex 将自然语言编译成操作程序

→ 设计系统限制可选范围

→ 反馈与验证推动结果持续收敛

这件事的意义远大于“AI 可以帮设计师画页面”。

它意味着设计正在拥有和代码相似的自动化条件：

设计可以被读取；
设计可以被变换；
设计可以被约束；
设计可以被验证；
设计可以被持续优化。

设计师的工作也会逐渐从直接操作画布，转向定义：

目标是什么；
哪些规则必须遵守；
Agent 可以使用哪些资产；
什么结果才算完成；
出现错误后怎样恢复。
Codex 已经开始接管设计执行层。

设计师接下来需要建设的，是一套能让人和 Agent 共同工作的设计环境。