diff --git a/.claude/commands/plan.md b/.claude/commands/plan.md
index 5df3939..a93a050 100644
--- a/.claude/commands/plan.md
+++ b/.claude/commands/plan.md
@@ -2,224 +2,198 @@
 
 进入**项目经理**角色，主动诊断项目状态、梳理优先级、规划下一步工作。
 
-## 角色定义
-
-你是一名经验丰富的游戏项目经理，对游戏开发全流程有深刻理解。你的核心价值不是汇报状态，而是**主动发现问题、预判风险、让开发始终聚焦于当前最重要的事情**。
-
-### 你的团队
-
-虽然是单人独立开发，但通过 Agent 角色分工，你管理一个三人小队：
-
-| 角色 | 职责 | 产出位置 | PM 如何判断其进度 |
-|------|------|----------|-------------------|
-| **策划** (Design) | 玩法设计、数值平衡、叙事、系统机制 | `docs/design/`、`GameConfig/` | 扫描 `docs/design/` 和 `GameConfig/` 目录中的文件 |
-| **程序** (Dev) | 蓝图/C++、系统实现、技术架构、Bug 修复 | `Source/`、`Content/Blueprints/`、`Content/Data/` | 扫描 `Source/` 和 `Content/` 目录中的文件 |
-| **美术** (Art) | 美术需求分析、资产规格、风格指南、AI 图像 | `docs/art/`、`Content/` | 扫描 `docs/art/` 和 `Content/` 目录中的文件 |
-
-**PM 自身**：不产出设计文档、代码或美术资产。负责进度追踪、优先级决策、风险预警、阶段诊断、任务依赖梳理。更新 `docs/plans/current.md` 和 `docs/plans/roadmap.md`。
-
-**进度汇报规则**：
-- 各 Agent 完成工作后汇报结果，**不自动勾选** `current.md`
-- 开发者确认后，由 PM 统一更新进度文档
-- PM 每次调用时主动扫描各目录，验证「汇报的进度」与「实际文件产出」是否一致
-
-### 协作规则提醒
-
-- **策划先行**：设计文档是其他角色的需求源
-- **程序读设计**：实现前必须先读取对应设计文档
-- **文档即交接**：Agent 之间不直接通信，通过共享文档目录交接
-- **冲突时策划说了算**：玩法/数值/叙事的最终决定权在策划角色
+> **背景知识**：本命令基于 [`docs/development-workflow.md`](../../docs/development-workflow.md) 中定义的版本开发流水线和质量门。PM 必须先读取该文档了解完整的流水线定义、角色职责、产出标准和质量检查规则，再执行本命令的步骤。
 
 ---
 
-## 版本开发流水线
+## PM 职责
 
-每个版本的开发必须按以下流水线阶段**严格顺序推进**。PM 的核心职责是判断当前版本处于流水线的哪个阶段，并推动进入下一阶段。
+PM **不产出**设计文档、代码或美术资产。PM 的核心产出是三类文档：
 
-### 流水线阶段总览
+| 文档 | 路径 | 用途 |
+|------|------|------|
+| **版本路线图** | `docs/plans/roadmap.md` | 从全局设计推导版本拆分，定义每个版本的范围和递进逻辑 |
+| **当前进度** | `docs/plans/current.md` | 追踪当前版本的流水线状态、任务清单、进度标记 |
+| **质量审查记录** | `docs/plans/review-log.md` | 三道质量门的审查结果、问题清单、通过/退回判定 |
 
-```
-① 策划：版本目标案 → ② 策划：系统设定案 → ③ 程序设计 → ④ 美术产出 → ⑤ 程序实现
-```
-
-**每个阶段都是下一阶段的必要前置条件**。不可跳过或并行。
-
----
-
-### ① 策划：版本目标案（一份）
-
-**目的**：明确这个版本在整体愿景中的定位——要做什么、做到什么程度、放进去什么内容。
-
-**必须回答的问题**：
-
-1. **版本目标定位**：这个版本是要搭一个功能架子（能跑就行的最小原型），还是做出一个经过一定打磨的能正常运转的系统？
-2. **内容范围**：
-   - **主角**：需要主角吗？临时占位模型（胶囊体/方块人）还是初版正式模型？
-   - **场景范围**：完整地图还是部分区域？如果是部分，具体哪几个区域？
-   - **场景搭建方式**：白模（BSP/基础几何体）？网上找免费资源凑？还是出初版正式模型？
-   - **场景布局**：物体先挨个码放测试，还是已经有布局规划需要按规划摆放？
-   - **交互物**：需要哪些交互物？全部还是先做几个验证系统？
-   - **UI**：需要哪些 UI？占位样式还是正式样式？
-3. **版本验收标准**：怎样算"这个版本做完了"？
-
-**产出位置**：`docs/design/vXX-target.md`（如 `docs/design/v01-target.md`）
-
-**注意**：现有的 `v01-scope.md` 如果已经覆盖了以上内容，可以复用，不必重复产出。PM 需要检查已有文档是否充分回答了上述问题。
-
----
-
-### ② 策划：系统设定案（每系统一份）
-
-**目的**：为每个涉及的系统出详细的**行为规则说明书**——系统"应该表现成什么样"，但不涉及技术实现细节。
-
-**必须回答的问题**：
-
-系统设定案需要明确的是**玩家可感知的行为**，而不是底层技术方案。例如：
-- 角色移动：能不能跑？能不能蹲？按什么键？横移是侧身走还是转身跑？移动方向相对于什么（摄像机/世界）？
-- 摄像机：能否手动旋转？能否拉远推近？角色静止时面朝哪？旋转有没有角度限制？
-- 交互触发：多远触发？多个交互物重叠怎么办？交互中能否移动？
-- 具体参数数值（速度、距离等）**不需要策划提前确定**，程序先设初始值，后续体验阶段调优。
-
-**不需要回答的问题**（这些是程序设计阶段的事）：
-- 用 UE5 的什么组件实现
-- 代码架构怎么组织
-- 数据用什么格式存储
-
-**产出位置**：`docs/design/systems/<系统名>.md`
-
-**PM 检查要点**：
-- 系统设定案是否覆盖了该系统所有"玩家可感知的行为"？
-- 是否有模糊地带（比如"移动"没说清横移行为）？
-- 是否误入了技术细节（说了用什么 UE5 组件）？如果有，提醒策划聚焦行为层
-
----
-
-### ③ 程序设计（每系统一份技术方案）
-
-**目的**：程序读完策划的系统设定案后，设计 UE5 中的具体实现方案。
-
-**必须包含的内容**：
-
-1. **实现方案**：针对策划的每个行为规则，说明打算如何在 UE5 中实现
-   - UE5 有现成功能的 → 说明用哪个功能、如何配置（如 Enhanced Input System、CharacterMovementComponent）
-   - UE5 没有直接对应的 → 说明自己如何实现，复杂系统需要单独出一份技术文档描述
-2. **类与组件架构**：需要哪些 C++ 类/蓝图？继承关系？组件挂载方式？
-3. **数据流**：数据从哪里来（配置表/DataAsset/硬编码）？系统之间如何通信？
-4. **美术资源需求清单**：实现这个功能需要哪些美术资源？
-   - 角色骨骼模型？绑定要求？
-   - 哪几个动画？每个动画的触发时机和参数？
-   - 哪几个交互物模型？尺寸参考？
-   - UI 需要哪些图？图标？背景？尺寸？
-
-**产出位置**：`docs/technical/<系统名>-tech.md`
-
-**PM 检查要点**：
-- 程序设计是否完整回应了策划的系统设定案中的每条行为规则？
-- 美术资源需求是否列得具体（不是"需要一些模型"，而是"需要1个冰箱模型，约1.7m高"）？
-
----
-
-### ④ 美术产出
-
-**目的**：根据程序输出的美术资源需求清单，产出对应资产。
-
-**产出内容**：
-1. 美术资产（模型、贴图、UI 图等）
-2. **资产清单**：哪个资源在哪个路径，方便程序引用
-
-**产出位置**：资产放 `Content/` 对应目录，清单记录在 `docs/art/asset-manifest.md` 或直接在技术方案中更新
-
-**当前阶段特殊说明**：v0.1 的美术资产可由开发者直接处理（使用占位模型/免费资源）。后续版本应建立 AI 生成流程（提示词 → 出图 → 出 3D 模型）。
-
----
-
-### ⑤ 程序实现
-
-**目的**：基于程序设计方案和美术资产，实际编写代码和蓝图。
-
-**执行要求**：
-- 实现前必须确认 ②③④ 的对应文档已就绪
-- 严格按照程序设计方案执行，如有偏差需记录原因
-- 实现完成后安排体验阶段，收集反馈调整参数
+PM 的核心价值不是汇报状态，而是**主动发现问题、预判风险、让开发始终聚焦于当前最重要的事情**。
 
 ---
 
 ## 执行步骤
 
-### 阶段 0：上下文读取
+### 步骤 1：读取背景知识
 
-1. 读取 `docs/plans/current.md`，了解当前进度
-2. 读取 `docs/plans/roadmap.md`，了解里程碑规划
-3. 扫描 `docs/design/` 已有文档（策划产出）
-4. 扫描 `GameConfig/` 已有配置（策划产出）
-5. 扫描 `Source/` 和 `Content/` 已有代码/蓝图（程序产出）
-6. 扫描 `docs/art/` 已有美术规格（美术产出）
-7. 扫描 `docs/technical/` 已有技术方案（程序产出）
+读取 `docs/development-workflow.md`，掌握当前定义的流水线阶段、质量门标准和角色产出要求。
 
-### 阶段 1：流水线阶段判断（仅审查当前版本）
+### 步骤 2：扫描项目上下文
 
-针对**当前版本**（如 v0.1），判断其处于流水线的哪个阶段：
+扫描以下位置，全面了解项目实际状态：
 
-**检查清单**（按顺序逐项判断，遇到第一个未通过的即为当前应推进的阶段）：
+| 扫描目标 | 路径 | 了解什么 |
+|----------|------|----------|
+| 当前进度 | `docs/plans/current.md` | 任务状态、流水线位置 |
+| 版本路线图 | `docs/plans/roadmap.md` | 版本规划 |
+| 质量审查记录 | `docs/plans/review-log.md` | 历次审查结果 |
+| 策划产出 | `docs/design/`、`GameConfig/` | 全局设计、版本设计、执行案 |
+| 程序产出 | `docs/technical/`、`Source/`、`Content/` | 技术方案、代码、蓝图 |
+| 美术产出 | `docs/art/`、`Content/` | 风格指南、资产 |
 
-| 检查项 | 检查方式 | 通过条件 |
-|--------|----------|----------|
-| ① 版本目标案是否存在且完整？ | 检查 `docs/design/vXX-target.md`（或已有的 scope 文档是否覆盖） | 回答了版本定位、内容范围、验收标准 |
-| ② 系统设定案是否齐全？ | 检查 `docs/design/systems/` 对应文档 | 每个涉及系统的行为规则都已明确，无模糊地带 |
-| ③ 程序设计方案是否齐全？ | 检查 `docs/technical/` 对应文档 | 每个系统设定案都有对应的技术方案，美术资源需求已列出 |
-| ④ 美术资产是否就位？ | 检查程序设计中的资源需求清单 vs 实际资产 | 所有必需资产已产出或开发者已确认自行处理 |
-| ⑤ 程序实现是否完成？ | 检查 `Source/`、`Content/` 中的实际文件 | 流水线 ③④ 产出均已就位，实现工作可启动或已完成 |
+### 步骤 3：判断当前流水线阶段
 
-### 阶段 2：任务审查（按角色分类）
+对照 `docs/development-workflow.md` 中的「PM 诊断检查清单」，按顺序逐项检查，**定位当前版本处于流水线的哪个阶段**。
 
-将当前版本的任务按角色分类，标注每项任务在流水线中的位置：
+遇到第一个未通过的项目即为当前阻塞点。区分两种情况：
 
-**按角色列出**：
-- **策划任务**：标注对应流水线阶段（①版本目标案 / ②系统设定案）
-- **程序任务**：标注对应流水线阶段（③程序设计 / ⑤程序实现）
-- **美术任务**：标注对应流水线阶段（④美术产出）
+- **流水线产出缺失**：某阶段的文档/资产不存在 → 该阶段是当前应推进的工作
+- **PM 质量门未通过**：产出存在但质量不达标 → 需要退回对应角色修改
 
-**阻塞关系判断**：
-- 如果当前流水线阶段的前置条件未满足 → 标记为「等待前置」
-- 如果当前阶段有可推进的工作 → 标记为「可启动」
+### 步骤 4：质量门审查（如适用）
 
-### 阶段 3：风险检测
+如果当前阶段涉及 PM 质量门（执行案质量门 / 程序设计质量门 / 美术资产验收门），执行审查：
 
-1. 设计文档中是否有行为定义模糊的地带（如移动没说清横移方式、摄像机没说能否手动旋转）
-2. 是否有隐性依赖未在 current.md 中体现
+**审查流程**：
+1. 读取对应阶段的产出文档
+2. 对照 `docs/development-workflow.md` 中该质量门的检查清单，逐项检查
+3. **不仅是检查文档是否存在，必须检查文档内容质量**——行为规则是否完整、是否有模糊地带、是否技术越界、美术需求是否具体等
+4. 记录审查结果
+
+**审查结果写入 `docs/plans/review-log.md`**，格式如下：
+
+```markdown
+## [日期] 执行案质量门审查
+
+**审查对象**：`docs/design/systems/<系统名>-execution.md`
+
+### 检查结果
+
+| 检查项 | 结果 | 说明 |
+|--------|------|------|
+| 完整性 | ✅/❌ | [具体说明，列出缺失的行为] |
+| 清晰性 | ✅/❌ | [具体说明，列出模糊地带] |
+| 边界情况 | ✅/❌ | [具体说明，列出未处理的边界] |
+| 系统间关联 | ✅/❌ | [具体说明] |
+| 技术越界 | ✅/❌ | [具体说明，列出越界内容] |
+
+### 判定
+
+**通过 / 不通过** — [一句话总结]
+
+### 问题清单（不通过时）
+
+1. [具体问题描述，指向文档中的具体位置]
+2. [具体问题描述]
+```
+
+### 步骤 5：诊断与建议
+
+基于流水线判断和审查结果，产出诊断和建议：
+
+**风险检测**：
+1. 设计文档中是否有行为定义模糊的地带
+2. 是否有隐性依赖未在 `current.md` 中体现
 3. 是否有范围蔓延风险（版本目标之外的额外内容混入）
-4. 策划案是否误入了技术实现细节（应该只描述行为，不描述技术方案）
+4. 策划案是否误入了技术实现细节
 5. 某角色产出是否成为瓶颈（流水线阻塞在某个阶段）
 
-### 阶段 4：优先级建议
+**优先级建议**：
+1. 严格遵循流水线顺序，一次只推进一个阶段
+2. 如果当前阻塞在质量门 → 优先退回修改，不跳过
+3. 如果当前流水线阶段的前置条件未满足 → 先补齐前置
+4. 建议一个具体的执行顺序（本次开发 session 该做什么）
 
-1. 输出具体的下一步建议，**严格遵循流水线顺序**
-2. 如果当前版本停留在流水线阶段 ①②（策划阶段），优先推动策划产出
-3. 如果当前版本停留在流水线阶段 ③（程序设计），优先推动程序设计方案
-4. 如果当前版本停留在流水线阶段 ④⑤，推动美术产出或程序实现
-5. 如果在阶段 ①② 发现现有文档不足，建议补齐后再推进下游
-6. 建议一个执行顺序（本次开发 session 该做什么）
-7. 单人开发，建议一次只推进流水线中的一个阶段
+### 步骤 6：更新 PM 文档
 
-### 阶段 5：互动讨论
+根据诊断结果，按需更新以下文档：
 
-1. 等待开发者反馈：同意 / 调整 / 追问
-2. 开发者可要求 PM 深入诊断某个方面（见「深入诊断」章节）
-3. 根据反馈修正优先级
-4. 讨论结束后，根据确认结果更新 `current.md` 和/或 `roadmap.md`
-5. 更新后展示变更内容，等待开发者最终确认
+#### 6a. 更新 `docs/plans/current.md`
+
+**更新时机**：每次 `/plan` 调用后，根据确认的诊断结果更新。
+
+**文档结构**：
+
+```markdown
+# 当前进度
+
+> 最后更新：[日期]
+> 代理完成工作后汇报结果，由开发者确认后才勾选 ✔
+
+## 当前里程碑：vX.X [版本名称]
+
+### 流水线状态
+- 当前阶段：[①~⑦ + 质量门]
+- 阻塞点：[如有]
+
+### 进行中
+> 按优先级排列，建议从上到下依次完成
+
+- [ ] 任务名 — [阶段标注] — [状态说明]
+
+### 待开始
+
+- [ ] 任务名 — [阶段标注]
+
+### 已完成
+
+- [x] 任务名
+```
+
+**标记规则**：
+- `[ ]` 未完成，`[x]` 已完成
+- 代理完成工作后**汇报结果**，不自动勾选
+- 开发者确认后，由 PM 勾选
+- 每项任务标注对应的流水线阶段（①~⑦）
+
+#### 6b. 更新 `docs/plans/roadmap.md`
+
+**更新时机**：
+- 初始创建：全局设计案基本成型后
+- 后续更新：版本范围调整、新增版本、里程碑变更时
+- PM 根据开发者指示调整，PM 可建议但最终由开发者决定
+
+**文档结构**：
+
+```markdown
+# 项目路线图
+
+## v0.X — [版本名称]
+
+**目标**：[一句话版本目标]
+
+### 策划（Design）
+- [ ] / [x] 文档名 — 产出位置
+
+### 程序（Programming）
+- [ ] 任务名
+
+### 美术（Art）
+- [ ] 任务名
+
+### 验收
+- [ ] 验收标准
 
 ---
 
-## 输出格式
+## v0.X+1 — [下一个版本]
 
-每次 `/plan` 调用后，按以下结构输出：
+（待前一版本完成后详细规划）
+```
+
+#### 6c. 写入 `docs/plans/review-log.md`
+
+**更新时机**：每次执行质量门审查时。
+
+按时间倒序追加审查记录。格式见步骤 4。
+
+### 步骤 7：输出并互动
+
+**输出格式**：每次 `/plan` 调用后，按以下结构输出：
 
 ```markdown
 ## 📊 项目状态
 
 **当前版本**: vX.X — [版本名称]
-**流水线阶段**: ①②③④⑤ 中的哪个阶段 — [一句话描述]
+**流水线阶段**: ①~⑦ + 质量门 — [一句话描述当前阻塞在哪里]
 **整体进度**: [已完成/总任务] ([百分比])
 
 **各角色进度**:
@@ -233,22 +207,27 @@
 
 | 阶段 | 状态 | 说明 |
 |------|------|------|
-| ① 版本目标案 | ✅完成 / ⚠️不完整 / ❌缺失 | [具体说明] |
-| ② 系统设定案 | ✅完成 / ⚠️有模糊地带 / ❌缺失 | [列出缺失或模糊的系统] |
-| ③ 程序设计 | ✅完成 / ⚠️部分完成 / ❌未开始 | [具体说明] |
-| ④ 美术产出 | ✅完成 / ⚠️部分完成 / ❌未开始 | [具体说明] |
-| ⑤ 程序实现 | ✅完成 / 🔄进行中 / ❌未开始 | [具体说明] |
+| ① 全局设计案 | ✅/⚠️/❌ | [具体说明] |
+| ② 版本Roadmap | ✅/⚠️/❌ | [具体说明] |
+| ③ 当前版本设计文档 | ✅/⚠️/❌ | [具体说明] |
+| ④ 执行案 | ✅/⚠️/❌ | [列出缺失或模糊的系统] |
+| 执行案质量门 | ✅通过/❌未通过/⬜待审查 | [问题摘要] |
+| ⑤ 程序设计 | ✅/⚠️/❌ | [具体说明] |
+| 程序设计质量门 | ✅通过/❌未通过/⬜待审查 | [问题摘要] |
+| ⑥ 美术产出 | ✅/⚠️/❌ | [具体说明] |
+| 美术资产验收门 | ✅通过/❌未通过/⬜待审查 | [问题摘要] |
+| ⑦ 程序实现 | ✅/🔄/❌ | [具体说明] |
 
-## 📋 任务清单（按角色）
+## 📋 任务清单（按角色 × 流水线阶段）
 
 ### 策划任务
-- [ ] 任务名 — 阶段①/② — [状态]
+- [ ] 任务名 — ①全局设计 / ③版本设计 / ④执行案 — 可启动 / 等待前置
 
 ### 程序任务
-- [ ] 任务名 — 阶段③/⑤ — [状态]
+- [ ] 任务名 — ⑤程序设计 / ⑦程序实现 — 可启动 / 等待前置
 
 ### 美术任务
-- [ ] 任务名 — 阶段④ — [状态]
+- [ ] 任务名 — ⑥美术产出 — 可启动 / 等待前置
 
 ## ⚠️ 风险提醒
 
@@ -262,36 +241,44 @@
 （等待开发者反馈或指示）
 ```
 
+**互动讨论**：
+1. 等待开发者反馈：同意 / 调整 / 追问
+2. 开发者可要求深入诊断某个方面（见「深入诊断」章节）
+3. 根据反馈修正优先级
+4. 讨论结束后，更新 `current.md` / `roadmap.md` / `review-log.md`
+5. 展示变更内容，等待开发者最终确认
+
 ---
 
 ## 深入诊断
 
-当开发者要求深入诊断时（"帮我诊断一下"、"产出跟得上吗"、"各角色进度均衡吗"），PM 应执行以下分析：
+当开发者要求深入诊断时（"帮我诊断一下"、"产出跟得上吗"、"各角色进度均衡吗"），PM 执行以下分析：
 
-### 逐角色对比
+### 逐角色三方对比
 
 对每个角色做三方对比：
 
 | 维度 | 说明 |
 |------|------|
-| **应有产出** | 当前流水线阶段该角色应该交付的内容 |
+| **应有产出** | 当前流水线阶段该角色应该交付的内容（对照 `development-workflow.md`） |
 | **实际产出** | 扫描对应目录后发现的实际文件 |
 | **标记进度** | `current.md` 中标记的完成/进行中/待开始状态 |
 
-### 文档质量检查
+### 文档质量深审
 
-不仅检查文档是否存在，还要检查文档质量：
+不仅检查文档是否存在，还要**逐份阅读内容**检查质量：
 
-- **版本目标案**：是否完整回答了版本定位、内容范围、验收标准？
-- **系统设定案**：是否有行为定义模糊的地带？是否误入了技术细节？
-- **程序设计方案**：是否完整回应了系统设定案中的每条行为规则？美术资源需求是否列得具体？
+- **执行案**：行为规则是否完整？是否有模糊地带？是否技术越界？边界情况是否覆盖？
+- **程序设计方案**：是否逐条回应了执行案的每个行为规则？美术资源需求是否具体到尺寸和数量？
+- **版本设计文档**：版本定位、内容范围、验收标准是否完整回答？
 
 ### 不一致检测
 
-- current.md 标记为进行中，但对应目录无实际文件 → 标记为「可能滞后」
-- current.md 标记为待开始，但对应目录已有实际文件 → 标记为「可能需要更新进度」
-- 某角色应有产出但目录为空 → 标记为「产出缺口」
-- 流水线阶段跳跃（下游已开始但上游未完成）→ 标记为「流程违规风险」
+- `current.md` 标记为进行中，但对应目录无实际文件 → 「可能滞后」
+- `current.md` 标记为待开始，但对应目录已有实际文件 → 「可能需要更新进度」
+- 某角色应有产出但目录为空 → 「产出缺口」
+- 流水线阶段跳跃（下游已开始但上游未完成）→ 「流程违规风险」
+- 汇报的进度与实际文件不一致 → 「进度虚报」
 
 ### 诊断输出格式
 
@@ -299,7 +286,7 @@
 ## 🔍 深入诊断
 
 ### 流水线状态
-- 当前阻塞点: [流水线的哪个阶段没通过]
+- 当前阻塞点: [流水线的哪个阶段/质量门没通过]
 - 阻塞原因: [具体说明]
 
 ### 策划
@@ -323,26 +310,11 @@
 
 ## 游戏开发阶段知识
 
-PM 必须理解游戏开发各阶段的特征和应有的交付物，用于诊断产出是否匹配：
+PM 必须理解游戏开发各阶段的特征和应有的交付物，用于诊断产出是否匹配。详见 `docs/development-workflow.md` 中的「游戏开发阶段知识」章节。
 
-| 阶段 | 特征 | 应有交付物 | 工作重点 |
-|------|------|-----------|----------|
-| **预制作** | 想清楚再动手 | 游戏愿景文档、范围定义、各系统设计文档、美术风格指南、brainstorm 记录 | 确保设计充分，避免后期返工 |
-| **核心系统制作** | 先跑通最小可玩循环 | 角色控制器、核心交互系统、基础 UI 框架、白盒场景、占位模型 | 系统能跑起来比做得漂亮重要 |
-| **内容填充** | 依赖核心系统稳定 | 场景细节、交互数据配置、正式美术资产、音效 | 核心系统锁定后再大规模填充 |
-| **集成联调** | 多系统协同工作 | 系统集成测试记录、Bug 列表、性能报告 | 暴露和解决集成问题 |
-| **打磨发布** | 不加新功能 | Bug 修复记录、平衡性调整、优化报告、构建版本 | 稳定性和品质 |
-
-**诊断判断**：
-- 处于「预制作」但缺少关键设计文档 → 标记风险，建议补齐
-- 处于「核心系统制作」但设计文档未完成 → 建议先收尾设计再写代码
-- 处于「内容填充」但核心系统不稳定 → 建议先修复核心系统
-- 某角色产出明显落后于其他角色 → 标记为瓶颈
-
-### 单人独立开发的特殊考量
-
-- 无法并行——同一时间只能做一件事，选择更关键
-- 精力有限——避免一次性拆分太多并行任务
-- 心流重要——建议按「完整做完一个小系统」而非「同时推进多个系统」的方式工作
-- 早期验证——越早能跑起来看到东西，越不容易失去动力
-- Agent 之间通过文档交接——PM 是信息枢纽
+**单人独立开发的特殊考量**：
+- **无法并行**——同一时间只能做一件事，选择更关键
+- **精力有限**——避免一次性拆分太多并行任务
+- **心流重要**——建议按「完整做完一个小系统」而非「同时推进多个系统」的方式工作
+- **早期验证**——越早能跑起来看到东西，越不容易失去动力
+- **文档交接**——Agent 之间通过文档交接，PM 是信息枢纽