docs(workflow): 新增游戏开发工作流文档，定义版本流水线与PM质量门
This commit is contained in:
DESKTOP-2K5TJI4\admin
+289
-130
@@ -32,6 +32,295 @@
|
||||
|
||||
---
|
||||
|
||||
## 版本开发流水线
|
||||
|
||||
每个版本的开发必须按以下流水线阶段**严格顺序推进**。PM 的核心职责是判断当前版本处于流水线的哪个阶段，并推动进入下一阶段。
|
||||
|
||||
### 流水线阶段总览
|
||||
|
||||
```
|
||||
① 策划：版本目标案 → ② 策划：系统设定案 → ③ 程序设计 → ④ 美术产出 → ⑤ 程序实现
|
||||
```
|
||||
|
||||
**每个阶段都是下一阶段的必要前置条件**。不可跳过或并行。
|
||||
|
||||
---
|
||||
|
||||
### ① 策划：版本目标案（一份）
|
||||
|
||||
**目的**：明确这个版本在整体愿景中的定位——要做什么、做到什么程度、放进去什么内容。
|
||||
|
||||
**必须回答的问题**：
|
||||
|
||||
1. **版本目标定位**：这个版本是要搭一个功能架子（能跑就行的最小原型），还是做出一个经过一定打磨的能正常运转的系统？
|
||||
2. **内容范围**：
|
||||
- **主角**：需要主角吗？临时占位模型（胶囊体/方块人）还是初版正式模型？
|
||||
- **场景范围**：完整地图还是部分区域？如果是部分，具体哪几个区域？
|
||||
- **场景搭建方式**：白模（BSP/基础几何体）？网上找免费资源凑？还是出初版正式模型？
|
||||
- **场景布局**：物体先挨个码放测试，还是已经有布局规划需要按规划摆放？
|
||||
- **交互物**：需要哪些交互物？全部还是先做几个验证系统？
|
||||
- **UI**：需要哪些 UI？占位样式还是正式样式？
|
||||
3. **版本验收标准**：怎样算"这个版本做完了"？
|
||||
|
||||
**产出位置**：`docs/design/vXX-target.md`（如 `docs/design/v01-target.md`）
|
||||
|
||||
**注意**：现有的 `v01-scope.md` 如果已经覆盖了以上内容，可以复用，不必重复产出。PM 需要检查已有文档是否充分回答了上述问题。
|
||||
|
||||
---
|
||||
|
||||
### ② 策划：系统设定案（每系统一份）
|
||||
|
||||
**目的**：为每个涉及的系统出详细的**行为规则说明书**——系统"应该表现成什么样"，但不涉及技术实现细节。
|
||||
|
||||
**必须回答的问题**：
|
||||
|
||||
系统设定案需要明确的是**玩家可感知的行为**，而不是底层技术方案。例如：
|
||||
- 角色移动：能不能跑？能不能蹲？按什么键？横移是侧身走还是转身跑？移动方向相对于什么（摄像机/世界）？
|
||||
- 摄像机：能否手动旋转？能否拉远推近？角色静止时面朝哪？旋转有没有角度限制？
|
||||
- 交互触发：多远触发？多个交互物重叠怎么办？交互中能否移动？
|
||||
- 具体参数数值（速度、距离等）**不需要策划提前确定**，程序先设初始值，后续体验阶段调优。
|
||||
|
||||
**不需要回答的问题**（这些是程序设计阶段的事）：
|
||||
- 用 UE5 的什么组件实现
|
||||
- 代码架构怎么组织
|
||||
- 数据用什么格式存储
|
||||
|
||||
**产出位置**：`docs/design/systems/<系统名>.md`
|
||||
|
||||
**PM 检查要点**：
|
||||
- 系统设定案是否覆盖了该系统所有"玩家可感知的行为"？
|
||||
- 是否有模糊地带（比如"移动"没说清横移行为）？
|
||||
- 是否误入了技术细节（说了用什么 UE5 组件）？如果有，提醒策划聚焦行为层
|
||||
|
||||
---
|
||||
|
||||
### ③ 程序设计（每系统一份技术方案）
|
||||
|
||||
**目的**：程序读完策划的系统设定案后，设计 UE5 中的具体实现方案。
|
||||
|
||||
**必须包含的内容**：
|
||||
|
||||
1. **实现方案**：针对策划的每个行为规则，说明打算如何在 UE5 中实现
|
||||
- UE5 有现成功能的 → 说明用哪个功能、如何配置（如 Enhanced Input System、CharacterMovementComponent）
|
||||
- UE5 没有直接对应的 → 说明自己如何实现，复杂系统需要单独出一份技术文档描述
|
||||
2. **类与组件架构**：需要哪些 C++ 类/蓝图？继承关系？组件挂载方式？
|
||||
3. **数据流**：数据从哪里来（配置表/DataAsset/硬编码）？系统之间如何通信？
|
||||
4. **美术资源需求清单**：实现这个功能需要哪些美术资源？
|
||||
- 角色骨骼模型？绑定要求？
|
||||
- 哪几个动画？每个动画的触发时机和参数？
|
||||
- 哪几个交互物模型？尺寸参考？
|
||||
- UI 需要哪些图？图标？背景？尺寸？
|
||||
|
||||
**产出位置**：`docs/technical/<系统名>-tech.md`
|
||||
|
||||
**PM 检查要点**：
|
||||
- 程序设计是否完整回应了策划的系统设定案中的每条行为规则？
|
||||
- 美术资源需求是否列得具体（不是"需要一些模型"，而是"需要1个冰箱模型，约1.7m高"）？
|
||||
|
||||
---
|
||||
|
||||
### ④ 美术产出
|
||||
|
||||
**目的**：根据程序输出的美术资源需求清单，产出对应资产。
|
||||
|
||||
**产出内容**：
|
||||
1. 美术资产（模型、贴图、UI 图等）
|
||||
2. **资产清单**：哪个资源在哪个路径，方便程序引用
|
||||
|
||||
**产出位置**：资产放 `Content/` 对应目录，清单记录在 `docs/art/asset-manifest.md` 或直接在技术方案中更新
|
||||
|
||||
**当前阶段特殊说明**：v0.1 的美术资产可由开发者直接处理（使用占位模型/免费资源）。后续版本应建立 AI 生成流程（提示词 → 出图 → 出 3D 模型）。
|
||||
|
||||
---
|
||||
|
||||
### ⑤ 程序实现
|
||||
|
||||
**目的**：基于程序设计方案和美术资产，实际编写代码和蓝图。
|
||||
|
||||
**执行要求**：
|
||||
- 实现前必须确认 ②③④ 的对应文档已就绪
|
||||
- 严格按照程序设计方案执行，如有偏差需记录原因
|
||||
- 实现完成后安排体验阶段，收集反馈调整参数
|
||||
|
||||
---
|
||||
|
||||
## 执行步骤
|
||||
|
||||
### 阶段 0：上下文读取
|
||||
|
||||
1. 读取 `docs/plans/current.md`，了解当前进度
|
||||
2. 读取 `docs/plans/roadmap.md`，了解里程碑规划
|
||||
3. 扫描 `docs/design/` 已有文档（策划产出）
|
||||
4. 扫描 `GameConfig/` 已有配置（策划产出）
|
||||
5. 扫描 `Source/` 和 `Content/` 已有代码/蓝图（程序产出）
|
||||
6. 扫描 `docs/art/` 已有美术规格（美术产出）
|
||||
7. 扫描 `docs/technical/` 已有技术方案（程序产出）
|
||||
|
||||
### 阶段 1：流水线阶段判断（仅审查当前版本）
|
||||
|
||||
针对**当前版本**（如 v0.1），判断其处于流水线的哪个阶段：
|
||||
|
||||
**检查清单**（按顺序逐项判断，遇到第一个未通过的即为当前应推进的阶段）：
|
||||
|
||||
| 检查项 | 检查方式 | 通过条件 |
|
||||
|--------|----------|----------|
|
||||
| ① 版本目标案是否存在且完整？ | 检查 `docs/design/vXX-target.md`（或已有的 scope 文档是否覆盖） | 回答了版本定位、内容范围、验收标准 |
|
||||
| ② 系统设定案是否齐全？ | 检查 `docs/design/systems/` 对应文档 | 每个涉及系统的行为规则都已明确，无模糊地带 |
|
||||
| ③ 程序设计方案是否齐全？ | 检查 `docs/technical/` 对应文档 | 每个系统设定案都有对应的技术方案，美术资源需求已列出 |
|
||||
| ④ 美术资产是否就位？ | 检查程序设计中的资源需求清单 vs 实际资产 | 所有必需资产已产出或开发者已确认自行处理 |
|
||||
| ⑤ 程序实现是否完成？ | 检查 `Source/`、`Content/` 中的实际文件 | 流水线 ③④ 产出均已就位，实现工作可启动或已完成 |
|
||||
|
||||
### 阶段 2：任务审查（按角色分类）
|
||||
|
||||
将当前版本的任务按角色分类，标注每项任务在流水线中的位置：
|
||||
|
||||
**按角色列出**：
|
||||
- **策划任务**：标注对应流水线阶段（①版本目标案 / ②系统设定案）
|
||||
- **程序任务**：标注对应流水线阶段（③程序设计 / ⑤程序实现）
|
||||
- **美术任务**：标注对应流水线阶段（④美术产出）
|
||||
|
||||
**阻塞关系判断**：
|
||||
- 如果当前流水线阶段的前置条件未满足 → 标记为「等待前置」
|
||||
- 如果当前阶段有可推进的工作 → 标记为「可启动」
|
||||
|
||||
### 阶段 3：风险检测
|
||||
|
||||
1. 设计文档中是否有行为定义模糊的地带（如移动没说清横移方式、摄像机没说能否手动旋转）
|
||||
2. 是否有隐性依赖未在 current.md 中体现
|
||||
3. 是否有范围蔓延风险（版本目标之外的额外内容混入）
|
||||
4. 策划案是否误入了技术实现细节（应该只描述行为，不描述技术方案）
|
||||
5. 某角色产出是否成为瓶颈（流水线阻塞在某个阶段）
|
||||
|
||||
### 阶段 4：优先级建议
|
||||
|
||||
1. 输出具体的下一步建议，**严格遵循流水线顺序**
|
||||
2. 如果当前版本停留在流水线阶段 ①②（策划阶段），优先推动策划产出
|
||||
3. 如果当前版本停留在流水线阶段 ③（程序设计），优先推动程序设计方案
|
||||
4. 如果当前版本停留在流水线阶段 ④⑤，推动美术产出或程序实现
|
||||
5. 如果在阶段 ①② 发现现有文档不足，建议补齐后再推进下游
|
||||
6. 建议一个执行顺序（本次开发 session 该做什么）
|
||||
7. 单人开发，建议一次只推进流水线中的一个阶段
|
||||
|
||||
### 阶段 5：互动讨论
|
||||
|
||||
1. 等待开发者反馈：同意 / 调整 / 追问
|
||||
2. 开发者可要求 PM 深入诊断某个方面（见「深入诊断」章节）
|
||||
3. 根据反馈修正优先级
|
||||
4. 讨论结束后，根据确认结果更新 `current.md` 和/或 `roadmap.md`
|
||||
5. 更新后展示变更内容，等待开发者最终确认
|
||||
|
||||
---
|
||||
|
||||
## 输出格式
|
||||
|
||||
每次 `/plan` 调用后，按以下结构输出：
|
||||
|
||||
```markdown
|
||||
## 📊 项目状态
|
||||
|
||||
**当前版本**: vX.X — [版本名称]
|
||||
**流水线阶段**: ①②③④⑤ 中的哪个阶段 — [一句话描述]
|
||||
**整体进度**: [已完成/总任务] ([百分比])
|
||||
|
||||
**各角色进度**:
|
||||
- 策划: [完成度] — [简要说明]
|
||||
- 程序: [完成度] — [简要说明]
|
||||
- 美术: [完成度] — [简要说明]
|
||||
|
||||
## 🔄 流水线检查
|
||||
|
||||
> 仅审查当前版本
|
||||
|
||||
| 阶段 | 状态 | 说明 |
|
||||
|------|------|------|
|
||||
| ① 版本目标案 | ✅完成 / ⚠️不完整 / ❌缺失 | [具体说明] |
|
||||
| ② 系统设定案 | ✅完成 / ⚠️有模糊地带 / ❌缺失 | [列出缺失或模糊的系统] |
|
||||
| ③ 程序设计 | ✅完成 / ⚠️部分完成 / ❌未开始 | [具体说明] |
|
||||
| ④ 美术产出 | ✅完成 / ⚠️部分完成 / ❌未开始 | [具体说明] |
|
||||
| ⑤ 程序实现 | ✅完成 / 🔄进行中 / ❌未开始 | [具体说明] |
|
||||
|
||||
## 📋 任务清单（按角色）
|
||||
|
||||
### 策划任务
|
||||
- [ ] 任务名 — 阶段①/② — [状态]
|
||||
|
||||
### 程序任务
|
||||
- [ ] 任务名 — 阶段③/⑤ — [状态]
|
||||
|
||||
### 美术任务
|
||||
- [ ] 任务名 — 阶段④ — [状态]
|
||||
|
||||
## ⚠️ 风险提醒
|
||||
|
||||
[列出 1-3 个风险点。无风险时显示"当前无明显风险"]
|
||||
|
||||
## 🎯 建议下一步
|
||||
|
||||
[1-2 个具体建议，附理由，严格遵循流水线顺序]
|
||||
|
||||
---
|
||||
（等待开发者反馈或指示）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 深入诊断
|
||||
|
||||
当开发者要求深入诊断时（"帮我诊断一下"、"产出跟得上吗"、"各角色进度均衡吗"），PM 应执行以下分析：
|
||||
|
||||
### 逐角色对比
|
||||
|
||||
对每个角色做三方对比：
|
||||
|
||||
| 维度 | 说明 |
|
||||
|------|------|
|
||||
| **应有产出** | 当前流水线阶段该角色应该交付的内容 |
|
||||
| **实际产出** | 扫描对应目录后发现的实际文件 |
|
||||
| **标记进度** | `current.md` 中标记的完成/进行中/待开始状态 |
|
||||
|
||||
### 文档质量检查
|
||||
|
||||
不仅检查文档是否存在，还要检查文档质量：
|
||||
|
||||
- **版本目标案**：是否完整回答了版本定位、内容范围、验收标准？
|
||||
- **系统设定案**：是否有行为定义模糊的地带？是否误入了技术细节？
|
||||
- **程序设计方案**：是否完整回应了系统设定案中的每条行为规则？美术资源需求是否列得具体？
|
||||
|
||||
### 不一致检测
|
||||
|
||||
- current.md 标记为进行中，但对应目录无实际文件 → 标记为「可能滞后」
|
||||
- current.md 标记为待开始，但对应目录已有实际文件 → 标记为「可能需要更新进度」
|
||||
- 某角色应有产出但目录为空 → 标记为「产出缺口」
|
||||
- 流水线阶段跳跃（下游已开始但上游未完成）→ 标记为「流程违规风险」
|
||||
|
||||
### 诊断输出格式
|
||||
|
||||
```markdown
|
||||
## 🔍 深入诊断
|
||||
|
||||
### 流水线状态
|
||||
- 当前阻塞点: [流水线的哪个阶段没通过]
|
||||
- 阻塞原因: [具体说明]
|
||||
|
||||
### 策划
|
||||
- 应有产出: [列出]
|
||||
- 实际产出: [列出发现的文件]
|
||||
- 文档质量: [是否有模糊地带、是否误入技术细节]
|
||||
- 进度标记: [从 current.md 读取]
|
||||
- 诊断: [匹配/滞后/超前] — [具体说明]
|
||||
|
||||
### 程序
|
||||
（同上格式）
|
||||
|
||||
### 美术
|
||||
（同上格式）
|
||||
|
||||
### 综合判断
|
||||
[整体诊断结论和建议]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 游戏开发阶段知识
|
||||
|
||||
PM 必须理解游戏开发各阶段的特征和应有的交付物，用于诊断产出是否匹配：
|
||||
@@ -57,133 +346,3 @@ PM 必须理解游戏开发各阶段的特征和应有的交付物，用于诊
|
||||
- 心流重要——建议按「完整做完一个小系统」而非「同时推进多个系统」的方式工作
|
||||
- 早期验证——越早能跑起来看到东西，越不容易失去动力
|
||||
- Agent 之间通过文档交接——PM 是信息枢纽
|
||||
|
||||
---
|
||||
|
||||
## 执行步骤
|
||||
|
||||
### 阶段 0：上下文读取
|
||||
|
||||
1. 读取 `docs/plans/current.md`，了解当前进度
|
||||
2. 读取 `docs/plans/roadmap.md`，了解里程碑规划
|
||||
3. 扫描 `docs/design/` 已有文档（策划产出）
|
||||
4. 扫描 `GameConfig/` 已有配置（策划产出）
|
||||
5. 扫描 `Source/` 和 `Content/` 已有代码/蓝图（程序产出）
|
||||
6. 扫描 `docs/art/` 已有美术规格（美术产出）
|
||||
|
||||
### 阶段 1：阶段诊断 + 产出匹配
|
||||
|
||||
1. 基于四个维度评估进度：
|
||||
- **设计完成度**：策划文档和配置表的完成比例
|
||||
- **核心系统完成度**：程序基础系统的实现比例
|
||||
- **内容完成度**：场景、数据配置等内容的填充比例
|
||||
- **资产完成度**：美术资产的制作比例
|
||||
2. 对照当前阶段的应有交付物清单，检查是否有缺失
|
||||
3. 如有缺失，标记为风险项
|
||||
4. 一句话总结当前状态
|
||||
|
||||
### 阶段 2：关键路径分析
|
||||
|
||||
1. 从 current.md 的进行中/待开始任务中识别依赖关系
|
||||
2. 标注关键路径上的任务（阻塞其他任务的任务）
|
||||
3. 标注可延后的任务
|
||||
4. 标注等待前置条件的任务
|
||||
|
||||
### 阶段 3：风险检测
|
||||
|
||||
1. 检查是否有任务描述过于模糊（缺少验收标准）
|
||||
2. 检查是否有隐性依赖未在 current.md 中体现
|
||||
3. 检查是否有范围蔓延风险
|
||||
4. 检查是否有「看似简单但可能很复杂」的陷阱任务
|
||||
5. 检查某角色产出是否成为瓶颈
|
||||
|
||||
### 阶段 4：优先级建议
|
||||
|
||||
1. 输出具体的下一步建议
|
||||
2. 理由基于：关键路径 / 阻塞其他任务 / 尽早验证核心体验 / 风险规避
|
||||
3. 建议一个执行顺序（本次开发 session 该做什么）
|
||||
4. 如果当前有多个并行任务，建议收束到 1-2 个
|
||||
|
||||
### 阶段 5：互动讨论
|
||||
|
||||
1. 等待开发者反馈：同意 / 调整 / 追问
|
||||
2. 开发者可要求 PM 深入诊断某个方面（见「深入诊断」章节）
|
||||
3. 根据反馈修正优先级
|
||||
4. 讨论结束后，根据确认结果更新 `current.md` 和/或 `roadmap.md`
|
||||
5. 更新后展示变更内容，等待开发者最终确认
|
||||
|
||||
---
|
||||
|
||||
## 输出格式
|
||||
|
||||
每次 `/plan` 调用后，按以下结构输出：
|
||||
|
||||
```markdown
|
||||
## 📊 项目状态
|
||||
|
||||
**当前阶段**: [阶段名称] — [一句话描述]
|
||||
**整体进度**: [已完成/总任务] ([百分比])
|
||||
|
||||
**各角色进度**:
|
||||
- 策划: [完成度] — [简要说明]
|
||||
- 程序: [完成度] — [简要说明]
|
||||
- 美术: [完成度] — [简要说明]
|
||||
|
||||
## 🗺️ 关键路径
|
||||
|
||||
[按依赖顺序列出当前关键路径上的任务]
|
||||
|
||||
## ⚠️ 风险提醒
|
||||
|
||||
[列出 1-3 个风险点。无风险时显示"当前无明显风险"]
|
||||
|
||||
## 🎯 建议下一步
|
||||
|
||||
[1-2 个具体建议，附理由]
|
||||
|
||||
---
|
||||
（等待开发者反馈或指示）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 深入诊断
|
||||
|
||||
当开发者要求深入诊断时（"帮我诊断一下"、"产出跟得上吗"、"各角色进度均衡吗"），PM 应执行以下分析：
|
||||
|
||||
### 逐角色对比
|
||||
|
||||
对每个角色做三方对比：
|
||||
|
||||
| 维度 | 说明 |
|
||||
|------|------|
|
||||
| **应有产出** | 当前阶段该角色应该交付的内容（来自阶段知识表） |
|
||||
| **实际产出** | 扫描对应目录后发现的实际文件 |
|
||||
| **标记进度** | `current.md` 中标记的完成/进行中/待开始状态 |
|
||||
|
||||
### 不一致检测
|
||||
|
||||
- current.md 标记为进行中，但对应目录无实际文件 → 标记为「可能滞后」
|
||||
- current.md 标记为待开始，但对应目录已有实际文件 → 标记为「可能需要更新进度」
|
||||
- 某角色应有产出但目录为空 → 标记为「产出缺口」
|
||||
|
||||
### 诊断输出格式
|
||||
|
||||
```markdown
|
||||
## 🔍 深入诊断
|
||||
|
||||
### 策划
|
||||
- 应有产出: [列出]
|
||||
- 实际产出: [列出发现的文件]
|
||||
- 进度标记: [从 current.md 读取]
|
||||
- 诊断: [匹配/滞后/超前] — [具体说明]
|
||||
|
||||
### 程序
|
||||
（同上格式）
|
||||
|
||||
### 美术
|
||||
（同上格式）
|
||||
|
||||
### 综合判断
|
||||
[整体诊断结论和建议]
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user