先说结论

从 Figma 到 Godot，一边是 Figma 上的 Exporter 插件，一边是 Godot 里的 Importer。Godot 一侧还有单独的 MCP 插件。两边都有工具，把画板切成图、写进引擎，仍然多半只做一次。

设计稿调整了之后，原来写进引擎的界面往往就过时了。节日运营如果要批量换一套新界面，引擎里的节点树大概率对不上原来的图层结构。用 AI 再生成一版新主题，也会碰到同一件事。

旧导入为什么是单向的

我最近在思考一个问题。到 2026 年 9 月，Cursor 这类 AI 编码工具已经逐渐普及。社区里从 Figma 进 Godot，常见的仍是 Figma 的 Exporter，再加上 Godot 的 Importer。做法通常是从 Figma 导出切图，再在 Godot 里搭成 Control 节点。做完这一步，画面第一次出现在引擎里。

Figma 里改一颗按钮，Godot 里的界面不会自动更新。需要先导出，再让驱动生成的 AI 检查这次最新的变动，才能同步进 AI 的上下文。同理，Godot 里的逻辑一旦变了，也无法有效地同步回 Figma，再用这份新上下文去驱动生成。

Godot 里出现了新的改动——少一张图、要换一屏、节点已经接好但画面要重做——需要回到 Figma 一侧再驱动 AI 生成。生成结果还要能映射回原来的节点和目录。再导一次，常常是多一份贴图，或者把已经接好的节点盖掉。设计稿和工程还是无法做到实时同步。

有了 Figma 的 Exporter 和 Godot 的 Importer，重新搭建被缩短成走一遍。图层的名字、位置、哪一块能点，会按这一次导出写进引擎。写进去的是一份 Snapshot。后面如果还要用 AI 重新生成界面，这份 Snapshot 并没有实时同步到 AI 的上下文中。

AI First 之后，缺的是同步和再次生成

r/godot 上现在还能看到不少人对 AI 生成美术的反馈。有人把用生成资源写成「原罪」，讨论仍停在该不该用：I committed the cardinal sin of using AI generated assets。已经按 AI First 来做的人，更早开始调度生成、导出和引擎里的接线，用这些步骤在这个背景下把开发效率拉上去。

开发效率要上去，界面就不能每次都在引擎里重新搭建一遍。通过 MCP，编程工具可以接到打开的 Godot 上，当前场景、节点和脚本可以读，也可以改。这一段已经可以用 Godot MCP 完成。

给按钮接事件时，靠的是节点还叫原来的名字，切图还在原来的目录。后来如果又生成了新的界面，名字和目录都变了，打开的工程里就是一棵对不上的新树，旧脚本接不回去。

这里缺两件事。一件是资源同步：文件要按引擎目录写进去，原图层的上下文信息都要保留和同步。另一件是可以重新生成：设计稿调整之后，还能从同一份分层文件再导出一轮，不必在引擎里手改贴图名字。只走一遍的 Exporter 或 Importer，覆盖不到这两件。单独用 Godot 的 MCP 插件，也覆盖不到。同步的是当前打开的编辑器，不会按引擎结构批量保存美术资源，也不会在生成新图之后把图层关系带回来。

AI First 背景下，real-time 的美术资源同步和代码逻辑同步需要并行

当前已经走通的做法是用 VberAI Studio 处理 Figma to Godot 这一段。把 .fig 导入 VberAI Studio，再按 Godot 工程目录导出场景和切图。图层名字、位置、哪一块能点，跟着文件一起写进引擎目录。设计稿要改，回到 VberAI Studio 再导出一轮，工程里的节点还能对上原来的图层结构。

代码这一边，通过 Godot MCP，把当前打开的场景和脚本交给编程工具。美术资源同步和代码逻辑同步要一起做：在 VberAI Studio 里保留还可以重新生成的分层源，并按引擎目录写出文件；再用编程工具对着还对得上的节点去接事件。只做其中一边，界面改第二次就会对不上。

完整步骤见 Figma 到 Godot。

小结

AI 编码工具已经成为主流。是时候重新调整工作流，让资源的生成和到引擎的映射做到更高程度的同步。