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/` 已有文档
+3. **确定当前阶段的设计目录**：
-4. 检查是否有头脑风暴讨论记录（`docs/design/brainstorm-*.md` 及 `docs/design/vXX/brainstorm-*.md`）
+   - 原型阶段 → `docs/design/prototype/`
-5. **对照以下路由表，判断当前应进入哪个模式**：
+   - 批量生产阶段 → `docs/design/production/`
   - 草案阶段 → `docs/design/`（根目录）
 4. 扫描对应阶段目录和 `GameConfig/` 已有文档
 5. 检查是否有头脑风暴讨论记录（`docs/design/<阶段>/brainstorm-*.md`）
 6. **对照以下路由表，判断当前应进入哪个模式**：
 | 流水线位置 | 判断条件 | 策划应做的事 | 路由到 |
 |---|---|---|---|
-| ① 全局设计案不完整 | `docs/design/` 缺少核心系统设计或无索引文档 | 探索设计方向，补全局设计 | **A. 全局设计模式** |
+| 草案阶段 | `docs/design/concept.md` 不存在 | 产出玩法草案 | **E. 草案模式** |
-| ② Roadmap 缺失 | `docs/plans/roadmap.md` 不存在 | PM 主导，策划无独立任务 | 提示开发者先用 `/plan` |
+| ① 全局设计案不完整 | 阶段目录缺少核心系统设计或无索引文档 | 探索设计方向，补全局设计 | **A. 全局设计模式** |
-| ③ 版本设计文档缺失 | `docs/design/vXX/vXX-design.md` 不存在 | 产出当前版本设计文档 | **B. 版本设计模式** |
+| ② 阶段路线图缺失 | `docs/plans/<阶段>-roadmap.md` 不存在 | PM 主导，策划无独立任务 | 提示开发者先用 `/plan` |
-| ④ 执行案缺失 | `docs/design/vXX/` 缺少当前版本所需系统的 `vXX-*-execution.md` | 逐系统产出执行案 | **C. 执行案模式** |
+| ③ 版本设计缺失 | 阶段路线图存在但当前版本设计未展开 | 产出当前版本设计 | **B. 版本设计模式** |
-| ④ 执行案质量门未通过 | `docs/plans/review-log.md` 记录了执行案审查不通过 | 按问题清单修正执行案 | **D. 执行案修正模式** |
+| ④ 执行案缺失 | 阶段目录缺少当前版本所需系统的 `*-execution.md` | 逐系统产出执行案 | **C. 执行案模式** |
-| ⑤+ 下游阶段 | ①②③④均已完成且质量门通过 | 策划无当前版本的产出任务 | 默认提示无任务，开发者可手动指定进入 **A. 全局设计模式**（探索后续版本设计） |
+| ④ 执行案质量门未通过 | `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`
+- **位置**: `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`
 - **内容**: 讨论目标 + 达成的共识摘要 + 未决问题
 - **用途**: 下次 /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/prototype/interaction-system-execution.md`
- 更新 `docs/design/systems/collection-system.md`
+- 更新 `docs/design/prototype/collection-system.md`
 **其他**:
 - ...
@@ -1,24 +1,73 @@
-# docs/design/ — 策划文档
+# docs/design/ — 策划文档索引
-策划 Agent 的输出目录。所有玩法设计、系统机制、剧情叙事文档存放于此。
+> 策划 Agent 的输出目录。所有玩法设计、系统机制、剧情叙事文档存放于此。
-## 文件组织
+## 目录结构
 ```
 docs/design/
-  activities/        # 各活动/小游戏的设计文档
+  concept.md                  # 草案阶段产出（项目初期）
-  systems/           # 系统机制设计（时间系统、NPC 关系等）
+  README.md                   # 本索引文件
-  narrative/         # 剧情/叙事设计
+  prototype/                  # 原型阶段设计（设计案 + 执行案 + 头脑风暴）
  production/                 # 批量生产阶段设计（从 prototype/ 复制，作为起点）
 ```
 ## 原型阶段文档 (`prototype/`)
 ### 全局设计
 | 文档 | 说明 |
 |------|------|
 | [game-vision.md](prototype/game-vision.md) | 游戏愿景、核心情感、三大支柱、游戏世界 |
 | [scene-world.md](prototype/scene-world.md) | 场景与世界观详细设计 |
 | [protagonist-character.md](prototype/protagonist-character.md) | 主角角色设计 |
 | [narrative-framework.md](prototype/narrative-framework.md) | 叙事框架（事件链、多支线结局、角色关系） |
 ### 系统设计
 | 文档 | 说明 |
 |------|------|
 | [player-controller.md](prototype/player-controller.md) | 玩家控制（移动、摄像机） |
 | [interaction-system.md](prototype/interaction-system.md) | 交互系统（观察、拾取、使用） |
 | [collection-system.md](prototype/collection-system.md) | 收集系统（四类收集品、展示、世界反馈） |
 | [minigame-system.md](prototype/minigame-system.md) | 小游戏体系（弹珠、四驱车、FC/街机等） |
 ### 版本相关
 | 文档 | 说明 |
 |------|------|
 | [v01-scope.md](prototype/v01-scope.md) | v0.1 范围定义 |
 | [scene-v01-suburban.md](prototype/scene-v01-suburban.md) | v0.1 场景设计（城郊结合区） |
 ### 头脑风暴
 | 文档 | 说明 |
 |------|------|
 | [brainstorm-2026-06-01-vision-pillars-world.md](prototype/brainstorm-2026-06-01-vision-pillars-world.md) | 愿景探索、三大支柱深挖、场景世界观、版本范围 |
 ### 待产出
 | 文档 | 说明 |
 |------|------|
 | `v01-design.md` | v0.1 版本设计文档（总纲） |
 | `player-controller-execution.md` | 玩家控制器执行案 |
 | `interaction-system-execution.md` | 交互系统执行案 |
 | `collection-system-execution.md` | 收集系统 v0.1 执行案 |
 ## 待产出的全局设计文档
 | 文档 | 说明 | 优先级 |
 |------|------|--------|
 | `economy-system.md` | 零花钱经济系统设计 | v0.3 前产出 |
 | `time-system.md` | 一天时间循环系统设计 | v0.3 前产出 |
 ---
 ## 格式约定
 - Markdown 格式
- 每个活动/系统一个独立文件
+- 每个系统/角色/场景一个独立文件
- 文件名使用小写英文 + 连字符：`marble-game.md`、`time-system.md`
+- 文件名使用小写英文 + 连字符：`player-controller.md`
-
+- 设计案和执行案按阶段放在 `prototype/` 或 `production/` 目录下，不按版本分子目录
-## 与其他 Agent 的关系
+- 执行案文件顶部必须包含迭代记录表头
-
+- 头脑风暴文件名格式：`brainstorm-YYYY-MM-DD-<讨论目标>.md`
 - 程序 Agent 读取此目录的设计文档作为开发需求
 - 美术 Agent 读取设计文档中的美术需求部分
 - 数值参数抽到 `GameConfig/` 目录下的 CSV/JSON 文件中
@@ -1,6 +1,6 @@
 # 游戏开发工作流
-> 本文档定义 ChildHood 项目的版本开发流水线、角色职责、产出标准和质量检查规则。
+> 本文档定义游戏项目的开发阶段、版本开发流水线、角色职责、产出标准和质量检查规则。
 > 所有开发工作必须遵循此工作流，不可跳过或并行阶段。
 ---
@@ -10,9 +10,9 @@
 | 角色 | 职责 | 产出位置 | PM 如何判断其进度 |
 |------|------|----------|-------------------|
 | **策划** (Design) | 玩法设计、数值平衡、叙事、系统机制 | `docs/design/`、`GameConfig/` | 扫描 `docs/design/` 和 `GameConfig/` 目录中的文件 |
-| **程序** (Dev) | 蓝图/C++、系统实现、技术架构、Bug 修复 | `Source/`、`Content/Blueprints/`、`Content/Data/`、`docs/technical/` | 扫描 `Source/`、`Content/`、`docs/technical/` 目录中的文件 |
+| **程序** (Dev) | 系统实现、技术架构、Bug 修复 | `Source/`、`Content/`、`docs/technical/` | 扫描对应目录中的文件 |
-| **美术** (Art) | 美术需求分析、资产规格、风格指南、AI 图像 | `docs/art/`、`Content/` | 扫描 `docs/art/` 和 `Content/` 目录中的文件 |
+| **美术** (Art) | 美术需求分析、资产规格、风格指南 | `docs/art/`、`Content/` | 扫描对应目录中的文件 |
-| **PM** | 进度追踪、优先级决策、风险预警、流水线推进、任务依赖梳理 | `docs/plans/` | 不产出设计文档、代码或美术资产 |
+| **PM** | 进度追踪、优先级决策、风险预警、流水线推进 | `docs/plans/` | 不产出设计文档、代码或美术资产 |
 ### 协作规则
@@ -30,12 +30,247 @@
 ---
-## 版本开发流水线
+## 开发阶段
-每个版本的开发必须按以下流水线**严格顺序推进**：
+项目开发分为四个宏观阶段，每个阶段有不同的关注重点和流程重量。
 ```
-① 全局设计案 → ② 版本Roadmap → ③ 当前版本设计文档 → ④ 执行案
+草案阶段 ─── "这个游戏是什么？" ─── 轻量流程，每项目一次
    ↓
 原型阶段 ─── "这个游戏好玩吗？" ─── 版本流水线（轻量），多版本迭代
    ↓
 批量生产阶段 ─── "把游戏做完整" ─── 版本流水线（完整 + 生产工具），多版本迭代
    ↓
 测试与发布阶段 ─── "把游戏做稳定" ─── Bug/反馈驱动
 ```
 **阶段转换由开发者主观判断**，无硬性标准。PM 可建议，但最终决定权在开发者。
 ---
 ### 草案阶段
 **目的**：确定游戏是什么——玩法方向、美术风格、技术可行性。
 **范围**：每项目一次，在正式开发之前完成。
 **关注问题**：这个游戏是什么？为什么要做？做不做得了？
 #### 产出
 **玩法草案文档**（`docs/design/concept.md`），包含以下 6 个字段：
 1. **一句话描述** — 用一句话说清楚这是什么游戏
 2. **玩家能做什么** — 玩家在游戏中的核心操作和活动
 3. **游戏氛围与风格** — 情感基调、视觉风格、目标审美
 4. **游戏核心循环** — 玩家在游戏中反复做什么、为什么持续玩
 5. **游戏元素** — 世界观、角色、剧情、物品、怪物等关键元素概述
 6. **参考** — 灵感来源（其他游戏、电影、书、某种经历）
 **美术风格指南**（`docs/art/style-guide.md`）— 确定视觉方向。
 **技术可行性评估** — 评估核心玩法在目标引擎/平台上的实现可行性。
 #### 流程特点
 - **极轻量**：不需要详细的系统设计，不需要执行案，不需要质量门
 - **可以反复推翻重来**：草案阶段推翻设计成本最低
 - **头脑风暴是核心方法**：通过讨论探索方向，确认后才进入文档产出
 #### PM 检查要点
 - 草案文档 6 个字段是否都已回答？
 - 美术风格是否有明确方向？
 - 技术上是否可行？
 - 开发者是否明确表示"可以进入下一阶段"？
 #### 完成标志
 玩法草案文档产出且开发者确认。进入原型阶段后，草案文档不再修改（除非开发者决定推翻重来）。
 ---
 ### 原型阶段
 **目的**：验证核心玩法可行性——从最核心功能开始，快速迭代。
 **关注问题**：这个游戏好玩吗？核心循环跑得通吗？
 #### 阶段路线图
 原型阶段开始时，产出**阶段路线图**（`docs/plans/prototype-roadmap.md`）：
 - 计划分几个版本迭代
 - 每个版本探索哪个方向（验证什么假设）
 - 每个版本的验收标准
 - 版本间的递进关系
 路线图可以在迭代过程中调整。
 #### 多版本迭代
 原型阶段包含**多个版本**，每个版本是版本开发流水线的一次循环。版本之间可以：
 - 基于上一版本的反馈调整方向
 - 增加新的系统验证
 - 修改已有系统的行为规则
 每个版本的流水线循环：**③版本设计 → ④执行案 → ⑤程序设计 → ⑥美术产出 → ⑦程序实现 → 同步文档**
 ①全局设计在阶段初期集中产出，后续版本可增量补充。②阶段路线图在阶段开始时产出。
 #### 设计文档组织
 原型阶段的所有设计案和执行案统一放在 `docs/design/prototype/` 目录下：
 ```
 docs/design/prototype/
  game-vision.md                       # 游戏愿景
  player-controller.md                 # 设计案
  player-controller-execution.md       # 执行案（含迭代版本表头）
  interaction-system.md
  interaction-system-execution.md
  ...
 ```
 **不按版本分子目录**——执行案通过文件内的迭代记录表头追踪各版本的变更。
 #### 各流水线步骤的原型阶段要求
 | 步骤 | 原型阶段要求 |
 |------|-------------|
 | ① 全局设计案 | 可以边做边补，不需要一开始就全部完成。新系统先产出简要设计再动手 |
 | ② 阶段路线图 | 原型阶段开始时产出，可随迭代调整 |
 | ③ 版本设计 | 明确本版本的验证目标和范围。允许粗粒度 |
 | ④ 执行案 | 关注影响玩法体验的核心行为。边界情况、非核心反馈等细节可以先略过 |
 | ⑤ 程序设计 | 可以用占位方案，不需要生产级架构。重点回答"怎么实现核心行为" |
 | ⑥ 美术产出 | 允许占位资源、开发者自行处理。能用就行 |
 | ⑦ 程序实现 | 允许硬编码、允许快速但不优雅的实现。先跑通再说 |
 | PM 质量门 | 关注核心行为是否完整描述，不要求面面俱到 |
 #### 文档同步（每个迭代完成后）
 **每个版本迭代完成后，必须同步更新设计案和执行案**，使其与实际实现保持一致：
 1. **实现完成** → 体验验证
 2. **对照实现更新文档** — 设计案和执行案中与实际不符的内容要修正
 3. **更新执行案迭代记录** — 在迭代版本表头中标记状态为 ✅ 已同步
 4. **记录差异** — 如果实现与设计有偏差，记录偏差原因
 > **为什么不迭代完就同步？** 文档是下一个迭代的起点。如果文档和实现不一致，下一个迭代的执行案会基于错误的假设，导致更多返工。
 #### 阶段退出
 - **退出标准**：开发者主观判断核心玩法已验证通过
 - **退出时应有**：至少一个可玩的核心循环原型，核心系统的执行案已验证可行，文档已同步
 - **退出后**：将 `prototype/` 最终版复制到 `production/`，`prototype/` 保留作为归档
 ---
 ### 批量生产阶段
 **目的**：在核心玩法验证通过的基础上，完善外围系统，填充游戏内容与资产。
 **关注问题**：怎么把游戏做完整？内容够不够？系统之间能不能协同？
 #### 阶段路线图
 批量生产阶段开始时，产出**阶段路线图**（`docs/plans/production-roadmap.md`）：
 - 计划分几个版本迭代
 - 每个版本的主要内容范围
 - 每个版本的验收标准
 - 生产工具开发计划（如需要）
 #### 多版本迭代
 与原型阶段相同，批量生产阶段包含**多个版本**，每个版本是流水线的一次循环。
 #### 设计文档组织
 批量生产阶段的所有设计案和执行案统一放在 `docs/design/production/` 目录下：
 ```
 docs/design/production/
  game-vision.md                       # 从 prototype/ 复制，作为起点
  player-controller.md                 # 在原型基础上更新
  player-controller-execution.md       # 继续迭代，追加新的迭代记录
  ...
 ```
 #### 各流水线步骤的批量生产阶段要求
 | 步骤 | 批量生产阶段要求 |
 |------|----------------|
 | ① 全局设计案 | 应已完整。新增系统必须先产出全局设计再进入版本开发 |
 | ② 阶段路线图 | 批量生产阶段开始时产出，可随迭代调整 |
 | ③ 版本设计 | 明确本版本的内容范围和完成度要求。粒度更细 |
 | ④ 执行案 | 所有细节必须补全：边界情况、非核心反馈、边缘体验、异常处理等 |
 | ⑤ 程序设计 | 需要生产级架构，考虑扩展性和数据驱动。美术需求必须具体到尺寸和数量 |
 | ⑥ 美术产出 | 正式资产，符合风格指南。不允许占位 |
 | ⑦ 程序实现 | 不允许硬编码，数据应配置化。代码质量需达到发布标准 |
 | PM 质量门 | 完整执行所有检查项，逐条对照 |
 #### 文档同步（每个迭代完成后）
 与原型阶段相同：每个版本迭代完成后必须同步更新设计案和执行案。
 #### 生产工具
 批量生产阶段可能需要在正式开发前先开发生产工具：
 | 工具类型 | 目的 | 何时开发 |
 |----------|------|----------|
 | 数据配置工具 | 让策划能自行配置交互内容、NPC 对话、物品属性等 | 需要大量配置数据时 |
 | 关卡编辑工具 | 快速搭建和调整场景布局 | 需要频繁调整场景时 |
 | 批量资产生成工具 | 批量生成/导入美术资产 | 资产量大时 |
 | 测试工具 | 自动化验证、数据校验 | 手动测试效率低时 |
 工具开发本身也应遵循版本流水线（有执行案、有程序设计），但可以简化流程。
 #### 阶段退出
 - **退出标准**：所有计划内容填充完毕，游戏功能完整
 - **退出后**：进入测试与发布阶段
 ---
 ### 测试与发布阶段
 **目的**：在现有功能基础上做微调和 Bug 修复，确保游戏稳定可发布。
 **关注问题**：有没有 Bug？体验够不够好？性能行不行？
 #### 流程特点
 - **不使用版本开发流水线**（①-⑦）
 - **不增加大型新功能**——所有功能应已在上游阶段完成
 - **以 Bug 和反馈驱动**
 - **微调允许**：数值调整、文案修改、UI 微调、性能优化
 #### 工作流程
 ```
 收集 Bug/反馈 → 评估优先级 → 修复/微调 → 验证 → 发布
     ↑                                           │
     └───────────────────────────────────────────┘
 ```
 1. **收集**：从测试、体验、反馈中收集 Bug 和改进意见
 2. **评估**：按严重程度和影响范围排优先级
 3. **修复/微调**：针对性修改，不引入大的架构变动
 4. **验证**：确认修复有效，未引入新问题
 5. **发布**：构建发布版本
 ---
 ## 版本开发流水线
 > 本流水线在**原型阶段**和**批量生产阶段**使用。两个阶段使用相同的流水线结构，但严格度和完整性要求不同（详见上方各阶段说明）。
 每个版本的开发按以下流水线**严格顺序推进**：
 ```
 ① 全局设计案 → ② 阶段路线图 → ③ 当前版本设计 → ④ 执行案
      ↓
  [PM 审查：执行案质量门]
      ↓
@@ -48,6 +283,8 @@
  [PM 审查：美术资产验收门]
      ↓
  ⑦ 程序实现
      ↓
  [文档同步：更新设计案/执行案以匹配实现]
 ```
 **每个阶段都是下一阶段的必要前置条件。不可跳过或并行。PM 审查不通过则退回重做，不可进入下一阶段。**
@@ -62,7 +299,7 @@
 **必须包含的内容**：
-1. **系统清单**：游戏最终包含哪些系统（移动、交互、收集、小游戏、时间、NPC、经济、叙事等）
+1. **系统清单**：游戏最终包含哪些系统
 2. **元素清单**：游戏世界中的关键元素（角色、场景区域、收集品分类、NPC等）
 3. **系统关系**：各系统之间如何关联和互相影响
 4. **核心玩法循环**：玩家在游戏中做什么、为什么持续玩
@@ -71,41 +308,37 @@
 **产出形式**：
 - 可以有多个文档，按系统或主题拆分
 - 必须有一个**索引文档**把所有全局设计文档串联起来
- 产出位置：`docs/design/`
+- 产出位置：`docs/design/<阶段>/`（`prototype/` 或 `production/`）
 **PM 检查要点**：
 - 是否覆盖了游戏最终形态的所有主要系统？
 - 系统关系是否清晰（谁依赖谁、谁独立）？
 - 索引文档是否存在且能串联所有全局设计文档？
 **时间点**：项目初期集中产出，后续版本中可增量补充新系统的全局设计。
 ---
-### ② 版本Roadmap（PM 主导，策划配合）
+### ② 阶段路线图（PM 主导，策划配合）
-**目的**：根据全局设计案，明确分几个版本推进，每个版本大致做哪些内容。
+**目的**：定义当前阶段（原型或批量生产）分几个版本推进，每个版本探索什么方向。
 **必须包含的内容**：
-1. **版本列表**：从 v0.1 到 v1.0 有哪些版本
+1. **版本列表**：当前阶段有哪些版本
-2. **每个版本的核心目标**：这个版本验证什么、实现什么
+2. **每个版本的核心目标**：这个版本验证/实现什么
 3. **每个版本的范围概述**：大致包含哪些系统和内容
 4. **版本间的递进关系**：为什么先做这些后做那些
-5. **预估时间**：粗略的时间预估（不需要精确到天）
+5. **每个版本的验收标准**：怎样算"这个版本做完了"
-**产出位置**：`docs/plans/roadmap.md`
+**产出位置**：`docs/plans/prototype-roadmap.md` 或 `docs/plans/production-roadmap.md`
 **PM 检查要点**：
 - 每个版本的范围是否与全局设计案对齐？
- 版本间是否有清晰的递进逻辑（先核心后扩展）？
+- 版本间是否有清晰的递进逻辑？
 - 是否有版本范围过大的风险？
 **时间点**：全局设计案基本成型后产出，随版本推进可调整。
 ---
-### ③ 当前版本设计文档（策划）
+### ③ 当前版本设计（策划）
 **目的**：针对最近要做的版本，明确这个版本的目标、范围、需要哪些元素和系统、做到什么程度。
@@ -118,17 +351,13 @@
 3. **版本验收标准**：怎样算"这个版本做完了"？验收标准必须明确、可检验
 4. **本版本涉及的系统清单**：哪些系统需要在本版本实现（引用执行案）
-> **示例**：一个"场景漫游原型"版本的内容范围可能包括：主角使用占位胶囊体、场景用白盒几何体搭建其中3个区域、交互物先做5个验证核心流程、UI 用占位灰框。验收标准为"能在场景中自由移动并完成5个交互点的完整流程"。
+**产出形式**：可以是阶段路线图中的详细展开，也可以是独立的版本设计文档。放在 `docs/design/<阶段>/` 目录下。
 **产出位置**：`docs/design/vXX-design.md`（如 `docs/design/v01-design.md`）
 **与执行案的关系**：本文档是"这个版本要做什么"的总纲，执行案是"怎么实现每个系统"的细节。本文档引用执行案。
 **PM 检查要点**：
 - 版本目标定位是否明确？
 - 内容范围是否清晰，每种内容的完成度是否定义？
 - 验收标准是否明确、可检验？
- 范围是否与 roadmap 中该版本的定义一致？
+- 范围是否与阶段路线图一致？
 ---
@@ -143,7 +372,31 @@
 - **只描述行为和规则，不涉及技术实现**
 - **必须覆盖所有玩家可感知的行为**
 - **不能有模糊地带**——程序拿到执行案后不应有"这没写要怎么做"的疑问
- **具体参数数值**（速度、距离等）不需要策划提前确定，程序先设初始值，后续体验阶段调优。如果策划有初始建议值可以标注"建议值，可调"
+- **具体参数数值**不需要策划提前确定，程序先设初始值，后续体验阶段调优。如有建议值标注"建议值，可调"
 **执行案格式**：
 每个执行案文件顶部必须包含**迭代记录表头**：
 ```markdown
 # <系统名>执行案
 ## 迭代记录
 | 迭代版本 | 修改日期 | 状态 | 说明 |
 |----------|----------|------|------|
 | v0.1 | 2026-06-10 | 📝 设计中 | 初始版本 |
 > 状态标记：📝 设计中 | 🔄 开发中 | ✅ 已同步
 ---
 ## 系统概述
 （描述该系统做什么、服务于什么体验目标）
 ## 行为规则
 （当前最新状态的所有行为规则）
 ```
 **必须包含的内容**：
@@ -154,22 +407,23 @@
 5. **与其他系统的交互**：本系统与其他系统的关联和影响
 **不应包含的内容**：
- 用什么 UE5 组件实现
+- 用什么引擎组件实现
- 代码/蓝图架构怎么组织
+- 代码/脚本架构怎么组织
- 数据用什么格式存储（JSON/CSV/DataAsset 等）
+- 数据用什么格式存储
- 具体的参数精确值（如推镜 0.5 秒、文案延迟 0.2 秒等调优参数）
+- 具体的参数精确值（调优参数标注"建议值，可调"）
 **阶段差异**：
 | 维度 | 原型阶段 | 批量生产阶段 |
 |------|----------|-------------|
 | 行为覆盖 | 核心行为必须完整，非核心行为可略过 | 所有行为必须完整覆盖 |
 | 边界情况 | 影响核心玩法的必须处理，其余可略过 | 全部必须处理 |
 | 系统间关联 | 核心关联必须说明 | 全部必须说明 |
 **产出形式**：
- 每个系统一份执行案，按系统拆分
+- 每个系统一份执行案，放在 `docs/design/<阶段>/` 目录下
- 产出位置：`docs/design/systems/<系统名>-execution.md`（如 `docs/design/systems/player-controller-execution.md`）
+- 文件命名：`<系统名>-execution.md`（如 `player-controller-execution.md`）
- 如果某系统的全局设计文档中恰好已经写清了当前版本的执行级细节，可以直接引用，但需确保满足执行案的完整性标准
+- 不按版本分文件，通过迭代记录表头追踪变更
 **PM 检查要点**：
 - 是否覆盖了该系统所有"玩家可感知的行为"？
 - 是否有模糊地带（行为描述含"大概"、"可能"、"看情况"等词）？
 - 是否误入了技术细节（说了用什么 UE5 组件、数据格式等）？
 - 边界情况是否都处理了（多物体重叠、交互中断、异常状态等）？
 - 程序拿到这份文档后，能否不问策划任何问题就实现功能？
 ---
@@ -182,45 +436,50 @@
 **审查内容**：
 1. **完整性**：是否覆盖了该系统所有玩家可感知的行为？每个操作是否明确了触发条件、触发后表现、结束条件？
-2. **清晰性**：是否有模糊地带（"大概"、"可能"、"看情况"等词）？行为描述是否无歧义？程序拿到后能否不问策划任何问题就实现功能？
+2. **清晰性**：是否有模糊地带？行为描述是否无歧义？程序拿到后能否不问策划任何问题就实现功能？
-3. **边界情况**：异常/极端情况下的系统行为是否都处理了（多物体重叠、交互中断、异常状态等）？
+3. **边界情况**：异常/极端情况下的系统行为是否都处理了？
 4. **系统间关联**：与其他系统的关联和影响是否说明？
-5. **技术越界检查**：是否误入了技术细节（UE5 组件、数据格式、代码架构）？精确参数值是否标注为"建议值，可调"而非固定值？
+5. **技术越界检查**：是否误入了技术细节？精确参数值是否标注为"建议值，可调"？
 **阶段差异**：
 | 维度 | 原型阶段 | 批量生产阶段 |
 |------|----------|-------------|
 | 完整性 | 核心行为必须完整，非核心可略过 | 全部必须完整 |
 | 边界情况 | 影响核心玩法的必须处理 | 全部必须处理 |
 | 严格度 | 重点关注核心行为质量 | 逐条全面检查 |
 **判定**：
 - **通过** → 进入 ⑤ 程序设计
- **不通过** → 退回策划修改，列出具体问题清单，策划修正后重新提交审查
+- **不通过** → 退回策划修改，列出具体问题清单
-**产出**：PM 审查记录（附在执行案文档末尾或记录在 `docs/plans/review-log.md`）
+**产出**：PM 审查记录（记录在 `docs/plans/review-log.md`）
 ---
 ### ⑤ 程序设计（程序）
-**目的**：程序读完策划的执行案后，设计 UE5 中的具体实现方案。
+**目的**：程序读完策划的执行案后，设计具体的实现方案。
 **前置条件**：执行案（④）已就绪，且 PM 审查通过。
 **必须包含的内容**：
-1. **实现方案**：针对执行案中的每条行为规则，说明打算如何在 UE5 中实现
+1. **实现方案**：针对执行案中的每条行为规则，说明打算如何实现
-   - UE5 有现成功能的 → 说明用哪个功能、如何配置（如 Enhanced Input System、CharacterMovementComponent）
+2. **类与组件架构**：需要哪些类/组件？继承关系？挂载方式？
-   - UE5 没有直接对应的 → 说明自己如何实现，复杂系统需单独出一份技术文档描述
+3. **数据流**：数据从哪里来？系统之间如何通信？
-2. **类与组件架构**：需要哪些 C++ 类/蓝图？继承关系？组件挂载方式？
+4. **美术资源需求清单**：实现这个功能需要哪些美术资源（模型、动画、UI 等），具体到数量和尺寸
 3. **数据流**：数据从哪里来（配置表/DataAsset/硬编码）？系统之间如何通信？
 4. **美术资源需求清单**：实现这个功能需要哪些美术资源？
   - 角色骨骼模型？绑定要求？
   - 哪几个动画？每个动画的触发时机和参数？
   - 哪几个交互物模型？尺寸参考？
   - UI 需要哪些图？图标？背景？尺寸？
 5. **技术风险和注意事项**：实现中可能遇到的技术难点
-**产出位置**：`docs/technical/<系统名>-tech.md`
+**阶段差异**：
-**PM 检查要点**：
+| 维度 | 原型阶段 | 批量生产阶段 |
- 程序设计是否完整回应了执行案中的**每条**行为规则？
+|------|----------|-------------|
- 美术资源需求是否列得具体（不是"需要一些模型"，而是"需要1个冰箱模型，约1.7m高"）？
+| 架构 | 可以用占位方案，不需要生产级 | 需要生产级架构，考虑扩展性 |
- 是否有执行案中的行为规则在技术方案中被遗漏？
+| 数据流 | 允许硬编码 | 数据应配置化 |
 | 美术需求 | 允许简化描述 | 必须具体到尺寸和数量 |
 **产出位置**：`docs/technical/<系统名>-tech.md`
 ---
@@ -228,21 +487,17 @@
 **触发时机**：程序完成技术设计（⑤）后，进入美术产出（⑥）之前。
 **审查人**：PM
 **审查内容**：
-1. **执行案覆盖度**：程序设计是否完整回应了执行案中的**每条**行为规则？逐条对照，不得有遗漏
+1. **执行案覆盖度**：程序设计是否完整回应了执行案中的每条行为规则？逐条对照
-2. **美术资源需求**：需求是否列得具体（不是"需要一些模型"，而是"需要1个冰箱模型，约1.7m高"）？每个资源的数量、尺寸、触发时机是否明确？
+2. **美术资源需求**：需求是否列得具体？数量、尺寸、触发时机是否明确？
-3. **类与组件架构**：C++ 类/蓝图的继承关系和组件挂载方式是否清晰？
+3. **类与组件架构**：继承关系和挂载方式是否清晰？
-4. **数据流**：数据从哪里来？系统之间如何通信？是否明确？
+4. **数据流**：是否明确？
-5. **技术风险**：是否识别了实现中可能遇到的技术难点？
+5. **技术风险**：是否识别？
 **判定**：
 - **通过** → 进入 ⑥ 美术产出
- **不通过** → 退回程序修改，列出具体问题清单（如遗漏的行为规则、不够具体的美术需求等），程序修正后重新提交审查
+- **不通过** → 退回程序修改
 **产出**：PM 审查记录（附在技术方案文档末尾或记录在 `docs/plans/review-log.md`）
 ---
@@ -252,86 +507,104 @@
 **前置条件**：程序设计（⑤）已就绪，且 PM 审查通过。
-**产出内容**：
+**阶段差异**：
-1. **美术资产**（模型、贴图、UI 图等）
+| 维度 | 原型阶段 | 批量生产阶段 |
-2. **资产清单**：哪个资源在哪个路径，方便程序引用
+|------|----------|-------------|
 | 资产质量 | 允许占位资源、开发者自行处理 | 正式资产，符合风格指南 |
 | 完成度 | 能用就行 | 必须满足规格要求 |
 **产出位置**：
 - 资产放 `Content/` 对应目录
 - 清单记录在 `docs/art/asset-manifest.md` 或直接在技术方案中更新
 **PM 检查要点**：
 - 程序资源需求清单中的每一项是否都有对应的美术产出？
 - 资产路径是否记录清晰，程序能找到？
 **当前阶段特殊说明**：v0.1 的美术资产可由开发者直接处理（使用占位模型/免费资源）。后续版本应建立 AI 生成流程（提示词 → 出图 → 出 3D 模型）。
 ---
 ### PM 审查：美术资产验收门
 **触发时机**：美术完成资产产出（⑥）后，进入程序实现（⑦）之前。
 **审查人**：PM
 **审查内容**：
-1. **需求覆盖度**：逐项对照程序设计中的美术资源需求清单，每一项是否都有对应的美术产出？
+1. **需求覆盖度**：逐项对照美术资源需求清单
-2. **资产到位确认**：资产文件是否已放置在 `Content/` 对应目录？路径是否记录在资产清单中？
+2. **资产到位确认**：资产文件是否已放置在对应目录？
-3. **资产规格**：模型尺寸、贴图尺寸等是否符合需求清单中的规格要求？
+3. **资产规格**：尺寸、格式等是否符合需求？
-4. **缺失项处理**：如有未到位的资产，是否有明确的处理方案（开发者自行处理/使用占位/延期）？
+4. **缺失项处理**：未到位资产是否有明确处理方案？
 **判定**：
 - **通过** → 进入 ⑦ 程序实现
 - **不通过** → 退回美术补齐，列出具体缺失项和规格不符项，美术修正后重新提交审查
 **产出**：PM 审查记录（记录在 `docs/plans/review-log.md`）
 ---
 ### ⑦ 程序实现（程序）
-**目的**：基于程序设计方案和美术资产，实际编写代码和蓝图。
+**目的**：基于程序设计方案和美术资产，实际编写代码。
-**前置条件**：
+**阶段差异**：
 - 执行案（④）已就绪，且 PM 审查通过
 - 程序设计方案（⑤）已就绪，且 PM 审查通过
 - 必需的美术资产（⑥）已就位，且 PM 审查通过（或开发者已确认自行处理占位方案）
-**执行要求**：
+| 维度 | 原型阶段 | 批量生产阶段 |
- 严格按照程序设计方案执行，如有偏差需记录原因
+|------|----------|-------------|
- 实现完成后安排体验阶段，收集反馈调整参数
+| 代码质量 | 允许硬编码、快速实现 | 不允许硬编码，数据配置化，代码达发布标准 |
- 每个系统实现后进行独立验证
+| 验证 | 核心流程跑通即可 | 每个系统独立验证 + 集成验证 |
-**产出位置**：`Source/`（C++）、`Content/Blueprints/`（蓝图）、`Content/Data/`（DataAsset）
+**实现后必须执行文档同步**：对照实际实现更新设计案和执行案，确保文档与代码一致。
 ---
 ## 文档同步流程
 **每个版本迭代完成后，必须同步更新设计案和执行案**。这是流水线的必要环节，不可跳过。
 ### 同步步骤
 1. **体验验证**：实际体验实现结果，确认核心行为是否符合预期
 2. **对照差异**：将实现结果与设计案/执行案对照，找出差异
 3. **更新文档**：
   - 设计案：更新与实际不符的系统描述
   - 执行案：更新行为规则以匹配实际实现，在迭代记录中新增一行
 4. **标记状态**：执行案迭代记录中该版本标记为 ✅ 已同步
 ### 为什么必须同步
 - 文档是下一个迭代的起点。如果文档和实现不一致，下一个迭代会基于错误假设
 - PM 的质量门审查基于文档。文档不准确会导致审查无效
 - 程序在实现时可能发现设计的问题并做了调整，这些调整必须反映到文档中
 ---
 ## PM 诊断检查清单
-PM 在每次 `/plan` 调用时，针对**当前版本**逐项检查流水线状态：
+PM 在每次 `/plan` 调用时，先判断宏观阶段，再针对**当前版本**逐项检查流水线状态。
 ### 宏观阶段判断
 | 检查项 | 判断方式 | 结果 |
 |--------|----------|------|
 | 项目处于哪个开发阶段？ | 检查 `concept.md` → 检查核心玩法是否已有可玩原型 → 检查内容是否已完整 | 草案 / 原型 / 批量生产 / 测试发布 |
 | 阶段信息是否记录在 `current.md`？ | 检查 `current.md` 中是否有阶段标注 | 如无则补充 |
 ### 版本流水线检查
 | 检查项 | 检查方式 | 通过条件 |
 |--------|----------|----------|
-| ① 全局设计案是否存在且完整？ | 检查 `docs/design/` 中的全局设计文档和索引 | 覆盖所有主要系统，有索引串联 |
+| ① 全局设计案是否存在且完整？ | 检查 `docs/design/<阶段>/` 中的全局设计文档和索引 | 覆盖所有主要系统，有索引串联 |
-| ② Roadmap 是否存在？ | 检查 `docs/plans/roadmap.md` | 版本列表、每版本目标、递进关系明确 |
+| ② 阶段路线图是否存在？ | 检查 `docs/plans/<阶段>-roadmap.md` | 版本列表、每版本目标、递进关系明确 |
-| ③ 当前版本设计文档是否完整？ | 检查 `docs/design/vXX-design.md` | 回答了版本定位、内容范围、验收标准 |
+| ③ 当前版本设计是否完整？ | 检查版本设计文档或路线图中的详细描述 | 回答了版本定位、内容范围、验收标准 |
-| ④ 执行案是否齐全？ | 检查 `docs/design/systems/` 对应执行案 | 每个涉及系统的行为规则都已明确，无模糊地带，无技术越界 |
+| ④ 执行案是否齐全？ | 检查 `docs/design/<阶段>/` 对应执行案 | 每个涉及系统的核心行为规则都已明确 |
-| **PM 审查**：执行案质量门 | 对照执行案质量标准逐项检查 | 完整性、清晰性、边界情况、技术越界全部通过 |
+| **PM 审查**：执行案质量门 | 对照质量标准逐项检查（注意阶段严格度差异） | 完整性、清晰性、边界情况通过 |
-| ⑤ 程序设计方案是否齐全？ | 检查 `docs/technical/` 对应文档 | 每个执行案都有对应技术方案，美术资源需求已列出 |
+| ⑤ 程序设计方案是否齐全？ | 检查 `docs/technical/` 对应文档 | 每个执行案都有对应技术方案 |
-| **PM 审查**：程序设计质量门 | 执行案与技术方案逐条对照，检查美术需求 | 行为规则全覆盖，美术需求具体 |
+| **PM 审查**：程序设计质量门 | 执行案与技术方案逐条对照 | 行为规则全覆盖，美术需求具体 |
-| ⑥ 美术资产是否就位？ | 检查程序设计中的资源需求清单 vs 实际资产 | 所有必需资产已产出或开发者已确认自行处理 |
+| ⑥ 美术资产是否就位？ | 检查资源需求清单 vs 实际资产 | 所有必需资产已产出或有处理方案 |
-| **PM 审查**：美术资产验收门 | 美术需求清单 vs 实际资产逐项对照 | 每项需求都有对应产出，路径和规格符合 |
+| **PM 审查**：美术资产验收门 | 需求清单 vs 实际资产逐项对照 | 每项需求都有对应产出 |
-| ⑦ 程序实现是否完成？ | 检查 `Source/`、`Content/` 中的实际文件 | 上游产出均已就位，实现工作可启动或已完成 |
+| ⑦ 程序实现是否完成？ | 检查实际文件 | 实现完成 |
 | **文档同步** | 对照实现检查文档是否一致 | 设计案/执行案已同步更新 |
-**遇到第一个未通过的即为当前应推进的阶段。PM 审查未通过的，退回对应角色修改后重新审查。**
+**遇到第一个未通过的即为当前应推进的阶段。**
 **注意**：原型阶段的质量门检查允许在非核心维度上降低严格度，批量生产阶段必须逐条全面检查。
 ---
 ## 文档质量检查标准
-以下标准对应流水线中的三道 PM 质量门。PM 审查时按对应清单逐项检查。
+以下标准对应流水线中的三道 PM 质量门。
 ### 执行案质量标准（对应「执行案质量门」）
@@ -342,17 +615,21 @@ PM 在每次 `/plan` 调用时，针对**当前版本**逐项检查流水线状
 - [ ] 与其他系统的关联是否说明？
 **清晰性检查**：
- [ ] 是否有模糊地带（"大概"、"可能"、"看情况"等词）？
+- [ ] 是否有模糊地带？
- [ ] 行为描述是否无歧义（如"移动"是否明确了参考系）？
+- [ ] 行为描述是否无歧义？
 - [ ] 程序拿到后能否不问策划任何问题就实现功能？
 **边界检查**：
- [ ] 是否误入了技术细节（UE5 组件、数据格式、代码架构）？
+- [ ] 是否误入了技术细节？
 - [ ] 精确参数值是否标注为"建议值，可调"而非固定值？
 **迭代记录检查**：
 - [ ] 迭代记录表头是否存在且填写完整？
 - [ ] 已完成版本的文档是否已同步（✅ 已同步）？
 ### 程序设计质量标准（对应「程序设计质量门」）
- [ ] 是否完整回应了执行案中的**每条**行为规则？（逐条对照）
+- [ ] 是否完整回应了执行案中的每条行为规则？（逐条对照）
 - [ ] 美术资源需求是否列得具体（尺寸、数量、触发时机）？
 - [ ] 类与组件架构是否清晰？
 - [ ] 数据流是否明确？
@@ -360,33 +637,15 @@ PM 在每次 `/plan` 调用时，针对**当前版本**逐项检查流水线状
 ### 美术资产验收标准（对应「美术资产验收门」）
- [ ] 程序资源需求清单中的每一项是否都有对应的美术产出？（逐项对照）
+- [ ] 资源需求清单中的每一项是否都有对应的美术产出？（逐项对照）
- [ ] 资产文件是否已放置在 `Content/` 对应目录？
+- [ ] 资产文件是否已放置在对应目录？
- [ ] 资产路径是否记录在资产清单中，程序能找到？
+- [ ] 资产路径是否记录清晰？
- [ ] 资产规格（模型尺寸、贴图尺寸等）是否符合需求？
+- [ ] 资产规格是否符合需求？
 - [ ] 未到位资产是否有明确的处理方案？
 ---
-## 游戏开发阶段知识
+## 单人独立开发的特殊考量
 PM 必须理解游戏开发各阶段的特征，用于诊断产出是否匹配：
 | 阶段 | 特征 | 应有交付物 | 工作重点 |
 |------|------|-----------|----------|
 | **预制作** | 想清楚再动手 | 全局设计案、版本Roadmap、各系统执行案、美术风格指南 | 确保设计充分，避免后期返工 |
 | **核心系统制作** | 先跑通最小可玩循环 | 角色控制器、核心交互系统、基础UI框架、白盒场景、占位模型 | 系统能跑起来比做得漂亮重要 |
 | **内容填充** | 依赖核心系统稳定 | 场景细节、交互数据配置、正式美术资产、音效 | 核心系统锁定后再大规模填充 |
 | **集成联调** | 多系统协同工作 | 系统集成测试记录、Bug列表、性能报告 | 暴露和解决集成问题 |
 | **打磨发布** | 不加新功能 | Bug修复记录、平衡性调整、优化报告、构建版本 | 稳定性和品质 |
 **诊断判断**：
 - 处于「预制作」但缺少关键设计文档 → 标记风险，建议补齐
 - 处于「核心系统制作」但执行案未完成 → 建议先收尾执行案再写代码
 - 处于「内容填充」但核心系统不稳定 → 建议先修复核心系统
 - 某角色产出明显落后于其他角色 → 标记为瓶颈
 ### 单人独立开发的特殊考量
 - **无法并行**——同一时间只能做一件事，选择更关键
 - **精力有限**——避免一次性拆分太多并行任务
@@ -5,16 +5,20 @@
 ## 当前里程碑：v0.1 场景漫游与环境交互
 **开发阶段**: 原型阶段
 **阶段路线图**: `docs/plans/prototype-roadmap.md`
 **设计目录**: `docs/design/prototype/`
 ### 流水线状态
 - 当前阶段：④执行案（①②③基本就绪）
- 阻塞点：执行案缺失，需先整理文档再补齐执行案
+- 阻塞点：执行案缺失，需先补齐执行案
 ### 进行中
 > 按流水线阶段和优先级排列
- [ ] 整理全局设计文档和头脑风暴文档，按规范放置 — ①全局设计
+- [ ] 整理全局设计文档，按规范放置 — ①全局设计
- [ ] 整理 v0.1 相关文档，按规范输出版本设计文档（v01-design.md）— ③版本设计
+- [ ] 产出 v0.1 版本设计文档（v01-design.md）— ③版本设计
 - [ ] 产出玩家控制器执行案（player-controller-execution.md）— ④执行案
 - [ ] 产出交互系统执行案（interaction-system-execution.md）— ④执行案
 - [ ] 产出收集系统 v0.1 执行案（collection-system-execution.md）— ④执行案
@@ -28,12 +32,13 @@
 - [ ] 程序设计质量门审查 — PM
 - [ ] v0.1 美术资产产出 — ⑥美术产出（v0.1 允许开发者自行处理占位资源）
 - [ ] 美术资产验收门审查 — PM
- [ ] 清理 UE5 模板变体代码 — ⑦实现（无流水线依赖，可并行）
+- [ ] 清理引擎模板变体代码 — ⑦实现（无流水线依赖，可并行）
 - [ ] 角色控制器实现 — ⑦实现
 - [ ] 交互系统实现 — ⑦实现
 - [ ] v0.1 场景白盒搭建（6个区域）— ⑦实现
 - [ ] 收集计数系统实现 — ⑦实现
 - [ ] v0.1 验收测试
 - [ ] 文档同步（更新设计案/执行案匹配实现）
 ### 已完成
@@ -51,27 +56,28 @@
 - [x] 场景与世界观详细设计（scene-world.md）
 - [x] 小游戏系统设计（minigame-system.md）
 - [x] 叙事框架设计（narrative-framework.md）
- [x] 主角角色设计（protagonist-character.md）— 远端同步新增
+- [x] 主角角色设计（protagonist-character.md）
 - [x] 开发流程重构：四阶段框架 + 阶段目录 + 文档同步
 ---
 ## 设计文档状态
-### 已完成
+### 已完成（均位于 `docs/design/prototype/`）
- [x] `docs/design/game-vision.md` — 游戏愿景
+- [x] `game-vision.md` — 游戏愿景
- [x] `docs/design/v01-scope.md` — v0.1 范围定义
+- [x] `v01-scope.md` — v0.1 范围定义
- [x] `docs/design/systems/player-controller.md` — 玩家控制设计
+- [x] `player-controller.md` — 玩家控制设计
- [x] `docs/design/systems/interaction-system.md` — 交互系统设计
+- [x] `interaction-system.md` — 交互系统设计
- [x] `docs/design/activities/scene-v01-suburban.md` — v0.1 场景设计
+- [x] `scene-v01-suburban.md` — v0.1 场景设计
- [x] `docs/design/systems/collection-system.md` — 收集系统设计
+- [x] `collection-system.md` — 收集系统设计
- [x] `docs/design/minigame-system.md` — 小游戏系统设计
+- [x] `minigame-system.md` — 小游戏系统设计
- [x] `docs/design/narrative-framework.md` — 叙事框架设计
+- [x] `narrative-framework.md` — 叙事框架设计
- [x] `docs/design/scene-world.md` — 场景与世界观详细设计
+- [x] `scene-world.md` — 场景与世界观详细设计
- [x] `docs/design/protagonist-character.md` — 主角角色设计
+- [x] `protagonist-character.md` — 主角角色设计
 ### 待产出
 - [ ] `docs/plans/roadmap.md` 更新 — 路线图补全 v0.5-v0.7
- [ ] `docs/design/economy-system.md` — 零花钱经济系统设计（v0.3 前产出即可）
+- [ ] `economy-system.md` — 零花钱经济系统设计（v0.3 前产出即可）
- [ ] `docs/design/time-system.md` — 一天时间循环系统设计（v0.3 前产出即可）
+- [ ] `time-system.md` — 一天时间循环系统设计（v0.3 前产出即可）
@@ -0,0 +1,77 @@
 # 原型阶段路线图
 > 定义原型阶段的版本迭代计划。每个版本验证一个核心假设。
 ---
 ## 阶段目标
 验证"在千禧年城郊场景中自由漫游并与环境交互"的核心体验可行性。确认核心玩法循环跑得通、好玩。
 ---
 ## 版本规划
 ### v0.1 — 场景漫游与环境交互
 **验证假设**：在场景中自由移动并与环境交互，这个基础体验成立吗？
 **范围**：
 - 第三人称角色控制器（移动 + 摄像机）
 - 交互系统（观察 + 拾取）
 - v0.1 场景白盒（6 个区域）
 - 收集计数系统（基础版）
 **验收标准**：
 - 6 个区域均可探索
 - 25+ 交互点可正常触发
 - 10 个收集品可拾取
 - 整体帧率稳定 30+
 ---
 ### v0.2 — 第一个完整小游戏
 **验证假设**：小游戏好不好玩？操作手感行不行？
 **范围**：
 - 弹珠小游戏完整实现
 - NPC 对话基础版
 - 基础音效（脚步、交互、环境）
 - 家和小卖部的室内空间
 **验收标准**：（待 v0.1 完成后详细定义）
 ---
 ### v0.3 — 一天时间循环
 **验证假设**：时间流动带来的日常节奏感成立吗？
 **范围**：
 - 一天四时段的时间系统
 - 时段与光照变化联动
 - 零花钱经济系统
 - 时段与 NPC 位置/行为联动
 **验收标准**：（待 v0.2 完成后详细定义）
 ---
 ## 递进关系
 ```
 v0.1 场景漫游 → v0.2 小游戏 → v0.3 时间循环
     │              │               │
     └─ 验证"世界有味道"  └─ 验证"游戏好玩"  └─ 验证"世界是活的"
 ```
 v0.1 是基础（场景 + 交互），v0.2 在此基础上加玩法深度，v0.3 加时间维度让世界活起来。
 ---
 ## 版本调整记录
 | 日期 | 调整内容 |
 |------|----------|
 | 2026-06-03 | 初始版本规划 |
@@ -1,76 +1,40 @@
 # 项目路线图
-## v0.1 — 场景漫游与环境交互
+> 项目总览路线图，简要列出各开发阶段和版本。
-
+> 每个阶段的详细版本规划见对应的阶段路线图。
 **目标**: 验证"在千禧年城郊场景中自由漫游并与环境交互"的核心体验
 ### 策划（Design）
 - [x] 游戏愿景文档（game-vision.md）
 - [x] v0.1 范围定义（v01-scope.md）
 - [x] 玩家控制设计（player-controller.md）
 - [x] 交互系统设计（interaction-system.md）
 - [x] v0.1 场景设计（scene-v01-suburban.md）
 ### 程序（Programming）
 - [ ] 角色控制器（第三人称移动 + 摄像机）
 - [ ] 交互系统实现（检测 + 提示 UI + 文本显示）
 - [ ] v0.1 场景白盒搭建（6个区域）
 - [ ] 交互内容数据配置（25+ 观察点 + 10 拾取品）
 - [ ] 收集计数系统
 ### 美术（Art）
 - [ ] v0.1 场景白盒的视觉优化（用色彩区分区域）
 - [ ] 主角占位模型（Lowpoly 简单角色）
 - [ ] 关键交互物体的简单模型（冰箱、电视、小卖部柜台等）
 - [ ] 基础光照和氛围设定
 ### 验收
 - [ ] 6个区域均可探索
 - [ ] 25+ 交互点可正常触发
 - [ ] 10个收集品可拾取
 - [ ] 整体帧率稳定30+
 ---
-## v0.2 — 第一个完整小游戏
+## 原型阶段
-**目标**: 在空地中加入弹珠小游戏，验证操作手感和趣味性
+> 验证核心玩法可行性。详见 [prototype-roadmap.md](prototype-roadmap.md)
-（待 v0.1 完成后详细规划）
+| 版本 | 核心验证 | 状态 |
-
+|------|----------|------|
-预期内容：
+| v0.1 | 场景漫游与环境交互 | 🔄 进行中 |
- 弹珠小游戏完整实现
+| v0.2 | 第一个完整小游戏 | ⬜ 待开始 |
- 蹲下探索系统
+| v0.3 | 一天时间循环 | ⬜ 待开始 |
 - NPC 对话基础版
 - 基础音效（脚步、交互、环境）
 - 家和小卖部的室内空间
 ---
-## v0.3 — 一天时间循环
+## 批量生产阶段
-**目标**: 实现上午/下午/傍晚/夜晚的时间流动，验证日常节奏感
+> 核心玩法验证通过后，完善外围系统，填充内容与资产。
 > 详见 production-roadmap.md（待原型阶段完成后创建）
-（待 v0.2 完成后详细规划）
+| 版本 | 核心内容 | 状态 |
-
+|------|----------|------|
-预期内容：
+| v0.4 | 叙事与收集 | ⬜ 待规划 |
- 一天四时段的时间系统
+| v0.5 | 多小游戏 + 收集扩展 | ⬜ 待规划 |
- 时段与光照变化联动
+| v0.6 | 乡下章节 | ⬜ 待规划 |
- 时段与 NPC 位置/行为联动
+| v0.7 | 整合 + 多支线 + 结局 | ⬜ 待规划 |
 - 时间触发的事件
 ---
-## v0.4 — 叙事与收集
+## 测试与发布阶段
-**目标**: 加入剧情事件链和完整的收集图鉴系统
+> Bug 修复 + 微调 + 发布
-（待 v0.3 完成后详细规划）
+| 版本 | 核心内容 | 状态 |
-
+|------|----------|------|
---
+| v1.0 | 全内容打磨 + 发布 | ⬜ 待规划 |
 ## v1.0 — 正式发布
 **目标**: 完整的暑假故事，从放假到开学前夕
 （远期目标，待前序版本完成后规划）