读取设计上下文

AI 应当从真实节点树读取设计，再提出修改。截图用于判断视觉结果；布局关系、字体、间距、组件来源和变量绑定应由结构信息确认。

从浅到深读取

先确认文件与页，再找目标 Section 或 Frame。使用 get_design_context 读取有限深度的结构；根据需要补读 Header、Board 等子区域。大节点可能返回拆分计划，按区域继续读取，避免一次塞入整页。

get_node 适合少量需要完整保真信息的对象；get_document 会返回当前页递归树，不应成为每次修改一个按钮的默认入口。

请先定位 Game Frame，读取浅层结构。
继续读取 Header 和 Board，报告布局模式、宽高来源、padding、gap、组件引用和变量绑定。
若结果被截断或去重，说明遗漏范围，再定向补读。
不能从截图猜颜色、字号或边距数值。

一个真实节点的读取示例

下面是本文件当前游戏 Frame 的调用参数。复制或重建文件后，应先搜索得到新的 ID。

{"nodeId":"3:27","depth":2}

将它用于 get_design_context。返回的 Game 内层为 Vertical，左右 padding 24、gap 20；Header 为 Horizontal、Space between；Board 为 Vertical、gap 12。需要检查每张牌时继续读取 Board 或具体实例，不从浅层结果推断未返回的细节。

三种信息用途不同

信息	用途	局限
节点结构	身份、布局、属性和引用	不能独立证明最终渲染可读
截图	层级、裁切、图案和整体观感	不能可靠证明实例关系或隐藏交互
Reactions / Motion	原型动作和时间线	两类动画需要分别检查

get_design_context 的去重有助于节省上下文，但某些实例或动画细节不会完整展开。需要实现 Motion 时另读 get_motion_context；原型过渡另读 reactions。

为后续实现保留依据

如果后续要写代码，让 AI 记录：来源 nodeId、设计基准尺寸、布局规则、组件和 Token 映射、资源文件以及未确认项。它们应与代码改动关联，方便设计变化后只更新受影响部分。

不要把读取到的一棵树机械翻译为满屏绝对定位。屏幕中的纵向 Frame 与横向行容器表达的是关系；引擎中可以用布局组件或计算实现相同关系，而不必复制 Figma 每一个包装层。

练习与检查

提供一张截图与一个真实 Frame，让 AI 分别列出“截图能证明的事”和“必须读节点才能证明的事”。要求指出一个看起来一样、但结构不同的例子，例如位图按钮和可编辑组件实例。

依据：Figwright 设计上下文与实现工作流。核查：2026-10-31。