skill 不是裝越多越好
週二晚上是我們 trAIgon AI 小聚的第二場。場地是開了十八年的紅球攝影棚，這幾個月被老闆改成 AI 基地。
那天我準備的簡報，開場十分鐘就決定不講了。skill 這件事的方向已經反過來了：以前是想辦法把知識塞進去，現在是想辦法把模型本來就會的東西拿出來。這篇整理那天真正討論出東西的幾段：skill 到底該怎麼寫、什麼東西不該寫成 skill、實作要不要交給便宜的模型，還有現場撿到的兩個做法。
準備好的簡報，開場就作廢
原本要講的是「AI 看別人用起來很厲害，自己用就卡卡的」，分享一些心法。結果自我介紹繞一圈聽下來，在座的程度比我預期高——有人一次訂三個 200 美金的方案還不夠用，有人已經在自己安排 subagent 的角色分工。
那個簡報講出去只會浪費大家的兩個小時，所以我當場改成講我現在身為工程師遇到的痛點怎麼解。後面一個多小時就一路變成互相討論，我被晾在旁邊聽了一大段——這反而是我想要的樣子。
skill 還沒被觸發，就已經在吃你的 context
那天最有爭議的一段，是「一個流程到底該寫成 skill，還是寫成一份文件就好」。
先講機制。你裝的每一個 skill，它的 name 跟 description 會在每次開 session 的時候，跟著 system prompt 一起送出去。它一開始就送，不是等你用到才送。這件事我自己撈過送出去的 request 驗證過，跟官方文件寫的一樣。
現場有人提到，這批 name 跟 description（也就是每個 skill 的 metadata）大概會佔掉整個 context 的 3%，skill 累積到五、六十個之後，就會開始被迫一個一個砍掉。所以 description 要寫短——很多人叫 AI 生一個 skill，description 一寫就是一百字以上，五十個 skill 就是五千字，還沒開始做事就先付出去了。
這裡我分享我自己的一招：有些 skill 我根本不希望模型主動觸發它，它的入口是另一個 skill，該觸發的時候由那個 skill 來叫。這種我就直接把 description 留空。模型不需要知道它在幹嘛，那就沒必要為它付這幾十個字。
另外一個實際踩到的坑是：我把在 Claude 這邊產好的 skill 搬去 Codex，它直接報錯，說 description 太長。Codex 那邊的長度限制比較嚴。所以短不只是為了省 context，也是為了搬得動。
SKILL.md 應該是目錄，不是手冊
skill 跟一份文件真正的差別，在於漸進式揭露（progressive disclosure）——它分三層載入：
- metadata（name + description）：一定會載入，你不用它也載入
- SKILL.md 全文：被觸發之後才整份讀進去
- SKILL.md 裡提到的其他檔案：模型判斷跟現在這件事有關，才去讀
關鍵在於第三層不是自動發生的。你把所有細節都塞在 SKILL.md 裡面，觸發的那一刻就是整包灌進 context，一層都沒省到。要拿到分層的好處，你得自己把細節移到別的檔案，讓 SKILL.md 只留下一份目錄，告訴模型「這裡面有什麼、什麼情況該去翻哪一份」。
所以那個問題的答案是：只有在 SKILL.md 寫得像目錄的前提下，skill 才比丟一份文件給它讀好。如果你的 skill 只是把一份 workflow 文件包了一層，那你多付的是前面那幾十個字的 metadata，什麼都沒換到。
什麼東西不該寫成 skill
第一個判斷不是「這個要不要寫成 skill」，是「這件事需不需要模型來判斷」。
如果它是確定性的——同樣的輸入每次都該給你同樣的輸出——那就寫成程式，讓程式去跑。skill 本質上是靠模型的理解在運作，所以它每次的結果會不一樣。跟文字相關、需要判斷的部分留給 skill，其他環節寫成程式會穩定得多。
第二個判斷是模型現在會不會。這件事的方向已經整個反過來了：以前大家是把 prompt 一直往 CLAUDE.md 塞，塞到太大，再抽出來變成 skill。現在是把東西塞進 skill 之後，發現模型本來就做得很好，於是精簡，或者直接拿掉。
現場有一組正在做的實驗更激進：他們把 workflow 的定義整個拿掉，只告訴主 agent 有哪些 subagent、每一隻的能力是什麼、目標在哪裡，剩下的讓它自己分配。他們的說法是這樣 context 又更少了。
我自己的做法是把 skill 集中管理，再針對不同專案用 symlink 掛過去。這樣每個專案只看得到跟它有關的那幾個，不相關的連 metadata 都不會出現。
實作丟給便宜的模型，這件事現場沒有共識
一派的做法是：規劃、寫 spec、驗收都用最強的模型，實作丟給便宜的。有人的主 agent 用 Opus，底下並行八隻 subagent 全跑 Sonnet，從 research 到寫程式都是。他不用 Haiku，對他來說太弱。
馬上有人反對：spec 寫得再細，都有寫不進去的模糊地帶，出事就是出在那些沒寫上去的地方。他說自己已經讓 AI 加了很多 guard，上線前會擋掉一堆東西，即使這樣他還是不敢信任便宜的模型。
最後收斂到的不是「該用哪個模型」，是兩件 AI 出現之前工程師本來就在做的事：把功能切到夠細，還有驗收條件要先講清楚。切得夠細，便宜的模型不會做歪；驗收條件先寫清楚，它有沒有做到你才驗得出來。
我自己想補充的是模型降智、突然變弱這件事。Day 198 我寫過 Codex 那一次——5.6 剛推出的時候各種任務都很強，撐不到一個禮拜就明顯變弱，那段時間他們一直在重置大家的週用量。後來我就切回 GPT-5.5，現在固定用它——用的人少，相對穩定。現場有人補充這跟時段也有關，凌晨一兩點是美國那邊的上班時間。
現場撿到的兩個做法
測試之前先把環境架好。 有人分享他實測的結果：開 session 之前如果沒有先幫 AI 把環境準備好——Docker 起來、DB 配好——它不會自己去起環境。不起環境，它就不會去參照專案裡既有的 end-to-end 測試規範，然後寫出來的測試會自己腦補，還會跟你說寫得很漂亮。同一隻模型，環境在跟環境不在，寫出來的測試品質差很多。
用呼叫關係圖取代整包搜尋。 現在 agent 要改一個功能，通常是用 grep 或 rg 去搜相關的片段，搜出來一堆用不到的東西，全部進 context。但我們自己寫程式的時候，IDE 之所以能按著 Cmd 點一下就跳到定義，是因為背後有 language server 幫你算好誰呼叫誰。同樣的關係可以先算成一張網狀圖，agent 要找東西的時候直接查圖，不用整包掃。現場推薦的是 graphify，分享的人說裝了之後 context 佔用壓在 10% 以內。
為什麼我要辦這個
會後收到一則回饋，我看了很久：
我覺得你真的很有心，願意做 AI 社群，照顧大家（有點像 AI 義診）。聽你分享受益良多，也因為有這個群，召喚出其他 AI 同好，這很重要。現在 AI 能變出什麼，多一點想法，對大家都有幫助。我會持續支持你。
「AI 義診」這個說法我很喜歡。我覺得技術上的突破現在已經收斂到一個程度了，真正有價值的是業界的案例——各行各業現在遇到哪些痛點、每天花最多時間在處理什麼，然後我們能不能用工程的背景加上一些創意的解法，把那件事的成本壓到最低，甚至直接自動化掉。
這種東西是簡報做不出來的，只能一群人把各自的痛點攤開來互相丟 idea。
下一場 trAIgon v3｜誰是下一個壹加壹，晚上七點到九點，在台北松山的紅球攝影棚（八德路三段 186-1 號），報名在這裡：https://luma.com/0h75ffdk
不用準備簡報，把你的痛點帶來就可以，不用有解法。
一句話總結：skill 不是裝越多越好，模型本來就做得很好的，精簡，或者直接拿掉。
最近開始做免費的一對一諮詢，幫你把 AI 接進自己的工作流——有需要的話可以約：https://www.dawsonwang.com/
- Day 198 Codex 降智 別被單一 AI 綁死
- Day 234 幫你的 subagent 們找一個老大
- Day 239 我做的 AI 社交特使怎麼設計
- trAIgon v3 報名：https://luma.com/0h75ffdk