DESKTOP-2K5TJI4\admin
0c38b42a2c
- 草案文档：合并「玩家能做什么」+「游戏氛围与风格」为「玩家核心游玩内容与感受」 - 草案文档：新增「核心受众画像」和「市场定位与三大卖点」字段(6→7项) - 全局设计案：移除与草案重复的「核心玩法循环」和「情感目标」 - 删除冗余的③当前版本设计步骤，其内容完成度信息合并到②路线图 - 流水线步骤从③-⑧重编号为③-⑦，全文件40+处引用同步更新
673 lines
28 KiB
Markdown
673 lines
28 KiB
Markdown
# 游戏开发工作流
|
||
|
||
> 本文档定义游戏项目的开发阶段、版本开发流水线、角色职责、产出标准和质量检查规则。
|
||
> 版本开发流水线（③-⑦）中各步骤严格按序推进，不可跳过或并行。①②为阶段级前置，仅在阶段开始时执行一次，后续版本迭代中不重复执行。
|
||
|
||
---
|
||
|
||
## 角色定义
|
||
|
||
| 角色 | 职责 | 产出位置 | PM 如何判断其进度 |
|
||
|------|------|----------|-------------------|
|
||
| **策划** (Design) | 玩法设计、数值平衡、叙事、系统机制 | `docs/design/`、`GameConfig/` | 扫描 `docs/design/` 和 `GameConfig/` 目录中的文件 |
|
||
| **程序** (Dev) | 系统实现、技术架构、Bug 修复 | `Source/`、`Content/`、`docs/technical/` | 扫描对应目录中的文件 |
|
||
| **美术** (Art) | 美术需求分析、资产规格、风格指南 | `docs/art/`、`Content/` | 扫描对应目录中的文件 |
|
||
| **PM** | 进度追踪、优先级决策、风险预警、流水线推进 | `docs/plans/` | 不产出设计文档、代码或美术资产 |
|
||
|
||
### 协作规则
|
||
|
||
- **策划先行**：设计文档是其他角色的需求源
|
||
- **程序读设计**：实现前必须先读取对应设计文档和配置表
|
||
- **文档即交接**：Agent 之间不直接通信，通过共享文档目录交接
|
||
- **冲突时用户说了算**：玩法/数值/叙事的最终决定权在用户
|
||
- **PM 是信息枢纽**：跨角色的信息同步和阻塞排查由 PM 负责
|
||
|
||
### 进度汇报规则
|
||
|
||
- 各 Agent 完成工作后汇报结果，不自动更新项目进度
|
||
- PM负责验收各Agent的工作结果，给出行动建议
|
||
- 用户确认PM建议后，由 PM 统一更新项目进度，调整计划
|
||
|
||
---
|
||
|
||
## 开发阶段
|
||
|
||
项目开发分为四个宏观阶段，每个阶段有不同的关注重点和流程重量。
|
||
|
||
```
|
||
草案阶段 ─── "这个游戏是什么？" ─── 轻量流程，每项目一次
|
||
↓
|
||
原型阶段 ─── "这个游戏好玩吗？" ─── 版本流水线（轻量），多版本迭代
|
||
↓
|
||
批量生产阶段 ─── "把游戏做完整" ─── 版本流水线（完整 + 生产工具），多版本迭代
|
||
↓
|
||
测试与发布阶段 ─── "把游戏做稳定" ─── Bug/反馈驱动
|
||
```
|
||
|
||
**阶段转换由用户主观判断**，无硬性标准。PM 可建议，但最终决定权在用户。
|
||
|
||
---
|
||
|
||
### 草案阶段
|
||
|
||
**目的**：确定游戏是什么——玩法方向、美术风格、技术可行性。
|
||
|
||
**范围**：每项目一次，在正式开发之前完成。
|
||
|
||
**关注问题**：这个游戏是什么？为什么要做？做不做得了？
|
||
|
||
#### 产出
|
||
|
||
**玩法草案文档**（`docs/design/concept.md`），包含以下 7 个字段：
|
||
|
||
1. **一句话描述** — 用一句话说清楚这是什么游戏
|
||
2. **玩家核心游玩内容与感受** — 玩家在游戏中的核心操作和活动，以及游戏希望带给玩家的情感基调、视觉风格和整体感受
|
||
3. **核心受众画像** — 目标玩家是谁（年龄段、游戏经历、情感诉求），他们为什么会喜欢这款游戏
|
||
4. **游戏核心循环** — 玩家在游戏中反复做什么、为什么持续玩
|
||
5. **游戏元素** — 世界观、角色、剧情、物品、怪物等关键元素概述
|
||
6. **市场定位与三大卖点** — 游戏在市场中的定位（品类、平台、价位），以及最能吸引玩家的三个核心卖点
|
||
7. **参考** — 灵感来源（其他游戏、电影、书、某种经历）
|
||
|
||
**美术风格指南**（`docs/art/style-guide.md`）— 确定视觉方向。
|
||
|
||
**技术可行性评估** — 评估核心玩法在目标引擎/平台上的实现可行性。
|
||
|
||
#### 流程特点
|
||
|
||
- **极轻量**：不需要详细的系统设计，不需要执行案
|
||
- **可以反复推翻重来**：草案阶段推翻设计成本最低
|
||
- **头脑风暴是核心方法**：通过讨论探索方向，确认后才进入文档产出
|
||
|
||
#### PM 检查要点
|
||
|
||
- 草案文档 7 个字段是否都已回答？
|
||
- 美术风格是否有明确方向？
|
||
- 技术上是否可行？
|
||
- 用户是否明确表示"可以进入下一阶段"？
|
||
|
||
#### 完成标志
|
||
|
||
玩法草案文档产出且用户确认。进入原型阶段后，草案文档不再修改（除非用户决定推翻重来）。
|
||
|
||
#### 设计文档层级关系
|
||
|
||
草案、设计案、执行案三者的关系：
|
||
|
||
| 层级 | 定位 | 比喻 | 特点 |
|
||
|------|------|------|------|
|
||
| **草案** (concept.md) | 给游戏**定调** | 灵魂 | 回答"这个游戏是什么"，简略但方向明确 |
|
||
| **设计案** | 给游戏**定骨架** | 骨架 | 基于草案的原则展开系统设计，定义有哪些系统、系统关系、核心行为 |
|
||
| **执行案** | 给游戏**填血肉** | 血肉 | 细化到程序可直接实现的交互规则和行为细节 |
|
||
|
||
设计案初始基于草案的原则进行设计。在后续迭代中遇到具体问题时，可以灵活调整或替换草案中的元素——草案是方向指引，不是硬性约束。
|
||
|
||
---
|
||
|
||
### 原型阶段
|
||
|
||
**目的**：验证核心玩法可行性——从最核心功能开始，快速迭代。
|
||
|
||
**关注问题**：这个游戏好玩吗？核心循环跑得通吗？
|
||
|
||
#### 阶段路线图
|
||
|
||
原型阶段开始时，产出**阶段路线图**（`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协调同步，策划更新执行案 |
|
||
| *PM 质量门* | *穿插于③④⑤之后，关注核心行为是否完整描述，不要求面面俱到* |
|
||
|
||
> **原型阶段灵活性**：④⑤⑥允许更紧密的交替推进，不必严格串行。例如程序设计时发现需要调整美术需求，可以回退到④补充后继续。批量生产阶段恢复严格串行。
|
||
|
||
#### 版本复盘（每个迭代完成后）
|
||
|
||
每个版本迭代完成后执行⑦版本复盘，具体要求见下方流水线中的⑦定义。
|
||
|
||
> **为什么每个版本都要复盘？** 文档是下一个迭代的起点。如果文档和实现不一致，下一个迭代的执行案会基于错误的假设，导致更多返工。
|
||
|
||
#### 阶段退出
|
||
|
||
- **退出标准**：用户主观判断核心玩法已验证通过
|
||
- **退出时应有**：至少一个可玩的核心循环原型，核心系统的执行案已验证可行，文档已同步
|
||
- **退出后**：将 `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协调同步，策划更新执行案。所有差异必须记录 |
|
||
| *PM 质量门* | *穿插于③④⑤之后，完整执行所有检查项，逐条对照* |
|
||
|
||
#### 版本复盘（每个迭代完成后）
|
||
|
||
与原型阶段相同：每个版本迭代完成后必须执行⑦版本复盘。批量生产阶段要求所有差异必须记录在案，不可省略。
|
||
|
||
#### 生产工具
|
||
|
||
批量生产阶段可能需要在正式开发前先开发生产工具：
|
||
|
||
| 工具类型 | 目的 | 何时开发 |
|
||
|----------|------|----------|
|
||
| 数据配置工具 | 让策划能自行配置交互内容、NPC 对话、物品属性等 | 需要大量配置数据时 |
|
||
| 关卡编辑工具 | 快速搭建和调整场景布局 | 需要频繁调整场景时 |
|
||
| 批量资产生成工具 | 批量生成/导入美术资产 | 资产量大时 |
|
||
| 测试工具 | 自动化验证、数据校验 | 手动测试效率低时 |
|
||
|
||
工具开发本身也应遵循版本流水线（有执行案、有程序设计），但可以简化流程。
|
||
|
||
#### 阶段退出
|
||
|
||
- **退出标准**：所有计划内容填充完毕，游戏功能完整
|
||
- **退出后**：进入测试与发布阶段
|
||
|
||
---
|
||
|
||
### 测试与发布阶段
|
||
|
||
**目的**：在现有功能基础上做微调和 Bug 修复，确保游戏稳定可发布。
|
||
|
||
**关注问题**：有没有 Bug？体验够不够好？性能行不行？
|
||
|
||
#### 流程特点
|
||
|
||
- **不使用版本开发流水线**（①-⑥）
|
||
- **不增加大型新功能**——所有功能应已在上游阶段完成
|
||
- **以 Bug 和反馈驱动**
|
||
- **微调允许**：数值调整、文案修改、UI 微调、性能优化
|
||
|
||
#### 工作流程
|
||
|
||
```
|
||
收集 Bug/反馈 → 评估优先级 → 修复/微调 → 验证 → 发布
|
||
↑ │
|
||
└───────────────────────────────────────────┘
|
||
```
|
||
|
||
1. **收集**：从测试、体验、反馈中收集 Bug 和改进意见
|
||
2. **评估**：按严重程度和影响范围排优先级
|
||
3. **修复/微调**：针对性修改，不引入大的架构变动
|
||
4. **验证**：确认修复有效，未引入新问题
|
||
5. **发布**：构建发布版本
|
||
|
||
---
|
||
|
||
## 版本开发流水线
|
||
|
||
> 本流水线在**原型阶段**和**批量生产阶段**使用。两个阶段使用相同的流水线结构，但严格度和完整性要求不同（详见上方各阶段说明）。
|
||
|
||
**阶段级前置**（每个阶段开始时执行一次）：
|
||
|
||
```
|
||
① 全局设计案 → ② 阶段路线图
|
||
```
|
||
|
||
**版本级循环**（每个版本迭代执行一次，严格按序推进）：
|
||
|
||
```
|
||
③ 执行案
|
||
↓
|
||
[PM 审查：执行案质量门]
|
||
↓
|
||
④ 程序设计
|
||
↓
|
||
[PM 审查：程序设计质量门]
|
||
↓
|
||
⑤ 美术产出
|
||
↓
|
||
[PM 审查：美术资产验收门]
|
||
↓
|
||
⑥ 程序实现
|
||
↓
|
||
⑦ 版本复盘
|
||
```
|
||
|
||
**③-⑦ 每个步骤都是下一步的必要前置条件，不可跳过或并行。PM 审查不通过则退回重做，不可进入下一步。用户是质量门争议的最终仲裁者。**
|
||
|
||
---
|
||
|
||
### ① 全局设计案（策划）
|
||
|
||
**目的**：定义**当前阶段目标形态**的全景图——有哪些系统、有哪些元素、它们大体上是什么关系。
|
||
|
||
**范围**：面向当前阶段要达成的目标形态，不是某个版本，也不是游戏的最终完成形态。
|
||
|
||
**必须包含的内容**：
|
||
|
||
1. **系统清单**：游戏最终包含哪些系统
|
||
2. **元素清单**：游戏世界中的关键元素（角色、场景区域、收集品分类、NPC等）
|
||
3. **系统关系**：各系统之间如何关联和互相影响
|
||
|
||
**产出形式**：
|
||
- 可以有多个文档，按系统或主题拆分
|
||
- 必须有一个**索引文档**把所有全局设计文档串联起来
|
||
- 产出位置：`docs/design/<阶段>/`（`prototype/` 或 `production/`）。不同阶段的全局设计案独立维护：原型阶段描述"原型要验证什么"，批量生产阶段描述"完整游戏要做成什么样"
|
||
|
||
**PM 检查要点**：
|
||
- 是否覆盖了游戏最终形态的所有主要系统？
|
||
- 系统关系是否清晰（谁依赖谁、谁独立）？
|
||
- 索引文档是否存在且能串联所有全局设计文档？
|
||
|
||
---
|
||
|
||
### ② 阶段路线图（PM 主导，策划配合）
|
||
|
||
**目的**：定义当前阶段（原型或批量生产）分几个版本推进，每个版本探索什么方向。
|
||
|
||
**必须包含的内容**：
|
||
|
||
1. **版本列表**：当前阶段有哪些版本
|
||
2. **每个版本的核心目标**：这个版本验证/实现什么
|
||
3. **每个版本的范围概述**：大致包含哪些系统和内容
|
||
4. **每个版本的内容完成度**：每种内容做到什么程度（占位/初版/正式）
|
||
5. **每个版本涉及的系统清单**：哪些系统需要在本版本实现（引用全局设计案中的系统名）
|
||
6. **版本间的递进关系**：为什么先做这些后做那些
|
||
7. **每个版本的验收标准**：怎样算"这个版本做完了"
|
||
|
||
**产出位置**：`docs/plans/prototype-roadmap.md` 或 `docs/plans/production-roadmap.md`
|
||
|
||
**PM 检查要点**：
|
||
- 每个版本的范围是否与全局设计案对齐？
|
||
- 版本间是否有清晰的递进逻辑？
|
||
- 是否有版本范围过大的风险？
|
||
|
||
---
|
||
|
||
### ③ 执行案（策划）
|
||
|
||
**目的**：针对当前版本中的每个系统/元素，写出完整的**交互规则细节**，细到程序照着这个逻辑实现功能。
|
||
|
||
**范围**：仅限当前版本中需要实现的系统。
|
||
|
||
**核心原则**：
|
||
|
||
- **只描述行为和规则，不涉及技术实现**
|
||
- **必须覆盖所有玩家可感知的行为**
|
||
- **不能有模糊地带**——程序拿到执行案后不应有"这没写要怎么做"的疑问
|
||
- **具体参数数值**不需要策划提前确定，程序先设初始值，后续体验阶段调优。如有建议值标注"建议值，可调"
|
||
|
||
**执行案格式**：
|
||
|
||
每个执行案文件顶部必须包含**迭代记录表头**：
|
||
|
||
```markdown
|
||
# <系统名>执行案
|
||
|
||
## 迭代记录
|
||
|
||
| 迭代版本 | 修改日期 | 状态 | 说明 |
|
||
|----------|----------|------|------|
|
||
| v0.1 | 2026-06-10 | 📝 设计中 | 初始版本 |
|
||
|
||
> 状态标记：📝 设计中 | 🔄 开发中 | ✅ 已同步
|
||
|
||
---
|
||
|
||
## 系统概述
|
||
（描述该系统做什么、服务于什么体验目标）
|
||
|
||
## 行为规则
|
||
（当前最新状态的所有行为规则）
|
||
```
|
||
|
||
**必须包含的内容**：
|
||
|
||
1. **系统概述**：这个系统做什么、服务于什么体验目标
|
||
2. **完整的行为规则清单**：每个操作的触发条件、触发后表现、结束条件
|
||
3. **状态和状态转换**：系统有哪些状态、什么条件触发状态变化
|
||
4. **边界情况处理**：异常/极端情况下的系统行为（如多个交互物重叠、交互中移动等）
|
||
5. **与其他系统的交互**：本系统与其他系统的关联和影响
|
||
|
||
**不应包含的内容**：
|
||
- 用什么引擎组件实现
|
||
- 代码/脚本架构怎么组织
|
||
- 数据用什么格式存储
|
||
- 具体的参数精确值（调优参数标注"建议值，可调"）
|
||
|
||
**阶段差异**：
|
||
|
||
| 维度 | 原型阶段 | 批量生产阶段 |
|
||
|------|----------|-------------|
|
||
| 行为覆盖 | 核心行为必须完整，非核心行为可略过 | 所有行为必须完整覆盖 |
|
||
| 边界情况 | 影响核心玩法的必须处理，其余可略过 | 全部必须处理 |
|
||
| 系统间关联 | 核心关联必须说明 | 全部必须说明 |
|
||
|
||
**产出形式**：
|
||
- 每个系统一份执行案，放在 `docs/design/<阶段>/` 目录下
|
||
- 文件命名：`<系统名>-execution.md`（如 `player-controller-execution.md`）
|
||
- 不按版本分文件，通过迭代记录表头追踪变更
|
||
|
||
---
|
||
|
||
### PM 审查：执行案质量门
|
||
|
||
**触发时机**：策划完成执行案（③）后，进入程序设计（④）之前。
|
||
|
||
**审查人**：PM
|
||
|
||
**审查内容**：
|
||
|
||
1. **完整性**：是否覆盖了该系统所有玩家可感知的行为？每个操作是否明确了触发条件、触发后表现、结束条件？
|
||
2. **清晰性**：是否有模糊地带？行为描述是否无歧义？程序拿到后能否不问策划任何问题就实现功能？
|
||
3. **边界情况**：异常/极端情况下的系统行为是否都处理了？
|
||
4. **系统间关联**：与其他系统的关联和影响是否说明？
|
||
5. **技术越界检查**：是否误入了技术细节？精确参数值是否标注为"建议值，可调"？
|
||
|
||
**阶段差异**：
|
||
|
||
| 维度 | 原型阶段 | 批量生产阶段 |
|
||
|------|----------|-------------|
|
||
| 完整性 | 核心行为必须完整，非核心可略过 | 全部必须完整 |
|
||
| 边界情况 | 影响核心玩法的必须处理 | 全部必须处理 |
|
||
| 严格度 | 重点关注核心行为质量 | 逐条全面检查 |
|
||
|
||
**判定**：
|
||
- **通过** → 进入 ④ 程序设计
|
||
- **不通过** → 退回策划修改，列出具体问题清单
|
||
- **争议** → PM 与策划对判定有分歧时，由用户最终裁决
|
||
|
||
**产出**：PM 审查记录（记录在 `docs/plans/review-log.md`）
|
||
|
||
---
|
||
|
||
### ④ 程序设计（程序）
|
||
|
||
**目的**：程序读完策划的执行案后，设计具体的实现方案。
|
||
|
||
**前置条件**：执行案（③）已就绪，且 PM 审查通过。
|
||
|
||
**必须包含的内容**：
|
||
|
||
1. **实现方案**：针对执行案中的每条行为规则，说明打算如何实现
|
||
2. **类与组件架构**：需要哪些类/组件？继承关系？挂载方式？
|
||
3. **数据流**：数据从哪里来？系统之间如何通信？
|
||
4. **美术资源需求清单**：实现这个功能需要哪些美术资源（模型、动画、UI 等），具体到数量和尺寸
|
||
5. **技术风险和注意事项**：实现中可能遇到的技术难点
|
||
|
||
**阶段差异**：
|
||
|
||
| 维度 | 原型阶段 | 批量生产阶段 |
|
||
|------|----------|-------------|
|
||
| 架构 | 可以用占位方案，不需要生产级 | 需要生产级架构，考虑扩展性 |
|
||
| 数据流 | 允许硬编码 | 数据应配置化 |
|
||
| 美术需求 | 允许简化描述 | 必须具体到尺寸和数量 |
|
||
|
||
**产出位置**：`docs/technical/<系统名>-tech.md`
|
||
|
||
---
|
||
|
||
### PM 审查：程序设计质量门
|
||
|
||
**触发时机**：程序完成技术设计（④）后，进入美术产出（⑤）之前。
|
||
|
||
**审查内容**：
|
||
|
||
1. **执行案覆盖度**：程序设计是否完整回应了执行案中的每条行为规则？逐条对照
|
||
2. **美术资源需求**：需求是否列得具体？数量、尺寸、触发时机是否明确？
|
||
3. **类与组件架构**：继承关系和挂载方式是否清晰？
|
||
4. **数据流**：是否明确？
|
||
5. **技术风险**：是否识别？
|
||
|
||
**判定**：
|
||
- **通过** → 进入 ⑤ 美术产出
|
||
- **不通过** → 退回程序修改
|
||
- **争议** → PM 与程序对判定有分歧时，由用户最终裁决
|
||
|
||
---
|
||
|
||
### ⑤ 美术产出（美术）
|
||
|
||
**目的**：根据程序输出的美术资源需求清单，产出对应资产。
|
||
|
||
**前置条件**：程序设计（④）已就绪，且 PM 审查通过。
|
||
|
||
**阶段差异**：
|
||
|
||
| 维度 | 原型阶段 | 批量生产阶段 |
|
||
|------|----------|-------------|
|
||
| 资产质量 | 允许占位资源、用户自行处理 | 正式资产，符合风格指南 |
|
||
| 完成度 | 能用就行 | 必须满足规格要求 |
|
||
|
||
**产出位置**：
|
||
- 资产放 `Content/` 对应目录
|
||
- 清单记录在 `docs/art/asset-manifest.md` 或直接在技术方案中更新
|
||
|
||
---
|
||
|
||
### PM 审查：美术资产验收门
|
||
|
||
**触发时机**：美术完成资产产出（⑤）后，进入程序实现（⑥）之前。
|
||
|
||
**审查内容**：
|
||
|
||
1. **需求覆盖度**：逐项对照美术资源需求清单
|
||
2. **资产到位确认**：资产文件是否已放置在对应目录？
|
||
3. **资产规格**：尺寸、格式等是否符合需求？
|
||
4. **缺失项处理**：未到位资产是否有明确处理方案？
|
||
|
||
**判定**：
|
||
- **通过** → 进入 ⑥ 程序实现
|
||
- **不通过** → 退回美术补充
|
||
- **争议** → PM 与美术对判定有分歧时，由用户最终裁决
|
||
|
||
---
|
||
|
||
### ⑥ 程序实现（程序）
|
||
|
||
**目的**：基于程序设计方案和美术资产，实际编写代码。
|
||
|
||
**阶段差异**：
|
||
|
||
| 维度 | 原型阶段 | 批量生产阶段 |
|
||
|------|----------|-------------|
|
||
| 代码质量 | 允许硬编码、快速实现 | 不允许硬编码，数据配置化，代码达发布标准 |
|
||
| 验证 | 核心流程跑通即可 | 每个系统独立验证 + 集成验证 |
|
||
|
||
**实现完成后进入⑦版本复盘**。
|
||
|
||
---
|
||
|
||
### ⑦ 版本复盘（程序汇报 → PM 协调 → 策划更新）
|
||
|
||
**目的**：确保文档与实现一致，为下一个迭代提供准确的起点。
|
||
|
||
**触发时机**：程序实现（⑥）完成后。
|
||
|
||
**流程**：
|
||
|
||
1. **程序汇报**：程序对照执行案，列出实现中产生的偏差和调整
|
||
2. **PM 协调**：PM 审核偏差清单，判断哪些需要回写文档、哪些是合理的实现优化
|
||
3. **策划更新**：策划根据 PM 的协调结果，更新设计案和执行案
|
||
4. **标记状态**：执行案迭代记录中该版本标记为 ✅ 已同步
|
||
|
||
**必须更新的内容**：
|
||
- 设计案中与实际不符的系统描述
|
||
- 执行案中与实际实现不一致的行为规则
|
||
- 执行案迭代记录中新增一行，记录变更
|
||
|
||
**阶段差异**：
|
||
|
||
| 维度 | 原型阶段 | 批量生产阶段 |
|
||
|------|----------|-------------|
|
||
| 偏差记录 | 核心行为的偏差必须记录 | 所有差异必须记录在案 |
|
||
| 文档同步 | 核心系统必须同步 | 所有系统必须同步 |
|
||
|
||
### 为什么必须复盘
|
||
|
||
- 文档是下一个迭代的起点。如果文档和实现不一致，下一个迭代会基于错误假设
|
||
- PM 的质量门审查基于文档。文档不准确会导致审查无效
|
||
- 程序在实现时可能发现设计的问题并做了调整，这些调整必须反映到文档中
|
||
|
||
---
|
||
|
||
## PM 诊断检查清单
|
||
|
||
PM 在每次 `/plan` 调用时，先判断宏观阶段，再针对**当前版本**逐项检查流水线状态。
|
||
|
||
### 宏观阶段判断
|
||
|
||
| 检查项 | 判断方式 | 结果 |
|
||
|--------|----------|------|
|
||
| 项目处于哪个开发阶段？ | 检查 `concept.md` → 检查核心玩法是否已有可玩原型 → 检查内容是否已完整 | 草案 / 原型 / 批量生产 / 测试发布 |
|
||
| 阶段信息是否记录在 `current.md`？ | 检查 `current.md` 中是否有阶段标注 | 如无则补充 |
|
||
|
||
### 版本流水线检查
|
||
|
||
| 检查项 | 检查方式 | 通过条件 |
|
||
|--------|----------|----------|
|
||
| ① 全局设计案是否存在且完整？ | 检查 `docs/design/<阶段>/` 中的全局设计文档和索引 | 覆盖所有主要系统，有索引串联 |
|
||
| ② 阶段路线图是否存在？ | 检查 `docs/plans/<阶段>-roadmap.md` | 版本列表、每版本目标、递进关系明确 |
|
||
| ③ 执行案是否齐全？ | 检查 `docs/design/<阶段>/` 对应执行案 | 每个涉及系统的核心行为规则都已明确 |
|
||
| **PM 审查**：执行案质量门 | 对照质量标准逐项检查（注意阶段严格度差异） | 完整性、清晰性、边界情况通过 |
|
||
| ④ 程序设计方案是否齐全？ | 检查 `docs/technical/` 对应文档 | 每个执行案都有对应技术方案 |
|
||
| **PM 审查**：程序设计质量门 | 执行案与技术方案逐条对照 | 行为规则全覆盖，美术需求具体 |
|
||
| ⑤ 美术资产是否就位？ | 检查资源需求清单 vs 实际资产 | 所有必需资产已产出或有处理方案 |
|
||
| **PM 审查**：美术资产验收门 | 需求清单 vs 实际资产逐项对照 | 每项需求都有对应产出 |
|
||
| ⑥ 程序实现是否完成？ | 检查实际文件 | 实现完成 |
|
||
| ⑦ 版本复盘是否完成？ | 检查执行案迭代记录是否 ✅ 已同步 | 策划已根据实现偏差更新文档 |
|
||
|
||
**遇到第一个未通过的即为当前应推进的阶段。**
|
||
|
||
**注意**：原型阶段的质量门检查允许在非核心维度上降低严格度，批量生产阶段必须逐条全面检查。
|
||
|
||
---
|
||
|
||
## 文档质量检查标准
|
||
|
||
以下标准对应流水线中的三道 PM 质量门。
|
||
|
||
### 执行案质量标准（对应「执行案质量门」）
|
||
|
||
**完整性检查**：
|
||
- [ ] 是否覆盖了该系统所有玩家可感知的行为？
|
||
- [ ] 每个操作是否明确了触发条件、触发后表现、结束条件？
|
||
- [ ] 边界情况是否都处理了？
|
||
- [ ] 与其他系统的关联是否说明？
|
||
|
||
**清晰性检查**：
|
||
- [ ] 是否有模糊地带？
|
||
- [ ] 行为描述是否无歧义？
|
||
- [ ] 程序拿到后能否不问策划任何问题就实现功能？
|
||
|
||
**边界检查**：
|
||
- [ ] 是否误入了技术细节？
|
||
- [ ] 精确参数值是否标注为"建议值，可调"而非固定值？
|
||
|
||
**迭代记录检查**：
|
||
- [ ] 迭代记录表头是否存在且填写完整？
|
||
- [ ] 已完成版本的文档是否已同步（✅ 已同步）？
|
||
|
||
### 程序设计质量标准（对应「程序设计质量门」）
|
||
|
||
- [ ] 是否完整回应了执行案中的每条行为规则？（逐条对照）
|
||
- [ ] 美术资源需求是否列得具体（尺寸、数量、触发时机）？
|
||
- [ ] 类与组件架构是否清晰？
|
||
- [ ] 数据流是否明确？
|
||
- [ ] 技术风险是否识别？
|
||
|
||
### 美术资产验收标准（对应「美术资产验收门」）
|
||
|
||
- [ ] 资源需求清单中的每一项是否都有对应的美术产出？（逐项对照）
|
||
- [ ] 资产文件是否已放置在对应目录？
|
||
- [ ] 资产路径是否记录清晰？
|
||
- [ ] 资产规格是否符合需求？
|
||
- [ ] 未到位资产是否有明确的处理方案？
|
||
|
||
### 版本复盘标准（对应「⑦版本复盘」）
|
||
|
||
- [ ] 程序是否汇报了实现偏差清单？
|
||
- [ ] PM 是否审核了偏差清单并给出协调意见？
|
||
- [ ] 策划是否根据协调结果更新了设计案/执行案？
|
||
- [ ] 执行案迭代记录是否新增一行并标记 ✅ 已同步？
|
||
|
||
---
|
||
|
||
## 单人独立开发的特殊考量
|
||
|
||
- **无法并行**——同一时间只能做一件事，选择更关键
|
||
- **精力有限**——避免一次性拆分太多并行任务
|
||
- **心流重要**——建议按「完整做完一个小系统」而非「同时推进多个系统」的方式工作
|
||
- **早期验证**——越早能跑起来看到东西，越不容易失去动力
|
||
- **文档交接**——Agent 之间通过文档交接，PM 是信息枢纽
|