「這個很難講，我做給你看比較快」：怎麼把老鳥的判斷挖成一份 Skill
☰ 目錄 table-of-contents.md
問一個做了十年的老師傅「你是怎麼判斷的」，最常得到的回答是「這個很難講，我做給你看比較快」。這句話不是在敷衍，是真的講不出來。他的判斷來自幾百次的經驗累積，而那些經驗早就壓縮成直覺了，直覺本身沒有語言。
把這種知識寫成 Skill 的難處從來不在寫，在挖。文件格式十分鐘就學得會，難的是怎麼讓一個講不出來的人講出來。這篇談的是萃取的方法，我們自己用這套流程整理過幾份內部的 Skill，也在中間踩過幾個坑。至於為什麼值得做這件事，把同事的經驗煉成技能包那篇談得比較完整，這裡直接進到怎麼做。
問錯問題，就會得到廢話
最沒效率的問法是「你平常怎麼做這件事」。得到的答案會是一份流程摘要，聽起來很完整，但寫下來之後你會發現它跟網路上找得到的通用流程差不多。真正值錢的判斷全部不見了，因為那些對他來說太理所當然，理所當然到不覺得需要講。
比較有效的問法是繞過流程，直接問例外。
問「你什麼時候會停下來不做」，會挖出風險判斷。問「新人最常在哪裡出錯」，會挖出他自己早就內化的檢查點。問「上一次出包是什麼情況」，會挖出流程裡最脆弱的環節。問「有沒有哪次你覺得不對勁但說不出哪裡怪」，這題最難回答，但答出來的通常是整份 Skill 裡最有價值的一段。
共通點是：不要問常態，問邊界。人對常態沒有記憶，對意外才有。
四個步驟
第一步，挑一件事，不要挑一個領域。「把客服的知識整理起來」這種範圍做不完，也不知道從哪開始。改成「客訴進來之後判斷要不要退費的那一段」，就有邊界了。範圍小到一次訪談能講完，是這一步的驗收標準。
第二步，訪談的時候錄下來，不要邊聽邊整理。邊聽邊整理會漏掉你當下覺得不重要的細節，而那些細節常常才是關鍵。實際整理的時候你會發現，最有用的往往是他隨口帶過的那句「喔對，這種情況要先看一下有沒有…」。
第三步，把內容分成規則與例外兩堆。規則寫進 SKILL.md 主體，例外放進附屬檔案。這樣分的理由是規則每次都要遵守，例外只有特定情況要查，而附屬檔案沒被讀到就不佔成本。分法的細節在Agent Skills 是什麼裡有講三層載入的機制。
第四步，寫完拿回去給他看，但不要問「這樣對嗎」。問對不對，得到的答案永遠是「大概是這樣」。要問的是「照這份做，會在哪裡出錯」。這個問法會逼他去模擬執行，而模擬執行的時候他才會想起那些沒講到的條件。
寫出來的東西長什麼樣
老鳥知識的特徵是充滿門檻與例外，所以寫出來會比通用流程醜一點，但那正是它值錢的地方。
## 判斷原則
先看金額。低於某個門檻的直接處理掉，不用往上問，
因為往上問的溝通成本已經超過那筆錢。
超過門檻的，看是不是同一個客戶第二次。
第二次的處理方式跟第一次不同，重點不在這筆，
在確認是不是我們的流程有問題。
## 這些狀況先停下來，不要自己決定
- 對方提到「消保官」「申訴」等字眼
- 涉及個資外洩的可能
- 對方是合約客戶（條件在合約裡，不適用一般規則）
## 新人最常錯的地方
把「客戶很生氣」當成要讓步的理由。情緒強度跟該不該退費無關，
判斷依據只有事實。這點寫在最前面是因為它每個新人都會犯。最後那一段是整份文件裡最有價值的。它是一句只有帶過很多新人的人才講得出來的話，而且它擋掉的是一個會重複發生的錯誤。
哪些不值得寫
不是所有經驗都該變成 Skill。有三類寫了會後悔。
查得到的東西不用寫，工具的操作方式、規格、參數，模型本來就知道，寫進去只是增加維護負擔，而且它們變動的時候你的文件會變成錯的。
會頻繁變動的東西也不適合，例如具體的價格、廠商聯絡窗口、當期的活動規則。這些放進去等於製造一份需要高頻更新的文件，而高頻更新的文件通常會停止更新。要放的話，放判斷邏輯而不是放數值：寫「低於門檻直接處理」，門檻本身放在別的地方維護。
還有一類是純屬個人偏好而沒有理由的做法。老鳥習慣先做 A 再做 B，如果順序沒有實質差別，寫進去只會讓文件變長。判斷方式很簡單：問他為什麼是這個順序，答不出理由的就不用寫。
驗證：讓沒做過的人照著跑一次
寫完不等於做完。驗證的方式不是給老鳥看，是找一個沒做過這件事的人照著執行，然後在旁邊記錄他卡在哪裡。
卡住的地方分兩種。一種是文件沒寫清楚，補上去就好。另一種比較有價值：他做了一個你們沒想過的錯誤決定，而且從文件的字面上看他沒有做錯。這代表那裡有一個老鳥腦中存在但沒被說出來的前提，這種前提就是還沒挖乾淨的部分。
我們自己整理寫作規範的時候就遇過。文件裡寫了不要用某些制式開場，結果實際跑起來還是一直出現變體，追下去才發現老鳥腦中的規則其實是「任何形式的摘要標籤都不要」，而不是那份清單上列的那幾個。把規則本身寫出來之後，變體的問題才真的解決。
三個常見失敗
寫成了教科書。訪談完之後忍不住把背景知識、原理、歷史脈絡都補進去，最後變成一份很完整但沒人看的文件。Skill 是給執行用的，不是給學習用的，判斷標準是：這段拿掉，執行結果會不會變？不會就拿掉。
把人的職責寫進去。有些判斷不該自動化，尤其是需要承擔後果的那些。這類內容應該寫成「停下來問人」，而不是寫成判斷規則。界線的畫法我們在監督者角色與安全落地裡談過。
做完就沒人管了。這是最常見也最可惜的。老鳥的知識寫下來之後會隨著業務變化慢慢失準，而失準的文件比沒有文件更危險，因為新人會相信它。實務上的最低要求是每份 Skill 開頭寫上最後確認日期與負責的流程，讓過時這件事看得見。
從誰開始
如果有一個人明年要退休、或是有人手上握著只有他會的東西，那就從他開始，理由不用解釋。
沒有這種急迫性的話，比較好的起點是找那個「最常被打斷來問問題」的人。被問得最多，代表他腦中裝著最多別人需要但拿不到的東西，而且他自己通常也受夠了重複回答同樣的問題，配合度會很高。
我們自己也在做 AI 產品：Ocean Bot 業務助理、玄燈命理 DestineAI、PiMe AI 形象照，以及陪跑者 PACER 這個 AI 原生官網，都收在作品案例裡，可以看看落地之後實際長什麼樣。
如果你們正好有這樣一位同事，或是想把團隊裡分散的判斷標準整理成能交接的形式，這正是我們AI 自動化開發在幫客戶處理的事。跟我們聊聊你們現在最怕誰請假。
延伸閱讀
RoamerHost 幫你把開源 AI 與自動化工具一鍵代管：獨立 Docker、自動 SSL、24/7 監控，60 秒上線。省下租機器、裝環境、顧維運的力氣，訂閱就能開始用。
▶立即免費註冊常見問題
訪談老鳥時該問什麼問題？
寫完之後要怎麼確認有沒有漏掉東西？
哪些經驗不值得寫進 Skill？
該從哪個同事開始？
整理出來之後最常見的失敗是什麼？
這個主題的完整脈絡、選型比較與導入建議，都整理在指南裡。
訂閱免費電子報
把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧，整理成電子報寄給你。只寄精選內容、不灌垃圾信，一鍵就能退訂。