config(commands): 重构开发流程：四阶段框架+通用化+阶段目录+文档同步

- development-workflow.md: 通用化(去掉UE5/ChildHood引用)，新增草案/原型/批量生产/测试发布四阶段，修复流水线编号(①-⑦完整)，明确多版本迭代，新增阶段路线图，新增文档同步流程 - design.md: 适配阶段目录(prototype/production)，执行案模板增加迭代记录表头，新增草案模式E - plan.md/pmstart.md: 路径引用适配，增加宏观阶段判断 - 设计文档全部迁移到 docs/design/prototype/，清空旧子目录 - 新建 prototype-roadmap.md，roadmap.md 改为项目总览 - 更新 current.md 和 README.md 路径引用
2026-06-03 23:38:32 +08:00
parent 487249e34e
commit cc0f66ac54
35 changed files with 793 additions and 295 deletions
@@ -7,10 +7,10 @@
 ## 角色规则

 - 你现在是**策划 Agent**，专注于玩法设计、数值平衡、叙事
- 设计文档放入 `docs/design/`，配置表放入 `GameConfig/`
+- 设计文档放入 `docs/design/<阶段>/`（`prototype/` 或 `production/`），配置表放入 `GameConfig/`
 - 文档格式：Markdown，数值表用 CSV 或 JSON（格式见 `GameConfig/README.md`）
 - 设计新系统时，先产出设计文档，再产出对应配置表
- **不做**: 不写蓝图、不写 C++、不处理 .uasset 文件
+- **不做**: 不写代码、不处理引擎资产文件
 - 完成工作后**汇报结果**，等待开发者确认，不要自动更新 `current.md`
 - **产出标准依据**: `docs/development-workflow.md` 中定义的各阶段文档质量要求

@@ -35,37 +35,44 @@

 ## 步骤 1：上下文读取与阶段判断

-1. 读取 `docs/plans/current.md`，获取当前版本和流水线状态
+1. 读取 `docs/plans/current.md`，获取当前版本、宏观阶段和流水线状态
 2. 读取 `docs/development-workflow.md`，掌握各阶段产出标准
-3. 扫描 `docs/design/` 和 `GameConfig/` 已有文档
-4. 检查是否有头脑风暴讨论记录（`docs/design/brainstorm-*.md` 及 `docs/design/vXX/brainstorm-*.md`）
-5. **对照以下路由表，判断当前应进入哪个模式**：
+3. **确定当前阶段的设计目录**：
+   - 原型阶段 → `docs/design/prototype/`
+   - 批量生产阶段 → `docs/design/production/`
+   - 草案阶段 → `docs/design/`（根目录）
+4. 扫描对应阶段目录和 `GameConfig/` 已有文档
+5. 检查是否有头脑风暴讨论记录（`docs/design/<阶段>/brainstorm-*.md`）
+6. **对照以下路由表，判断当前应进入哪个模式**：

 | 流水线位置 | 判断条件 | 策划应做的事 | 路由到 |
 |---|---|---|---|
-| ① 全局设计案不完整 | `docs/design/` 缺少核心系统设计或无索引文档 | 探索设计方向，补全局设计 | **A. 全局设计模式** |
-| ② Roadmap 缺失 | `docs/plans/roadmap.md` 不存在 | PM 主导，策划无独立任务 | 提示开发者先用 `/plan` |
-| ③ 版本设计文档缺失 | `docs/design/vXX/vXX-design.md` 不存在 | 产出当前版本设计文档 | **B. 版本设计模式** |
-| ④ 执行案缺失 | `docs/design/vXX/` 缺少当前版本所需系统的 `vXX-*-execution.md` | 逐系统产出执行案 | **C. 执行案模式** |
-| ④ 执行案质量门未通过 | `docs/plans/review-log.md` 记录了执行案审查不通过 | 按问题清单修正执行案 | **D. 执行案修正模式** |
-| ⑤+ 下游阶段 | ①②③④均已完成且质量门通过 | 策划无当前版本的产出任务 | 默认提示无任务，开发者可手动指定进入 **A. 全局设计模式**（探索后续版本设计） |
+| 草案阶段 | `docs/design/concept.md` 不存在 | 产出玩法草案 | **E. 草案模式** |
+| ① 全局设计案不完整 | 阶段目录缺少核心系统设计或无索引文档 | 探索设计方向，补全局设计 | **A. 全局设计模式** |
+| ② 阶段路线图缺失 | `docs/plans/<阶段>-roadmap.md` 不存在 | PM 主导，策划无独立任务 | 提示开发者先用 `/plan` |
+| ③ 版本设计缺失 | 阶段路线图存在但当前版本设计未展开 | 产出当前版本设计 | **B. 版本设计模式** |
+| ④ 执行案缺失 | 阶段目录缺少当前版本所需系统的 `*-execution.md` | 逐系统产出执行案 | **C. 执行案模式** |
+| ④ 执行案质量门未通过 | `docs/plans/review-log.md` 记录了审查不通过 | 按问题清单修正执行案 | **D. 执行案修正模式** |
+| ⑤+ 下游阶段 | ①②③④均已完成且质量门通过 | 策划无当前版本的产出任务 | 默认提示无任务，开发者可手动指定 **A.** 探索后续版本设计 |

-6. 向开发者汇报判断结果：
+7. 向开发者汇报判断结果：

 ```
 ## 📐 策划状态

+**开发阶段**: [草案 / 原型 / 批量生产 / 测试发布]
+**设计目录**: docs/design/[阶段]/
 **当前版本**: vX.X — [名称]
 **流水线位置**: [①~⑦]
-**建议模式**: [A/B/C/D] — [一句话理由]
+**建议模式**: [A/B/C/D/E] — [一句话理由]

-**已有产出**: [列出 docs/design/ 和 GameConfig/ 中与当前版本相关的文档]
+**已有产出**: [列出阶段目录中与当前版本相关的文档]
 **待产出**: [列出缺失的文档]

 建议进入 [模式名]。或手动指定其他模式。
 ```

-7. 等待开发者确认或手动指定模式，然后进入对应模式
+8. 等待开发者确认或手动指定模式，然后进入对应模式

 ---

@@ -98,13 +105,9 @@

 ### 讨论记录

-每次头脑风暴的成果按讨论目标存放：
+每次头脑风暴的成果存放在当前阶段的设计目录下：

- **全局性讨论**（愿景、支柱、世界观等）→ `docs/design/brainstorm-YYYY-MM-DD-<讨论目标>.md`
-  - 例: `brainstorm-2026-06-01-game-vision.md`
- **版本相关讨论**（版本范围、系统执行细节等）→ `docs/design/vXX/brainstorm-YYYY-MM-DD-<讨论目标>.md`
-  - 例: `docs/design/v01/brainstorm-2026-06-02-interaction.md`
-  - 例: `docs/design/v01/brainstorm-2026-06-03-scope.md`
+- **位置**: `docs/design/<阶段>/brainstorm-YYYY-MM-DD-<讨论目标>.md`
 - **内容**: 讨论目标 + 达成的共识摘要 + 未决问题
 - **用途**: 下次 /design 时读取，避免重复讨论已确认的内容

@@ -121,7 +124,7 @@

 ### 执行流程

-1. 检查 `docs/design/` 下的全局设计文档，识别缺失的系统设计
+1. 检查当前阶段目录下的全局设计文档，识别缺失的系统设计
 2. 检查已有头脑风暴记录，识别已讨论和未讨论的维度
 3. **对未明确的维度，使用头脑风暴方法与开发者确认**
 4. 确认完毕后，逐份产出全局设计文档
@@ -138,22 +141,17 @@
 - 不做什么：明确不想做的内容

 **玩法支柱深挖**（逐个讨论）:
- 叙事支柱：故事结构、情感弧线、叙事穿插方式
- 小游戏支柱：核心操作乐趣、小游戏之间关系、输赢反馈
- 收集支柱：动机、深度、获取方式、与小游戏/叙事的关联
- 其他支柱：经济系统、社交关系、时间/天气等（按需展开）
+- 各个核心支柱的具体设计
+- 支柱之间的关系和联动

 **场景与世界观**:
- 场景地图：主要区域、连通方式、空间尺度
- 时代细节：必须有 vs 锦上添花的千禧年元素
- 室内外空间：哪些可进入、哪些是装饰
- 乡下乡土情节的表现形式
+- 场景地图、连通方式、空间尺度
+- 世界观中的关键元素

 **版本范围与优先级**:
 - 当前版本目标和验证核心
 - 明确排除的内容
 - 验收标准
- 版本间递进关系

 ### 文档产出

@@ -162,24 +160,24 @@
 1. **对照文档产出自检标准**（见文末），确认每份文档符合①阶段质量要求
 2. **先产出最核心文档**（通常是游戏愿景），产出后汇报，等开发者确认
 3. 开发者确认后，展开下一份文档
-4. 每份文档产出后汇报结果，不自动更新 `current.md` 或 `roadmap.md`
+4. 每份文档产出后汇报结果，不自动更新 `current.md`
 5. 全部完成后汇总汇报，由 PM（`/plan`）统一更新进度文档

 ---

 ## 模式 B：版本设计

-> 触发条件：①②已完成，但当前版本设计文档（③）缺失。
+> 触发条件：①②已完成，但当前版本设计（③）缺失。

-**前置检查**: 确认 `docs/plans/roadmap.md` 存在且当前版本目标已定义。如缺失，提示先用 `/plan`。
+**前置检查**: 确认阶段路线图（`docs/plans/<阶段>-roadmap.md`）存在且当前版本目标已定义。如缺失，提示先用 `/plan`。

 ### 执行流程

-1. 读取 `docs/plans/roadmap.md` 中当前版本的定义
+1. 读取阶段路线图中当前版本的定义
 2. 读取已有的全局设计文档，理解当前版本涉及的系统
 3. 如有相关头脑风暴记录，读取其中的版本范围相关共识
 4. 如版本范围的细节不够明确，**使用头脑风暴方法**与开发者确认
-5. 产出 `docs/design/vXX/vXX-design.md`（如 `docs/design/v01/v01-design.md`）
+5. 产出或更新版本设计文档（放在阶段目录下）

 ### 文档必须包含

@@ -198,13 +196,13 @@

 ## 模式 C：执行案

-> 触发条件：③已完成（版本设计文档存在），但当前版本所需系统的执行案（④）缺失。
+> 触发条件：③已完成（版本设计已定义），但当前版本所需系统的执行案（④）缺失。

 ### 前置检查

-1. 读取当前版本设计文档（`docs/design/vXX/vXX-design.md`）
+1. 读取当前版本设计文档
 2. 提取本版本涉及的系统清单
-3. 扫描 `docs/design/vXX/vXX-*-execution.md`，确认哪些系统的执行案已存在、哪些缺失
+3. 扫描阶段目录下的 `*-execution.md`，确认哪些系统的执行案已存在、哪些缺失
 4. 向开发者列出待产出的执行案清单，确认产出顺序

 ### 每份执行案的产出流程
@@ -214,7 +212,32 @@
 1. 读取该系统的全局设计文档（如有）
 2. 读取相关头脑风暴记录中与该系统的共识
 3. 如行为规则细节不够明确，**使用头脑风暴方法**与开发者确认具体行为
-4. **对照执行案标准**产出 `docs/design/vXX/vXX-<系统名>-execution.md`
+4. **对照执行案标准**产出 `<系统名>-execution.md`
+
+### 执行案格式
+
+每个执行案文件必须以**迭代记录表头**开头：
+
+```markdown
+# <系统名>执行案
+
+## 迭代记录
+
+| 迭代版本 | 修改日期 | 状态 | 说明 |
+|----------|----------|------|------|
+| vX.X | YYYY-MM-DD | 📝 设计中 | [简要说明本次迭代的范围] |
+
+> 状态标记：📝 设计中 | 🔄 开发中 | ✅ 已同步
+
+---
+
+## 系统概述
+（描述该系统做什么、服务于什么体验目标）
+
+## 行为规则
+（当前最新状态的所有行为规则，包含所有已迭代的内容）
+...
+```

 ### 执行案必须包含

@@ -223,15 +246,15 @@
 1. **系统概述** — 这个系统做什么、服务于什么体验目标
 2. **完整的行为规则清单** — 每个操作的：触发条件 → 触发后表现 → 结束条件
 3. **状态和状态转换** — 系统有哪些状态、什么条件触发状态变化
-4. **边界情况处理** — 异常/极端情况下的系统行为（多物体重叠、交互中断、异常状态等）
+4. **边界情况处理** — 异常/极端情况下的系统行为
 5. **与其他系统的交互** — 本系统与其他系统的关联和影响

 ### 执行案不应包含（技术越界红线）

- 用什么 UE5 组件实现
- 代码/蓝图架构怎么组织
- 数据用什么格式存储（JSON/CSV/DataAsset 等）
- 具体的参数精确值（如推镜 0.5 秒、文案延迟 0.2 秒等调优参数，如需标注则写"建议值，可调"）
+- 用什么引擎组件实现
+- 代码架构怎么组织
+- 数据用什么格式存储
+- 具体的参数精确值（调优参数标注"建议值，可调"）

 ### 已有文档的引用规则

@@ -240,6 +263,15 @@
 - 在执行案文档中注明"引用自 [全局设计文档名]，已逐条确认满足标准"
 - 不满足标准的部分必须补充

+### 文档同步（迭代完成后）
+
+每个版本迭代完成后，必须同步更新执行案：
+
+1. 对照实际实现，找出与文档的差异
+2. 更新行为规则以匹配实际实现
+3. 在迭代记录中新增一行，标记为 ✅ 已同步
+4. 如果实现与设计有重大偏差，记录偏差原因
+
 ### 产出节奏

 - 逐系统产出，每个系统产出后汇报结果
@@ -268,16 +300,57 @@

 ---

+## 模式 E：草案
+
+> 触发条件：项目处于草案阶段，`docs/design/concept.md` 不存在。
+
+### 执行流程
+
+1. 使用头脑风暴方法与开发者逐项确认草案的 6 个字段
+2. 确认完毕后，产出 `docs/design/concept.md`
+
+### 草案文档必须包含
+
+对照 `docs/development-workflow.md` 草案阶段标准：
+
+1. **一句话描述** — 用一句话说清楚这是什么游戏
+2. **玩家能做什么** — 玩家在游戏中的核心操作和活动
+3. **游戏氛围与风格** — 情感基调、视觉风格、目标审美
+4. **游戏核心循环** — 玩家在游戏中反复做什么、为什么持续玩
+5. **游戏元素** — 世界观、角色、剧情、物品、怪物等关键元素概述
+6. **参考** — 灵感来源（其他游戏、电影、书、某种经历）
+
+### 产出节奏
+
+产出后汇报，等开发者确认。确认后进入原型阶段，开始全局设计（模式 A）。
+
+---
+
+## 阶段感知说明
+
+策划在不同开发阶段下，对执行案的严格度不同：
+
+| 维度 | 原型阶段 | 批量生产阶段 |
+|------|----------|-------------|
+| 行为覆盖 | 核心行为必须完整，非核心行为可略过 | 所有行为必须完整覆盖 |
+| 边界情况 | 影响核心玩法的必须处理，其余可略过 | 全部必须处理 |
+| 系统间关联 | 核心关联必须说明 | 全部必须说明 |
+| 参数精度 | 可标注"建议值，可调" | 同样可标注，但范围更窄 |
+
+策划在产出执行案时，应感知当前项目所处的宏观阶段，按对应严格度产出。
+
+---
+
 ## 文档产出自检标准

 策划产出每份文档时，必须对照以下标准自检。这些标准来自 `docs/development-workflow.md`。

 ### 全局设计文档（流水线 ①阶段）

-产出位置：`docs/design/`
+产出位置：`docs/design/<阶段>/`

 - [ ] **系统清单**: 游戏最终包含哪些系统
- [ ] **元素清单**: 游戏世界中的关键元素（角色、场景区域、收集品分类、NPC 等）
+- [ ] **元素清单**: 游戏世界中的关键元素
 - [ ] **系统关系**: 各系统之间如何关联和互相影响
 - [ ] **核心玩法循环**: 玩家在游戏中做什么、为什么持续玩
 - [ ] **情感目标**: 游戏要给玩家带来什么样的体验和情感
@@ -285,20 +358,21 @@

 ### 版本设计文档（流水线 ③阶段）

-产出位置：`docs/design/vXX/vXX-design.md`（如 `docs/design/v01/v01-design.md`）
+产出位置：`docs/design/<阶段>/`

 - [ ] **版本目标定位**: 原型 / 功能完整可玩版 / 打磨体验版
 - [ ] **内容范围**: 每个内容项 + 完成度（占位 / 初版 / 正式）
 - [ ] **验收标准**: 明确、可检验的验收条件
 - [ ] **系统清单**: 本版本涉及的系统，引用执行案
- [ ] **范围一致性**: 与 roadmap 中该版本的定义一致
+- [ ] **范围一致性**: 与阶段路线图中该版本的定义一致

 ### 执行案文档（流水线 ④阶段）

-产出位置：`docs/design/vXX/vXX-<系统名>-execution.md`（如 `docs/design/v01/v01-player-controller-execution.md`）
+产出位置：`docs/design/<阶段>/<系统名>-execution.md`

+- [ ] **迭代记录表头**: 文件顶部包含迭代记录表，填写完整
 - [ ] **行为规则完整**: 覆盖所有玩家可感知的行为，每个操作有触发条件 + 表现 + 结束条件
- [ ] **无模糊地带**: 不含"大概""可能""看情况"等模糊描述，程序拿到后能不问策划任何问题就实现功能
- [ ] **无技术越界**: 不涉及 UE5 组件、数据格式、代码架构；精确参数值标注为"建议值，可调"
+- [ ] **无模糊地带**: 不含"大概""可能""看情况"等模糊描述
+- [ ] **无技术越界**: 不涉及引擎组件、数据格式、代码架构
 - [ ] **边界情况覆盖**: 异常/极端情况的处理都已明确
 - [ ] **系统间关联**: 与其他系统的关联和影响已说明
@@ -41,9 +41,26 @@ PM 的核心价值不是汇报状态，而是**主动发现问题、预判风险
 | 程序产出 | `docs/technical/`、`Source/`、`Content/` | 技术方案、代码、蓝图 |
 | 美术产出 | `docs/art/`、`Content/` | 风格指南、资产 |

-### 步骤 2：判断当前流水线阶段
+### 步骤 2：判断宏观阶段与流水线阶段

-对照 `docs/development-workflow.md` 中的「PM 诊断检查清单」，按顺序逐项检查，**定位当前版本处于流水线的哪个阶段**。
+**2a. 判断宏观开发阶段**：
+
+对照 `docs/development-workflow.md` 中的「宏观阶段判断」，确定项目当前处于哪个阶段：
+
+| 判断条件 | 阶段 |
+|----------|------|
+| `docs/design/concept.md` 不存在 | 草案阶段 |
+| `concept.md` 存在，但核心玩法尚无可玩原型 | 原型阶段 |
+| 核心玩法已有可玩原型，正在填充内容和资产 | 批量生产阶段 |
+| 功能完整，正在做 Bug 修复和微调 | 测试与发布阶段 |
+
+**2b. 判断版本流水线阶段**（仅原型和批量生产阶段适用）：
+
+对照 `docs/development-workflow.md` 中的「版本流水线检查」清单，按顺序逐项检查，**定位当前版本处于流水线的哪个阶段**。
+
+**注意阶段严格度差异**：
+- 原型阶段：质量门检查重点关注核心行为，非核心维度可降低严格度
+- 批量生产阶段：质量门必须逐条全面检查

 遇到第一个未通过的项目即为当前阻塞点。区分两种情况：

@@ -58,14 +75,16 @@ PM 的核心价值不是汇报状态，而是**主动发现问题、预判风险
 1. 读取对应阶段的产出文档
 2. 对照 `docs/development-workflow.md` 中该质量门的检查清单，逐项检查
 3. **不仅是检查文档是否存在，必须检查文档内容质量**——行为规则是否完整、是否有模糊地带、是否技术越界、美术需求是否具体等
-4. 记录审查结果
+4. **根据宏观阶段调整严格度**——原型阶段重点关注核心行为，批量生产阶段逐条全面检查
+5. 记录审查结果

 **审查结果写入 `docs/plans/review-log.md`**，格式如下：

 ```markdown
 ## [日期] 执行案质量门审查

-**审查对象**：`docs/design/systems/<系统名>-execution.md`
+**宏观阶段**：[原型 / 批量生产]
+**审查对象**：`docs/design/<阶段>/<系统名>-execution.md`

 ### 检查结果

@@ -194,6 +213,7 @@ PM 的核心价值不是汇报状态，而是**主动发现问题、预判风险
 ```markdown
 ## 📊 项目状态

+**开发阶段**: [草案 / 原型 / 批量生产 / 测试发布]
 **当前版本**: vX.X — [版本名称]
 **流水线阶段**: ①~⑦ + 质量门 — [一句话描述当前阻塞在哪里]
 **整体进度**: [已完成/总任务] ([百分比])
@@ -68,7 +68,7 @@
 ### Step 3：展示 TODO + 建议下一步

 1. 读取 `docs/plans/current.md`，展示未完成任务（仅 `[ ]` 未勾选项）
-2. 读取 `docs/development-workflow.md`，判断当前流水线阶段
+2. 读取 `docs/development-workflow.md`，判断当前宏观阶段（草案/原型/批量生产/测试发布）和流水线阶段
 3. 综合分析后给出建议：
   - 接下来由**哪个角色**做什么**具体任务**（附理由）
   - 如果需要深度审查（质量门、流水线诊断）→ 建议使用 `/plan`
@@ -92,6 +92,7 @@

 ## 📋 当前 TODO

+**开发阶段**: 原型
 **流水线阶段**: ④执行案（①②③基本就绪）

 - [ ] 任务1 — ④执行案
@@ -117,8 +118,8 @@
 ### 📥 远端更新摘要

 **策划产出**:
- 新增 `docs/design/systems/interaction-system-execution.md`
- 更新 `docs/design/systems/collection-system.md`
+- 新增 `docs/design/prototype/interaction-system-execution.md`
+- 更新 `docs/design/prototype/collection-system.md`

 **其他**:
 - ...