真實案例分析：如何把經驗裝到Skills？

AI工具Skills的真正價值不在于炫技，而在于如何將個人經驗轉化為生產力。本文通過一個SaaS產品經理的真實案例，深度剖析如何將自己的方法論「喂」給AI，讓輸出的結果從「看起來對」變成「對你有用」。從第一輪調試的貪心失敗到最終實現穩定可用的Skill，揭示了AI應用中最關鍵的認知轉變：不是讓AI代替思考，而是幫我們復用專業判斷。

———— / BEGIN / ————

最近一直在分享Skills。

從最早聊它如何完成 50 個客戶案例，到后來聊它怎樣嵌進產品經理的工作流，再到最近分享如何從 0 到 1 寫一個“畫原型”的 Skills，這條線其實一直很清晰：不是在炫技，而是在回答一個更實際的問題，AI 到底怎么真正進入工作，而不是只停留在演示里。

但這里面一直有一個繞不開的話題，之前沒有單獨展開說。

那就是：怎么把你的經驗、方法論，真正裝進 Skills 里，讓它輸出的內容不只是“看起來對”，而是“對你有用”。

很多人會有一個很自然的疑問：AI 已經這么強了，為什么還要強調“把自己的經驗喂給它”？這聽起來好像有點自以為是，仿佛默認自己比 AI 更懂。

其實不是。

更準確地說，你不是在教 AI 變聰明，而是在給它一個邊界、一個約束、一個參考。你是在告訴它，什么才叫符合你的業務現實，什么才叫符合你的判斷標準，什么才是你真正想要的輸出結果。

否則，它當然也能給你答案，而且往往還會給得很完整、很漂亮、很像那么回事。但問題是，那些內容未必屬于你，未必適合你的場景，甚至可能只是“高大上”，卻和實際工作沒什么關系。

這篇文章，就是想聊這件事。

為什么我會開始折騰這個問題

拿一個很真實的場景來說。

作為一名 SaaS 產品經理，每周少則要評估 1 到 2 家客戶的定制需求工作量，多的時候可能有 5 到 10 家。每次評估，少則 1 小時，多則一整天。它既重復，又高頻，還特別費時間。

你如果不認真評估，只是給客戶一個籠統的人天，比如 10 人天，對方很可能會繼續追問：“你們有評估依據嗎？有沒有需求理解和時數拆解？”

可你如果認真去做，又會很快陷入另一個現實：費了不少時間，最終真正愿意付費定制的客戶，可能連 5% 都不到。

這就是一個特別典型、也特別適合用 Skills 去解決的問題。

但真正開始寫的時候，很快就會發現，事情沒那么簡單。一個看起來“很明確”的需求，要做成一個穩定可用的 Skills，背后其實很講究。不是把需求描述給 AI，就能自然得到一個符合預期的結果。

我前后調了好幾個小時，寫廢過一個 Skills，又拿 5 個完全不同的真實需求反復驗證，才慢慢調出一個能真正投入工作的版本。

回過頭來看，真正決定結果的，不是提示詞寫得多長，而是你有沒有把自己的經驗和方法論講清楚。

這也是這篇文章的由來。想把這個過程完整分享給你，或許能幫你少走一點彎路。

第一輪調試：一個 Skill 干太多事

最開始調試的時候，我其實犯了一個很常見的錯：希望一個 Skill 一次性把所有問題都解決。

我當時的想法很直接。輸入一個需求，讓它同時輸出解決方案、用戶故事、流程圖，再順便給出工作量評估。聽起來很合理，甚至還有點“一步到位”的味道。

結果也確實能出東西。它會給我 2 到 3 個解決方案，每個方案后面還附帶一份對應的工作量評估。

但真正一看，就發現問題很明顯。

第一個問題，是評估結果偏差非常大。原本經驗判斷大概 15 人天的需求，它給出來的方案一可能是 30 人天，方案二甚至能到 59 人天。表面上看是在“多方案分析”，實際上是評估基準已經飄了。

第二個問題，是拆得太細，而且太技術化。它會把很多研發內部的實現層內容直接攤出來，比如日志管理、數據映射配置之類。這樣的結果拿給客戶，未必能幫助對方理解，反而更容易把溝通帶偏。

后來再回頭看，這一輪失敗幾乎是必然的。因為我實際上是在讓一個 Skill 同時承擔“方案設計”和“工作量評估”兩種不同職責。一個偏發散，一個偏收斂，本來就不該混在一起。

第二輪調試：拆開職責，但只給要求，不給方法

第一輪結果不符合預期之后，我開始拆分職責。

說到底，問題有兩個。一個是不符合 Skills 的設計常識，也就是一個 Skill 最好只做一件事。另一個更關鍵，是我雖然給了很多要求，卻沒有把背后的經驗和方法講給它。

于是第二輪，我把它拆成了至少兩個 Skill。一個負責設計解決方案，一個專門負責評估工作量。

這次，我把約束加得很強，也明確告訴它一些經驗判斷。比如測試工作量通常是后端的三分之一到二分之一，前端一般是后端的一半，產品和設計工作量最小，簡單需求 1 天，最復雜也不超過 5 天。

然后，我拿一個真實需求去測它：

評估工作量：需求是新增審批流支持審批通過后，把對應 Excel 表附件數據自動同步到系統中。背景是目前系統已有兩種導入方式，一種是直接導入，一種是通過第三方 API 接口同步，但還不支持通過審批流程導入。

本來以為這次會比第一輪好，結果反而有點弄巧成拙。

同樣一個經驗判斷大約 15 人天的需求，它直接給我評到了 44 人天。而且它還特別“聽話”，幾乎完全照著我給的比例去套。后端 18 天，前端 9 天，測試又 9 天，數字看起來很規整，邏輯也似乎說得通，但結果明顯不對。

那一刻我才真正意識到，只給比例、不給方法，問題會更大。因為它會非常認真地執行約束，卻不一定真的理解你為什么這么約束。

你有沒有過類似體驗？你給一個新人很多規則，結果對方每條都記住了，但做出來的東西還是不對。問題不在執行力，而在于他沒有建立判斷框架。

AI 也是一樣的。

第三輪調試：給它經驗，更要給它判斷邏輯

前兩輪調試之后，我慢慢發現了一個核心問題：

不是 AI 不夠聰明，而是我對它有不切實際的期待。

我一開始太希望它像“肚子里的蛔蟲”，既能自動讀懂需求，又能自己掌握拆解需求、評估工作量的方法論。可現實是，這幾乎等于你期待一個剛入職的同事，在不了解業務、不熟悉系統的情況下，直接產出一份完全符合你預期的結果。

哪怕這個同事再聰明，也不現實。

所以第三輪，我索性推倒重來，從 0 到 1 重新寫了一個全新的 Skill，目標非常單一：只做工作量評估。

這一次，我不再一味加強硬約束，而是開始把真正的方法論告訴它。

最核心的，是下面這幾件事。

第一，要遵循“需求是 1，方案是 1”的原則。也就是說，在需求沒搞清楚之前，不能直接評估工作量；在方案沒定下來之前，也不能直接給時數。必須先問清需求，再確認方案，最后才評估。

第二，要有一套明確的拆解路徑。我給它的是“需求 → 場景 → 模塊 → 功能 → 原子任務”這條鏈路，并補充了拆解原則。比如一個功能點只做一件事、鏈路要閉環、不要為了拆而拆。

第三，要告訴它如何一步步拆。我把工作量評估定義成一個“五步法”，按照需求、場景、業務、最小功能點、任務的順序逐層展開，而不是一上來就按角色拍腦袋報數。

第四，可以給經驗，但不要給死。比如測試工作量通常是后端的一半，產品工作量可以按需求復雜度浮動，小需求 0.5 天，常規需求 1 天，中等需求 2 天，復雜需求 3 天，超級復雜需求最多 5 天。它們應該是參考系，而不是鐵律。

這一次，我干脆單獨新開了一個項目，從零開始重建，工具也從扣子換到了 Trae，把這些拆解原則和方法論都明確寫進去了。

結果比前兩輪明顯好很多，但還是沒有一步到位。

同一個需求輸進去之后，它雖然開始更像回事了，可輸出方式還是不符合我想要的工作習慣。它會按角色逐項評估，每個角色都給一整份時數，看上去很完整，但不夠適合直接拿去跟客戶溝通。

于是，我又繼續調。

第一次微調，重點是約束最終輸出形式。把“UI”替換成“產品”角色，同時把表格邏輯改成按場景來組織。每一行對應一個用戶場景，功能點聚合在同一格里，后端、前端、產品、測試分別展示工作量，最后一行再匯總總人天。并且我特意補了一條：如果某個功能點很小，允許評估成 0.2、0.4 天，不必強行從 0.5 起跳。

第二次微調，是把產品經理和測試的工作量從“功能級逐項評估”改成“場景級匯總評估”。因為真實工作里，這兩個角色通常沒必要在每個小功能點上拆得那么細。產品更多是按需求復雜度判斷，測試更多是按整體鏈路和風險范圍評估。

經過這兩輪微調后，最終結果終于基本符合預期，也正式投入到實際工作里了。

我怎么判斷這個 Skill 算“可用”了

真正決定一個 Skill 能不能進工作流，標準其實沒那么復雜。

對我來說，只有兩個。

第一，評估顆粒度要合適。既不能粗到只剩一個總人天，也不能細到全是客戶看不懂的技術項。最理想的狀態是：一個需求拆成若干場景，一個場景下再拆若干功能點。場景負責讓客戶看懂，功能點負責支撐細節。

第二，工作量結果要符合經驗和常識。如果同一個需求，我的經驗判斷是 10 人天，那它給出的結果在上下 20% 波動都可以接受；但如果直接翻倍，或者壓得離譜，再漂亮的表格也沒有意義。

說到底，Skills 不是替你“發明”工作經驗，而是幫你把已有經驗穩定地復用出來。

最后，分享幾個我覺得很重要的經驗

寫到這里，其實最想傳達的不是“這個 Skill 我是怎么調出來的”，而是你如果也想寫出一個真正能用的 Skill，應該怎么想這件事。

首先，一個 Skill 只做一件事。

別貪心。寫需求文檔是一個 Skill，探索方案思路是一個 Skill，輸出正式方案是一個 Skill，評估工作量是一個 Skill，畫原型是一個 Skill，寫上線公告也是一個 Skill。分得越清楚，越容易穩定。

其次，把每個 Skill 都當成一個很聰明、但剛入職的實習生。

它能力很強，執行也很快，但它不是你肚子里的蛔蟲。你不給背景，它就只能猜；你不講標準，它就只能按“通用理解”去做。

再進一步，把你的經驗和方法論當成上下文告訴它。

AI 學過很多知識，但不代表它天然知道你所在行業、你所在團隊、你這份工作的判斷標準。你完全可以直接把方法論講給它，而不是期待它自己猜中。就像這次工作量評估里用到的拆解思路，本質上也不是“我原創”的，而是從經驗中提煉出來，再明確寫進 Skill 里。

最后，工具和模型的選擇，確實會影響結果。

免費工具當然可以上手，也足夠你嘗鮮，但如果你真的想把 Skills 當成生產力，而不是玩具，還是要接受一件事：好工具、好模型，確實會讓你少走很多彎路。至少在當前階段，Trae 或 Cursor 的付費版，再搭配 Gemini 或 Claude 這樣的模型，整體體驗會更穩定。

回頭看，這一路最大的變化，不是我多會寫提示詞了，而是我終于開始接受一件事：

AI 的價值，不只是替你干活，更是替你復用判斷。

而判斷這件事，不會憑空出現。它來自你的經驗，來自你踩過的坑，來自你總結出來的方法論。你把這些東西講清楚，Skills 才可能真正長成“你的 Skills”，而不是一個看起來很厲害、實際上誰都能替代的通用能力。

所以，如果你最近也在寫 Skills，不妨問自己一個問題：

你現在寫進去的，究竟只是任務說明，還是已經開始把自己的經驗裝進去了？

這兩者的差別，往往決定了它最終是玩具，還是生產力。

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