推薦兩個小眾卻值錢的PM Skill
整理版優先睇
推薦兩個PM Skill：pre-mortem幫你上線前拆雷，review-resume幫你求職時唔好寫虧自己
呢篇文章係產品經理邢小作寫嘅，佢最近一直圍繞一個問題：產品經理點樣用Skill令AI真正幫到手，而唔係得個睇字。佢之前寫過好多相關內容，包括點樣用Skills做客戶案例、嵌入工作流、由0到1創建原型Skill等等。佢越寫越肯定一件事：AI嘅價值唔係因為乜都做到，而係可以將本來靠經驗、靠拍腦袋嘅工作拆成可複用嘅能力。
今次佢推薦兩個佢認為最值得先裝上嘅Skill，一個偏工作現場，一個偏職業現場，分別係pre-mortem（預先驗屍）同review-resume（簡歷評審）。呢兩個Skill都嚟自一個好值得留意嘅項目：PM Skills Marketplace（https://github.com/phuryn/pm-skills）。呢個項目唔係單純堆提示詞，而係將好多成熟嘅產品方法論直接做成可調用嘅Skill。作者認為最有價值嘅地方係俾咗你一個好好嘅起點，唔使由空白頁開始焦慮，可以從成熟框架出發再改。
整體結論係：呢兩個Skill可以幫產品經理精準卡住高頻、昂貴、又容易靠經驗拍腦袋嘅場景。pre-mortem逼你喺上線前假設產品已經失敗，倒推出最可能出問題嘅位，避免集體樂觀；review-resume逼你從招聘方角度重新睇自己，將職責型簡歷升級做成果型簡歷。而且佢哋嘅使用門檻低，好快你會發現好多事情可以被結構化處理。
- 推介兩個實用PM Skill：pre-mortem（預先驗屍，上線前假設失敗倒推風險）同review-resume（簡歷評審，從招聘方角度優化表達）
- pre-mortem嘅核心係逼團隊接受「呢個版本已失敗」嘅前提，專注找出失敗路徑，而唔係普通風險分析咁正向
- 用pre-mortem分析「AI虛擬員工」產品時發現真正問題係產品定義太大、底層Skill唔穩定，而唔係模型夠唔夠強
- review-resume幫你將職責型簡歷變成果型簡歷，突出B端信號如複雜業務場景、平台能力、規則拆解，唔好寫得太泛
- 呢兩個Skill嚟自PM Skills Marketplace，你可以直接拎SKILL.md漢化同本土化改造，好過由零開始
PM Skills Marketplace GitHub
一個面向產品經理嘅Skills市場，內含多個成熟產品方法論做成嘅可調用Skill，包括pre-mortem同review-resume
pre-mortem SKILL.md
用於上線前假設失敗倒推風險嘅Skill，原版英文，可按需漢化
review-resume SKILL.md
用於評審產品經理簡歷嘅Skill，提供10條最佳實踐同逐項反饋，適合本土化改造
點解推薦呢兩個Skill
作者邢小作一直研究產品經理點樣用Skill令AI真正幫到手，而唔係得個睇字。佢發現真正有價值嘅Skill係可以將本來靠經驗、靠拍腦袋嘅工作拆成可複用嘅能力。
一個 Skill 值唔值得推薦，唔在於佢個名有幾型，而在於佢能唔能夠精準卡住高頻、昂貴、又容易靠經驗拍腦袋嘅場景
呢兩個Skill——pre-mortem同review-resume——正好滿足呢個條件。佢哋嚟自PM Skills Marketplace，一個將成熟產品方法論直接做成可調用Skill嘅項目。作者強調唔使由零開始，可以直接攞框架再改成適合自己版本。
pre-mortem：上線前拆雷神器
作者用pre-mortem分析咗兩個典型場景。第一個係「AI虛擬員工」產品，結果發現真正問題唔係模型強唔強，而係產品定義太大、底層Skill唔穩定、用戶信任門檻被低估。
普通討論容易停留在「我哋仲可以加啲咩功能」，但pre-mortem會逼你回到產品成敗嘅底層邏輯上
第二個場景係分析一份真實PRD「智能排班三期」，用pre-mortem跑完，即刻暴露出規則優先級冇講清楚、字段容易配錯、錯誤唔會即時暴露等風險。
- 1 幫助區分風險層級：邊啲係真問題，邊啲係團隊未討論透嘅隱憂
- 2 將風險變成可執行動作：追問邊個處理、幾時處理、能唔能夠上線前補掂
- 3 特別適合B端產品經理：因為B端項目規則複雜、鏈路長、角色多、後果重
想用嘅話直接去PM Skills Marketplace攞pre-mortem嘅SKILL.md，複製到自己Skill目錄，再做漢化同本土化就得。作者用Trae自動創建同漢化，好方便。
review-resume：求職時唔好寫虧自己
好多產品經理寫自己嘅時候最唔識表達，明明做咗好多嘢，最後寫成一句「負責某模塊產品設計」。review-resume呢個Skill就係幫你從招聘方角度重新睇自己。
review-resume會強迫你從招聘方嘅視角重新睇自己，發現「唔係冇價值，而係冇將價值講出嚟」
作者用呢個Skill分析自己2022年嘅舊簡歷，即刻發現幾個問題：版本太舊、職業總結似資歷羅列唔像定位清晰嘅Summary、求職意向太泛、整體似職責型簡歷唔似成果型簡歷。
真正該補嘅係B端信號：複雜業務場景、平台型能力、角色權限、配置化能力、規則拆解、跨團隊推進
- 幫你發現自己嘅價值點，將「做過咩」升級做「做成咗咩」
- 幫你做崗位收斂，尤其係冇JD嗰陣，避免寫成大而全
- 唔單止係求職工具，仲係成果表達訓練器，可以用喺晉升材料、年度總結、項目覆盤
使用方式同pre-mortem一樣，攞SKILL.md再漢化本土化。作者建議B端產品經理可以改成「B端產品經理簡歷評審Skill」，專注睇平台產品、複雜業務規則呢類經驗。
比推薦兩個Skill更重要嘅嘢
作者真正想推薦嘅唔只係兩個現成工具，而係背後思路：產品經理完全可以將自己嘅方法論，沿住工作流拆成一組Skills。寫需求文檔、上線公告、評估工作量、設計方案、畫原型、做競品調研都可以係一個Skill。
真正有價值嘅唔係「我又做咗一個Skill」，而係你開始越來越清楚自己工作入面邊啲部分係高頻、邊啲靠經驗、邊啲可以沉澱成標準
PM Skills Marketplace嘅價值係俾咗你一批已經編碼過嘅產品方法論，你唔需要由零開始焦慮點寫一個Skill，而係可以從「我而家邊個場景最需要一個Skill」開始，攞框架、漢化、改造、用真實案例調試。
作者認為呢兩個Skill好適合做「入門樣板」，從佢哋開始可以摸出一條路徑：點樣由現成框架出發改成自己中文版，再改成適合業務同習慣嘅版本。等你跑順咗，再做需求文檔、工作量評估、競品調研甚至Agent，成個思路會順好多。
呢排我其實一路圍住同一個問題嚟寫：產品經理到底要點樣用 Skill，先可以令 AI 真正融入工作，而唔係停留喺「睇落好犀利」嘅階段。
之前傾過點樣用 Skills 做 50 個客戶案例，傾過點樣將 Skills 嵌入產品經理嘅工作流程，亦寫過點樣由 0 到 1 建立一個畫原型嘅 Skill。後尾再專門展開過，點樣將經驗同方法論裝入 Skill 裏面，之後仲補咗幾篇更「反高潮」嘅內容，例如做產品規劃時踩過嘅坑，做競品調研時對 AI 能力嘅誤判。一路寫落嚟，我自己越來越肯定一件事：AI 真正有價值，唔係因為佢乜都做到，而係因為你將嗰啲本來靠經驗、靠拍腦袋、靠臨場發揮嘅工作，慢慢拆成可以重用嘅能力。
但寫到呢度，總會有人追問一句：如果我而家就想開始，唔想由零搞起，有冇啲產品經理值得優先裝嘅 Skill？
有，而且我會優先推薦兩個。一個偏向工作現場，一個偏向職業現場；一個幫你喺上線之前少啲踩坑，一個幫你喺求職嘅時候少啲蝕底。佢哋分別係：pre-mortem 同 review-resume。
更重要嘅係，呢兩個 Skill 唔係我憑空寫出嚟，佢哋都嚟自一個好值得產品經理認真睇嘅項目：PM Skills Marketplace（即https://github.com/phuryn/pm-skills）。
你可以當佢係一個面向產品經理嘅 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 啱啱補咗呢塊。
點樣建立同使用
如果你想直接用，方法其實好簡單。裏面已經有現成嘅 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」，而係你開始越來越清楚：自己嘅工作，到底邊啲部分係高頻嘅，邊啲部分係靠經驗嘅，邊啲部分係可以沉澱成標準嘅。
對我嚟講特別有價值嘅一點，亦喺呢度。佢畀你嘅唔係空白頁，而係一批已經編碼過嘅產品方法論。你唔需要由「我要點樣寫一個 Skill」開始焦慮，而係可以先由「我而家邊個場景最需要一個 Skill」開始。揾到對應嘅框架，拎過來，漢化，改造成自己嘅版本，再用真實案例去調試。呢個過程比由零整一個新框架現實得多，亦更容易出成果。
結合呢段時間踩過嘅坑，我自己而家越來越認同一個好樸素嘅建立方法。先唔好追求一個 Skill 做好多嘢，單一職責永遠更穩；亦唔好迷信 AI 會自己理解你嘅業務，上下文同真實材料始終要你嚟畀；更加唔好一開始就想做一個全能 Agent，先將底層 Skill 打磨穩定，之後先講編排，條路會順好多。
用好一個現成嘅 PM Skill，只係開始；真正重要嘅係，你能唔能夠順住佢學識將自己嘅產品經驗，變成可重用嘅 Skill。
最後想講嘅
如果你最近啱啱想開始做產品經理 Skill，我會真係建議你唔好急住由最宏大嘅話題入手。先裝上 pre-mortem 同 review-resume 呢兩個 Skill，前者幫你練上線前嘅反向判斷，後者幫你練成果表達同崗位視角。一個鍛煉你點樣少犯錯，一個鍛煉你點樣將價值講清楚。
更重要嘅係，佢哋好適合作為「入門樣板」。你由呢兩個開始，唔只係得到兩個可以用嘅工具，更加係摸索一條路徑：點樣由一個現成框架出發，將佢改成自己嘅中文版本，再改成適合自己業務同習慣嘅版本。等你將呢個過程跑順咗，再去做需求文檔、工作量評估、競品調研、產品規劃，甚至再向上做 Agent，成個思路會順好多。
講到底，產品經理做 Skill 呢件事，最有價值嘅地方唔在於「識唔識寫一個 SKILL.md」，而在於你有冇能力將自己嘅判斷、經驗同方法論，沉澱成人哋都可以重用、自己都可以反覆調用嘅能力單元。
你而家手頭上嘅工作入面，有冇邊個環節，其實都好適合做成下一個產品經理 Skill？？
這段時間，我其實一直在圍繞同一個問題往下寫：產品經理到底該怎麼用 Skill，才能讓 AI 真正進入工作，而不是停留在“看起來很厲害”的階段。
前面聊過怎麼用 Skills 做 50 個客戶案例，聊過怎麼把 Skills 嵌進產品經理工作流，也寫過怎麼從 0 到 1 創建一個畫原型的 Skill。後來又專門展開過，怎麼把經驗和方法論裝到 Skill 裏，再往後，還補了幾篇更“反高潮”的內容，比如做產品規劃時踩過的坑，做競品調研時對 AI 能力的誤判。一路寫下來，我自己越來越確定一件事：AI 真正有價值，不是因為它什麼都能做，而是因為你把那些本來靠經驗、靠拍腦袋、靠臨場發揮的工作，慢慢拆成了可複用的能力。
但寫到這裏，總會有人接着問一句：如果我現在就想開始，不想從零折騰，有沒有什麼產品經理值得先裝上的 Skill？
有，而且我會優先推薦兩個。一個偏工作現場，一個偏職業現場；一個幫你在上線前少踩坑，一個幫你在求職時少吃虧。它們分別是：pre-mortem和review-resume。
更重要的是，這兩個 Skill 不是我憑空寫出來的，它們都來源於一個很值得產品經理認真看看的項目：PM Skills Marketplace（即https://github.com/phuryn/pm-skills）。
你可以把它理解成一個面向產品經理的 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正好補的是這塊。
怎麼創建和使用
如果你想直接用，方法其實很簡單。裏已經有現成的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”，而是你開始越來越清楚：自己的工作，到底哪些部分是高頻的，哪些部分是靠經驗的，哪些部分是可以沉澱成標準的。
對我來說特別有價值的一點，也在這裏。它給你的不是空白頁，而是一批已經編碼過的產品方法論。你不需要從“我要怎麼寫一個 Skill”開始焦慮，而是可以先從“我現在哪個場景最需要一個 Skill”開始。找到對應的框架，拿過來，漢化，改造成自己的版本，再用真實案例去調試。這個過程比從零造一個新框架現實得多，也更容易出成果。
結合這段時間踩過的坑，我自己現在越來越認同一個很樸素的創建方法。先別追求一個 Skill 幹很多事，單一職責永遠更穩；也別迷信 AI 會自己理解你的業務，上下文和真實材料還是得你來給；更不要一開始就想做一個全能 Agent，先把底層 Skill 打磨穩定，後面再談編排，路會順很多。
用好一個現成的 PM Skill，只是開始；真正重要的是，你能不能順着它學會把自己的產品經驗，變成可複用的 Skill。
最後想說的
如果你最近正好想開始做產品經理 Skill，我會真的建議你先別急着從最宏大的話題入手。先裝上pre-mortem和review-resume這兩個 Skill，前者幫你練上線前的反向判斷，後者幫你練成果表達和崗位視角。一個鍛鍊你怎麼少犯錯，一個鍛鍊你怎麼把價值講清楚。
更重要的是，它們很適合作為“入門樣板”。你從這兩個開始，不只是得到兩個能用的工具，更是在摸一條路徑：怎麼從一個現成框架出發，把它改成自己的中文版本，再改成適合自己業務和習慣的版本。等你把這個過程跑順了，再去做需求文檔、工作量評估、競品調研、產品規劃，甚至再往上做 Agent，整個思路會順很多。
說到底，產品經理做 Skill 這件事，最有價值的地方不在於“會不會寫一個SKILL.md”，而在於你有沒有能力把自己的判斷、經驗和方法論，沉澱成別人也能複用、自己也能反覆調用的能力單元。
你現在手裏的工作裏，有沒有哪個環節，其實也很適合被做成下一個產品經理 Skill？