寫了上百個Skill效率起飛後，我總結了一套Skill實操教程
整理版優先睇
作者分享點樣將經驗SOP化，通過先跑通再封裝嘅流程寫出高質量Skill
呢篇文章嘅作者寫咗上百個Skill，佢由最初覺得Skill只係大號Prompt，到後來理解到Skill係一套可以令AI完成複雜SOP嘅作業系統。佢想分享自己嘅實戰心得，幫讀者避開常見誤區，掌握寫Skill嘅核心方法。
作者提出一個重要觀點：唔好一開始就設計Skill，而係先同AI跑通一個真實任務，再覆盤個過程，然後封裝成Skill，最後做回溯測試。呢個流程同傳統寫Prompt好唔同，因為Agent任務複雜度更高，好難預先設計全部細節。佢嘅整體結論係：寫Skill考驗嘅唔係語法或Prompt技巧，而係將一個場景SOP化嘅能力。
文章仲詳細講解咗Skill嘅組織結構，包括name/description、SKILL.md同參考資料三層，同埋點樣好似做產品咁持續迭代Skill。佢用多視角分析Skill同PPT Skill做例子，說明每個版本解決一個核心問題，避免功能發散。
- Skill唔係大號Prompt，而係一套讓AI執行複雜SOP嘅作業系統，包括規則、腳本、參考資料等模塊。
- 寫Skill嘅最佳流程：先同AI跑通一個真實場景，然後覆盤正向流程，再封裝成Skill，最後做回溯測試確保穩定性。
- Skill組織分三層：name/description決定觸發時機，SKILL.md定義主流程，參考資料補充各階段能力。
- Skill迭代要好似做產品：每個版本專註解決最明顯嘅問題，同時守護Skill嘅核心定位，避免功能過界。
- 寫Skill本質係將經驗SOP化——熟悉領域要蒸餾經驗，唔熟悉領域要建立可靠嘅回溯驗證機制。
Skill同Prompt嘅本質差異
作者一開始都覺得Skill只係大號Prompt，但寫得多之後發現兩者底層邏輯雖然一樣——都係叫AI跟SOP做嘢——但喺調用方式同複雜度上有明顯分別。
Skill可以畀模型根據任務自動判斷調用邊個，Prompt就要人手指定，好難融入全局工作流。
而且Skill可以包含規則、參考文檔、Python腳本、素材庫，分階段畀模型用；Prompt就要一次過塞曬，信息量同複雜度都好有限。
寫Skill嘅四步流程：跑通、覆盤、封裝、回溯
作者最核心嘅經驗係：唔好一開始就設計Skill，先同AI跑出效果再封裝。呢個同傳統寫Prompt好唔同，因為Agent任務複雜，好難預先諗曬所有細節。
- 1 先同AI定好目標，並將真實場景跑通：唔使完美，但要攞到自己認可嘅結果。
- 2 同AI覆盤結果點樣跑出來：分清邊啲係正向流程、邊啲係負向，沉澱應保留嘅內容。
- 3 基於覆盤結果封裝成Skill：從真實成功經驗提煉流程，效果遠好過憑空設計。
- 4 開新對話做回溯測試：睇Skill能否穩定復現類似結果，唔穩定就針對性優化。
呢套流程本質係先跑通、再覆盤、再封裝、再回溯，而唔係傳統嘅先設計再驗證。
Skill嘅組織結構：三層漸進加載
Agent調用Skill時唔會一次過塞曬全部內容，而係分幾層逐步加載：第一層係name同description，用嚟判斷應該調用邊個Skill。
description如果寫得太泛，模型可能會錯誤調用，例如將網頁設計Skill用喺App設計場景。
第二層係SKILL.md，負責定義主流程；第三層係參考資料，包括references、scripts、assets等，補充各階段能力。
Skill嘅進化：好似做產品咁迭代
Skill好難一次就做到完美，要靠人不斷迭代。作者圍繞兩個維度優化：呢個Skill根本上要做嘅問題係咩？當前做得唔好嘅地方係邊度？
多視角深度分析Skill從1.0到2.0解決視角穩定性，2.0到3.0增加顧問數量，但3.0時忍住冇加設計功能，因為會偏離核心定位。
PPT Skill由1.0嘅60分逐步提升：先解決「做到」，再改善樣式豐富度，然後引入subagent設計邏輯，最後減少人手幹預。
每個版本只解決一個最明顯嘅問題，唔好追求一開始就完美。
寫Skill嘅本質：將經驗SOP化
作者同朋友討論後總結：Skill考驗嘅係人將一件事SOP化嘅能力——即係能否將反覆出現嘅問題沉澱成AI可複用嘅流程。
熟悉領域嘅寫Skill係經驗蒸餾，將自己嘅做法拆成AI理解嘅步驟。
唔熟悉領域嘅時候，最關鍵係建立回溯驗證機制，例如占卜Skill因為作者唔識解卦，冇辦法判斷AI結果啱唔啱，最終放棄。
最近呢排，我做得最多嘅一件事，就係寫唔同嘅 Skills。
我試緊將工作同日常生活入面更多嘢交畀 AI，等佢更加深入融入我嘅工作流程。
啱啱呢排表達慾多少少返嚟，所以想寫篇文章，同大家講下我呢排寫 Skill 嘅方法同諗法。
1. Skill 同 Prompt 有咩分別
我初初接觸 Skill 嘅時候，試完之後同朋友講第一反應就係：呢個咪即係一個大號嘅 prompt？好似都冇乜特別新嘅嘢出嚟。
但係親手寫咗好多 Skill 之後，我覺得佢哋之間確實有連續性，不過都有好多明顯嘅分別。
由底層邏輯嚟講，Skill 同 Prompt 做嘅係同一件事：令 AI 按照一套 SOP 標準去作業。
所以最簡單嘅 Skill 同 Prompt 冇本質分別，例如 Claude 官方嘅設計 Skill，佢就係一個單 Skill.md 文件構成嘅 Skill，入面描述咗整體設計思路，令模型可以根據呢套邏輯去作業，放喺 Prompt 上面都係一樣嘅效果。
但係喺模型嘅調用方式上，Skill 比 Prompt 更加友好。
模型作業嗰陣，可以首先見到多個 Skill 嘅基礎說明，然後根據當前任務判斷要調用邊個 Skill。而 Prompt 只可以靠人手指定嘅方式嚟加載，好難喺全局工作流程入面形成穩定嘅調用機制。
同時喺複雜嘅 SOP 流程上，Skill 可以做到好多 Prompt 做唔到嘅嘢，佢可以包含各種規則、參考文檔、Python 腳本、素材庫，喺唔同階段令模型調用唔同嘅內容。
而 Prompt 就要一次過將所有內容餵畀模型，但係咁樣能夠承載嘅信息量同複雜度都係有限的。內容一多唔單止會佔用大量上下文，仲容易令模型執行嗰陣抓唔到重點。
所以我後來對 Skill 嘅理解就變咗：Skill 唔係一個大號嘅 Prompt，佢係一套可以令 AI 完成更加複雜 SOP 嘅作業系統。
2. 寫 Skill 嘅流程：跑通、覆盤、封裝、回溯。
如果淨係講一個最核心嘅經驗，我認為係：唔好一開始就設計 Skill，先同 AI 跑出效果，再封裝成 Skill。
呢個邏輯同我之前寫提示詞有好大分別。
寫提示詞嗰陣，我會同 AI 一齊先諗目標係咩，然後提示詞嘅作業流程係點，基於呢個設計出一版提示詞，再攞去測試，最後根據效果調整。
但係呢個有個大前提：之前 AI 作業比較偏向 Chatbot，基本上都係網頁入面做對話。
而喺 Agent 作業邏輯下，任務嘅複雜度明顯高咗，佢唔再只係多輪對話，中間會混雜各種腳本、工具調用、文件讀取、subagent 分工嘅情況，所以好多流程好難一開始就完整設計出嚟。
所以我而家比較傾向先同 AI 定個目標，然後想辦法達到對應嘅結果，再回頭將呢個過程封裝成 Skill。
咁樣做嘅試錯成本最低，亦都可以降低好多測試成本。
我目前嘅作業流程分咗呢四步。
1. 先同 AI 定好目標，然後將呢個真實場景跑通：唔需要一開始就做到完美效果，但係要先根據自己定好嘅目標拿到一個自己認可嘅結果。 2. 同 AI 覆盤呢個結果係點樣跑出嚟嘅：主要係同 AI 討論成個過程入面有邊啲係正向流程，邊啲係負向流程，邊啲內容係應該保留沉澱落嚟嘅。 3. 將呢套過程封裝成 Skill：叫 AI 根據我哋嘅覆盤結果進行 Skill 封裝就得，由真實成功經驗提煉出嚟嘅流程往往比憑空設計嘅流程效果好好多。 4. 做回溯測試：開一個新對話，測試呢個 Skill 可唔可以穩定重現類似結果，如果唔穩定就要睇下問題喺邊，然後對應嘅 Skill 流程進行優化。
所以呢套流程本質上唔係先設計，再驗證，而係先跑通，再覆盤，再封裝，再回溯。
3. Skill 嘅組織結構
呢度我打算獨立開一個小節，講下 Skill 嘅組織結構，主要係方便大家理解模型係點樣加載一個 Skill。
當 Claude Code、Codex 呢啲 Agent 調用 Skill 嗰陣，唔係一開始就將成個 Skill 嘅全部內容塞畀模型，佢係分多層級逐步加載嘅。
第一層係 Skill 嘅描述：佢由 name 同 description 兩個字段構成，呢兩個字段會話畀模型呢個 Skill 係做咩用，方便模型喺作業場景入面判斷要調用邊個 Skill。
喺一次對話入面，模型係會將讀取到嘅所有 Skill 描述都加載入去，所以寫 Skill 描述嗰陣最好清楚講明場景係咩，例如話 Skill 係寫 PRD 文檔嘅，咁 description 就要明確話畀模型，當用戶提出需求整理成結構化 PRD、補全背景、目標、功能範圍同驗收標準時，應該用呢個 Skill。
如果 description 寫得太濫，有時模型會錯誤調用，例如一個係網頁設計 Skill，一個係 app 設計 Skill，如果唔清晰寫明使用場景，模型可能會喺 app 設計嗰陣誤用網頁設計 Skill。
第二層係 SKILL.md 文件：當模型判斷需要調用某個 Skill 之後，佢會再去讀取 SKILL.md，瞭解呢個 Skill 嘅主流程。
所以最簡單嘅 Skill，其實只需要一個 SKILL.md 就夠，入面寫清楚呢個 Skill 係做咩、適合咩場景、整體作業流程係點、最後應該輸出咩結果。
例如我嘅設計 Skill，佢就係得一個 SKILL.md 文件：佢會先理解需求，再確定設計方向，同用戶確認 ASCII 圖，然後再生成頁面方案，佢唔需要複雜嘅外部資源。
第三層係參考資料：我習慣將 references、scripts、assets 呢啲內容都定義為參考資料，因為佢哋係主流程下各個階段調用內容嘅補充，無論係 md 文件、python 腳本、定係各種素材，其實都係令模型能夠喺對應流程下進行更標準嘅作業。
例如我之前做嘅多視角深度分析 Skill，佢入面仲包含咗各種 subagent 嘅語料庫，AI 執行任務嗰陣，會根據唔同專家視角，將對應資料發畀 subagent，等佢哋按照更穩定嘅邏輯去分析。
最後綜合一下我對 Skill 組織嘅理解：name 同 description 負責觸發，Skill.md 負責主流程，參考資料負責喺複雜場景下補充能力。
關鍵唔係目錄睇起嚟幾完整，而係每一層都要服務於模型嘅真實作業流程。
4. Skill 嘅進化：好似做產品咁迭代
Skill 唔係一次就可以做出一個好出色嘅產品，佢往往依賴人嘅多次迭代。
我而家優化 Skill 嘅時候主要會圍繞兩個維度嚟做：
1. 呢個 Skill 根本要解決嘅問題係咩？唔好做做嚇越界。 2. 當前 Skill 做得唔好嘅地方係咩，今次優化重點要解決咩問題。
例如我之前做多視角深度分析 Skill 嗰陣，第一版就係叫 subagent 自由選擇視角，對內容進行評估。測試完之後發現一個問題：subagent 嘅作業邏輯成日變，好難穩定用同一個視角幫我覆盤。
所以由 1.0 版本去到 2.0 版本，我主要解決嘅問題係視角穩定性。
我幫每一個 subagent 嘅派單加咗語料庫，將唔同專家視角嘅判斷邏輯標準化，令 subagent 可以根據一套相對穩定嘅流程進行分析。
2.0 版本嗰陣，我覺得 5 個顧問嘅數量唔太夠，於是我就再篩選增加咗一批顧問數量到 10 個，呢個就係 3.0 版本。
但係喺 3.0 版本嗰陣，我想用呢個 Skill 去寫 code 同做設計，當時我就諗緊要畀呢個 Skill 增加更多能力落去。
呢個時候就要回望多視角深度分析 Skill 嘅初衷係咩，佢其實係用嚟做思維複製分析嘅產品，唔應該承擔設計、debug、寫 code 相關嘅內容，所以我冇將佢做成一個萬能分析 Skill。
而係新開咗設計 Skill 同 debug Skill，令每一個 Skill 對應一個更明確嘅場景。
另一個例子係做 PPT 嘅 Skill，佢嘅目標好明確，就係令 AI 幫人做出更精美嘅 PPT。
1.0 先解決 AI 做唔做到嘅問題，效果唔係幾好，可能得 60 分左右。
2.0 解決樣式豐富度嘅問題，通過增加更多底板同參考樣式，令效果達到 65 分。
3.0 引入 subagent 嘅設計邏輯，令頁面唔止係套模板，而係可以根據內容做更適合嘅設計。
4.0 再優化整體 PPT 設計嘅流程，減少人手幹預，令 AI 更加自主作業。
每個版本其實都係解決一個當下最明顯嘅問題。
所以 Skill 優化同產品迭代好似：唔好一開始就追求完美，而係先跑起來，再一輪一輪解決關鍵問題。
5. 對 Skill 嘅思考：本質係將經驗 SOP 化
我同朋友都討論過好多次：Skill 到底考驗人嘅咩能力？
我而家嘅理解係：Skill 本質上係人將一件事 SOP 化嘅能力。
即係人可唔可以將一個真實場景入面反覆出現嘅問題，沉澱成一套 AI 可以重用嘅流程。
呢度根據我自己嘅測試經驗，總結咗兩種唔同嘅場景。
第一種係人熟悉嘅領域。
呢個時候寫 Skill，更加似係經驗蒸餾。
因為人本來就知道呢件事應該點做，亦知道咩結果係好嘅。人要做嘅係將自己嘅經驗拆出嚟，變成 AI 能夠理解、執行同重用嘅流程。
第二種係人唔熟悉嘅領域。
呢個時候寫 Skill，最重要就係建立一套回溯驗證機制。
因為呢個場景下難嘅其實唔係叫 AI 產出內容，而係判斷佢做得啱唔啱。
例如我之前一直想做一個六爻占卜 Skill。
呢個場景睇落好適合做 Skill，因為佢有規則、有流程，亦都有好多資料可以參考。但係真正做成 Skill 嘅時候，我發現佢好難穩定落嚟。
我自己唔夠識占卜，我其實對於點樣解卦毫無頭緒，然後 AI 都唔識，我哋兩個夾埋冇辦法構建一個可靠嘅回溯測試系統。
我根本唔知解卦係準定唔準，最後呢個 Skill 我打磨咗半個月都放棄咗。
測試完呢個 Skill 令我感觸好深，人唔熟悉嘅領域唔係話一定做唔出 Skill，核心係要睇可唔可以透過回溯機制嚟驗證。
例如喺編程嘅自動化測試上，我都唔係專業嘅測試工程師，但係我可以叫 AI 設計一套測試邏輯，然後不斷透過回溯測試優化呢套邏輯嘅合理性，最後令 AI 將穩定運行嘅流程封裝成 Skill。
所以寫 Skill 到最後考驗嘅唔係語法，亦唔止係提示詞能力，而係人將場景 SOP 化嘅能力。
最近一段時間，我乾的最多的一件事，就是寫各種Skills。
我在嘗試把工作和日常生活中更多事情交給AI，讓它更深度地融入到我的工作流。
正好最近表達欲恢復了一些，就想寫篇文章，和大家聊聊我這段時間寫Skill的方法和思考。
1. Skill和Prompt的區別是什麼
在我剛接觸Skill的時候，我在體驗完後和朋友說的第一反應就是：這不就是一個大號的prompt嗎？感覺好像也沒有什麼特別新的內容出來啊。
但在親手寫了很多Skill後，我覺得它們之間確實有連續性，但是也有很多明顯的差別。
從底層邏輯上來講，Skill和Prompt做的是同一件事情：讓AI按照一套SOP標準去作業。
所以最簡單的Skill和Prompt沒有本質區別，比如Claude官方的設計Skill，它就是一個單Skill.md文件構成的Skill，裏面對整體設計思路進行了描述，讓模型能夠基於這套邏輯去作業，放到Prompt上來也是一樣的效果。
但在模型的調用方式上，Skill比Prompt更友好。
模型在作業時，可以先看到多個Skill的基礎說明，然後根據當前任務判斷要調用哪個Skill。而Prompt只能通過人工手動指定的方式來進行加載，很難在全局工作流裏形成穩定的調用機制。
同時在複雜的SOP流程上，Skill能夠實現更多Prompt做不到的事情了，它可以包含各種規則、參考文檔、Python腳本、素材庫，在不同的階段讓模型調用不同的內容。
而 Prompt則需要一次性把所有內容都餵給模型，但這樣能夠承載的信息量和複雜度都是有限的。內容一多不僅會佔用大量上下文，也容易讓模型在執行時抓不住重點。
所以我後來對Skill的理解就變了：Skill並不是一個大號的Prompt，它是一套可以讓AI完成更加複雜SOP的作業系統。
2. 寫Skill的流程：跑通、覆盤、封裝、回溯。
如果只說一個最核心的經驗，那我認為是：不要一開始上來就是設計Skill，先和AI跑出效果，再封裝成Skill。
這個邏輯和我之前寫提示詞有很大區別。
寫提示詞的時候，我是和AI一起先思考目標是什麼，然後提示詞的作業流程是什麼，基於此設計出來一版提示詞，再拿去測試，最後基於效果進行調整。
但這有一個大的前提：之前的AI作業更偏Chatbot，基本上都是網頁裏進行對話的。
而在Agent作業邏輯下，任務的複雜度是明顯變高的，它不再只是多輪對話，中間會摻雜各種腳本、工具調用、文件讀取、subagent分工的情況，所以很多流程很難在一開始就完整設計出來。
所以我現在更傾向於先和AI定一個目標，然後想辦法達到對應的結果，再回頭把這個過程封裝成Skill。
這樣做的試錯成本最低，也可以降低很多的測試成本。
我目前的作業流程分為這四步。
1. 先和AI定好目標，然後把這個真實場景跑通：不需要剛開始就做到了一個完美的效果，但要先基於自己定好的目標拿到一個自己認可的結果。 2. 和AI覆盤這個結果是怎麼跑出來的：主要是和AI討論整個過程中有哪些是正向的流程，哪些是負向的流程，哪些內容是應該保留沉澱下來的。 3. 把這套過程封裝成Skill：讓AI基於我們的覆盤結果進行Skill封裝即可，從真實成功經驗中提煉出來的流程往往比憑空設計的流程效果好很多。 4. 做回溯測試：開一個新的對話，測試這個Skill能否穩定復現類似的結果，如果不穩定的話就要去看看問題出現在哪，然後對對應的Skill流程進行優化。
所以這套流程本質上不是先設計，再驗證，而是先跑通，再覆盤，再封裝，再回溯。
3. Skill的組織結構
這裏我準備單獨開一個小節，講一下Skill的組織結構，主要是方便大家理解模型是如何去加載一個Skill的。
當Claude Code、Codex這些Agent調用Skill時，並不是一上來就把整個Skill的全部內容都塞給模型，它是分多層級進行漸進式加載的。
第一層是Skill的描述：它由name和description兩個字段構成，這兩個字段會告訴模型這個Skill是做什麼用的，方便模型在作業場景裏要判斷調用哪個Skill。
在一次對話中，模型是會把讀取到的所有的Skill描述都加載進去的，所以在寫Skill描述的時候，最好清晰明瞭的講清楚場景是什麼，比如說Skill是寫PRD文檔的，那description就要明確的告訴模型，當用戶提出需求整理成結構化 PRD、補全背景、目標、功能範圍和驗收標準時，應該使用這個Skill。
如果description寫得太泛，有的時候模型會錯誤的進行調用，比如一個是網頁設計skill，一個是app設計skill，如果不能清晰的寫明使用場景，模型可能會在app設計的時候誤調用網頁設計skill。
第二層是SKILL.md文件：當模型判斷需要調用某個Skill後，它會再去讀取SKILL.md，來了解這個Skill的主流程。
所以最簡單的 Skill，其實只需要一個SKILL.md就夠了，裏面寫清楚這個Skill是幹什麼的、適合什麼場景、整體作業流程是什麼、最後應該輸出什麼結果。
比如說我的設計Skill，它就是隻有一個SKILL.md文件：它會先理解需求，再確設計方向，和用戶確認ASCII圖，然後再生成頁面方案，它不需要複雜的外部資源。
第三層是參考資料：我習慣把references、scripts、assets這些內容都定義為參考資料，因為他們是主流程下各個階段調用內容的補充，不管是md文件也好、還是python腳本、還是各種素材，其實都是讓模型能夠在對應流程下進行更標準的作業。
比如我之前做的多視角深度分析Skill，它裏面還包含了各種subagent 的語料庫，AI 在執行任務時，會根據不同專家視角，把對應資料發給subagent，讓它們按照更穩定的邏輯去分析。
最後彙總一下我對Skill組織的理解：name和description負責觸發，Skill.md負責主流程，參考資料負責在複雜場景下補充能力。
關鍵不是目錄看起來多完整，而是每一層都要服務於模型的真實作業流程。
4. Skill的進化：像做產品一樣迭代
Skill並不是一次就可以做出一個非常棒的產品，它往往依賴人的多次迭代。
我現在在優化Skill的時候主要是會圍繞兩個維度來進行：
1. 這個Skill根本上要做的問題是什麼？不要做着做着過界了。 2. 當前Skill做的不好的點是什麼，這次要優化重點要解決什麼問題。
比如我之前做多視角深度分析Skill時，第一版就是讓subagent自由選擇視角，對內容進行評估。測試完後發現一個問題：subagent的作業邏輯一直在變，很難穩定用同一個視角幫我覆盤。
所以從1.0版本到2.0版本，我主要解決的問題是視角穩定性。
我給每一個subagent的派單增加了語料庫，把不同專家視角的判斷邏輯標準化，讓subagent能夠基於一套相對穩定的流程進行分析。
2.0版本的時候，我覺得5個顧問的數量不太夠，於是我就又篩選增加了一批顧問數量到10個，這就是3.0版本。
但在3.0版本的時候，我想用這個Skill去寫代碼和做設計，當時我就在想給這個Skill增加更多的能力進去。
這時候就需要會看多視角深度分析Skill的初衷是什麼，它其實就是用來做思維複製分析的產品，不應該承擔設計、debug、寫代碼相關的內容，所以我就沒有把它做成一個萬能分析Skill。
而是新開了設計Skill和debug Skill，讓每一個Skill對應一個更明確的場景。
另一個例子是做PPT的Skill，它的目標很明確，就是讓AI幫人做出更精美的PPT。
1.0先解決的是AI能不能做的問題，效果沒多好，可能有個60分的水平。
2.0解決的是樣式豐富度的問題，通過增加更多的底板和參考樣式，讓效果能夠達到65分。
3.0引入subagent的設計邏輯，讓頁面不只是套模板，而是能根據內容做更適配的設計。
4.0再優化整體PPT設計的流程，減少人的干預程度，讓AI更加自主的作業。
每個版本其實都是解決一個當下最明顯的問題。
所以Skill優化和產品迭代很像：不要一開始就追求完美，而是先跑起來，再一輪一輪解決關鍵問題。
5. 對Skill的思考：本質是把經驗SOP化
我和朋友們也討論過很多次：Skill到底考驗人的什麼能力？
我現在的理解是：Skill本質上是人把一件事SOP化的能力。
也就是人能不能把一個真實場景裏反覆出現的問題，沉澱成一套AI可以複用的流程。
這裏根據我自己的測試經驗，總結出來了兩種不同的場景。
第一種是人熟悉的領域。
這種時候寫Skill，更像是經驗蒸餾。
因為人本來就知道這個事情應該怎麼做，也知道什麼樣的結果是好的。人要做的是把自己的經驗拆出來，變成 AI 能理解、能執行、能複用的流程。
第二種是人不熟悉的領域。
這種時候寫Skill，最重要的就是建立一套回溯驗證機制。
因為這個場景下其實難得並不是讓AI產出內容，而是判斷它做的對不對。
比如我之前一直想做一個六爻占卜Skill。
這個場景看起來很適合Skill化，因為它有規則、有流程，也有很多資料可以參考。但真正做成Skill的時候，我發現它很難穩定下來。
我自己不夠懂占卜，我其實對於怎麼解卦毫無思路，然後AI也不懂，我們倆加一起沒辦法構建一個可靠的回溯測試系統。
我壓根不知道解卦到底是準還是不準，最後這個Skill我打磨了半個月還是放棄了。
測完這個Skill讓我感慨萬分，人不熟悉的領域倒不是說一定做不出來Skill，核心還是要看能否通過回溯機制來驗證。
比如在編程的自動化測試上，我也不是專業的測試工程師，但我可以讓AI設計一套測試邏輯，然後不斷通過回溯測試優化這套邏輯的合理性，最後讓AI把穩定運行的流程封裝成Skill。
所以寫Skill到最後考驗的不是語法，也不只是提示詞能力，而是人把場景SOP化的能力。