上图是这款游戏现在的样子。它叫「圣光防线」，是一款竖屏塔防，10 月 25 日开工，到今天是第 5 天：
- 两种玩法：战役模式从第 4 关起程序生成关卡，可以一直打下去；对战模式是 1v1，征兵、拖进坑位、合成升级，合出英雄。
- 全部素材自制：22 个角色和全部场景、界面由 AI 生图，21 个音效和背景音乐用代码合成。
- 能在手机上玩：打包成 13.84MB 的微信小游戏，已经在 iPhone 的微信里跑起来，适配了灵动岛。
- 代码规模：77 个 GDScript 文件、8408 行，另有 573 个测试函数。
这些代码全部由 Claude Code 编写，我没有手写过一行。我做的事是提需求、试玩、拍板，以及处理账号注册、扫码登录这类只能本人做的操作。
这个系列按时间顺序记录它从开工到上线的全过程：开工、玩法、素材、打包、微信小游戏、对战模式、抖音与软著、上线。目前还没有上线，后面几篇会跟着进度写。
本篇讲开工第一天。值得单独拿出来讲的是三件事：AI 开工前先问了什么，引擎定下来之后查出了哪些平台约束，以及为什么在写第一行玩法代码之前，先搭了一套让 AI 检查自己工作的工具。后面 5 天能一直往上加功能，靠的就是这套工具。
开工第一句话：AI 先问了 4 个问题
我对 Claude Code 说的第一句话是：做一个塔防游戏，引擎用 Godot，角色想参考一款老游戏。
它没有直接开写，先提了一个版权问题：那款游戏的角色名字和美术都属于原厂商，如果打算公开发布，就只能借用玩法和题材，名字、美术、数据都不能用。然后用 4 个选择题把范围定下来：
| 问题 | 我的选择 |
|---|---|
| 做出来打算怎么用？ | 公开发布 |
| 美术资源怎么处理？ | AI 生成原创素材 |
| 塔防用哪种形态？ | 路径塔防（敌人沿固定路线走，玩家在路边建造） |
| 第一个可玩版本做多大？ | 最小可玩：1 张地图、3 种塔、8 波亡灵、金币和生命值 |
这 4 个问题看起来普通，后面每个都起了作用。「公开发布」让版权规则从第一天就写进了项目说明：代码、数据、美术和生图 prompt 里都不能出现现有游戏的名字。「最小可玩」让第一天结束时就有一局能完整打完的游戏，后面所有改动都建立在这局游戏上。
Godot 是我定的，AI 查出了平台约束
引擎是我开口就指定的，没有做过横向对比。AI 没有质疑这个选择，它做的是：我说了目标平台是 Steam、微信小游戏和抖音小游戏之后，去查 Godot 在这三个平台上分别是什么情况。查到的结果是：
- 抖音有官方的 Godot SDK，但只支持 Godot 4.5，不支持自定义导出模板，只能单线程运行。项目用的是 4.7。
- 微信没有官方的 Godot 支持，只有社区维护的导出模板，其中一个有 4.7 版本。
- 包体：主包上限 4MB，总包上限 20MB（调研时查到的是 30MB，后来推预览被拒才知道是 20MB）。光 Godot 引擎就要好几 MB（实测压缩后 8.4MB），必须放进分包。
- iOS 上必须开启微信的高性能模式。
- 小游戏环境里没有系统字体，中文字体要自己打包。
AI 的建议是保留 Godot，Steam 版照常做，等三张地图做完，花一两天把游戏导出到真机上验证，验证不通过再考虑换引擎。后来的事实证明这一步是必要的：真机上卡在加载、iPhone 黑屏这些问题，都是在这个阶段才暴露出来，第 5 篇会详细讲。
第二天又定了一件影响全局的事：全平台统一竖屏，电脑上也是一个竖长窗口。画面从 1280×720 改成 720×1280，三张地图全部按竖屏重新排布，顶栏右侧留出微信小游戏右上角胶囊按钮的位置。这个决定越晚做，返工越多。
先搭工具，让 AI 能检查自己的工作
用 AI 写游戏有一个天然的盲区：它看不到画面，也不会亲手玩。代码能编译，不代表游戏能玩；测试全过，也不代表画面没有错位。所以第一天在写玩法之前，先搭了一套让 AI 自己验证的工具，全部做成 make 命令：
| 命令 | 做什么 | 防住的问题 |
|---|---|---|
make test |
跑全部单元测试（GUT 框架），无头运行，失败就返回非零 | 改一处坏一处 |
make lint |
把 GDScript 的警告当成错误 | Godot 命令行默认不打印警告，问题悄悄留在代码里 |
make smoke |
无头启动游戏，8 倍速自动打完一关，出现任何引擎或脚本报错就失败 | 测试覆盖不到的运行时错误 |
make frames |
自动游玩一关，每个游戏秒存一张 PNG | AI 看不到画面 |
前三条是常规做法，但每条都有 Godot 特有的坑。例如 Godot 的命令行从不打印 GDScript 警告，不专门处理的话，警告根本不会出现在 AI 能看到的输出里。make lint 的做法是运行前临时放一个配置文件，把所有警告升级成错误，跑完再删掉。
测试方面，项目规定先写测试再写实现。测试数从第一天的 118 个，一路涨到现在的 573 个。AI 也如实说明了一个限制：GDScript 没有覆盖率工具，所以「80% 覆盖率」这条要求无法度量，只能靠先写测试的习惯来保证。
make frames：让 AI 看到游戏画面
第四条是这套工具里最关键的。Godot 自带的录制功能可以把游戏逐帧输出成图片，make frames 让游戏自动游玩第一关，4 倍速跑 90 秒，每个游戏秒存一张 PNG，一共 91 张。AI 用读图能力逐张看这些图，检查角色有没有站在路上、血条有没有被遮住、特效是不是对的位置。项目说明里写得很直接：这是在命令行里看到游戏的唯一方式。
后面 5 天，改界面和美术时都会用到它。换竖屏那次，AI 还用同样的思路批量截了几种屏幕比例下的界面，逐张检查按钮和菜单有没有出界。
这套工具也会出问题，AI 自己也踩过坑。比如有一次它把 smoke 的输出重定向到了它接下来要读取的同一个文件，读的同时文件在增长，结果陷入了死循环。另一次更严重：它做了一项启动优化，在编辑器里验证通过，但导出成安装包之后，一个数组被引擎清空，点「出征」直接崩溃。这件事之后，打包命令加上了一步：打完包后自动用导出的版本玩一关，检查退出码。第 4 篇会详细讲这次崩溃。
开工第一天的几条做法
| 做法 | 原因 |
|---|---|
| 开工前让 AI 先问清用途、美术来源、玩法形态和第一版范围 | 这些答案决定了版权规则、素材流程和第一天的交付物 |
| 引擎定下后，先查清目标平台的支持情况和包体限制，再排一次真机验证 | 小游戏平台对 Godot 的支持很薄，问题只有在真机上才会暴露 |
| 竖屏还是横屏尽早定 | 越晚改，地图、界面和截图的返工越多 |
| 写玩法之前先搭测试、lint、自动游玩和截帧 | AI 看不到画面也不会亲手玩，这些工具让它能自己发现大部分问题 |
| AI 自己踩过的坑，改成一条自动检查加进命令里 | 同一类问题不会第二次漏过去 |
下一篇讲玩法：我的每一句试玩反馈，是怎么变成无限关卡、局外积累和援军登场这些系统的。