ChildHood/.claude/refs/development-workflow.md

游戏开发工作流

本文档定义游戏项目的开发阶段、版本开发流水线、角色职责、产出标准和质量检查规则。 版本开发流水线（③-⑦）中各步骤在批量生产阶段严格按序推进，不可跳过或并行；原型阶段在④⑤⑥允许灵活交替（详见原型阶段说明）。①②为阶段级前置，仅在阶段开始时执行一次，后续版本迭代中不重复执行。

项目管理工具当前使用 Gitea。所有操作命令和标签定义详见 .claude/skills/gitea-collab.md。

---

角色定义

角色	职责	产出位置	PM 如何判断其进度
策划 (Design)	玩法设计、数值平衡、叙事、系统机制	docs/design/、GameConfig/	扫描 docs/design/ 和 GameConfig/ 目录中的文件
程序 (Dev)	系统实现、技术架构、Bug 修复	Source/、Content/、docs/technical/	扫描对应目录中的文件
美术 (Art)	美术需求分析、资产规格、风格指南	docs/art/、Content/	扫描对应目录中的文件
PM	进度追踪、优先级建议、风险预警、流水线推进	项目管理工具（当前为 Gitea Issues）+ docs/plans/reviews/	通过项目管理工具读取任务和里程碑

协作规则

• 策划先行：设计文档是其他角色的需求源
• 程序读设计：实现前必须先读取对应设计文档和配置表
• 文档即交接：Agent 之间不直接通信，通过共享文档目录 + 任务 Issue 评论交接（参见 .claude/skills/gitea-collab.md）
• 冲突时用户说了算：玩法/数值/叙事的最终决定权在用户
• PM 是信息枢纽：跨角色的信息同步和阻塞排查由 PM 负责
• 会话启动先调 PM：每次工作会话开始时，用户必须先调出 PM 执行进度追踪，确认当前状态后再进入具体工作
• 用户驱动角色切换：角色间的工作切换由用户手动触发，PM 不自动指派任务
• 角色任务汇报：各角色通过项目管理工具在任务 Issue 下评论汇报进度，PM 据此追踪

进度汇报规则

• 进度管理唯一真实来源是 项目管理工具（当前为 Gitea Issues + Milestones）。具体操作参见 .claude/skills/gitea-collab.md
• 各角色完成工作后在对应 Issue 下评论汇报，不更新本地 report 文件
• PM 通过项目管理工具读取任务和评论验收各角色工作结果，给出行动建议
• 角色完成工作后汇报结果，PM 验收并建议关闭 Issue，用户确认后由 PM 关闭 Issue
• 任务追踪使用唯一任务 ID（格式：[角色前缀]-[三位数字]），对应 Issue 标题前缀
• 审查记录仍保留在本地 docs/plans/reviews/，同时在 Issue 评论中发布摘要和链接

---

开发阶段

项目开发分为四个宏观阶段，每个阶段有不同的关注重点和流程重量。

草案阶段 ─── "这个游戏是什么？" ─── 轻量流程，每项目一次
    ↓
原型阶段 ─── "这个游戏好玩吗？" ─── 版本流水线（轻量），多版本迭代
    ↓
批量生产阶段 ─── "把游戏做完整" ─── 版本流水线（完整 + 生产工具），多版本迭代
    ↓
测试与发布阶段 ─── "把游戏做稳定" ─── Bug/反馈驱动

阶段转换由用户主观判断，无硬性标准。PM 可建议，但最终决定权在用户。

---

草案阶段

目的：确定游戏是什么——玩法方向、美术风格、技术可行性。

范围：每项目一次，在正式开发之前完成。

关注问题：这个游戏是什么？为什么要做？做不做得了？

产出

玩法草案文档（docs/design/concept.md），包含以下 7 个字段：

1. 一句话描述 — 用一句话说清楚这是什么游戏
2. 玩家核心游玩内容与感受 — 玩家在游戏中的核心操作和活动，以及游戏希望带给玩家的情感基调、视觉风格和整体感受
3. 核心受众画像 — 目标玩家是谁（年龄段、游戏经历、情感诉求），他们为什么会喜欢这款游戏
4. 游戏核心循环 — 玩家在游戏中反复做什么、为什么持续玩
5. 游戏元素 — 世界观、角色、剧情、物品、怪物等关键元素概述
6. 市场定位与三大卖点 — 游戏在市场中的定位（品类、平台、价位），以及最能吸引玩家的三个核心卖点
7. 参考 — 灵感来源（其他游戏、电影、书、某种经历）

美术风格指南（docs/art/style-guide.md）— 确定视觉方向。

技术可行性评估 — 评估核心玩法在目标引擎/平台上的实现可行性。

流程特点

• 极轻量：不需要详细的系统设计，不需要执行案
• 可以反复推翻重来：草案阶段推翻设计成本最低
• 头脑风暴是核心方法：通过讨论探索方向，确认后才进入文档产出

PM 检查要点

• 草案文档 7 个字段是否都已回答？
• 美术风格是否有明确方向？
• 技术上是否可行？
• 用户是否明确表示"可以进入下一阶段"？

完成标志

玩法草案文档产出且用户确认。进入原型阶段后，草案文档不再修改（除非用户决定推翻重来）。

任务管理

草案阶段不使用版本开发流水线。草案阶段的任务管理（如"产出概念草案"）遵循 pm-role-specification.md 中的草图任务类型。

设计文档层级关系

草案、设计案、执行案三者的关系：

层级	定位	比喻	特点
草案 (concept.md)	给游戏定调	灵魂	回答"这个游戏是什么"，简略但方向明确
设计案	给游戏定骨架	骨架	基于草案的原则展开系统设计，定义有哪些系统、系统关系、核心行为
执行案	给游戏填血肉	血肉	细化到程序可直接实现的交互规则和行为细节

设计案初始基于草案的原则进行设计。在后续迭代中遇到具体问题时，可以灵活调整或替换草案中的元素——草案是方向指引，不是硬性约束。

---

原型阶段

目的：验证核心玩法可行性——从最核心功能开始，快速迭代。

关注问题：这个游戏好玩吗？核心循环跑得通吗？

阶段路线图

原型阶段开始时，产出阶段路线图（docs/plans/prototype-roadmap.md）：

• 计划分几个版本迭代
• 每个版本探索哪个方向（验证什么假设）
• 每个版本的验收标准
• 版本间的递进关系

路线图可以在迭代过程中调整。

多版本迭代

原型阶段包含多个版本，每个版本是版本开发流水线的一次循环。版本之间可以：

• 基于上一版本的反馈调整方向
• 增加新的系统验证
• 修改已有系统的行为规则

每个版本的流水线循环：③执行案 → ④程序设计 → ⑤美术产出 → ⑥程序实现 → ⑦版本复盘

①设计案在阶段初期集中产出，后续版本可增量补充。②阶段路线图在阶段开始时产出。

设计文档组织

原型阶段的所有设计案和执行案统一放在 docs/design/prototype/ 目录下：

docs/design/prototype/
  player-controller.md                 # 设计案
  player-controller-execution.md       # 执行案（含迭代版本表头）
  interaction-system.md
  interaction-system-execution.md
  ...

不按版本分子目录——执行案通过文件内的迭代记录表头追踪各版本的变更。

各流水线步骤的原型阶段要求

步骤	原型阶段要求
① 设计案	可以边做边补，不需要一开始就全部完成。新系统先产出简要设计再动手
② 阶段路线图	原型阶段开始时产出，可随迭代调整
③ 执行案	关注影响玩法体验的核心行为。边界情况、非核心反馈等细节可以先略过
④ 程序设计	可以用占位方案，不需要生产级架构。重点回答"怎么实现核心行为"
⑤ 美术产出	允许占位资源、用户自行处理。能用就行
⑥ 程序实现	允许硬编码、允许快速但不优雅的实现。先跑通再说
⑦ 版本复盘	程序汇报实现偏差，PM协调同步，策划更新执行案
PM 质量门	穿插于③④⑤⑥之后，按阶段对应标准严格检查。用户可决定跳过哪些检查项，PM 记录用户的跳过决策

原型阶段灵活性：④⑤⑥允许更紧密的交替推进，不必严格串行。例如在⑤美术产出或⑥程序实现中发现需要调整美术需求，可以回退到④重新设计后继续推进。质量门在每次推进时仍然触发，用户可决定跳过非核心检查项。批量生产阶段恢复严格串行。

版本复盘（每个迭代完成后）

每个版本迭代完成后执行⑦版本复盘，具体要求见下方流水线中的⑦定义。

为什么每个版本都要复盘？ 文档是下一个迭代的起点。如果文档和实现不一致，下一个迭代的执行案会基于错误的假设，导致更多返工。

阶段退出

• 退出标准：用户主观判断核心玩法已验证通过
• 退出时应有：至少一个可玩的核心循环原型，核心系统的执行案已验证可行，文档已同步
• 退出后：将 prototype/ 最终版复制到 production/，prototype/ 保留作为归档

---

批量生产阶段

目的：在核心玩法验证通过的基础上，完善外围系统，填充游戏内容与资产。

关注问题：怎么把游戏做完整？内容够不够？系统之间能不能协同？

阶段路线图

批量生产阶段开始时，产出阶段路线图（docs/plans/production-roadmap.md）：

• 计划分几个版本迭代
• 每个版本的主要内容范围
• 每个版本的验收标准
• 生产工具开发计划（如需要）

多版本迭代

与原型阶段相同，批量生产阶段包含多个版本，每个版本是流水线的一次循环。

设计文档组织

批量生产阶段的所有设计案和执行案统一放在 docs/design/production/ 目录下：

docs/design/production/
  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 审查：程序实现验收门]
      ↓
  ⑦ 版本复盘

③-⑦ 每个步骤都是下一步的必要前置条件，不可跳过或并行（批量生产阶段严格执行；原型阶段④⑤⑥允许灵活交替，见原型阶段说明）。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

版本编号规则：

• 原型阶段：v0.1、v0.2、v0.3……
• 批量生产阶段：从 v1.0 开始，按 v1.1、v1.2 递增
• 版本号反映阶段归属，不跨阶段延续（原型 v0.3 完成后，批量生产从 v1.0 开始）

PM 检查要点：

• 每个版本的范围是否与设计案对齐？
• 版本间是否有清晰的递进逻辑？
• 是否有版本范围过大的风险？

---

③ 执行案（策划）

目的：针对当前版本中的每个系统/元素，写出完整的交互规则细节，细到程序照着这个逻辑实现功能。

范围：仅限当前版本中需要实现的系统。

核心原则：

• 只描述行为和规则，不涉及技术实现
• 必须覆盖所有玩家可感知的行为
• 不能有模糊地带——程序拿到执行案后不应有"这没写要怎么做"的疑问
• 具体参数数值不需要策划提前确定，程序先设初始值，后续体验阶段调优。如有建议值标注"建议值，可调"

执行案格式：

每个执行案文件顶部必须包含迭代记录表头：

# <系统名>执行案

## 迭代记录

| 迭代版本 | 修改日期 | 状态 | 说明 |
|----------|----------|------|------|
| 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/reviews/<任务ID>-review.md）

---

④ 程序设计（程序）

目的：程序读完策划的执行案后，设计具体的实现方案。

前置条件：执行案（③）已就绪，且 PM 审查通过。

必须包含的内容：

1. 实现方案：针对执行案中的每条行为规则，说明打算如何实现
2. 类与组件架构：需要哪些类/组件？继承关系？挂载方式？
3. 数据流：数据从哪里来？系统之间如何通信？
4. 美术资源需求清单：实现这个功能需要哪些美术资源（模型、动画、UI 等），具体到数量和尺寸
5. 技术风险和注意事项：实现中可能遇到的技术难点
6. 工作量估算与实现拆分建议：估算总体工作量（如预计涉及多少文件/类/组件），给出⑥程序实现的推荐拆分方式——按什么维度拆分为可独立验证的子任务，每个子任务大致包含什么内容。供 PM 审核后据此创建⑥的实现任务

阶段差异：

维度	原型阶段	批量生产阶段
架构	可以用占位方案，不需要生产级	需要生产级架构，考虑扩展性
数据流	允许硬编码	数据应配置化
美术需求	允许简化描述	必须具体到尺寸和数量

产出位置：docs/technical/<系统名>-tech.md

---

PM 审查：程序设计质量门

触发时机：程序完成技术设计（④）后，进入美术产出（⑤）之前。

审查内容：

1. 执行案覆盖度：程序设计是否完整回应了执行案中的每条行为规则？逐条对照
2. 美术资源需求：需求是否列得具体？数量、尺寸、触发时机是否明确？
3. 类与组件架构：继承关系和挂载方式是否清晰？
4. 数据流：是否明确？
5. 技术风险：是否识别？
6. 工作量估算与拆分建议：是否给出了工作量估算？拆分方式是否合理（每个子任务可独立验证，粒度适合单人单次会话完成）？拆分后的任务是否能完整覆盖实现方案？

判定：

• 通过 → 进入 ⑤ 美术产出
• 不通过 → 退回程序修改
• 争议 → PM 与程序对判定有分歧时，由用户最终裁决

---

⑤ 美术产出（美术）

目的：根据程序输出的美术资源需求清单，产出对应资产。

前置条件：程序设计（④）已就绪，且 PM 审查通过。

阶段差异：

维度	原型阶段	批量生产阶段
资产质量	允许占位资源、用户自行处理	正式资产，符合风格指南
完成度	能用就行	必须满足规格要求

产出位置：

• 资产放 Content/ 对应目录
• 清单记录在 docs/art/asset-manifest.md 或直接在技术方案中更新

---

PM 审查：美术资产验收门

触发时机：美术完成资产产出（⑤）后，进入程序实现（⑥）之前。

审查内容：

1. 需求覆盖度：逐项对照美术资源需求清单
2. 资产到位确认：资产文件是否已放置在对应目录？
3. 资产规格：尺寸、格式等是否符合需求？
4. 缺失项处理：未到位资产是否有明确处理方案？

判定：

• 通过 → 进入 ⑥ 程序实现
• 不通过 → 退回美术补充
• 争议 → PM 与美术对判定有分歧时，由用户最终裁决

---

⑥ 程序实现（程序）

目的：基于程序设计方案和美术资产，实际编写代码。

前置条件：程序设计（④）已就绪且 PM 审查通过，美术资产（⑤）已就位且 PM 验收通过。

阶段差异：

维度	原型阶段	批量生产阶段
代码质量	允许硬编码、快速实现	不允许硬编码，数据配置化，代码达发布标准
验证	核心流程跑通即可	每个系统独立验证 + 集成验证

实现完成后进入 PM 程序实现验收门，验收通过后进入⑦版本复盘。

---

PM 审查：程序实现验收门

触发时机：程序完成实现（⑥）后，进入版本复盘（⑦）之前。

审查人：PM

审查内容：

1. 设计一致性：实现是否与程序设计方案（④）一致？逐条对照
2. 执行案覆盖度：最终实现是否完整覆盖了执行案（③）中的所有行为规则？
3. 资产使用确认：美术资产是否已正确集成？
4. 完成度评估：当前版本的实现是否达到了阶段要求的完成度？
5. 偏差梳理：实现中产生的偏差是否已梳理，偏差等级是否合理？

偏差处理规则：

偏差等级	判定标准	处理方式
轻微	不影响核心行为，仅实现细节差异	记录在偏差清单，在⑦版本复盘时同步文档
重大	影响核心行为或与设计方案严重不一致	PM 建议回退到③重新出执行案或开启新版本修正，由用户决定

判定：

• 通过 → 进入 ⑦ 版本复盘
• 不通过（轻微） → 程序补充修正后重新验收
• 不通过（重大） → PM 提出处理建议（回退步骤或开新版本），由用户最终决定
• 争议 → PM 与程序对判定有分歧时，由用户最终裁决

产出：PM 审查记录（记录在 docs/plans/reviews/<任务ID>-review.md）

---

⑦ 版本复盘（程序汇报 → PM 协调 → 策划更新）

目的：确保文档与实现一致，为下一个迭代提供准确的起点。

触发时机：PM 程序实现验收门通过后。

流程：

1. 程序汇报：程序对照执行案，列出实现中产生的偏差和调整
2. PM 协调：PM 汇总程序汇报的偏差清单，协调策划进行文档更新
3. 策划更新：策划根据偏差清单，更新设计案和执行案
4. 标记状态：执行案迭代记录中该版本标记为 ✅ 已同步

必须更新的内容：

• 设计案中与实际不符的系统描述
• 执行案中与实际实现不一致的行为规则
• 执行案迭代记录中新增一行，记录变更

阶段差异：

维度	原型阶段	批量生产阶段
偏差记录	核心行为的偏差必须记录	所有差异必须记录在案
文档同步	核心系统必须同步	所有系统必须同步

为什么必须复盘

• 文档是下一个迭代的起点。如果文档和实现不一致，下一个迭代会基于错误假设
• PM 的质量门审查基于文档。文档不准确会导致审查无效
• 程序在实现时可能发现设计的问题并做了调整，这些调整必须反映到文档中

---

PM 诊断检查清单

PM 在每次 /plan 调用时，先判断宏观阶段，再针对当前版本逐项检查流水线状态。

宏观阶段判断

检查项	判断方式	结果
项目处于哪个开发阶段？	检查 concept.md → 检查核心玩法是否已有可玩原型 → 检查内容是否已完整	草案 / 原型 / 批量生产 / 测试发布

版本流水线检查

检查项	检查方式	通过条件
① 设计案是否存在且完整？	检查 docs/design/<阶段>/ 中的设计文档和索引	覆盖所有主要系统，有索引串联
② 阶段路线图是否存在？	检查 docs/plans/<阶段>-roadmap.md	版本列表、每版本目标、递进关系明确
③ 执行案是否齐全？	检查 docs/design/<阶段>/ 对应执行案	每个涉及系统的核心行为规则都已明确
PM 审查：执行案质量门	对照质量标准逐项检查	完整性、清晰性、边界情况通过
④ 程序设计方案是否齐全？	检查 docs/technical/ 对应文档	每个执行案都有对应技术方案
PM 审查：程序设计质量门	执行案与技术方案逐条对照	行为规则全覆盖，美术需求具体，工作量与拆分建议明确
⑤ 美术资产是否就位？	检查资源需求清单 vs 实际资产	所有必需资产已产出或有处理方案
PM 审查：美术资产验收门	需求清单 vs 实际资产逐项对照	每项需求都有对应产出
⑥ 程序实现是否完成？	检查实际文件	实现完成
PM 审查：程序实现验收门	实现与设计方案逐条对照 + 偏差分级处理	设计一致，偏差已处理或有明确方案
⑦ 版本复盘是否完成？	检查执行案迭代记录是否 ✅ 已同步	策划已根据实现偏差更新文档

遇到第一个未通过的即为当前应推进的步骤。

注意：所有质量门按阶段对应标准严格检查。用户可根据实际情况决定跳过特定检查项，PM 记录用户的跳过决策及理由。

---

文档质量检查标准

以下标准对应流水线中的三道 PM 质量门。

执行案质量标准（对应「执行案质量门」）

完整性检查：

• 是否覆盖了该系统所有玩家可感知的行为？
• 每个操作是否明确了触发条件、触发后表现、结束条件？
• 边界情况是否都处理了？
• 与其他系统的关联是否说明？

清晰性检查：

• 是否有模糊地带？
• 行为描述是否无歧义？
• 程序拿到后能否不问策划任何问题就实现功能？

边界检查：

• 是否误入了技术细节？
• 精确参数值是否标注为"建议值，可调"而非固定值？

迭代记录检查：

• 迭代记录表头是否存在且填写完整？
• 已完成版本的文档是否已同步（✅ 已同步）？

程序设计质量标准（对应「程序设计质量门」）

• 是否完整回应了执行案中的每条行为规则？（逐条对照）
• 美术资源需求是否列得具体（尺寸、数量、触发时机）？
• 类与组件架构是否清晰？
• 数据流是否明确？
• 技术风险是否识别？
• 工作量估算是否给出？实现拆分建议是否合理且可操作？

美术资产验收标准（对应「美术资产验收门」）

• 资源需求清单中的每一项是否都有对应的美术产出？（逐项对照）
• 资产文件是否已放置在对应目录？
• 资产路径是否记录清晰？
• 资产规格是否符合需求？
• 未到位资产是否有明确的处理方案？

程序实现验收标准（对应「程序实现验收门」）

• 实现是否与程序设计方案一致？（逐条对照）
• 最终实现是否完整覆盖了执行案中的所有行为规则？
• 美术资产是否已正确集成并使用？
• 当前版本的实现是否达到了阶段要求的完成度？
• 偏差清单是否已梳理清楚？
• 重大偏差是否有明确的处理方案（回退步骤或开新版本）？

版本复盘标准（对应「⑦版本复盘」）

• 程序是否汇报了实现偏差清单？
• PM 是否审核了偏差清单并给出协调意见？
• 策划是否根据协调结果更新了设计案/执行案？
• 执行案迭代记录是否新增一行并标记 ✅ 已同步？

---

单人独立开发的特殊考量

• 无法并行——同一时间只能做一件事，选择更关键
• 精力有限——避免一次性拆分太多并行任务
• 心流重要——建议按「完整做完一个小系统」而非「同时推进多个系统」的方式工作
• 早期验证——越早能跑起来看到东西，越不容易失去动力
• 文档交接——Agent 之间通过文档交接，PM 是信息枢纽