AI工具正重塑产品经理的工作方式，但如何让Skills真正融入工作流而非沦为花哨噱头？本文深度解析两个实战型Skills：pre-mortem帮你在上线前精准排雷，review-resume助你将职业价值结构化呈现。更关键的是，它们来自PM Skills Marketplace这个产品方法论宝库，教你如何将经验沉淀为可复用的能力模块。

这段时间，我其实一直在围绕同一个问题往下写：产品经理到底该怎么用 Skill，才能让 AI 真正进入工作，而不是停留在“看起来很厉害”的阶段。

前面聊过怎么用 Skills 做 50 个客户案例，聊过怎么把 Skills 嵌进产品经理工作流，也写过怎么从 0 到 1 创建一个画原型的 Skill。后来又专门展开过，怎么把经验和方法论装到 Skill 里，再往后，还补了几篇更“反高潮”的内容，比如做产品规划时踩过的坑，做竞品调研时对 AI 能力的误判。一路写下来，我自己越来越确定一件事：AI 真正有价值，不是因为它什么都能做，而是因为你把那些本来靠经验、靠拍脑袋、靠临场发挥的工作，慢慢拆成了可复用的能力。

但写到这里，总会有人接着问一句：如果我现在就想开始，不想从零折腾，有没有什么产品经理值得先装上的 Skill？

有，而且我会优先推荐两个。一个偏工作现场，一个偏职业现场；一个帮你在上线前少踩坑，一个帮你在求职时少吃亏。它们分别是：pre-mortem 和 review-resume。

更重要的是，这两个 Skill 不是我凭空写出来的，它们都来源于一个很值得产品经理认真看看的项目：PM Skills Marketplace。

你可以把它理解成一个面向产品经理的 Skills 市场，里面不是单纯堆提示词，而是把很多成熟的产品方法论直接做成了可调用的 Skill。对我来说，它最有价值的地方不在于“现成”，而在于它给了你一个非常好的起点：你不用再从空白页开始焦虑“一个 Skill 到底该怎么写”，而是可以先从成熟框架出发，再改成适合自己的版本。

为什么我先推荐这两个

如果你现在就问我，产品经理最该先装哪两个 Skill，我不会先推荐写 PRD，也不会先推荐画原型。

我会先推荐 pre-mortem 和 review-resume。原因很简单。前者帮你少把产品做砸，后者帮你少把自己写亏。一个服务于工作现场，一个服务于职业现场；一个卡在“上线前最容易集体乐观”的节点，一个卡在“求职时最容易自我表达失真”的节点。

更重要的是，这两个 Skill 都不是那种“看起来很厉害，但很难融进日常工作”的类型。相反，它们的使用门槛很低，可一旦真正用起来，你很快就会发现：原来很多本来靠经验、靠开会、靠反复沟通的事情，是可以被结构化处理的。

一个 Skill 值不值得推荐，不在于它名字多酷，而在于它能不能精准卡住那些高频、昂贵、又容易靠经验拍脑袋的场景。

第一个Skill：pre-mortem，适合在上线前拆雷

先说 pre-mortem。如果直译，它大概叫“预先验尸”，听起来有点重，但意思非常准确。它不是让你在项目失败后写复盘，而是让你在上线前，先假设它已经失败了，然后倒推：到底会因为什么失败。

你可能会觉得，这不就是风险分析吗？还真不完全一样。普通的风险分析，很多时候还是顺着项目往下讲，大家更容易停留在“功能做完了没有”“测试过了没有”“排期有没有风险”这种层面。pre-mortem 的狠劲在于，它逼你先接受一个前提：这个版本已经上线了，但结果不理想，客户没买单，团队也很被动。既然如此，那最可能出问题的地方到底在哪里？

这一步看起来只是换了个问法，但对产品经理来说，差别非常大。因为很多时候，团队不是没有讨论风险，而是讨论得太表面、太正向，最后所有人都在“推进上线”，却没人认真去想“失败路径”。

我是怎么用它的

今天我就拿它跑过两个很典型的场景。

第一个，是一款“AI 虚拟员工”产品。这个产品如果顺着常规方式讲，很容易一路讲到 Agent、多角色协同、统一入口、自动执行，听起来特别像未来。但把 pre-mortem 一跑，最先暴露出来的问题根本不是模型强不强，而是更底层的几个判断：产品定义是不是太大了，讲的是“虚拟员工”的大故事，卖的却只是一个不够稳定的功能集合；有没有真的从角色工作流出发，把招聘专员、考勤专员、客服专员这些岗位拆清楚；底层 Skill 稳不稳定，如果不稳定，越往上做 Agent，风险只会越大；用户愿不愿意把关键工作交给它，信任门槛到底有没有被低估。

你会发现，这种分析和普通讨论完全不一样。普通讨论容易停留在“我们还能加什么功能”，但 pre-mortem 会逼你回到产品成败的底层逻辑上。

第二个场景，是我今天拿它分析的一份真实 PRD，就是“智能排班三期：大小周 / 上N天休W天”那份需求文档。这个需求本身并不小，规则非常复杂，涉及多周循环、按天循环、节假日、公休日、覆盖已有排班、按方案和按班组两条入口。你如果只是普通评审，很容易陷进细节里，一条一条看字段规则，看着看着就忘了真正的风险在哪里。

但用 pre-mortem 跑一遍，几个关键问题一下就冒出来了。最典型的一个，是规则优先级没有被“算法级”讲清楚。单看每条规则都能理解，可一旦把多周循环、按天循环、节假日、公休日、顺延、跳过、覆盖这些逻辑叠起来，真实执行顺序到底是什么？这如果不提前讲死，后面很容易出现“产品以为是这样，研发理解成那样，测试又按第三种方式测”的情况。

另一个很狠的问题，是“第一天开始日期 / 第一周开始日期 / 开始日期”这种字段，对用户来说特别容易配错。产品文档里给了很多提示语，看起来很贴心，但反过来说，这也说明它本身的认知门槛很高。你只要选错一天，系统排出来的班可能逻辑上是对的，业务上却是错的。更麻烦的是，这类错误通常不是当场就会暴露，而是等考勤、排班、休假甚至薪资环节出问题，大家才回头追。

这就是 pre-mortem 真正值钱的地方。它不是帮你罗列一堆泛泛的风险，而是帮你在上线前，把那些最容易被“集体乐观”掩盖掉的关键问题提前翻出来。

它好在哪里

如果只说“帮你识别风险”，这还是太虚。它真正的优势，我觉得有三点。

第一，它能帮你区分风险层级。哪些是真问题，哪些只是大家会担心但优先级没那么高，哪些是团队其实还没讨论透的隐忧。这个区分非常重要，因为很多项目最后不是死在没有风险，而是死在所有风险都被混在一起，导致什么都没有真正处理。

第二，它能把风险变成动作。不是停留在“这个有问题”，而是继续往下追：这个问题谁来处理，什么时候处理，能不能在上线前补掉。这样它才不是一个会议上的观点，而是一份能推动团队行动的材料。

第三，它特别适合 B 端产品经理。因为 B 端很多项目，不是页面复杂，而是规则复杂、链路长、角色多、后果重。你少想一个边界，最后可能不是一个提示文案错了，而是实施、客服、客户信任和后链路一起出问题。pre-mortem 正好补的是这块。

怎么创建和使用

如果你想直接用，方法其实很简单。PM Skills Marketplace 里已经有现成的 pre-mortem，你只需要把对应的 SKILL.md 拿过来，复制到自己的 Skill 目录里，再根据自己的业务语境做一点汉化和本土化改造就行。

原地址：https://github.com/phuryn/pm-skills/blob/main/pm-execution/skills/pre-mortem/SKILL.md

我是直接用Trae把对应连接给它，让它直接帮我自动创建Skill，并完成汉化。

第二个Skill：review-resume，适合在求职时防止把自己写亏

再说 review-resume。

我知道很多产品经理看到这个名字，第一反应会觉得它偏求职工具，和产品工作没那么近。但我反而觉得，它特别适合产品经理，甚至是那种“越有经验的人，越应该早点用”的 Skill。

因为产品经理平时最常做的一件事，就是帮别人把复杂问题说清楚。写方案、写需求、写路径、做汇报，大家都很熟。但轮到写自己，很多人反而最不会表达。项目做了不少，最后写成一句“负责某模块产品设计”；带过团队，最后写成一句“协同推进项目上线”；明明做成过关键结果，最后却写得像一份岗位职责说明书。

说得直白一点，很多产品经理不是没有经历，而是不会把自己的经历写成“招聘方看得懂、记得住、愿意继续聊”的价值表达。

我是怎么用它的

今天我就拿它看了我自己一份很老的简历，是 2022 年版本的《邢小作-资深产品经理》。如果只是自己看，你很容易有一种错觉：经历不少，带过团队，也有一些数据，看起来还可以。

但 review-resume 一跑，有几个问题一下就被点出来了，而且都不是那种“表面优化”，而是会直接影响投递效果的问题。

第一个问题，是版本太旧。文件名还是 2022 年，如果这是你现在拿出去投的版本，那别的地方再好也会先吃亏。因为招聘方最先关心的是：你最近几年在做什么，有没有新项目，有没有新结果。简历一旧，别人默认你信息没更新。

第二个问题，是职业总结写得太像资历罗列，不像定位清晰的 Summary。比如“4年C端经验 + 4年B端经验”这种信息当然有价值，但它更像在陈列履历，而不是主动告诉招聘方：你到底适合什么岗位，你最强的价值点是什么。

第三个问题，是求职意向太泛。像“资深产品经理 / 产品专家”这种写法，看起来没错，但对 B 端岗位来说太宽了。招聘方不会帮你做选择，他们只会觉得你定位不够清楚。真正更好的写法，其实是收窄，比如明确成“资深B端产品经理”“平台型产品经理”“HR SaaS产品经理”这类方向。

第四个问题，是简历整体更像职责型简历，而不是成果型简历。也就是说，它会让人知道你做过很多事，但不一定能立刻知道你做成过什么。这对产品经理是很吃亏的。因为产品经理岗位不是只看你干没干活，而是看你有没有判断、有没有推进、有没有带来结果。

后面我又顺着“B 端产品经理”这个方向继续收敛了一版建议，马上就能看出来，真正该往简历里补的，不是什么更华丽的词，而是那些更像 B 端的信号：复杂业务场景、平台型能力、角色权限、配置化能力、规则拆解、跨团队推进、业务落地。这些东西一旦被明确写出来，整份简历的方向感就会完全不一样。

它好在哪里

review-resume 的好，不是“帮你润色几句”，而是它会强迫你从招聘方的视角重新看自己。

第一，它能帮你发现你不是没有价值，而是没有把价值说出来。这对产品经理特别重要，因为很多 PM 的问题不是经历少，而是表达太像流水账。

第二，它能帮你做岗位收敛。尤其是你现在没有 JD 的时候，人很容易写成一个“大而全”的自己，结果什么都写了，什么都不突出。review-resume 会逼你问自己：如果我要投 B 端，那我的简历里，什么应该放大，什么应该收一收。

第三，它其实不只是求职工具，也是一个“成果表达训练器”。你今天拿它改简历，明天也可以拿它改晋升材料、年度总结、项目复盘，甚至帮团队新人梳理项目经历。因为它训练的不是排版，而是产品经理非常核心的一项能力：你能不能把自己做成的事情，结构化地讲清楚。

所以它真正值钱的地方，不是帮你找工作，而是帮你把“我做过什么”升级成“我做成了什么”。

怎么创建和使用

和 pre-mortem 一样，review-resume 也来自 PM Skills Marketplace。原版已经给了很完整的结构，包括开场、10 条最佳实践、逐项反馈和结尾总结。你真正要做的，不是从零写，而是做两层改造。

原地址：https://github.com/phuryn/pm-skills/blob/main/pm-toolkit/skills/review-resume/SKILL.md

第一层是汉化，把那些更偏英文简历语境的表达，改成中文产品经理更能用的语言。第二层是本土化，比如你可以继续往前补上 B端 / C端 简历写法差异，或者区分 校招 / 转岗 / 3-5年产品经理 / 资深产品经理 的不同标准。这样它出来的结果，就不会只是“翻译过来的简历建议”，而更像一个真正懂国内 PM 求职市场的人在给你反馈。

如果你是做 B 端的，我甚至建议你再往前走一步，把它改成一个“B 端产品经理简历评审 Skill”。这样它在看简历的时候，就会更主动去找你有没有平台产品、复杂业务规则、角色权限、配置化能力、跨团队推进这些经验，而不是只从一个通用简历视角去看。

比推荐两个Skill更重要的，是学会怎么创建产品经理Skill

如果文章只停在“我推荐你装这两个 Skill”，其实还是不够。因为我真正想推荐给你的，不只是两个现成工具，而是背后的思路：产品经理完全可以把自己的方法论，沿着工作流拆成一组 Skills。

我前面几篇文章其实都在讲这件事。写需求文档可以是一个 Skill，写上线公告可以是一个 Skill，评估工作量是一个 Skill，设计产品方案是一个 Skill，画原型是一个 Skill，做竞品调研也可以是一个 Skill。你一路写下来会发现，真正有价值的不是“我又做了一个 Skill”，而是你开始越来越清楚：自己的工作，到底哪些部分是高频的，哪些部分是靠经验的，哪些部分是可以沉淀成标准的。

PM Skills Marketplace对我来说特别有价值的一点，也在这里。它给你的不是空白页，而是一批已经编码过的产品方法论。你不需要从“我要怎么写一个 Skill”开始焦虑，而是可以先从“我现在哪个场景最需要一个 Skill”开始。找到对应的框架，拿过来，汉化，改造成自己的版本，再用真实案例去调试。这个过程比从零造一个新框架现实得多，也更容易出成果。

结合这段时间踩过的坑，我自己现在越来越认同一个很朴素的创建方法。先别追求一个 Skill 干很多事，单一职责永远更稳；也别迷信 AI 会自己理解你的业务，上下文和真实材料还是得你来给；更不要一开始就想做一个全能 Agent，先把底层 Skill 打磨稳定，后面再谈编排，路会顺很多。

用好一个现成的 PM Skill，只是开始；真正重要的是，你能不能顺着它学会把自己的产品经验，变成可复用的 Skill。

最后想说的

如果你最近正好想开始做产品经理 Skill，我会真的建议你先别急着从最宏大的话题入手。先装上 pre-mortem 和 review-resume 这两个 Skill，前者帮你练上线前的反向判断，后者帮你练成果表达和岗位视角。一个锻炼你怎么少犯错，一个锻炼你怎么把价值讲清楚。

更重要的是，它们很适合作为“入门样板”。你从这两个开始，不只是得到两个能用的工具，更是在摸一条路径：怎么从一个现成框架出发，把它改成自己的中文版本，再改成适合自己业务和习惯的版本。等你把这个过程跑顺了，再去做需求文档、工作量评估、竞品调研、产品规划，甚至再往上做 Agent，整个思路会顺很多。

说到底，产品经理做 Skill 这件事，最有价值的地方不在于“会不会写一个 SKILL.md”，而在于你有没有能力把自己的判断、经验和方法论，沉淀成别人也能复用、自己也能反复调用的能力单元。

你现在手里的工作里，有没有哪个环节，其实也很适合被做成下一个产品经理 Skill？