把方法论变为AI工作流的PM skills深度解析

对于做产品，最大的体会是——方法论谁都能讲，能落地的没几个。

OST、JTBD、Lean Canvas、Pre-Mortem，这些词每个产品经理都熟。但每次真要用，要么打开一个空 Word 对着模板发呆，要么打开 ChatGPT 问"帮我写一个 PRD"，结果它给我一篇看起来很丰满、用起来全是空话的"标准模板"。

直到上周我在 GitHub 翻到一个项目，叫 PM Skills，三个月 1.6 万 Star。我拉下来用了几天，做了一份真实的 PRD 和一次小型用户访谈，才意识到——它解决的不是"AI 能不能写文档"，而是"AI 能不能陪你跑完一遍方法论"。 这两件事，差得很远。

下面是我的真实使用过程和一些拆解。

它到底是什么

一句话定位：PM Skills 是一个把产品经理的方法论编码成 AI 可执行工作流的开源市场（Marketplace）。

最新的 v2.0.0 一共有：

9 个插件
（pm-toolkit、pm-product-discovery、pm-product-strategy、pm-market-research、pm-data-analytics、pm-marketing-growth、pm-go-to-market、pm-execution、pm-ai-shipping）
68 个 Skills
（每个对应一个具体的方法论或框架）
42 个 Commands
（把多个 skills 串成端到端工作流）

它原生支持 Claude Code、Claude Cowork、Codex CLI；其他工具（Cursor、Gemini CLI、OpenCode、Kiro）通过复制 SKILL.md 也能用 skills 部分，但 /slash commands 只在 Claude/Codex 上能跑完整工作流。

开源地址：https://github.com/phuryn/pm-skills

可以用它做的三件事

场景一：写一份"敢拿出去评审"的 PRD

我手里有个真实需求——给我们内部一个工具加"团队空间"功能。原来我会怎么写？打开飞书文档，套一个公司模板，写背景、写目标、写功能点、画几张原型图，1 天搞定，但每次评审都被 CTO 问到哑口无言："这个功能为什么必须做？"

这次我装好 pm-execution 插件后，输入：

/write-prd 给内部协作工具新增"团队空间"功能

它做的不是"给我一个模板"，而是问我一连串我以前会跳过的问题：

这个需求的目标用户具体是谁？描述他们一天的工作流。
现在他们用什么方式解决这个问题？为什么这种方式不够好？
不做这个功能，最坏的结果是什么？
你的成功指标是什么？为什么是它而不是别的？
列出 3 个最有可能的失败原因。

我一开始还想偷懒"用一句话糊过去"，但因为它每个问题都接着追问"为什么"，逼得我要么去翻数据，要么承认"我其实不知道"。回答完所有问题，它才生成 8 段式 PRD，每一段的论据都来自我前面的回答。

变化：以前 PRD 是我"包装"想法的工具，现在它先帮我审讯自己的想法。评审会上 CTO 第一次没反驳，因为风险点已经在 PRD 里写明白了。

场景二：用户访谈脚本，从模板到带血的现场

我以前做用户访谈，脚本基本就是：

你平时怎么用 XX？
遇到什么问题？
希望怎么改？

这种问题，每个用户都能给你一个"看起来很合理"的答案，但它们没法支持决策。

我跑了 /interview prep，告诉它"我要访谈 5 个企业 IT 主管，验证我们的工单系统的痛点"。它直接走 JTBD（Jobs To Be Done） 框架：

触发场景
：上一次他们感到工单系统"碍事"，是在做什么任务？
进度问题
：他们当时想完成的是什么"进度"，而不是"任务"？
取舍问题
：当系统让他们烦躁时，他们用什么"补救手段"绕过去？（这个问题最杀，因为补救手段就是真正的需求）
不雇佣的力量
：他们考虑过换系统吗？为什么没换？

更狠的是它内置了禁问清单：不要问"你希望怎么改进"——用户给的是解决方案，不是问题。

我用这套脚本做了 3 场访谈，第一场就发现一个我们团队从没意识到的需求：IT 主管不是要"更好的工单分配"，而是想知道"哪个工单可以理直气壮地拖到下周"。这个洞察直接干掉了我们路线图上一个原计划做的功能。

场景三：Pre-Mortem，把"上线后翻车"提前到"立项时翻车"

/pre-mortem 这个命令被低估了。它的玩法很反直觉——假设这个项目已经上线 3 个月，并且彻底失败了，让团队倒推失败原因。

它会把所有风险按权重分成三类：

Tigers（真老虎）
：高概率 + 高影响，必须现在解决
Paper Tigers（纸老虎）
：看起来很吓人但概率很低，监控即可
Elephants（房间里的大象）
：所有人都看见但没人愿意说

我跑团队空间这个项目时，最后被拎出来的"大象"是——"我们其实没想清楚团队空间和现有项目空间的区别，PM 自己都解释不清楚，更别提让用户理解"。这条没有任何技术风险，但它差点让整个项目变成一次失败的 launch。Pre-Mortem 把它在立项阶段就摆上了桌面。

从产品视角看，它好在哪儿

抛开"功能多"这种废话，我更想说三件事：

1. 它把"流程"做成了产品的一等公民。

普通 AI 助手的交互单位是"一句话回复"。PM Skills 的交互单位是"一段流程"。它先问你 → 你答 → 它根据回答下一步问什么 → 最终输出一份反映你思考的产物。这种强制串行的提问机制，本质上是把方法论的"约束"做进了产品里。约束才是方法论的价值，模板不是。

2. 它选择了"窄而深"，而不是"全而浅"。

68 个 skills 听起来多，但每一个 skill 只解一个具体问题：identify-assumptions-existing 只做"识别已有产品的风险假设"，不掺别的。粒度细到这种程度，AI 才有可能给出带专业判断力的引导。这是典型的"小而美组合"思路，比一个号称"全能 PM 助手"的大模型应用强太多。

3. 命令（Commands）和技能（Skills）的二层结构是关键设计。

Skills 是积木，Commands 是已经搭好的样板间。这意味着：

新人可以直接用 /discover 跑完整流程
老手可以单独调 opportunity-solution-tree 这一个 skill 嵌进自己的工作流
同一个 skill（如 prioritization-frameworks）可以被多个 command 复用

这种"用积木而不是 monolith"的架构，是它能在三个月做到 60 多个 skill 还不混乱的根本原因。

会踩到的一些坑

老实说，不全是好事：

Windows 上用 OpenCode/Cursor 安装 skills 偶尔会卡
，PowerShell 的路径分隔符和文件复制偶尔需要手动改
Commands（/discover 这类）只在 Claude Code 和 Codex CLI 上是真原生
，复制到 Cursor/Gemini CLI 只剩 skills 部分，工作流就断了
它假设你有方法论基础
。如果你没听过 Opportunity Solution Tree，AI 问你"这个机会的子机会是什么"时你会卡住。它不是替你学习方法论的工具，是替你执行方法论的工具
它解决不了"我没有真实数据/真实用户"的问题
。如果你只是空想，它问的每一个问题你都会编答案，最后产出的也是编出来的 PRD

一句话总结

知道方法论的人很多，能落地的人很少。PM Skills 的价值不是替你思考，而是逼你按方法论的顺序思考。

下次写 PRD、做战略画布、设计访谈脚本之前，可以先让它带你走一遍——你会发现，原来你以为自己想清楚了的事，并没有。