夜雨聆风很多人还在问，AI 到底能不能写代码。
我这次没有继续停留在问答里，而是做了一个更直接的实验：把一份游戏产品文档交给 Codex，让它从零开始做一个中国神话修仙卡牌游戏的 Godot MVP。
几个小时后，它真的跑起来了。
不是只生成一堆脚本，也不是停在「看起来差不多」的界面。这个版本已经有主菜单、角色立绘、塔层路线、战斗、手牌、敌人意图、奖励卡和 Boss。至少作为一个 MVP，它已经能打开、能选择路线、能打牌、能结算。
先看主菜单：
这个项目叫《神域之塔》。设定并不复杂：修仙、登塔、卡牌构筑、Roguelike 路线、像素风战斗。坦白说，它很像很多国产独立游戏最开始会写进文档里的那种想法。
但做过游戏原型的人都知道，从「文档里写得很清楚」到「玩家真的能点进去玩」，中间隔着一大堆细碎工作。
场景要搭，卡牌要能结算，敌人要有意图，UI 要能读，素材要显示正常，胜利失败要能切换场景，测试还得跑通。每件事单独看都不算惊天动地，但堆在一起，很容易把一个原型拖死在半路。
这次我把这些工作交给 Codex，让它一路往前推。
先把游戏跑起来
最开始只有一份产品文档和两张结构图。
一张是 Godot 场景结构图，一张是卡牌管理节点图。文档里有玩法设想，也有美术方向，但项目目录里还没有真正的 Godot 工程。
所以第一步不是做酷炫效果，而是把工程搭起来。
Codex 初始化了 Godot 项目，创建主场景 Main.tscn，搭了主菜单、塔层路线和战斗场景。它还顺手把卡牌、敌人、效果、奖励这些数据结构先放进去，写了单元测试，并安装 Godot 做运行验证。
这一步之后，《神域之塔》已经有了最小可玩闭环：
进入游戏，开始登塔，选择节点，进入战斗，打出卡牌，击败敌人，获得奖励，再推进路线。
这听起来像一句流程描述，但对一个原型来说很重要。因为从这一刻开始，它不再只是文档，而是一个可以被测试、被截图、被继续修改的游戏工程。
卡牌系统先做小，但要完整
MVP 没有一上来就做几十张牌。
先做的是一个很小的初始牌组：
- • 斩击：造成 6 点伤害
- • 护身诀：获得 5 点护体
- • 灵息：抽 1 张牌，获得 1 点能量，并消耗自身
然后补了两张奖励牌：
- • 借风：获得 1 点能量
- • 天雷符：造成 10 点伤害，并施加封印
数量不多，但该有的类型已经覆盖了一圈：伤害、防御、抽牌、回能量、消耗、状态施加。
战斗系统也一起搭出来了。抽牌堆、手牌、弃牌堆、消耗堆、能量、护体、敌人 HP、敌人意图、战斗日志、胜利结算、奖励选择，这些都不是「以后再说」的占位，而是能在一局战斗里串起来的系统。
做到这里，游戏已经可以打牌了。
截图一出来，问题就藏不住了
第一次跑起来的画面，其实挺粗糙。
主角 sprite sheet 被整张显示出来，角色看起来像贴了一条横向动作条。卡牌只有框，没有插画。敌人血量像普通文字一样压在背景上。战斗日志堆在右侧。有些中文换行还显示成了 \n。按钮、卡牌、日志都能用，但整个界面还不像一个游戏。
这也是我这次感受很深的一点：代码跑通只是第一步，截图能看才算进入真正的游戏开发。
后面几轮基本都围绕截图修。
顶部状态栏不清楚，就做 HP、护体、能量条。敌人状态不突出，就加敌人 HP 条和意图图标。手牌区太散，就加底部手牌托盘。日志不稳定，就做成战斗记录面板。卡牌没有素材，就补卡牌插画。
这个过程不浪漫，但很真实。它不像演示视频里那样一句 prompt 直接变成完整游戏，更像有人盯着截图一点点挑毛病，然后让 Codex 接着修。
素材从「能显示」改到「能看懂」
一开始的美术素材来自一张完整资产表。
这能临时解决问题，但限制也明显：素材没有拆开，很多图像带底色，尺寸和比例不稳定。能显示，不等于适合放进游戏里。
后面改成单独生成和整理素材。
主角拆成云游剑修立绘、待机动作、攻击动作、受击动作、死亡动作。敌人单独做了山魈、石傀儡和饕餮残影 Boss。背景也分成凡界裂土、幽冥回廊、云海仙庭。UI 则单独处理卡牌框、敌人意图图标、状态图标、地图节点图标、按钮和面板。
最后补上的，是卡牌插画和 Boss 战相关截图。
这一步很关键。
卡牌游戏里，卡牌不是普通按钮。没有插画时，玩家看到的是功能块；有了插画，才会开始把它当成一张牌。
斩击有剑光，护身诀有护盾，灵息有灵气，借风有风旋，天雷符有雷符。虽然还只是 MVP，但世界观的味道已经出来了一点。
真正麻烦的 bug，通常藏在「能运行」之后
开发过程中还遇到一个很典型的 bug。
敌人 HP 已经归零，日志也显示「战斗胜利」，但界面还停在战斗场景，按钮也没法继续点。
这种问题第一眼很像 UI 卡住了。实际根因在战斗状态刷新顺序。
卡牌打死敌人后，battle_finished 已经触发，按理说应该进入奖励界面。但后面又触发了一次 state_changed，把界面刷新回战斗画面。于是看起来就变成了「赢了，但卡住了」。
修复方式并不复杂：胜利或失败后，战斗管理器停止继续刷新战斗 UI，让 battle_finished 专门负责切换到奖励或失败界面。
同时补了回归测试：击杀敌人后 battle_finished 会触发，state_changed 不再追加触发，界面也不会回到无效战斗状态。
这一步让我更确定，MVP 不是「能打开」就结束了。真正可玩的感觉，往往来自这些不起眼的状态修复。
现在这个 MVP 已经有什么
当前版本已经包含主菜单、素材预览、塔层路线、战斗节点、事件节点、商店节点、休整节点和 Boss 节点。
战斗部分有回合制卡牌流程、敌人意图、战斗日志和奖励选牌。素材部分也已经覆盖主角、敌人、Boss、背景、卡牌和 UI。工程侧还有 Godot 单元测试，以及自动截图验证脚本。
换句话说，它已经不是一堆散装功能，而是一条能跑通的游戏原型生产链路：从文档到工程，从工程到闭环，从闭环到截图，再从截图回到 UI 修正和 bug 回归测试。
这次真正让我意外的地方
AI 写代码本身已经不算新鲜了。
这次更有意思的，是 Codex 能连续推进一个复杂目标：读产品文档，拆计划，建工程，写系统，生成素材，跑测试，看截图，修 UI，补 bug，再提交版本。
游戏开发里最耗人的，常常不是某一个特别难的算法，而是大量中间态工作。它们琐碎、重复、需要耐心，而且经常要在「差一点能玩」和「真的能玩」之间来回磨。
Codex 这次的价值就在这里。它没有替我做最终审美判断，也没有替我决定游戏到底好不好玩；但它把那些原本容易卡住的中间步骤持续往前推，直到项目真的跑起来。
接下来还可以继续做什么
这个版本还只是 MVP，但已经值得继续迭代。
我会优先考虑几件事：出牌时切换角色攻击动作，受击时播放受击动作；加伤害飘字和屏幕震动；扩充更多卡牌和状态组合；把奖励、商店、休整界面再整理一遍；最后加上音效和背景音乐，做一次可试玩打包。
如果继续推进，它有机会从技术原型变成一个观感更完整的小型试玩 Demo。
结语
这次实验让我更确定一件事：个人开发者和独立游戏团队启动项目的方式，正在变得不一样。
以前我们常常先写设定、画结构图、列需求，然后花很久才搭出一个能玩的原型。现在可以把文档、设定和参考图先交给 AI，让它把最初那段最难熬的工程搭建和闭环验证先跑起来。
当然，游戏开发不会因此变简单。方向判断、玩法取舍、审美和手感，最后还是要人来负责。
但从 0 到 1 的阻力，确实小了很多。
《神域之塔》这次最重要的成果也很朴素：它从一份文档，变成了一个能打开、能战斗、还能继续迭代的游戏。
