收到 Spine JSON 却没有 .spine 工程？先确认交付目标

封面复用 AI 生成的角色与部件概念，不是实际导出文件、编辑器界面或工程恢复结果。

同事说“把 Spine 文件给我”，你交付 JSON、Atlas 和 PNG，对方却要继续修改原工程。此时先确认交付目标，而不是把 JSON 改名为 .spine，或仅因没有工程扩展名就认定下载失败。

Tooliva 工作台教程展示的多皮肤包包含共享 JSON、Atlas 与皮肤 PNG。这个演示说明了该流程的资源交付，不等于承诺每次下载都附带原始编辑工程。应以当前实际导出内容为准。

先把后续工作写成一个动作

• 在目标游戏里加载并播放：需要确认同批数据、图片引用与目标集成要求。
• 修改图片外观或工作台部件：需要保留可定位的工作台资源和本次导出基线。
• 在 Spine 编辑器继续编辑：需要明确实际可用的工程或数据导入路径，以及要保留的编辑信息。

这三种需求不能只用“要一个Spine文件”代替。先写下负责编辑或集成的人、使用的工具与计划修改对象，再讨论缺了什么文件。

列清单，不用扩展名猜能力

独立解压本次包，记录实际文件名、用途、图片引用与批次。JSON是数据文件的常见后缀，不代表任意JSON都属于同一结构；PNG包含图像，也不代表它本身就是可编辑的动画工程。

不要为满足某个导入对话框的文件筛选而直接改扩展名。改名没有证明内容已经转换。若交付方和接收方使用的词不同，先让双方对照这份清单，避免在错误文件上反复尝试。

数据可导入，不等于完整原工程

Spine 官方导入文档说明编辑器支持导入其JSON或二进制数据；同时说明未导出 Nonessential 数据时，回导可能缺少部分信息。因此不能将“能够导入”直接写成“原工程已完整恢复”。

若团队选择这条路径，先在副本上验证实际导入结果。针对本次要修改的内容列验收项，例如相关骨架、计划动作、附件及图片引用是否可定位。只有真正检查过的内容才能记为通过，不把一次成功打开替代后续编辑验证。

将工程需求与运行交付分开验收

假设程序同事只需播放某套外观，而动画同事需要继续修改一段动作。前者的成功加载记录并不能证明后者已经拿到所需编辑材料。可以分别记录“运行资源交付已检查”和“编辑材料待确认”，不用强行给整个任务写一个含糊的成功状态。

回到 Spine 工作台时，保留资源的实际定位信息；不要把网页预览能播放解释为已经导出了某种未核实的工程格式。

保留两条可追溯记录

• 交付记录：原始包、实际文件、导出批次及目标用途。
• 编辑记录：接收工具、导入或打开的真实路径、检查结果与仍缺的信息。

原始文件与工作副本分开保存，避免为了尝试恢复而覆盖唯一基线。若本次是多皮肤运行交付，可继续用 多皮肤导出清单核对名称和文件引用。本篇不承诺任意数据可无损还原，也不替代项目实际的授权与兼容要求。