从零用 AI 做独立游戏：一套 Vibe Coding 开发流程复盘
本文根据 Nenly 的 X 长文整理。原文发布于 2026 年 10 月 28 日，标题为《万字复盘：0代码基础，如何用 AI 做出10万人玩过的独立游戏？》，介绍《群侠传：幸存者》的第一阶段开发与上线经验。原文末尾标注“未完待续”，因此本文只整理当前公开的第一部分，不补写尚未公开的后续内容。文中 Steam 评测、玩家数量、Token 消耗和工具效果均属于作者的项目自述，未在本文中独立核验。
这不是“让 AI 写完游戏”
Nenly 复盘的对象，是一款武侠题材的 Survivor-like 独立游戏《群侠传：幸存者》。玩法可以概括为：玩家在江湖世界中移动躲避敌人，角色自动施展武学，通过外功、内功、轻功和道具搭配完成构筑，经历 20 波挑战并进入无尽模式。
原文的价值不在于证明“不会写代码也能一键做游戏”，而在于记录了一个没有游戏开发经验的人，如何把模糊想法拆成需求、文档、原型、资产、验收和迭代。AI 参与了代码、美术、动画、音乐和配音，但作者仍然承担了设计判断、范围控制、测试、反馈取舍和上线后的修复。
兴趣与题材
→ 需求澄清与调研
→ GDD 和项目文档
→ 最小可玩原型
→ AI Coding 与资产接入
→ 人工试玩和验收
→ 发布、反馈与持续迭代
先看项目结果，但不要把结果当成保证
作者称，游戏在 Steam 以免费抢先体验形式上线后，获得了两千多条评测、较高好评率，并有超过二十万次入库；作者还分享了激活数、实际游玩人数、平均时长和同时在线峰值等项目数据。
这些数字是作者的公开自述。它们可能受免费发行、题材、账号受众、上线时间、平台推荐、版本迭代和统计口径影响，不能推导出“使用同样模型或流程就能获得同样结果”。判断一条 AI 游戏工作流是否适合自己，应该看它能否让你稳定地产出、检查和修改，而不是只看一个成功案例的最终数字。
游戏当前的内容规模也说明，AI 生成第一版只是开始：作者列出 153 门武学、247 件道具、55 种敌人、20 波主线、无尽模式、113 个奇遇事件和 61 个 Steam 成就。这样的内容量需要持续的系统设计、数值调整、测试和版本管理。
从兴趣出发，先定义一个可玩的核心
这个项目的灵感来自武侠小说和 Survivor-like 游戏。作者长期游玩《吸血鬼幸存者》《土豆兄弟》等作品，又重新阅读武侠小说，于是把“武学搭配、内功心法和随机构筑”看成天然适合 Survivor-like 的系统基础。
这种起点比“我要做一个什么都能做的游戏”更容易落地，因为它同时给出了：
- 一个熟悉的核心循环：移动、自动攻击、击杀、升级和构筑；
- 一个有辨识度的题材：武侠世界、门派和武学组合；
- 一组可以研究的对标作品：玩法、波次、经济和成长系统；
- 一个能快速验证的最小版本：先让玩家移动、躲怪、攻击、升级并完成一局。
AI 可以帮助补课，但不能代替你决定游戏到底让玩家做什么。第一轮需求最好先把核心体验写成一句话，再确定一局时长、玩家操作、成长方式和失败条件。
让 AI 提问，而不是直接替你设计
作者开始真正制作前，先让 AI 解释游戏开发需要考虑的技能和常见坑，再用提问的方式澄清自己的需求。问题覆盖游戏定位、世界观、角色、武学系统、构筑、地图、局外成长、技术和 MVP。
这个方式适合没有行业经验的人，因为你不需要一开始就写出专业的 GDD，而是逐步回答一组有顺序的问题：
- 核心体验是爽快割草、构筑研究、Roguelite 探索还是养成收集？
- 一局希望持续 10 分钟、15 分钟还是 30 分钟？
- 玩家只移动，还是还要操作闪避、手动绝招或瞄准？
- 第一版必须证明哪个最小可玩闭环？
- 哪些内容属于首发范围，哪些只能放到后续版本？
作者花时间回答这些问题，再让 AI 整理成设计文档包。这里的关键不是一次性生成一份漂亮文档，而是把自己的取舍说出来，让后续代码和资产有一个可以检查的依据。
对标调研要落到系统和数字
作者对《土豆兄弟》等对标作品进行拆解，重点关注玩法、波次、数值和经济系统，并把资料整理成面向自己项目的参考报告。报告进一步建议为每一波建立表格，写清时长、目标体验、刷怪量、期望击杀、期望收入和商店承接。
对标调研可以用下面的模板，避免停留在“这个游戏很好玩”：
| 维度 | 要问的问题 |
|---|---|
| 核心循环 | 玩家每分钟重复什么动作？什么时刻产生奖励？ |
| 波次节奏 | 敌人数量、强度和休息窗口怎样变化？ |
| 成长系统 | 升级、武器、属性和局外成长怎样互相影响？ |
| 经济系统 | 资源从哪里来，什么时候花，是否存在关键断点？ |
| 内容结构 | 一套新武器或敌人需要哪些数据和资产？ |
| 体验目标 | 每个阶段想让玩家紧张、爽快、探索还是决策？ |
然后把结论改写成自己的设计约束。调研资料是参考，不是复制许可；对标游戏的数值和规则也可能随版本变化，正式实现前仍要在自己的原型中验证。
文档要分开记录“想做什么”和“现在是什么”
项目早期只有简单的 docs 目录。随着代码快速推进，设计重新调整、底层重构和功能增加，原有文档开始漂移。作者后来把文档拆成不同用途：
- 设计文档：计划把游戏做成什么样；
- 实现文档：当前代码和系统实际上是什么样；
- 决策记录：为什么选择某个方案，后来为什么改变；
- 开发债务：哪些功能没做完，哪些内容要校对，哪些地方缺测试；
- 入口 README：每份文档的用途、状态和最近变更。
这是一条适用于 AI Coding 项目的通用规则。让 Agent 继续工作时，它需要知道当前约束、上一次做到哪里、哪些问题仍未解决，以及“完成”到底验证到了什么程度。
尤其要避免把旧设计草案继续当成事实。过期文档应该标记、归档或删除；否则 Agent 可能依据历史方案重写已经稳定的代码。
AI Coding：引擎、模型与 Harness 要一起选
作者最终选择 Godot 4，并使用 GPT-5.5、Opus 4.8 等模型配合 Coding Agent。工具选择本身不是成功关键，关键是把模型放在一个有边界的工程环境里：项目规则、文档入口、提交记录、测试方式和运行命令都应该明确。
给 Agent 的需求不能只写“做一个升级系统”。更可执行的任务至少应包含：
目标：完成玩家升级时的三选一界面
现状：战斗循环已有经验掉落，但没有升级暂停
约束：不改变现有武学数据格式，不重做主菜单
验收：经验达到阈值时暂停战斗；显示三个候选；选择后恢复；刷新后状态可保存
验证：启动游戏，模拟升级，截图检查 UI，运行已有测试
作者总结的几条经验也适合直接写进项目规则：
- AI 可以快速写出第一版，但报错定位、验收和范围控制仍需要人负责；
- 先做最小可玩核心，不要先堆几十种武器和完整美术；
- 内容与系统分离，数值尽量数据化；
- 把需求写成目标、现状、约束和验收标准；
- 小步提交，让每一次失败都能回滚。
“许愿式” Prompt 也许能很快生成一个能运行的原型，但原型能运行不等于游戏好玩。作者很快发现，方块和圆圈组成的骨架虽然能跑，却无法让自己持续玩下去。后续的大量工作，都是在骨架上补足手感、内容和反馈。
美术：先统一视觉语言，再批量生产资产
作者把视觉方向描述为带有“伪像素风”和 HD-2D 光影质感的风格，并把视觉语言文档化，用来约束角色、敌人、场景和 UI。
一个适合 AI 游戏项目的资产链路是：
概念稿
→ 风格参考与提示词
→ 角色 / 敌人 / 场景资产
→ 手工抠图、分层和裁切
→ 游戏内尺寸、碰撞和锚点适配
→ 实机截图验收
AI 生成的图片不是可以直接丢进引擎的最终资产。角色可能有多余背景，场景可能需要拆成前中后景，UI 还要考虑九宫格、文字可读性和不同分辨率。真正的生产工作包括清理、命名、导入、尺寸、层级、碰撞和版本管理。
保持一致性的最好办法，不是每次重新描述“看起来像某种风格”，而是维护一份视觉规范：色板、光源方向、线条、材质、角色比例、敌人识别度、UI 间距和禁用的视觉元素。新资产先对照规范，再进入游戏。
动画、特效与 CG：生成素材还要变成可运行资源
原文提到使用视频模型生成绿幕动画，再拆成 2D 序列帧；刀光、冲击波和真气粒子则通过程序化 Shader 设计；剧情 CG 也使用视频模型辅助生成。
这类流程的难点在于“生成”和“接入”之间：
- 绿幕视频需要去背景、裁切、统一帧率和尺寸；
- 序列帧要匹配角色动作、碰撞和播放速度；
- Shader 特效要考虑 GPU 性能、叠加顺序和不同分辨率；
- CG 片段要适配游戏节奏、字幕和文件大小；
- 每个资源都要确认许可范围和商业使用条件。
特效验收不能只看单张图片。需要在真实战斗中检查是否遮挡信息、是否影响目标识别、是否在高密度敌人场景下造成性能问题。
音频与配音也需要统一的设计目标
作者的音频链路包括用生成模型制作 BGM、音效和角色配音，并尝试用核心动机维持 BGM 的听觉一致性。
游戏音频可以分成三层来管理：
| 层级 | 需要统一的内容 |
|---|---|
| BGM | 场景情绪、速度、核心动机和循环点 |
| 音效 | 攻击、受击、升级、稀有事件和 UI 操作反馈 |
| 配音 | 角色身份、情绪、音色、语言和触发时机 |
生成的音频需要导入游戏做循环、响度、延迟和混音检查。声音克隆或参考音色必须取得权利人的明确授权；不能下载他人的公开视频来仿制声音。音乐、音效和配音的模型服务也需要单独确认授权、署名、商用和训练条款。
发布不是最后一步，而是新的反馈循环
作者把 Steam 上架、传包、成就、更新公告和数据看板放在发布与运营环节，并使用数据抓取和多维表格收集玩家反馈，再让 Agent 协助整理归档。
一个可控的发布循环可以是：
版本候选
→ 本地冒烟与完整试玩
→ 发布包检查
→ 更新公告与成就核对
→ 小范围上线
→ 数据与反馈归档
→ 分类、排序和复现
→ 修复、验证、发布下一版本
玩家反馈不要直接变成任务列表。先标记来源、版本、复现步骤、影响范围和可能的解决方案，再决定是 Bug、平衡问题、可用性问题、内容建议还是个人偏好。Agent 可以帮助去重和归类，但是否改变玩法，仍需要开发者结合目标体验和数据判断。
最容易被忽略的是“好不好玩”
作者在早期让 AI 生成了一个能运行的原型，但自己玩不到十分钟就失去兴趣。这个发现非常关键：功能闭环、代码能运行、资产看起来完整，都不能证明游戏成立。
游戏的质量判断至少要分成三层：
- 技术可运行：不崩溃，输入、保存和加载基本正常。
- 流程可完成：玩家知道目标，能完成一局，反馈和奖励能跟上。
- 体验值得重复：玩家愿意继续尝试构筑、学习规则、挑战更高难度。
AI 适合加速前两层的实现，也能提供数值和内容的候选方案；第三层必须通过真实试玩和反馈验证。开发者不能只因为 Agent 说“已完成”就把功能标记为 Done。
一条适合初学者的最小实践路径
如果你也想用 AI 尝试一个独立游戏，可以从一个很小的实验开始：
- 选择一个你熟悉的核心玩法和一个明确题材。
- 让 AI 通过提问帮你写出一页核心体验和 MVP 边界。
- 研究一到两个对标作品，只记录与你的玩法直接相关的系统。
- 建立设计、实现、决策和债务文档，明确当前版本的事实来源。
- 先做一个 5 到 10 分钟可玩的闭环，不先做全量资产。
- 为每个 AI 任务写目标、现状、约束、验收和回滚方式。
- 每加入一类资产，就在真实场景中检查尺寸、性能、授权和一致性。
- 找人试玩，把“无聊、看不懂、太难、太快、想继续玩”记录成可复现反馈。
- 发布小版本，保留版本号、变更说明、反馈和修复证据。
最重要的边界是：AI 可以把想法变成候选实现，人负责选择目标、设置约束、验收结果和承担发布责任。
来源与边界
原文是一篇尚未完结的长文，本文只整理当前已公开部分。Steam 数据、Token 消耗、模型能力、生成素材的版权和商业可用性均未在本文独立核验；实际开发前应查看当前工具条款、引擎文档、商店规则和素材授权。GitHub、Steam 或 AI 工具的可用状态也可能随时间变化。