把 Figma 理解为可执行的设计规格
Figma Design 是一个组织视觉对象、布局规则和交互意图的设计环境。它既能画静态界面，也能表达组件复用和有限的原型行为。对后端开发者来说，可以先把文件看成一棵带约束的对象树。
工程类比能帮助到哪里
| Figma 概念 | 可借助的工程类比 | 类比的边界 |
|---|---|---|
| 图层树 | 结构化对象树 | 渲染顺序和视觉包含关系还需检查 |
| 主组件 Main component | 共享定义 | 不执行你的业务代码 |
| 实例 Instance | 引用定义并带局部参数 | 覆盖规则和普通对象继承不同 |
| 变体 Variant | 有限枚举配置 | 不自动执行游戏状态转移 |
| 设计变量 Variable | 有类型的配置值 | 与 JavaScript 内存变量不是同一个运行域 |
| 原型 Prototype | 可点击的行为说明 | 不等于任意输入下正确的小游戏实现 |
类比用来建立入口；后续仍要学习每个对象真实支持的行为。比如组件实例有文本、颜色等覆盖，但常规实例不能随意重排内部结构；Slot 是专门允许内容插入的一类能力。
从业务需求到视觉需求
业务需求：“玩家完成配对后获得奖励。”这句话还不足以让 AI 设计，因为缺少可观察行为。
把它展开：最后一对卡牌匹配后，停止接受新翻牌；先显示卡牌成功反馈，再进入结算；结算展示用时、步数和奖励；奖励发放失败时显示处理中或重试状态，避免视觉上重复领取。
设计树可以这样描述：
GameScreen
├─ SafeTop
├─ Header：返回 / 关卡 / 暂停
├─ Status：用时 / 已配对数量
├─ Board
│ └─ Card instances
├─ Help：提示 / 玩法说明
└─ SafeBottom
这棵树定义职责和关系。具体 x/y 只是某个尺寸下的结果。若你只给 AI 坐标，它很难知道缩窄屏幕后应当重新排布还是缩小卡牌。
结构、外观、行为分开表达
同一张卡牌至少有三个维度：结构是图案和标签放在哪里；外观是边框、填充和文字；行为是点击后翻开以及何时禁止点击。让 AI 分别说明这三个维度，可以更早发现遗漏。
Figma 内的变量和组件可以让设计保持一致，但它们并不会自动连接你的金币接口。开发交付需要另行说明状态来源、异步过程和失败策略。
给 AI 的练习
先不要画图。请把“星际翻牌配对”的游戏界面拆成对象树。
每层写明职责、数据来源、尺寸来源和会变化的状态。
指出哪些适合组件化，哪些属于运行时业务逻辑。
我确认结构后，再逐个建立 Frame 与组件。
检查 AI 是否把整个屏幕作为背景图片、是否遗漏暂停或失败状态、是否承诺 Figma 原型自动实现随机洗牌。能够指出这些问题，才算读懂了设计模型。
依据：Figma Frame、组件属性。核查：2026-10-31。