夜雨聆风让它写 PRD，它会写；让它做竞品分析，它会做；让它拆用户反馈，它也能拆。但真正影响工作质量的，不是“能不能生成一段文字”，而是它有没有按照产品工作的框架去想：先问什么、怎么拆假设、如何排序风险、拿什么证据做决策、上线前怎么验收。
这就是 pm-skills 值得关注的地方。
它不是又一个“万能提示词合集”，而是一套给 PM 使用的 Agent 技能市场。根据官方 README 和 Product Compass 在 2026 年 6 月 5 日发布的 v2.0 说明，当前版本覆盖 9 个插件、68 个 PM skills、42 个串联工作流，范围从 discovery、strategy、execution、analytics、GTM、growth，一直到这次新增的 AI Shipping Kit。
真正的信号不是“PM 可以少写文档了”。真正的信号是：PM 可以把自己反复使用的方法，装进 AI 的工作流里。
1. 先理解三个概念：Skill、Command、Plugin
Skill 是方法。比如假设识别、机会解决方案树、优先级框架、用户访谈脚本、A/B 测试分析。它会告诉 AI：这类问题应该按什么框架推理，输出时要给哪些字段，哪些地方要提醒用户验证。
Command 是流程。比如 /discover 会串起发散方案、识别假设、排序假设、设计实验。它不是一个提示词，而是一段 PM 工作流。
Plugin 是场景包。比如 pm-product-discovery 面向发现，pm-execution 面向 PRD 和迭代，pm-ai-shipping 面向 AI 写出来的代码如何被人类验收。
图 1：先决定你在哪个工具里工作，再按场景安装整套插件，避免只挑单个 Skill 导致流程缺环。
2. 安装方式：不同入口，适合不同人
如果你不写代码，优先用 Claude Cowork。官方路径是：打开左下角 Customize，进入 Browse plugins -> Personal -> +，选择 Add marketplace from GitHub，然后输入：
phuryn/pm-skills如果你经常在代码仓库里工作，用 Claude Code：
claude plugin marketplace add phuryn/pm-skills claude plugin install pm-toolkit@pm-skills claude plugin install pm-product-strategy@pm-skills claude plugin install pm-product-discovery@pm-skills claude plugin install pm-market-research@pm-skills claude plugin install pm-data-analytics@pm-skills claude plugin install pm-marketing-growth@pm-skills claude plugin install pm-go-to-market@pm-skills claude plugin install pm-execution@pm-skills claude plugin install pm-ai-shipping@pm-skills如果你用 Codex，也可以装：
codex plugin marketplace add phuryn/pm-skills codex plugin add pm-toolkit@pm-skills codex plugin add pm-product-strategy@pm-skills codex plugin add pm-product-discovery@pm-skills codex plugin add pm-market-research@pm-skills codex plugin add pm-data-analytics@pm-skills codex plugin add pm-marketing-growth@pm-skills codex plugin add pm-go-to-market@pm-skills codex plugin add pm-execution@pm-skills codex plugin add pm-ai-shipping@pm-skills关键差异是：Codex 可以读取这些插件里的 Skill，slash command 不会像 Claude Code 那样直接作为 /discover、/write-prd 运行。更自然的用法，是把命令背后的步骤说成自然语言。
Codex 示例：请基于 pm-product-discovery 的方法，对这个产品想法做 discovery：先发散方案，再识别关键假设，再按影响和风险排序，最后给出本周可做的实验。每一步完成后先暂停，等我确认。 |
3. 第一个必试场景：用 /red-team-prd 攻击你的 PRD
pm-skills v2.0 最值得先试的，是 pm-execution 里的 /red-team-prd。普通评审会上，大家常常会给“礼貌反馈”。真正会把项目拖进坑里的假设，往往没有在会议上被清楚说出来。
你可以这样输入：
/red-team-prd 我们计划优先做 AI 新手引导，因为当前增长瓶颈是激活率。 目标是在下个版本把新用户首日激活率提升 15%。你希望它输出的不是“风险很多，请谨慎”，而是这种结构：
Claim：激活率是增长瓶颈。 Fails if：真正流失发生在激活后的次日留存，而不是首日激活。 Evidence：拉最近 3 个 cohort 的激活到留存漏斗。 Cheapest test：半天内先做漏斗拆解，不需要开发。
图 2：红队不是为了显得聪明，而是把最可能伤害项目的假设转成低成本验证动作。
我建议把 /red-team-prd 放在三个节点使用：路线图评审前、PRD 初稿完成后、排期前。如果某个需求的核心假设都没有证据，却已经开始排研发资源，那它不是需求成熟，而是风险被包装成了计划。
4. 第二个必试场景：用 AI Shipping Kit 做发版检查
现在越来越多产品原型、内部工具、自动化流程，是 AI 或 Agent 直接写出来的。问题是：AI 写代码很快，但它不一定留下足够的意图记录。
系统到底应该做什么？谁有权限做什么？环境变量和密钥在哪里？哪些规则真的被测试覆盖？这些问题如果没人记录，最后就会变成一句危险的话：“AI 说它已经好了。”
pm-ai-shipping 包含两个核心 Skill：shipping-artifacts 和 intended-vs-implemented，以及五个命令：/document-app、/security-audit-static、/performance-audit-static、/derive-tests、/ship-check。
图 3：AI Shipping Kit 的关键不是替 PM 审代码，而是把“意图、实现、测试、风险”对齐成可验收证据。
/ship-check ./my-ai-built-app 请先整理系统文档，再检查实现和文档是否一致。 重点看：权限、环境变量、用户数据、定时任务、测试覆盖和上线前需要人工确认的风险。5. 一周内可以这样用
第一步：用 /discover 或 discovery prompt 处理想法。目标不是“想出 20 个功能”，而是找到最该验证的前 3 个假设。
第二步：用 /write-prd 写第一版 PRD。把目标、用户、场景、约束、非目标和验收标准说清楚。
第三步：用 /red-team-prd 攻击 PRD。哪些假设一旦错了，代价最大？哪些证据本周就能拿到？哪些需求应该先缩小范围？
第四步：有代码后用 /ship-check 做发版包。不是为了证明 AI 写得多快，而是为了证明这个东西为什么可以被人类负责地上线。
6. 使用反馈里最常见的坑
不要只装一个看起来有用的 Skill。很多 workflow 依赖同一插件里的多个 Skill。官方 README 也建议按插件安装，而不是只挑单个 Skill。
slash command 不是所有工具都通用。Claude Code 和 Cowork 里的命令很顺手；到了 Codex、Cursor、Gemini CLI、OpenCode 这类环境，通常是 Skill 可用，command 不一定以 slash 形式运行。
工具 UI 会变，安装路径以 README 为准。GitHub Issue 里有人提到 Claude Cowork 的界面更新后，旧教程入口不完全一致。遇到这种情况，先回到仓库 README 和最新 release。
pm-skills 给的是方法，不是你的业务上下文。没有真实数据、用户反馈、产品约束，它只能给通用建议。建议在项目根目录准备 product-context、roadmap、metrics、decisions、constraints 这类文档，让红队和发版检查更贴近真实约束。
7. 直接可用的三段提示词
需求发现： 请用 pm-product-discovery 的方法处理这个产品想法： [贴你的想法] 依次输出目标用户、使用场景、可能方案、关键假设、风险排序和本周可做的最低成本实验。PRD 红队： 请用 pm-execution 的 red-team-prd 方法审视这份 PRD： [贴 PRD 或路线图] 只输出真正会伤害项目的 5 个 kill-assumptions。 每个假设必须包含 Claim、Fails if、Evidence、Cheapest test。发版检查： 请用 pm-ai-shipping 的方法检查这个 AI 写出来的项目： [贴仓库路径或关键文件说明] 先整理系统意图，再检查实现差异。 重点看权限、密钥、数据流、测试覆盖、安全与性能。 最后输出一份上线前人工签字清单。结尾：别把 AI 当写稿机器，要把它训练成工作流
pm-skills 的价值，不是让 PM 显得更会用 AI。它真正有用的地方，是把产品工作里那些原本靠经验、靠师傅带、靠反复踩坑才形成的方法，变成 Agent 可以调用的结构。
当你会安装 Skill、组合 workflow、补充业务上下文、要求证据验收，AI 才不只是聊天助手。它开始变成你的第二个产品工作台。
人人会AI-智能体进阶 不是追每一个新工具，而是把工具变成方法，把方法变成流程，把流程变成你自己的 AI 工作系统。 |
参考资料：Product Compass《PM Skills 2.0: Red-Team Your Roadmap, Then Check the Code Before You Ship》；GitHub phuryn/pm-skills README；phuryn/pm-skills 公开 Issue；Awesome Skills、ClaudePluginHub 等第三方目录。
