TL;DR
能扛到第 2 周的 Roadmap，是按 容量的 70-80% 规划的，不是 100%——几乎所有靠谱的容量规划资料都收敛到这个上限，因为软件工作里永远藏着调试、协调和返工。让 AI 做结构（按月分列、依赖映射、容量算术、RICE 计算），把工程量估时交给真碰过代码的工程师锚定。给模型 10-15 个想法、真实的人 × 周容量、本季战略目标，以及你不做什么；让它回给你 3 列月度计划、一张 RICE 表、依赖图、不做清单和砍掉顺序。最后自查一遍：承诺出去的人 × 周是落在 80% 附近，而不是顶到 100%。
任务场景
新季度。你有 10-15 个 feature ideas、有限的团队容量、一个战略目标。你要一份野心够推动、现实能出货的 Roadmap，并显眼地列出”本季度不做哪些”，防止干系人中途偷渡范围。
最贵的错误就是按 100% 容量规划。容量规划的实践早已收敛出一个上限：多数团队在大约 70-80% 利用率 时表现最好，因为一旦越过 ~80%，队列就开始崩，一个意外足以炸掉整个季度。这 20% 的余量不是浪费——它是当现实插进来时，让你还能兑现承诺的缓冲垫。
哪些适合让 AI 来做，哪些不要
AI 擅长 Roadmap 的机械层，弱在判断层。
| AI 擅长 | AI 不擅长 |
|---|---|
| 排月度列、画依赖图 | 估你这套代码的工程量 |
| 算 RICE 分、做容量算术 | 看出哪个”小”功能藏着一次迁移 |
| 起草不做清单和砍掉顺序 | 在战略必发和分数之间权衡 |
| 找出卡住别人的 feature | 判断干系人到底能接受什么 |
AI 给的估时只能当占位，要等真碰过代码的工程师锚定后才算数。绝不要只凭 AI 估时就承诺上线日期。
需要给 AI 的输入信息
- 10-15 个 feature ideas，每个配一句话描述
- 团队容量（人 × 周，工程师和设计分开算）
- 本季战略目标（一句话）
- 战略必发（不看分）+ 每个为什么不可动
- 类似的过去季度：出了什么、滑了什么、滑了多少
- 不在范围内的：冻结的代码区、监管工作、团队休假
过去季度的数据越细，模型校准得越准。如果上季度滑了 30%，就如实写——这应该让模型更保守，而不是更乐观。
RICE：让 AI 把过程算给你看
这里的优先级大多跑在 RICE 上：(Reach × Impact × Confidence) ÷ Effort。Reach 是固定时间窗内触达多少用户，Impact 是一个倍数（常用刻度：3 = 巨大、2 = 高、1 = 中、0.5 = 低、0.25 = 极小），Confidence 是百分比（100% / 80% / 50%），Effort 是人 × 月或人 × 周。分数就是单位工作量带来的总影响——越高越好。
让 AI 把 RICE 表连同每一项输入一起列出来，而不是只给一个排好序的清单。某个”高价值”功能背后藏着的 50% 置信度，恰恰是你在承诺前最该看到的东西。
可直接复制的 Prompt
规划 3 个月 Roadmap。
战略目标：[一句话]
战略必发（带原因）：[列表]
容量：[工程人 × 周 / 设计人 × 周]
类似过去季度——出 vs 滑：[notes]
不在范围内 / 冻结的：[列表]
候选 feature：
1. [feature] — [描述] — 工程估时（如有）：[S/M/L]
2. ...
请输出：
1. 一张 RICE 表：Reach、Impact、Confidence(%)、Effort（人 × 周）、分数——每项输入都要可见
2. 3 列月度 Roadmap，feature 按月分配
3. 依赖图——谁卡谁，卡住别人的排在前面
4. ~20% slack 留给反应式工作 + 使用规则
5. "本季度不做"段——3 件明确推迟 + 原因
6. "本季翻车"砍掉顺序——先砍 / 再砍 / 三砍
7. 每个 feature 一个 1-5 置信度（按估时把握）
按 80% 容量规划。20% 留给意外。低置信的 feature 不要排进第 3 个月。平台 / 基建为主的季度，再加一句：单独加一条"维护 + 基建"轨，固定占 20-30% 容量。
规划这一步用哪个模型（截至 2026 年 6 月）
这是一个带长输入的推理 + 算术任务，所以模式选择和上下文窗口比纯写代码能力更重要。
| 模型 / 套餐 | 为什么适合做 Roadmap | 备注 |
|---|---|---|
| ChatGPT Plus（$20），GPT-5.5「Thinking」 | 结构化推理强；把选择器从「Instant」切走，它才会把 RICE 过程算出来 | 应用内上下文约 320 页；完整 1M 仅 $200 Pro |
| Claude Pro（$20），Sonnet 4.6 | 1M token 上下文，一口气塞下完整 brief + 过去季度笔记 | brief 很大时上 Max 用 Opus 4.7 |
| Google AI Pro（$19.99），Gemini 3.1 Pro | 1M 上下文 + Workspace；输入若在 Google 表格 / 文档里很顺手 | 原名「Gemini Advanced」，2026 年初改名 |
三家都能搞定一个季度的计划。真正的决定因素通常是你的素材本来放在哪，以及你有没有记得把模型切进它的思考 / 推理模式，让 RICE 算术是真算出来的，而不是猜的。
建议让 AI 输出成什么样
3 列月度 + 依赖箭头 / 注解 + slack 行 + “不做” callout + 砍掉顺序 + 每个 feature 的置信度。规划阶段别上甘特图——它暗示一种你现在还没有的精确度。如果团队是持续交付、而非按版本发布，Now / Next / Later 的布局往往比固定月份更好用：“Now”列是承诺出去的，“Next”和”Later”则随着你学到的东西随时重排。
怎么判断 AI 给的结果能不能直接用
- 承诺出去的人 × 周落在 80% 附近，不是 100%
- 战略必发即使 RICE 分低也在计划里
- “不做”段具体、不空
- 依赖被命名，卡住别人的 feature 排在它前面
- 砍掉顺序具体（先 / 再 / 三），不是”到时候再说”
- 每一行 RICE 都显示 Reach / Impact / Confidence / Effort 输入
容易踩的坑
- 计划到 100% 容量。 一个意外炸掉整季度；上限压到 ~80%。
- 没”不做”清单。 干系人中途偷渡范围。
- 跳过依赖检查。 feature 等前置卡死。
- 让 AI 不带工程师估时。 尺寸漂离你真实的代码。
- 把 Roadmap 当合同。 它是假设——每月重排。
- 把战略必发藏在常规槽位。 要显眼，并写明原因。
FAQ
季度规划还是月度规划？ 季度骨架，月度重排。周度太噪，撑不起一份 Roadmap。把季度当承诺单位，随着置信度变实再按月调整。
要不要对外公开 Roadmap？ 要，但要带 caveat，最好用 Now / Next / Later 的形式。对外 Roadmap 比内部更锚定预期，所以绝不要把你自己只打 2/5 置信的第 3 月项目带着日期公开。
OKR 和 Roadmap 是什么关系？ Roadmap 服务 OKR，不是反过来。每一项 Roadmap 都该对上一个结果指标；如果你说不出指标，这一项很可能是为做而做的产出。
2026 年的 Roadmap 要不要把 AI agent 当用户？ 越来越要。如果你的产品对外暴露 API 或 MCP 接口，就把面向 agent 的能力当成与人类功能并行的一条轨，而不是事后补的东西。
相关
- Roadmap 规划 Prompt：更多写法
- 功能优先级 Prompt：规划前先打分
- 功能优先级：RICE 优先级详解
- 项目计划草稿：Roadmap 定了再排交付
- PRD 草稿：每项 Roadmap 写一份 PRD
- 用户反馈聚类 AI：把用户信号变成 Roadmap 输入
- Roadmap 摘要 AI：做对外摘要