关于 pm-idea-to-plan
pm-idea-to-plan 是面向产品经理的构思到可执行计划编排技能，按问题、发现、用户、风险测试、优先级、规格和指标依次推进。它强调先取得证据再写规格，并在计划完成后交由产品评审验证。
主要功能
- 01按阶段编排产品规划技能
- 02先做问题界定与用户发现
- 03设计最高风险假设测试
- 04依据风险确定优先级
- 05证据就绪后编写规格
- 06将计划交由产品评审
适用场景
- 01把初步想法转成可执行计划
- 02在投入开发前验证采用或付费意愿
- 03为新产品确定首个开发范围
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/pm-idea-to-plan确认已加载。
详细介绍
想法 → 计划（PM 创建编排器）技能
此技能的工作方式（请先阅读）
这是将原始想法转化为可直接构建的计划的入口，也是 ux-design-from-scratch 的 PM 对应技能。pm-product-review 编排的是验证方向（生成式 → 审核），而此技能编排的是组合式方向（生成式 → 生成式）：它按顺序推进 PM 范围阶梯 —
问题 → 探索 → 用户 → 最危险假设测试 → 优先级排序 → 规格说明 → 指标 —
根据工作需要调用各项技能，最后将结果交给 pm-product-review 进行验证。
这是 docs/orchestration-policy.md 中组合式编排部分（§9）在 PM 领域的可执行形式。它的全部职责，就是避免此技能旨在解决的失败情形：PRD 写得过于详尽，却没有充分降低产品押注的风险——一份精致的规格说明，建立在未经审视的市场和未经验证的付费意愿之上。规格说明是最后一级，而不是第一级；在下方的证据阶梯完成之前，绝不会启动规格说明。
让此技能发挥作用的唯一准则：证据先于规格说明。 当被要求“带我从想法走到计划”时，Claude 默认会匆忙给出一份看似合理的 PRD——包含需求、用户故事和指标，却建立在未经验证的问题和零采用证据之上。这份文档看起来很完整，而这正是它危险的原因：团队会据此开展构建工作。此编排器会强制先梳理问题、探索证据和最危险假设测试，并确保规格说明与计划相称，而不是任由其吞噬整个计划。
以下情况请勿使用此技能：
- 只需要一种明确的交付物——“帮我写一份 PRD”“帮我界定这个问题”“帮我制作优先级矩阵”。让相应技能直接触发。明确指定的范围优先于编排。
- 战略／发布流程——愿景与战略、竞争分析、路线图、GTM、发布实验。这属于另一条组合式流程（
pm-vision-strategy、pm-competitive-analysis、pm-roadmap、pm-gtm-plan、pm-experimentation-ab、pm-analytics）。此技能到经过验证、可直接构建的计划为止；应提议继续进入战略流程，而不是在此处生成相关内容。
步骤 0 — 建立上下文概况（仅一次）
根据用户提供的信息进行推断；只提出一两个会实质影响后续流程的问题。说明你将采用的假设，然后按顺序推进。在本次会话的其余时间内保留这些信息——不要重复询问。
- 一句话概括想法——计划为谁提出什么。复述用户的想法也是第一次完整性检查（如果只能将其表述为解决方案，说明问题尚未界定）。
- 构建决策的影响与可逆性——成本低且可逆的实验所需证据，远少于成本高且难以撤回的押注。这决定需要多大程度的探索和测试严谨性（对可逆决策过度测试，与对重大决策测试不足，同样不妥）。
- 阶段——尚未证实的是问题（有人在意吗？）、尚待明确的是解决方案（用户能否使用？他们会切换吗？），还是可行性／规模化（他们会付费吗？方案能否经受考验？）。这有助于确定每一级所需的深度。
- 市场成熟度——这是一个竞争激烈的品类吗？如果是，最危险的假设几乎从来都不是“我们能不能构建出来”，而是切换成本和采用情况（为什么要放弃现有产品？）。尽早指出这一点；它会改变优先测试的假设，并使
pm-competitive-analysis成为适时的选项。 - 现有证据——已有的研究、数据或客户联系。不要重复用户已经完成的探索；应在其基础上推进。
步骤 1 — 逐级组合阶梯，并在每一阶设置门槛
按顺序逐级推进。每一阶都将技能归类为核心（立即应用）／可提供（提及，不自动构建）／跳过（由其他环节负责或已完成）——不要默认以最大深度应用每项技能（那是创建侧的盲目跟风）。
子技能以其可安装技能的
name命名。只有在已安装时才组合使用；如果某个具名技能不存在，就在此阶内运用其意图和核心最佳实践，并注明缺失之处，而不是因此停滞。
第 1 阶 — 界定问题 · pm-problem-statement （核心，首先执行）
将问题明确为有证据支撑的差距，并与症状和解决方案区分开来 （问题 + 后果 + 目标）。在这一点成立之前，后续所有内容都不可信。如果用户无法提供证据，则继续推进，但要将该问题标记为未经验证的假设，并在第 3 阶将其处理掉——不要掩盖这一点。
第 2 阶 — 通过探索降低风险 · pm-discovery （核心——切勿跳过而直接编写规格说明）
这是默认赶着写 PRD 时会跳过的一阶，而跳过它正是导致规格说明扎实、但押注不靠谱的原因。探索要确认谁会真正采用、产品如何融入他们当前的工作流、他们是否愿意切换，以及他们是否愿意付费——这些都是计划赖以成立的证据。探索的深度应与步骤 0 的风险相称（对于可逆的决策，轻量、持续地接触用户；对于重大且不可逆的决策，则开展更深入的研究），但始终要在编写规格说明之前进行。在竞争激烈的市场中，切换成本的证据正是从这里获得的。
第 3 阶 — 明确用户 · pm-personas-jtbd （核心）
以探索证据为基础确定目标用户——围绕待完成的工作和真实痛点展开，每个细节都必须有助于决策。不要虚构人口统计特征。本阶依赖第 2 阶的产出；如果跳过了探索，那么用户画像只是猜测，应明确标注为猜测。
第 4 阶 — 验证风险最高的假设 · pm-assumption-testing （核心——并置于首要位置）
找出关键赌注假设——一旦为假，就会让整个想法失败的那个假设——将其表述为可证伪的命题，并设计能回答该问题的最低成本测试，且预先设定成功标准。将可行性／需求度测试置于首要位置，不要把它埋在规格说明之下。在大多数从想法到计划的场景中，风险最高的假设是“我们的目标用户确实会采用这一方案，并愿意付费／切换”——因此，通常应在这里明确设置一道构建／不构建的门槛，通过门面测试、礼宾式服务或预售测试，在编写一行代码之前验证真实行为**。如果计划把这项测试当作 PRD 中一个不起眼的小节，那么这一阶就没有做好。
第 5 阶 — 确定优先构建内容 · pm-prioritization （核心）
使用一种能关联到策略／成果并揭示取舍的方法，确定最先交付的部分，而不是用看似精确的分数制造假象。优先级排序应在明确风险最高的假设之后进行——优先级应以已验证的风险为依据，而不是以愿望清单为依据。
第 6 阶 — 编写计划 · pm-product-spec （核心，最后执行——且应与证据相称）
现在才编写规格说明／PRD，并确保其详略程度与底层证据相称。每项需求都必须可测试；涵盖完整流程（而不只是理想路径）；明确列出范围之外的内容；设置依赖关系／约束／假设章节；并且逐项追溯每个假设，说明它是否已在第 4 阶得到验证，或仍未解决。规格说明的任务是承接已有证据和未解决的风险，而不是用经过润色的需求掩盖它们。pm-user-story 由本阶负责（遵循该技能的指引）。
第 7 阶 — 定义成功标准 · pm-okrs-kpis (可选 → 核心，若指标具有重要意义)
pm-product-spec 已包含成功指标部分；当计划需要一等的结果指标时，加入 pm-okrs-kpis——包含基线／目标值和护栏的结果指标，而非虚荣指标。先将其作为可选项；如果用户要求提供成功指标，或规格中的指标需要真正严谨的定义，则将其设为核心技能。
一致性规则：决策会沿阶梯向上传递。第 1 阶中定义的问题、第 2 阶中的证据，以及第 4 阶中经验证／尚未验证的假设，都会由后续每一阶复用——不要在规格中重新争论这些内容。这正是从想法出发逐步推进的全部意义。
第 2 步 — 通过 product-review 验证
计划完成后，将其交给 pm-product-review（如果已安装），由它应用审查策略：它会自动运行 pm-assumption-rigor-audit（始终适用的审查视角——是否针对了风险最高的假设，是否可证伪，是否匹配了保真度恰当的方法，并预先设定了标准？），并根据产物类型分派审查——规格 → pm-spec-quality-audit，指标 → pm-okr-metric-validity-audit，优先级排序 → pm-prioritization-rigor-audit，并提供 pm-decision-quality-audit 来审查是否构建的决策。它会返回一份按优先级排序、去重后的报告，而不是每项审计各出一份报告。根据第 0 步的决策处理所有发现。如果未安装 pm-product-review，则直接运行已有的审计技能，或根据策略自行审查。
第 3 步 — 提供策略／发布路径（不要自动运行）
经过验证的计划是交接节点，而非终点。计划通过审查后，应提供继续推进策略路径的选项，而不是未经提示就生成内容：产品愿景与策略（pm-vision-strategy）、竞争分析（pm-competitive-analysis——在竞争激烈的市场中应重点提供，因为转换成本是这条路径要解决的策略问题）、路线图（pm-roadmap）、上市计划（pm-gtm-plan），以及发布实验与分析（pm-experimentation-ab、pm-analytics）。指出下一阶段是什么，才是服务；自动生成，就是盲目跟风。
常见的应做／不应做模式
| ❌ 不要 | ✅ 应该 |
|---|---|
| 一拿到想法就直接开始写 PRD | 先明确问题，再通过探索降低风险，然后才写规格 |
| 因为想法“显然”有市场就跳过探索 | 根据风险程度开展探索——评估用户采用、工作流适配度、转换成本和付费意愿 |
| 把验证测试藏在 PRD 的某个小节中 | 突出展示风险最高假设的测试（通常是礼宾式／预售测试），将其明确设为构建门槛 |
| 让规格变成整份计划 | 将规格保留为最后一个、与情况相称的阶；让它承载已有证据 |
| 把“用户是否愿意付费／转换”当作细节 | 在竞争激烈的市场中，将转换成本视为风险最高的假设，并优先测试 |
| 按功能愿望清单排优先级 | 根据已验证的风险进行优先级排序，并追溯到策略，清楚呈现取舍 |
| 为单个指定产物运行此编排器 | 让对应技能直接触发（明确指定的范围优先） |
| 自动生成愿景／竞争分析／路线图／上市计划 | 在计划通过验证后停止；接下来再提供策略路径 |
| 生成内容后就宣布完成 | 交由 pm-product-review 生成一份合并后的严重程度评级报告 |
与策略的关系
此技能是 docs/orchestration-policy.md 第 9 节“组合式编排”在 PM 工作中的可执行形式。与其配套的验证技能是 pm-product-review；对应的 UX 技能是 ux-design-from-scratch。如果此技能与策略不一致，以策略为准——请更新此技能，使其与策略一致。
源课程（Uxcel）
这是一个编排器——它的大部分内容都来自它组合的技能（请参阅 pm-problem-statement、pm-discovery、pm-personas-jtbd、pm-assumption-testing、pm-prioritization、pm-product-spec、pm-okrs-kpis 中的源课程）。其阶段划分——从创意到计划，在构建前先准备好证据并明确产品定义——基于以下课程：