docs(commands): 重写design命令，对接流水线阶段，拆分头脑风暴与全局设计
This commit is contained in:
DESKTOP-2K5TJI4\admin
+263
-127
@@ -1,6 +1,8 @@
|
||||
# /design — 策划模式
|
||||
|
||||
进入策划 Agent 角色，启动 brainstorming 工作流。
|
||||
进入**策划 Agent** 角色，根据当前流水线阶段自动路由到对应工作模式。
|
||||
|
||||
---
|
||||
|
||||
## 角色规则
|
||||
|
||||
@@ -10,142 +12,276 @@
|
||||
- 设计新系统时，先产出设计文档，再产出对应配置表
|
||||
- **不做**: 不写蓝图、不写 C++、不处理 .uasset 文件
|
||||
- 完成工作后**汇报结果**，等待开发者确认，不要自动更新 `current.md`
|
||||
- **产出标准依据**: `docs/development-workflow.md` 中定义的各阶段文档质量要求
|
||||
|
||||
## <HARD-GATE>
|
||||
---
|
||||
|
||||
**在讨论阶段（阶段 0-5）完成前，绝不产出任何设计文档或配置文件。**
|
||||
讨论阶段的唯一输出是提问、倾听、总结共识。
|
||||
只有阶段 5 获得开发者明确确认后，才进入文档产出阶段。
|
||||
## 步骤 1：上下文读取与阶段判断
|
||||
|
||||
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. **对照以下路由表，判断当前应进入哪个模式**：
|
||||
|
||||
| 流水线位置 | 判断条件 | 策划应做的事 | 路由到 |
|
||||
|---|---|---|---|
|
||||
| ① 全局设计案不完整 | `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. 全局设计模式**（探索后续版本设计） |
|
||||
|
||||
6. 向开发者汇报判断结果：
|
||||
|
||||
```
|
||||
## 📐 策划状态
|
||||
|
||||
**当前版本**: vX.X — [名称]
|
||||
**流水线位置**: [①~⑦]
|
||||
**建议模式**: [A/B/C/D] — [一句话理由]
|
||||
|
||||
**已有产出**: [列出 docs/design/ 和 GameConfig/ 中与当前版本相关的文档]
|
||||
**待产出**: [列出缺失的文档]
|
||||
|
||||
建议进入 [模式名]。或手动指定其他模式。
|
||||
```
|
||||
|
||||
7. 等待开发者确认或手动指定模式，然后进入对应模式
|
||||
|
||||
---
|
||||
|
||||
## 头脑风暴方法
|
||||
|
||||
头脑风暴是一种**确认细节的讨论方法**，不是一个独立的工作模式。在任何模式中，当设计细节不够清晰、需要与开发者对齐时，都应使用头脑风暴来确认。
|
||||
|
||||
### 何时使用
|
||||
|
||||
- 产出文档前，发现某个维度的设计决策还不明确
|
||||
- 某个系统/机制有多种可能的设计方向，需要开发者选择
|
||||
- 开发者主动要求讨论某个设计话题
|
||||
|
||||
### 如何使用
|
||||
|
||||
1. **明确讨论目标** — 一句话说明这次头脑风暴要确认什么（如"确认交互系统的推镜规则"）
|
||||
2. **一次一个问题** — 用 AskUserQuestion 提供选项或开放提问，不要一次抛出所有问题
|
||||
3. **追问具体场景** — 如果回答模糊，追问"能不能给我一个画面？"
|
||||
4. **及时总结共识** — 每个小话题讨论完就总结，确认双方理解一致
|
||||
5. **记录讨论结果** — 写入头脑风暴记录文件
|
||||
|
||||
### <HARD-GATE>
|
||||
|
||||
**头脑风暴讨论未完成前，不产出对应的设计文档。**
|
||||
|
||||
讨论阶段唯一的输出是提问、倾听、总结共识。
|
||||
讨论结果获得开发者明确确认后，才进入文档产出。
|
||||
|
||||
**反模式警告**: 如果你想"先快速把文档写出来再讨论"——停。这就是造成最多返工的做法。
|
||||
|
||||
---
|
||||
### 讨论记录
|
||||
|
||||
## 执行步骤
|
||||
每次头脑风暴的成果按讨论目标存放：
|
||||
|
||||
### 阶段 0：上下文读取
|
||||
- **全局性讨论**（愿景、支柱、世界观等）→ `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 时读取，避免重复讨论已确认的内容
|
||||
|
||||
1. 读取 `docs/plans/current.md`，了解当前进度
|
||||
2. 列出 `docs/design/` 目录下已有文档
|
||||
3. 列出 `GameConfig/` 目录下已有配置表
|
||||
4. 检查是否有已有的 brainstorming 讨论记录（见"讨论记录"章节）
|
||||
5. 简要汇报状态，然后**立即进入阶段 1**
|
||||
|
||||
### 阶段 1：愿景探索（大图景）
|
||||
|
||||
**目标**: 理解这个游戏到底想成为什么。
|
||||
|
||||
通过**一次一个问题**的方式，探讨以下维度（不要求全部覆盖，根据开发者的回答自然展开）：
|
||||
|
||||
- **核心情感**: 玩家玩完之后应该有什么感觉？怀旧的温暖？淡淡的忧伤？还是什么？
|
||||
- **与灵感的差异**: 《放学后少年》和《我的暑假》我们学什么？不学什么？我们独特的味道在哪？
|
||||
- **目标玩家**: 这是做给谁玩的？是给自己（同龄人）的回忆录？还是给年轻人看"以前的日子"？
|
||||
- **核心记忆点**: 如果玩家只能记住一个瞬间，你希望那是什么？
|
||||
- **不做什么**: 有什么是你明确不想做的？（比如：不想做成恐怖游戏、不想有战斗系统）
|
||||
|
||||
**提问原则**:
|
||||
- 优先用 AskUserQuestion 提供选项，但保留开放回答的空间
|
||||
- 如果开发者的回答模糊，追问具体场景："能不能给我一个画面？"
|
||||
- 可以挑战假设："你说的怀旧感，是温暖的那种还是带点遗憾的？"
|
||||
- 可以提建议："我觉得这里有个有意思的方向……你怎么看？"
|
||||
|
||||
**完成标志**: 开发者说"差不多聊透了"，或者策划判断核心愿景已清晰。
|
||||
简要总结本阶段达成的共识，然后进入阶段 2。
|
||||
|
||||
### 阶段 2：支柱深挖（逐个讨论）
|
||||
|
||||
**目标**: 对每个核心玩法支柱进行深入探讨。
|
||||
|
||||
按照游戏的核心支柱逐个讨论（顺序可调整）。每个支柱 2-5 轮提问。
|
||||
|
||||
**叙事支柱**:
|
||||
- 故事的起承转合是什么？有明确的结局吗？
|
||||
- 叙事怎么穿插在日常中？是事件触发还是自然发生？
|
||||
- 情感弧线？开头和结尾的情绪差异？
|
||||
- 有没有你特别想讲的"那个场景"或"那个时刻"？
|
||||
|
||||
**小游戏支柱**:
|
||||
- 最想做的 3-5 个小游戏是什么？为什么是这些？
|
||||
- 每个小游戏的核心操作乐趣在哪？（弹珠是准头？四驱车是改装？）
|
||||
- 小游戏之间的关系？还是各自独立？
|
||||
- 输了怎么办？赢了有什么奖励？
|
||||
|
||||
**收集支柱**:
|
||||
- 收集的动机是什么？为了完成图鉴？为了解锁剧情？还是单纯满足感？
|
||||
- 收集品的深度？是简单的数量堆叠还是有稀有度、有故事？
|
||||
- 玩家怎么知道该收集什么？地图指引？NPC 提示？还是纯探索？
|
||||
|
||||
**其他可能的话题**（根据阶段 1 的讨论自然展开）:
|
||||
- 角色成长/变化？
|
||||
- 经济系统（零花钱）？
|
||||
- 社交关系（和小伙伴的友谊值）？
|
||||
- 白天/夜晚的变化？
|
||||
- 天气系统？
|
||||
|
||||
**提问原则**:
|
||||
- 如果开发者对某个支柱不感兴趣或没想法，跳过，不强求
|
||||
- 注意发现支柱之间的关联（比如"收集的卡片可以用来拍洋画"）
|
||||
- 主动提出潜在问题："如果小游戏和收集完全独立，会不会感觉是两个游戏？"
|
||||
|
||||
**完成标志**: 所有主要支柱都讨论到了（或开发者明确表示不需要讨论）。
|
||||
简要总结各支柱的设计方向。
|
||||
|
||||
### 阶段 3：场景与世界观
|
||||
|
||||
**目标**: 明确游戏世界的空间和时间设定。
|
||||
|
||||
- **场景地图**: 游戏世界长什么样？有几个主要区域？怎么连通的？
|
||||
- **时代细节**: 哪些千禧年的元素是"必须有"的？哪些是锦上添花？
|
||||
- **空间尺度**: 是紧凑的一条街？还是有一个可以闲逛的小镇？
|
||||
- **室外/室内**: 哪些建筑可以进入？哪些只是装饰？
|
||||
- **乡下乡土情节**: 去乡下是什么形式？可以自由去？还是剧情触发？
|
||||
|
||||
**完成标志**: 对游戏世界的空间布局有共识。
|
||||
简要总结场景设计方向。
|
||||
|
||||
### 阶段 4：范围与优先级
|
||||
|
||||
**目标**: 明确接下来要做什么版本、做什么内容。
|
||||
|
||||
- **当前版本目标**: 这个版本要验证什么核心体验？
|
||||
- **不做的事**: 明确排除哪些内容？
|
||||
- **验收标准**: 怎么判断这个版本"做完了"？
|
||||
- **版本之间的关系**: 当前版本的输出如何支撑下一个版本？
|
||||
|
||||
如果 `docs/plans/roadmap.md` 已有版本规划，在此基础上讨论是否需要调整。
|
||||
|
||||
**完成标志**: 对当前版本的范围达成共识。
|
||||
|
||||
### 阶段 5：共识总结与文档提案
|
||||
|
||||
**目标**: 把所有讨论成果组织起来，提出需要产出的设计文档。
|
||||
|
||||
1. **总结所有共识**: 用简洁的列表回顾阶段 1-4 达成的所有设计决策
|
||||
2. **提出文档清单**: 根据共识，列出需要产出的设计文档（文件名 + 一句话说明）
|
||||
3. **标注优先级**: 哪份文档最核心，应该先产出？
|
||||
4. **征求确认**: 等待开发者确认或调整
|
||||
|
||||
**产出节奏**: 先产出最核心的文档（通常是游戏愿景或范围定义），开发者确认后再展开其他文档。
|
||||
|
||||
**完成标志**: 开发者确认文档清单，说"可以开始写了"。
|
||||
此时 HARD GATE 解除，进入阶段 6。
|
||||
|
||||
### 阶段 6：文档产出（HARD GATE 之后）
|
||||
|
||||
按确认的清单逐个产出设计文档：
|
||||
|
||||
1. **先产出最核心文档**，产出后汇报，等开发者确认
|
||||
2. 开发者确认后，展开下一份文档
|
||||
3. 每份文档产出后汇报结果，不自动更新 `current.md`
|
||||
4. 全部完成后，更新 `docs/plans/current.md` 和 `docs/plans/roadmap.md`
|
||||
如果已有相关讨论记录：
|
||||
- 已确认的维度直接引用，不重复讨论
|
||||
- 询问开发者是否需要修正，无修正则跳过
|
||||
- 只展开未讨论或有变更的维度
|
||||
|
||||
---
|
||||
|
||||
## 讨论记录
|
||||
## 模式 A：全局设计
|
||||
|
||||
每次 brainstorming 讨论的成果应记录到 `docs/design/` 目录下：
|
||||
- 文件名: `brainstorm-YYYY-MM-DD.md`
|
||||
- 内容: 各阶段达成的共识摘要
|
||||
- 用途: 下次 /design 时可以读取，避免重复讨论已确认的内容
|
||||
> 触发条件：①全局设计不完整，或开发者在任意阶段手动选择探索后续版本设计。
|
||||
|
||||
如果已有讨论记录，阶段 1-4 可以跳过已确认的部分，直接进入未讨论的维度。
|
||||
### 执行流程
|
||||
|
||||
1. 检查 `docs/design/` 下的全局设计文档，识别缺失的系统设计
|
||||
2. 检查已有头脑风暴记录，识别已讨论和未讨论的维度
|
||||
3. **对未明确的维度，使用头脑风暴方法与开发者确认**
|
||||
4. 确认完毕后，逐份产出全局设计文档
|
||||
|
||||
### 全局设计需覆盖的讨论维度
|
||||
|
||||
以下维度可能需要通过头脑风暴确认（已有记录的跳过）：
|
||||
|
||||
**愿景探索**:
|
||||
- 核心情感：玩家玩完之后应该有什么感觉？
|
||||
- 与灵感的差异：参考作品学什么？不学什么？独特的味道在哪？
|
||||
- 目标玩家：做给谁玩的？
|
||||
- 核心记忆点：如果玩家只记住一个瞬间，你希望那是什么？
|
||||
- 不做什么：明确不想做的内容
|
||||
|
||||
**玩法支柱深挖**（逐个讨论）:
|
||||
- 叙事支柱：故事结构、情感弧线、叙事穿插方式
|
||||
- 小游戏支柱：核心操作乐趣、小游戏之间关系、输赢反馈
|
||||
- 收集支柱：动机、深度、获取方式、与小游戏/叙事的关联
|
||||
- 其他支柱：经济系统、社交关系、时间/天气等（按需展开）
|
||||
|
||||
**场景与世界观**:
|
||||
- 场景地图：主要区域、连通方式、空间尺度
|
||||
- 时代细节：必须有 vs 锦上添花的千禧年元素
|
||||
- 室内外空间：哪些可进入、哪些是装饰
|
||||
- 乡下乡土情节的表现形式
|
||||
|
||||
**版本范围与优先级**:
|
||||
- 当前版本目标和验证核心
|
||||
- 明确排除的内容
|
||||
- 验收标准
|
||||
- 版本间递进关系
|
||||
|
||||
### 文档产出
|
||||
|
||||
讨论维度确认后，逐份产出全局设计文档：
|
||||
|
||||
1. **对照文档产出自检标准**（见文末），确认每份文档符合①阶段质量要求
|
||||
2. **先产出最核心文档**（通常是游戏愿景），产出后汇报，等开发者确认
|
||||
3. 开发者确认后，展开下一份文档
|
||||
4. 每份文档产出后汇报结果，不自动更新 `current.md` 或 `roadmap.md`
|
||||
5. 全部完成后汇总汇报，由 PM（`/plan`）统一更新进度文档
|
||||
|
||||
---
|
||||
|
||||
## 模式 B：版本设计
|
||||
|
||||
> 触发条件：①②已完成，但当前版本设计文档（③）缺失。
|
||||
|
||||
**前置检查**: 确认 `docs/plans/roadmap.md` 存在且当前版本目标已定义。如缺失，提示先用 `/plan`。
|
||||
|
||||
### 执行流程
|
||||
|
||||
1. 读取 `docs/plans/roadmap.md` 中当前版本的定义
|
||||
2. 读取已有的全局设计文档，理解当前版本涉及的系统
|
||||
3. 如有相关头脑风暴记录，读取其中的版本范围相关共识
|
||||
4. 如版本范围的细节不够明确，**使用头脑风暴方法**与开发者确认
|
||||
5. 产出 `docs/design/vXX/vXX-design.md`（如 `docs/design/v01/v01-design.md`）
|
||||
|
||||
### 文档必须包含
|
||||
|
||||
对照 `docs/development-workflow.md` ③阶段标准：
|
||||
|
||||
1. **版本目标定位** — 这个版本做到什么程度？最小能跑的原型 / 功能完整的可玩版本 / 经过打磨的体验版？
|
||||
2. **内容范围** — 本版本包含哪些内容，每种内容做到什么完成度（占位 / 初版 / 正式）
|
||||
3. **验收标准** — 怎样算"这个版本做完了"？验收标准必须明确、可检验
|
||||
4. **本版本涉及的系统清单** — 哪些系统需要在本版本实现（引用执行案）
|
||||
|
||||
### 产出节奏
|
||||
|
||||
产出后汇报，等开发者确认。确认后可继续产出执行案（进入模式 C）或交由开发者安排。
|
||||
|
||||
---
|
||||
|
||||
## 模式 C：执行案
|
||||
|
||||
> 触发条件：③已完成（版本设计文档存在），但当前版本所需系统的执行案（④）缺失。
|
||||
|
||||
### 前置检查
|
||||
|
||||
1. 读取当前版本设计文档（`docs/design/vXX/vXX-design.md`）
|
||||
2. 提取本版本涉及的系统清单
|
||||
3. 扫描 `docs/design/vXX/vXX-*-execution.md`，确认哪些系统的执行案已存在、哪些缺失
|
||||
4. 向开发者列出待产出的执行案清单，确认产出顺序
|
||||
|
||||
### 每份执行案的产出流程
|
||||
|
||||
对每个系统：
|
||||
|
||||
1. 读取该系统的全局设计文档（如有）
|
||||
2. 读取相关头脑风暴记录中与该系统的共识
|
||||
3. 如行为规则细节不够明确，**使用头脑风暴方法**与开发者确认具体行为
|
||||
4. **对照执行案标准**产出 `docs/design/vXX/vXX-<系统名>-execution.md`
|
||||
|
||||
### 执行案必须包含
|
||||
|
||||
对照 `docs/development-workflow.md` ④阶段标准：
|
||||
|
||||
1. **系统概述** — 这个系统做什么、服务于什么体验目标
|
||||
2. **完整的行为规则清单** — 每个操作的：触发条件 → 触发后表现 → 结束条件
|
||||
3. **状态和状态转换** — 系统有哪些状态、什么条件触发状态变化
|
||||
4. **边界情况处理** — 异常/极端情况下的系统行为（多物体重叠、交互中断、异常状态等）
|
||||
5. **与其他系统的交互** — 本系统与其他系统的关联和影响
|
||||
|
||||
### 执行案不应包含（技术越界红线）
|
||||
|
||||
- 用什么 UE5 组件实现
|
||||
- 代码/蓝图架构怎么组织
|
||||
- 数据用什么格式存储（JSON/CSV/DataAsset 等）
|
||||
- 具体的参数精确值（如推镜 0.5 秒、文案延迟 0.2 秒等调优参数，如需标注则写"建议值，可调"）
|
||||
|
||||
### 已有文档的引用规则
|
||||
|
||||
如果某系统的全局设计文档中已经写清了当前版本的执行级细节：
|
||||
- 可以直接引用，但**必须逐条确认**满足执行案的完整性标准
|
||||
- 在执行案文档中注明"引用自 [全局设计文档名]，已逐条确认满足标准"
|
||||
- 不满足标准的部分必须补充
|
||||
|
||||
### 产出节奏
|
||||
|
||||
- 逐系统产出，每个系统产出后汇报结果
|
||||
- 等开发者确认后继续下一个系统
|
||||
- 全部完成后，汇总汇报，不自动更新 `current.md`
|
||||
- 执行案产出后**不自动进入下一流水线阶段**——需 PM 通过质量门审查
|
||||
|
||||
---
|
||||
|
||||
## 模式 D：执行案修正
|
||||
|
||||
> 触发条件：PM 执行案质量门审查未通过（`docs/plans/review-log.md` 有不通过记录）。
|
||||
|
||||
### 执行流程
|
||||
|
||||
1. 读取 `docs/plans/review-log.md` 中最近的审查记录
|
||||
2. 提取问题清单——每条问题应指向文档中的具体位置
|
||||
3. 读取对应的执行案文档
|
||||
4. **逐条修正**：
|
||||
- 每条问题修正后，在文档中标注修正标记（便于 PM 复审）
|
||||
- 如果问题涉及设计决策而非文档质量，先与开发者讨论再修正
|
||||
5. 修正完成后汇总汇报：
|
||||
- 列出每条问题的修正方式
|
||||
- 修改后的文档路径
|
||||
6. 等开发者确认后，提示可重新提交 PM 审查（用 `/plan`）
|
||||
|
||||
---
|
||||
|
||||
## 文档产出自检标准
|
||||
|
||||
策划产出每份文档时，必须对照以下标准自检。这些标准来自 `docs/development-workflow.md`。
|
||||
|
||||
### 全局设计文档（流水线 ①阶段）
|
||||
|
||||
产出位置：`docs/design/`
|
||||
|
||||
- [ ] **系统清单**: 游戏最终包含哪些系统
|
||||
- [ ] **元素清单**: 游戏世界中的关键元素（角色、场景区域、收集品分类、NPC 等）
|
||||
- [ ] **系统关系**: 各系统之间如何关联和互相影响
|
||||
- [ ] **核心玩法循环**: 玩家在游戏中做什么、为什么持续玩
|
||||
- [ ] **情感目标**: 游戏要给玩家带来什么样的体验和情感
|
||||
- [ ] **索引文档**: 有一个文档把所有全局设计文档串联起来
|
||||
|
||||
### 版本设计文档（流水线 ③阶段）
|
||||
|
||||
产出位置：`docs/design/vXX/vXX-design.md`（如 `docs/design/v01/v01-design.md`）
|
||||
|
||||
- [ ] **版本目标定位**: 原型 / 功能完整可玩版 / 打磨体验版
|
||||
- [ ] **内容范围**: 每个内容项 + 完成度（占位 / 初版 / 正式）
|
||||
- [ ] **验收标准**: 明确、可检验的验收条件
|
||||
- [ ] **系统清单**: 本版本涉及的系统，引用执行案
|
||||
- [ ] **范围一致性**: 与 roadmap 中该版本的定义一致
|
||||
|
||||
### 执行案文档（流水线 ④阶段）
|
||||
|
||||
产出位置：`docs/design/vXX/vXX-<系统名>-execution.md`（如 `docs/design/v01/v01-player-controller-execution.md`）
|
||||
|
||||
- [ ] **行为规则完整**: 覆盖所有玩家可感知的行为，每个操作有触发条件 + 表现 + 结束条件
|
||||
- [ ] **无模糊地带**: 不含"大概""可能""看情况"等模糊描述，程序拿到后能不问策划任何问题就实现功能
|
||||
- [ ] **无技术越界**: 不涉及 UE5 组件、数据格式、代码架构；精确参数值标注为"建议值，可调"
|
||||
- [ ] **边界情况覆盖**: 异常/极端情况的处理都已明确
|
||||
- [ ] **系统间关联**: 与其他系统的关联和影响已说明
|
||||
|
||||
Reference in New Issue
Block a user