From 0c38b42a2c5b8bc813846e2b324b4ac3c1fba643 Mon Sep 17 00:00:00 2001 From: "DESKTOP-2K5TJI4\\admin" Date: Thu, 4 Jun 2026 11:44:02 +0800 Subject: [PATCH] =?UTF-8?q?docs(workflow):=20=E4=BC=98=E5=8C=96=E8=8D=89?= =?UTF-8?q?=E6=A1=88=E5=AD=97=E6=AE=B5=E4=B8=8E=E7=B2=BE=E7=AE=80=E6=B5=81?= =?UTF-8?q?=E6=B0=B4=E7=BA=BF=E6=AD=A5=E9=AA=A4?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 草案文档：合并「玩家能做什么」+「游戏氛围与风格」为「玩家核心游玩内容与感受」 - 草案文档：新增「核心受众画像」和「市场定位与三大卖点」字段(6→7项) - 全局设计案：移除与草案重复的「核心玩法循环」和「情感目标」 - 删除冗余的③当前版本设计步骤，其内容完成度信息合并到②路线图 - 流水线步骤从③-⑧重编号为③-⑦，全文件40+处引用同步更新 --- .claude/refs/development-workflow.md | 159 +++++++++++---------------- 1 file changed, 67 insertions(+), 92 deletions(-) diff --git a/.claude/refs/development-workflow.md b/.claude/refs/development-workflow.md index 73931b9..4d27b65 100644 --- a/.claude/refs/development-workflow.md +++ b/.claude/refs/development-workflow.md @@ -1,7 +1,7 @@ # 游戏开发工作流 > 本文档定义游戏项目的开发阶段、版本开发流水线、角色职责、产出标准和质量检查规则。 -> 版本开发流水线（③-⑧）中各步骤严格按序推进，不可跳过或并行。①②为阶段级前置，仅在阶段开始时执行一次，后续版本迭代中不重复执行。 +> 版本开发流水线（③-⑦）中各步骤严格按序推进，不可跳过或并行。①②为阶段级前置，仅在阶段开始时执行一次，后续版本迭代中不重复执行。 --- @@ -19,14 +19,14 @@ - **策划先行**：设计文档是其他角色的需求源 - **程序读设计**：实现前必须先读取对应设计文档和配置表 - **文档即交接**：Agent 之间不直接通信，通过共享文档目录交接 -- **冲突时策划说了算**：玩法/数值/叙事的最终决定权在策划角色 +- **冲突时用户说了算**：玩法/数值/叙事的最终决定权在用户 - **PM 是信息枢纽**：跨角色的信息同步和阻塞排查由 PM 负责 ### 进度汇报规则 -- 各 Agent 完成工作后汇报结果，**不自动勾选** `current.md` -- 开发者确认后，由 PM 统一更新进度文档 -- PM 每次调用时主动扫描各目录，验证「汇报的进度」与「实际文件产出」是否一致 +- 各 Agent 完成工作后汇报结果，不自动更新项目进度 +- PM负责验收各Agent的工作结果，给出行动建议 +- 用户确认PM建议后，由 PM 统一更新项目进度，调整计划 --- @@ -44,7 +44,7 @@ 测试与发布阶段 ─── "把游戏做稳定" ─── Bug/反馈驱动 ``` -**阶段转换由开发者主观判断**，无硬性标准。PM 可建议，但最终决定权在开发者。 +**阶段转换由用户主观判断**，无硬性标准。PM 可建议，但最终决定权在用户。 --- @@ -58,14 +58,15 @@ #### 产出 -**玩法草案文档**（`docs/design/concept.md`），包含以下 6 个字段： +**玩法草案文档**（`docs/design/concept.md`），包含以下 7 个字段： 1. **一句话描述** — 用一句话说清楚这是什么游戏 -2. **玩家能做什么** — 玩家在游戏中的核心操作和活动 -3. **游戏氛围与风格** — 情感基调、视觉风格、目标审美 +2. **玩家核心游玩内容与感受** — 玩家在游戏中的核心操作和活动，以及游戏希望带给玩家的情感基调、视觉风格和整体感受 +3. **核心受众画像** — 目标玩家是谁（年龄段、游戏经历、情感诉求），他们为什么会喜欢这款游戏 4. **游戏核心循环** — 玩家在游戏中反复做什么、为什么持续玩 5. **游戏元素** — 世界观、角色、剧情、物品、怪物等关键元素概述 -6. **参考** — 灵感来源（其他游戏、电影、书、某种经历） +6. **市场定位与三大卖点** — 游戏在市场中的定位（品类、平台、价位），以及最能吸引玩家的三个核心卖点 +7. **参考** — 灵感来源（其他游戏、电影、书、某种经历） **美术风格指南**（`docs/art/style-guide.md`）— 确定视觉方向。 @@ -79,14 +80,14 @@ #### PM 检查要点 -- 草案文档 6 个字段是否都已回答？ +- 草案文档 7 个字段是否都已回答？ - 美术风格是否有明确方向？ - 技术上是否可行？ -- 开发者是否明确表示"可以进入下一阶段"？ +- 用户是否明确表示"可以进入下一阶段"？ #### 完成标志 -玩法草案文档产出且开发者确认。进入原型阶段后，草案文档不再修改（除非开发者决定推翻重来）。 +玩法草案文档产出且用户确认。进入原型阶段后，草案文档不再修改（除非用户决定推翻重来）。 #### 设计文档层级关系 @@ -126,7 +127,7 @@ - 增加新的系统验证 - 修改已有系统的行为规则 -每个版本的流水线循环：**③版本设计 → ④执行案 → ⑤程序设计 → ⑥美术产出 → ⑦程序实现 → ⑧版本复盘** +每个版本的流水线循环：**③执行案 → ④程序设计 → ⑤美术产出 → ⑥程序实现 → ⑦版本复盘** ①全局设计在阶段初期集中产出，后续版本可增量补充。②阶段路线图在阶段开始时产出。 @@ -152,25 +153,24 @@ docs/design/prototype/ |------|-------------| | ① 全局设计案 | 可以边做边补，不需要一开始就全部完成。新系统先产出简要设计再动手 | | ② 阶段路线图 | 原型阶段开始时产出，可随迭代调整 | -| ③ 版本设计 | 明确本版本的验证目标和范围。允许粗粒度 | -| ④ 执行案 | 关注影响玩法体验的核心行为。边界情况、非核心反馈等细节可以先略过 | -| ⑤ 程序设计 | 可以用占位方案，不需要生产级架构。重点回答"怎么实现核心行为" | -| ⑥ 美术产出 | 允许占位资源、开发者自行处理。能用就行 | -| ⑦ 程序实现 | 允许硬编码、允许快速但不优雅的实现。先跑通再说 | -| ⑧ 版本复盘 | 程序汇报实现偏差，PM协调同步，策划更新执行案 | -| *PM 质量门* | *穿插于④⑤⑥之后，关注核心行为是否完整描述，不要求面面俱到* | +| ③ 执行案 | 关注影响玩法体验的核心行为。边界情况、非核心反馈等细节可以先略过 | +| ④ 程序设计 | 可以用占位方案，不需要生产级架构。重点回答"怎么实现核心行为" | +| ⑤ 美术产出 | 允许占位资源、用户自行处理。能用就行 | +| ⑥ 程序实现 | 允许硬编码、允许快速但不优雅的实现。先跑通再说 | +| ⑦ 版本复盘 | 程序汇报实现偏差，PM协调同步，策划更新执行案 | +| *PM 质量门* | *穿插于③④⑤之后，关注核心行为是否完整描述，不要求面面俱到* | -> **原型阶段灵活性**：⑤⑥⑦允许更紧密的交替推进，不必严格串行。例如程序设计时发现需要调整美术需求，可以回退到⑤补充后继续。批量生产阶段恢复严格串行。 +> **原型阶段灵活性**：④⑤⑥允许更紧密的交替推进，不必严格串行。例如程序设计时发现需要调整美术需求，可以回退到④补充后继续。批量生产阶段恢复严格串行。 #### 版本复盘（每个迭代完成后） -每个版本迭代完成后执行⑧版本复盘，具体要求见下方流水线中的⑧定义。 +每个版本迭代完成后执行⑦版本复盘，具体要求见下方流水线中的⑦定义。 > **为什么每个版本都要复盘？** 文档是下一个迭代的起点。如果文档和实现不一致，下一个迭代的执行案会基于错误的假设，导致更多返工。 #### 阶段退出 -- **退出标准**：开发者主观判断核心玩法已验证通过 +- **退出标准**：用户主观判断核心玩法已验证通过 - **退出时应有**：至少一个可玩的核心循环原型，核心系统的执行案已验证可行，文档已同步 - **退出后**：将 `prototype/` 最终版复制到 `production/`，`prototype/` 保留作为归档 @@ -213,17 +213,16 @@ docs/design/production/ |------|----------------| | ① 全局设计案 | 应已完整。新增系统必须先产出全局设计再进入版本开发 | | ② 阶段路线图 | 批量生产阶段开始时产出，可随迭代调整 | -| ③ 版本设计 | 明确本版本的内容范围和完成度要求。粒度更细 | -| ④ 执行案 | 所有细节必须补全：边界情况、非核心反馈、边缘体验、异常处理等 | -| ⑤ 程序设计 | 需要生产级架构，考虑扩展性和数据驱动。美术需求必须具体到尺寸和数量 | -| ⑥ 美术产出 | 正式资产，符合风格指南。不允许占位 | -| ⑦ 程序实现 | 不允许硬编码，数据应配置化。代码质量需达到发布标准 | -| ⑧ 版本复盘 | 程序汇报实现偏差，PM协调同步，策划更新执行案。所有差异必须记录 | -| *PM 质量门* | *穿插于④⑤⑥之后，完整执行所有检查项，逐条对照* | +| ③ 执行案 | 所有细节必须补全：边界情况、非核心反馈、边缘体验、异常处理等 | +| ④ 程序设计 | 需要生产级架构，考虑扩展性和数据驱动。美术需求必须具体到尺寸和数量 | +| ⑤ 美术产出 | 正式资产，符合风格指南。不允许占位 | +| ⑥ 程序实现 | 不允许硬编码，数据应配置化。代码质量需达到发布标准 | +| ⑦ 版本复盘 | 程序汇报实现偏差，PM协调同步，策划更新执行案。所有差异必须记录 | +| *PM 质量门* | *穿插于③④⑤之后，完整执行所有检查项，逐条对照* | #### 版本复盘（每个迭代完成后） -与原型阶段相同：每个版本迭代完成后必须执行⑧版本复盘。批量生产阶段要求所有差异必须记录在案，不可省略。 +与原型阶段相同：每个版本迭代完成后必须执行⑦版本复盘。批量生产阶段要求所有差异必须记录在案，不可省略。 #### 生产工具 @@ -253,7 +252,7 @@ docs/design/production/ #### 流程特点 -- **不使用版本开发流水线**（①-⑦） +- **不使用版本开发流水线**（①-⑥） - **不增加大型新功能**——所有功能应已在上游阶段完成 - **以 Bug 和反馈驱动** - **微调允许**：数值调整、文案修改、UI 微调、性能优化 @@ -287,24 +286,24 @@ docs/design/production/ **版本级循环**（每个版本迭代执行一次，严格按序推进）： ``` -③ 当前版本设计 → ④ 执行案 +③ 执行案 ↓ [PM 审查：执行案质量门] ↓ - ⑤ 程序设计 + ④ 程序设计 ↓ [PM 审查：程序设计质量门] ↓ - ⑥ 美术产出 + ⑤ 美术产出 ↓ [PM 审查：美术资产验收门] ↓ - ⑦ 程序实现 + ⑥ 程序实现 ↓ - ⑧ 版本复盘 + ⑦ 版本复盘 ``` -**③-⑧ 每个步骤都是下一步的必要前置条件，不可跳过或并行。PM 审查不通过则退回重做，不可进入下一步。开发者是质量门争议的最终仲裁者。** +**③-⑦ 每个步骤都是下一步的必要前置条件，不可跳过或并行。PM 审查不通过则退回重做，不可进入下一步。用户是质量门争议的最终仲裁者。** --- @@ -319,8 +318,6 @@ docs/design/production/ 1. **系统清单**：游戏最终包含哪些系统 2. **元素清单**：游戏世界中的关键元素（角色、场景区域、收集品分类、NPC等） 3. **系统关系**：各系统之间如何关联和互相影响 -4. **核心玩法循环**：玩家在游戏中做什么、为什么持续玩 -5. **情感目标**：游戏要给玩家带来什么样的体验和情感 **产出形式**： - 可以有多个文档，按系统或主题拆分 @@ -343,8 +340,10 @@ docs/design/production/ 1. **版本列表**：当前阶段有哪些版本 2. **每个版本的核心目标**：这个版本验证/实现什么 3. **每个版本的范围概述**：大致包含哪些系统和内容 -4. **版本间的递进关系**：为什么先做这些后做那些 -5. **每个版本的验收标准**：怎样算"这个版本做完了" +4. **每个版本的内容完成度**：每种内容做到什么程度（占位/初版/正式） +5. **每个版本涉及的系统清单**：哪些系统需要在本版本实现（引用全局设计案中的系统名） +6. **版本间的递进关系**：为什么先做这些后做那些 +7. **每个版本的验收标准**：怎样算"这个版本做完了" **产出位置**：`docs/plans/prototype-roadmap.md` 或 `docs/plans/production-roadmap.md` @@ -355,30 +354,7 @@ docs/design/production/ --- -### ③ 当前版本设计（策划） - -**目的**：针对最近要做的版本，明确这个版本的目标、范围、需要哪些元素和系统、做到什么程度。 - -**范围**：仅限当前版本，不涉及后续版本。 - -**必须包含的内容**： - -1. **版本目标定位**：这个版本要做到什么程度——是最小能跑的原型、功能完整的可玩版本、还是经过打磨的体验版？ -2. **内容范围**：本版本包含哪些内容，每种内容做到什么完成度（占位/初版/正式） -3. **版本验收标准**：怎样算"这个版本做完了"？验收标准必须明确、可检验 -4. **本版本涉及的系统清单**：哪些系统需要在本版本实现（引用全局设计案中的系统名） - -**产出形式**：可以是阶段路线图中的详细展开，也可以是独立的版本设计文档。放在 `docs/design/<阶段>/` 目录下。 - -**PM 检查要点**： -- 版本目标定位是否明确？ -- 内容范围是否清晰，每种内容的完成度是否定义？ -- 验收标准是否明确、可检验？ -- 范围是否与阶段路线图一致？ - ---- - -### ④ 执行案（策划） +### ③ 执行案（策划） **目的**：针对当前版本中的每个系统/元素，写出完整的**交互规则细节**，细到程序照着这个逻辑实现功能。 @@ -446,7 +422,7 @@ docs/design/production/ ### PM 审查：执行案质量门 -**触发时机**：策划完成执行案（④）后，进入程序设计（⑤）之前。 +**触发时机**：策划完成执行案（③）后，进入程序设计（④）之前。 **审查人**：PM @@ -467,19 +443,19 @@ docs/design/production/ | 严格度 | 重点关注核心行为质量 | 逐条全面检查 | **判定**： -- **通过** → 进入 ⑤ 程序设计 +- **通过** → 进入 ④ 程序设计 - **不通过** → 退回策划修改，列出具体问题清单 -- **争议** → PM 与策划对判定有分歧时，由开发者最终裁决 +- **争议** → PM 与策划对判定有分歧时，由用户最终裁决 **产出**：PM 审查记录（记录在 `docs/plans/review-log.md`） --- -### ⑤ 程序设计（程序） +### ④ 程序设计（程序） **目的**：程序读完策划的执行案后，设计具体的实现方案。 -**前置条件**：执行案（④）已就绪，且 PM 审查通过。 +**前置条件**：执行案（③）已就绪，且 PM 审查通过。 **必须包含的内容**： @@ -503,7 +479,7 @@ docs/design/production/ ### PM 审查：程序设计质量门 -**触发时机**：程序完成技术设计（⑤）后，进入美术产出（⑥）之前。 +**触发时机**：程序完成技术设计（④）后，进入美术产出（⑤）之前。 **审查内容**： @@ -514,23 +490,23 @@ docs/design/production/ 5. **技术风险**：是否识别？ **判定**： -- **通过** → 进入 ⑥ 美术产出 +- **通过** → 进入 ⑤ 美术产出 - **不通过** → 退回程序修改 -- **争议** → PM 与程序对判定有分歧时，由开发者最终裁决 +- **争议** → PM 与程序对判定有分歧时，由用户最终裁决 --- -### ⑥ 美术产出（美术） +### ⑤ 美术产出（美术） **目的**：根据程序输出的美术资源需求清单，产出对应资产。 -**前置条件**：程序设计（⑤）已就绪，且 PM 审查通过。 +**前置条件**：程序设计（④）已就绪，且 PM 审查通过。 **阶段差异**： | 维度 | 原型阶段 | 批量生产阶段 | |------|----------|-------------| -| 资产质量 | 允许占位资源、开发者自行处理 | 正式资产，符合风格指南 | +| 资产质量 | 允许占位资源、用户自行处理 | 正式资产，符合风格指南 | | 完成度 | 能用就行 | 必须满足规格要求 | **产出位置**： @@ -541,7 +517,7 @@ docs/design/production/ ### PM 审查：美术资产验收门 -**触发时机**：美术完成资产产出（⑥）后，进入程序实现（⑦）之前。 +**触发时机**：美术完成资产产出（⑤）后，进入程序实现（⑥）之前。 **审查内容**： @@ -551,13 +527,13 @@ docs/design/production/ 4. **缺失项处理**：未到位资产是否有明确处理方案？ **判定**： -- **通过** → 进入 ⑦ 程序实现 +- **通过** → 进入 ⑥ 程序实现 - **不通过** → 退回美术补充 -- **争议** → PM 与美术对判定有分歧时，由开发者最终裁决 +- **争议** → PM 与美术对判定有分歧时，由用户最终裁决 --- -### ⑦ 程序实现（程序） +### ⑥ 程序实现（程序） **目的**：基于程序设计方案和美术资产，实际编写代码。 @@ -568,15 +544,15 @@ docs/design/production/ | 代码质量 | 允许硬编码、快速实现 | 不允许硬编码，数据配置化，代码达发布标准 | | 验证 | 核心流程跑通即可 | 每个系统独立验证 + 集成验证 | -**实现完成后进入⑧版本复盘**。 +**实现完成后进入⑦版本复盘**。 --- -### ⑧ 版本复盘（程序汇报 → PM 协调 → 策划更新） +### ⑦ 版本复盘（程序汇报 → PM 协调 → 策划更新） **目的**：确保文档与实现一致，为下一个迭代提供准确的起点。 -**触发时机**：程序实现（⑦）完成后。 +**触发时机**：程序实现（⑥）完成后。 **流程**： @@ -622,15 +598,14 @@ PM 在每次 `/plan` 调用时，先判断宏观阶段，再针对**当前版本 |--------|----------|----------| | ① 全局设计案是否存在且完整？ | 检查 `docs/design/<阶段>/` 中的全局设计文档和索引 | 覆盖所有主要系统，有索引串联 | | ② 阶段路线图是否存在？ | 检查 `docs/plans/<阶段>-roadmap.md` | 版本列表、每版本目标、递进关系明确 | -| ③ 当前版本设计是否完整？ | 检查版本设计文档或路线图中的详细描述 | 回答了版本定位、内容范围、验收标准 | -| ④ 执行案是否齐全？ | 检查 `docs/design/<阶段>/` 对应执行案 | 每个涉及系统的核心行为规则都已明确 | +| ③ 执行案是否齐全？ | 检查 `docs/design/<阶段>/` 对应执行案 | 每个涉及系统的核心行为规则都已明确 | | **PM 审查**：执行案质量门 | 对照质量标准逐项检查（注意阶段严格度差异） | 完整性、清晰性、边界情况通过 | -| ⑤ 程序设计方案是否齐全？ | 检查 `docs/technical/` 对应文档 | 每个执行案都有对应技术方案 | +| ④ 程序设计方案是否齐全？ | 检查 `docs/technical/` 对应文档 | 每个执行案都有对应技术方案 | | **PM 审查**：程序设计质量门 | 执行案与技术方案逐条对照 | 行为规则全覆盖，美术需求具体 | -| ⑥ 美术资产是否就位？ | 检查资源需求清单 vs 实际资产 | 所有必需资产已产出或有处理方案 | +| ⑤ 美术资产是否就位？ | 检查资源需求清单 vs 实际资产 | 所有必需资产已产出或有处理方案 | | **PM 审查**：美术资产验收门 | 需求清单 vs 实际资产逐项对照 | 每项需求都有对应产出 | -| ⑦ 程序实现是否完成？ | 检查实际文件 | 实现完成 | -| ⑧ 版本复盘是否完成？ | 检查执行案迭代记录是否 ✅ 已同步 | 策划已根据实现偏差更新文档 | +| ⑥ 程序实现是否完成？ | 检查实际文件 | 实现完成 | +| ⑦ 版本复盘是否完成？ | 检查执行案迭代记录是否 ✅ 已同步 | 策划已根据实现偏差更新文档 | **遇到第一个未通过的即为当前应推进的阶段。** @@ -679,7 +654,7 @@ PM 在每次 `/plan` 调用时，先判断宏观阶段，再针对**当前版本 - [ ] 资产规格是否符合需求？ - [ ] 未到位资产是否有明确的处理方案？ -### 版本复盘标准（对应「⑧版本复盘」） +### 版本复盘标准（对应「⑦版本复盘」） - [ ] 程序是否汇报了实现偏差清单？ - [ ] PM 是否审核了偏差清单并给出协调意见？