产品路线图这件事，说起来都知道重要，做起来没几个人觉得自己真的做得好。
我自己做过不少版本。最早是一个 Notion 表格，列了功能、优先级、预计时间，看起来很整齐。后来换成 Miro 白板，贴了一堆便利贴，花了两个小时做出来，两周后没人看。再后来跟着季度 OKR 走，每次规划会前焦虑到凌晨，因为你知道排出来的东西大概率三个月后会变。
说真的，路线图的问题从来不在工具上。哪个都能画出一张漂亮的图：
-
Notion 表格 -
Miro 白板 -
Linear 项目管理 -
Airtable 数据库
真正的问题是你自己脑子里没有一套稳定的判断框架，每次排优先级都在拍脑袋，拍完之后自己都不敢回去看。
从文档结构和框架覆盖来看，roadmap-management 这个 Skill 的野心比我想象中大很多。它不在工具层抢地盘，而是把产品经理做路线图时最需要的那套“判断骨架”做成了可交互的对话模板。读完这篇文章，你会理解它为什么选了这些框架、每个框架适合什么场景、以及这种“把方法论做成 Skill”的设计思路为什么值得关注。
环境准备
这个 Skill 的使用门槛低到几乎没有。它是 Smithery 平台上的一个 AI Skill，托管在 Smithery 的 skill 市场里，属于 anthropics 命名空间下的知识工作类插件。
要在 Claude Code 里使用它，你得先确认 Claude Code 已经支持 Skills 功能并接入了 Smithery 平台。具体来说有两步：在 Smithery 上找到 roadmap-management 的页面，点击安装后授权给 Claude Code。装好之后不需要额外配置，直接在对话里提路线图相关的问题，Skill 会被自动触发。
如果你想在 Claude.ai 或 API 中使用，需要检查你的账户是否开通了 Skills 扩展能力。目前 Smithery 平台上的数据显示这个 Skill 有 93 次安装，6,647 次浏览量，社区热度不算高但稳定增长。GitHub 仓库显示约 8,000 个 star，说明底层代码和 Prompt 设计经得起一定规模的审视。
有一点值得注意：这个 Skill 严重依赖你提供的产品上下文。它不是那种”丢个名称给我，我帮你规划”的魔法工具。你得准备好这些真实数据，它才能输出有用的东西：
-
团队规模 -
当前产品阶段 -
已有的功能积压 -
战略目标
如果输入太模糊，输出的优先级排序也会很空泛。
操作流程
用这个 Skill 做一次路线图规划，整体流程可以分成五个环节：
-
选格式 -
排优先级 -
理依赖 -
算容量 -
做沟通
它不是流水线式的串行步骤，更像是一套可自由组合的分析模块，你可以根据当前遇到的问题跳到对应的环节。
最重要的一步是选对路线图格式。Skill 提供了四种格式：Now/Next/Later 把工作分成“当前已承诺”“近期计划”“远期方向”三栏，适合对外沟通，因为它刻意避免了日期的虚假精确性。季度主题型围绕每季度 2-3 个战略主题组织内容，适合需要解释“为什么做这批事”的场景。OKR 对齐型把每个路线图项直接映射到具体的关键结果，适合跑 OKR 的组织。时间线/甘特图型适合工程执行层面的调度，但不推荐对外使用。
优先级排序是 Skill 的核心模块之一。它内置了四种框架，各有各的适用边界。
RICE 评分用四个维度给每个功能打分，适合有足够数据的成熟产品，算出来的分数有说服力：
-
覆盖范围：影响多少用户 -
影响程度：对每个用户的影响有多大 -
信心水平：对估计有多确定 -
所需努力：需要多少人月MoSCoW 把功能分成四类，适合定义版本范围或者跟利益相关者协商范围： -
必须有：没有这些路线图就是失败的 -
应该有：重要且预期，但没有也能交付 -
可以有：理想但明显优先级低 -
不会有：明确不在本期范围内ICE 评分比 RICE 更轻量，每个维度 1-10 分，适合早期产品或者快速筛选大量功能。价值与努力矩阵是一个 2×2 象限图，把功能放在四个区域，适合团队规划会上的可视化讨论。
依赖关系映射是很多人会跳过的环节，但 Skill 专门给了它一大段指令。它要求从五个维度去扫描：
-
技术依赖：功能 B 需要功能 A 的基础设施 -
团队依赖：需要跨团队协调（设计、平台、数据） -
外部依赖：等待供应商或第三方集成 -
知识依赖：需要先完成研究或调查 -
序列依赖：必须先交付 A 再开始 B
每个依赖都要求分配负责人和”需要日期”，还要求提前准备应急计划。这个设计很有意思，它把依赖管理从”遇到了再说”变成了一个结构化的检查清单。
容量规划部分有一组参考比例：
-
70% 计划功能 -
20% 技术健康 -
10% 未计划缓冲
它还根据产品阶段给了调整建议：新产品多做功能、成熟产品多投技术债、事故后多投可靠性。这组数字不是硬性规定，但作为一个快速校对工具很实用，如果你的路线图承诺明显超过容量的 70%，就得问问自己砍掉了什么。
最后一个环节是路线图变更的沟通模板。Skill 提供了五步沟通法：
-
承认变更：直接说明什么在变 -
解释原因：什么新信息驱动了这个决定 -
展示权衡：什么被降优先级以腾出空间 -
展示新计划：更新后的路线图 -
承认影响：谁受影响、怎么受影响
它还特别提醒要区分”路线图变更”和”范围调整”，前者是战略级重排，后者是正常执行优化。这个提醒的价值在于，它能防止团队因为过于频繁的”路线图变更”而失去对战略方向的信心。
关键设计
从架构上看，roadmap-management 的 SKILL.md 本质上是一个结构高度清晰的 Prompt 系统。它不是代码，不是工具，不是 API，就是一段以”你是产品路线图规划、优先级排序和沟通的专家”开头的角色定义，然后按以下模块展开：
-
四种路线图格式 -
四种优先级框架 -
依赖管理方法 -
容量规划公式 -
沟通策略
这种设计有一个隐含的判断，路线图管理这件事最大的困难不是信息不足，而是决策框架缺失。大多数产品经理不是缺数据，是面对一堆数据时不知道该按什么逻辑去判断哪个功能更重要。Skill 的策略是在对话中直接提供这些判断框架，然后让用户填入自己的上下文。这个思路跟传统 SaaS 工具完全不同，传统工具给你一个界面让你自己操作，Skill 给你一套方法论让你在对话中完成判断。
另一个有趣的设计是它把“容量规划”和“路线图变更沟通”作为独立的模块写进了 Skill，而不是像大多数路线图工具那样只关注可视化部分。从设计者的视角推演，这两个模块的存在说明设计者认为路线图失败的主要原因不是画得不好看，而是排多了做不完、变了说不清。这两件事发生之后，再漂亮的路线图也没用。
但我对这个设计有一个保留意见。四种优先级框架放在同一个 Skill 里，确实给用户提供了灵活度，但同时也增加了选择成本。RICE 和 ICE 覆盖的场景有重叠，MoSCoW 和价值与努力矩阵也有部分重叠。对于第一次用这个 Skill 的用户，他可能需要额外花时间去理解每个框架的适用边界。如果 Skill 在对话开始时能先问几个关键问题来决定推荐哪个框架，而不是把四种框架平铺出来，入门体验会更好。
还有一个细节值得注意：Skill 里的数值参考（比如 70/20/10 的容量分配比例、1-10 的 ICE 评分范围）在很多场景下是一个合理的起点，但不是放之四海皆准的。如果你的团队是 3 个人的创业公司，70% 计划功能这个比例可能不够激进。如果你的产品是一个已经运行了五年的 SaaS 平台，20% 技术健康可能不够。Skill 在指令层面给了调整建议，但在实际对话中是否真的会根据用户的上下文动态调整这些比例，取决于 AI 模型的理解能力。
使用场景
挑两个最能说明这个 Skill 价值的场景来聊聊。
第一个场景是接入一个新团队时的路线图对齐。假设你刚接手一个已经跑了两个季度的产品线，功能积压里堆了 40 多个需求，各有各的“紧急”理由。传统的做法是拉一个表格一个一个过，但效率很低，因为每个人对“重要”的定义不一样。用这个 Skill 你可以直接把积压喂给它，用 RICE 评分框架跑一轮，过程中它会追问每个维度的评分理由。出来的结果不一定完美，但它至少给了你一个可追溯的判断标准，而不是“因为我感觉这个更重要”。
第二个场景是季度规划会前的准备。每季度前产品经理都要做一件事：跟老板同步下一季度的路线图。如果你只是列一个功能清单，老板大概率会追问“为什么要做这些”“不做行不行”“那个为什么不在”。用 Skill 的季度主题 + OKR 对齐模式，你可以把每个功能映射到一个战略主题和一个可衡量的关键结果上。这种输出方式的优势在于它强迫你在内部先想清楚逻辑，而不是在会上被问到才开始解释。
还有一个容易被忽略的使用场景是路线图变更时的沟通。产品经理最怕的一件事是在季度中期被告知“优先级变了，那个功能要先做”，然后你要跟已经投入了精力的团队解释，还要跟期望那个功能的用户沟通。Skill 提供的五步沟通模板在你的方案被推倒重来时至少能帮你把话说清楚，而不是憋出一句“老板说要先做这个”。
但要说清楚它的适用边界。如果你的产品还处于 0-1 阶段，用户量和数据都不够支撑 RICE 评分，这时候用 ICE 或者直接做直觉判断可能更现实。如果你在一个完全没有 OKR 文化的团队里，季度主题型的价值会大打折扣。这个 Skill 不是万能药，它更擅长在“已经有了一些数据但缺乏判断结构”的阶段发挥作用。
洞察与反思
用得越深，我越觉得这个 Skill 最大的价值不在那些框架本身。RICE、MoSCoW、ICE 这些方法论你在任何一本产品管理书上都能找到，网上有无数篇讲解文章。Skill 真正提供的是两个东西：第一，它把这些框架从“我知道这个概念”变成了“我在实际决策时可以用它”，因为对话过程中它会带着你一步步套用；第二，它强制你面对一个事实，如果你无法为自己的优先级判断给出一个可追溯的理由，那说明你还没有真正做过判断。
从趋势来看，这种“把方法论做成 Skill”的方向可能会成为 AI 产品中一个被低估的品类。过去我们习惯的 AI 产品形态是“AI 帮你做”（AI 直接输出结果）或者“AI 帮你学”（AI 当老师解释概念）。roadmap-management 代表的是第三种形态：“AI 带着你按一套方法论走完一个决策过程”。它不替你决策，但也不只是科普概念，它在中间地带，给你骨架，你填血肉。
但我也看到一个结构性的矛盾。这种 Skill 的效果极度依赖对话质量，而对话质量又依赖用户输入的质量。如果你给的是模棱两可的产品上下文，它输出的优先级排序也只能是模棱两可的。这不是 Skill 的问题，是方法论本身的特性。RICE 评分里的“影响”和“信心”这两个维度本来就有主观成分，Skill 可以把计算过程标准化，但没法替你做出主观判断。
另一个值得讨论的点是，这种 Skill 在未来会不会被 Agent 替代。如果 AI 有一天能直接读取你的产品数据、用户反馈、团队容量，然后自动生成路线图建议，那这个 Skill 的“骨架提供”价值就会大幅缩水。但短期来看，让 AI 替你拍板产品优先级这件事本身就很危险，因为 AI 不承担决策后果。Skill 的“方法论提供”角色在相当长一段时间内仍然有存在价值。
资源地址
| 资源 | 地址 |
|---|---|
| Smithery | smithery.ai/skills/anthropics/roadmap-management |
总结
回到开头那个问题：路线图做不好的原因是什么？从这个 Skill 的架构反推，设计者给出的答案很明确，不是因为工具不够好，而是因为缺乏一套可复用的判断框架，以及在面对变化时没准备好一套沟通逻辑。
如果你现在已经在用 Notion 或者 Linear 管理产品规划，这个 Skill 不会替代你现有的工具链。它做的事情是你的工具做不到的：在你需要做优先级判断时给你一个结构化的思维框架，在你需要解释路线图变更时给你一套可复用的沟通模板。你用完之后规划仍然在你的 Notion 里，但决策依据会清晰很多。
如果你对它感兴趣，建议先从一个具体的场景入手，比如用 RICE 评分跑一遍积压里的前 10 个功能，或者用 Now/Next/Later 重排一版当前的路线图。别一上来就尝试全部四个框架，那样很容易陷入方法论选择疲劳。先从让一个判断变得更清晰开始，再慢慢扩展。