上下文正在成为 AI 辅助开发的瓶颈。不是模型能力。模型改进足够快，它们通常不是制约因素。限制 AI 生成代码质量的是那些模型接收到的上下文质量。

对于 Figma 转代码工作流，上下文有两种根本不同的形式：像素上下文（截图、渲染图像）和结构化上下文（类型化 IR、令牌、语义关系）。这不只是相同信息的不同格式。它们是不同类别的输入，有着不同的属性、不同的损耗特征，以及 Agent 从中生成内容的不同上限。

业界仍然主要使用像素上下文。这是一个错误。figmascope 从一开始就导出结构化上下文——正确的输入。

什么是像素上下文

像素上下文是设计的任何栅格化表示：从 Figma 导出的截图、"导出框架"的 PNG、设计工具的渲染。它是你在 Figma 画布上按 Cmd+Shift+4 时得到的东西。

具有视觉能力的 LLM 可以令人印象深刻地处理像素上下文。它们识别 UI 模式，识别布局区域，从视觉外观推断组件类型，并仅从图像生成合理的代码。如果你使用过 Claude 或 GPT-4V 进行截图转代码，你已经见过这种情况。输出看起来正确的频率超出你的预期。

但"看起来正确"和"是正确的"不是一回事，两者之间的差距是设计系统合规性、令牌保真度、组件标识和可复现性所在之处。

什么是结构化上下文

结构化上下文是一种类型化的、机器可读的表示，保留了设计的语义：每个元素是什么，而不只是它看起来像什么。它包括：

figmascope IR 就是这样。每屏 JSON 中的每个节点都有 kind、name、absoluteBoundingBox、children、解析为令牌引用（如可用）的填充、适用时的自动布局属性，以及实例上的 componentId。这是明确化的设计树。

像素上下文告诉 Agent 设计看起来像什么。结构化上下文告诉它设计意味着什么。编码 Agent 需要意义来编写代码，而不是外观。外观是视觉测试的用途。

像素到结构化方向丢失了什么

像素上下文的核心失败模式是不可逆的信息损失。当 Figma 将框架渲染为 PNG 时，它丢弃了对代码生成最重要的信息：

图层树折叠了。不再有"三个项目间距 8px 的组"。有一个暗示组的像素区域。Agent 必须从视觉证据重建树结构，而重建是近似的。它会在某个百分比的时间内出错。随着设计变得更复杂，这个百分比会增长。

令牌绑定消失了。映射到 color/action/primary 的橙色背景变成了 #FF6B00。Agent 生成一个硬编码的十六进制值。如果你的颜色改变，或者你支持深色模式，或者你需要审计令牌使用，那个硬编码值就是负债。

组件标识消失了。同一卡片组件的四个实例是四个看起来相似的矩形。Agent 可能根据推断的结构相似程度生成一个可复用组件，或四个相似但不完全相同的块。你想要可预测的输出；你得到的是概率性输出。

布局意图是模糊的。这是 flex 行还是网格？项目之间的间距是 gap 还是 margin 还是每个项目上的 padding？像素不说。Agent 选择。选择在不同运行之间不同。

Figma → React 流水线，有和没有结构

考虑从 Figma 到生产 React 的路径。

有像素上下文：导出 PNG。粘贴到 Claude。得到 JSX。审查 JSX 的正确性。注意到硬编码值。注意到错误的组件结构。提示更正。迭代。最终得到看起来合理的东西。手动编辑以匹配设计系统。发布。下一个屏幕：从头重复，因为前一次运行的输出不可组合。

有结构化上下文：导出包（一键，在浏览器中运行）。将 CONTEXT.md + 屏幕 IR 传递给 Claude，系统提示指定框架和设计系统约定。得到使用你的令牌名称、你的组件名称、正确布局结构的 JSX。审查正确性。发布。下一个屏幕：相同的包，相同的 Agent，可组合的输出，因为输入是一致的。

节省的工作是真实的，但是次要的。主要收益是可组合性。结构化上下文使跨屏幕和 Agent 可组合的输出成为可能。像素上下文不行——每个屏幕的输出都是从新鲜推断通过生成的孤岛。

结构意味着：类型化

IR 中的每个节点都有 kind。这立即很重要。TEXT 节点生成文本元素。带自动布局的 FRAME 生成容器。Button/Primary/Large 的 INSTANCE 生成带正确 props 的按钮组件调用。VECTOR 生成图标引用。

Agent 不猜测。它将类型映射到代码原语。映射在 CONTEXT.md 中为目标框架指定。"对于 INSTANCE 节点，使用组件名称确定 React 组件。对于 layoutMode HORIZONTAL 的 FRAME，使用 flex row。对于带样式 typography/heading.lg 的 TEXT，使用 Heading 组件。"这些是编译器风格的规则，不是推断任务。

结构意味着：空间感知

每个节点上的 absoluteBoundingBox 给出在 Figma 坐标空间中的位置和大小。结合自动布局属性——layoutMode、itemSpacing、paddingLeft/Right/Top/Bottom、primaryAxisAlignItems、counterAxisAlignItems——Agent 拥有生成正确布局代码所需的一切，无需数像素。

绝对边界框还让 Agent 验证其输出：如果生成的组件尺寸与 IR 指定的不同，说明出了问题。这是结构化上下文的可测试属性，在像素上下文中没有等效物。

结构意味着：标识感知

当 IR 中的四个节点共享一个 componentId 时，Agent 知道它们是同一组件的实例。它生成一次组件定义，从实例中的变体推导 props，并四次渲染调用。这是正确的输出。从像素上下文无法实现这一点，需要大量提示工程，本质上是要求 Agent 重新推导设计文件已经拥有的结构。

字符串交叉引用的工作方式相同。当多个文本节点引用 stringRef.key: "action.continue" 时，Agent 知道使用单个 i18n 查找，而不是三个硬编码字符串。标识信息在 IR 中；Agent 只需读取它。

结构意味着：可版本控制

纯 JSON 文件可以干净地进行差异比较。更改的 padding 值在每屏 IR 中显示为单行更改。重命名的令牌在令牌文件中显示为查找替换差异。新的组件实例在子数组中显示为添加的对象。

这是工程师真正有用的设计版本历史。不是"设计在周二更新了"，而是"以下是这个屏幕的 v2 和 v3 导出之间变化的三个属性"。你可以把它放在 PR 描述中。你可以对其运行自动检查。你可以用它来审计代码更改是否与设计更改匹配。

这通向哪里：设计上下文基础设施

这里形成的工具类别不是"更好的 Figma 导出"。它是堆栈中的新层：设计上下文基础设施。这一层的工作是将设计源（Figma 文件、组件库、令牌系统）转换为结构化的、Agent 可读的、版本控制的工件，供代码生成层使用。

这一层位于设计工具和编码 Agent 之间。它有目前双方都不拥有的责任：快照管理、语义提取、令牌解析、组件库存、跨屏幕字符串索引、包版本控制。这些是基础设施关注点，不是设计工具关注点，也不是 LLM 关注点。

将其视为基础设施意味着：它是自动化的，它是版本化的，它在 CI 中运行，它有定义的格式，它是可检查的。就像构建系统是代码的基础设施一样——不是代码本身，不是目标二进制文件，而是可靠、可复现地将一个转换为另一个的管道。

诚实：像素仍然重要

figmascope 包包含每个导出屏幕的 2x PNG。不是因为 PNG 驱动代码生成，而是因为视觉确认很重要。Agent 应该能够将其生成的输出与 PNG 进行交叉参考。开发人员应该能够在不打开 Figma 的情况下查看屏幕。PNG 是健全性检查，不是规范。

这种区别——像素用于确认，结构用于规范——是正确的思维模型。你不消除像素上下文；你将其降级到正确的角色。它是 QA 工件，不是构建输入。

就像你不会给编译器一张源代码的截图一样：你给它源代码，并将截图用于文档。设计文件是源代码。包是编译工件。PNG 是文档图像。

这对多目标代码生成意味着什么

结构化上下文使像素上下文无法实现的工作流成为可能：一个设计，多个目标。同一个 IR 可以供给 React/Tailwind 生成器、Jetpack Compose 生成器和 SwiftUI 生成器。底层设计是相同的；特定目标的上下文（框架原语、命名约定、布局 API）存在于 CONTEXT.md 中，每个目标生成一个。

这是真正可扩展的多目标代码生成。你从设计中导出一个包。你运行三个带有三个不同 CONTEXT.md 文件的 Agent。你得到三个在结构上等价的实现，因为它们是从同一个 IR 生成的，而不是从三个截图上的三个独立推断通过生成的。

这个工作流的瓶颈不是模型能力。是上下文质量。结构化上下文是使其成为可能的东西。

从 figmascope 主应用导出你的结构化上下文包，然后与 Cursor、Claude Code 或 Aider 一起使用进行多目标、可组合的 UI 生成。