项目里程碑规划器
根据项目需求、技术方案或功能模块清单，生成结构化的项目里程碑规划，包含分阶段交付计划、周维度任务拆解、并行开发安排和可演示的里程碑节点。适用于软件开发、系统集成、AI平台建设等各类技术项目。
核心价值
把"要做什么"转化为"怎么做、谁来做、什么时候交付"的可执行计划：
- 面向客户：展示清晰的阶段交付节奏和可演示节点
- 面向团队：明确每周任务分配和并行协作安排
- 面向管理层：提供人天汇总和关键路径分析
输入
用户提供以下任一信息：
- 功能模块清单：项目包含哪些模块和功能
- 技术方案/PRD：已有技术文档，基于文档内容规划
- 人天评估表：已有各模块人天估算，基于估算排期
- 口头描述：自然语言描述项目范围和时间要求
输出
- 里程碑规划文档（
.md）：完整的分阶段计划 - 甘特图（可选）：
.drawio格式，可视化时间轴
工作流程
Step 1：信息收集与确认
从用户输入中提取以下关键信息：
| 维度 | 确认内容 | 默认值 |
|---|---|---|
| 项目名称 | 用于文档命名 | - |
| 功能模块 | 核心模块清单 | - |
| 团队规模 | 各角色人数 | 设计1+前端1+后端2+测试1 |
| 项目周期 | 总工期要求 | 根据人天估算推算 |
| 并行能力 | 哪些模块可并行开发 | 自动判断 |
| 交付要求 | 是否需要分阶段演示 | 是 |
| 关键约束 | 硬性截止日期、外部依赖等 | - |
Step 2：模块依赖分析
分析各功能模块之间的依赖关系，确定执行顺序：
依赖类型：
├── 强依赖：B模块必须等A模块完成后才能开始
├── 弱依赖：B模块可以在A模块基本完成后并行启动
└── 无依赖：可完全并行开发
输出依赖矩阵：
模块A（基础架构）← 所有业务模块的依赖前置
模块B（用户管理）← 依赖A，是其他业务模块的弱依赖
模块C（核心业务）← 依赖A+B，可与其他业务模块并行
模块D（数据报表）← 依赖C，需业务数据就绪
模块E（系统集成）← 依赖A+C，可与D并行
Step 3：阶段划分
将项目划分为3-5个阶段，每个阶段遵循以下原则：
阶段划分原则：
1. 每个阶段有明确的可演示交付物——客户能在阶段末看到东西
2. 前一阶段的产出是后一阶段的输入——不跳跃式开发
3. 核心功能优先，辅助功能后置——先跑通主链路再补功能
4. 高风险模块尽量前置——早暴露风险早解决
典型三阶段模型：
阶段1：基础搭建（第1-4周）
→ 公共框架 + 核心基础能力 → 可内部演示
阶段2：核心业务（第5-10周）
→ 核心业务模块并行开发 → 可向客户演示核心流程
阶段3：完善上线（第11-14周）
→ 辅助功能 + 集成测试 + 部署上线 → 全系统交付
Step 4：周维度任务拆解
每个阶段内按周拆解任务，格式：
### 第N阶段：{阶段名称}（第X-Y周）
**里程碑：{可演示的交付物描述}**
| 周次 | 节点 | 内容 |
|------|------|------|
| W1-W2 | 需求确认 | 需求评审、技术方案定稿、接口设计 |
| W2-W3 | 基础开发 | 框架搭建、公共组件、数据库初始化 |
| W3-W4 | 模块A开发 | 模块A核心功能开发 |
| W3-W4 | 模块B开发 | 模块B核心功能开发（并行） |
| W4 | 联调测试 | 模块A+B联调 + 阶段验收 |
> 本阶段交付：{具体交付物}
拆解规则：
- 每个任务标注负责角色（设计/前端/后端/测试）
- 标注并行任务（同一周内可同时推进的模块）
- 每周总工作量不超过团队容量的90%，预留buffer
- 联调测试时间不少于阶段总时间的20%
Step 5：并行开发安排
识别可并行的模块，在计划中明确标注：
并行组1（第5-7周同时进行）：
├── 模块A开发（后端1 + 前端1）
├── 模块B开发（后端2 + 前端1后半程）
└── 模块C开发（后端1后半程）
并行组2（第8-10周同时进行）：
├── 模块D开发
├── 模块E开发
└── 模块A/B联调测试
Step 6：资源排期
输出人天汇总和角色工作量分布：
## 资源排期汇总
### 各角色人天分布
| 角色 | 人数 | 阶段1 | 阶段2 | 阶段3 | 合计 |
|------|------|-------|-------|-------|------|
| 设计 | 1 | 8 | 10 | 5 | 23 |
| 前端 | 1 | 6 | 12 | 5 | 23 |
| 后端 | 2 | 16 | 32 | 14 | 62 |
| 测试 | 1 | 4 | 10 | 12 | 26 |
| 项目管理 | - | 4 | 6 | 4 | 14 |
| **合计** | | **38** | **70** | **40** | **148** |
### 关键路径
模块A(基础) → 模块C(核心业务) → 集成测试 → 部署上线
这是项目的关键路径，任何延误都会影响最终交付日期。
Step 7：里程碑节点定义
每个阶段末尾定义清晰的里程碑节点：
## 里程碑节点
| 里程碑 | 时间 | 交付物 | 验收标准 |
|--------|------|--------|---------|
| M1-基础框架就绪 | W4 | 公共框架+基础模块 | 可登录、可导航、基础CRUD可用 |
| M2-核心功能演示 | W10 | 核心业务模块 | 主流程端到端跑通，可向客户演示 |
| M3-系统交付上线 | W14 | 全系统 | 全功能可用、测试通过、生产部署完成 |
Step 8：总体节奏一览
用文字图表展示整体节奏：
月1 月2 月3 月4
|--阶段1--|----阶段2----|--阶段3--|
▲方案定稿 ▲核心模块A ▲辅助模块
▲环境搭建 ▲核心模块B ▲全量回归
▲公共框架 ▲核心模块C ▲部署上线
▲基础模块 ▲联调测试 ▲运维交接
M1↑ M2↑ M3↑
边界情况
- 工期压缩：当用户要求缩短工期时，优先增加并行度而非减少测试时间；测试时间低于总工期15%时提出风险警告
- 人手不足：单人全栈场景下，模块串行执行，总工期=各模块人天之和
- 外部依赖：如等客户提供API文档、等第三方系统就绪等，在计划中标注为风险点
- 需求变更：预留总工期的10-15%作为需求变更buffer
- 节假日：排期时跳过法定节假日和周末，按实际工作日计算
排期估算参考
各类功能的标准人天参考（供无详细评估时使用）：
| 功能类型 | 设计 | 前端 | 后端 | 测试 |
|---|---|---|---|---|
| 标准CRUD | 0.5-1 | 1-2 | 1-3 | 0.5-1 |
| 复杂业务逻辑 | 1-2 | 1-3 | 2-5 | 1-2 |
| AI/算法能力 | 1-2 | 0.5-1 | 3-8 | 1-2 |
| 数据对接/API | 0.5-1 | 0-1 | 1-4 | 0.5-1 |
| 基础设施/架构 | 1-3 | 0-0.5 | 2-5 | 0.5-1 |
| 项目管理/公共 | - | - | - | 总人天5-10% |
使用示例
示例1：从功能清单规划
用户输入："项目有5个模块：邮件Agent、返利计算、AI客服、订单核对、政策转换，团队5人，3-4个月工期"
执行：
1. 分析5个模块的依赖关系
2. 划分为3个阶段：基础搭建→核心模块并行→政策转换+上线
3. 按周拆解任务，标注并行安排
4. 输出完整里程碑文档
示例2：从人天评估表规划
用户输入："根据这个人天评估Excel帮我排个计划" + 上传Excel
执行：
1. 读取Excel，提取各模块人天估算
2. 根据团队规模计算各模块所需周数
3. 按依赖关系排布，识别并行机会
4. 输出里程碑文档 + 甘特图
示例3：追加阶段规划
用户输入："在现有计划基础上，增加一个阶段4做运维交接和二期需求规划"
执行：
1. 读取已有里程碑计划
2. 在阶段3后追加阶段4
3. 重新输出完整计划
