# 📋 项目管理工作流详解
> 本文档详细说明项目管理的完整工作流程，包括多智能体协作机制和上下文管理策略。
---
## 一、项目生命周期
```mermaid
graph LR
subgraph 启动[P1 启动]
A1[需求收集] --> A2[需求分析]
A2 --> A3[可行性评估]
end
subgraph 规划[P2 规划]
B1[架构设计] --> B2[任务拆解]
B2 --> B3[排期制定]
end
subgraph 执行[P3 执行]
C1[开发实现] --> C2[进度追踪]
C2 --> C3[风险控制]
C3 --> C1
end
subgraph 交付[P4 交付]
D1[测试验收] --> D2[部署上线]
D2 --> D3[用户手册]
end
subgraph 复盘[P5 复盘]
E1[数据收集] --> E2[问题分析]
E2 --> E3[经验沉淀]
end
启动 --> 规划 --> 执行 --> 交付 --> 复盘
```
---
## 二、多智能体协作架构
基于 DocAgent 模式，本系统采用多智能体协作：
```mermaid
graph TB
subgraph Orchestrator[🎯 编排器 - 项目管理专家]
O[任务分发与协调]
end
subgraph Agents[🤖 智能体矩阵]
A1[📖 Reader
需求理解]
A2[🔍 Searcher
上下文检索]
A3[✍️ Writer
内容生成]
A4[✅ Verifier
质量校验]
A5[📊 Tracker
进度追踪]
end
subgraph Memory[💾 记忆层]
M1[project-state.md]
M2[execution-table.md]
M3[conversation-log.md]
M4[prompts-library.md]
end
O --> A1
A1 --> A2
A2 --> A3
A3 --> A4
A4 --> A5
A5 --> Memory
A4 -->|不通过| A3
Memory -->|上下文| A2
```
### 智能体职责
| 智能体 | 角色 | 职责 | 触发场景 |
|:---:|:---|:---|:---|
| 📖 Reader | 需求分析师 | 理解用户输入，提取关键信息 | 新需求/变更请求 |
| 🔍 Searcher | 上下文检索 | 检索历史对话和项目状态 | 所有交互 |
| ✍️ Writer | 内容生成 | 生成文档、代码、报告 | 展开目录/生成内容 |
| ✅ Verifier | 质量校验 | 校验一致性、完整性 | 重要变更后 |
| 📊 Tracker | 进度追踪 | 更新状态、识别风险 | 进度变更 |
---
## 三、上下文管理策略
### 3.1 上下文窗口优化
由于 LLM 上下文窗口有限，采用以下策略：
```yaml
分层存储:
即时层: 当前对话内容（保留完整）
工作层: project-state.md 摘要（每次加载）
归档层: conversation-log.md 历史（按需检索）
摘要策略:
每次对话结束: 提取关键信息写入 conversation-log.md
每个里程碑: 更新 project-state.md 总览
每周: 归档过期任务，压缩执行表
检索策略:
优先: project-state.md（当前状态）
次之: 最近 5 次对话记录
按需: 历史对话全文检索
```
### 3.2 会话切换无损转移
当需要开始新对话时：
```markdown
## 会话转移清单
1. 当前项目状态摘要
2. 进行中的任务列表
3. 未解决的阻碍/风险
4. 下一步待办事项
5. 关键决策和背景
---
复制以上内容到新对话，即可无缝继续工作。
```
---
## 四、任务拆解标准
### 4.1 拆解原则
```yaml
粒度标准:
- 每个任务 ≤ 2 天工时
- 每个任务有明确交付物
- 每个任务可独立验收
依赖管理:
- 明确前置依赖
- 避免循环依赖
- 并行任务分组
优先级定义:
P0: 阻塞性任务，必须最先完成
P1: 核心功能，影响上线
P2: 重要功能，影响体验
P3: 锦上添花，时间允许再做
```
### 4.2 用户故事模板
```markdown
**US-[编号]: [功能名称]**
- **As a** [用户角色]
- **I want** [具体功能]
- **So that** [业务价值]
**验收标准 (AC)**:
- [ ] AC1: [具体可验证的条件]
- [ ] AC2: [具体可验证的条件]
**技术备注**:
- 依赖: [前置任务]
- 估时: [工时估算]
- 负责: [开发人员]
```
---
## 五、进度追踪机制
### 5.1 每日站会模式
```markdown
## 站会纪要 - [日期]
### 🟢 昨日完成
- [任务1]: 完成情况
- [任务2]: 完成情况
### 🔵 今日计划
- [任务3]: 计划内容
- [任务4]: 计划内容
### 🔴 阻碍事项
- [阻碍1]: 问题描述 + 需要的支持
### 📊 进度概览
- 总任务: X 个
- 已完成: Y 个 (Z%)
- 进行中: A 个
- 待开始: B 个
```
### 5.2 状态流转
```mermaid
stateDiagram-v2
[*] --> Pending: 任务创建
Pending --> InProgress: 开始执行
InProgress --> Done: 完成
InProgress --> Blocked: 遇到阻碍
Blocked --> InProgress: 阻碍解决
Blocked --> Cancelled: 需求取消
Done --> [*]
Cancelled --> [*]
```
### 5.3 风险识别矩阵
| 风险等级 | 可能性 | 影响 | 处理方式 |
|:---:|:---:|:---:|:---|
| 🔴 高危 | 高 | 高 | 立即处理，上报并制定应急方案 |
| 🟡 中等 | 中 | 高/中高 | 密切关注，准备预案 |
| 🟢 低风险 | 低/中 | 低/中 | 记录观察，定期检查 |
---
## 六、文档联动规则
### 6.1 变更传播链
```yaml
需求变更:
触发更新:
- 架构文档 (如影响技术方案)
- 接口文档 (如影响 API 设计)
- 执行表 (新增/调整任务)
- 排期 (重新评估时间)
接口变更:
触发更新:
- 前端代码 (调用方式)
- 后端代码 (实现方式)
- API 文档 (接口定义)
- 测试用例 (验证逻辑)
数据库变更:
触发更新:
- ER 图
- 后端 Model
- 接口文档 (数据结构)
```
### 6.2 一致性检查
每次重大变更后，执行一致性检查：
```markdown
## 一致性检查清单
- [ ] 需求文档与执行表任务一致
- [ ] 架构设计与技术选型一致
- [ ] 接口定义与前后端实现一致
- [ ] 数据库设计与 Model 定义一致
- [ ] 部署配置与环境变量一致
```
---
## 七、复盘流程
### 7.1 数据收集
```yaml
收集指标:
进度:
- 计划工时 vs 实际工时
- 计划周期 vs 实际周期
- 任务完成率
质量:
- Bug 数量及分布
- 返工次数
- 代码审查通过率
过程:
- 需求变更次数
- 阻碍事项数量
- 风险应对效果
```
### 7.2 复盘模板
详见 [templates.md](templates.md) 中的复盘报告模板。
---
## 八、最佳实践
### 8.1 高效使用技巧
```yaml
每日习惯:
- 早: 快速查看进度概览
- 中: 遇到问题及时记录
- 晚: 更新当日进度
每周习惯:
- 周一: 确认本周目标
- 周五: 检查进度偏差
每个里程碑:
- 更新项目状态总览
- 压缩归档已完成任务
- 调整后续计划
```
### 8.2 常见问题处理
| 问题 | 解决方案 |
|:---|:---|
| 任务拆分太粗 | 按 2 天原则继续细分 |
| 进度不透明 | 强制每日更新执行表 |
| 风险后知后觉 | 每个任务标记潜在风险 |
| 复盘流于形式 | 必须有具体改进行动 |
| 上下文丢失 | 及时记录到 conversation-log.md |
---
> **记住**: 项目管理的核心是让事情可见、可追踪、可预测。AI 是你的助手，但决策权在你手中！