如何把經驗裝到Skills？
整理版優先睇
寫 Skill 唔係只係畀任務說明，而係要將自己嘅經驗同判斷邏輯寫入去，先至可以得到真正可用嘅結果。
呢篇文章係一位 SaaS 產品經理分享佢點樣將自己嘅經驗裝入 AI Skills 嘅過程。佢經常要評估客戶嘅定製需求工作量，每星期少則一兩個，多則五到十個，每次評估耗時唔少，但最後真正願意俾錢嘅客戶連 5% 都唔到。佢想整一個 AI Skill 幫手自動評估工作量，但發現直接將需求掟畀 AI 係唔得嘅。
佢經歷咗三輪調試：第一輪一個 Skill 想做曬所有嘢（方案設計同工作量評估），結果評估結果完全唔靠譜；第二輪拆開職責，但只係畀硬性比例（例如測試係後端嘅三分之一到二分之一），結果 AI 死跟比例但唔理解點解，結果都係錯。第三輪佢重新寫過，將自己嘅評估方法論——「需求 → 場景 → 模塊 → 功能 → 原子任務」拆解路徑同五步法——明確寫入 Skill，結果終於可用。最後佢總結咗幾條關鍵原則：一個 Skill 只做一件事、將 Skills 當成新入職實習生、將經驗同判斷邏輯作為上下文提供、同埋工具同模型嘅選擇會影響效果。
- 一個 Skill 只做一件事：設計方案同評估工作量要分開，避免職責混合。
- 只畀硬約束唔畀方法：AI 會盲從比例而忽略實際，必須畀清楚判斷邏輯。
- 畀一套拆解路徑：例如「需求→場景→模塊→功能→原子任務」，幫 AI 有結構地分析。
- 經驗要作為參考系而非鐵律：容許浮動（例如測試工作量係後端一半），但唔好鎖死。
- 將 Skills 視為新入職實習生：需要背景、標準同方法論先可以產出合預期結果。
工作量評估五步法
將需求按「需求→場景→模塊→功能→原子任務」逐層拆解，然後按角色（後端、前端、產品、測試）評估，最終以場景為單位組織輸出。
點解要將經驗裝入 Skill？
作為 SaaS 產品經理，作者每週要評估大量客戶定製需求工作量，但真正付費嘅客戶好少。佢想用 AI 幫手，但發現直接畀任務說明係唔夠嘅。
你係喺話畀佢知，咩先叫符合你嘅業務現實
第一、二輪調試：撞板經驗
第一輪作者犯咗一個常見錯誤：希望一個 Skill 同時做方案設計同工作量評估。結果輸出嘅評估結果偏差好大，仲包含好多技術細節，唔適合同客戶溝通。
一個 Skill 幹太多事
- 評估結果偏差大：經驗判斷 15 人天，AI 畀出 30 甚至 59 人天。
- 拆得太細太技術化：列出日誌管理、數據映射呢啲研發內部細節，客戶睇唔明。
第二輪作者拆開職責，專注工作量評估，並畀咗硬性比例約束。
只畀要求、唔畀方法
- AI 死跟比例：測試係後端三分之一到二分之一，結果後端 18 天、前端 9 天、測試 9 天，總共 44 人天（經驗判斷 15 人天）。
- 問題在於 AI 唔理解比例背後嘅判斷邏輯，只係機械式執行。
第三輪調試：方法論嘅力量
第三輪作者推倒重來，寫咗一個全新 Skill，目標單一：只做工作量評估。呢次佢唔再加硬約束，而係將真正嘅方法論話畀 AI 知。
- 1 遵循「需求是 1，方案是 1」原則：先問清需求，再確認方案，最後先評估。
- 2 畀一套明確嘅拆解路徑：需求 → 場景 → 模塊 → 功能 → 原子任務。
- 3 將工作量評估定義成「五步法」：按需求、場景、業務、最小功能點、任務逐層展開。
- 4 經驗作為參考系：測試工作量通常係後端一半，產品工作量按複雜度浮動（0.5 到 5 天），唔好鎖死。
微調兩次後：第一次將輸出表格按場景組織，容許 0.2、0.4 天嘅小功能；第二次將產品同測試工作量改為場景級彙總評估。最終結果符合預期。
將你嘅經驗同方法論當成上下文告訴佢
可再用法則
- 一個 Skill 只做一件事：寫需求文檔、探索方案、輸出方案、評估工作量、畫原型、寫上線公告，全部要分開。
- 將每個 Skill 當成一個好聰明但剛入職嘅實習生：唔畀背景佢就只能估；唔講標準佢就只能按通用理解去做。
- 將你嘅經驗同方法論當成上下文話畀佢知：唔好期望 AI 自己估中你嗰行嘅判斷標準。
- 工具同模型嘅選擇會影響效果：免費工具夠試玩，但想做生產力，就要投資好啲嘅工具（例如 Trae、Cursor 付費版配 Gemini 或 Claude）。
Skills 唔係幫你「發明」工作經驗，而係幫你將已有經驗穩定複用
最後問自己一個問題：你寫入去嘅，究竟只係任務說明，定係已經開始將自己嘅經驗裝入去？呢個分別決定咗佢係玩具定係生產力。
唔知你有冇留意，最近一直係咁分享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，不妨問自己一個問題：
你而家寫入去嘅，究竟只係任務說明，定係已經開始將自己嘅經驗裝入去？
呢兩者嘅分別，往往決定了佢最終係玩具，定係生產力。
不知道你有沒有留意，最近一直在分享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，不妨問自己一個問題：
你現在寫進去的，究竟只是任務說明，還是已經開始把自己的經驗裝進去了？
這兩者的差別，往往決定了它最終是玩具，還是生產力。