产品路线图（product roadmap）是一份关于你打算做什么、大致按什么顺序、以及——多数路线图最爱跳过的——为什么做的共识计划。它让团队、管理层、乃至越来越多的 AI agent，不用开例会就对方向保持一致。这页做两件事：先把产品路线图到底是什么、真正会被用起来的几种类型、怎么搭一份讲清楚；然后诚实地谈那件没人提醒你的事——路线图本质是覆盖在一堆决策之上的一个「视图」，而只要底下某个决策一变，路线图当天就悄悄错了，却没有任何东西告诉你错在哪。
产品路线图就是对「我们接下来做什么、为什么做」这个问题的共识答案——用主题（theme）或结果（outcome）沿时间铺开来表达。剥掉那些仪式感，它的意义就是把「方向」变得可读：让下游每个人不必反复来问就能行动。一份好的路线图，谈的更多是结果（「把激活时间砍一半」）而不是功能（「上线 onboarding v2」），因为结果经得起现实的撞击，功能清单经不起。
它不是 backlog（那是没排序的「所有事情」那一堆），不是发布计划（那是已承诺事项的日期和版本），也不是甘特图（那是带依赖的任务级排期）。路线图站在这三者之上：它是被具体到能拿来排优先级的策略，但又松到不至于对 Q3 说谎。下面会把这几者的区别讲清。
格式并不神圣。路线图可以是白板上的三列，也可以是专业工具里一条工整的时间轴。真正要紧的是：每一项是否都能回溯到一个目标、以及它背后的决策——因为那根线是最先断的，一断，路线图就成了表演。
五种格式覆盖几乎所有真实路线图。它们并不互斥——团队常常给干系人留一份 Now-Next-Later，给交付留一份时间轴。按你「诚实地」有多少确定性来选。
用三个桶代替日期。它诚实地承认「later 就是模糊的」，这也是它成为产品型团队默认选择的原因。给干系人看很好，给想要上线日期的人看很糟——而且是故意的。
把条目落在真实的月份或季度上。当承诺是真的（一次发布、一份合同、对另一个团队的依赖）时很有用；当确定性是假的就很危险——给一个猜测标上精确日期，读者会当成承诺。
围绕几个策略主题（「信任」「激活」「企业级就绪」）而不是功能来组织。把对话保持在「为什么」的高度，并且让主题下的具体功能可以变，而路线图本身不算「变了」。
每一项是一个可衡量的结果而非功能——「把首次见效时间降到 5 分钟以内」。这是最能逼团队保持诚实的格式：你没法靠「上线了」就把一个结果标成 done，你得把那个数字推动起来。
按版本或发布列车分组。最接近发布计划，适合工作已经承诺、你在协调真实上线的阶段。这里就是路线图交棒给发布计划和 changelog 的地方。
想要可直接抄的版本？看 产品路线图示例。
三样看起来很像、回答的却是不同问题的东西。把它们混为一谈，是路线图沦为一串空头支票最常见的方式。
| 构件 | 回答什么 | 时间尺度 |
|---|---|---|
| 产品路线图 | 做什么、为什么，按主题/结果 | 季度，宽松 |
| 发布计划 | 已承诺的工作何时上线 | 周，明确 |
| 甘特图 | 任务顺序与依赖 | 天，精确 |
| Backlog | 所有事情，无排序 | 无 |
一条诚实的原则：你越靠左，就越不该对日期下承诺。一份承诺精确日期的路线图，其实是伪装成路线图的发布计划——第一次跳票就把整份东西变成虚构。（工作一旦承诺，就交给 发布计划 和 发布说明。）
路线图是 产品策略 的下游。任何一项上去之前，你都该能说清它服务于哪几个赌注——你为谁、解决什么问题、为什么是现在。跳过这一步，你得到的就是一张配了日历的功能清单，这正是最常见的翻车方式。
选一个匹配你真实确定性的格式（见上）。当你对「later 就是模糊」很诚实时用 Now-Next-Later；只有在承诺确实牢靠的地方才用时间轴。别画你没有的精确度。
路线图在你发布它的当天最准。之后决策会动，而路线图不会跟着动——除非有人记得一次改动牵连到的每一个下游条目。这一步每篇指南都一笔带过，没人真用手做得到。这页剩下的部分讲的就是它。
先把话说清楚：Draftlize 不是 路线图工具。你想要漂亮的时间轴 UI，就用 Productboard、Aha 或 ProductPlan——我们乐意指给你。Draftlize 只占一件它们都不做的窄事：让路线图底下的那些决策不悄悄过时。
每一项都压在一些决策上——一次定价决定、一个目标人群、一个对依赖的假设。路线图只显示结论，不显示推理，所以推理一变，画面照旧，却悄悄变假了。漂移之所以看不见，恰恰因为路线图看起来「已完成」。
在 Draftlize 里每个决策都是一张可寻址卡片，路线图条目、spec、PRD 都连到它们依赖的决策。上游决策一改，所有压在它上面的东西自动标记 stale——就像构建系统让被改文件的下游全部失效一样。你在做出改动的那一刻就看到它打破了什么，而不是等到下次规划评审。
留着你的路线图工具。在它底下加一层 Draftlize 作为决策层，让 Claude Code 或 Cursor 经 MCP 读写——这样给你起草下一份 spec 的 agent，眼前是路线图所依据的「活」决策，而不是上个季度规划时为真的那一版。
路线图失败，不是因为画得差，而是因为没有任何东西在它底下某个决策不再成立时告诉它。留着你的路线图工具，补上让它底下决策保持最新的那一层。
路线图讲你打算做什么、为什么，用主题或结果、按宽松的时间段表达；发布计划讲具体的、已承诺的工作何时上线，用明确的日期和版本。路线图在上游、偏策略；发布计划在下游、偏执行。
不是。backlog 是没排序的「所有可能要做的事」那一堆；路线图是围绕目标、刻意挑选并排好优先级的子集。backlog 回答「我们可以做什么」，路线图回答「我们接下来会做什么、为什么」。
让时间尺度匹配你真实的确定性。多数团队把「now」做实（本季度）、「next」做成方向（下一两个季度）、「later」只放没有日期的主题。在你把握之外画精确日期，是把路线图变成空头支票最快的方式。
产品经理负责它，但它由工程、设计、销售、支持、管理层的多方输入搭起来，也服务于所有这些人。负责，意味着让它保持诚实与最新——而不是一个人拍板所有事。
就路线图视图本身而言，Productboard、Aha、ProductPlan 这类专业工具很强。Draftlize 不是路线图工具——它坐在你所用工具的底下，持有每个路线图条目所依赖的决策，让它们不悄悄过时。
留着你喜欢的路线图工具。补上 Draftlize 来做它们都不做的那一件事：确保路线图所依赖的每个决策都保持最新——并且你的 AI agent 永远读到「活」的那一版。
$5 免费开始