starmen1265/ChildHood
1
0
Fork 0
Code Issues 11 Pull Requests Actions Packages Projects 2 Releases Wiki Activity

docs(plan): 重写plan命令，引用工作流文档，细化PM操作流程与产出规范

Browse Source
This commit is contained in:
DESKTOP-2K5TJI4\admin
2026-06-02 16:58:53 +08:00
parent 3de55e147b
commit 4898bb8557
1 changed files with 197 additions and 225 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/commands/plan.md
+197 -225
View File
@@ -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 是信息枢纽