morning-start ① 远期路线图规划 (ROADMAP Planner)
任务目标
帮助用户制定项目的远期规划（通常为季度或年度），产出标准化的 ROADMAP.md 文件。该文件应清晰呈现：
- 战略愿景: 1-3 年的北极星方向
- 目标体系: 基于 OKR 的 O（目标）+ KR（关键结果）
- 里程碑时间轴: 关键节点和交付物
- 风险与依赖: 潜在障碍和应对策略
触发条件
当用户说以下任一话术时激活：
- "帮我写 roadmap" / "制定路线图"
- "设定年度/季度目标"
- "规划远期计划" / "长期规划"
- "创建 OKR" / "对齐目标"
- "定义里程碑"
前置信息收集
在开始编写 ROADMAP 前，必须先了解：
# 收集项目上下文
cat README.md | head -50 # 项目定位
ls -1 package.json Cargo.toml pyproject.toml 2>/dev/null # 技术栈
git log --oneline -10 # 近期活动
# 如有现有的 TODO 或规划文件，也需查看
必须确认的 5 个关键问题
| # | 问题 | 获取方式 | 权重 |
|---|---|---|---|
| 1 | 项目当前阶段？ (MVP/成长期/成熟期) | 与用户沟通或读 README | 20% |
| 2 | 时间跨度？ (Q4/2026全年/未来12个月) | 用户明确指定 | 25% |
| 3 | 核心目标？ (1-3个主要方向) | 用户描述 | 30% |
| 4 | 团队规模？ (个人/小团队/企业) | 影响方法论选择 | 15% |
| 5 | 约束条件？ (资源/技术/市场) | 可能影响可行性 | 10% |
操作步骤
Step 1: 定义战略愿景（北极星）
什么是愿景？
愿景是长期的、定性的、鼓舞人心的方向性描述，回答："我们最终想成为什么？"
撰写规范
✅ 好的愿景示例：
成为开发者首选的 {领域} 解决方案
让 {用户群体} 能够 {核心价值}
打造 {行业} 最 {形容词} 的 {产品类型}
❌ 差的愿景示例：
完成所有功能开发 ← 太操作化，不是愿景
提高代码质量 ← 太模糊，无法衡量
赚更多的钱 ← 太功利，无激励性
检验清单:
- 时间跨度：1-3 年（非短期任务）
- 定性描述：不包含具体数字
- 有激励性：能激发团队热情
- 方向清晰：知道往哪个方向走
- 简洁有力：1-2 句话能说完
📖 详细指南: smart-principle.md
Step 2: 设定 OKR 目标体系
OKR 标准结构
愿景 (Vision)
↓
年度目标 O1 ──→ KR1-1, KR1-2, KR1-3
O2 ──→ KR2-1, KR2-2, KR2-3, KR2-4
O3 ──→ KR3-1, KR3-2
↓
季度目标 Q1-O1 ──→ Q1-KR1-1, ...
Q2-O1 ──→ Q2-KR1-1, ...
如何撰写优秀的 Objective (O)
定义: 定性的、有野心的、激励人心的目标描述
公式: 动词 + 名词 + 成果描述
| 维度 | 要求 | 示例 |
|---|---|---|
| 定性 | 不含数字 | ✅ "建立可靠的市场地位" ❌ "获得100万用户" |
| 有野心 | 跳一跳够得着 | ✅ "成为Top3" ❌ "保持现状" |
| 时限内可达成 | 在规划周期内合理 | 非遥不可及的空想 |
| 可独立存在 | 不依赖其他O | 自身完整 |
常见 Objective 模板:
- 打造{形容词}{核心能力}
- 建立{领域}的{地位}
- 实现{功能/能力}的{水平}
- 完成{阶段}的{转型}
如何撰写优秀的 Key Result (KR)
定义: 可量化的、可衡量的结果指标，用于验证 Objective 是否达成
公式: 指标 + 当前值 → 目标值 + 时间
KR 的 4 种类型:
| 类型 | 格式 | 示例 |
|---|---|---|
| 📈 增长型 | 从 X 增长到 Y | 日活从 1K → 5K (+400%) |
| 📉 减少型 | 从 X 降低到 Y | P95延迟从 500ms → 200ms (-60%) |
| ✅ 达成型 | 完成率为 0% → 100% | 核心模块测试覆盖率 40% → 85% |
| ⭐ 评分型 | 评分从 X 提升到 Y | NPS从 30 → 60 (+30分) |
KR 质量自检（SMART）:
| 维度 | 问题 | 通过标准 |
|---|---|---|
| S (Specific) | 衡量什么？ | 指标明确（如"日活用户数"而非"用户参与度"） |
| M (Measurable) | 怎么算达成？ | 有明确的目标值和当前基线值 |
| A (Achievable) | 能做到吗？ | 有一定挑战性但非不可能（建议增长 30-100%） |
| R (Relevant) | 为什么重要？ | 直接支撑 Objective 的达成 |
| T (Time-bound) | 何时检查？ | 有明确的截止日期或检查节奏 |
数量控制:
- 每个 O 对应 2-5 个 KR（推荐 3-4 个）
- 整个周期（季度/年）的 O 数量：1-3 个（推荐 2-3 个）
- 总 KR 数量：4-8 个（过多则焦点分散）
Step 3: 设计里程碑时间轴
里程碑 vs OKR 的区别
| 维度 | OKR (Objective+KR) | Milestone (里程碑) |
|---|---|---|
| 性质 | 结果导向（Outcome） | 交付导向（Output） |
| 衡量 | 定量指标 | 二元状态（完成/未完成） |
| 粒度 | 季度/月度 | 具体日期点 |
| 示例 | "DAU 提升 50%" | "v2.0 发布 (3/15)" |
里程碑设计原则
- 关键节点: 标志性的转折点或交付点
- 时间均匀分布: 避免集中在季末
- 可验收: 有明确的 Done 标准
- 依赖可见: 前置条件已标注
标准格式:
### Q2 2026 里程碑
| 日期 | 里程碑 | 类型 | 负责人 | 依赖 | Done标准 |
|------|--------|------|--------|------|----------|
| 4/15 | M1: Alpha 版本发布 | 🚀 交付 | Team A | 无 | 内部可用，核心流程跑通 |
| 5/01 | M2: 性能优化完成 | ⚡ 改进 | Team B | M1 | P95 < 200ms |
| 5/20 | M3: Beta 公测启动 | 👥 运营 | Team C | M1,M2 | 100+ 外部用户试用 |
| 6/10 | M4: 正式版 v1.0 发布 | 🎉 发布 | All | M1-M3 | 生产环境稳定运行 7天 |
里程碑命名建议:
- 使用动宾结构: "发布 v2.0"、"完成重构"、"上线新功能"
- 加上版本号或代号: "M1: Project Phoenix 启动"
- 标注类型emoji: 🚀交付 / ⚡改进 / 👥运营 / 🎉发布 / 🔬研究
Step 4: 评估风险与依赖
风险评估矩阵
| 影响 \ 概率 | 低 (L) | 中 (M) | 高 (H) |
|---|---|---|---|
| 高 (H) | 🟡 中等 | 🟠 较高 | 🔴 必须应对 |
| 中 (M) | 🟢 低 | 🟡 中等 | 🟠 较高 |
| 低 (L) | 🟢 可接受 | 🟢 低 | 🟡 中等 |
每个风险记录:
### ⚠️ 风险 #{N}: {简短标题}
- **描述**: {具体说明风险是什么}
- **影响**: 🔴高/🟠中/🟢低 （如果发生会怎样？）
- **概率**: 🔴高(>50%)/🟠中(20-50%)/🟢低(<20%) （发生的可能性）
- **触发条件**: {什么情况下可能发生？}
- **应对策略**:
- 缓解(Mitigate): {如何降低概率或影响}
- 应急(Contingency): {如果发生了怎么办}
- **负责人**: @{who}
- **监控频率**: {每周/每两周/每月}
必填风险项（至少 3 个）:
- 技术风险（如：核心技术难点、性能瓶颈）
- 资源风险（如：关键人员离职、预算削减）
- 市场风险（如：竞品发布、需求变更）
依赖关系管理
## 🔗 关键依赖
| 依赖项 | 类型 | 来源 | 状态 | 备选方案 |
|--------|------|------|------|---------|
| {依赖名称} | 🔗外部/🔗内部/🔗上游 | {来自哪里} | ✅就绪/⏳等待中/❌阻塞 | {如果没有怎么办} |
Step 5: 编写完整 ROADMAP.md
标准模板（推荐使用）
# {项目名} 路线图 ({时间范围})
> 最后更新: {date} | 负责人: {owner} | 下次评审: {next_review}
---
## 🎯 战略愿景
{1-2句话的北极星方向}
### 核心价值观/原则（可选）
1. {value_1}
2. {value_2}
3. {value_3}
---
## 📅 {年份} 年度目标
### O1: {Objective 1 描述}
| KR | 指标描述 | 当前值 | 目标值 | 截止日期 | 负责人 | 状态 |
|----|---------|--------|--------|----------|--------|------|
| KR1 | {metric} | {current} | {target} | {deadline} | @who | 🔴🟡🟢⚪ |
| KR2 | {metric} | {current} | {target} | {deadline} | @who | 🔴🟡🟢⚪ |
| KR3 | {metric} | {current} | {target} | {deadline} | @who | 🔴🟡🟢⚪ |
#### Q1 季度拆解
- **Q1-O1**: {季度目标}
- Q1-KR1: {季度KR}
- Q1-KR2: {季度KR}
**Q1 里程碑**:
- [ ] **M1 ({date})**: {milestone}
- [ ] **M2 ({date})**: {milestone}
### O2: {Objective 2 描述}
...（同上结构）
### O3: {Objective 3 描述}
...（同上结构）
---
## 📍 里程碑总览
| 季度 | 日期 | 里程碑 | 关联O/KR | 状态 |
|------|------|--------|----------|------|
| Q1 | ... | ... | ... | ⬜/✅ |
| Q2 | ... | ... | ... | ⬜/✅ |
| Q3 | ... | ... | ... | ⬜/✅ |
| Q4 | ... | ... | ... | ⬜/✅ |
---
## ⚠️ 风险与依赖
### Top 风险
| # | 风险 | 影响 | 概率 | 应对策略 | 负责人 |
|---|------|------|------|---------|--------|
| 1 | ... | H/M/L | H/M/L | ... | @who |
| 2 | ... | H/M/L | H/M/L | ... | @who |
| 3 | ... | H/M/L | H/M/L | ... | @who |
### 关键依赖
| 依赖项 | 类型 | 来源 | 状态 | 截止 |
|--------|------|------|------|------|
| ... | 外部/内部 | ... | 就绪/等待 | ... |
---
## 📊 进度仪表盘（可选）
### OKR 完成率
| 目标 | KR完成数 | 总KR数 | 完成率 | 健康度 |
|------|---------|--------|--------|--------|
| O1 | X/Y | Z% | 🟢健康/🟡警告/🔴危险 |
| O2 | X/Y | Z% | ... |
| O3 | X/Y | Z% | ... |
| **总计** | X/Y | Z% | ... |
---
## 📚 相关文档
- 本周期的详细TODO: [TODO.md](./TODO.md)
- 上季度复盘: [review-q{n}.md](./reviews/)
- 技术架构文档: [architecture.md](./docs/architecture.md)
---
## 📝 变更日志
| 日期 | 变更内容 | 原因 | 作者 |
|------|---------|------|------|
| {date} | 初始版本 | 新建 | {author} |
Step 6: 质量验证
SMART 自检清单
对每个 OKR 执行以下检查：
## OKR 质量检查表
### Objective 检查
- [ ] 是否定性？（不含数字）
- [ ] 是否有激励性？（能让人兴奋）
- [ ] 是否在周期内可实现？（非空想）
- [ ] 是否独立？（不依赖其他O）
### Key Results 检查
- [ ] **S**pecific: 指标清晰无歧义？
- [ ] **M**easurable: 有数值目标和基线？
- [ ] **A**chievable: 挑战性适中（30-100%增长）？
- [ ] **R**elevant: 直接支撑O？
- [ ] **T**ime-bound: 有截止日期？
### 整体检查
- [ ] O的数量: 1-3个 ✅
- [ ] 每个O的KR数: 2-5个 ✅
- [ ] 总KR数: 4-8个 ✅
- [ ] 里程碑分布均匀 ✅
- [ ] 至少3个风险已识别 ✅
- [ ] 所有KR都有负责人 ✅
可行性快速评估
# 检查 ROADMAP 行数（应在合理范围内）
wc -l ROADMAP.md
# 推荐: 80-150行（根据复杂度）
# 检查关键元素
echo "=== 元素完整性 ==="
grep -c "^## " ROADMAP.md # 一级章节数 (应≥6)
grep -ciE "(O[1-3]:|KR[0-9])" ROADMAP.md # OKR数量
grep -c "|.*|.*|.*|" ROADMAP.md # 表格数量
grep -c "⚠️\|🔴\|🟠" ROADMAP.md # 风险标记数
快速路径（简化模式）
如果用户只需要轻量级 OKR（不需要完整的 Roadmap），可以使用简化模板：
# {项目} OKR ({周期})
## O1: {目标1}
- **KR1**: {指标} {current} → {target} (@who)
- **KR2**: {指标} {current} → {target} (@who)
- **KR3**: {指标} {current} → {target} (@who)
## O2: {目标2}
...
---
*最后更新: {date} | 下次评审: {review_date}*
适用场景:
- 个人项目
- 快速迭代的小团队
- 作为更大规划的子集
常见问题
Q: OKR 和 KPI 有什么区别？
A:
- OKR: 目标驱动，关注结果（Outcome），鼓励挑战性目标，允许部分达成（60-70%算成功）
- KPI: 指标驱动，关注绩效（Performance），通常要求100%达成，用于考核而非激励
Q: KR 设多少合适？太容易还是太难？
A: 推荐的完成率目标是 70%：
- 如果总是 100% → 目标太低，缺乏挑战性
- 如果总是 < 50% → 目标太高，容易挫败
- 最佳区间: 60-80%（既有挑战又可实现）
Q: 多久更新一次 ROADMAP？
A: 建议：
- KR 数据跟踪: 月度或双周
- 整体评审: 季度末（配合 OKR 复盘）
- 重大调整: 仅当出现不可预见的变化时（如市场剧变、战略调整）
Q: 个人项目需要这么复杂的规划吗？
A: 不需要。个人项目推荐使用简化模式：
- 1个 O + 3个 KR（季度）
- 或直接用 SMART TODO（见 2-todo-planner）
注意事项
⚠️ 规划 ≠ 计划: ROADMAP 是"做什么+为什么"，不是"怎么做+谁什么时候做"。后者是 TODO/Gantt 的范畴。
⚠️ 保持动态: ROADMAP 是活文档！建议每季度回顾一次，根据实际情况调整。
⚠️ 避免过度规划: 远期（>6个月）的内容应保持粗粒度，细节随时间推移逐步细化。
⚠️ 对齐意识: 团队项目的 OKR 必须与上级/公司目标对齐，避免各自为战。