Day 27：把反覆的流程打包成 skill——但 skill 其實有兩種，選哪種是個判斷

前兩天講的是把判斷「沉澱成規範」（CLAUDE.md）和「沉澱成記憶」（HackMD）。今天講第三種沉澱：把我反覆在做、每次都得重講一遍的固定流程，打包成一鍵就能跑的 skill——讓判斷不只是被記住，還能被直接執行。

先講 skill 是什麼：它是一個資料夾，裡面一份 SKILL.md，寫清楚「什麼時候該用它、用的時候做哪些事」。Claude Code 在你講到對應的關鍵字時（例如我說「合併分支」「發佈」），會自動把它載進來、照著做。我手上有五、六個，全是我在這套系統上反覆會做的事：合併分支、發佈、把資料表結構轉成 ORM 定義、升級 Node 版本……

但用久了我發現，這些 skill 其實分成性質很不一樣的兩種，而選哪一種，本身就是一個判斷。

第一種：固化成 prompt 的 skill

第一種，本質上就是「把一套工作流用文字寫死」。SKILL.md 裡是一步步的指示，可能夾雜幾行 shell 指令，但沒有獨立的程式；觸發時，Claude 讀懂那份說明，照著做。

我大部分的 skill 都是這種。比如一個負責「合併分支」的 skill，裡面寫的是「合併完，對這次帶進來的檔案逐一跑語法檢查」這類步驟；一個「發佈」的 skill，把發佈流程連同那句危險的 rm -rf 精確路徑一起寫死；一個「把資料表轉成 ORM 定義」的 skill，寫的是查表結構的 SQL 和輸出格式的規範。它們的共同點是：內容是給 Claude 讀、由 Claude 去執行的指令，像一段被固定下來、每次都會照著跑的 prompt。

這種 skill 的長處是彈性——Claude 讀了會照做，也會依當下情況微調。但它的性質，其實跟前幾天講的 CLAUDE.md 是同一種：它是強預設，不是保證。 步驟寫在那裡，多數時候會被好好執行，但它終究是「指示」，不是「一定會這樣跑」的程式。

第二種：包了程式的 skill

第二種不一樣。它的資料夾裡除了 SKILL.md，還放著真正的腳本和資產檔，而 SKILL.md 的角色變成「叫 Claude 去跑那支腳本」，而不是「叫 Claude 自己一步步做」。

我的「Node 版本升級」skill 就是這種。它的資料夾長這樣：一支 upgrade.js 主腳本，加一組模板檔（新版的 app.js、package.json、共用工具檔、處理 EJS 的腳本）。SKILL.md 開宗明義就寫：「使用自動化腳本執行，人工只需確認標記為 TODO 的項目。」執行方式就是一行 node upgrade.js <專案路徑>，腳本自動把該複製的模板複製過去、該替換的替換掉、該移除的廢棄套件移除掉。

這種 skill 的性質，跟第一種正好相反：它是確定性的。 那支腳本每跑一次，做的事一模一樣，不依賴模型「記不記得步驟」「有沒有漏掉一步」。這正好對應 Day 25 講的那條線——真正要「每次都一樣、不能出錯」的機械操作，靠的不是文字指示，是一段實際會執行的程式。

這兩種怎麼合作：一套「制式」的工具，碰上一堆「不制式」的專案

有意思的是，這個包了程式的升級 skill，本身就演了一齣「確定性」和「判斷」怎麼分工的好戲。

它要處理的處境是：我有一批舊專案要從舊版 Node 升到新版，升級的大架構是制式的——middleware 怎麼換、package.json 怎麼更新、哪些廢棄套件要移除，每個專案都一樣。這部分，交給腳本自動跑，又快又不會漏。

但真實的舊專案，偏偏都有不制式的地方。所以這支腳本很聰明地沒有把所有事都硬幹到底：它自動做完能確定的部分之後，在結尾吐出一張 TODO 清單，把那些「不能盲目自動化」的項目一項項列出來，交還給人逐一確認——像某個字串填充的字元對不對、某段網路請求改寫後的錯誤處理和格式對不對、某個 ORM 運算子的結構有沒有正確傳進去、EJS 注入安全標頭之後頁面有沒有正常。

看出這個設計的漂亮了嗎：能確定的，交給程式一次做完；不能確定的，不硬幹，留給判斷。 它沒有假裝「自動化能解決一切」，也沒有因為「有例外」就乾脆不自動化。這正是前面一路在講的那條線，落在一個 skill 上的具體樣子——制式的量交給程式扛，不制式的判斷留給人。

一個插曲：skill 跟 CLAUDE.md 的界線

順帶記一個小插曲，剛好說明「什麼該當 skill、什麼該留在憲法」。

我有一組自訂的下拉元件，用法規則本來是寫在 CLAUDE.md 裡的。後來 /doctor 建議把它搬成一個獨立的 skill，CLAUDE.md 裡只留一行指標：「講到『自訂下拉』時，去看 custom-dropdown skill」。

它的理由，正好是 Day 25 談過的 context 成本：這組元件的用法很長，但只有在我真的要做下拉元件時才需要。留在 CLAUDE.md 裡，它每個 session 都被載入、每次都佔常駐額度；收成 skill 之後，平常不佔空間，等我講到關鍵字才被叫出來。常駐的通則留憲法，任務型、講到才需要的收成 skill 按需載入——這是 skill 和 CLAUDE.md 的分工。

這一天的分工

skill 是「把判斷沉澱成可執行」的形式，但這篇真正的重點在：skill 沉澱的，只是判斷裡「確定的那一半」。

AI 在這裡做的，是照著 skill 執行——prompt 型的照步驟走，程式型的跑腳本，這些機械性的量，外包得很乾脆。而人的角色有三層，一層比一層上游：一是決定把哪些反覆流程值得打包；二是決定用哪一種——這件事必須每次結果一模一樣嗎（包程式），還是需要依情況調整（固化 prompt）；三是接住程式吐回來的 TODO——那些「不制式」的部分，是自動化故意留給人的判斷，不是它的失敗。

所以 skill 不是「把人換掉」的工具，是「把人從制式的量裡解放出來、好專心處理不制式的判斷」的工具。程式扛掉重複，人扛住例外——這才是 1+1 大於 2 的地方。

這篇最後那張 TODO 清單，其實就是一種「我沒有照單全收」——自動化做完它能做的，剩下的我不簽字。這一路走下來，這種「按下暫停、不採用 AI 給的東西」的時刻，其實比想像中多。明天把它們攤開來看：我到底都在什麼時候不採用 AI 的建議？那些時刻，有沒有共同的形狀？