面向独立游戏开发学习者的 AI Game Development Workflow

AI 发展非常迅速，近一段时间也出现了许多使用 Codex、Claude Code 等 AI 编程工具进行独立游戏开发的开发者。很多项目可以直接通过 vibe coding 的方式快速推进，甚至在很短时间内做出一个可运行的原型。

但对于想学习游戏开发思路的独立开发者或学生来说，直接 vibe coding 出来的代码并不一定适合学习。代码虽然能跑起来，但开发者往往还需要重新花大量时间去理解结构、系统划分和实现思路，也不容易在过程中养成自己的工程搭建能力。

另一种方式是启用“教练模式”，让 AI 一点点给出代码、一点点解释实现。但这种方式也有明显问题：它会大量占用上下文窗口。项目进行到一半时，可能会出现上下文污染、开发进度不清晰、任务边界模糊等情况。开发者也容易不知道自己离第一版可玩的 Demo 还有多远。

基于这些问题，我自己研究并整理了一套 Codex Skills 作为游戏开发辅助流程，并附上了对应的使用方式。

这套流程没有被直接做成自动化工作流，原因是它的目标并不是让 AI 完全代替开发者完成项目，而是帮助起步阶段的独立游戏制作人或学生，在 AI 辅助下学习如何梳理想法、拆分系统、规划 MVP，并逐步培养整体工程思维。

整体流程

我将整个开发流程拆成了 5 个部分。严格来说，前 3 步属于设计与规划阶段，第 4 步和第 5 步更偏向开发过程中的项目状态维护和阶段性自检。

推荐顺序如下：

IdeaToGDD
  -> GDDToArchitecture
  -> ArchitectureToRoadmap
  -> DevLogger
  -> ProjectReviewer

对应会形成或维护以下核心文档：

GDD.md
Architecture.md
Roadmap.md
ProjectMemory.md

1. Idea To GDD

游戏开发首先需要有一个大体思路。但对于新手来说，最开始的想法往往是混乱的：可能只有一个核心玩法、一个美术风格、一个世界观片段，或者几个零散的系统设想。

这个阶段可以先和 Codex 或其他 AI 工具进行讨论，发散思维，围绕游戏玩法、功能、画风、玩家目标、核心循环等内容进行探索。随后将这些讨论上下文交给 Codex，并使用 IdeaToGDD 这个 Skill，将零散想法整理成一份 GDD.md。

GDD 即 Game Design Document，也就是游戏设计文档。它会帮助开发者把一开始模糊的想法收束成更稳定的设计内容，并给出一些 Open Questions，用于提醒开发者还有哪些关键问题尚未确定。

当这些待确认问题逐步明确后，我们就可以得到一份完成度较高、结构较完整的游戏设计文档 GDD.md。这份文档会成为后续架构拆分和开发规划的基础。

2. GDD To Architecture

在得到 GDD.md 之后，可以继续使用 GDDToArchitecture，将游戏设计文档转换成顶层技术架构设计。

这一步的目标是帮助开发者理解：为了实现当前设计，项目大概需要哪些系统、模块、数据结构和接口依赖。它会将玩法层面的需求进一步拆分为技术层面的结构，最终形成 Architecture.md。

Architecture.md 主要负责描述：

• 模块划分
• 模块边界
• 数据流
• 接口依赖
• 技术风险
• 技术债
• 待确认的技术问题

如果项目使用了某个特定框架，也可以将框架接口文档作为输入，让生成的架构设计尽量符合当前框架的逻辑。

开发者需要阅读并确认这份架构文档。如果整体架构思路没有太大问题，就可以继续进入下一步。

3. Architecture To Roadmap

ArchitectureToRoadmap 的作用是将 Architecture.md 转换成 MVP 开发路线图，也就是 Roadmap.md。

这里的 Roadmap.md 并不是详细任务清单，也不是一步一步的开发教程。它更关注项目从 0 到最小可行产品的阶段路径，帮助开发者明确每个阶段要完成什么、做到什么程度才算完成。

Roadmap.md 中通常会包含：

• 项目的不同开发阶段
• 当前阶段需要处理的内容
• 阶段目标
• 阶段交付物
• 验收标准
• MVP 范围
• 暂时不做的内容

这份文档会成为 AI 辅助开发过程中较为确定的来源之一。后续开发时，开发者可以通过 Roadmap.md 确认自己目前处于哪个阶段、已经学习和完成了哪些内容、距离第一版可玩的 Demo 还有多远。

对新手来说，这一步非常重要。它可以避免项目一开始就无限扩张，也能让开发过程拥有更清晰的节奏。

4. DevLogger

严格来说，DevLogger 不属于前面的设计流程。到 ArchitectureToRoadmap 为止，设计和规划阶段已经基本结束。

DevLogger 更适合在开发过程中使用。例如：

• 当前窗口上下文已经很多，需要切换到新窗口
• 完成了某个阶段性任务
• 项目状态需要总结和沉淀
• 需要让新对话快速理解当前项目进度

调用 DevLogger 后，它会维护一份 ProjectMemory.md。这份文档不是日报、周报，也不是简单记录“今天做了什么”。它更像是项目的长期上下文记忆。

ProjectMemory.md 通常会记录：

• 当前项目已经完成了什么
• 已经实现的接口和模块
• 关键方法和技术决策
• 历史架构变化
• 当前仍未完成的内容
• 开发过程中暂时搁置、需要以后处理的问题
• 当前项目阶段和下一步建议

这样做的好处是，当开发者开启新窗口或隔一段时间回到项目时，可以通过 ProjectMemory.md 快速恢复上下文，不需要重新翻阅大量历史对话。

5. ProjectReviewer

当项目逐渐变大，或者经过一段时间开发后发现项目可能已经偏离最开始的路线时，可以使用 ProjectReviewer 进行一次项目自检。

这一步会结合项目中的核心文档和实际代码状态，对项目进行阶段性评审。它主要关注：

• 各文档之间是否一致
• 当前实现是否偏离原始架构
• MVP 是否存在风险
• 项目范围是否膨胀
• 技术债是否已经影响后续开发
• 当前项目推进情况是否清晰
• Roadmap 是否仍然合理
• ProjectMemory 是否需要更新

通过这类自检，开发者可以根据结果重新规划开发路径，调整流程，或者修改架构文档和开发路线图，尽量保证项目仍然朝着可完成的方向推进。

结语

本项目目前仍处于个人学习与实践阶段。这些 Skills 主要来源于我在使用 AI 工具学习游戏开发过程中的探索与总结。

这套流程的可靠性仍在验证中，可能存在设计缺陷、流程冗余或不适用于部分项目的情况。因此，它更适合作为游戏开发初学者、独立开发者或学生的参考，而不是一套必须严格照搬的标准流程。

欢迎大家根据自己的项目实际情况进行修改、拓展与迭代。

项目已放在我的 GitHub 上。如果这个项目对你有帮助，也欢迎点一个 Star 支持一下作者：

https://github.com/anliuyu71/AI-Game-Development-Workflow