先说结论

在本站发布了 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 就走不下去。

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

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

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

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

小结

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

相关教程