| name | milestone-gate |
| description | 设计里程碑和交付门禁时使用。适用于阶段评审、上线前检查、重要节点验收。优先使用 Stage-Gate 方法 + 验收标准 + 强制门禁清单。 |
里程碑和交付门禁（Milestone Gates）
参考来源：Stage-Gate Process、PMBOK Phase Gates
适用场景
- 项目阶段划分
- 阶段评审检查点
- 上线前最后检查
- 重要节点的"通过/不通过"决策
核心原则
1. 里程碑 = 阶段性可验证的交付节点
不是"做完一半"，而是"完成了某个完整产物"
2. 门禁 = 强制检查
不通过门禁就不进入下一阶段
即使时间紧张也不能跳过
3. 每个里程碑必须可独立验证
不能"等下游说没问题才算通过"
4. 门禁是项目的"刹车系统"
宁可暂停也不能让问题流到下游
好的里程碑 vs 坏的里程碑
好的里程碑：
✓ 有明确的验收标准
✓ 有具体的时间点
✓ 有负责工作流
✓ 可以独立验证（不依赖后续工作）
坏的里程碑：
✗ "开发完成 50%"（不可验证）
✗ "基本可用"（标准模糊）
✗ 没有时间点的里程碑
✗ "等所有人都觉得 OK"
标准门禁清单
需求门禁
□ PRD 已评审通过
□ 验收标准已定义（可测试）
□ 技术可行性已确认
□ 非目标范围已明确
□ 优先级已排序
□ 关键风险已识别
设计门禁
□ UI/UX 设计已完成（含状态说明）
□ API 契约已定义（OpenAPI）
□ 数据库设计已完成（DDL）
□ 关键决策已记录
□ 设计评审通过
□ 前后端能据此独立开发
开发门禁
□ 核心功能已完成
□ 单元测试通过
□ 接口联调通过
□ 代码评审完成
□ 没有阻塞性 Bug
□ 文档同步更新
测试门禁
□ 核心路径测试通过
□ 关键 Bug 已修复
□ 回归测试通过
□ 边界条件测试通过
□ 性能符合要求
□ 测试报告已输出
安全门禁
□ 代码安全评审通过
□ 依赖漏洞已修复
□ 敏感数据保护已检查
□ 鉴权权限已验证
□ OWASP Top 10 已检查
□ 安全报告已输出
上线门禁
□ 安全检查通过
□ 部署文档就绪
□ 回滚方案就绪（5 分钟内可回滚）
□ 监控告警配置完成
□ 健康检查端点正常
□ 相关方已通知
□ 上线时间窗口确认
门禁通过决策
通过：所有项打勾
→ 进入下一阶段
部分通过：核心项打勾，非核心项有 1~2 项不通过
→ 评估风险后决定：
- 风险可控 → 通过 + 标注待办
- 风险高 → 不通过
不通过：有核心项不打勾
→ 退回上游修复
→ 重新进入门禁
里程碑设计模板
## 项目里程碑计划
| 里程碑 | 时间点 | 验收标准 | 门禁类型 | 负责工作流 |
|--------|--------|---------|---------|----------|
| M1: 需求确认 | +15min | PRD + 验收标准已定义 | 需求门禁 | product-manager |
| M2: 接口就绪 | +50min | API 契约 + 数据库设计完成 | 设计门禁 | api-designer + database-engineer |
| M3: 开发完成 | +2h | 前后端联调通过 | 开发门禁 | backend + frontend |
| M4: 测试通过 | +2.5h | QA + 安全检查通过 | 测试 + 安全门禁 | qa + security |
| M5: 上线 | +3h | 服务上线，监控正常 | 上线门禁 | devops + sre |
### M1: 需求确认
**时间点**：项目开始 +15min
**负责工作流**：product-manager
**门禁清单**：
□ PRD 已输出（docs/prd.md）
□ 14 节结构完整
□ 至少 5 个用户故事 + 验收标准
□ 非目标范围已明确
□ 关键风险已列出（≥ 5 个）
□ 未决问题清单 ≤ 3 条
**通过后产出**：
- PRD 文档
- 风险清单
- 转交项目经理拆任务
**不通过处理**：
- 退回 product-manager 工作流
- 标注具体哪些项不通过
- 限定修复时间（不超过原计划 50%）
工作流程
1. 项目启动时：
- 根据 WBS 和关键路径识别里程碑
- 一般 5~7 个里程碑（XL 项目可以更多）
↓
2. 每个里程碑定义：
- 时间点（基于关键路径）
- 验收标准（可测试）
- 门禁清单（标准 + 项目特定）
- 负责工作流
↓
3. 项目执行中：
- 每个里程碑前一步开始准备门禁检查
- 到达里程碑时执行门禁检查
- 通过 → 进入下一阶段
- 不通过 → 退回 + 修复
↓
4. 里程碑数据沉淀：
- 通过率
- 平均门禁检查耗时
- 不通过的常见原因
- 沉淀到 field-journal
质量自检
□ 每个里程碑是否有时间点（不能"开发完成后"）
□ 每个验收标准是否可测试
□ 门禁清单是否覆盖了关键风险
□ 是否标注了负责工作流
□ 不通过处理路径是否明确
□ 是否有强制门禁（不能跳过）
常见坑
- 里程碑太多——20 个里程碑 = 没有里程碑
- 里程碑太少——只有"上线"一个，到了才发现一堆问题
- 验收标准模糊——"开发完成" → 应该是"接口可调用 + 测试通过"
- 门禁可选——"时间紧就跳过" → 失去了门禁的意义
- 门禁清单不更新——上次的清单不适用本次项目
- 不记录不通过原因——下次还踩同样的坑
- "通过率 100%"——要么门禁太宽松，要么团队作弊
配套模板
templates/milestone-plan-template.md — 里程碑计划模板templates/delivery-gate-checklist.md — 门禁检查清单 + 门禁评审记录模板
与其他 skill 的协作
上游：
critical-path → 关键路径节点是天然的里程碑
risk-management → 高风险点需要门禁拦截
下游：
progress-tracking → 追踪门禁状态
retrospective → 复盘门禁有效性
