如何用 Skills高效完成產品經理的工作？

AI 工具如何徹底改變產品經理的工作流？本文深度拆解從需求文檔撰寫到上線公告、工作量評估及產品方案設計的四大核心場景，揭示如何通過 Skills 將經驗固化為可復用的能力模塊。

———— / BEGIN / ————

在之前的文章里，曾提到過用 AI 提效的“三步曲”。

第一步，是把 AI 當搜索引擎，效率大約提升 10%。這一步很多人已經很熟了，用豆包、DeepSeek 之類的工具查資料、找答案，確實比傳統搜索更快，但提升往往有限。

第三步，是把 OpenClaw 當作“實習生”來用，效率可能直接翻倍，但對應的時間成本、學習成本和經濟成本也不低。它更像是一種更徹底的工作方式改造，不太適合大多數人一上來就直接進入。

真正值得大多數產品經理認真做的，其實是第二步：用合適的 AI 工具，把自己的工作流拆解成原子化的 Skills。

今天繼續沿著這個主題往下走，不過這次不講客戶案例，而是回到產品經理最日常、也最真實的工作場景里，聊聊一件更重要的事：

如何用 Skills，高效完成產品經理的工作？

如果你是做 B 端產品的，對下面這條工作流應該不會陌生：需求管理、需求優先級判斷、產品規劃、競品調研、客戶需求調研、設計產品方案、評估工作量、繪制原型、寫 PRD、評審、項目管理、上線、上線培訓、寫上線公告、收集反饋……

看上去每個環節都重要，但真正要下手改造時，千萬別想著一口氣全做完。改變工作流從來不是一件容易的事，更不是裝一個工具、寫幾句提示詞就能立刻見效。

更現實的做法是：先僵化，再固化，然后再優化。

說白了，就是先挑那些高頻、重復、相對標準化的環節，固定下來反復用，等跑順了，再慢慢擴大范圍。別一上來就想“重構整個產品經理工作方式”，那樣大概率只會把自己折騰累。

以自己的實踐為例，真正把“寫需求文檔”和“寫上線公告”這兩個環節改造出來，前后差不多花了一年多。到現在，這兩個環節基本已經穩定下來了。日常需求文檔，通常先由 AI 生成，再做人工調整。如果是 1 到 2 周的小需求，調整量大概在 5% 到 10%；如果是 2 到 4 周的中等需求，改動量一般在 10% 到 20%；大型項目的變動會更高，通常在 30% 到 50%。

這里有一個非常真實的規律：你給 AI 的上下文越完整，最后需要改的內容就越少。

后來又花了近半年時間，把“評估工作量”和“設計產品方案”這兩個環節調到可用狀態。前者幫忙處理每周 2 到 5 個客戶需求的工作量評估，后者更像一個隨時能討論思路的“軍師”，在方案設計上提供結構化支持。

最近還在持續調試的是“需求價值判斷”和“競品調研”兩個環節。一個用來避免陷入自嗨，更客觀地看待需求價值和優先級；另一個用來更高效地收集競品信息，尤其是相關需求的解決思路。

下面，就結合這幾個真實案例，講講 Skills 到底怎么嵌進產品經理的工作流里。

Case 1：怎么用 AI 寫一份專屬的需求文檔？

最開始用的工具，其實不是 Skills，而是智譜清言的自定義智能體。后來逐漸轉向 Trae 的智能體，再到扣子的 Skills，現在基本穩定在 Trae + Skills這套組合上。

如果你現在才開始，不想繞太多彎路，我反而更建議你直接用 Skills，而不是從自定義智能體起步。原因很簡單：Skills 更穩定、更可控，也更靈活。

智能體早期最大的問題，是每次都得先切換入口。寫需求文檔要進“B 端需求文檔助理”，寫上線公告又要換“B 端上線公告助理”。

更麻煩的是，效果并不總穩定。尤其當提示詞變長、格式要求變復雜時，經常會出現偏差。比如明明要求“一個需求對應一條需求清單”，最后卻常常被拆成 3 到 5 條。

現在換成Trae + Skills之后，體驗就順了很多。入口其實還是同一個，只是通過前綴告訴它這是“需求文檔”還是“上線公告”，輸出的結構和質量基本就比較穩定了。

很多人會問，能不能直接把現成的 Skills 拿去用。坦白說，這種想法很正常，但意義不大。

因為每家公司、每個團隊，甚至每個產品經理，對需求文檔模板的定義都不一樣。你真正需要的，不是一份別人現成的 Skills，而是知道怎么做出自己的專屬 Skills。

這件事的核心，無非三步。

第一，你要有一個能幫你寫 Skills 的工具。第一次上手的話，扣子編程里的“技能”或者 Trae 都可以，門檻不高，直接用自然語言告訴它：“幫我創建一個寫需求文檔的 Skills”，再補充背景、文檔格式和注意事項，它就能先搭一個雛形出來。

第二，你得先定義清楚，什么叫一份“好的需求文檔”。這個標準非常重要，因為 Skills 最終輸出的穩定性，不是來自模型本身，而是來自你對格式和標準的定義。你給得越清楚，它越容易穩定。

第三，反復調試，直到結果符合預期。寫 Skills 很像做一個小項目，不可能一次就對。你得像調產品一樣，一輪輪試、一輪輪改，不斷把它往你的標準上拉。

最終形成的，通常不只是一個簡單的提示詞，而是一套更完整的文檔結構。核心一般包括SKILL.md和format-template.md。前者負責說明這個技能的目標、觸發時機、格式要求和注意事項，后者負責嚴格定義格式和示例。

如果你能把第一個需求文檔 Skills 跑通，后面的很多事其實就開始通了。因為你會突然意識到，原來工作里很多原本靠經驗和手感完成的環節，都是可以被拆出來、定義出來、再固化下來的。

Case 2：怎么用 AI 寫上線公告？

上線公告其實是很適合 Skills 化的一個環節。

它的特點很典型：高頻、重復、格式相對固定，而且只要結構清楚，AI 的完成度通常就會很高。你把第一個 Skills 做出來之后，后面做上線公告，整個過程會明顯輕松很多，本質上就是不斷“復制、粘貼、優化”。

上線公告最關鍵的，不是語言有多華麗，而是信息結構要穩定。發布對象是誰、更新了什么、影響哪些用戶、操作路徑是什么、注意事項有哪些，這些都要提前定義清楚。只要結構定住，后面就好辦了。

真正要做的，依然是反復調試。讓它輸出出來的內容，越來越貼近你所在公司的真實公告風格，而不是一個“看起來正確”的通用模板。

當這個環節穩定之后，你會明顯感覺到，寫上線公告不再是一件要重新組織思路的事，而更像是“填充上下文，再快速確認”的過程。生成后貼進用戶中心，稍微調整下語氣和細節，通常就能直接發布。

這類工作以前很容易被低估，覺得只是寫一篇公告而已。但真正做久了你會發現，正是這種高頻、事務性、又不太復雜的環節，最適合優先用 Skills 改造。因為一旦跑順，幾乎每周都能立刻回收效率。

Case 3：怎么用 AI 評估工作量？

如果說前兩個案例更像是“怎么做”，那工作量評估更值得聊的是“為什么做”，以及“做的時候最容易踩什么坑”。

做 SaaS 產品的人對這個場景應該都不陌生。很多客戶需求排不上標準版本時，就會問能不能付費定制。這時候，產品經理通常要先給一個工作量評估，作為客戶是否繼續推進的依據。

問題在于，這件事很尷尬。

你如果隨口說個 10 人天，客戶大概率會追問依據；你如果認真拉人評估，又會發現很耗時間，因為超過 90% 的需求最后可能都不會真的落地。也就是說，這是一件必須做，但很容易“投入產出不成正比”的事。

所以，給工作量評估單獨做一個 Skills，價值就出來了。

這類 Skills 的核心不是“拍腦袋估時”，而是先把需求結構化，再按角色分工去估算。比如它先把一個需求拆成若干功能點，再分別評估產品、設計、前端、后端、測試各自的工作量，最后輸出成一份清晰的 Markdown 文檔，可以直接發給客戶。

這里特別關鍵的第一點，是：需求沒診斷清楚之前，不要評估。

這和真實工作完全一樣。

一個模糊需求，談不上有效評估。真正靠譜的 Skills，應該先幫你補齊信息、識別歧義、確認邊界，然后再進入評估階段。

第二點，是把拆解規則講清楚。比如一個用戶故事對應一個需求，一個需求再拆成若干功能。簡單需求可能只有 1 到 2 個功能，復雜需求拆成 3 到 6 個功能。如果超過 6 個，就應該提示“這已經不是一個需求，而是多個需求”。

第三點，是輸出格式一定要明確。工作量評估最怕看起來很多，實際不可用。所以最好直接定義成 Markdown 表格，明確列出功能清單、角色分工和對應人天。

你會發現，這個環節的核心價值，不只是幫你省時間，而是幫你把“評估”這件事從經驗型動作，慢慢變成一個更可解釋、更可復用的過程。

Case 4：怎么用 AI 設計產品方案？

如果你做過復雜需求，應該對這種感覺很熟：思路卡住了，但又找不到一個真正能把背景接住、愿意耐心陪你推演的人。

跟同事聊，大家都有自己的工作，能給的時間有限；跟外部同行聊，又常常因為上下文太多、背景太重，很難在短時間內給出真正有效的建議。

這時候，產品方案 Skills 的價值就會非常明顯。

它最像的，不是一個“自動生成方案的工具”，而是一個隨時在線的資深產品經理。你可以不斷跟它聊思路、聊困惑、聊約束條件，讓它幫你做結構化思考，也幫你看到自己沒注意到的視角。

不過這里也有兩個特別容易走偏的點。

第一，不要讓它一上來就直接給方案。真正有效的方式，是先讓它診斷需求，確認背景、目標、角色、邊界，再逐步進入方案討論。你可以把它理解成一次高質量的同行交流，而不是一次機械的內容生成。

第二，要把你的方法論告訴它。比如“需求是 1，方案是 0”，“以終為始，全面規劃；以始為終，最小閉環”這類原則，就很適合寫進 Skills。這樣它每次給方案時，不是只會拼湊功能點，而是會沿著你的思考框架去展開。

在輸出結構上，也最好提前定義清楚。通常一個需求對應一個解決方案，而一個方案可以包括需求背景、用戶故事、設計理念、解決方案、原型示意圖、流程圖，復雜場景下甚至還可以補實體關系圖。

最后，要告訴它不能諂媚（尤其是在用Gemini模型），保持質疑、警惕之心。

這樣一來，它就不只是“幫你寫方案”，而是真的在參與方案設計。

順便說一句，我準備再寫一個子SKills，快速輸出3個完全不同思路的方案，用于早期設計方案時，完全打開自己的思路。

聊到這里，你應該已經能感受到，Skills 真正厲害的地方，不是“讓 AI 多會一點”，而是把你自己的經驗和方法論，慢慢固化成一個能反復調用的能力模塊。

為什么會覺得它很重要？因為它同時具備幾個非常關鍵的特性。

首先是穩定。復雜任務下，普通提示詞經常會漂，今天寫得像回事，明天又偏了。但 Skills 一旦定義清楚，輸出會穩定得多。

其次是靈活。你不需要每次都精確記住要調哪個工具、進哪個入口。只要描述清楚需求，它就能根據上下文調用合適的 Skills，甚至多個 Skills 配合完成一個任務。

還有一個很容易被忽略的點，是可復用。不同工具之間，Skills 的底層格式其實越來越像一個統一接口。你在一個工具里沉淀下來的能力，不至于每換個平臺就得從零再來一次。

更重要的是，它的能力并不止于“寫文檔”。在更深入的場景里，Skills 還能寫腳本、調接口、執行具體動作。之前那篇文章里，就用它直接請求企業內部系統，拿客戶信息，再自動生成客戶案例 PPT。到了這一步，你會發現 Skills 已經不只是內容助手，而是在真正進入工作流。

說到底，AI 改造工作流這件事，最難的從來不是工具本身，而是你愿不愿意把自己的經驗拆出來、定義清楚、反復調試，直到它變成一個真正能用的“技能”。

如果你現在正準備開始，真沒必要一上來就追求“大而全”。不如先問自己一個更簡單的問題：

在你的工作流里，哪個環節最重復、最耗時、也最容易先被改造？

從那個點開始，往往比什么都重要。

本文來自公眾號：產品方法論集散地 作者：產品方法論集散地