map-systems

---
name: map-systems
description: "将游戏概念拆解为独立系统，映射依赖关系，确定设计优先级，并创建系统索引。"
argument-hint: "[可选: 'next' 以选择最高优先级的未设计系统，或系统名称以交接给 /design-system]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, TodoWrite
---

当此技能被调用时：

## 1. 解析参数

两种模式：

- **无参数**：`/map-systems` — 运行完整的拆解工作流（阶段 1-5）以创建或更新系统索引。
- **`next`**：`/map-systems next` — 从索引中选择最高优先级的未设计系统并交接给 `/design-system`（阶段 6）。

---

## 2. 阶段 1：读取概念（必需上下文）

读取游戏概念和任何已有的设计工作。这为系统拆解提供了原始材料。

**必需：**
- 读取 `design/gdd/game-concept.md` — **如果缺失则明确报错退出**：
  > "在 `design/gdd/game-concept.md` 未找到游戏概念。请先运行 `/brainstorm` 创建一个，然后再回来将其拆解为系统。"

**可选（如果存在则读取）：**
- 读取 `design/gdd/game-pillars.md` — 游戏支柱约束优先级和范围
- 读取 `design/gdd/systems-index.md` — 如果存在，**从上次中断处**继续（更新，而非从头重建）
- Glob `design/gdd/*.md` — 检查哪些系统 GDD 已经存在

**如果系统索引已存在：**
- 读取并向用户展示当前状态
- 使用 `AskUserQuestion` 询问：
  "系统索引已存在，包含 [N] 个系统（[M] 个已设计，[K] 个未开始）。您希望做什么？"
  - 选项："更新索引中的新系统"、"设计下一个未设计系统"、"审查并修订优先级"

---

## 3. 阶段 2：系统枚举（协作式）

提取并识别游戏需要的所有系统。这是本技能的核心创意环节 — 它需要人工判断，因为概念文档很少明确列举每个系统。

### 步骤 2a：提取显式系统

扫描游戏概念中直接提及的系统和机制：
- 核心机制部分（最明确）
- 核心循环部分（暗示驱动每层循环的系统）
- 技术考量部分（联网、程序化生成等）
- MVP 定义部分（必需功能 = 必需系统）

### 步骤 2b：识别隐式系统

对于每个显式系统，识别它所暗示的**隐藏系统**。游戏需要的系统总是比概念文档中提到的多。使用以下推理模式：

- "背包" 暗示：物品数据库、装备槽、重量/容量规则、背包 UI、物品序列化以实现存读档
- "战斗" 暗示：伤害计算、生命值系统、命中检测、状态效果、敌人 AI、战斗 UI（血条、伤害数字）、死亡/重生
- "开放世界" 暗示：流式加载/分块、LOD (Level of Detail) 系统、快速旅行、地图/小地图、兴趣点追踪、世界状态持久化
- "多人游戏" 暗示：网络层、大厅/匹配、状态同步、反作弊、网络 UI（延迟、玩家列表）
- "制作" 暗示：配方数据库、材料收集、制作 UI、成功/失败机制、配方发现/学习
- "对话" 暗示：对话树系统、对话 UI、选择追踪、NPC 状态管理、本地化钩子
- "成长" 暗示：经验值系统、升级机制、技能树、解锁追踪、成长 UI、成长存档数据

在对话中解释为什么需要每个隐式系统（附示例）。

### 步骤 2c：用户审核

按类别组织展示枚举结果。对于每个系统，展示：
- 名称
- 类别
- 简要描述（一句话）
- 是显式的（来自概念）还是隐式的（推理得出）

然后使用 `AskUserQuestion` 收集反馈：
- "此列表中是否缺少系统？"
- "是否有需要合并或拆分的系统？"
- "是否有此游戏不需要的系统？"

迭代直到用户批准枚举结果。

---

## 4. 阶段 3：依赖映射（协作式）

对于每个系统，确定它依赖什么。如果系统 A 没有系统 B 就无法运行，则系统 A "依赖" 系统B。

### 步骤 3a：映射依赖

对于每个系统，列出其依赖项。使用以下依赖启发式规则：
- **输入/输出依赖**：系统 A 产生系统 B 需要的数据
- **结构依赖**：系统 A 提供系统 B 接入的框架
- **UI 依赖**：每个游戏系统都有对应的 UI 系统，UI 系统依赖于它（但 UI 在游戏系统之后设计）

### 步骤 3b：按依赖顺序排序

将系统排列为层级：
1. **基础层**：零依赖的系统（首先设计和构建）
2. **核心层**：仅依赖基础层系统的系统
3. **功能层**：依赖核心层系统的系统
4. **表现层**：包裹游戏系统的 UI 和反馈系统
5. **打磨层**：元系统、教程、分析、无障碍

### 步骤 3c：检测循环依赖

检查依赖图中的循环。如果发现：
- 向用户高亮显示
- 提出解决方案（接口抽象、同时设计、通过定义两系统间的契约来打破循环）

### 步骤 3d：展示给用户

以分层列表形式展示依赖图。高亮：
- 任何循环依赖
- 任何"瓶颈"系统（许多其他系统依赖它们 — 这些是高风险的）
- 任何没有依赖者的系统（叶子节点 — 风险较低，可以较晚设计）

使用 `AskUserQuestion` 询问："这个依赖顺序看起来正确吗？是否有遗漏或应移除的依赖？"

---

## 5. 阶段 4：优先级分配（协作式）

根据每个系统所需的里程碑，将其分配到优先级层级。

### 步骤 4a：基于概念自动分配

使用以下启发式规则进行初始分配：
- **MVP**：概念中 "MVP 必需" 部分提及的系统，加上其基础层依赖
- **垂直切片**：在一个区域实现完整体验所需的系统
- **Alpha**：所有剩余的游戏系统
- **完整愿景**：打磨、元功能和锦上添花的系统

### 步骤 4b：用户审核

以表格形式展示优先级分配。对于每个层级，解释为什么将系统放在那里。

使用 `AskUserQuestion` 询问："这些优先级分配符合您的愿景吗？哪些系统应该更高或更低优先级？"

在对话中解释推理："我将 [系统] 放在 MVP 中，因为核心循环需要它 — 没有 [系统]，30 秒循环无法运行。"

### 步骤 4c：确定设计顺序

结合依赖排序 + 优先级层级得出最终设计顺序：
1. 首先是 MVP 基础层系统
2. 其次是 MVP 核心层系统
3. 再次是 MVP 功能层系统
4. 垂直切片基础层/核心层系统
5. 依此类推

这就是团队应该按此顺序编写 GDD 的顺序。

---

## 6. 阶段 5：创建系统索引（写入）

### 步骤 5a：起草文档

使用 `.claude/docs/templates/systems-index.md` 中的模板，用阶段 2-4 的所有数据填充系统索引：
- 填充枚举表
- 填充依赖图
- 填充推荐设计顺序
- 填充高风险系统
- 填充进度追踪器（所有系统初始为 "未开始"，除非 GDD 已存在）

### 步骤 5b：审批

展示文档摘要：
- 按类别的系统总数
- MVP 系统数量
- 设计顺序中的前 3 个系统
- 任何高风险项目

询问："可以将系统索引写入 `design/gdd/systems-index.md` 吗？"

等待批准。仅在 "同意" 后写入文件。

### 步骤 5c：更新会话状态

写入后，更新 `production/session-state/active.md`：
- 任务：系统拆解
- 状态：系统索引已创建
- 文件：design/gdd/systems-index.md
- 下一步：设计各系统 GDD

---

## 7. 阶段 6：设计各系统（交接给 /design-system）

当以下情况进入此阶段：
- 用户在创建索引后同意开始设计系统
- 用户调用 `/map-systems [system-name]`
- 用户调用 `/map-systems next`

### 步骤 6a：选择系统

- 如果提供了系统名称，在系统索引中查找
- 如果使用 `next`，选择最高优先级的未设计系统（按设计顺序）
- 如果用户刚完成索引，询问：
  "您现在要开始设计各系统吗？设计顺序中的第一个系统是 [名称]。或者您想先停在这里稍后继续？"

使用 `AskUserQuestion` 询问："现在开始设计 [系统名称]，选择其他系统，还是先停在这里？"

### 步骤 6b：交接给 /design-system

选择系统后，调用 `/design-system [system-name]` 技能。

`/design-system` 技能负责完整的 GDD 编写流程：
- 从游戏概念、系统索引和依赖 GDD 收集上下文
- 立即创建文件骨架
- 逐一走完所有 8 个必需部分（协作式、增量式）
- 交叉引用现有文档以防止矛盾
- 路由到专家代理获取领域专业知识
- 每个部分一经批准立即写入文件
- 完成后运行 `/design-review`
- 更新系统索引

**不要在这里重复 /design-system 的工作流。** 此技能拥有系统*索引*；`/design-system` 拥有各系统*GDD*。

### 步骤 6c：循环或停止

`/design-system` 完成后，使用 `AskUserQuestion`：
- "继续下一个系统（[下一个系统名称]）？"
- "选择其他系统？"
- "本次会话到此为止？"

如果继续，返回步骤 6a。

---

## 8. 阶段 7：建议后续步骤

系统索引创建后（或设计了一些系统后），建议适当的后续操作：

- "运行 `/design-system [系统名称]` 编写下一个系统的 GDD"
- "对每个完成的 GDD 运行 `/design-review [路径]` 以验证质量"
- "运行 `/gate-check pre-production` 检查是否准备好开始构建"
- "使用 `/prototype [系统]` 原型化最高风险的系统"
- "使用 `/sprint-plan new` 计划第一个实现 Sprint"

---

## 协作协议

本技能在每个阶段遵循协作设计原则：

1. 每一步都遵循 **提问 -> 选项 -> 决定 -> 草稿 -> 审批**
2. 在每个决策点使用 `AskUserQuestion`（解释 -> 捕获模式）：
   - 阶段 2："有遗漏的系统？需要合并或拆分？"
   - 阶段 3："依赖顺序是否正确？"
   - 阶段 4："优先级分配符合您的愿景？"
   - 阶段 5："可以将系统索引写入吗？"
   - 阶段 6："开始设计、选择其他、还是停止？"然后交接给 `/design-system`
3. 每次文件写入前都要 **"可以将此内容写入 [文件路径] 吗？"**
4. **增量写入**：每设计完一个系统后更新系统索引
5. **交接**：单个 GDD 编写由 `/design-system` 负责，它处理增量部分写入、交叉引用、设计审查和索引更新
6. **会话状态更新**：在每个里程碑（索引创建、系统设计、优先级变更）后写入 `production/session-state/active.md`

**绝不要**在未经审核的情况下自动生成完整系统列表并写入。
**绝不要**在未经用户确认的情况下开始设计系统。
**始终**展示枚举、依赖和优先级供用户验证。