美术切图，程序重拼：游戏 UI 同步的苦，能靠 AI 解决吗？（全套方案源码）

程序员最讨厌的两三事

程序员最讨厌的两件事：

1. 写文档。
2. 别人不写文档。

游戏前端程序员最讨厌的三件事：

1. 看别人写的文档。
2. 刚拼完 UI，美术说你拼得不对，策划又要加个按钮。
3. 接 SDK 时发现 API 版本过时，还没有提供源码。

做了这么多年游戏，曾老师深知游戏研发团队内部同步的痛点。

很多痛点，最后都会落到沟通效率上。每个岗位在自己的工作上付出了努力，就容易觉得自己的工作最重要。

碰到情商高的人，或者有鼓励师的团队，或者有严格规范并严格执行的团队，效率可能会高一点。但规范、灵活和效率，犹如不可能三角，很难兼得。

而且情商这东西，在某些人身上，四舍五入约等于不存在……

就像曾老师在上一篇免费的才是最贵的：游戏研发团队选择/自研AI工具的3个原则末尾提到的：

人类的沟通方式，还是太落后了。

提升开发效率，先提升沟通效率

要提升沟通效率，无非就是三个办法：

1. 让每个人类只关心自己的一亩三分地，用规范减少沟通。
2. 把人类从沟通流程中摘出来，让 AI 和 AI 互相沟通。
3. 让一个人类自己解决所有问题。

方法 2，我们以后再说。方法 3，并不适合大多数人。

今天说说方法 1：让美术在 Figma 里维护 UI 的视觉，让程序在 Cocos Creator 里维护逻辑，用工具把两者连接起来。

P.S. 如果不喜欢看技术描述， 或者时间有限：直接拖到文章最后看 曾老师的最终建议 那一节，那是本文精华。

文章目录

UI 更新的痛点

用一个场景来展示日常游戏开发中的 UI 更新：

 1策划：案子写好了，UI 做一下。
 2UI 美术：做完了，切图在 xxxx。
 3程序：开始用 AI 拼界面。
 4UI 美术：字体不对，按钮差了 9 像素，边框没对齐。
 5程序：手动对齐。
 6策划：加了个按钮。
 7UI 美术：做完了，切图在 xxxx。
 8程序：这按钮加到哪里？手动加。
 9运营：上线了。
10UI 美术：为什么这个按钮的颜色不对？
11策划：为什么按钮的反馈不对？

UI 更新是碎片化的，各岗位的参与也是碎片化的。但对最终结果的检验，又需要大家看到同一个整体。

这导致了效率低下，不得不使用会议的方式来同步。 而会议总会占用开发人员不太愿意交出去的时间。

10 年前，曾老师写过一篇一定要开的会，其中有句话：

总有些事情必须让所有人明确的知道（有些重要的事情，你以为大家都知道，其实往往只有你自己知道），这就是动用一定要开的会的时候。

为了少开会，大家想了许多办法。UI 同步工具，就是其中一种。

PSD2UI

比较常见的做法，是让美术按规则命名 PSD 图层，再由工具自动导出图片、坐标和节点，生成引擎里的 UI。

先来看看一个标准的非语义化的 PSD 图层命名。很显然，无法从图层名称推导UI组件作用。

下面是常见的约定图层命名规范，各个项目的实际语法会不同：

这套模式有不少实践，但也有一些成本：

1. 遵循命名规则的成本。美术的思维方式与程序不同，规则需要培训，也需要工具检查。
2. 半角全角/英文中文/前后空格，这些处理程序员自己也经常出错，更别说美术了，出个错要找半天。
3. 多个 PSD、多位美术之间的共享，一个 PSD 两三个 GB，传来传去的痛苦谁知道……
4. PSD 图层与游戏 UI 之间的对应关系，需要独立维护。
5. 首次生成之后，程序往往已经挂上脚本和事件。下次重新导出，哪些能覆盖，哪些不能覆盖？

#AI嵌入游戏研发工作流 之后，图层命名这部分可以交给 AI 辅助整理，只是比较耗费 Token。但共享关系和后续更新的所有权，仍然要有人设计。

用 Figma 完成 UI 拼接

只要流程中有人类参与，就有沟通效率问题。按照上面提到的「各干各的」的思路，曾老师想到：

如果用 Figma 承担 UI 的拼接、排版和协作，让美术全面参与到拼界面的过程中来，是不是可以减少沟通成本？

一张界面对应一个 Frame，多张界面可以并排比较；重复的背景、按钮和列表单元可以通过 Component 与 Instance 统一维护。

讨论时，策划、美术和程序打开同一份设计稿，少传几次 PSD，少猜几次「你说的是哪个版本？」。

Photoshop 仍然可以负责绘画和素材加工，处理后的图片进入 Figma 组装。碰到有碎图需要调整的情况，美术将碎图传入 Figma，再通过插件推送到游戏引擎中，由程序预览并确认 Apply。

注意，Figma 官方并不直接支持导入 PSD。但 Figma 中已经有不少第三方插件，可以导入 PSD。曾老师人肉测试过，效果不错。即使自己实现一个 PSD 导入 Figma 的插件，也并不难。

DoomUI

基于上面的思考，曾老师开发了 UI 同步工具 DoomUI，Cocos Creator 的兼容范围为 >=3.8.6 <3.9.0。

文章底部提供工具网站和源码下载。

它解决四件事：

1. 把 Figma 中明确选择的 Frame、Component 转成 Cocos Prefab。
2. 让 Figma 负责持续维护视觉，减少在引擎里重复拼接。
3. 将已有 Cocos UI 一次性导入 Figma，给旧项目建立可编辑的起点。
4. 把程序维护的逻辑 Prefab 与工具生成的视觉 Prefab 分开，后续同步只更新视觉产物。

这里的「更新一次」，指设计侧修改一次后，由同步工具生成引擎产物。仍然需要程序检查变更、点击 Apply，并验收游戏里的效果。

目前完成运行态验证的环境是 macOS、Figma Desktop、Cocos Creator 3.8.6。兼容范围内的其他补丁版本尚未逐一验收，其他系统和引擎也没有做过独立验证。

Cocos Sync

安装在 Figma Desktop 中的插件，目录名是 cocos-sync。

它负责推送选中的设计、导入 Cocos Prefab、导入共享素材。三个主要入口分别是「同步到 Cocos」「创建 Figma 起点」「共享素材」。

Figma Sync

安装在 Cocos Creator 中的扩展，目录名是 figma-sync。

它负责本机连接、变更预览、资源校验、Prefab 和贴图写入，以及同步映射的维护。

名字记不住也没关系：插件名说的是它要连接的另一端。上面两张图是项目中的实际界面，下面再用一个独立工程走完整流程。

基础使用

安装和配对

完整源码已按 MIT 许可证开放：

1https://github.com/zrong/doomui

从源码试用，可以先运行仓库提供的命令：

1git clone https://github.com/zrong/doomui.git
2cd doomui
3just install
4just check
5just sandbox-link

前置环境和正式项目的扩展安装方式见仓库的 开发指南：

1https://github.com/zrong/doomui/blob/master/docs/development.md

1. 用 Creator 3.8.6 打开 sandbox/，从「扩展 → DoomUI → Figma Sync」打开面板。
2. 在 Figma Desktop 中使用「Plugins → Development → Import plugin from manifest…」，选择仓库中的 cocos-sync/manifest.json，然后运行 Cocos Sync。
3. 仓库已经固定了插件 ID，团队成员应使用同一个 manifest，无需每台电脑再创建一个新 ID。
4. 在 Cocos 面板展开「Desktop 连接」，把本机服务地址和当前配对码填入 Figma 插件，连接成功后再开始操作。
5. Figma 端使用 http://localhost:38638，Creator 服务只监听本机回环地址，两端需要运行在同一台电脑上。
6. 扩展重载或重置配对后，要用新的配对码重新连接。如果同时打开多个 Cocos 工程，还要确认端口和工程对应，避免把界面发给另一个项目。

给旧 Prefab 建立 Figma 起点

为了演示，曾老师单独建了一个 Creator 3.8.6 工程，准备了一张 720 × 540 的签到界面 UI_ArticleDemo，包含一个背景、几行文字、一个领取按钮，以及三个不同宽度的九宫格面板。

这个演示已经合入仓库的 sandbox/，可以直接运行 assets/ArticleDemo.scene。下面记录的是制作演示时的同步过程；在仓库示例中重新走一遍时，请按 Sandbox 说明使用独立的 assets/roundtrip Bundle。随仓库提供的 article_ui 是离线产物，不带私有 Figma 映射，不能直接当成已经建立关联的输出目录。

原 Prefab 放在：

1db://assets/legacy/UI_ArticleDemo.prefab

在 Cocos 的「创建 Figma 起点」中选择源 Prefab，导入类型选「UI Frame」，准备导入会话。源文件可以位于项目 assets 下的普通 Prefab 路径，不必先复制到工具的输出目录。

再到 Figma 的同名页签，选择目标 Page，点击「从 Cocos 导入」。这次会话读取了 15 个节点、2 张图片，导入预检为 0 个警告。

导入结果是可以编辑的 Frame、文字和图片节点。它会建立节点、图片与 Cocos 来源的映射，原 Prefab 保持原路径，内容不修改。

这一步只负责创建视觉起点，业务脚本和事件需要程序员迁移。 同一个源 Prefab 也不能反复导入成多个活跃来源；确实删除了原设计节点时，要在原 Figma 文件中确认并清理失效映射，再重新导入。

从 Figma 推送到 Cocos

在 Cocos 中创建一个真实 Asset Bundle，例如 assets/article_ui，在 Figma Sync 的输出设置里填写：

1db://assets/article_ui

普通文件夹仅仅叫这个名字还不够，需要在 Creator 中配置为 Bundle。工具会据此安排输出路径和资源归属。

在 Figma 中选中 UI_ArticleDemo Frame，点击「推送到 Cocos」。回到 Creator，先看 Preview：

• 将新增或更新哪些节点、Prefab 和贴图。
• 共享素材能否显示为 REUSE。
• 字体、布局和不支持属性产生了哪些警告。
• 是否存在阻断项，以及绑定契约是否发生变化。

预览里的「15 个新增」是节点变更数量，不是说要生成 15 个文件。确认后执行 Apply，写入资产。

本例的两张图是 Creator 的内置默认 UI 素材，来源和版本校验通过后直接复用，所以共享 Bundle 白名单留空也能看到 2 项 REUSE。

项目中自己的 common 等素材要走后面介绍的显式白名单规则。

UI 的主要产物是：

1assets/article_ui/
2├── prefabs/view/UI_ArticleDemo.prefab
3├── prefabs/view/figma/UI_ArticleDemo.root.prefab
4└── textures/figma/                  # 需要生成贴图时使用

再改一次，验证逻辑留存

首次 Apply 后，在外层逻辑 Prefab 挂上 ArticleDemoController，让「Claim reward」按钮修改奖励文字。然后保存逻辑 Prefab。

再到 Figma 把标题改为 Daily Check-in · Updated，重新 Push、Preview、Apply。

这次核对了文件和实际运行结果：

两次 Apply 都没有阻断项，但各有 9 条 FONT_UNMAPPED 警告：示例没有把 Figma 的 Arial/ArialMT 映射到项目字体，使用了回退字体。

这个演示验证了同步、资源复用和按钮逻辑保留。

九宫格：显示尺寸和切片边距分开

在 Figma 节点名后附上：

1panel @9slice{l:12,r:12,t:12,b:12}

l/r/t/b 分别是原图左、右、上、下的切片边距，单位是源图片像素。节点的 W/H 则是它在界面里显示的尺寸。

本例按钮背景原图为 40 × 40，四个边距均为 12。三个面板引用同一张图，显示尺寸分别为：

上面的 Figma 图与浏览器图就能对照这三个面板。调整显示尺寸，只改 W/H；调整边角保留范围，才改四个边距。

曾老师知道这个设计十分丑陋。但 Figma 没有与 Cocos SLICED Sprite 等价的原生九宫格预览。带有效 @9slice 标记时，DoomUI 会保留九宫格源图语义，这也算是一个 quick and dirty 的设计方案，简单有效。

在 Cocos 侧，还要区分两处设置：节点上的 Sprite.Type = SLICED，以及 SpriteFrame 资源本身保存的 Border。同一张图可以同时用于 SIMPLE 和 SLICED 节点，也能有不同显示尺寸。

设计思路说明

为什么不使用 API 拉取 Figma

曾老师最初实现过 Personal Access Token + REST API 拉取，后来把这部分支持源码删除了。

一个直接原因是额度：Figma REST API 会按端点、文件所在套餐和调用者席位限流。 如果插件依赖 REST API 频繁读取文件，就要核对文件所属套餐和席位的额度；仅仅在别处买了付费席位，也不保证当前文件有足够额度。

低额度的文件读取不适合频繁改 UI，那个额度少到甚至都没法用。具体规则见 Figma 官方限流说明：

1https://developers.figma.com/docs/rest-api/rate-limits/

另一个原因是工作流。我们已经需要 Figma 插件来创建旧 Prefab 的设计起点、读取当前选择、处理共享素材。再保留一套 URL/PAT 拉取，会增加配置、状态和验收成本。

现在的主链路是：

1Figma Desktop 中明确选择 Frame / Component
2                  ↓
3Plugin API 导出节点与所需图片
4                  ↓ 本机连接
5Cocos 接收 → Preview → 人工确认 Apply

既然两个插件已经覆盖了这条同步链路，就不必再为 REST 文件读取额度调整订阅。DoomUI 的设计传输在本机进行，不额外把设计上传到公网服务；Figma 文件本身仍按 Figma 的云端协作方式保存。

Frame、Component、Instance 各做什么

Frame 本身会成为逻辑 Prefab 的视觉子节点 root，不要在 Frame 内再包一个直接子节点 root，否则绑定路径就多了一层。

复用一张图片，并不需要把每个图标都做成 Component。Component 更适合统一维护一块结构、布局和样式。相同图片在同一 Bundle 内的去重，则由图片内容和导入设置决定。

一个 Item Component 会产生：

1prefabs/item/item_Reward.prefab
2prefabs/item/figma/item_Reward.root.prefab

Component 要保持 Page 直属。日常同步既可以只选一个 Frame，也可以只选一个 Component，或者在同一 Page 内多选。

注意：只推送本次明确选择的内容。 放在另一个 Page 的 Item，需要切过去单独推送，插件不会因为同步某张 UI 就自动扫描全文件所有 Item。

如果把旧 Item 导回原来的输出路径，要先备份并迁移它的人工逻辑，再按文档处理旧产物与首次生成的冲突。

不要把 「创建起点」 理解成允许覆盖已有业务 Prefab。

Button Variant 有明确边界

多个同级 Component 可以合并为 Component Set，再用 State 表达按钮状态：

1Button/Primary
2├── State=Default
3├── State=Hover
4├── State=Pressed
5└── State=Disabled

Default/Normal、Hover、Pressed/Down、Disabled 可以对应 Cocos Button 状态：

1. 原生 Button 的一次 Transition 只能负责图片、颜色或缩放中的一类变化。
2. Pressed 状态如果连文字、图标和多层特效都一起改变，就需要自己的运行时状态组件。
3. DoomUI 会对无法映射的情况降级并警告。

导出子树里还要包含所需状态定义，否则会出现状态不可用的警告。源码中的 sandbox/ 示例只验证了普通按钮点击，没有包含四态交互验证。

root 和外层逻辑 Prefab

核心设计逻辑，请认真阅读

这套结构的关键，是文件的维护责任：

1UI_ArticleDemo.prefab                    程序员维护
2├── ArticleDemoController
3└── root                                嵌套视觉 Prefab 实例
4    ├── $txt_title
5    ├── $txt_reward
6    └── $btn_claim
7
8UI_ArticleDemo.root.prefab               DoomUI 持续生成

逻辑 Prefab 只在首次同步时创建，以后保留程序员添加的脚本、事件和参数；视觉 .root.prefab 则跟随 Figma 更新。游戏实际加载的是外层逻辑 Prefab。

root 最初来自项目 UI 框架的约定，后来固定为 DoomUI 的标准。它并非 Cocos 或 Figma 官方要求，但在这套工作流里是标准规范。

外层 UI 根节点首次创建时有四边 Widget，内层视觉根保留设计尺寸，不强制四边拉伸。因此，外层可以跟随运行容器，弹窗的视觉内容仍保持设计大小。

后续修改 Frame 尺寸，不会影响程序员维护的外层配置。

有时脚本必须挂到视觉树内部，例如给 $list_rewards 加列表组件。应在外层逻辑 Prefab 的编辑模式里，对嵌套实例添加组件或子节点，并把这些添加保存为外层的实例覆盖；不要应用回视觉源 Prefab。保存后关闭重开，确认挂载关系仍在。

在外层编辑模式中添加的组件和子节点，应保存为外层实例覆盖；Figma 后续只更新 root 对应的视觉源 Prefab。若视觉节点被删除、改名或移动，原有覆盖和绑定仍可能受影响，需要保存重开并验证，不能仅凭编辑位置判断一定安全。

但是，如果你把 $btn_set 改名为 $btn_close，或者换父节点，代码中的名称或 root/... 查找路径就变了。DoomUI 会检查这类破坏性契约变更，要求确认；程序员还需要更新绑定代码，并实际点击验证。

$node_、$btn_、$txt_、$sp_ 等前缀用于声明和校验节点用途。工具不会自动生成你的 UIView、TypeScript Binding 或业务框架代码。

项目原来使用 Auto UI 的，仍应在逻辑 Prefab 上执行自己的绑定生成流程。

列表和 Item 的关系留给程序

列表最容易让人误以为「只要设计稿画出来，程序就能直接用」。

在 Figma 中，$list_rewards 是一个稳定的列表占位，Item Component 是独立的视觉目标。DoomUI 不会推断这个列表该使用哪个 Item，也不会自动生成运行时的 view/content 和数据逻辑。

程序员在外层逻辑 Prefab 中配置 ScrollView、项目自己的列表组件和 Item 引用。例如本项目使用 ListExtent.tmpPrefab，它应引用 item_Reward.prefab 逻辑壳，不能绕过逻辑层直接引用 .root.prefab。

没有旧 Prefab，也能复用共享素材

新界面经常要用 Cocos 中现成的公共按钮背景、图标和面板。为了导入一张图而先造一个假 Prefab，实在多余。

两端的「共享素材」页签就是为此准备的：

1. 在 Cocos 配置真实共享 Bundle 根，例如 db://assets/subpackages/common。
2. 在资源管理器单选或多选图片、SpriteFrame，准备共享素材会话。
3. 在 Figma 导入到当前文件的 Shared Assets Catalog。
4. 从 Catalog 的 Component 创建 Instance，或复制已有图片填充到新界面。
5. 推送新界面时查看 REUSE，不要也选中 Catalog。

Catalog 是一个带插件标记的 Frame，每张素材是一个 Component。同一文件只有一个 Catalog，可以改名、移动到其他 Page；Catalog 的身份不依赖「DoomUI Shared Assets」这个名字。

资源复用时，工具会核对 Figma imageRef、源图片 UUID、精确 SpriteFrame UUID、内容哈希、九宫格边距，以及源目录是否为白名单中的真实 Bundle。改节点名、复制同文件中的图片填充，不会影响来源文件。

全部通过后，生成的视觉 Prefab 直接引用原 SpriteFrame。若图片、切片设置或来源发生变化，则警告并回退为目标 Bundle 自有贴图，避免改坏旧界面。

空 SpriteFrame 与纯色也要区别对待。原来供程序动态赋图的空 $sp_ 槽位，未修改占位时回传仍应为空；设计师新画的纯色矩形则需要可渲染资源。

换电脑，需要保留哪些关联

Figma 云文件并没有保存程序员的全部 Cocos 工作。

只提交 Prefab、不提交映射，工具可能把已有文件视为非自己拥有的资源并阻断；只提交映射、不提交资产，设计虽能重建，人工脚本挂载、参数和原 UUID 引用却不能靠 Figma 恢复。

正式项目应把这些关联作为同一批变更提交。用于本机实验的 Bundle 可以不提交，但不能指望另一台电脑接着获得其中的程序逻辑。

使用限制和取舍

坐标系和锚点差异

Figma 通常以父容器左上角为原点，Y 轴向下；本工具生成的 Cocos UI 使用中心锚点 (0.5, 0.5)，Y 轴向上。

以父节点 100 × 100、子节点 84 × 31.72 为例：

1Cocos position = (0, -56.78)
2Figma position = (8, 90.92)
3
4Figma X = 0 + 100/2 - 84/2 = 8
5Figma Y = 100/2 - (-56.78) - 31.72/2 = 90.92

这是项目实际遇到过的例子。两边数值不同，逆向转换后仍能回到相同位置。这里的公式针对未旋转、父子均中心锚点的基础情况。

Figma 没有 Cocos 那种可配置的 anchorPoint。工具采用固定规则转换，无法把任意锚点语义原样搬过去。验收要比较回传后的运行效果。

还有四种「对齐」，需要分开看。把文字设置为水平居中，不能替代 Widget 的居中约束；点击一次 Align center，也不表示以后父节点变大时还会自动居中。

Widget、Layout 和 Scale 只能转换明确的部分

普通 Constraints 可以映射为 Widget，但 Cocos 的任意 Widget 组合并不能完整回到 Figma，表现如下：

1. target 不是直接父节点。同轴混合像素与百分比、特殊中心偏移和运行时 alignMode，都超出了直接对应范围。
2. Auto Layout 目前支持受限的横向、纵向排列，以及兼容的间距、Padding、Fixed/Hug 组合。Grid、复杂换行、Fill/Hug 混用等不能难以清晰表达，无法表达时会固化最终位置、尺寸并警告。
3. 缩放也采用视觉结果优先的取舍。Cocos 接管时会累计祖先 Scale，将结果烘焙进 Figma 坐标。例如 126 × 155 的根节点乘以 0.8，变成 100.8 × 124；下面 37 × 39 的节点再乘以 0.7，最终是 20.72 × 21.84。回传新的几何尺寸与单位缩放，无法恢复「尺寸 × 多层 Scale」的结构。

字体、图片效果和运行时组件要另行验收

字体要把 Figma 的 family/style 映射到项目中的 .ttf 或 .otf。回退字体可以让预览继续，但不等于文字宽度、换行、描边与目标设备表现已经验收。

在输出设置的「字体映射」中，每行按下面的格式填写，字体键以警告中报告的实际值为准，路径换成工程里已经导入的字体：

1Arial/ArialMT = db://assets/fonts/ui-regular.ttf

普通图片的 FIT、FILL、裁切和特效也会影响产物。简单原图可以直接用 SpriteFrame，复杂纯视觉内容可能栅格化为 PNG；带文字、按钮等语义子节点的复杂背景，工具会要求拆分或修正。

Mask 尤其如此：纯视觉遮罩可能被栅格化；包含 Text、Button 或绑定节点时，会保留结构、跳过无法表达的遮罩并警告。动态头像裁剪、ScrollView 视口仍需要在逻辑 Prefab 中配置真正的运行时 Mask。

进度、动画、物理组件、材质、业务事件和自定义脚本，不能从一张设计稿里自动推导出来。老 Prefab 的视觉导入完成后，要按警告和迁移清单逐项接回业务。

Preview、退役和清理

Preview 用来审查变更，不写入资产；Apply 使用当前预览计划写入，计划超过 10 分钟、被新 Push 替换或扩展重载后，需要重新推送并检查。

写入过程有失败恢复实现，但不能保证恢复完整工程。正式资产应该保留版本记录，失败后核对资源与引用。

设计节点移除后，旧贴图也不会顺便删除。ORPHAN / 解除管理 只说明它不再属于当前目标。彻底放弃一个同步目标时，可在「孤儿资源维护 → 同步目标映射」中退役这个素材，再审查候选、确认清理。

不要直接把已同步 Bundle 文件夹改名，期待映射自动跟随。面板的活动 Bundle Root 可以切换，用于不同目标；已经建立的目标有自己的输出路径，切换输入框不会自动迁移资产。

曾老师最后的建议：放弃人类参与

本来只是想做一个 UI 同步工具，做着做着就变成了 DoomUI 这样一个产品。

做完之后，在项目中进行了部分界面的更新测试，最后曾老师团队的决定是：

放弃使用DoomUI。

原因也很简单：

本来希望降低对人类的要求，现在反而提升了要求。

抛开 Figma 无法完美表达 Cocos 行为的问题不说（连九宫格都支持得那么丑陋），让美术和程序跑去重新学习 Figma ，让美术理解层级结构，就都不现实。

也许有人会说，学习有那么难吗？当然不难。但学习依然需要时间。

AI 时代，最宝贵的就是学习时间。

AI时代的研发，大部分时候，不应该把时间花在学习上。

因为AI知道一切，学得再快，也没有AI快。

但是，并不能简单地说，只要我学得慢，就永远不用学。

而应该理解为，在AI时代研发，需要：

• 让人类把自己能干的事情，干好。
• 让AI把人类不擅长快速完成的事情，干快。

当然，大公司，或者是有专门的UI岗位的团队，使用此类工具是提效的。因为大型团队需要将现有的团队的工作方式，更快地执行下去。大团队有惯性，大团队有人才，大团队有时间。

《颠覆性创新》一书中提到过，重复处理的任务多了，流程就会出现。

大型团队的稳定产出，需要依赖流程。黄金周刚刚过去，全国的景区都有想你的风，为什么所有的古镇都雷同？因为创新是会出错的，创新是昂贵的，创新是会让管理成本变得毫无价值的。在一个科层组织中，最高效且正确的工作方式，就是维持当前的流程不变。

换个角度说，DoomUI 这个方案，不适合没有专职 UI 岗位、习惯于一个人干 N 套活儿的创业小团队。

退一万步讲，都做到这里了，干嘛不用 FairyGUI？更强大，更配套。

1https://github.com/fairygui

DoomUI 的思路，充其量只是 在老的研发流程上的苟延残喘而已。

MCP / Agent / Skill 已经齐备，直接让 Agent 干活就好了。在美术标准和风格确定的前提下，甚至连 PSD 都不需要。

想要维护一个便于美术、策划共同查看和管理的视觉工作区，就必须接受转换边界和默会知识积累的时间代价。

读书笔记：《俞军产品方法论》中谈到过企业的默会知识。个人掌握的知识，需要通过内部惯例和制度，逐渐成为团队的共同知识，才能提升组织效率。

这个转换过程和制度化的过程，是需要时间沉淀的。在 AI 时代，显然有更好的办法加速这个沉淀。

什么办法？咱们下回再说。

DoomUI 官方网站和源码

DoomUI 是一套连接 Figma 与 Cocos Creator 的开源 UI 工具链。设计师在 Figma 中调整界面，手动推送所选设计；程序员在 Cocos 中预览变更，确认后生成或更新 Prefab，让设计迭代进入游戏工程。

兼容范围：Cocos Creator >=3.8.6 <3.9.0。当前已在 macOS + Figma Desktop + Creator 3.8.6 完成运行态验证，范围内其他补丁版本尚未逐一验收。

DoomUI 官方网站

1https://zengrong.net/project/doomui/

GitHub 源码

1https://github.com/zrong/doomui

来胡扯社群，一起聊天！

有很多重要内容，公众号发不了，但群里特别能聊。

「胡扯漫剧」 社群关注最新的 AI 漫剧知识，技巧和搞钱方法论。

「胡扯游戏」 社群有独立开发者，游戏公司创始人、大厂负责人、量子理论研究者…… 独立游戏、商业游戏、流量游戏、研发、投放、发行、运营、招人 都能聊，纯唠嗑也欢迎。

「胡扯行业」 群关注游戏、电商、工具、视频…… 泛互联网行业都可以加入。

「胡扯AI」 社群关注 AI 深度整合进入工作流。

胡扯知识（免费）	胡扯社群（免费）

识别上方二维码获取加入胡扯社群的详细说明，关注下方公众号亦可获得更多信息。

「曾嵘胡扯的地方」是一个关注AI、游戏、互联网前沿资讯的公众号。撰稿人曾老师基于丰富的创业经验和公司管理经验，多年的游戏研发经验，全栈编程和自研+自发经验，二十多年的写作经验，持续以公众号为阵地，进行高频输出和有效讨论。公众号追求松弛感，提供正能量，为群友提供价值，为行业做点贡献。

都刷到这里了，不来个「点赞」「分享」「在看」一键三连吗？