《便当勇者传》是什么

《便当勇者传》是一款融合饭盒空间构筑与自动战斗的独立游戏。玩家不直接操控勇者的一招一式，而是作为队伍的后勤大厨，在战斗前购买食材、规划饭盒空间，并分别为战士、猎手和法师准备便当。三名角色拥有不同的生命、攻击和战斗定位，同一种食材放在不同角色的饭盒中，会形成完全不同的构筑结果。

游戏的核心循环是：市场采购 → 三份饭盒摆盘 → 自动战斗 → 获得金币与掉落 → 继续构筑 → 挑战 Boss。三名角色各自拥有一份独立饭盒，但共享同一个食材仓库；饭盒从 3×3 起步，可以通过拓展块在 6×8 的范围内继续扩张。食物拥有不同形状，可以拖拽、旋转和重新排列。完整内容包含 54 种食物与 6 类食物羁绊，玩家需要同时考虑有限空间、食材类别、角色定位和后续战斗路线。

玩家通过食材与饭盒构筑影响勇者的战斗表现，而不是在战斗中直接下达每一个操作。

在市场界面中，玩家一边观察三名角色当前的属性，一边从商品与背包中挑选食材，再把它们放入合适的饭盒。三种同类别食物可以触发羁绊，羁绊强度还会随该类别占用的总格数继续成长。自动战斗因此不是脱离玩家的演出，而是对上一阶段构筑决策的即时检验。

市场、共享背包、三名角色状态与饭盒编辑集中在同一界面，玩家的主要决策都发生在开战之前。

把策划案改写成 AI 可执行的“项目操作系统”

这个项目对我而言更重要的实验，是如何让 AI 真正进入游戏开发流程，而不是只在零散环节生成一段代码。项目开始时已有主策划案、食物清单、数值修订和持续补充的需求，但这些资料的职责并不相同：有些描述设计目标，有些提供具体数值，有些仍然包含待定内容，还有些会被更新指令覆盖。如果把所有资料直接交给 AI，它可以很快产出结果，却很难保证每一轮都使用相同的规则解释项目。

因此，我首先做的不是要求 AI 开发功能，而是把策划资料标准化。我将原始内容整理成一组职责清楚的文档：项目简报负责定义游戏身份与资料优先级，核心循环负责说明最小可玩闭环，范围与优先级文档负责控制阶段目标，系统规范与内容目录负责承载玩法和数值，UI 规则与 Godot 开发模式负责约束实现方式，AI 开发规则则专门说明哪些事可以执行、哪些情况必须暂停提问。最后再用验收清单和进度日志把“做什么”连接到“怎样证明做完了”。

这套文档更像项目的操作系统，而不是一份被动保存的策划案。它先规定唯一事实来源：最新确认的直接指令优先于本地补充，更新后的策划资料优先于早期派生内容；当资料出现冲突数值、待定项、缺失表格或多种合理解释时，AI 必须先提出问题，不能用行业常识静默补全。它也明确禁止 AI 为了快速完成而自行砍功能、修改数量、替换规则或扩大范围。这样一来，AI 的执行速度仍然被保留，但每次执行都落在我提前划定的设计边界内。

标准化还解决了交接问题。每次开始新的开发轮次，接手者都要先读取项目简报、范围、系统规范、UI 规则、引擎规则、AI 开发规则和最新进度，而不是依赖上一轮对话里可能已经丢失的上下文。策划更新也不再只停留在聊天记录中：新决定需要同步回规则文档、验收项和实际实现。项目知识因此从“某个人记得”变成了所有后续工作都能重新读取的项目资产。

从拆分到开发：每一步都留下证据

文档标准化之后，AI 才进入任务拆分与开发。整个流程可以概括为：

标准化策划 → 设计说明 → 分阶段实现计划 → 单项开发 → 自动检查与人工验收 → 进度日志 → Git 提交

AI 不直接从宏观需求跳到大规模改动，而是先根据策划包输出设计说明，确认目标、范围、数据关系和界面职责；设计通过后，再生成可以逐项执行的阶段计划，把市场、饭盒编辑、食物效果、自动战斗、关卡推进、存档和 UI 等内容拆成更小的开发任务。每个任务都需要指向明确的文件、预期行为和验证方式。这样的拆分让我能在实现开始前发现理解偏差，也让一次失败只影响当前任务，而不会把整个工程一起拖入难以回退的状态。

开发记录采用固定格式并且只追加、不覆盖。每个重要节点都要写下 Completed、In Progress、Next、Blockers、Files Touched 和 Notes：这一轮完成了什么、正在处理什么、下一步是什么、是否存在待确认问题、实际修改了哪些文件，以及有哪些需要交接的判断。如果遇到资料歧义，问题必须明确进入 Blockers，而不是在代码中留下一个没有说明来源的临时决定。后来的人或新的 AI 轮次只要查看最新状态和历史记录，就能沿着文档找到某项功能为什么出现、在哪一步发生变化。

饭盒构筑最终会在自动战斗中接受检验；开发流程同样要求每个实现结果都回到可观察、可核对的行为。

可追溯不只依靠文字。项目从 2026 年 3 月 28 日初始化，到 5 月 17 日的修复迭代，共保留了 129 次 Git 提交；工程内沉淀了 3 份专项设计说明和 7 份阶段实现计划，测试目录中还有 33 个面向具体行为的运行器，分别覆盖饭盒拖拽、食物效果、战斗掉落、战役推进、存档、设置、UI 与数值编辑工具等环节。这些数字并不等于“所有内容永远不会出错”，但它们证明每次修改都有可以回看的上下文、实现记录和验证入口。

借助这套流程，AI 逐步参与完成了三角色饭盒、食材拖拽与旋转、六类羁绊、市场、自动战斗、固定冒险路线、存档、界面组件和数值编辑工具，并最终形成实机演示与 Windows 发布包。重点不是 AI 一次生成了多少代码，而是每个阶段都能回答三个问题：依据是什么、改了什么、怎样确认结果。

我作为组长兼策划/程序做了什么

我在项目中同时担任组长、策划和程序。作为组长，我负责确定范围、资料优先级与阶段目标，把工作拆成可对齐的里程碑，组织成员定期同步进度，并在需求、资源和实现发生冲突时做出取舍。AI 可以帮助快速整理信息和执行任务，但什么时候继续、什么时候暂停提问、什么内容属于当前版本，仍然需要一个明确的负责人判断。

作为策划，我不只负责提出“饭盒构筑加自动战斗”的创意，还要把它写成可执行的规则：三名角色如何分工，三份饭盒怎样扩展，54 种食物如何进入统一分类，羁绊怎样触发，市场、掉落、休整与 Boss 路线如何连接。更重要的是，我把这些规则继续转译为来源优先级、禁止假设项和验收标准，让 AI 知道哪些内容可以根据现有资料直接推进，哪些内容必须由我确认。

战士、猎手与法师承担不同的战斗职责，饭盒构筑需要围绕角色定位分配有限食材。

作为程序，我参与 Godot 工程的核心系统实现与整合，负责让策划规则真正落到可运行的市场、饭盒、战斗、关卡与界面中，也负责定位跨模块问题并检查 AI 产出的实现是否符合项目约束。我的工作因此不是把任务完全交给 AI，而是同时维护策划、工程和验证三条线：策划决定正确方向，工程保证功能能够运行，验证负责确认二者没有在快速迭代中逐渐分离。

复盘：AI 加速的前提是标准化与可验证

这次开发让我更加确定，AI 游戏开发的起点不是一条足够复杂的提示词，而是一套清晰、分层并且能处理冲突的项目标准。策划文档如果无法说明信息来源、范围边界和待定项，AI 只会更快地放大歧义；任务计划如果没有明确验收方式，快速完成也可能只是把返工推迟到集成阶段。

项目过程中当然仍然会遇到跨系统联动、界面迭代和行为一致性等技术问题，但我没有把解决方案建立在某次对话的临时记忆上，而是尽量把它们重新纳入设计说明、任务计划、进度日志、测试与版本记录。这样处理之后，一个问题不只获得一次修复，也为下一轮开发留下了可以复用的上下文。

AI 带来的变化，并不是让人的角色消失，而是让人的工作重心发生转移：从逐项执行，转向定义目标、整理规则、维护上下文、处理歧义和承担最终判断。对我而言，《便当勇者传》不仅是一款围绕饭盒与食物构筑展开的游戏，也是一次把策划、组织、程序和 AI 协作连成完整生产流程的实践。只有当每一步都能够被解释、检查和回溯，AI 的速度才会真正转化为项目进度，而不是无法说明来源的黑箱结果。