任务场景
新季度。你有 10-15 个 feature ideas、有限的团队容量、一个战略目标。你要一份野心够推动、现实能出货的 Roadmap，并显眼地列出”本季度不做哪些”，防止干系人中途偷渡范围。能扛第 2 周的 Roadmap，是按 ~80% 容量规划的，不是 100%。
哪些情况适合让 AI 来做，哪些情况不要
AI 善于结构：按月分列、依赖映射、容量算术。但它估不准工程量——那需要真碰过代码的人。AI 的估时是占位，要让工程师锚定后再承诺日期。
需要给 AI 的输入信息
- 10-15 个 feature ideas + 一句话描述
- 团队容量（人 × 周，工程师和设计分开）
- 本季战略目标
- 战略必发（不看分） + 原因
- 类似的过去季度——出了什么 / 滑了什么
- 不在范围内的：冻结的代码区、监管工作、团队休假
可直接复制的 Prompt
规划 3 个月 Roadmap。
战略目标：<line>
战略必发（带原因）：<列表>
容量：<工程周 / 设计周>
类似过去季度——出 vs 滑：<notes>
不在范围内 / 冻结的：<列表>
候选 feature：
1. <feature> ——<描述> ——工程估时（如有）：<S/M/L>
2. ...
请输出：
1. 3 列月度 Roadmap，feature 按月分配
2. feature 尺寸（人 × 周）+ 置信度
3. 依赖图——谁卡谁
4. ~20% slack 留给反应式工作 + 使用规则
5. "本季度不做" 段——3 件明确推迟 + 原因
6. "本季翻车" 砍掉顺序——先砍 / 再砍 / 三砍
7. 每个 feature 一个 1-5 置信度（按 AI 估时把握）
按 80% 容量规划。20% 留给意外。低置信的 feature 不要排到第 N+2 个月。平台 / 基建为主的季度：“单独加一条”维护 + 基建” 轨，固定比例容量——通常 20-30%。“
建议让 AI 输出成什么样
3 列月度 + 依赖箭头 / 注解 + slack 行 + “不做” callout + 砍掉顺序 + 置信度。规划阶段不要甘特图——太早细化。
怎么判断 AI 给的结果能不能直接用
- 总人 × 周到 80%，不是 100%
- 战略必发即使 RICE 分低也在计划里
- “不做”段具体，不空
- 依赖被命名，卡住别人的 feature 被排到前面
- “翻车” 砍掉顺序具体——先 / 再 / 三
容易踩的坑
- 计划到 100%——一个意外炸掉整季度
- 没”不做”清单——干系人中途偷渡范围
- 跳依赖检查——feature 等前置卡死
- 让 AI 不带工程估——尺寸漂离现实
- 把 Roadmap 当合同——它是假设，每月重排
- 把战略必发藏在常规槽位——要显眼
实操加深
做「用 AI 做 Roadmap 规划：野心 + 真能出货的季度计划」这类任务时，AI 输出质量主要取决于输入包是否完整。至少给它受众、原始材料、目标格式、你要做的决策，以及一好一坏两个参考。第一轮先要求保留事实，第二轮再优化结构、语气或表达，不要让模型一边猜事实一边润色。
拿到结果后单独做一次复核：有没有遗漏限制、编造细节、行动项不清、语气和真实场景不符。最终稿最好能马上使用，包含明确对象、下一步和判断标准，而不是还需要别人重新解释一遍。
FAQ
- 季度 vs 月度规划？ 季度骨架，月度重排。周度太噪。
- 要不要对外公开 Roadmap？ 要带 caveat。对外 Roadmap 比内部更锚定预期。
- 公开 OKR 和 Roadmap？ Roadmap 服务 OKR，不是反过来。
相关
- Roadmap 规划 Prompt ——更多写法
- 功能优先级 Prompt ——规划前先打分
- 功能优先级 ——RICE 优先级
- 项目计划草稿 ——Roadmap 定了再排交付
- PRD 草稿 ——每项 Roadmap 写 PRD
- 用户反馈聚类 AI ——用户信号给 Roadmap 输入
- Roadmap 摘要 AI ——对外摘要