starmen1265/ChildHood
1
0
Fork 0
Code Issues 11 Pull Requests Actions Packages Projects 2 Releases Wiki Activity

docs(refs): 更新工作流文档并新增策划/PM角色规格说明书

Browse Source
This commit is contained in:
DESKTOP-2K5TJI4\admin
2026-06-04 19:16:33 +08:00
parent 50f987b0e0
commit 410d206a7d
3 changed files with 1478 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/refs/development-workflow.md
+42 -37
View File
@@ -12,7 +12,7 @@
| **策划** (Design) | 玩法设计、数值平衡、叙事、系统机制 | `docs/design/`、`GameConfig/` | 扫描 `docs/design/` 和 `GameConfig/` 目录中的文件 |
| **程序** (Dev) | 系统实现、技术架构、Bug 修复 | `Source/`、`Content/`、`docs/technical/` | 扫描对应目录中的文件 |
| **美术** (Art) | 美术需求分析、资产规格、风格指南 | `docs/art/`、`Content/` | 扫描对应目录中的文件 |
| **PM** | 进度追踪、优先级决策、风险预警、流水线推进 | `docs/plans/` | 不产出设计文档、代码或美术资产 |
| **PM** | 进度追踪、优先级建议、风险预警、流水线推进 | `docs/plans/` | 不产出设计文档、代码或美术资产 |
### 协作规则
@@ -21,12 +21,18 @@
- **文档即交接**：Agent 之间不直接通信，通过共享文档目录交接
- **冲突时用户说了算**：玩法/数值/叙事的最终决定权在用户
- **PM 是信息枢纽**：跨角色的信息同步和阻塞排查由 PM 负责
- **会话启动先调 PM**：每次工作会话开始时，用户必须先调出 PM 执行进度追踪，确认当前状态后再进入具体工作
- **用户驱动角色切换**：角色间的工作切换由用户手动触发，PM 不自动指派任务
- **角色任务汇报**：每个角色维护任务汇报文档（`docs/plans/reports/<role>-report.md`），PM 据此追踪进度
### 进度汇报规则
- 各 Agent 完成工作后汇报结果，不自动更新项目进度
- PM负责验收各Agent的工作结果，给出行动建议
- 用户确认PM建议后，由 PM 统一更新项目进度，调整计划
- 各角色维护任务汇报文档（`docs/plans/reports/<role>-report.md`），记录当前任务 ID、状态和进度细节
- 各 Agent 完成工作后更新任务汇报文档，不自动更新项目进度
- PM 通过读取任务汇报文档验收各角色工作结果，给出行动建议
- 角色完成工作后汇报结果，PM 验收并建议归档，用户确认后由 PM 执行归档并更新项目进度
- 任务追踪使用唯一任务 ID（格式：`[角色前缀]-[三位数字]`），详细规范见 PM 角色规格说明书
- `current.md` 标准结构、阶段路线图模板、审查记录格式、归档机制等文档规范见 PM 角色规格说明书（`.claude/refs/pm-role-specification.md`）
---
@@ -89,6 +95,10 @@
玩法草案文档产出且用户确认。进入原型阶段后，草案文档不再修改（除非用户决定推翻重来）。
#### 任务管理
草案阶段不使用版本开发流水线。草案阶段的任务管理（如"产出概念草案"）遵循 `pm-role-specification.md` 中的草图任务类型。
#### 设计文档层级关系
草案、设计案、执行案三者的关系：
@@ -129,7 +139,7 @@
每个版本的流水线循环：**③执行案 → ④程序设计 → ⑤美术产出 → ⑥程序实现 → ⑦版本复盘**
①全局设计在阶段初期集中产出，后续版本可增量补充。②阶段路线图在阶段开始时产出。
①设计案在阶段初期集中产出，后续版本可增量补充。②阶段路线图在阶段开始时产出。
#### 设计文档组织
@@ -137,7 +147,6 @@
```
docs/design/prototype/
game-vision.md # 游戏愿景
player-controller.md # 设计案
player-controller-execution.md # 执行案（含迭代版本表头）
interaction-system.md
@@ -151,16 +160,16 @@ docs/design/prototype/
| 步骤 | 原型阶段要求 |
|------|-------------|
| ① 全局设计案 | 可以边做边补，不需要一开始就全部完成。新系统先产出简要设计再动手 |
| ① 设计案 | 可以边做边补，不需要一开始就全部完成。新系统先产出简要设计再动手 |
| ② 阶段路线图 | 原型阶段开始时产出，可随迭代调整 |
| ③ 执行案 | 关注影响玩法体验的核心行为。边界情况、非核心反馈等细节可以先略过 |
| ④ 程序设计 | 可以用占位方案，不需要生产级架构。重点回答"怎么实现核心行为" |
| ⑤ 美术产出 | 允许占位资源、用户自行处理。能用就行 |
| ⑥ 程序实现 | 允许硬编码、允许快速但不优雅的实现。先跑通再说 |
| ⑦ 版本复盘 | 程序汇报实现偏差，PM协调同步，策划更新执行案 |
| *PM 质量门* | *穿插于③④⑤⑥之后，关注核心行为是否完整描述/实现，不要求面面俱到* |
| *PM 质量门* | *穿插于③④⑤⑥之后，按阶段对应标准严格检查。用户可决定跳过哪些检查项，PM 记录用户的跳过决策* |
> **原型阶段灵活性**：④⑤⑥允许更紧密的交替推进，不必严格串行。例如程序设计时发现需要调整美术需求，可以回退到④补充后继续。批量生产阶段恢复严格串行。
> **原型阶段灵活性**：④⑤⑥允许更紧密的交替推进，不必严格串行。例如在⑤美术产出或⑥程序实现中发现需要调整美术需求，可以回退到④重新设计后继续推进。质量门在每次推进时仍然触发，用户可决定跳过非核心检查项。批量生产阶段恢复严格串行。
#### 版本复盘（每个迭代完成后）
@@ -201,7 +210,6 @@ docs/design/prototype/
```
docs/design/production/
game-vision.md # 从 prototype/ 复制，作为起点
player-controller.md # 在原型基础上更新
player-controller-execution.md # 继续迭代，追加新的迭代记录
...
@@ -211,7 +219,7 @@ docs/design/production/
| 步骤 | 批量生产阶段要求 |
|------|----------------|
| ① 全局设计案 | 应已完整。新增系统必须先产出全局设计再进入版本开发 |
| ① 设计案 | 应已完整。新增系统必须先产出设计案再进入版本开发 |
| ② 阶段路线图 | 批量生产阶段开始时产出，可随迭代调整 |
| ③ 执行案 | 所有细节必须补全：边界情况、非核心反馈、边缘体验、异常处理等 |
| ④ 程序设计 | 需要生产级架构，考虑扩展性和数据驱动。美术需求必须具体到尺寸和数量 |
@@ -252,7 +260,7 @@ docs/design/production/
#### 流程特点
- **不使用版本开发流水线**（①-⑥）
- **不使用版本开发流水线**（③-⑦）
- **不增加大型新功能**——所有功能应已在上游阶段完成
- **以 Bug 和反馈驱动**
- **微调允许**：数值调整、文案修改、UI 微调、性能优化
@@ -280,7 +288,7 @@ docs/design/production/
**阶段级前置**（每个阶段开始时执行一次）：
```
① 全局设计案 → ② 阶段路线图
① 设计案 → ② 阶段路线图
```
**版本级循环**（每个版本迭代执行一次，严格按序推进）：
@@ -305,11 +313,11 @@ docs/design/production/
⑦ 版本复盘
```
**③-⑦ 每个步骤都是下一步的必要前置条件，不可跳过或并行。PM 审查不通过则退回重做，不可进入下一步。用户是质量门争议的最终仲裁者。**
**③-⑦ 每个步骤都是下一步的必要前置条件，不可跳过或并行（批量生产阶段严格执行；原型阶段④⑤⑥允许灵活交替，见原型阶段说明）。PM 审查不通过则退回重做，不可进入下一步（生产工具开发可省略⑤及对应验收门，见生产工具说明）。用户是质量门争议的最终仲裁者。**
---
### ① 全局设计案（策划）
### ① 设计案（策划）
**目的**：定义**当前阶段目标形态**的全景图——有哪些系统、有哪些元素、它们大体上是什么关系。
@@ -323,13 +331,13 @@ docs/design/production/
**产出形式**：
- 可以有多个文档，按系统或主题拆分
- 必须有一个**索引文档**把所有全局设计文档串联起来
- 产出位置：`docs/design/<阶段>/`（`prototype/` 或 `production/`）。不同阶段的全局设计案独立维护：原型阶段描述"原型要验证什么"，批量生产阶段描述"完整游戏要做成什么样"
- 必须有一个**索引文档**把所有设计文档串联起来
- 产出位置：`docs/design/<阶段>/`（`prototype/` 或 `production/`）。不同阶段的设计案独立维护：原型阶段描述"原型要验证什么"，批量生产阶段描述"完整游戏要做成什么样"
**PM 检查要点**：
- 是否覆盖了当前阶段目标形态的所有主要系统？
- 系统关系是否清晰（谁依赖谁、谁独立）？
- 索引文档是否存在且能串联所有全局设计文档？
- 索引文档是否存在且能串联所有设计文档？
---
@@ -343,14 +351,19 @@ docs/design/production/
2. **每个版本的核心目标**：这个版本验证/实现什么
3. **每个版本的范围概述**：大致包含哪些系统和内容
4. **每个版本的内容完成度**：每种内容做到什么程度（占位/初版/正式）
5. **每个版本涉及的系统清单**：哪些系统需要在本版本实现（引用全局设计案中的系统名）
5. **每个版本涉及的系统清单**：哪些系统需要在本版本实现（引用设计案中的系统名）
6. **版本间的递进关系**：为什么先做这些后做那些
7. **每个版本的验收标准**：怎样算"这个版本做完了"
**产出位置**：`docs/plans/prototype-roadmap.md` 或 `docs/plans/production-roadmap.md`
**版本编号规则**：
- 原型阶段：`v0.1`、`v0.2`、`v0.3`……
- 批量生产阶段：从 `v1.0` 开始，按 `v1.1`、`v1.2` 递增
- 版本号反映阶段归属，不跨阶段延续（原型 v0.3 完成后，批量生产从 v1.0 开始）
**PM 检查要点**：
- 每个版本的范围是否与全局设计案对齐？
- 每个版本的范围是否与设计案对齐？
- 版本间是否有清晰的递进逻辑？
- 是否有版本范围过大的风险？
@@ -436,20 +449,12 @@ docs/design/production/
4. **系统间关联**：与其他系统的关联和影响是否说明？
5. **技术越界检查**：是否误入了技术细节？精确参数值是否标注为"建议值，可调"？
**阶段差异**：
| 维度 | 原型阶段 | 批量生产阶段 |
|------|----------|-------------|
| 完整性 | 核心行为必须完整，非核心可略过 | 全部必须完整 |
| 边界情况 | 影响核心玩法的必须处理 | 全部必须处理 |
| 严格度 | 重点关注核心行为质量 | 逐条全面检查 |
**判定**：
- **通过** → 进入 ④ 程序设计
- **不通过** → 退回策划修改，列出具体问题清单
- **争议** → PM 与策划对判定有分歧时，由用户最终裁决
**产出**：PM 审查记录（记录在 `docs/plans/review-log.md`）
**产出**：PM 审查记录（记录在 `docs/plans/reviews/<任务ID>-review.md`）
---
@@ -580,7 +585,7 @@ docs/design/production/
- **不通过（重大）** → PM 提出处理建议（回退步骤或开新版本），由用户最终决定
- **争议** → PM 与程序对判定有分歧时，由用户最终裁决
**产出**：PM 审查记录（记录在 `docs/plans/review-log.md`）
**产出**：PM 审查记录（记录在 `docs/plans/reviews/<任务ID>-review.md`）
---
@@ -588,13 +593,13 @@ docs/design/production/
**目的**：确保文档与实现一致，为下一个迭代提供准确的起点。
**触发时机**：程序实现（⑥）完成后。
**触发时机**：PM 程序实现验收门通过后。
**流程**：
1. **程序汇报**：程序对照执行案，列出实现中产生的偏差和调整
2. **PM 协调**：PM 审核偏差清单，判断哪些需要回写文档、哪些是合理的实现优化
3. **策划更新**：策划根据 PM 的协调结果，更新设计案和执行案
2. **PM 协调**：PM 汇总程序汇报的偏差清单，协调策划进行文档更新
3. **策划更新**：策划根据偏差清单，更新设计案和执行案
4. **标记状态**：执行案迭代记录中该版本标记为 ✅ 已同步
**必须更新的内容**：
@@ -632,10 +637,10 @@ PM 在每次 `/plan` 调用时，先判断宏观阶段，再针对**当前版本
| 检查项 | 检查方式 | 通过条件 |
|--------|----------|----------|
| ① 全局设计案是否存在且完整？ | 检查 `docs/design/<阶段>/` 中的全局设计文档和索引 | 覆盖所有主要系统，有索引串联 |
| ① 设计案是否存在且完整？ | 检查 `docs/design/<阶段>/` 中的设计文档和索引 | 覆盖所有主要系统，有索引串联 |
| ② 阶段路线图是否存在？ | 检查 `docs/plans/<阶段>-roadmap.md` | 版本列表、每版本目标、递进关系明确 |
| ③ 执行案是否齐全？ | 检查 `docs/design/<阶段>/` 对应执行案 | 每个涉及系统的核心行为规则都已明确 |
| **PM 审查**：执行案质量门 | 对照质量标准逐项检查（注意阶段严格度差异） | 完整性、清晰性、边界情况通过 |
| **PM 审查**：执行案质量门 | 对照质量标准逐项检查 | 完整性、清晰性、边界情况通过 |
| ④ 程序设计方案是否齐全？ | 检查 `docs/technical/` 对应文档 | 每个执行案都有对应技术方案 |
| **PM 审查**：程序设计质量门 | 执行案与技术方案逐条对照 | 行为规则全覆盖，美术需求具体 |
| ⑤ 美术资产是否就位？ | 检查资源需求清单 vs 实际资产 | 所有必需资产已产出或有处理方案 |
@@ -644,9 +649,9 @@ PM 在每次 `/plan` 调用时，先判断宏观阶段，再针对**当前版本
| **PM 审查**：程序实现验收门 | 实现与设计方案逐条对照 + 偏差分级处理 | 设计一致，偏差已处理或有明确方案 |
| ⑦ 版本复盘是否完成？ | 检查执行案迭代记录是否 ✅ 已同步 | 策划已根据实现偏差更新文档 |
**遇到第一个未通过的即为当前应推进的阶段。**
**遇到第一个未通过的即为当前应推进的步骤。**
**注意**：原型阶段的质量门检查允许在非核心维度上降低严格度，批量生产阶段必须逐条全面检查。
**注意**：所有质量门按阶段对应标准严格检查。用户可根据实际情况决定跳过特定检查项，PM 记录用户的跳过决策及理由。
---