Vibe Coding 独立游戏实战（二）：Godot、Agent 协作与 AI 美术资产
本文根据 Nenly 的第 2/4 篇 X 长文整理。原文发布于 2026 年 10 月 28 日，是《群侠传：幸存者》开发复盘的续篇，内容覆盖 AI Coding 和 AI 美术两部分，末尾标注“未完待续”。本文只整理当前公开内容；作者对项目规模、模型分工和工具效果的描述属于个人实践记录，不构成复现保证。
上一篇复盘讲了如何从题材、需求、对标调研和最小可玩原型开始。本篇进入真正耗时的生产环节：让 Agent 持续修改游戏代码，再把 AI 生成的角色、地图和 UI 资产变成引擎里可以运行的资源。
作者的实践可以概括成两条并行流水线：
设计文档 / 执行计划
→ Agent 读代码、修改、验证、提交
→ Godot 实机运行与人工验收
视觉规范 / 概念稿
→ 生成、风格校准、分层、抠图和组件化
→ 导入 Godot、适配碰撞与布局、实机检查
Godot 4：文本化项目更适合 Agent 接管
作者最初让 Agent 用 HTML 搭了一个原型，后来因为项目包含较多资产和数据，选择迁移到 Godot 4。选择 Godot 的直接原因是开源免费、使用 MIT 许可证，以及脚本、场景和资源配置基本都以文本形式存在。
这带来一个对 AI Coding 很实际的优点：Agent 可以直接读取和修改项目文件，不必完全依赖编辑器里的鼠标操作。一个敌人的场景、节点属性和资源引用，对 Agent 来说都是可以搜索、比较和提交的文本。
作者的工作方式很简单：用 Godot 建立项目目录，让 Coding Agent 进入项目根目录完成修改，再回到编辑器按 F5 启动主场景，检查实机效果。原文提到没有使用 MCP，多数时候也不需要 Computer Use。
这不是说图形化编辑器没有价值，而是把职责分开：
| 环节 | 更适合的工具 |
|---|---|
| 代码、场景配置和数据修改 | Agent + 文本文件 + Git |
| 运行、手感和视觉检查 | Godot 编辑器与实际试玩 |
| 复杂资源的手工调整 | 图像编辑器、动画工具或音频工具 |
| 版本恢复和比较 | Git 提交与差异 |
对于初学者，文本化并不等于可以不理解项目。仍然需要知道主场景、节点、资源路径、输入映射和运行命令，否则 Agent 改错时很难判断问题发生在哪一层。
规划模型与执行模型分开
作者回顾了不同阶段的模型分工。早期使用一个模型负责代码理解、规划和复盘，另一个模型负责实现、重构和排错；随着模型更新，后来进一步把工作拆成两层：
全盘规划
→ 读代码、做调研、拆方案、形成执行计划
长程执行
→ 按计划实现功能、运行验证、分批提交
这种拆分的理由是，大功能无法在一个会话里快速完成。规划层留下文档性的执行计划，执行层可以跨会话、跨 Agent 接着做。遇到小 Bug、文案修改和局部调整时，可以直接交给执行层处理，避免每次都重新加载完整背景。
这套分工的关键不是记住某几个模型名称，而是让“计划”和“改动”之间有明确接口。计划至少应该写清：目标、现状、涉及文件、约束、分步任务、验证方式和未决问题。
一个简单的计划文件可以这样组织：
目标：加入新的门派选择和对应初始武学
现状：角色选择界面已有，但门派数据仍写死在脚本中
范围：数据表、选择界面、存档初始化、三条测试路径
不做：重做战斗数值，不修改旧门派的资源
验收：新建存档可选择新门派；进入战斗后初始武学正确；旧存档不受影响
验证：启动游戏、创建新存档、加载旧存档、运行数据校验
没有这种中间记录时，规划模型的判断很容易停留在对话里，执行模型只能重新猜测上下文。
AGENTS.md 是多 Agent 的共同规则
作者同时使用 Claude Code、Codex、Kimi Code 和 ZCode 等工具。多个 Agent 可以在同一个仓库协作，前提是它们读到的是同一套项目规则。
作者使用仓库根目录的 AGENTS.md 说明自己的背景、项目结构、沟通方式和工作约束。对一个没有编程经验的开发者，规则文件还可以告诉 Agent：解释要用能理解的语言、方案要先说清风险、改动要小步提交、完成后要提供验证证据。
规则文件不应该变成几十页的万能手册。模型能力提升后，过时的限制和重复的安全提醒会占用上下文，却不能增加实际稳定性。更好的做法是保留真正影响项目的事实：目录结构、命令、数据约定、验收方式、不可触碰的资产和回滚规则。
一个适合游戏项目的最小规则区块可以包括：
- 项目如何启动、测试和导出；
- 哪些文件是设计事实，哪些文件是当前实现；
- 资源命名、尺寸、路径和导入约定；
- 修改 UI、数值、存档和输入时需要检查什么；
- 每次改动必须提供什么运行截图或试玩证据；
- 哪些目录不能覆盖，哪些改动必须先拆成计划。
Skill：沉淀反复出现的流程，而不是堆教程
作者早期安装过很多看起来与游戏开发、Godot 或写代码相关的通用 Skill，后来通过查看 Agent 的调用记录发现，其中不少几乎没有真正触发。于是他删掉了大而泛的 Skill，只保留项目中反复使用、边界清晰的流程。
这给游戏项目的 Skill 设计一个很实用的判断标准：
是否重复出现？
是否有明确输入和输出？
是否有稳定的验收步骤？
是否能跨一次具体任务复用？
例如素材导入压缩、性能基准测试、封包上传和特定 UI 组件生成，往往比“通用游戏开发方法论”更适合做成 Skill。太泛的 Skill 可能与模型已经掌握的常识重复，甚至用额外约束限制了本来可以更好的方案。
作者还维护了一个项目经验 Skill：每次完成有意义的改动，都追问这条经验换一个游戏、换一个引擎、换一套美术流程是否仍然成立。只有能跨场景复用的结论才回流到 Skill 中。
多 Agent 共用 Skill 时，要保持一份真源。作者将 Skill 放在 .claude/skills，其他工具通过目录链接指向它，避免每个 Agent 各自维护一份逐渐漂移的副本。
AI 美术第一步：先固定视觉语言
游戏需要大量角色、敌人、场景、UI 和道具资产。作者先选择了类似 HD-2D 的像素风作为视觉方向，一方面是个人审美，另一方面是像素化和光影处理可以降低某些生成瑕疵的违和感。
他也明确承认，这并不等于真正的像素风或完整的 HD-2D 工程，而是一种为项目服务的近似视觉语言。这个区分很重要：生成一张“像某种风格”的图片，不代表项目已经建立了统一的渲染和资产规范。
风格锚点应该写成可检查的规则，例如：
- 像素密度和角色比例；
- 线条、材质和边缘处理；
- 主光源方向、阴影颜色和体积光；
- 场景的前中后景关系；
- UI 的色板、边框、间距和字体；
- 角色、敌人和道具在战斗中的识别优先级。
后续每次生成资产都带上这份风格约束，生成后再用已有主角、场景或 UI 组件做对照。
角色和敌人：概念稿、风格迁移、手工修整
作者把角色和敌人的生产拆成三步。
1. 先生成概念稿
提示词同时写入整体风格、门派视觉基调、敌人外貌、服装、侧身动势和识别点。一张图适合放少量普通敌人，BOSS 则单独描述，避免模型把不同角色的武器、体型和服饰混在一起。
2. 用主角校准风格和比例
单独做“把图 A 变成图 B 的风格”效果可能不稳定。作者尝试让模型把敌人加入已经包含主角的画面，并放在主角旁边的空白区域，再要求使用主角所在画面的画风和相对比例。
这不是通用的模型保证，而是一种经验性工作方法。它的价值在于给模型同时提供风格参照、尺寸参照和构图位置，减少单张图之间的漂移。
3. 手工抠图和微调
生成一排角色后，仍要手工抠出每个角色，调整身体比例、修掉不满意的局部，再决定是否重新生成。最终的精灵图还需要统一命名、尺寸、锚点和透明边界，才能进入动画和碰撞流程。
场景制作：从一张背景图到可行走地图
一张漂亮的概念图直接导入游戏，只能成为铺在底下的背景。要让角色走到建筑后面、被前景遮挡，场景必须拆成可以独立控制的层。
作者把雪山场景拆成地面与地形底图、前景遮挡、建筑和旗帜、坛火光照、体积光和飘雪等部分，再提供合成说明，让 Agent 在 Godot 中拼回去。动态元素可以在此基础上加入程序化动效或序列帧。
概念图
→ 地面 / 建筑 / 前景 / 光效分层
→ 每层独立裁切和命名
→ Godot 中按深度排序
→ 加入碰撞、遮挡和动态效果
→ 实机检查可读性与性能
纯白背景常用于抠图，纯黑背景则可以作为光效或氛围层，用加算等混合模式合成。对于复杂地形，还需要手绘可行走区域遮罩，明确玩家能走和不能走的位置。
这一步体现了“生成素材”和“游戏资产”之间的差异：资产不仅要好看，还要包含层级、遮挡、碰撞、导航和运行时性能信息。
UI：从整页设计稿到可复用组件
作者把 UI 制作流程拆成五步：
- 先做 UI 原型，标明位置和每块区域的功能；
- 让图像模型根据原型生成整页设计稿；
- 将框体、血条、按钮和图标底座拆成独立零件；
- 在图像编辑器里拼装和修改，直到视觉符合预期；
- 让 Agent 读取 PSD 的图层名、坐标、尺寸和混合模式，重新放进 Godot 场景。
早期模型无法稳定输出透明背景时，作者使用纯白、纯绿或洋红色背景，再通过抠图处理。现在工具能力可能已经变化，但仍应检查透明边缘、抗锯齿和不同背景下的显示效果。
固定尺寸窗口在换分辨率后容易变形。作者进一步了解了组件化 UI 和 Nine Slice，把一套素材拆成背景、填充条、节点和可拖动部分，再通过组件参数重组为不同尺寸的滑杆和窗口。
一个 UI 组件应至少明确：
| 项目 | 需要记录的内容 |
|---|---|
| 视觉部件 | 背景、边框、填充、节点、图标和交互态 |
| 尺寸规则 | 固定尺寸、可拉伸区域、最小和最大宽高 |
| 布局规则 | 锚点、间距、Nine Slice 边界和响应式行为 |
| 交互状态 | 默认、悬停、按下、禁用、选中和错误 |
| 验收方式 | 不同分辨率、语言长度和窗口尺寸下的截图或试玩 |
当组件被稳定拆分后，才值得写成 Skill，让 Agent 可以快速调用，而不是每次从一张整页截图重新猜测。
代码和美术必须在同一个验收循环里
这篇复盘反复说明，代码和资产不能分成两个互不相干的阶段。新的敌人需要数据、动画、碰撞和 UI 信息；新的地图需要层级、遮罩、导航和性能检查；新的滑杆需要素材拆分、组件规则和分辨率测试。
因此，一个可执行的任务应同时写清：
功能目标
+ 涉及的代码、数据和资产
+ 资源路径、命名和导入规则
+ 运行时行为和失败边界
+ 截图、试玩或性能验收
+ 可回滚的提交范围
只看编辑器里的节点树，不能证明游戏体验正确；只看生成图片，也不能证明资产能在游戏里使用。每轮改动都应进入实机，检查布局、遮挡、碰撞、动画、性能和玩家能否理解当前反馈。
给自己的 AI 游戏项目的最小清单
如果你准备从零开始，可以先建立以下文件和规则：
AGENTS.md：项目结构、命令、沟通方式、边界和验收标准；docs/design/：当前设计，不保存过期草案；docs/decisions/：重要方案和修改原因；docs/plans/：跨会话执行计划；docs/debt/：未完成、待校对和缺测试的问题；assets/：按角色、场景、UI 和音频划分的资源目录；skills/：只放输入、输出和验收都稳定的重复流程。
每次让 Agent 工作时，给出目标、现状、约束、验收和验证命令；每次导入 AI 资产时，记录来源、生成参数、编辑步骤和授权边界；每次标记完成时，附上实机证据。
来源与边界
原文尚未完结，本文不补写第 3、4 篇中可能涉及的动画、音频、发布或运营细节。模型名称、工具能力、引擎版本、生成图片质量、商用授权和平台规则都可能变化；执行前请查看当前文档并用自己的项目验证。AI 生成素材必须单独核对第三方模型、字体、音乐、声音和图片的使用许可。