拆分任务与小批量修改
把任务拆小的目的，是让每一步都有明确输入和可验证结果。它同时减少上下文漂移、重复创建和出错后的恢复成本。
按依赖组织任务
需求与状态表
→ 容器结构
→ 布局规则与设计值
→ 主组件及属性
→ 屏幕实例
→ 原型连接
→ 截图与结构检查
→ 导出及交付
父节点创建后才能把子项放进去；主组件存在后才能创建实例；原型目标存在后才能连接。这些步骤要顺序执行。互不依赖的读取或资料核对可以并行。
batch 能帮什么
Figwright 的 batch 用于一组可逆写操作，按顺序应用并尝试在失败时恢复。删除、解除实例和某些结构操作不适合该回滚模型，工具可能拒绝。
不要把它当成数据库事务的无条件等价物。官方实现会报告回滚失败或残留；遇到错误仍应读回现场。本次批量文字操作超时后，读回发现文字已经出现，因此没有直接重复创建。
一轮的合适边界
可以是一组已存在节点的命名调整、一个状态栏布局，或者一组互不依赖的基础 Frame。不要把全站所有界面、变量、字体、交互和导出塞进一个难以检查的批次。
没有统一的“最多 N 个操作”适合所有任务；根据字体加载、节点规模、连接状态和恢复难度控制范围。
请把本轮拆为有依赖的操作列表。
先列出复用节点、将创建的对象、将修改的属性及验收方式。
每完成一个可检查单元，读回结果并记录 nodeId。
超时或失败后先核查是否部分生效，不直接重发整批。
保留恢复线索
修改前记录受影响节点的关键属性和截图；修改后记录实际结果。对批量改名或样式变更，至少保留 nodeId 与旧值。恢复时优先修改已知节点，避免凭截图重建导致 ID 和原型引用变化。
练习与检查
把“做完整游戏界面”拆成六个左右的可验收单元。每个单元写出依赖和完成证据。如果某一步只能说“看起来差不多”，继续细化验收。