AI-Wiki

文档概览

原文的核心立场很明确：AI 生成游戏素材已经从“看起来很酷但难以落地”，推进到“可以直接塞进 Unity/Godot 跑起来”的阶段。文章不讨论趋势判断，而是只讨论当前已经能实际使用的工具和做法。

文章按三类可落地资产展开：

角色分层素材
游戏地图瓦片与场景
UI 界面组件

作者反复强调一个边界：这里讨论的不是单纯用来做游戏美术参考资料的概念图，而是能进入 Unity 或 Godot 工作流、可切片、可导出、可复用、可做动画或拼场景的生产资产。

文末还补了工具速查表与若干共通坑点，尤其强调透明底、分辨率、seed 锁定、后处理成本和商用条款。

关键事实

一、文章按三类生产资产组织，而非按模型或平台组织

原文不是按“哪个模型最强”来写，而是按游戏开发中最常见、最需要工程化输出的三类资产来写：

角色分层素材：重点是透明底精灵图、多帧动作、画风一致。
地图瓦片与场景：重点是无缝拼接、风格统一、可批量扩展到完整地图。
UI 界面组件：重点是按钮、面板、HUD、状态变体、自动切片与导出。

这种组织方式对应的是实际生产流程，而不是单次出图效果。它与项目视觉参考板或游戏美术参考资料的用途不同，关注的是能否进入引擎、能否复用、能否批量生产。

二、角色精灵案例 1：腾讯元宝智能体 + ComfyUI 的完整透明底多帧工作流

原文给出的第一个角色案例，是一条完整的低成本角色精灵工作流，目标是输入一句角色描述，约 10 秒输出一张包含多个动作帧的透明底 PNG，然后在 Unity 中直接切片成动画。

工具链由五部分组成：

腾讯元宝智能体：把自然语言角色描述扩展为结构化英文提示词
ComfyUI：搭建文生图工作流
2D Pixel Toolkit LoRA：固定像素风格
OpenPose + ControlNet：锁定动作姿态
LayerDiffuse 插件：直接生成透明底 RGBA 图像，省掉抠图

原文给出了腾讯元宝智能体中的明确规则，属于这个案例最关键的前置约束：

提示词必须是英文
长度控制在 50-70 词
用逗号分隔
开头固定前缀为 , full body, pixel art, highly detailed
必含分类：角色职业、主要配色、身高描述、胖瘦描述、头发颜色、头发长度、头饰或帽子、皮肤颜色、身体其他特征
每个分类 1-2 个词
各分类之间不能互相矛盾
不描述手持物品

“不描述手持物品”是一个非常具体的限制，不是泛泛建议。它意味着为了减少多帧动作中的结构漂移和遮挡混乱，提示词层面就主动回避会影响姿态一致性的内容。

三、角色精灵案例中的骨骼参考制作细节非常具体

在动作用姿态控制部分，原文没有只说“用 OpenPose 控一下”，而是给出了完整的参考制作步骤：

从 Mixamo 下载跑步动作 FBX
每隔 5 帧截图一张
在 Figma 中把截图拼接为 512×512 参考图
用 OpenPose 识别骨骼
再用 OpenPose Editor 逐帧校准缺失肢体节点

原文明确指出，这一步是整个流程中最耗时间的一步：一个 4 帧跑步动作，大约需要 15-20 分钟校准。

这说明该方案虽然“生成”很快，但前期姿态参考并非零成本。实际瓶颈不是模型采样，而是骨骼对齐与可控性准备。

四、ComfyUI 工作流的节点顺序和关键参数被明确给出

原文没有只说“搭个 ComfyUI 工作流”，而是列出了节点串联顺序：

提示词输入 → Checkpoint Loader → KSampler → ControlNet(OpenPose) → LoRA Loader(2D Pixel Toolkit) → LayerDiffuse → VAE Decode → 保存 PNG

关键参数也给得很明确：

Checkpoint：DreamShaper
LoRA 权重：0.7-0.85
ControlNet 强度：0.8-1.0
LayerDiffuse：foreground 模式
输出：含 Alpha 通道的 PNG

其中几个参数有明显的工程含义：

DreamShaper 被作为基础 checkpoint 使用。
LoRA 权重 0.7-0.85 说明像素风约束不能过弱，否则风格会漂；也不能一味拉满，否则可能压死角色差异。
ControlNet 强度 0.8-1.0 表明姿态控制在该案例里优先级很高。
LayerDiffuse 不是普通生成后再抠图，而是直接走 foreground 模式输出透明底。

最后导入 Unity 的步骤也很直白：在 Unity Sprite Editor 中按帧切片，再拖入 Animation Controller 形成角色动画。

原文还给出成本结论：这条链路的成本是零元，因为所用工具均有免费版或开源方案。

五、Layer.ai 的定位是团队风格锁定与批量生产，而非个人折腾型节点工作流

角色部分的第二个案例是 Layer.ai。原文对它的定位非常清楚：它是面向游戏工作室的平台，核心价值是“风格一致性”。

使用方式是：

上传 10-20 张美术风格参考图
在云端训练一个专属风格模型
输入提示词生成角色精灵图、动画帧、精灵表
输出 PNG 透明底，可直接导入引擎

这里有几个重要点：

训练集规模是 10-20 张，不是海量数据。
训练在云端完成，不需要本地 GPU。
产出不止单张图，而包括动画帧和 Sprite Sheet。
输出是透明底 PNG，直接面向引擎使用。

原文还给了一个实际产能级别的描述：有工作室每周用它生成数百张 2D 插画级角色素材。作者强调这些不是概念图，而是生产资产。

六、Agent Sprite Forge 代表的是“需求描述 → 自动规划 → 自动后处理 → 引擎导出”的全自动思路

角色部分的第三个案例是 Agent Sprite Forge。原文强调它和前两类方案的差异在于：用户只描述需求，其余的资产规划、生成、后处理和输出由自动化管线完成。

它是 GitHub 上的 MIT 许可开源项目。

两个核心命令是：

$generate2dsprite：生成角色精灵表、动画帧、道具包、特效包，并自动完成色度键清理、去溢色、帧提取、对齐、透明 GIF/PNG 导出
$generate2dmap：生成分层光栅地图、道具包、碰撞区/触发区，并可直接输出 Godot 可编辑场景文件

原文概括的工作流为：

用户描述需求 → Codex Agent 选择资产类型/帧数/布局策略 → 内置图像生成模型创建原始素材 → Python 确定性脚本做后处理（扣底、切片、对齐、导出） → 可选：组装 Godot/Unity 场景文件

这里“Codex Agent 选择资产类型/帧数/布局策略”和“Python 确定性脚本做后处理”是两个非常重要的工程化点：

前者说明它不是纯图片模型接口，而是会先做资产规划。
后者说明后处理不是继续交给随机模型，而是交给可复现脚本，降低产物不稳定性。

原文列出的输出文件也很具体：

raw-sheet.png：原始精灵表
sheet-transparent.png：透明底版本
逐帧 PNG
动画 GIF
pipeline-meta.json：流水线元数据

这类输出结构意味着它不是“只给你一张图”，而是产出完整中间件和可追踪元数据，更接近工程资产包。

七、地图部分的核心不是“生成一张场景图”，而是“持续生成可拼接、可扩展、风格统一的地图资产”

原文第二大部分讨论游戏地图，重点从瓦片到完整场景。这里列了三种代表性方案：Scenario、Leonardo.AI、Agent Sprite Forge。

八、Scenario 提供了两条地图工作流：训练自有风格模型，或从零在画布中逐层构建

原文在 Scenario 部分明确区分了两种 workflow，这一点是地图章节最关键的信息之一。

Workflow A：训练专属模型

步骤为：

准备 8-20 张符合项目美术方向的等距瓦片参考图
这些参考图应包含直线边缘、转角、过渡等结构
上传到 Scenario
训练自定义模型
输入提示词批量生成同风格变体

这条路线的目的，是解决“AI 画风不统一”的问题。原文判断这是目前最可靠的路径之一。

Workflow B：从零用 Inpainting 构建