vibegame

Godot AI 美术流程：盯住批量化处理，以及生成和代码之间的同步

2026-09-10T16:45:00+08:00

先说结论

目前常见的 Godot ai 美术流程 是这样的：提示词出图，去掉背景，切成精灵图，把 PNG 放进 Godot 的 res://，再设 Nearest，挂到 AnimatedSprite2D 或 Control 上。但实事求是地讲，这套逻辑已经过时了——如果你当前已经在高频调用 Cursor、Claude Code、Codex 这类工具的话。如何在整套工作流中针对批量化处理美术素材，以及处理好批量化生成与代码逻辑之间的同步问题，才是目前的开发流程应该关注的地方。

常见流程还停在五步

常见写法会这样排：先写提示词，用图像模型画出角色、场景或界面。再去背景、修边、统一尺寸。然后按格子切成精灵图，再起名字。接着把文件拖进 Godot 工程。最后在编辑器里设过滤方式，把图挂到节点上，用脚本播放动画或响应点击。

是的，这已经是上世纪的做法了，叔叔。Godot 官方教程里，AnimatedSprite2D 和 SpriteFrames 也确实还是这样吃一张格子图。社区里从 Figma 进 Godot，常见的也是 Exporter 加 Importer，走一遍就算完成。

已经在高频调用编码工具时，缺的是批量处理，以及图层上下文能不能跟着走。节日要换一套界面时，原来挂好的节点往往对不上。用 AI 再生成一版主题时，也是同样的问题。一张 PNG 拖进 res://，编程工具读到的是文件名，读不到这块是不是按钮。

生成之后还要盯住这三步

AI 生成的平面图还需要大量的自动化处理，才能和节点树匹配。 图像模型给出的是一张合成图。HUD、按钮、血条叠在同一张位图上。进 Godot 之后，整屏当一张 Sprite，或靠人一格一格切，都还没完。如果还在依赖手工为每张切好的图片重命名，或者直接拿着自动化脚本切图生成的 Part 26，那真的是在给后续的 AI 编程增加过多的无效上下文。

一次一张，撑不起后面的改动。 提示词可以再跑一遍，得到的是另一张新图。图层关系、尺寸、哪一块能点，不会自动带到下一张上。万圣节要换皮时，常见流程里的「再导出一次 PNG」会把接线重做一遍。情人节要再出一套时，也是同样的缺口。

大量无组织、无结构的切图文件，和程序工程之间的实时映射，是需要重视的一环。 通过 MCP，打开的 Godot 可以接到 Cursor 上，当前场景和脚本可以读。前提是切图已经按引擎目录写进去，节点还叫原来的名字。Figma to Godot 的导入是单向的已经写过：只走一遍的 Exporter 或 Importer，覆盖不到重新生成。Godot AI 美术流程里，同一段缺口出现在出图之后。

我已经走通且在实践的方式：把省下的时间转到玩法策划上

把生成之后的处理放到 VberAI Studio 里做完，再导入到 Godot 中。切图、命名、按目录导出不再占掉整天，省下的时间可以转到真正的玩法策划上。

界面如果还是一张平面 PNG，在画板上选中这一屏，打开重叠图层菜单，跑 Auto-Layering（自动分层）。按检测边缘切图，导出有意义命名的图片文件。步骤见自动分层：图片转多图层。需要 Photoshop 文件时，同一套图层可以 PNG 到 PSD，再 PSD 到 Godot。

已经是格子精灵图、块与块之间空隙清楚时，用 Auto Split。本机切成单张。名字会带序号，进引擎前仍要改成能读的名字。说明见自动切图。

节日要换一套视觉时，不要另外导出一套对不上原来名字的图。选中已分层的画板，跑 AI Reskin（换皮肤）。图层关系和尺寸仍一一对应，再导出一轮即可。说明见 AI 换皮肤。

源文件如果在 Figma，用 Import Project（导入项目） 读入 .fig，再 Export to Godot。导出得到 .tscn，默认路径按 Godot 的 Assets 目录来写。步骤见 Figma 到 Godot。设计稿要改，回到 VberAI Studio 再导出一轮，工程里的节点还能对上原来的图层结构。

代码这一边，通过 Godot MCP，把当前打开的场景和脚本交给编程工具。美术资源同步和代码逻辑同步要一起做。只把 PNG 丢进 res://，会停在「图已经在工程里」；节点名字和图层上下文不在，后续的 AI 编程仍对不上事件。

去背景这一步，游戏界面不要用照片抠图工具硬切 HUD。VberAI Studio 里的 AI 去背景对准的是保留按钮和条，去掉场景底。

小结

别再信任 AI 告诉你的标准流程，尤其是在 AI 已经铺开的现在。提前考虑如何调度和同步多个 AI 生成源头之后的数据，这将会直接拉开差距。

Figma 到 Godot 的导入工具是单向的：MCP 和可重新生成的美术同步需要另一套流程

2026-09-10T16:00:00+08:00

先说结论

从 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 编码工具已经成为主流。是时候重新调整工作流，让资源的生成和到引擎的映射做到更高程度的同步。

Cocos Creator 2.x MCP

2026-09-09T15:14:00+08:00

先说结论：3个步骤

Cocos Creator 2.x MCP 用在已经打开的 Cocos Creator 2.4.x 工程上，让 AI 编程工具看见并操作编辑器。3.8.6+ 工程改走 Cocos Creator 3.x MCP。从 Cocos Creator 2.x MCP 下载。通道本身怎么工作，见 MCP 怎样把 AI 编程工具接到游戏引擎上。

步骤 1：打开 CocosCreator2.x MCP Server

从官网安装后，打开 CocosCreator2.x MCP Server。窗口若要求登录，先登录。Cocos Creator 2.x 保持打开，工程就是当前这份。

步骤 2：确认 Running，用一键配置

在 Server（服务） 页，Status（状态） 应显示 Running（运行中）。这个窗口里默认端口是 4000。MCP URL 是 http://127.0.0.1:4000/mcp。主流编程工具用 One-Click Configuration（一键配置）。

另外两页是 Tool Management（工具管理） 和 Quick Config（快捷配置）。传输方式是 Streamable HTTP（MCP 2025-03-26）。

步骤 3：把 AI 编程工具接上

走完 One-Click Configuration（一键配置）。写代码时要通过 MCP 让编程工具跟工程对话，Cocos Creator 和 MCP 服务都要开着。

版本、工具列表和授权：vberai.com/game-engines/cocos2x。

Cocos Creator 3.x MCP

2026-09-09T15:14:00+08:00

先说结论：3个步骤

Cocos Creator 3.x MCP 用在已经打开的 Cocos Creator 3.8.6+ 工程上：让 AI 编程工具看见并操作场景、节点、预制体，而不只是在文本里补全代码。从 Cocos Creator MCP 下载。2.4.x 工程改走 Cocos Creator 2.x MCP。通道本身怎么工作，见 MCP 怎样把 AI 编程工具接到游戏引擎上。

步骤 1：打开 Cocos Creator MCP Server

从官网安装后，打开 Cocos Creator MCP Server。窗口若要求登录，先登录。Cocos Creator 3.x 保持打开，工程就是当前这份。

步骤 2：确认 Running，用一键配置

在 Server（服务） 页，Status（状态） 应显示 Running（运行中）。这个窗口里默认端口是 3000。MCP URL 是 http://127.0.0.1:3000/mcp。主流编程工具用 One-Click Configuration（一键配置）。

另外两页是 Tool Management（工具管理） 和 Quick Config（快捷配置）。传输方式是 Streamable HTTP（MCP 2025-03-26）。

步骤 3：把 AI 编程工具接上

走完 One-Click Configuration（一键配置）。写代码时要通过 MCP 让编程工具跟工程对话，Cocos Creator 和 MCP 服务都要开着。

版本、工具列表和授权：vberai.com/game-engines/cocos。

Godot MCP

2026-09-09T15:14:00+08:00

先说结论：3个步骤

Godot MCP 用在已经打开的 Godot 4 工程上：让 AI 编程工具看见并操作场景、节点、脚本，而不只是在文本里补全代码。从 Godot MCP 下载。通道本身怎么工作，见 MCP 怎样把 AI 编程工具接到游戏引擎上。

步骤 1：打开 Godot MCP Server

从官网安装后，打开 Godot MCP Server。窗口若要求登录，先登录。Godot 4 保持打开，工程就是当前这份。

步骤 2：确认 Running，用一键配置

在 Server（服务） 页，Status（状态） 应显示 Running（运行中）。这个窗口里默认端口是 2000。Endpoint（接口） 是 http://127.0.0.1:2000/mcp。主流编程工具用 One-Click Configuration（一键配置）。

这一页上有 Start（启动） / Stop（停止）。另外两页是 Tools（工具） 和 Setup（设置）。传输方式是 Streamable HTTP（MCP 2025-03-26）。

步骤 3：把 AI 编程工具接上

走完 One-Click Configuration（一键配置）。写代码时要通过 MCP 让编程工具跟工程对话，Godot 和 MCP 服务都要开着。

版本、工具列表和安装包：vberai.com/game-engines/godot。

Unity MCP

2026-09-09T15:14:00+08:00

先说结论：3个步骤

Unity MCP 用在已经打开的 Unity 工程上：让 AI 编程工具看见并操作场景、游戏对象、预制体，而不只是在文本里补全代码。从 Unity MCP 下载。通道本身怎么工作，见 MCP 怎样把 AI 编程工具接到游戏引擎上。

步骤 1：打开 Unity MCP Server

从官网安装后，打开 Unity MCP Server。窗口若要求登录，先登录。Unity 编辑器保持打开，工程就是当前这份。

步骤 2：确认 Running，用一键配置

Server Status（服务状态） 应显示 Running（运行中）。这个窗口里默认端口是 6594。Endpoint URL（接口地址） 是 http://127.0.0.1:6594/mcp。主流编程工具用 One-Click Configuration（一键配置）。

传输方式是 Streamable HTTP（MCP 2025-03-26）。状态旁边是 Stop Server（停止服务器）。

步骤 3：把 AI 编程工具接上

走完 One-Click Configuration（一键配置）。写代码时要通过 MCP 让编程工具跟工程对话，Unity 和 MCP 服务都要开着。

版本、工具列表和授权：vberai.com/game-engines/unity。

MCP 怎样把 AI 编程工具接到游戏引擎上

2026-09-09T15:14:00+08:00

先说结论：3个步骤

游戏开发的场景中，如果不熟悉切图和相关的逻辑，很容易就会烦躁。AI 编程工具能写代码，但默认看不见引擎里那棵节点树，也不知道一张带名字的切图该挂在哪个按钮上。

MCP（Model Context Protocol）相当于在 AI 编程工具和游戏引擎之间，专门架起一条通信方式。切图如果已经按引擎目录导出、名字也对得上，就不必再口头告诉编程工具「这张图放到什么位置」。它通过 MCP 读取当前打开的工程。

步骤 1：真正烦的是切图放哪，不是图本身

磁盘上的一张 PNG 还不是游戏 UI。编程工具仍要弄清哪个节点是攻击按钮、哪个目录是 Assets/Textures、哪份预制体已经搭好布局。靠对话一张张贴截图来解释，会很慢。

自动分层：图片转多图层导出有意义命名的图片文件，再加上按引擎目录导出（例如 Figma 到 Unity），已经能回答前半段。MCP 回答后半段：当前打开的编辑器，而不是桌面上的压缩包。

步骤 2：MCP 在本地跑一个服务

每个引擎的 MCP 都是编辑器旁边的一个小窗口。Server Status（服务状态） 应显示 Running（运行中）。编程工具连的是本机地址，例如 Unity MCP 上的 http://127.0.0.1:6594/mcp。

目前 VberAI Studio 里的 MCP 工具都支持 One-Click Configuration（一键配置）。装好之后，主流编程工具都可以一键配上。一键配置之后，写代码时要通过 MCP 让编程工具跟工程对话，引擎和 MCP 服务都要开着。

步骤 3：用一键配置接上编程工具，再打开对应引擎的页面

Cursor、Codex、Claude Desktop 一类主流编程工具，用一键配置接上即可。通道通了之后，当前场景、层级、带名字的资源，都走 MCP，而不必再往对话里贴截图。

同一套逻辑，换一个引擎窗口——例如在 Godot MCP 中，用端口 2000，地址是 http://127.0.0.1:2000/mcp：

已经打开哪个引擎，就进哪一页：

从图片到多图层：如何把角色图拆成图层，加快游戏资源准备

2026-09-09T13:39:00+08:00

先说结论

转换系列刚补完 Figma 到 Unity、PNG 到 PSD，Godot 和 Cocos Creator 那几条也重写过。连着看下来，感受很清楚：image-to-layers 已经简单。把一张 PNG 拆成图层不难；按原来的位置和交互信息，把这些图层复原到游戏引擎中，才是后面要盯住的问题。

现在能用的答案，不只是多一个拆图按钮。垂直方向的工具要把图层的名字、位置、交互这些上下文一直带着走。Docs 里已经写开的是：自动分层：图片转多图层、Figma 到 Unity、AI图片翻译、AI 换皮肤。

拆图层已经不难

把一张 PNG 拆成不同的图层，现在已经简单。当前的 AI 分层基本上都能切开，也能补上边缘和被挡住的部位。

除了 VberAI Studio 里的自动分层：图片转多图层，市面上还有不少工具可以一键拆图。拆开之后如何接着处理，才是大问题：原来的位置还在不在，按钮还是不是按钮，导入到引擎中能不能按原样复原。

导入到引擎，原图层的上下文信息都要保留和同步

Figma 到 Unity 在自动分层之后，按 Assets 目录导出：Prefabs 是组装好的界面，Textures 是切图。图层的名字、位置、叠放顺序、哪一块能点，这些上下文都要跟着走。少了任何一项，Codex 和 Unity MCP 都对不上节点，导入到引擎中的就只是一堆图。

Photoshop 年代那些经验——面板做九宫格、字不要画进图、导出前先排完按钮状态——仍然在说引擎里的真实工作。它们不再是准备游戏资源的起步条件。Figma 到 Unity 那篇 Exp 已经写过：旧准则里至少有一半不再卡住进度。

垂直化的工具价值在于持续的共同上下文共享机制

自动分层：图片转多图层按检测边缘切图，导出有意义命名的图片文件。Figma 到 Unity 或 PSD 到 Unity 把同一套图层导入到 Unity 工程目录中。AI图片翻译换字，AI 换皮肤换外观，图层关系和尺寸仍一一对应。

这几项能连着跑，靠的是同一套图层上下文没有在中途断掉。单独拆图层做得到切图，带不走后面的名字、位置和交互。

小结

上下文共享的前提下，做批量化的游戏 UI 拆图才更有开发环境中的基本可用性。

Figma 到 Unity：AI First 之后，不必把界面手动处理流程作为最大时间成本项来考虑了

2026-09-09T13:12:00+08:00

先说结论

在本站发布了 Figma 到 Unity 的流程之后可以看出来：在 AI 急剧冲击旧有游戏开发流程的大背景下，即便是 2026 年 5 月 Saharukh 那篇 Figma to Unity 里列出的黄金准则，现在至少有一半不再卡住开发进度。从 AI First 的角度看，这只是让一切能自动化的流程都更加自动化，效率跟着上来。

当前站点的所有教程和已经发布的文章，都围着 AI First 的核心逻辑：不先把游戏引擎学透，而是结合已经能用的 AI 能力，回到做游戏本身的乐趣。现在已经走通的工具链组合是：

Codex：负责编码
VberAI Studio：负责美术资源的批量化生成和处理
Unity MCP：负责在编码工具和游戏引擎之间同步
Unity：最后验证、测试，整理成完整的游戏工程

原文还在坚持的细节有一半都已经失效

先详细罗列原文里的经验都有哪些，后面会一一对应。

设计稿在 Figma 里好看，不等于游戏里能用。 原文的说法是：界面要会动、要响应、要能缩放、要有多种状态、要能在不同设备上跑、还要在实时引擎里扛得住性能。所以 Figma 到 Unity 不能当成「导出一张图就结束」。

Figma 是图纸，Unity 是工地。 进到 Unity 之后才会冒出这些具体问题：按钮能不能点、指针悬停时怎样、禁用时怎样、换一种语言字会不会挤爆、弹窗在手机和电脑上是否都合适、动画顺不顺、界面会不会把帧率拖垮。

一个按钮不是一张矩形加一行字。 原文列过一整串：普通、悬停、按下、禁用、选中、手柄焦点、音效、点击动画、本地化、自适应缩放、可能的光效，以及接到玩法代码上的事件。所以「把按钮从 Figma 导出去」听起来轻，做到工程里并不轻。

导出切图只是其中一小段。 还要事先决定：哪些做成图片、哪些直接在 Unity 里搭、哪些做成可复用的预制体、哪些要做九宫格拉伸、哪些要动画、哪些要着色器、哪些要本地化、哪些要同时应付键盘、鼠标、触摸和手柄。

不要把整屏都导出成一张图。 原文点名的坏例子包括：整屏、带文字的按钮、固定尺寸的面板、用多张静图拼进度条、把文案烤进 PNG。文案一旦进图，翻译就很难改；整块面板不好缩放；静图进度条没法平滑填充；每屏一张大图又重又难改。更好的拆法是：文字留在 Unity 里当真正的文字，按钮做成可复用组件，面板多用九宫格，进度条用填充图或着色器，图标导出成精灵图，重复件做成预制体。

命名在项目变大之前看起来无聊。 Rectangle 124、Group 56、Icon copy 9、Frame 32 进工程之后，开发或技术美术只能猜。原文给的好名字是 btn_primary_bg、icon_currency_gold、panel_shop_base、hud_health_fill、popup_reward_frame、img_avatar_border_rare。

按组件想，不要只按整屏想。 商店这一屏拆开：顶栏、货币条、商品卡、购买按钮、滚动区、分类页签、确认弹窗。Figma 里是可复用组件，Unity 里是可复用预制体，例如 Shop Item Card 对上 PF_ShopItemCard，里面再放图标、名称、价格、稀有框、购买按钮、锁定 / 选中 / 悬停。

Figma 的排版不等于 Unity 的排版。 同一套界面可能要面对手机、平板、电脑、超宽屏、刘海和安全区、不同语言、不同输入方式。实现时要考虑锚点、缩放、安全区、布局组和可伸缩间距。界面不能像一张贴纸，只贴在一个分辨率上。

动画不要留到最后。 弹窗淡入、按钮略微缩放、血条闪一下、奖励图标发光、报错时抖一下——这些是在告诉玩家发生了什么。不早做，后面会和布局、节奏、性能、玩法流程打架。

界面也会吃性能。 半透明叠层、大贴图、模糊、遮罩、粒子、会动的图标、没整理过的画布、过多零散精灵图、频繁重建布局。高端电脑上不明显，手机上会变成真问题。

原文给的十条制作流程： 整理 Figma 文件 → 标出可复用组件 → 决定导出什么 → 按尺寸和透明区域准备资源 → 导入 Unity 并设贴图、压缩、图集 → 做预制体 → 补状态 → 加动画和反馈 → 在多种屏幕上试 → 尽早看绘制次数、显存、过度绘制和画布重建。

原文要避开的失误： 整屏导出成图、文案烤进精灵图、不管按钮状态、只按一个分辨率设计、图层乱起名、忘记本地化、不管手柄或触摸、独特资源太多、不做图集、动画太晚、不管安全区、性能留到最后才看。

界面技术美术 被写成设计和工程之间的人：准备资源、搭预制体、做着色器、做动画、优化性能、做可复用组件、适配分辨率，一边让设计师看见引擎限制，一边让开发保住画面。职责被概括成：保护设计，让它在制作过程里还能活下来。

以上这些，在「先有人、再有工具」的年代里，每一条都花时间。

对照：AI First 之后，哪些还成立，哪些不再是中心

首页写得很直：用接近 Figma 的交互组织美术资源，再用引擎 MCP 做密集协同，把原来靠人力的环节拆开。对照原文，可以先看成一张表。

原文还在强调的工作	AI First 之后还成不成立
设计稿好看不等于游戏里能用	仍成立。能点、能缩放、能换语言，最后都要在 Unity 里验证。
导出切图不是全部	仍成立，但中心变了。缺的不再是人亲手决定每一块怎么切，而是文件能不能按引擎目录导出，让 Codex 读得懂。
不要整屏导出、不要把文案烤进图	仍成立。本地化那篇已经写过：字烤进图，后面只能整张重做。
`Rectangle 124` 这类名字进工程会乱	仍成立。自动分层就是在按检测边缘切图，导出有意义命名的图片文件；名字乱，后面的预制体和脚本也对不齐。
按钮要有悬停、按下、禁用、手柄焦点、音效、事件	一半成立。这些状态和事件仍然要在 Unity 里出现；但不必须先由界面技术美术在导入前用手搭完。Codex 加 Unity MCP 可以在预制体落地之后补。
九宫格、着色器、图集、画布重建	一半成立。手机项目里这些仍会爆。AI First 的顺序是：先让界面进工程能跑，再让 Codex 对着打开的编辑器去查、去改，而不是先把这些当成入门门槛。
按组件做成预制体	仍成立，而且已经被导出这一步接住了一部分。Figma 到 Unity 里，选 Prefab（`.prefab`）再解压，`Assets/Prefabs` 是组装好的界面，`Assets/Textures` 是切图。
动画和性能必须编进「导出之前的流程」	不再是中心。原文把动画和性能写成制作流程的第 8、第 10 步，好像不排进计划就不能导出。现在更常见的是：先导出能用的预制体，再在 Unity 里用 Codex 和 Unity MCP 补运动和开销。
必须有一位界面技术美术守在中间	对没有游戏开发背景的人，这条最先失去作用。首页的前提就是不必先精通引擎。守门人改成：VberAI Studio 负责把稿整理成引擎目录，Unity MCP 把当前场景和脚本交给 Codex。

所以「不必把界面手动处理流程作为最大时间成本项来考虑了」。界面仍然要做对：不要再把原文那十条靠人一点点处理的流程，当成 Figma 到 Unity 的入场券。

现在这套组合实际改了哪一段

VberAI Studio 对准的是原文里最耗人的前半段：整理图层、起能用的名字、决定切哪些图、按 Unity 的 Assets 目录导出。.fig 用 Import Project（导入项目） 进来，再跑自动分层，最后 Export to Unity。这一步覆盖的是「文件如何结构化地导出到 Unity 工程文件夹中」，覆盖不到悬停态、本地化字号、粒子好不好看——这些原文后半段，本来就不该假设设计工具一次做完。

Unity 仍是验证发生的地方。预制体拖进场景之后，原文问过的那些问题还在：能不能点、换语言会不会挤、刘海会不会挡、会不会掉帧。

Unity MCP 对准的是 MCP 能做、设计工具做不了的那一段：把当前场景、层级和脚本同步给 AI 工具。Figma 加 Cursor 之后，设计稿怎么进 Godot 已经写过类似分工：MCP 负责开发和场景上下文；设计工具继续改稿，需要时按引擎目录导出。Unity 这边同一套逻辑。

Codex 对准的是原文留给「界面技术美术 / 程序」的接线：给按钮挂事件、补几种状态、把文字留成可翻译的文本、按不同分辨率试一次。首页的身份是设计师兼会写基础代码的产品经理，不是引擎专家；这些接线如果还要求先手写完一套界面框架，AI First 就走不下去。

四件套串起来，原来的开发模式变成：

用 AI 生成工具先做出游戏 UI 截图，再到 Figma 里简单处理边缘情况和需要修补的地方。
在 VberAI Studio 里导入、自动分层、导出 Unity 的 Assets（预制体 + 切图）。
在打开的 Unity 工程里，用 Unity MCP 让 Codex 看见当前界面层级。
用 Codex 补交互、状态和基本适配；稿要改，回到 VberAI Studio 再导出一轮，而不是在引擎里手改贴图名字。

原文里的界面技术美术，保护的是「设计在制作过程里别被做丢」。现在保护设计的方式变了：图层和名字在导出时就对齐，后面的判断交给人看结果，具体操作交给 Codex 在引擎里改。

或许把任何文字信息都画进图层里——这种现在看起来蠢笨的做法，以后也不一定还是问题，只要 AI 自动生成和自动标注的成本、便利性，已经压过以往整套手改的总成本。

小结

AI 能力在快速吞噬着原有游戏开发里那些还没自动化的流程。
VberAI Studio 几乎是沿着游戏开发这条垂直方向，用 AI First 又迭代了一层。这类工具迟早会更大规模地加快游戏开发。
没有被这套组合自动吃掉的空间，会在未来变得急剧缩小。

Figma 到 Unity

2026-09-09T11:20:00+08:00

先说结论：6个步骤

Figma 到 Unity 的主要逻辑是：针对已经分层的 .fig 文件 UI / HUD，要批量化处理好美术素材后，导入到 Unity 中。VberAI Studio 用 Import Project（导入项目） 导入这份文件，再跑自动分层：检测边缘切图，导出有意义命名的图片文件，然后选 Export to Unity。

已经是分层的 Photoshop 文件：PSD 到 Unity。

步骤 1：存一份本地 `.fig`

在 Figma 中打开菜单：File（文件）→ Save Local Copy（保存本地备份）。已经命名的编组（画框、按钮、HUD 条）会带到 VberAI Studio。

步骤 2：在 VberAI Studio 里 Import Project

在 VberAI Studio 的项目页，选 Import Project（导入项目），选择刚刚导出的 Figma 的 .fig 文件。

步骤 3：自动分层

选中画板（例如 cat_journey_UI）。在选中后的工具栏里打开重叠图层，选 Auto-Layering（自动分层）。

对话框是 Run AI auto-layering?，再点 Start layering。

带名字的边界会出现在图上，这意味着分层切分的图片都处理好了。关于这一步骤的详细说明可以参考自动分层。

步骤 4：导出到 Unity

保持已分层的画板选中（这里是 cat_journey_UI_layer）。打开 Export，选 Export to Unity。

步骤 5：选择导出到 Unity 的形式

导出到 Unity 时，可以选导出形式。对话框里 Target engine 是 Unity；格式可以选 Prefab（.prefab）。Export to 可以选 ZIP 压缩包，或直接写到目标工程。Default paths 会按引擎默认目录来放文件。

步骤 6：检查导出结果

这次选的是 ZIP 压缩包。解压后是 Assets 总文件夹：Prefabs 里是 Unity 可用的 .prefab（组装好的界面，可以拖进场景）；Textures 里是具体的切图文件（按图层起好名的 PNG）。

PSD 到 Unity

2026-09-09T11:20:00+08:00

先说结论：6个步骤

PSD 到 Unity 的主要逻辑是：针对已经分层的 Photoshop 文件（PSD 或 PSB），要批量化处理好美术素材后，导入到 Unity 中。VberAI Studio 导入这份设计稿，再跑自动分层：检测边缘切图，导出有意义命名的图片文件，然后选 Export to Unity。

已经是 .fig 文件：Figma 到 Unity。还是一张扁平 PNG、需要先分层：PNG 到 PSD。

步骤 1：打开分层 PSD

编组要有名字（画框、按钮、HUD 条）。这些名字会带到 VberAI Studio。

步骤 2：在 VberAI Studio 里导入 PSD/PSB

在 VberAI Studio 选 Import → PSD/PSB（导入 PSD/PSB）。

步骤 3：自动分层

选中画板（例如 cat_journey_UI）。在选中后的工具栏里打开重叠图层，选 Auto-Layering（自动分层）。

对话框是 Run AI auto-layering?，再点 Start layering。

带名字的边界会出现在图上，这意味着分层切分的图片都处理好了。关于这一步骤的详细说明可以参考自动分层。

步骤 4：导出到 Unity

保持已分层的画板选中（这里是 cat_journey_UI_layer）。打开 Export，选 Export to Unity。

步骤 5：选择导出到 Unity 的形式

步骤 6：检查导出结果

PSD 到 Godot

2026-09-08T18:40:00+08:00

先说结论：3个步骤

PSD 到 Godot 的主要逻辑是：针对已经分层的 Photoshop 文件（PSD 或 PSB），要批量化处理好美术素材后，导入到 Godot 中作为场景使用。VberAI Studio 导入这份设计稿，再导出到 Godot。导出得到 .tscn；默认路径按 Godot 的 Assets 目录来写。

已经是 .fig 文件：Figma 到 Godot。还是一张扁平 PNG、需要先分层：PNG 到 PSD。

步骤 1：打开分层 PSD

编组要有名字（画框、按钮、HUD 条）。这些名字会带到 VberAI Studio，并进到 Godot 的节点树里。

步骤 2：在 VberAI Studio 里导入 PSD/PSB

在 VberAI Studio 选 Import → PSD/PSB（导入 PSD/PSB）。

步骤 3：导出到 Godot

选中这一屏（例如 Main Screen）。打开 Export，选 Export to Godot。

对话框里把格式设成 Scene（.tscn）。Default paths 会去项目里找 Assets 文件夹，并按这套目录写文件。

演示视频

PSD/PSB 导入，再导出到 Godot：

PNG 到 PSD

2026-09-08T18:36:00+08:00

先说结论：3个步骤

PNG 到 PSD 的主要逻辑是：针对只有一张扁平 PNG 的游戏 UI（HUD、整屏截图、从来没有分层的画板），要先批量化处理好美术素材，再回到 Photoshop 里改。先跑自动分层：检测边缘切图，导出有意义命名的图片文件，再选 Export to Photoshop PSD。导出的 .psd 里，这些块是分开的图形层和文字层。同一套步骤也适合很多张都从单张 PNG 起步的 UI。

步骤 1：自动分层

在 VberAI Studio 打开这张 PNG，选中画板（例如 cat_journey_UI）。在选中后的工具栏里打开重叠图层，选 Auto-Layering（自动分层）。

对话框是 Run AI auto-layering?，再点 Start layering。

带名字的边界会出现在图上，这意味着分层切分的图片都处理好了。关于这一步骤的详细说明可以参考自动分层。

步骤 2：导出为 Photoshop PSD

保持已分层的画板选中（这里是 cat_journey_UI_layer，1536×864）。打开 Image Export，选 Export to Photoshop PSD。

步骤 3：打开 PSD

文件会写成 {name}_layer.psd，这份稿是 cat_journey_UI_layer.psd。Photoshop 里能看到已命名的图形层和文字层（技能格、货币图标、HUD 文案），可以挪位置、隐藏或改样式，不用再截一次屏。

要把这份文件导入到 Godot 中：PSD 到 Godot。

精灵图网格切图

2026-09-08T17:31:00+08:00

打开一张精灵图。能数清行列就用简单网格；已经知道格子宽高、偏移和间距就用手动网格；透明像素把各块隔开时用自动检测。

调整叠加线直到格子对齐。跳过空格子可以丢掉全透明的格。在预览里排除不需要的帧，再导出单张、按行拼条或按列拼条。放大用邻近取样，像素画不会发糊。文件只留在本机，不会上传。

AI 去背景

2026-08-28T18:30:00+08:00

先说结论：3个步骤

AI Background Removal 用在完整的游戏 UI / 场景板上：要清掉环境衬底，同时尽量留下 HUD、按钮、文字条和其它界面层。界面元素的保留是这条路径的重点——按游戏界面帧定制；Pixian.ai、Remove.bg 一类偏照片的去背，HUD 块经常被削边或整块拿掉。

打开去背景菜单，选 AI Background Removal，跑一遍，再核对场景环境是否已去掉、UI 是否还能进引擎或继续做精灵。光晕、半透明边要精细抠、又不走重绘时，见 AI 超精细抠图。

步骤 1：从一张游戏 UI 场景板开始

用环境美术和 HUD、控件叠在同一帧上的位图——状态栏、任务卡、技能栏、虚拟摇杆都还在。

步骤 2：选 AI Background Removal

选中图片后，打开去背景菜单，选 AI Background Removal。

步骤 3：检查界面元素是否还在

结果去掉绘制的环境，角色、路牌、宝箱和周围 HUD 留着。导出前过一眼面板和图标边缘。

环境已去掉；HUD 和可交互 UI 还在板上。

常见问题

2026-08-26T16:00:00+08:00

VberAI Studio 要付费才能用吗？

不订阅也能用，只是积分消耗偏高。某几个功能如果会经常用，后面多半会自己去充积分——几乎每次走 AI 生成都会扣相应积分。

VberAI Studio 中如何导入 Figma 的 .fig 文件？

在 VberAI Studio 的项目页，点 Import Project（导入项目），选对应的 .fig 文件即可导入。

零基础能开始做小游戏吗？

这个实验还在进行。可以从本站文章里找某条流程里最短的走法，先看入门。

自动分层：图片转多图层

2026-08-26T14:39:00+08:00

先说结论：3个步骤

本页的图片转多图层（Image to Layers）就是 Auto Layering（自动分层）：把一张合成图拆成可单独编辑的图层。不用画框：检测边缘切图，导出有意义命名的图片文件。和 Layer Split 在同一工具栏；目标一样，按框定尺寸的走那一页。

为什么切完之后，名字、位置和交互还要跟着进引擎：从图片到多图层：如何把角色图拆成图层，加快游戏资源准备。

步骤 1：打开 Auto-Layering

选中画板（例如 cat_journey_UI）。打开重叠图层菜单，选 Auto-Layering（自动分层）。

步骤 2：确认开始分层

对话框是 Run AI auto-layering?，再点 Start layering。弹窗里若仍写 Manual Layering，对应现在的 Layer Split。

步骤 3：检查带名字的图层

带名字的边界会出现在图上，这意味着分层切分的图片都处理好了。结果铺在原图右侧。复杂的 HUD 和场景件会自动框出来。

演示视频

同样要拆层，但手动画框：Layer Split。图层已经切好之后，用 PNG 到 PSD 写成 Photoshop 文件。同一批图层也可以导入到 Unity 中：Figma 到 Unity，或 PSD 到 Unity。

一键游戏主题换皮：市面上已经有了针对美术资源的批量节日换皮肤工具

2026-08-20T15:00:00+08:00

VberAI Studio 的换皮肤很容易用上瘾。功能说明见换皮肤。

对独立开发和游戏设计师来说，游戏美术已经齐了之后，再办一次节日活动并不轻松。对美术设计几乎是一场灾难。

核心工作是在旧美术上批量加上新的节日效果：万圣节要一套节日主题图标；情人节会涌出大量表达爱意的视觉元素。项目阶段改变不了这一点。有持续运营时，美术和开发总会在那些日子之前进排期，节日内容先做好上线准备，日期到了再放出来。

更核心的是批量、并且提示词要一致。

换皮肤就是为这个来的。生成按结构化文档提交：结构化的美术资源设置留着，只替换视觉呈现。

小结

游戏 UI 的批量换皮肤需要批量 API 请求和返回。原来的环境参数设置非常重要。

同一点也出现在 r/aigamedev 这条讨论里：用 AI 给资源换皮肤。工作室一旦部署换皮肤，收获是便捷的节日换皮：短时间、按指定方向生成大量资源。后面可能还有成本公式——怎样调度，才能把生成成本压到尽量低。眼下更稳的路，仍是让懂调度的人去排专业的活。调度更专，要生成的量会下来，这才是生产端这一轮升级。

AI 换皮肤

2026-08-20T14:30:00+08:00

先说结论：4个步骤

AI 换皮肤 用在 VberAI Studio 里已经做完的 UI / HUD 画板上：要换一套气氛，又不想手改布局。选中画板，打开 AI 换皮肤，写目标主题，这一轮会按提示词重绘各层外观。图层关系和图片尺寸仍一一对应。字的颜色常常还停在源图上，后面需要再统一一遍标签颜色。

步骤 1：在选中的画板上打开 AI 换皮肤

在 VberAI Studio 画布上选中要换风格的那一屏（例如 Main Screen）。画板上方浮出的选中工具栏里，选最右侧带 AI 标记的 AI 换皮肤。

步骤 2：输入主题提示词

AI 换皮肤 对话框按描述重绘视觉风格。确认前能看到积分（这一轮大约 68–130 积分）。

提示词示例：

Halloween-themed page atmosphere

步骤 3：检查结果

等跑完，再看画板。环境、面板边框和道具会跟着主题走；画面上的字往往还是源图颜色，标签后面可能要再统一一遍颜色。

步骤 4：图层关系和尺寸

图层关系和图片尺寸仍一一对应。

演示视频

在选中的画板上做 AI 换皮肤，从提示词到一一对应的分层结果：

Figma 到 Cocos Creator，完美支持设计稿转Prefab

2026-08-20T13:40:00+08:00

先说结论：3个步骤

Figma 到 Cocos Creator 的主要逻辑是：针对已经分层的 .fig 文件 UI / HUD，要批量化处理好美术素材后，按设计稿转 Prefab，导入到 Cocos Creator 3.x 中使用。VberAI Studio 用 Import Project（导入项目） 导入这份文件，再导出到 Cocos Creator 3.x。导出结果在 Assets 总文件夹里：Prefabs 是组装好的界面，Textures 是按图层起好名的切图。界面逻辑用 Cursor 或 Codex 补。在 Cocos Creator 里 Build，预览会开到本地网页。

步骤 1：存一份本地 `.fig`

在 Figma 中打开菜单：File（文件）→ Save Local Copy（保存本地备份）。

步骤 2：在 VberAI Studio 里 Import Project

在 VberAI Studio 的项目页，选 Import Project（导入项目），选择刚刚导出的 Figma 的 .fig 文件。

步骤 3：导出并预览

选中这一屏（例如 Main Screen）。打开 Export，选 Export to cocosCreator3.x。

界面逻辑用 Cursor 或 Codex 接上。在 Cocos Creator 里 Build 工程，预览会开到本地网页。

导出结果按 Assets 目录来放：Prefabs 里是 Cocos Creator 可用的 Prefab（组装好的界面，可以拖进场景）；Textures 里是具体的切图文件（按图层起好名的 PNG）。

2026年9月最新操作流程指引

从 Figma 经 VberAI Studio 进到 Cocos Creator 的完整一遍：

Figma 加 Cursor 之后，设计稿怎么进 Godot

2026-08-19T14:17:00+08:00

先说结论

Figma 负责美术设计，Cursor 负责写代码。中间还缺一步：图层还在、名字对得上、文件保存到 Godot 工程目录里，好让 AI IDE 直接读取。

Figma 没有针对游戏引擎的结构化导出。VberAI Studio 可以当作中间环节。

缺的是什么

只导出一张 PNG，图层和命名都没了。真正需要的是：图层还在、名字能对上、文件已经保存在引擎正在使用的目录里。

MCP 能把当前场景和脚本同步给 AI 工具，但不会按引擎结构批量保存美术资源。这一步还是需要在设计工具的流程中实现。

2025 年 5 月，Latenode 上有人问过同一件事：Exporting Figma designs to Godot: Current status?。当时常见做法是导出切图，再在 Godot 里重新搭建界面。2026 年 5 月 Figma 出了画布内 Agent（Fast Company），调整图层更方便了，但是仍然没解决掉文件如何结构化地导出到 Godot 工程文件夹中。两套可以一起用：MCP 负责开发和场景上下文；设计工具继续修改稿件，需要时按引擎目录导出。

.fig 这条路写在 Figma 到 Godot。PSD/PSB 导入是另一篇：PSD 到 Godot。VberAI Studio 导入 PSD 时，矢量图层还不完整。同一份稿用 Import Project 导入 .fig，更顺畅，矢量也能比较完整地带进导出。流程见这段视频：

Import Project：把 .fig 导入 Studio，再导出到 Godot

Studio 项目页上的 Import Project 入口不明显，容易错过。

小结

要源文件对齐、一次保存进开发目录，VberAI Studio 可用。配上对应的 MCP（例如 Godot MCP），可以少一轮手工整理文件。
就算 Figma 以后自己做引擎导出，游戏制作仍更常要批量生成和替换；只导出 PNG 覆盖不到。

Figma 到 Godot

2026-08-18T17:20:00+08:00

先说结论：3个步骤

Figma 到 Godot 的主要逻辑是：针对已经分层的 .fig 文件 UI / HUD，要批量化处理好美术素材后，导入到 Godot 中作为场景使用。VberAI Studio 用 Import Project（导入项目） 导入这份文件，再导出到 Godot。导出得到 .tscn；默认路径按 Godot 的 Assets 目录来写。

已经是分层的 Photoshop 文件：PSD 到 Godot。

步骤 1：存一份本地 `.fig`

在 Figma 中打开菜单：File（文件）→ Save Local Copy（保存本地备份）。已经命名的编组（画框、按钮、HUD 条）会带到 VberAI Studio，并进到 Godot 的节点树里。

步骤 2：在 VberAI Studio 里 Import Project

在 VberAI Studio 的项目页，选 Import Project（导入项目），选择刚刚导出的 Figma 的 .fig 文件。

步骤 3：导出到 Godot

选中这一屏（例如 Main Screen）。打开 Export，选 Export to Godot。

对话框里把格式设成 Scene（.tscn）。Default paths 会去项目里找 Assets 文件夹，并按这套目录写文件。

演示视频

Figma Import Project，再导出到 Godot：

提升清晰度

2026-08-11T21:22:00+08:00

先说结论：3个步骤

HD Upscale 用在需要更大像素尺寸、又能接受一点生成改写的位图上。能调的是重绘范围、输出格式和放大倍率；跑完会扣积分，结果作为新图层铺在源图右侧。密集的游戏 UI、烤进画面的字、小图标网格目前仍不稳——把重绘范围拉高，改的是样子，很难把字标拉回清晰。

本篇演示用的源图：商店 / 背包场景，HUD、道具格和环境叠在一张底板上。

步骤 1：在选中的图上打开 HD Upscale

在画布上选中图片。选中后的工具栏里选 HD Upscale（AI 一组）。

步骤 2：设重绘范围、格式和倍率

对话框会显示原尺寸和预计放大后的尺寸。可调：

Redraw range — 允许重绘细节的幅度（低则结构更贴源图；高则改写更多）
Output format — PNG、JPG 或 WEBP
Magnification — 放大倍率（例如 ×2）

确认前能看到积分消耗。放大后的底板会作为新图层出现在原图右侧。

步骤 3：检查放大后的图层

跑完后把新图层和源图对比。这张商店 UI 底板上，低重绘会把画面放大，但小图标和界面文字的边仍然软。

把 Redraw range 拉高（例如 0.6），这一轮会把更多算力花在重绘上。布局和道具可能漂；字标和细的 HUD 记号往往还是糊的，或变成噪点，读不出来。

更在意导出尺寸变大、不太要求 UI 像素级还原时，用 HD Upscale。背包图标、状态文字或像素边必须卡死的底板，重绘留低——或者这条先跳过，只放大那些吃得消生成细节的层。

精灵图自动切图

2026-07-17T18:30:00+08:00

拖入精灵表，或选择本地图片 / ZIP。工具在浏览器里按透明通道或背景色切开每一块，导出 PNG，也可打包下载。文件留在本机。

不透明图可在设置里指定背景色；最小尺寸用来丢掉过小的碎块。按外形抠出会留下透明边缘，按包围盒则裁成矩形。

自动切图

2026-07-17T15:13:00+08:00

先说结论：2个步骤

Auto Split 用在块与块之间已经有明显空隙的精灵表上：要在本地尽快切成单独的位图。不耗积分，在本机跑；切完后每块都可以单独导出，或拖到后面的步骤里继续处理。

命名沿用源精灵表，再加一段序号后缀。切的是几何区域，不是模型打的标签，所以这些名字仍是自动生成、不好读——导出后若要能认，再自己改名。

步骤 1：打开 Split — Auto Split

在画布上选中精灵表。选中后的工具栏里打开 Split，再选 Auto Split。

步骤 2：检查切出来的碎图

Auto Split 会检出分离的区域，切成单张图。每块沿用精灵表的基名，再加序号后缀（例如 … Part 26），可以直接导出，或拖到后面继续处理。

更在意速度和积分、不太在意文件名含义时，用 Auto Split。若要好认的名字或更紧的边界，进引擎前先改名，或改走手动切。

只在浏览器里切、文件不离开本机，可以用本地的 Sprite Auto Split Extractor。

App Store 截图还在一张张本地化？用 VberAI Studio 批量做 Image Translate

2026-07-16T16:45:00+08:00

先说结论

Tired of localizing App Store screenshots one by one 问的是：App Store 截图还要不要一张张本地化，有没有工具一次做完。VberAI Studio 的 Image Translate 可以按批次处理。

独立团队碰到画进截图里的 UI 文字，仍要按语言重新截图，或进 Photoshop / Figma。App Store、Google Play、Steam 上架也是同一套耗时。r/SoloDevelopment 上也有一条商店页讨论：帮游戏公司做商店页本地化的服务商已经在流程里跑 AI。

接下来的测试就是最好的证明。

商店宣传图

Frostpunk 2 Steam 商店页的预览图可以作为这次本地化的测试用例。

用上面这张英文原图，在 VberAI Studio 中选择简体中文生成后的效果。

文案换成了简体中文。人物、金色边框、价格行和右侧内容格子都还在原来的位置。要整张构图完整的商店图，这份文件可以用。

和把图片直接发给主流的 ChatGPT 图片生成、或者 Nano Banana 图片生成不同，这里的图片翻译效果更准：只重新生成文字区域，其余画面基本不动。看得出经过了另一套工具 Harness 处理，很适合做游戏 UI 的本地化。

流程见 Image Translate：选中图片 → Image Translate → 选择语言 → 导出同尺寸文件。

小结

可行。在 VberAI Studio 里，直接调用主流生图模型做 AI 图片翻译，完全没压力。

演示视频

App Store 商店预览图的国际化，批量完成，用 AI 图片翻译。

AI 超精细抠图

2026-07-16T15:10:00+08:00

先说结论：3个步骤

Super AI Matting 用在精灵或 UI 截图上：要干净的透明底，又不跑图像生成。光晕、软边、半透明像素的边缘质量比较稳——做游戏美术时，往往比通用去背服务更合适。这条路径只做抠图：去掉衬底，前景画面保持原样。

工具栏入口是 Remove background — Super AI Matting。选中图片，跑 Super AI Matting，导出透明结果，进引擎或继续做精灵都可以。

步骤 1：从带背景的精灵或场景截图开始

用还带着原来背景的位图——角色、HUD、发光图标和环境叠在同一帧里。

步骤 2：选 Remove background — Super AI Matting

选中图片后，打开 Remove background 菜单，选 Super AI Matting。

步骤 3：检查抠图结果

输出去掉场景衬底，前景美术和 UI 边缘还在。光晕和半透明区域通常比面向照片的自动抠图更干净。

棋盘格衬底：背景已去掉，透明处能看见格子。

这条路径不重绘像素，只抠源图里已有的内容。游戏精灵带光晕、法术拖尾或软边图标时，要直接进引擎、少一圈毛边，这个差别会很明显。

提取背景

2026-07-16T14:40:00+08:00

先说结论：3个步骤

Extract Background 用在完整的场景精灵上：要一张没有角色、HUD、交互提示的环境底板。打开 Extract 菜单，选模型和尺寸，再生成。输出是一张可拿去复用的背景候选，建筑边缘不必指望和原图像素级对齐。

Extract Background 让模型在去掉前景角色和 UI 的前提下把场景补回来，得到一张偏背景的图，后面做美术或关卡都能用。

步骤 1：从一张完整场景精灵开始

用环境、角色、UI 叠在一起的场景。下面这张是村庄镜头，NPC、HUD 和画面上的字都还在。

步骤 2：打开 Extract Background 并设模型

选中图片后，打开 Extract 菜单，选 Extract Background。

在 AI Extract Background 对话框里选模型（例如 GPT Image 2），设输出尺寸和质量，再开始提取。

步骤 3：检查干净背景

结果去掉角色和 UI，留下环境底板——房子、地面、树、天空——可以当背景再用。

抽出来的背景往往对不齐源图像素。这个例子里，建筑外形和部分画风相对原帧会漂。当成品锁版之前，先过一眼（需要的话再轻轻修）。

AI图片翻译

2026-07-16T14:20:00+08:00

先说结论：3个步骤

Image Translate 用在大批已经把字烤进画面的精灵或 UI 位图上。字继续留在图里也行时，这是一条比较快的本地化路径：选目标语言，跑生成，得到同尺寸的图——场景大体还在，标签换成另一种语言。它走的是图像生成，不是单独导出文字层，版式和风格都还在像素里。

Image Translate 用模型生成，改写位图里的字，再输出一张同尺寸资源。第一遍不必逐条手绘标签。

步骤 1：从一张源语言 UI 图开始

用已经带源语言的游戏界面或场景精灵。下面这张是英文界面（地名、NPC 提示、招牌、背包 / 设置等字）。

步骤 2：打开 Image Translate 并设定目标语言

选中图片后，在工具栏打开 Image Translate。

在 AI Image Translate 对话框里选目标语言（例如日语），确认图层，再跑 Translate。

步骤 3：检查同尺寸的译后图

结果和源图尺寸相同。画面上的字换成目标语言（地点名、NPC 提示、商店 / 出口招牌、背包 / 设置一类）。

英文标签换成日文；场景美术还在板上。

没有AI辅助工具的时候，像素精灵图的处理和生产流程是怎么样的？比我想象中的麻烦多了。

2026-07-15T18:00:00+08:00

先说结论

已经有不错的AI工具足够处理像素风角色动画帧和精灵图这件事了。为看清整条调用链怎么串起来，使用之前熟悉的工具链走了一遍：参考图生图、抠底、对齐导出、GIF 预览，再到最终精灵图。下面按步骤记录，并标出阻力点。

测试中用到的工具

工具	作用
Grok Image	生图快，短时间内可出多个方向备选
GPT Image 2	更慢，画质更稳；关键词或参考给对时输出更可靠
Pixian.ai	去背景；高级版对大尺寸抠图完整性更好
Figma	裁切、对齐、命名与整条链路的可视化记录

走查顺序

整条链路里，工具调用大致为：Grok Image ×2、GPT Image 2 ×2、Figma ×2+、Pixian.ai ×2、Ezgif ×1（合计约九次切换）。标题图是从两枚静态图标想法走到可在 Ezgif 预览的 GIF。从想法落到可预览动画，耗时明显偏长，中间还夹着返工与弃用路径。

步骤 1：Grok Image，参考图 + 提示词生成像素风原图

用参考图与提示词生成像素风格原始图：

Two icons share the same style—one for “Documents” and the other for “Experiments”—and both employ a gamified aesthetic. The “Documents” icon depicts a scroll shimmering with magical trails of light, while the “Experiments” icon features a weapon-forging tool, symbolizing a resource honed through the fires of experience.

步骤 2：Figma，裁成独立小图

在 Figma 中把目标图标裁成单独一张小图，便于后续序列帧生成。

步骤 3：GPT Image 2，生成序列帧

用 GPT Image 2 生成序列帧。提示词约束有误（要求首尾帧一致），实际只得到约 5 帧可用结果；黑底为模型输出。

步骤 4：Pixian，移除背景

对序列帧做背景移除。

步骤 5：Figma，逐帧对齐、命名与导出

逐帧调整上下对齐与动作幅度一致性，按顺序命名并导出。这是整条链路里人工成本最高的一段。

步骤 6：ChatGPT 对话内直接试生成

在对话里直接生成测试动画，效果不理想，放弃该路径。

背景为黑色，未做透明处理；游戏场景不可直接使用。

步骤 7：Ezgif，逐帧打包为透明 GIF

用 Ezgif 逐帧合成 GIF，背景透明，便于站点或本地预览动作。

步骤 8：引擎侧目标形态，序列帧精灵图

Godot 等引擎实际更常用一张排好的序列帧精灵图（透明 PNG / WebP）。

阻力点

阻力点 1：步骤 5 的人工对齐成本高、结果不稳定

链路最大短板在步骤 5：需要手动对齐物体、压住动作幅度跳变。AI 序列帧的帧间一致性不可预测，这一步会引入大量不确定与返工。

阻力点 2：强依赖干净抠底与可迭代预览

工作流离不开两个前置条件：

背景移除足够干净，能信
能快速预览 GIF / 动画效果，并据此重生成或微调

缺一则后续对齐与引擎接入都会反复卡住。

对照：主流产品形态

当前更稳的角色精灵序列帧路径，多半会结合骨骼 / 绑定校对：在给定动作约束后再生成，帧间保证通常高于「纯提示词出多帧再手调」。

一键工具（见文末服务）把调度、抠底、对齐与预览收进产品。通用工具链则把每一步的阻力暴露得更清楚。

提取 UI 元素

2026-07-15T17:15:00+08:00

先说结论：3个步骤

Extract UI Elements 用在一张具体的游戏场景截图上：调视觉模型，把 UI 抽出来拼进一张精灵位图。区域数量和边界要卡得很准时不太合适——结果是近似的，跟所选模型有关。

Extract UI Elements 对当前图片直接调模型做 UI 提取。不用写提示词，界面上点完就能跑。

步骤 1：从菜单选中这个功能

提取前先准备好场景或精灵截图。下面这张是本篇演示用的源图。

选中目标图后，打开提取相关菜单，选提取 UI 元素。

仅作点击流程入口参考。截图为截至 2026 年 9 月 3 日的最新产品界面。

步骤 2：设模型和参数

对话框里选模型和输出尺寸。可选 GPT Image 2、Nano Banana / Nano Banana 2、Nano Banana Pro。尺寸越大，抽出来的物件往往更多、花样也更多。

仅作点击流程入口参考。截图为截至 2026 年 9 月 3 日的最新产品界面。

步骤 3：看提取结果

生成后检查拼合结果。当前输出是一张不透明的位图图层；接到后面的步骤前，通常还要清一次。

GPT Image 2，输出尺寸 1K。

更合适的场景：从位图到精灵表

UI 更密的单张位图，比上面步骤 1–3 的演示更适合 Extract UI Elements。模型从一张源图抽出控件和面板，拼到一张精灵图上；丰富度和边界精度都高于步骤 3 那张演示结果。

源图：一张 UI 很密的位图。

输出精灵表，GPT Image 2，输出尺寸 1K。

用AI生成精灵图，再针对处理成可以导入到游戏引擎的美术资源

2026-07-15T10:00:00+08:00

先说结论

把 AI 生成的精灵表做成可进游戏的像素美术，常常卡在两类问题上：场景分类和语义角色（阻力点 1），以及把散图整理成可进引擎的结构化资源（阻力点 2）。这两类，VberAI 做切分、提取和清理会更省事。下文再展开其余阻力点，以及 Cursor 式的 Rules、命名和元数据。

Reddit 上的讨论

Reddit r/aigamedev 有一条相关讨论：

用AI生成精灵图，再针对处理成可以导入到游戏引擎的美术资源

讨论围绕同一条管线：用 AI 生成精灵表，再清理成可进入游戏的像素美术。评论里常见的卡点包括：生成结果难以直接进引擎、动画帧不够稳定、清理后仍要大量手工处理。

在整理 Layer Split 这类提取流程时，这些卡点可以进一步拆成更细的阻力点。

阻力点分析

阻力点 1：精灵需要分类，也带有场景语义

精灵进入游戏后，通常要先被归入不同用途，例如：

场景建筑 / 装饰元素：位置相对固定，交互很少，一般不需要碰撞设定
可交互 / 可碰撞对象：往往附带碰撞、遮挡、层级，有时还涉及状态切换

因此，资源在「看起来像一张精灵」之前，已经隐含分类与行为预期。图像模型更擅长生成画面，较少系统化回答「这张图在场景里承担什么角色」。VberAI 目前也未把分类与场景语义做成系统能力：切分、提取、整理可以完成，「装饰还是碰撞体」这类判断仍主要落在导出后、在 IDE 里的批量处理。

阻力点 2：美术资源应按结构化数据管理，却仍常被当作散图处理

游戏美术最终要进入引擎目录与引用关系。更稳妥的形态接近带结构的资源描述：类型、用途、关系、可检索字段齐全。匿名位图堆很难撑起后续自动化。

AI 生成阶段通常先得到一张或一组图，结构信息后补。VberAI 的 Layer Split / 框选提高了边界控制精度（见 Layer Split），但结构化方式仍偏人工：对每张图重复「选区、分层、确认」，成本随素材量上升。核心问题是处理步骤能否沉淀为可复用结构。单次做完还不够。

阻力点 3：常识性上下文如何传给模型——同一界面图内规则并不统一

同一张界面图里，不同元素需要的生成约束不同：

角色立绘 / 头像：通常只要单张结果，不需要 idle、run、attack 等多帧状态；无约束生成却常多出状态表（见标题图）
多帧动画：需要更强的一致性约束（比例、朝向、节拍、关键帧），重生成与筛选成本更高
界面中只露出局部的元素：直接生图有时可以补全被裁切部分；若只做手动切分后再提取，则会受原图局部信息不足限制

左：VberAI 手动标注提取，框选过紧，建筑右侧被切掉。右：GPT Image 2 精灵表，建筑完整，底部土堆和草坪仍粘在一起。

这里缺少类似 Cursor Rules 的用法：把「只要单帧」「需要跑动循环」「允许补全遮挡区域」写成可复用、可切换的上下文约束，再交给模型执行。常识约束若不能稳定传入，结果容易停在「视觉上可接受」与「引擎内可直接使用」之间。

同一条 Reddit 讨论里：

I tried doing this with nano banana. I was trying to animate a cartoony dinosaur running. It would create the sprite sheet, but I couldn’t get enough good frames to make a convincing run animation.

I ultimately just cut out the limbs and tried animating them as a 2d skeleton in Unity. Just like anything, I think it takes practice and creativity to make these things work.

这条反馈对应同一类限制：模型可以产出精灵表，却未必能稳定产出足够、可用的动画帧；工作流最终退回更可控的拆件 / 2D 骨骼方案。差距不只在模型画质，也在任务上下文与验收标准是否进入工具链。

阻力点 4：自动化命名与元数据——支撑 MCP / IDE 调用

美术资源最终要打包进引擎。若要通过 MCP 与 Cursor 等 IDE 协作，可调用性更多取决于图背后的 元数据。单张位图本身撑不起调度。

有效调度通常依赖两层：

有意义的命名：用命名建立初始上下文（对象是什么、属于哪一类、用于哪一步）
更完整的内置元数据：按资源类型做检索、筛选、批量处理与按规则调用（harness）

在这一点上，VberAI 已有明确进展：处理后的输出会自动带上有意义的命名，后续检索与资源管理更直接。命名与元数据把生成结果推进到更接近「可被 IDE / MCP 引用的结构化资产」。

小结

游戏美术资源本身带结构，因此适合放进 AI 生成式开发流程。真正要处理的是结构化 harness：分类语义、可检索元数据、可配置上下文规则，以及能被引擎与 IDE 接力的命名体系。

VberAI Studio 已经覆盖切分、提取与自动命名中的若干环节。阻力点 1–3 仍更依赖人工判断或缺少系统化配置；后续若这些约束能变成可复用、可被 Agent 调用的结构，管线完整度会明显高于继续加深单次手动操作。

分层切图

2026-07-09T10:00:00+08:00

先说结论：3个步骤

Layer Split 用在已经选中的位图上：切图尺寸要跟着手画的框走。画完框之后会自动分层并用 AI 切；导出文件名还能对上各块内容。同一工具栏里还有 Auto-Layering（自动分层），不画框，检测边缘切图。全自动切图请参考自动分层：图片转多图层。

物体被挡住或贴在一起时，手画一框仍能单独抠出一件东西——比如只要建筑，不要边上的草和土。

步骤 1：从工具栏打开 Layer Split

在画布上选中图片。选中后的工具栏里，打开重叠图层入口（Extract 右侧）。里面是两个平级项：

Layer Split（分层切图）——手动画区域，再自动分层、AI 切图。生成尺寸跟画的框走。
Auto-Layering（自动分层）——不手动画框，检测边缘切图，导出有意义命名的图片文件。

Extract 里原来的 Manual Layering 已经没了。Layer Split 就是那条流程的现用名：先画框，再自动分层和切图。

步骤 2：把画面层和文字层分开

打开 Layer Split 之后，框出目标画面所在的整块区域，再标哪些层是画面、哪些层是文字。框决定生成尺寸。画面 / 文字分开标，后面加工时能插手的地方会多一些。

步骤 3：生成处理结果

框和层类型确认后跑生成。输出会按这些边界和标注来。

复杂场景仍可能碰到额外的处理上限。跑完后，输出图会带上能对上各块画面的名字，后面找起来方便一些。

演示视频

在选中的画板上做 Layer Split，从工具栏到按框切图：

同样要拆层，但不画框：自动分层：图片转多图层。

入门

2026-06-26T10:00:00+08:00

AI优先的思路学习如何制作游戏：先摸清常见制作卡点，再用生成能力把卡住的环节拆开，最后把产出变成引擎能直接导入的资源。

过程里会对照不同工具，说清楚各自能做什么、卡在哪。VberAI Studio 是这条线上的核心，操作上更接近「直接用 AI 做游戏」。

把耗时费力的内容生产交给 AI。

入门

2026-06-26T10:00:00+08:00

这里的经验过程会放置更加细化的经验笔记。文档页通常对准一个具体问题；这里更常写某条路径上的做法，以及路上最直接的体验。

vibegame

Godot AI 美术流程：盯住批量化处理，以及生成和代码之间的同步

先说结论

常见流程还停在五步

生成之后还要盯住这三步

我已经走通且在实践的方式：把省下的时间转到玩法策划上

小结

Figma 到 Godot 的导入工具是单向的：MCP 和可重新生成的美术同步需要另一套流程

先说结论

旧导入为什么是单向的

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

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

小结

Cocos Creator 2.x MCP

先说结论：3个步骤

步骤 1：打开 CocosCreator2.x MCP Server

步骤 2：确认 Running，用一键配置

步骤 3：把 AI 编程工具接上

Cocos Creator 3.x MCP

先说结论：3个步骤

步骤 1：打开 Cocos Creator MCP Server

步骤 2：确认 Running，用一键配置

步骤 3：把 AI 编程工具接上

Godot MCP

先说结论：3个步骤

步骤 1：打开 Godot MCP Server

步骤 2：确认 Running，用一键配置

步骤 3：把 AI 编程工具接上

Unity MCP

先说结论：3个步骤

步骤 1：打开 Unity MCP Server

步骤 2：确认 Running，用一键配置

步骤 3：把 AI 编程工具接上

MCP 怎样把 AI 编程工具接到游戏引擎上

先说结论：3个步骤

步骤 1：真正烦的是切图放哪，不是图本身

步骤 2：MCP 在本地跑一个服务

步骤 3：用一键配置接上编程工具，再打开对应引擎的页面

从图片到多图层：如何把角色图拆成图层，加快游戏资源准备

先说结论

拆图层已经不难

导入到引擎，原图层的上下文信息都要保留和同步

垂直化的工具价值在于持续的共同上下文共享机制

小结

Figma 到 Unity：AI First 之后，不必把界面手动处理流程作为最大时间成本项来考虑了

先说结论

原文还在坚持的细节有一半都已经失效

对照：AI First 之后，哪些还成立，哪些不再是中心

现在这套组合实际改了哪一段

小结

相关教程

Figma 到 Unity

先说结论：6个步骤

步骤 1：存一份本地 .fig

步骤 2：在 VberAI Studio 里 Import Project

步骤 3：自动分层

步骤 4：导出到 Unity

步骤 5：选择导出到 Unity 的形式

步骤 6：检查导出结果

PSD 到 Unity

先说结论：6个步骤

步骤 1：打开分层 PSD

步骤 2：在 VberAI Studio 里导入 PSD/PSB

步骤 3：自动分层

步骤 4：导出到 Unity

步骤 5：选择导出到 Unity 的形式

步骤 6：检查导出结果

PSD 到 Godot

先说结论：3个步骤

步骤 1：打开分层 PSD

步骤 2：在 VberAI Studio 里导入 PSD/PSB

步骤 3：导出到 Godot

演示视频

PNG 到 PSD

先说结论：3个步骤

步骤 1：自动分层

步骤 2：导出为 Photoshop PSD

步骤 3：打开 PSD

精灵图网格切图

AI 去背景

步骤 1：存一份本地 `.fig`

步骤 1：存一份本地 `.fig`

步骤 1：存一份本地 `.fig`