踩坑无数！GPT 生成的游戏 UI，完整可落地的工作流程终于摸透

上一篇发完，评论区里有一条留言很扎我。

pp 问：

“然后自己挨个扣下来吗”

我当时回了一句：

“不用的，有更好的方法，周一我出开发游戏的详细教程。”

评论区组件库抠图提问

我一开始也这么想过。

上篇文章里，我让 GPT 生成了一整套游戏 UI 组件库。它看起来很完整，有面板、按钮、图标、边框、道具，像一张可以直接交给开发的资产总览图。

但问题来了。

一张图很好看，不等于它能用。

要真正用起来，你得把里面的每一个按钮、每一个图标、每一个头像都变成单独文件。评论区还有人说：“不用抠啊，你直接让 AI 给你列好目录输出就可以了。”

这个方向是对的。

于是我顺着这个问题，真的去试了一遍。

不是只在脑子里想“应该怎么用”，而是先做一个游戏，再回头验证：这套 UI 到底该怎么变成真实资产。

结论是：抠图这条路能走，但我不建议个人开发者一上来就这么走。

不是因为抠图技术不行。是因为游戏会改。

1我先做了一个游戏

为了验证这套 UI 到底能不能用，我没有停在概念图那一步。

我让 Codex 和我一起做了一个互动叙事小游戏，叫《生活的背面》。

它的主题很简单：

我们总在羡慕别人的人生正面，却看不到他们背后的代价。更有意思的是，我们自己也可能正在被别人羡慕。

我把它做成了一个手机解谜游戏。

玩家捡到一部陌生人的碎屏手机，里面有聊天记录、相册、账单、备忘录。你要一点点翻这些信息，收集 17 条线索，解 5 道推理题，再把三个人连成一个“羡慕之环”。

这不是一个很大的游戏。

但它刚好够用。

够我验证一件事：AI 生成的游戏 UI，怎么从“好看的图”变成“真的能跑的资产”。

2抠图这件事，我真的试了

准备做游戏之后，我先试的是最直觉的办法：

把前面那张完整 UI 组件库大图拿来，从里面把组件切出来。

我找到了一个叫 Playmo Studio 的工具。它可以上传一张大图，自动识别主体，框选后导出透明 PNG。我试了一次，能用。

Playmo Studio 切割演示

从技术上讲，这条路是成立的。

有些工具能把大图里的小组件切得很干净。后来我还查到，游戏行业里本来就有类似做法，叫 sprite sheet，中文一般叫精灵图。

精灵图不是“靠肉眼抠图”。

它是一张合并后的大图，加一份机器能读的坐标表。代码知道每个图标在大图的哪一块，就能按名字取出来。比如 Phaser、Pixi、Unity 这些游戏引擎，都会用 texture atlas 这类东西。

所以我不是说“一张大图”一定错。

大厂、成熟团队、有固定美术管线，用精灵图很正常。它能减少请求、统一管理资源、方便性能优化。

但我这种个人做小游戏的场景，不一样。

我没有美术管线。

我也不是在维护一套已经定型的资产。

我是在一边做，一边改。

3真正的问题：游戏不是第一版就定稿

《生活的背面》一共做了三版。

v1 是桌面翻牌。

桌上放着照片、信封、工牌，你点一下翻正面，再点一下翻背面。翻完之后，把线索连起来。

v1 桌面翻牌界面

我自己玩了一遍，感觉不对。

信息太直接了。

所有东西都摆在那里，玩家只是点开它们。没有“我发现了什么”的感觉，也没有推理的快感。

于是 v2 改成了手机。

玩家不是在翻桌面物件，而是在翻一部手机。聊天记录、相册、账单、备忘录，本身就更像现代人的秘密抽屉。

v2 手机形态界面

到 v3，我又加了推理机制。

你不是把线索看完就结束，而是要用证据去解 5 道题。解完之后，才能在黑板上把三个人连成环。

v3 推理黑板

这三版改下来，我越来越确定：游戏 UI 不能一开始就焊死在一张图里。

今天我觉得需要 4 个 tab 图标，明天可能只保留 3 个。

今天角色叫陈远、陈若、陈亮，后面发现同姓会让人误会成亲兄妹，又改成林远、苏若、周亮。

今天需要一张桌面背景，明天整个玩法变成手机，桌面背景就没用了。

如果所有组件都在一张大图里，我每次改 20%，都要牵动那张图里的 100%。

这就很难受。

不是不能做。

是不适合我这种边做边试的人。

4后来我换了一套方法

我后来换成了这套流程：

先和 AI 聊想法。

让它给我几个适合这个主题的游戏形态。

选定一个方向后，先写游戏文档。

再用占位图和临时 UI，把游戏初版跑起来。

然后根据这个初版页面，列出真正需要的视觉资产清单。

再按清单逐个生图，替换进游戏里。

听起来反而更笨，但它更适合我。

第一步先和 AI 聊想法

我告诉它：我想做一个关于“我们总在羡慕别人的人生，但看不见别人背后代价”的游戏。你觉得这个主题适合做成什么样？

它会给几个方向。

可能是翻牌，可能是聊天记录，可能是侦探推理，也可能是互动小说。

我选了“捡到一部陌生手机”这个方向。

第二步写游戏文档

玩法是什么，人物是谁，需要哪些界面，需要哪些线索，哪些东西必须是图片，哪些可以用 CSS 画。

这一步不是为了写得多专业。

是为了让 AI 知道这个游戏到底是什么。

第三步先做一个能跑的初版

这时候不用急着生图。

先用占位图、色块、临时按钮，把游戏流程跑通。能点，能切换，能看到大概结构就行。

因为这时候很多东西还会变。

你现在生一整套精美资产，后面玩法一改，很多图就白生了。

不是先画一整套“看起来很完整”的组件库。

而是先问：这个游戏现在真的需要什么？

第四步让 Codex 根据初版页面列资产清单

比如它会告诉我：需要 3 个主角头像、4 个 tab 图标、4 个配角符号头像、几张横版场景图、一张终局“羡慕之环”插图。

这一步很重要。

我不是凭空猜组件，也不是先生成一张“全家桶”大图。

我是先把游戏做出一个毛坯，再让 AI 看着真实页面列。

第五步统一风格，再逐个生成、替换进去

我给每张图都加同一段风格前缀。

这段前缀负责锁住材质、色调、边框和光照，后面再接每张图自己的描述：

Game UI component, dark emerald green leather texture with aged brass/copper trim, vintage parchment paper inlay, consistent with existing UI kit style. Black background, centered, clean edges for web use. PNG, 1024px.

比如聊天 tab：

A circular tab icon for "Chat". Dark green leather circle with brass ring border, inside shows a simplified chat bubble symbol embossed in aged parchment color. 256x256px.

相册、账单、备忘录也是同一套前缀，只换里面的符号。

配角符号头像也是同样的逻辑。

妈妈用复古电话，大姨用伸手求助，一家人群聊用圆桌聚餐，学姐用日记本和眼镜。

这样生出来的图，就不会像“一堆东西”，而会像“一套东西”。

复古电话图标

伸手求助图标

圆桌聚餐图标

日记本与眼镜图标

还有一个小技巧。

每次生图，我都垫同一张基准图。

不是这一张垫上一张、上一张再垫上上一张。

那样风格会一路漂。

我固定拿第一张满意的图当基准，让后面所有图都向它靠拢。

5Codex 生图这块，我也踩坑了

一开始我想偷懒，直接让 Codex 一次生成一堆图。

我发了 8 张提示词。

它生了 2 张，然后卡住了。

我以为是数量太多，就减到一次 2 张。

结果等了 30 分钟，才出来两张。

再减到一次 1 张，能跑，但还是慢。大概 5 分钟一张。

Codex 生成素材等待截图

后来我换到 GPT 网页端。

同样的提示词，半分钟到一分钟一张。

生完之后，我直接把图丢进 games/assets/ 文件夹，跟 Codex 说：图在这里，你改名，然后插进游戏页面。

它会自己处理引用路径、文件名、页面替换。

所以这套活儿后来变成了这样：

GPT 网页端负责生图。

Codex 负责写代码和接资源。

我负责判断：这张图能不能用，这个玩法好不好玩，这版要不要继续改。

这也是我现在越来越喜欢的协作方式。

我不需要每一步都懂代码。

但我必须能判断结果。

6逐个生成也不是完美答案

这套方法也有代价。

最大的问题是一致性。

逐个生成，第 10 张图和第 1 张图可能就不是一个味儿了。

我用统一前缀、固定垫图去压住它，但只能缓解，不能完全解决。

一张大图在这一点上反而有优势：同一次生成，天然更统一。

所以这不是“逐个生成吊打抠图”。

更准确地说，是我拿“一点一致性风险”，换了“可局部修改”。

对个人开发来说，这个交换划算。

因为我最怕的不是性能不够，也不是资源管理不够工业化。

我最怕的是：做着做着发现不对，但改不动了。

还有一点，后来我也想明白了。

功能性 UI 不一定都要用图片。

按钮、tab、高亮状态、推理黑板、证据卡，这些规则性很强的东西，用 CSS 或 SVG 画，反而更好。改颜色改一个变量，改尺寸改一个数，永远不会漂。

AI 生图更适合那些代码不好画的东西：

人物头像。

场景氛围。

复古纹理。

结局插画。

所以我的理想流程不是“所有东西都交给 AI 生图”。

而是两条线：

规则性 UI 用代码。

情绪性资产用 AI 图。

7这个方法适合谁

如果你是大厂团队，有成熟的美术资产、命名规范、sprite sheet 工具、引擎管线，那你应该继续用专业流程。

我这套方法不是工业标准答案。

它更像是给个人开发者的轻量替代方案：

用自然语言维护视觉资产。

需要什么，列出来。

先生成能用的。

哪张不好，单独重做。

哪版玩法改了，只动相关资产。

这套方法牺牲了一点一致性和性能优化，换来的是零门槛、低成本、可迭代。

对我这种不会写代码、也没有美术团队的人来说，够了。

而且很关键的一点是：

它让我敢开始。

以前“游戏美术”听起来是很远的词。

现在我知道，如果我脑子里有一个游戏，我可以先和 AI 把想法聊清楚，再写文档、做初版、列资产、让 GPT 一张张生图，然后让 Codex 接进页面。

第一版不好玩，就改。

第二版不顺，就再改。

不用等到什么都准备好。

8文末放一下我的提示词结构

如果你也想试，可以直接按这个格式来。

不要一上来让 AI “生成一整套游戏 UI 组件库”。

先让它帮你把游戏方向聊出来：

我想做一个互动小游戏，主题是：[写你的主题]。  请你给我 5 个适合这个主题的游戏形态。  要求： 1. 每个方向用一句话说清玩法。 2. 说明这个玩法为什么适合这个主题。 3. 标出哪个方向最适合一个人用 AI 快速做出原型。 4. 不要急着写代码，先帮我选方向。

选定方向后，让它写游戏文档：

我选择第 X 个方向。  请把它整理成一份游戏设计文档。  要求： 1. 写清核心玩法、主要角色、关卡流程、玩家要做什么。 2. 写清每个页面需要展示什么信息。 3. 先不要追求美术细节，重点是让 Codex 能根据这份文档做出一个可玩的初版。

接着让 Codex 先做占位版：

请根据这份游戏设计文档，先做一个可以玩的网页原型。  要求： 1. 先用占位图、色块、CSS 临时 UI，不要生成正式美术资源。 2. 保证核心流程能跑通。 3. 每个未来需要替换成图片资产的位置，用清楚的占位名称标出来。

等占位版跑起来，再让它根据游戏文档和页面列资产清单。这里可以顺手让它把统一风格前缀也写出来：

请根据这个已经跑起来的游戏原型和设计文档，列出真正需要独立生成的视觉资产。  要求： 1. 只列需要图片生成的资产，不要把可以用 CSS/SVG 实现的按钮和面板列进去。 2. 每个资产写清用途、尺寸比例、是否需要透明背景。 3. 给每个资产写一段英文生图提示词。 4. 所有提示词都共用同一段统一风格前缀。 5. 标明每张图生成后应该替换到页面的哪个占位位置。

如果你对前缀不满意，再单独让它重写一版：

请为这个游戏写一段统一风格前缀，用来生成所有 UI 图片资产。  要求： 1. 锁定材质、色调、光照、边框风格。 2. 不要包含具体物体。 3. 每个组件提示词前都可以复用。 4. 输出英文。

然后逐个生成。

不要贪快。

一张一张看，一张一张改。

这件事反而和做游戏很像。

不是第一版就对。

是你能不能一直改到它对。

评论区有人问，AI 生成的游戏 UI 组件库怎么用。

如果你本来就是游戏从业者，有成熟的图集、切图和引擎工作流，抠图/合图当然重要。

但如果你和我一样，只是一个对做游戏有兴趣、没有美术管线的人，我现在的答案是：

别一开始就卡在抠图上。

先做一个真的会变的游戏。