《便当勇者传》是我们六个人在一次 48 小时 Game Jam 中完成的作品。两天时间里，我们要从空白开始确定玩法，完成策划、程序和美术，最后交付一款能够从头玩到尾的游戏。时间虽然很紧，但我们并不想只做一个验证创意的原型。借助 AI 开发管线和团队之间比较紧密的配合，最后完成的版本已经包含市场、食材管理、三名角色的饭盒构筑、自动战斗、关卡推进和 Boss 战，内容量与完成度都超过了我们最初对 48 小时作品的预期。
三份便当怎样变成一套构筑玩法
玩家在游戏中扮演队伍的后勤大厨，不直接控制勇者战斗，而是在开战前准备便当。战士、猎手和法师分别拥有一份饭盒，三个人共享食材仓库。玩家从市场购买食物，再根据形状把它们拖进饭盒。食物可以旋转和重新排列，初始饭盒只有 3×3，之后可以在 6×8 的范围内继续扩张。有限空间、食材价格和三名角色的定位共同决定了每一轮应该买什么、放在哪里。
游戏里一共有 54 种食物和 6 类羁绊。同一种食物给战士可能用于提高生存，放进猎手或法师的饭盒里又会进入另一套构筑。三件同类别食物可以启动羁绊，羁绊强度还会继续受到占用格数影响。玩家需要一边处理形状拼接，一边考虑角色分工和后面的战斗路线。准备完成后，三名勇者自动进入战斗，之前的购买和摆放会立刻反映在伤害、承伤和技能表现上。我们希望自动战斗不是一段与玩家无关的播放，而是对上一阶段构筑结果的检查。
48 小时开发，最先落地的是策划案
AI 可以很快写出一段代码，但它并不知道我们脑中没有写下来的规则。三名角色怎样分工、食物怎样分类、羁绊如何触发、市场和掉落怎样连接，如果这些问题只停留在口头讨论中，同一个需求在不同开发任务里很容易得到不同解释。Game Jam 的时间越短，这类偏差越难留到后面再修。
因此我们花了不少时间先把策划案写完整。文档不仅描述创意，也明确核心循环、系统关系、内容范围、数据格式和验收条件。哪些内容是这一版必须完成的，哪些只是可能加入的想法，也要提前分开。这样做看起来占用了宝贵的开发时间，实际减少了后面反复解释和返工的次数。美术可以根据确定的界面职责与资源规格开始制作，程序也能沿着同一套规则并行推进。
从策划文档到可以执行的开发任务
策划案完成后，AI 不会直接对整个 Godot 工程做一次大改。它先读取策划文档，把其中的系统关系整理成设计说明；设计说明确认后，再生成阶段计划，把市场、饭盒编辑、食物效果、自动战斗、关卡推进和界面接入拆成单项任务。每个任务都会写明要修改的文件、预期出现的行为和验收方式。实现完成后先做自动检查与人工试玩，通过后记录进度并提交 Git。
策划案
-> 设计说明
-> 阶段计划
-> 单项实现
-> 自动检查与人工验收
-> 进度日志
-> Git 提交这条流程让资料、实现和结果能够互相对应。比如“食物可以旋转”不能只以代码已经提交作为完成标准，还要检查旋转后的形状是否仍然符合饭盒边界、能否正确占格、重新载入后是否保持状态，以及界面是否给出清楚反馈。一次任务只解决一个明确问题，出现错误时也比较容易退回到对应的设计说明和修改记录。
进度日志采用只追加、不覆盖的方式。Completed 记录这一轮已经完成的内容，Next 指出接下来可以接手的任务，Blockers 保存仍需策划或其他成员确认的问题，Files Touched 标出实际改过的文件。48 小时里，成员会不断切换任务，AI 的执行上下文也不会永久保留。新的开发轮次先读最新状态和历史记录，就能知道项目现在位于哪里，不必依赖上一段对话或某个人的记忆。遇到问题时，我们也可以从 Git 提交和日志中找到它从哪项需求、哪轮实现开始发生变化。
六个人怎样在两天里配合
我在项目中同时承担组长、策划和程序工作。前期主要负责确定范围、跟进开发进度并对接美术需求，同时把饭盒构筑、角色定位、食物系统和战斗循环写进策划案。文档稳定以后，我把工作重心转到程序开发，参与核心系统的实现、整合和最终验收。策划、程序和美术并不是依次等待上一环节完成，而是围绕已经确认的文档并行工作；出现规则冲突或资源依赖时，再由我集中确认取舍，避免不同成员各自做出一套解释。
这次 Game Jam 最明显的感受，是单纯的工作量不再像以前那样容易成为瓶颈。资料整理、任务拆分和一部分程序实现可以由 AI 加速，团队能够在 48 小时内尝试更丰富的内容。但节省下来的时间并不会自动变成成品，新的压力落在了沟通上：人与人之间要迅速对齐，人与 AI 之间也要使用足够准确的资料建立同一种理解。
这也提高了策划文档的要求。过去有些可以在开发过程中口头补充的内容，现在需要提前写清楚规则、数据关系、优先级和验收方式。文档存在歧义时，AI 只会更快地做出错误实现；文档结构清楚时，程序、美术和 AI 才能真正并行。对我来说，《便当勇者传》不只是一次在 48 小时内完成游戏的经历，也是第一次比较完整地体验这种新的协作方式。