docs(workflow): 修复开发流程文档7项逻辑问题

.claude/refs/development-workflow.md

@@ -1,7 +1,7 @@
 # 游戏开发工作流
 
 > 本文档定义游戏项目的开发阶段、版本开发流水线、角色职责、产出标准和质量检查规则。
-> 版本开发流水线（③-⑦）中各步骤严格按序推进，不可跳过或并行。①②为阶段级前置，仅在阶段开始时执行一次，后续版本迭代中不重复执行。
+> 版本开发流水线（③-⑦）中各步骤在批量生产阶段严格按序推进，不可跳过或并行；原型阶段在④⑤⑥允许灵活交替（详见原型阶段说明）。①②为阶段级前置，仅在阶段开始时执行一次，后续版本迭代中不重复执行。
 
 ---
 
@@ -158,7 +158,7 @@ docs/design/prototype/
 | ⑤ 美术产出 | 允许占位资源、用户自行处理。能用就行 |
 | ⑥ 程序实现 | 允许硬编码、允许快速但不优雅的实现。先跑通再说 |
 | ⑦ 版本复盘 | 程序汇报实现偏差，PM协调同步，策划更新执行案 |
-| *PM 质量门* | *穿插于③④⑤之后，关注核心行为是否完整描述，不要求面面俱到* |
+| *PM 质量门* | *穿插于③④⑤⑥之后，关注核心行为是否完整描述/实现，不要求面面俱到* |
 
 > **原型阶段灵活性**：④⑤⑥允许更紧密的交替推进，不必严格串行。例如程序设计时发现需要调整美术需求，可以回退到④补充后继续。批量生产阶段恢复严格串行。
 
@@ -218,7 +218,7 @@ docs/design/production/
 | ⑤ 美术产出 | 正式资产，符合风格指南。不允许占位 |
 | ⑥ 程序实现 | 不允许硬编码，数据应配置化。代码质量需达到发布标准 |
 | ⑦ 版本复盘 | 程序汇报实现偏差，PM协调同步，策划更新执行案。所有差异必须记录 |
-| *PM 质量门* | *穿插于③④⑤之后，完整执行所有检查项，逐条对照* |
+| *PM 质量门* | *穿插于③④⑤⑥之后，完整执行所有检查项，逐条对照* |
 
 #### 版本复盘（每个迭代完成后）
 
@@ -235,7 +235,7 @@ docs/design/production/
 | 批量资产生成工具 | 批量生成/导入美术资产 | 资产量大时 |
 | 测试工具 | 自动化验证、数据校验 | 手动测试效率低时 |
 
-工具开发本身也应遵循版本流水线（有执行案、有程序设计），但可以简化流程。
+工具开发本身也应遵循版本流水线（有执行案、有程序设计），但允许省略美术产出步骤（⑤）和对应的美术验收门。
 
 #### 阶段退出
 
@@ -300,6 +300,8 @@ docs/design/production/
       ↓
   ⑥ 程序实现
       ↓
+  [PM 审查：程序实现验收门]
+      ↓
   ⑦ 版本复盘
 ```
 
@@ -315,7 +317,7 @@ docs/design/production/
 
 **必须包含的内容**：
 
-1. **系统清单**：游戏最终包含哪些系统
+1. **系统清单**：当前阶段目标形态包含哪些系统
 2. **元素清单**：游戏世界中的关键元素（角色、场景区域、收集品分类、NPC等）
 3. **系统关系**：各系统之间如何关联和互相影响
 
@@ -325,7 +327,7 @@ docs/design/production/
 - 产出位置：`docs/design/<阶段>/`（`prototype/` 或 `production/`）。不同阶段的全局设计案独立维护：原型阶段描述"原型要验证什么"，批量生产阶段描述"完整游戏要做成什么样"
 
 **PM 检查要点**：
-- 是否覆盖了游戏最终形态的所有主要系统？
+- 是否覆盖了当前阶段目标形态的所有主要系统？
 - 系统关系是否清晰（谁依赖谁、谁独立）？
 - 索引文档是否存在且能串联所有全局设计文档？
 
@@ -537,6 +539,8 @@ docs/design/production/
 
 **目的**：基于程序设计方案和美术资产，实际编写代码。
 
+**前置条件**：程序设计（④）已就绪且 PM 审查通过，美术资产（⑤）已就位且 PM 验收通过。
+
 **阶段差异**：
 
 | 维度 | 原型阶段 | 批量生产阶段 |
@@ -544,7 +548,39 @@ docs/design/production/
 | 代码质量 | 允许硬编码、快速实现 | 不允许硬编码，数据配置化，代码达发布标准 |
 | 验证 | 核心流程跑通即可 | 每个系统独立验证 + 集成验证 |
 
-**实现完成后进入⑦版本复盘**。
+**实现完成后进入 PM 程序实现验收门，验收通过后进入⑦版本复盘。**
+
+---
+
+### PM 审查：程序实现验收门
+
+**触发时机**：程序完成实现（⑥）后，进入版本复盘（⑦）之前。
+
+**审查人**：PM
+
+**审查内容**：
+
+1. **设计一致性**：实现是否与程序设计方案（④）一致？逐条对照
+2. **执行案覆盖度**：最终实现是否完整覆盖了执行案（③）中的所有行为规则？
+3. **资产使用确认**：美术资产是否已正确集成？
+4. **完成度评估**：当前版本的实现是否达到了阶段要求的完成度？
+5. **偏差梳理**：实现中产生的偏差是否已梳理，偏差等级是否合理？
+
+**偏差处理规则**：
+
+| 偏差等级 | 判定标准 | 处理方式 |
+|----------|----------|----------|
+| **轻微** | 不影响核心行为，仅实现细节差异 | 记录在偏差清单，在⑦版本复盘时同步文档 |
+| **重大** | 影响核心行为或与设计方案严重不一致 | PM 建议回退到③重新出执行案或开启新版本修正，由用户决定 |
+
+**判定**：
+
+- **通过** → 进入 ⑦ 版本复盘
+- **不通过（轻微）** → 程序补充修正后重新验收
+- **不通过（重大）** → PM 提出处理建议（回退步骤或开新版本），由用户最终决定
+- **争议** → PM 与程序对判定有分歧时，由用户最终裁决
+
+**产出**：PM 审查记录（记录在 `docs/plans/review-log.md`）
 
 ---
 
@@ -573,7 +609,7 @@ docs/design/production/
 | 偏差记录 | 核心行为的偏差必须记录 | 所有差异必须记录在案 |
 | 文档同步 | 核心系统必须同步 | 所有系统必须同步 |
 
-### 为什么必须复盘
+#### 为什么必须复盘
 
 - 文档是下一个迭代的起点。如果文档和实现不一致，下一个迭代会基于错误假设
 - PM 的质量门审查基于文档。文档不准确会导致审查无效
@@ -605,6 +641,7 @@ PM 在每次 `/plan` 调用时，先判断宏观阶段，再针对**当前版本
 | ⑤ 美术资产是否就位？ | 检查资源需求清单 vs 实际资产 | 所有必需资产已产出或有处理方案 |
 | **PM 审查**：美术资产验收门 | 需求清单 vs 实际资产逐项对照 | 每项需求都有对应产出 |
 | ⑥ 程序实现是否完成？ | 检查实际文件 | 实现完成 |
+| **PM 审查**：程序实现验收门 | 实现与设计方案逐条对照 + 偏差分级处理 | 设计一致，偏差已处理或有明确方案 |
 | ⑦ 版本复盘是否完成？ | 检查执行案迭代记录是否 ✅ 已同步 | 策划已根据实现偏差更新文档 |
 
 **遇到第一个未通过的即为当前应推进的阶段。**
@@ -654,6 +691,15 @@ PM 在每次 `/plan` 调用时，先判断宏观阶段，再针对**当前版本
 - [ ] 资产规格是否符合需求？
 - [ ] 未到位资产是否有明确的处理方案？
 
+### 程序实现验收标准（对应「程序实现验收门」）
+
+- [ ] 实现是否与程序设计方案一致？（逐条对照）
+- [ ] 最终实现是否完整覆盖了执行案中的所有行为规则？
+- [ ] 美术资产是否已正确集成并使用？
+- [ ] 当前版本的实现是否达到了阶段要求的完成度？
+- [ ] 偏差清单是否已梳理清楚？
+- [ ] 重大偏差是否有明确的处理方案（回退步骤或开新版本）？
+
 ### 版本复盘标准（对应「⑦版本复盘」）
 
 - [ ] 程序是否汇报了实现偏差清单？