你的工程直覺，是最值錢卻最脆弱的資產
如果你做過三年以上的軟體開發或資料工程，腦袋裡一定累積了大量的「條件反射」。
收到一張 on-call alert，你知道先看哪個 dashboard、點進哪個 log group、用什麼關鍵字過濾。接手別人的 data pipeline，你第一眼看的不是邏輯而是有沒有做 null check 和 schema validation。接到新需求，你在心裡三秒內就評估出是一天的活還是一週的活。
這些判斷幾乎不需要思考。但如果有人問你：「能把你這套判斷寫成文件讓新人照做嗎？」你大概會愣一下。
知識管理研究把這種「知道怎麼做但說不出來」的東西叫做隱性知識（Tacit Knowledge）。野中郁次郎在上個世紀提出的 SECI 模型裡，「外化」（Externalization）是把隱性知識轉成顯性知識最關鍵的環節——而這個環節一直是組織裡最大的瓶頸。
直到 AI 輔助開發工具成為日常，一個新的載體出現了：Skill。
Skill 不是文件，不是 README，不是 prompt template。它是一份可被 AI 自動發現、自動載入、按步驟執行的工作流程規格。寫好的 Skill，相當於把你的工程直覺變成了一個 AI 能呼叫的 API。
這篇文章拆的是：你要怎麼走完「從腦袋裡的經驗到一份可靠的 Skill」這整段路。
Skill 的運作邏輯：不是 AI 一口氣讀完的
在開始寫之前，先理解 AI 怎麼「使用」你的 Skill，否則你會在錯誤的地方花力氣。
AI 載入 Skill 不是「打開一份文件全部讀完」。它遵循一套漸進式揭露（Progressive Disclosure）的邏輯，概念源自 1980 年代人機互動界面設計原則——先呈現最關鍵的資訊，使用者需要時再展開細節。AI 工具把這套思維搬進了 Skill 載入機制：
第一層：Frontmatter 裡的 description。每次對話 AI 都能看見，token 消耗極小，但它要靠這幾句話判斷「現在的任務跟這個 Skill 有關嗎」。這是決定生死的篩選器。
第二層：SKILL.md 內文。AI 判定這個 Skill 跟當前任務相關後，才會把 body 載入 context。你的完整指令、判斷邏輯、限制規則都在這裡。
第三層：references/ 目錄裡的額外資源。API 文件、範本檔、範例程式碼。AI 有明確需要時才會往裡面翻。
對工程師來說，這個架構非常直覺——它跟你寫函式庫的思路完全一致。description 是 README 首段，body 是 API 文件，references 是 examples/ 目錄。
理解了這一點，你就知道：frontmatter 沒寫好，後面的內容再精彩都是白寫。
第一步：用真實情境把經驗挖出來
工程師最常犯的錯是跳過萃取步驟，直接坐下來寫 SKILL.md。
結果寫出來的東西不是太抽象（「分析問題並提出解決方案」），就是太瑣碎（逐行列出十五個 CLI 指令卻沒說什麼時候該用哪個）。
正確做法是先回到你的真實工作場景，帶著「如果 AI 要代替我做這件事，它需要知道什麼」的視角，回顧至少三到五個實際案例。
打開你最近一個月的工作筆記、Slack 對話、或 PR review 紀錄。找出你重複做過的工作。如果你能在三個不同案例裡，找到相同的判斷模式，那就是一個值得封裝成 Skill 的候選項。
然後用 AI 做結構化訪談。不是叫它「幫你寫 Skill」，而是請它從你的案例裡歸納出規則：
我最近處理了這三個 data pipeline 故障案例：
[案例 A：上游 schema 變更導致下游 null pointer]
[案例 B：Kafka lag 激增導致處理延遲]
[案例 C：S3 權限更新後 ETL job 靜默失敗]
請從這三個案例歸納出：
1. 我判斷問題類型的依據是什麼
2. 我排查的固定順序或優先級
3. 我在什麼條件下會跳過某些步驟
4. 我絕對不會做的事（例如不手動改 production table）
這個做法有效的原因是：AI 從具體案例裡提取模式的能力極強，但它沒辦法憑空猜你的偏好。你給它素材，它幫你找到自己沒注意到的規律。
幾輪來回後，你手上會有一份粗糙但真實的流程文字稿。這不是最終的 Skill，但它是你最真實的原材料。
第二步：把原材料壓進工程結構
有了文字稿，接下來是結構化。這一步決定 AI 能不能按規格執行你的流程，而不是自由發揮。
從 data engineering 的角度，我把它想成 schema design——你定義的不是資料欄位，而是 AI 處理任務時的「判斷欄位」和「轉換規則」。
一份好 Skill 的 body 通常由以下幾塊組成（不是每次都全用，依複雜度選配）：
決策分支：讓 AI 根據輸入走不同路
你的工作流程裡，有些路口是要做判斷的。同一類型的問題，來源不同、嚴重程度不同，處理方式可能完全不同。
沒有決策分支的 Skill，AI 每次都走預設路徑——通常就是它認為「最安全」的那條，但不見得是你需要的那條。
設計決策分支時，保持節點在四個以內。每多一個判斷層，AI 的執行準確度都會下降。這跟你設計 data pipeline 的 branching logic 一樣——分支太多等於沒有分支。
步驟流程：寫得像 runbook，不像說明書
執行步驟要寫成 AI 能直接操作的指令，不是概念描述。
差的寫法：「檢查資料品質」。好的寫法：「對目標表格的最近一批資料執行 null count，若超過 5% 則停止後續步驟並回報」。
把每一步想成 runbook 裡的操作條目——你在凌晨三點被叫醒、腦袋只清醒一半的時候，還能照著做的那種清晰度。AI 也需要這種清晰度。
禁止清單：你的血淚教訓
這是整份 Skill 裡投入產出比最高的段落。
社群實踐反覆驗證了一件事：告訴 AI 「不要做什麼」的效果，往往比告訴它「要做什麼」更顯著。因為 AI 在缺乏明確限制時，傾向用最通用的方式填補空白——而這些「通用方式」偏偏是工程場景中最危險的。
每一條 NEVER 背後應該對應一個你實際遇過的問題。例如：
- NEVER 在沒有 dry-run 的情況下修改 production 資源
- NEVER 假設上游 schema 不會變，必須做 defensive parsing
- NEVER 把 credential 寫進程式碼或 log 中
這些不是通用安全守則——它們是你踩過好幾次才學會的東西。正因為來自真實經驗才有價值——AI 自己不會產生這些規則，它不知道你的組織裡「什麼事情出過包」。
完工驗收條件：什麼叫「做完了」
沒有完工條件的 Skill，AI 不知道該在哪裡停下來。它可能過早結束，也可能在不需要的地方繼續鑽牛角尖。
好的完工條件應該是可機械驗證的，例如：
- 所有相關測試通過
- 輸出檔案符合指定 schema
- git diff 範圍在預期之內
- 無 lint error 或 type error
這跟 data pipeline 的 quality gate 完全一樣的思路——你不會讓一條沒通過 data validation 的管線上線，也不應該讓一個沒通過驗收的 Skill 執行結果被採用。
第三步：Frontmatter——三行字決定整個 Skill 的命運
回到漸進式揭露的第一層。frontmatter 裡的 description 是 AI 判斷「要不要載入這個 Skill」的唯一依據。
很多人把 description 當成欄位填一下就好。然而，它的本質更接近你在設計 API 時寫的 endpoint 路由規則——它定義的是什麼 request 應該被 route 到這裡。
一個設計得好的 description 同時包含三個維度：
正向觸發條件（什麼情況應用這個 Skill）：
USE FOR: data pipeline 故障診斷、ETL job 靜默失敗排查、
上下游 schema 不一致的問題定位
反向排除條件（什麼情況不要用）：
DO NOT USE FOR: 本地開發環境除錯、SQL 查詢優化、
新 pipeline 的架構設計（改用 pipeline-design skill）
語意觸發詞（使用者可能的說法）：
Trigger words: pipeline broken, ETL failed, data missing,
schema mismatch, job stuck, 資料遺失, 管線故障
反向排除條件是最被忽略卻最重要的設計。沒有邊界的 Skill 就像一個沒有 content-type 檢查的 API endpoint——什麼 request 都能打進來，但真正該處理的反而被噪音淹沒。
第四步：用 AI 生成初稿，再用你的經驗修正
有了結構化的素材，現在可以請 AI 幫你組裝第一版 SKILL.md。
給 AI 的 prompt 應該包含完整的上下文，而不只是一句「幫我寫個 Skill」：
我要建立一個 Agent Skill，用途是 [一句話描述]。
以下是我從實際案例歸納出的素材：
## 觸發時機
[你從第一步得到的觸發條件]
## 不適用情境
[明確列出不該觸發的場景]
## 判斷分支
[你整理好的決策節點]
## 執行步驟
[你的 step-by-step 流程]
## 紅線
[你的 NEVER 清單]
## 完成標準
[可驗證的完工條件]
請依照 SKILL.md 格式輸出，frontmatter 包含 name 與 description，
description 要同時有正向觸發詞和 DO NOT USE FOR 排除詞。
AI 生成的初稿通常有兩個問題：
- 步驟描述太通用。AI 會把你具體場景的邏輯抽象化，例如把「檢查 Kafka consumer group lag」泛化成「檢查訊息佇列延遲」，反而失去了精確性。
- 夾帶 AI 本來就會做的事。「確保程式碼可以編譯」「使用正確的 Markdown 格式」這類敘述完全是冗餘——AI 不需要你提醒它做基本的事，寫這些等於在浪費 context 空間。
初稿拿到手之後，你要做的修正工作：
- 把被泛化的步驟改回你的具體場景用語
- 刪除所有 AI 本來就會做的敘述
- 確認每一條 NEVER 都對應一個你刻骨銘心的真實事件
你寫進 Skill 的每一行，問自己一個問題：「這一行，如果拿掉，AI 的輸出會變差嗎？」。如果答案是「不會」，拿掉它。真正有價值的內容是那些只有你知道、AI 憑自己想不出來的東西。冗餘內容不只浪費 token，還會稀釋真正重要的指令的權重。
第五步：三維測試——Skill 不是寫完就能用
你不會把一條 data pipeline 寫完就直接上線跑。Skill 也一樣。
測試 Skill 有三個不同的驗證維度，每個維度抓的是不同類型的問題：
觸發邊界測試
你的 description 精準嗎？準備三組對話：
- 正面：明確屬於這個 Skill 對應的場景。例如「幫我查 pipeline X 為什麼今天早上沒跑」
- 同義改寫：換個說法，語意相同。例如「ETL job X 的 output table 今天是空的，什麼狀況」
- 不相關：語意完全不同。例如「幫我寫一個 Python 函式讀 CSV」
如果前兩組沒觸發，description 太窄。如果第三組也觸發了，description 太廣。
流程合規測試
觸發之後，AI 有沒有真的按照你寫的步驟走？
重點不是看 AI 是否完成了任務——而是看它有沒有跳步驟。AI 模型看到不夠具體的步驟描述時，傾向自行判斷重要性，然後略過它認為不重要的。
跳步驟幾乎都指向同一個根因：那個步驟的指令不夠具體。把「檢查相關設定」改成「讀取 config.yaml 中的 source_table 和 target_table 欄位，確認兩邊 schema 版本一致」，跳步驟的問題通常就解了。
有 Skill vs 無 Skill 對比測試
同一個任務，分別在有 Skill 和沒有 Skill 的條件下各跑一次。比較輸出品質。
如果差別不顯著，代表你的 Skill 沒有真正在引導 AI——可能是因為 body 裡的內容大部分是 AI 本來就會做的事。這時候需要回頭重新提煉，增加真正源自你獨特經驗的部分。
迭代才是主體，初版只是起點
如果你做過 data pipeline 的開發，你知道一件事：第一版永遠不是最終版。
Schema 會演進，上游會改格式，業務邏輯會調整。你的 pipeline 因此需要持續維護。Skill 完全一樣。
每次 AI 執行你的 Skill 之後，觀察結果跟你預期的差距在哪。不要只接受或拒絕輸出——回去看是哪一條規則沒寫清楚，把它修正。
幾個常見的迭代情境：
AI 不觸發 Skill：通常是 description 裡缺乏足夠的關鍵詞覆蓋。一個有效的 debug 方法——直接問 AI「你什麼時候會使用這個 Skill？」，它會引述 description 回答，你馬上能看出缺口在哪。
AI 觸發太頻繁：需要加反向排除條件。明確告訴它「這不是你的事，遇到 X 場景請用另一個 Skill」。
AI 跑完但結果不對：步驟描敘不夠具體，或判斷分支遺漏了一種情境。
AI 做了不該做的事：NEVER 清單需要擴充，補上你剛發現的新邊界案例。
每一次修正都讓 Skill 更精確、更可靠。這個循環就是把你的經驗一點一點「編譯」進 Skill 的過程。
分類思維：不是所有 Skill 都在產出程式碼
工程經驗不只有寫程式碼這一種。你的判斷力在不同環節有不同形態，對應的 Skill 設計也該不同。
陪伴思考型：引導你釐清思路，不直接產出。例如需求評審——AI 不該直接開始實作，而是先問你一系列問題。這類 Skill 的特徵是輸入開放、輸出是決策方向而非程式碼檔案、工具需求最低。
規劃型：把模糊需求轉成可執行計畫。它的輸出通常是結構化文件（task list、architecture decision record）。這類 Skill 需要你的 schema 設計經驗——什麼欄位必填、什麼欄位有預設值、什麼格式是上下游能接受的。
執行型：拿到明確規格就開工。寫測試、做 code review、跑部署流程。這類 Skill 的步驟最詳細、NEVER 清單和完工條件最嚴格，因為執行型的錯誤成本最高。
你在開始寫之前，先判斷你的 Skill 屬於哪一種。不同類型的結構重心不同——把規劃型 Skill 寫成執行型的步驟會太死板，把執行型 Skill 寫成思考型的開放式引導會失控。
結語：你的經驗值得被編譯
Skill 的門檻不高——一個資料夾、一個 Markdown 檔案。但寫好它需要的不是 prompt 技巧，而是你對自己工作流程的深度理解。
Anthropic 在設計 Agent 系統時反覆強調的一個原則是：工具的界面設計和工具本身同等重要。SKILL.md 就是你和 AI 之間的界面。你花在設計它上面的心思，不會亞於你花在程式碼上的心思。
最終，一份好的 Skill 不只是給 AI 看的技術文件。它是你多年經驗的一次知識結晶——可版本控制、可測試驗證、可持續演進。
你腦袋裡那些「不用想就知道」的東西，值得被寫下來。不是寫在 Notion 裡讓人偶爾翻閱，而是寫成一份 AI 能直接執行的規格，讓你的判斷力在每一次任務中自動發揮作用。