从零制作一个 AI 游戏（02. 垂直切片）
从想法到可玩的第一步。
现在我们要把想法落地成一个最小的可玩游戏，看着它一步步演变成我们想要的样子。
这一步尽可能使用好一些的 AI 模型。
我们需要借助好的 AI 模型把抽象的游戏设计落地成一个小的游戏原型，依靠这个游戏原型来快速发现问题。
首先，我们要根据游戏大纲规划第一个垂直切片。
什么是垂直切片？垂直切片是指一个游戏中最小的可玩游戏。
它是最简单的一次游戏过程，比如从开始游戏 -> 游戏过程 -> 结束游戏。
下面，我们让 AI 根据《游戏大纲规划.md》规划第一个垂直切片。（复制下面内容，直接丢给 AI）
根据《游戏设计大纲.md》规划第一个垂直切片，生成一份规划文档:《垂直切片规划.md》。
## 唯一目标
大纲里那句"一次迭代屏幕上有什么、玩家能操作什么"就是本次切片的目标。
不要扩大它。不要加"顺便也做一下"的东西。
## 第一步：读非目标（规划之前先做）
大纲的非目标清单，接下来的规划如果撞上任何一条，现在就直接说出来。
## 第二步：规划
### 2.1 系统划分
列出实现那句话所需的系统。通常 2-3 个。
超过 4 个说明太大，回去缩小那句话，并告诉我你缩成了什么。
划分原则：按状态所有权。每份状态有且仅有一个 owner，
其他系统通过命令/事件间接影响。不按 UI 页面分，不按功能名词分。
每个系统 ≤ 400 字，写清：职责一句话 / 它拥有哪些状态 / 它不负责什么。
### 2.2 实现顺序（重要，不要漏）
给出这些系统的实现顺序，并满足一个硬条件：
**每完成一个系统，游戏必须仍然能启动、能看到东西。**
不允许出现"三个都写完才能第一次跑起来"的顺序。
对每一步注明：做完这一步，屏幕上会出现什么。
如果某个系统不做完就没法看到任何东西，说明它该被拆开或被延后。
### 2.3 验收标准
一句话，描述我在屏幕上能看到和操作到什么。
必须是我能亲眼验证的。
不能是"系统正常工作""核心循环可运行"这类说法。
### 2.4 起点
指出实现该从哪个文件开始，给出具体路径和它的职责一句话。
不要写这个文件的内容，那是后续由其他 agent 执行的事。
### 2.5 backlog
其余系统列进来，每个一行职责。
不写状态、不写依赖、不写规模、不写接口。
## 提问规则
- 每轮最多 3 个问题，只问"不回答就没法规划"的。
- 每个问题必须附带你的默认答案和一句话理由。
- 我不回复的按默认执行，记进 ADR 待办。
- 待游玩确认 清单的处理：一律不要问，它们正是要靠这个原型来验证的。
- 不必顺从我。切片过大、假设可疑、大纲某个结论在实现上行不通、或参考项目某个做法其实不适合我们，直接说。
## 不要写的东西
- 代码、伪代码、函数签名
- 架构图
- 事件总表（事件在实现中长出来）
- 尚不存在的模块之间的接口
- 扩展点、抽象层、"为以后考虑"的任何设计
- 技术选型的长篇理由（选了什么，一行说完）
## 体量
整份规划 ≤ 3 页。超了说明在写实现细节。
## 输出
确认没有待解决问题后，我回复"确认"，你再输出规划文档。
文档结构就是上面 2.1 到 2.5 五节，不要加别的章节。