借助 Codex 独立做游戏 · 开发复盘

战斗还没做完，
我先给 Riftkeeper 搭了一条可测试的入口

一次使用 Codex 的真实问题记录：范围、动态加载、过期测试和安全操作。

上一篇确定了《Riftkeeper》的美术、UI 和玩法方向。这次，我准备借助 Codex 开始搭建战斗模块。

最初的目标并不复杂：从主界面进入 battle 模块，显示战斗 HUD，并为后续胜利和失败准备结算入口。

真正做下来，我发现最值得记录的不是增加了多少脚本和 Prefab，而是使用 Codex 时遇到的几个问题。

● AI 给出的方案很完整，却可能超出当前范围；

● 我说“动态加载”，它理解的结果和我想要的不一样；

● 测试失败不一定代表新代码错误，也可能是旧测试已经过期；

● 涉及 Git 删除时，不能直接相信一条看起来正确的命令。

01. 方案很完整，但不是我现在需要的

当我提出“搭建战斗入口”时，Codex 很快把战斗模块拆成了配置、状态机、ECS、怪物、武器、商店、事件、HUD 和结算等完整架构。

从长期来看，这些建议并没有明显问题。但当前阶段，我只想完成一条最小路径：

主界面 → 加载 battle bundle → 打开战斗场景 → 显示 BattleUI → 预留结算入口

如果继续按照完整方案开发，任务很快就会扩大到怪物移动、武器伤害、商店交易、格子合成、波次、奖励和存档。文件越来越多，却不一定更接近第一个可验证结果。

AI 负责展开可能性，人负责决定当前最需要的是什么。

我的解决方法：同时写清“必须做”和“明确不做”

本次必须完成

● 主界面进入 battle 模块；

● battle bundle、BattleUI 和 SettlementUI；

● 加载失败与重复点击处理。

本次明确不做

怪物移动、武器伤害、购买、放置、合成、真实胜负判定、奖励发放和存档。

我还要求 Codex 在结束时分别列出：已经实现、只完成设计、仍然缺失和尚未验证。这样，设计文档里出现的系统就不会被误写成已经完成的功能。

02. 我说“动态加载”，Codex 理解得不够具体

最初的部分方案和测试，默认把 BattleStage 与 SettlementUI 直接放在 battle.scene 中。但我希望场景只保留 Canvas、Camera 和 WorldRoot，战斗舞台在进入时创建，结算界面只在产生结果后加载。

我一开始只说了一句：“代码可以动态加载。”现在回头看，这句话仍然有很大的解释空间。

动态加载不只是代码打开界面，还包括创建时机、失败恢复和退出释放。

我的解决方法：把技术名词改成生命周期

进入战斗：加载 bundle → 运行 scene → 创建 BattleStage → 打开 BattleUI；

产生结果：再加载 SettlementUI，不在 UI 层伪造奖励；

退出战斗：停止逻辑 → 取消异步任务 → 关闭 UI → 回收节点 → 释放资源。

目前 BattleStage 的运行时实例化仍未补齐，相关旧测试也还没有完全同步。因此，这部分只能写成“方向和部分入口已经确定”，不能写成“动态加载已经完成”。

03. 测试失败，不一定代表新代码错了

本次重新运行了战斗入口、HUD、资源、结算和主界面相关测试：

45 项测试

通过 41 项　·　失败 4 项

如果只告诉 Codex“把测试全部修绿”，它很可能直接修改当前代码去迎合旧断言。但检查后发现，失败项并不是同一种问题：

测试是证据之一，但测试本身也可能保留旧假设。

● 两项仍要求场景中固定存在 BattleStage 和 SettlementUI；

● 一项仍期待 MainUI 中已经不存在的 startLabel；

● 一项仍在查找旧主界面标题图片的 .meta 路径。

我的解决方法：先诊断，不立即修改

确认当前需求 → 检查真实代码、Prefab 和资源 → 找出测试依赖的旧假设 → 判断属于实现错误、测试过期还是环境问题 → 再决定修改哪一侧。

不能为了让数字变成全绿，就把已经确定的动态场景方案改回去。

04. 一个小错误，不应该变成一次大重构

检查 LoadingUI 时，发现重试逻辑中存在一个当前作用域并不存在的调用：

formatLoadingLabel(0)

项目中真正存在的接口属于 LoadingStartupFlow 静态类。但检查重试状态后，我确认这次标签赋值没有继续保留的必要。

最终只删除了这一行，没有借机重写整个 Loading 流程。修改后，应用检查、框架构建和 git diff --check 均通过。

使用 Codex 修复局部问题时，先找根因和最小安全修改，
不要顺带重构无关流程。

05. 让 Codex 执行 Git 删除时，必须先确认目标

清理旧战斗工作树时，Windows 返回了 Invalid argument。最危险的处理方式，是看到命令失败后马上换一个更强制、范围更大的删除命令。

AI 可以给出候选操作，但删除范围必须由人确认。

我的解决方法：先进行只读核对

● 工作树真实目录是否存在；

● 是否存在未提交修改；

● Git 是否只剩目标工作树的元数据；

● 本地和远端分支分别指向哪个提交。

确认真实目录已经消失，只剩精确目标的 worktree 元数据以后，才继续清理对应记录和分支。

06. 我现在怎样向 Codex 提开发需求

经过这次开发，我把后续任务的提示词整理成了一个固定框架：

请先检查当前项目状态，再开始实现。

本次目标：[唯一主要目标]

本次必须完成：[明确清单]

本次明确不做：[负面清单]

完成后分别输出：实际修改、真实问题、定位依据、修复方式、通过验证、失败验证和尚未执行的
 Editor/设备/E2E 验证。

这个提示词不会让 Codex 写得更快，却能明显减少范围扩张、错误假设和“看起来已经完成”的情况。

07. 这次真正完成了什么

本次完成了主界面到 battle 模块的入口、battle bundle 与资源路径、BattleUI 静态 HUD、SettlementUI 的胜败展示和回调边界，以及重复点击和部分加载失败处理。

仍未完成 BattleStage 运行时创建、战斗 Domain 和 ECS、怪物移动、武器伤害、购买放置、合成、真实胜负、奖励发放和存档。

应用 TypeScript 检查通过，git diff --check 返回 0，但相关测试仍有 4 项失败；同时还没有执行 Cocos Creator Game Preview、设备运行和完整端到端验证。

这次最准确的结论

Codex 没有帮我完成战斗系统。我是在搭建战斗入口的过程中，逐渐学会怎样限制范围、纠正错误假设、判断测试是否过期，以及怎样在危险操作前保留人的最终确认。

下一步

下一步，我会让 Codex 在现有入口上实现一个真正可验证的纵向切片：

一波怪物 → 一种武器 → 一次购买和放置 → 怪物沿路径移动 → 武器造成伤害 → 产生胜利或失败 → 打开结算界面

下一篇不会重点记录“又增加了多少文件”，而会继续记录 Codex 是否正确理解了路径、状态和验证结果。只有把问题、判断依据和修复过程留下来，这个系列才不只是开发流水账。