三份饭盒摆在面前，仓库里的食物却要一起分。给战士多留一点，猎手和法师就少了一点；一块食物的形状不合适，还得腾挪已经放好的位置。《便当勇者传》的战斗，就从这些准备开始。
这是我们六个人在 48 小时 Game Jam 中完成的游戏。两天里，从确定玩法到策划、程序和美术，我们想做出一个能从头玩到尾的版本。最后，市场、食材管理、三名角色的饭盒构筑、自动战斗、关卡推进和 Boss 战都做了出来。借助 AI 开发流程和团队配合，内容量与完成度超过了我们起初的预期。
三份便当怎样变成一套构筑玩法
玩家扮演队伍的后勤大厨，负责开战前的便当准备，勇者进入战场后会自动作战。战士、猎手和法师各有一份饭盒，共享食材仓库。从市场买来的食物，要根据形状拖进饭盒，可以旋转，也可以重新排列。初始饭盒只有 3×3，之后能在 6×8 的范围内继续扩张。每轮买什么、放在哪里，要一起考虑剩下的空间、食材的价格和三名角色各自的需要。
游戏里有 54 种食物和 6 类羁绊。同一种食物，给战士可能是为了提高生存，放进猎手或法师的饭盒里，又会组成另一套搭配。三件同类别食物可以启动羁绊，占用格数还会影响羁绊强度。于是，拼得下只是第一步，角色分工和后面的战斗路线也要在这里考虑。准备结束，三名勇者进入战场，之前的购买和摆放随即体现在伤害、承伤和技能上。我们希望玩家能从这一轮战斗里，看出刚才那几份便当配得如何。
48 小时开发，最先落地的是策划案
三名角色怎样分工，食物怎样分类，羁绊如何触发，市场和掉落怎样连接，这些都要先写下来。AI 写代码很快，没写进文档的规则却只能由它自行理解。同一个需求分到几个开发任务里，很容易就有了几种解释。48 小时的开发，留给这种返工的时间很少。
我们花了不少时间写策划案，把核心循环、系统关系、内容范围、数据格式和验收条件逐项确定下来。必须在这一版完成的内容，与还在考虑的想法分开放。前面把规则写清楚，后面就少了些反复解释和返工。美术拿到界面用途与资源规格后可以开始制作，程序也能按同一份文档并行推进。
从策划文档到可以执行的开发任务
策划案交给 AI 后，先整理成设计说明，确认系统之间的关系，再生成阶段计划。市场、饭盒编辑、食物效果、自动战斗、关卡推进和界面接入，被拆成一项项任务，在 Godot 工程中逐步实现。每项任务写明要改哪些文件、做完后应该出现什么行为、怎样验收。自动检查和人工试玩通过后，再记录进度并提交 Git。
策划案
-> 设计说明
-> 阶段计划
-> 单项实现
-> 自动检查与人工验收
-> 进度日志
-> Git 提交比如“食物可以旋转”，验收时就要把它放进饭盒里试：转过之后有没有越过边界，占格是否正确，重新载入后能否保留状态，界面反馈是否清楚。代码提交以后，这些也要检查完。一次任务处理一个问题，哪里出了错，就能顺着任务找到对应的设计说明和修改记录。
进度日志只追加，不覆盖。Completed 记下这一轮做完的内容，Next 留下可以接手的任务，Blockers 保存还要等策划或其他成员确认的问题，Files Touched 列出改过的文件。两天里，大家会不断切换任务，AI 也会失去上一轮的上下文。再开始一轮开发时，先读最新状态和历史记录，就能接着往下做。出了问题，Git 提交和日志也留着线索，可以回头找出哪项需求、哪轮实现发生了变化。
六个人怎样在两天里配合
我在项目里兼任组长、策划和程序。前期确定开发范围、跟进进度、对接美术需求，把饭盒构筑、角色定位、食物系统和战斗循环写进策划案。文档稳定后，我转去参与核心系统的实现、整合和最终验收。策划、程序和美术按已经确认的文档同时开工，遇到规则冲突，或是需要等另一边的资源时，再由我集中确认怎样取舍，让大家继续按同一套规则往下做。
这次 Game Jam 里，我明显感觉到，工作量带来的压力不像以前那么大了。AI 加快了资料整理、任务拆分和一部分程序实现，我们也因此在两天里尝试了更多内容。沟通却变得更紧：成员之间要尽快确定想法，交给 AI 的资料也要足够准确，否则做得越快，偏离得也越远。
过去能在开发中随口补充的规则，这一次要更早写进文档，连同数据关系、优先级和验收方式一起交代清楚。文档有歧义，错误也会很快进入实现；写得清楚，程序、美术和 AI 就能同时往前推进。《便当勇者传》是我第一次比较完整地用这套方式与团队合作。回头看这 48 小时，前面花在策划案上的时间，省下了后面许多来回解释。