經驗具現化——讓工作流成為穩定的存在
EP00：這個系列想說的事
記得剛成為工程師的時候，同事們有交流過怎麼記錄自己的開發 tips。其中一個人維護著一份純文字的小抄，有點長，裡面塞滿了他常用的指令、踩過的坑、某個服務的設定步驟。每次換電腦或進新專案，第一件事就是把那份小抄搬過來。
後來有了 Dropbox，那份小抄就漸漸長大了。不只是一個檔案，變成一整個資料夾。同步方便了，內容也就不客氣地膨脹起來。現在回頭看可能覺得奇怪，怎麼不用版本控制系統呢？git 那麼方便好用。因為在那時候，還不流行啊。
再後來，大家開始用 private GitHub repo 放自己的 dotfiles（.bashrc、.vimrc、.editorconfig 這些）、automation script、甚至打包成 Homebrew package。工作習慣搭上了版本控制和自動化，看起來比純文字進步了不少，但做的事其實一樣，就是把自己的工作經驗封裝起來，讓重複的事不用再想。
我在那時也有了這個概念，時不時都在優化自己的開發環境和工作經驗的記錄。這裡有一條線值得指出來：只要你能把小抄裡可自動化的部分變成 script、變成 shell profile、變成一個動作（function）、變成你自己的 setup automation，小抄的內容就可以變小，因為它漸漸成為具體可執行的檔案，或是你開發群體內的最佳實踐。開發流程也跟著變得穩定。當你累積了足夠的 credit，這些東西可以成為團隊內建立新工作流程或軟體專案的範本，需要額外做的事又會更少了。
只是到了現在，形式又換了一次。
這兩年，隨著 agentic workflow 逐漸受到開發者喜愛，我也用 Claude Code 在做一樣的事情。不只是叫它寫程式，而是跟它一起跑部署、看帳單、管工作進度、甚至在我離開的時候把剩下的事做完。這無關於 AI agent 是否有這些能力，它需要知道的是你的期望和偏好，而這些是 LLM 的學習材料裡沒有的，因為它不是普遍的知識。是我在反覆使用的過程中，把摩擦到的地方一個一個修掉，慢慢發展出自己的 plugins。
封裝這些能力的方式，是 Claude Code 的 plugin 和 skill。skill 是一份 markdown，裡面寫的是「遇到這種事該怎麼做」的知識。plugin 是把一組 skill 打包起來，可以安裝、可以更新、可以跨機器同步。
聽起來很正式，但它就像我們過去在各種 IDE 環境裡安裝過的 plugin。只是在過去，要自己擴充 IDE plugin 的門檻稍微高了一點。對比之下，給 Claude Code 裝上 plugin marketplace，再選擇要用的 plugin 裝上，難易度明顯不同。說穿了，它就是新一代的小抄。
差別在於，以前的小抄要自己看仔細，自己努力把每一步做對，特別是那些得嚴肅看待的 deploy 任務。現在是 AI 替你看，幫你注意細節，你只需要 review 和 approve。但本質沒變，都是你的工作經驗，用你習慣的方式，解決你反覆碰到的問題。
但光是把經驗寫下來還不夠。「經驗」這種無形的東西，寫成文字之後多少會失真。而看的人又各有各的主觀認定，可能忽略了一些前置條件，結果難以被複製。以前的小抄就有這個根本問題：你寫了，但不一定會照著做。步驟可能跳過、順序可能打亂、某個你覺得不重要的細節被省略。小抄是靜態的文字，它不會反抗你的偷懶。
Skill 不一樣。你把工作流寫成 skill，AI 會逐字照著跑。跑的過程中，它會碰到你沒想到的 edge case、會踩到你描述得不夠精確的地方、會在某個步驟卡住然後回報。這些摩擦不是壞事，它讓你看見自己的工作流裡有哪些是真的穩固的、哪些只是你以為穩固的。
當你的經驗被具現化成 skill，它就有了固定的形體。有了形體，才能被反覆執行、被檢驗、被打磨。每次碰壁都是一次回饋，每次修改都讓它更穩定一點。經過反覆的使用和打磨，你會發現摩擦越來越少。到了某個程度，你會開始有點信任感，在可以授權的範圍內，讓它獨自完成一些事情。
這就是「讓工作流成為穩定的存在」的意思。不是一次到位，是磨出來的。
這個系列記錄的就是這樣一個過程。我的工作流怎麼從腦袋裡的模糊經驗，變成可以被執行、被檢驗、被持續改善的 skill 和 plugin。你不會看到我發佈什麼通用的 plugin，這裡只是個講故事的系列。而那些歷程與經驗，都是個人化的。