你要是天天被"这个需求到底该不该做"这种问题卡住，答案其实不在于多写一份PRD模板，而是把需求分析拆成五个环节，每个环节配一个Skill来跑。这篇就聚焦需求分析这一个高频场景，把PM Skills Marketplace里能用的东西掰开讲清楚。
别一上来就找"万能PRD Skill"
产品经理真正难的，往往不是不知道PRD格式，而是不知道这个需求该不该做、问题有没有证据、第一版范围怎么收、评审前还有哪些风险没暴露。所以更实用的方式，是按需求分析的过程，把Skill放到不同环节里用：一个负责澄清问题，一个负责整理证据，一个负责收敛范围，一个负责审查风险，最后一个负责设计指标。这样比"帮我写一份PRD"更接近产品经理真实工作。
安装方式先说清楚
这个项目提供的是一组插件包和命令式工作流，不是只能复制提示词。Claude Code里可以先添加marketplace再装插件，命令依次是：claude plugin marketplace add phuryn/pm-skills，然后claude plugin install pm-product-discovery@pm-skills，claude plugin install pm-market-research@pm-skills，claude plugin install pm-execution@pm-skills，claude plugin install pm-data-analytics@pm-skills。 Codex CLI用户也能用同一个marketplace，把命令换成codex plugin marketplace add phuryn/pm-skills，装包时用codex plugin add pm-product-discovery@pm-skills，其余三个包同理替换即可。需求分析这条线，先看这四个包就够：pm-product-discovery管问题和假设，pm-market-research管用户和市场证据，pm-execution管PRD、用户故事和验收标准，pm-data-analytics管指标和验证。战略、增长、GTM这些包先放一边，不急着用。
第一步：先澄清问题，别急着写方案
需求刚出现时最容易犯的错是直接写方案。比如业务方说"我们也做个会员体系吧，竞品都有"，普通AI很容易顺手写出会员等级、积分商城、权益中心一整套东西，看着挺完整，但最关键的问题——为什么要做会员，是留存下降还是付费转化低——还没回答。这时候该用pm-product-discovery里的需求澄清能力，对应problem framing、assumption mapping这类Skill，先问清楚背后可能是什么用户问题、哪些判断只是团队假设、哪个假设一旦错了整个需求就不该继续。Claude Code里的/discover工作流就是这个思路，换成普通对话也可以直接让AI"先不要写PRD，帮我做一次需求澄清"，列出用户问题、当前假设、优先验证的假设和低成本验证方式。这一步的价值就是让团队先停一下，别把"有人提了个功能"当成"已经确认了需求"。 第二步：拉用户证据进来，别靠脑补
需求分析不能只靠推理，pm-market-research里的用户访谈、反馈归类相关Skill适合处理客服记录、问卷、App评论这类材料。产品经理经常说"用户希望我们做这个"，评审时一被追问就容易变成几条零散印象。这类Skill分两个方向用：访谈前，把需求假设翻译成访谈问题，比如不直接问"你愿意买会员吗"，而是问用户现在怎么解决这个问题；访谈后做反馈归类，但一定要求引用原文，每个结论至少引用2条原始反馈，并区分"用户明确说了什么"和"我们推断出来的需求"，这样才能把"我感觉用户需要"变成"这些用户在这些场景下反复遇到这个问题"。
第三步：写PRD只写MVP，别大而全
问题和证据清楚之后才轮到pm-execution出场，对应write PRD、user stories、acceptance criteria这类Skill。前提是不能让AI凭空写——如果输入只有一句"做会员体系"，AI只能靠常识补全，写出来的东西看着完整但没有业务判断。正确做法是把前两步的结果当输入，要求AI明确"本期必须做/本期不做/后续再看"，并对所有假设信息标注"待确认"。这组Skill最重要的产出不是"本期要做什么"，而是"本期不做什么"，很多PRD失败就是因为默认什么都能顺手加一点，会员体系写着写着就长出积分商城、任务系统、等级勋章。
第四步：评审前让AI专门反对你
红队评审类Skill值得长期保留，类似/red-team-prd这样的工作流，任务不是帮你润色，而是站在反方检查：最脆弱的假设是什么、如果失败最可能失败在哪、哪个前提没有证据。可以把PRD初稿丢进去，只要求它找问题不改写，找出最危险的5个假设、缺少证据支撑的判断、可能被研发设计运营挑战的地方，以及评审前必须补充的材料清单。真正好的评审不是把措辞改得更专业，而是提前发现方案可能根本不成立的地方。
第五步：别让需求停在"提升体验"
很多需求分析写到最后会落在一句很虚的话上——提升用户体验、增强粘性。这话不是不能写，但没有指标就很难判断需求是否真的有效。接pm-data-analytics里的指标设计Skill，给出1个核心指标、3个辅助指标、2个反指标，说明上线后7天、14天、30天分别看什么，如果数据没改善列出可能原因和排查路径。这组Skill把需求分析从"方案讨论"拉回"结果验证"，产品经理最需要防的不是需求做不出来，而是做出来以后没人知道它到底有没有用。
这五步分别对应pm-product-discovery（需求澄清）、pm-market-research（用户证据）、pm-execution（PRD和红队评审，用两次）、pm-data-analytics（指标设计），串起来是一条从模糊需求到可评审方案的闭环，但AI只负责提出假设、整理材料、找风险，哪些需求值得做、哪些范围必须砍掉，最后仍然得由你自己判断。别把Skill当成更聪明的模板库，输入一句需求输出一份文档格式齐全但没解决真问题——先从一个真实需求开始，拆成问题、证据、范围、风险、指标五段，给每段配一个Skill，你会发现AI真正帮上的忙，是让你更早发现这个需求到底有没有想清楚。
AI 速览
