1 roadmap planner

① 远期路线图规划 (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)"

里程碑设计原则

1. 关键节点: 标志性的转折点或交付点
2. 时间均匀分布: 避免集中在季末
3. 可验收: 有明确的 Done 标准
4. 依赖可见: 前置条件已标注

标准格式:

### 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 个）:

1. 技术风险（如：核心技术难点、性能瓶颈）
2. 资源风险（如：关键人员离职、预算削减）
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 必须与上级/公司目标对齐，避免各自为战。