docs(workflow): 优化草案字段与精简流水线步骤

- 草案文档：合并「玩家能做什么」+「游戏氛围与风格」为「玩家核心游玩内容与感受」
- 草案文档：新增「核心受众画像」和「市场定位与三大卖点」字段(6→7项)
- 全局设计案：移除与草案重复的「核心玩法循环」和「情感目标」
- 删除冗余的③当前版本设计步骤，其内容完成度信息合并到②路线图
- 流水线步骤从③-⑧重编号为③-⑦，全文件40+处引用同步更新

.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 是否审核了偏差清单并给出协调意见？