用AI和主动缩减范围三天交付游戏

我是如何刻意缩小范围，最终成功发布一款游戏的。

我之前的项目是一款用 Godot 开发的 RPG。

它每个月都在变得更庞大。

也每个月都离发布更遥远。

终于有一天，我意识到自己已经不是在开发一款游戏，而是在打造一个永远做不完的项目。

于是，我做了一件完全违背直觉的事：主动缩小项目范围，直到自己能够在三天内完成并发布一款商业游戏。

先交代一点背景：我的本职工作是软件工程师，并不是第一次接触编程的业余爱好者。这一点对理解接下来的经历非常重要。

我希望在作品集中再增加一个完整的商业项目——它需要具备真正的项目规模，而不是一个玩具 Demo。原来的 Godot RPG 每次动手都会继续膨胀，所以这一次，我特意选择了另一种类型的项目。

我评估了几个游戏品类，最终选择了卡牌游戏。原因非常现实：

规则已经存在，玩家也已经理解这些规则。

不需要敌人寻路，不需要关卡编辑器，也没有需要调试的程序化生成系统。

即使内容量不大，也依然可以给人完整的体验。

锄大地（Big Two）显然是最合适的选择。

我的目标并不是开发梦想中的游戏，而是重新学会如何把一款游戏真正做完。

梦想中的游戏不会消失，势头却会。

技术栈方面，我选择了能够让我最快推进的方案：HTML5 + Phaser 3 + Vite + TypeScript。并不是因为它们是市面上功能最强大的选择，而是因为我已经足够熟悉，不必再为工具分心，可以直接开始构建游戏。

接着，我编写了一份真正的设计文档——不是什么长篇巨著，只包含足够支撑开发的内容：锄大地的核心玩法与道具系统规则、粗略的故事大纲，以及前两位对手的名字和性格。其他一切都可以在开发过程中逐步演化。

阶段 1：搭建骨架

第一要务是让核心循环可以游玩，并验证它是否真的有趣。

我不断提醒自己一条原则：

如果基础卡牌游戏本身不好玩，那么建立在它之上的一切都毫无意义。

规则引擎最初的繁重工作由 Claude Code 完成。之后，我轮流使用 Codex 和 Copilot，让开发持续推进——并不是什么优雅的多 Agent 策略，而是因为 Agent 的使用额度确实有限。当一个工具的额度用完，又需要继续工作时，自然只能切换到另一个工具。我还始终开着一个网页聊天窗口，用来讨论架构决策。你可以把它想象成一套轮班制度，只不过工作人员是 AI Agent，而决定换班时间的不是时钟，而是速率限制。

在这个阶段，所有视觉资源都是占位素材——简单的图形、图标或 SVG。任何功能都不允许因为等待最终美术资源而停滞。首要任务是确保各个系统真正连接起来：存档与读档、多个结局，以及从头到尾完整通关。如果使用彩色矩形代替美术素材时，我都无法点击操作并走完整个游戏流程，那么后续再多的打磨也无济于事。

美术方面，GPT Plus 已经足够——但 prompt 必须经过精心设计。真正困难的是保持一致性，而不是生成素材的数量。

在生成任何剧情 CG 之前，我先确定了角色设计以及房间和背景的参考图。此后每张新插画都会复用这些参考图，让角色与场景始终保持相同的视觉特征，而不是看起来像把一堆彼此无关的生成图片拼接在一起。

大部分工作并不是生成图片，而是防止视觉风格发生漂移。

举一个具体的例子：我没有逐个生成角色表情，而是将它们一次性生成在同一张 sprite sheet 上，之后再进行切分——同一个角色、同样的光照、相同的风格，各帧之间不会出现漂移。

这个阶段还与另一项我完全无法控制的流程并行进行：itch.io 的发行商入驻，包括收款模式、税务问卷和 PayPal 绑定。这个流程不是靠更加努力就能加速的，所以我尽可能早地启动了它，让它在后台推进，同时继续处理美术素材流水线。

游戏开发不只是编写代码。发布之前，那些枯燥的行政事务同样必须完成。

阶段 3：音频、打磨与调试深坑

音频来自两个渠道：Kenney（CC0 音效）和 StockTune（订阅制音乐，采用公有领域许可）。大部分内容就位后，我实现了画廊与解锁模式，随后跌入了只能用“调试地狱”来形容的境地——逐一追查 BGM 生命周期 Bug、存档状态的边缘情况，以及动画打磨问题。

发布 EXE 并不意味着调试结束，它只是引入了一种全新的 Bug 物种。

我从未打算把它宣传成“一款用三天做出来的游戏”。

临近结束时，我查看了 Git 历史，突然意识到一件事：如果再加把劲，它真的可以在三天内完成。于是我这么做了——当然，也熬了几个夜。

颇具讽刺意味的是，带来最大生产力提升的并不是 AI 代码生成，而是自动化测试。

这才是我真正想推荐给其他独立开发者的部分：HTML5 + AI 辅助开发与 Playwright 的组合效果极佳。自动化浏览器测试大幅减少了我的手动 QA 时间——每一次规则引擎修改、每一次 UI 调整，都会通过真实的浏览器会话完成验证，不必再由我一遍又一遍地手动点击相同的十五个步骤。

自动化测试放大了 AI 生成的一切成果。

不过坦白说，这个项目能够如此迅速地推进，真正的原因根本不是工具，而是我在为自己开发，同时身兼两个角色。

作为玩家，我早就知道自己想要什么样的体验。

一些真正的惊喜。

作为工程师，我也早就知道该如何实现它。

如何组织系统结构。

如何保持代码的可维护性。

如何停止添加新功能。

同时理解这两个方面，意味着我很少会困在“接下来应该做什么”这个问题上。顺带一提，那份设计文档大约花了三个小时完成。此后的一切都是执行，而不是探索。

工具：VS Code、GitHub、HTML5、Phaser 3、Vite、TypeScript、Claude Code、Codex、GitHub Copilot、ChatGPT Plus、Playwright、Electron，以及一个使用 Python + Pillow 编写的小型自定义脚本（asset_builder.py），用于批量将 PNG 转换为 WebP。

音频：Kenney（CC0 音效）和 StockTune（AI 生成的公有领域音乐）。

三天听起来不可能。

直到你查看 Git 历史。

下面是这三天在 Git 中真实呈现出来的样子：

没有什么巨大的飞跃，只有数百个微小的步骤。

回头来看，我认为这个故事真正有意思的地方并不是那三天。

作为玩家，我已经花费多年时间了解自己喜欢什么样的游戏。

作为工程师，我也已经花费多年时间学习如何构建软件。

AI 并没有赋予我这些经验。

它只是让我能够以快得多的速度运用这些经验。

AI 加速了执行。

经验加速了决策。

缩小范围让发布成为可能。

这次实验最终变成了 DULAN：一款剧情驱动的锄大地游戏。每位对手都有自己的房间、音乐、个性和动态响应对话，而你选择的玩法方式会导向不同的结局。

每次 commit 都很小。在提交它们的时候，没有任何一次让我觉得多么重要。

但回头来看，它们并不只是在构建一款游戏。

它们把多年的经验复利叠加，最终变成了一件我真正能够发布的作品。

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。