让 Codex 在 Figma 干活的 15 个基础概念

当我们让 Codex 读取 Figma、查找组件、修改布局、创建页面时，表面上看，它像一个会操作 Figma 的设计师。

从底层看，Codex 完成的是一条连续的信息处理链：

• 用户先提出设计要求，要求进入模型的上下文。
• 模型结合 Figma 文件信息、工具说明和历史操作，判断下一步应该做什么。
• 它随后生成一次工具调用，由外部程序真正修改 Figma。
• 修改结果再次返回模型，模型继续判断和执行，直到任务完成。

理解这套过程，需要先掌握下面 15 个概念。

Token：模型处理信息的基础单位

这个概念整体解决什么问题

Token 解决的是：人类输入的文字，怎样转换成模型能够计算的信息。

一段自然语言进入模型前，会先被拆成多个 Token。Token 可能是一个字、一个词的一部分、一个标点，也可能是一段代码符号。

例如，“把指标卡改成两列布局”这句话，在模型内部会被拆成多个单位。具体怎样拆分，取决于模型使用的分词器。

在 Codex 控制 Figma 时有什么作用

进入 Codex 的内容远不止用户的一句话，还可能包括：

• Figma 节点名称；
• Node ID；
• 组件属性；
• 工具说明；
• Skill 内容；
• 工具执行结果；
• 错误信息；
• 代码内容。

这些信息最终都会转换成 Token，放进模型的上下文中。

模型一次能处理多少信息，通常也使用 Token 数量衡量。

需要记住什么

Token 只是信息的编码单位。

模型需要结合上下文，才能理解不同 Token 之间的含义和关系。

上下文：模型当前能够看到的全部信息

这个概念整体解决什么问题

上下文决定模型这一轮判断时，能够参考哪些内容。

它可能包括：

• 用户当前提出的任务；
• 之前的对话；
• 系统规则；
• Skill；
• 可调用工具的说明；
• 已读取的 Figma 节点；
• 页面截图；
• 之前的工具调用结果。

模型不会天然知道当前 Figma 文件中有什么。只有被读取并放进上下文的内容，才能参与模型的判断。

在真实任务中的影响

例如你说：

“使用现有组件创建一个任务列表。”

模型需要知道文件里有哪些组件。如果组件信息已经进入上下文，它可以直接判断应该复用哪个组件。

如果上下文中没有组件信息，它可能先查询组件库，也可能自行创建新的结构。

为什么上下文管理很重要

上下文太少，模型缺少完成任务所需的信息。

上下文太多，大量无关节点、页面和规则可能干扰模型判断。

所以成熟的 Agent 通常不会一次读取整个 Figma 文件，而是先读取概要，再根据任务逐步获取详细信息。

Embedding：把语义转换成可以计算的向量

这个概念整体解决什么问题

Embedding 负责把文字、图片或节点信息转换成一组数字。

这组数字可以表达不同内容之间的语义关系。

例如，“按钮”“主按钮”“操作按钮”在语义上比较接近，它们对应的向量通常也会更接近。

“按钮”和“页面背景”含义差距更大，它们在向量空间中的距离也通常更远。

在 Figma 场景中的作用

当你说“指标卡”，模型可以将它与文件中的这些名称关联起来：

• Metric Card；
• Business Metric；
• 经营指标；
• AUM Card；
• Data Summary Card。

即使用户的表达与组件名称不完全一致，模型依然可能根据语义相似性找到候选对象。

Embedding 的限制

Embedding 擅长判断“含义是否接近”。

它无法单独判断两个对象是否就是同一个节点。

“指标卡”和“数据卡”可能非常相似，最终应该修改哪一个，还要结合节点位置、父子结构和页面截图。

Transformer：同时处理大量信息关系的模型架构

这个概念整体解决什么问题

Transformer 是当前大语言模型的核心架构。

它可以同时处理用户需求、Figma 节点、工具说明、Skill 和历史操作结果，并计算这些信息之间的关系。

为什么它适合 Agent 任务

设计任务中的信息经常相隔很远。

例如用户最开始说“必须复用已有组件”，后面经过多次工具调用，模型依然需要记住这个要求。

又例如用户说“在指标卡下方创建任务列表”，模型需要把“指标卡下方”与后续读取到的节点位置和布局属性联系起来。

Transformer 可以在较长的上下文中建立这些关联。

Attention：模型当前重点关注哪些信息

这个概念整体解决什么问题

Attention 是 Transformer 中用于分配注意力的机制。

模型处理当前内容时，会判断上下文中的哪些信息更重要，并为它们分配不同权重。

在 Figma 任务中的表现

当模型处理“现有组件”时，它可能重点关注：

• 组件搜索结果；
• Instance 信息；
• 组件名称；
• 组件库工具。

当模型处理“两列布局”时，它可能重点关注：

• Auto Layout；
• 容器宽度；
• 子节点数量；
• Wrap 属性；
• Gap 和 Padding。

例如你说：

“把右侧第二张卡片换成风险提醒。”

模型需要同时关注：

• “右侧”对应空间位置；
• “第二张”对应排列顺序；
• “卡片”对应节点类型；
• “风险提醒”对应目标内容。

为什么 Attention 也会出错

Attention 建立的是概率关系。

如果文件中有很多相似节点，图层命名又比较混乱，模型可能关注到错误对象。

自回归生成：模型怎样一步一步决定接下来做什么

这个概念整体解决什么问题

自回归生成指的是：模型根据已经看到的内容，逐步预测接下来的内容。

语言模型生成一句话时，会根据前面的 Token 继续预测下一个 Token。

在 Agent 中，这种机制也用于判断下一步行动。

Codex 每一步在预测什么

它可能判断：

• 接下来应该继续输出文字；
• 应该读取 Figma 文件；
• 应该搜索组件；
• 应该调用修改工具；
• 应该获取截图；
• 当前任务已经可以结束。

模型通常不会在任务开始时生成一条完全固定的执行路线。

它会根据每一步真实返回的信息，动态决定后续操作。

所以 Codex 的行为看起来像“边做边想”。

Tool Calling：模型怎样让外部工具真正执行操作

这个概念整体解决什么问题

Tool Calling 负责把模型的判断转换成外部程序可以执行的指令。

模型可能判断：

“现在需要读取这个节点。”

随后生成一条结构化工具调用，其中包含目标工具和 Node ID。

外部系统接收到调用后，才会真正读取 Figma。

模型和工具分别负责什么

模型负责：

• 判断应该使用哪个工具；
• 生成调用参数；
• 理解工具返回结果；
• 决定下一步行动。

工具负责：

• 读取真实文件；
• 修改真实节点；
• 返回数据；
• 返回错误或执行状态。

需要记住什么

模型生成的是操作指令。

真正改变 Figma 文件的是外部工具和 Figma 接口。

Tool Schema：工具参数为什么必须有明确格式

这个概念整体解决什么问题

Schema 规定工具接受哪些参数，以及参数应该是什么类型。

例如，一个修改布局的工具可能要求提供：

• 目标 Node ID；
• 布局方向；
• 元素间距；
• Padding；
• 宽度模式。

其中 Node ID 是字符串，间距是数字，布局方向只能从规定选项中选择。

为什么自然语言不能直接执行

用户可能会说：

“把这个卡片稍微加宽一点。”

工具无法理解“稍微”到底是多少。

模型需要结合当前宽度和页面情况，将它转换成一个明确数值。

常见错误

工具调用失败，通常会涉及：

• 参数类型不正确；
• 缺少必填字段；
• Node ID 不存在；
• 使用了工具不支持的参数值；
• 调用了错误工具。

Agent Loop：Codex 为什么可以连续完成多个步骤

这个概念整体解决什么问题

Agent Loop 是模型、工具和真实环境之间的循环。

整个过程包括四个动作：

第一步，观察当前环境。

第二步，判断下一步行动。

第三步，调用工具执行操作。

第四步，读取执行结果并继续判断。

一个真实的 Figma 任务

例如你说：

“使用现有组件增加一个任务列表。”

Agent 可能先读取当前页面，找到主内容区域，再搜索任务列表组件。

找到组件后，它将组件插入目标容器，随后获取截图。

如果截图中发现间距不合适，它会继续修改间距，再次检查结果。

为什么需要循环

模型一开始通常没有完整信息。

它需要通过工具主动获取文件状态，再根据真实结果调整后面的计划。

复杂任务的能力主要来自这个循环，而非一次性生成。

多模态视觉编码：模型怎样读取 Figma 截图

这个概念整体解决什么问题

当 Codex 读取一张截图时，图片需要先被视觉编码器转换成模型可以处理的视觉表示。

模型会提取：

• 页面中的区域；
• 颜色；
• 文字；
• 元素位置；
• 空间关系；
• 视觉层级；
• 可能存在的遮挡和溢出。

截图在 Figma 任务中的作用

截图可以帮助模型发现：

• 卡片是否互相遮挡；
• 页面是否失去平衡；
• 某个模块是否过宽；
• 文字是否溢出；
• 当前结果是否接近参考图。

截图和节点数据的区别

截图提供最终的视觉结果。

节点数据提供精确的设计结构和属性。

模型仅看到截图时，可能知道“这个区域看起来太宽”。

同时拿到节点数据后，它才能进一步判断，具体应该修改哪个 Frame 的宽度或布局方式。

Grounding：模型怎样找到你说的“那个模块”

这个概念整体解决什么问题

Grounding 指的是，把自然语言里的概念对应到真实环境中的具体对象。

例如用户说“右侧第二张指标卡”，系统最终需要找到一个唯一的 Node ID。

模型会参考哪些信息

它通常会综合：

• 节点名称；
• 节点类型；
• 父子关系；
• X、Y 坐标；
• 宽度和高度；
• 组件信息；
• 截图中的视觉位置。

为什么容易失败

一个页面中可能存在很多都叫 Card 的节点。

模型需要根据位置、父容器和视觉内容继续判断。

当图层结构混乱、命名重复或者节点嵌套复杂时，它可能选中视觉相似、业务含义不同的对象。

一个重要判断

很多看起来像“AI 没听懂需求”的问题，实际来自 Grounding 失败。

模型可能已经理解了应该怎样修改，只是找错了节点。

上下文条件控制：Skill 为什么能改变 Codex 的行为

这个概念整体解决什么问题

同一个模型，在不同上下文中会表现出不同的行动倾向。

如果没有额外规则，Codex 可能直接创建新的按钮、颜色和卡片。

如果 Skill 中规定：

• 创建前先搜索已有组件；
• 优先使用变量；
• 禁止打散 Instance；
• 完成后必须截图检查；

模型就更可能按照这些步骤调用工具。

Skill 在底层做了什么

Skill 通常不会重新训练模型，也不会修改模型参数。

它将一组规则放入当前上下文，改变模型对下一步行动的概率判断。

所以可以简单理解为：

同一个模型，在不同规则和上下文下，会表现出不同的行为。

采样与不确定性：为什么同样的任务会走不同路线

这个概念整体解决什么问题

模型在生成下一步时，面对的通常不是唯一答案。

例如，收到“使用现有组件增加任务列表”后，模型可能认为以下动作都合理：

• 先读取页面；
• 先搜索组件；
• 先读取变量；
• 直接修改当前选区。

每个选项都有一定概率，系统会从中选择一个。

为什么结果会发生变化

即使用户要求相同，下面这些因素也可能不同：

• 当前上下文内容；
• 工具返回顺序；
• 已经读取到的节点；
• 模型的采样结果；
• 之前某一步选择的操作。

早期一步发生变化，后续路径也会持续分叉。

怎样提高稳定性

清晰的 Skill、设计系统、工具说明和验收规则，可以让正确行动的概率更集中。

反馈闭环：Codex 怎样根据结果继续修正

这个概念整体解决什么问题

反馈闭环指的是，模型执行操作后，会重新读取结果，再决定是否继续修改。

例如，Codex 创建了任务列表，随后通过截图发现列表太宽。

它继续读取节点属性，发现宽度使用了固定值。

下一步便可能将宽度改成 Fill Container，再次截图检查。

反馈主要来自两类信息

第一类是结构反馈，包括：

• Node ID；
• 节点属性；
• Auto Layout；
• 组件引用；
• 变量绑定。

第二类是视觉反馈，包括：

• 页面截图；
• 元素遮挡；
• 对齐关系；
• 页面密度；
• 与目标图的差异。

为什么反馈很关键

没有反馈时，模型只能假设工具操作已经达到目标。

有了反馈，它才可以根据真实结果继续修正。

幂等性：为什么同一个操作不能重复产生新结果

这个概念整体解决什么问题

幂等性指的是：同一个操作执行一次和执行多次，最终结果保持一致。

例如用户说：

“创建一个今日任务模块。”

如果系统没有幂等性，任务运行两次后，页面中可能出现两个相同模块。

有幂等性时，系统会先检查模块是否存在。

模块不存在时才创建。

模块已经存在时，则更新现有模块或跳过创建。

它属于哪一层技术

幂等性主要属于软件工程和 Agent 可靠性。

它不属于大语言模型内部原理。

它解决的是：模型可能重复调用工具时，怎样避免真实文件被重复修改。

为什么 Agent 特别需要幂等性

Agent 可能因为以下原因再次执行同一个动作：

• 工具请求超时；
• 返回结果不明确；
• 自动重试；
• 上下文中没有保存成功状态；
• 模型误判之前的操作没有完成。

当 AI 开始修改真实文件时，这类可靠性概念会变得非常重要。

最后，用一句话理解整套机制

Codex 会把用户需求、工具说明、Figma 节点、Skill 和历史结果一起放进上下文。

Transformer 根据这些信息持续预测下一步行动。

当模型生成工具调用后，外部工具真正修改 Figma，再将节点和截图结果返回模型。

模型根据新结果继续判断和修正，最终形成一套连续的观察、行动与反馈循环。