「要幫 AI 寫一支 skill，是不是要先坐下來，把這個領域的規則想清楚、列完整,再一次寫好？」
如果你也這樣想過，今天的案例可能會顛覆這個直覺。昨天講到 skill 的本質是「把一次性經驗提煉成可重複套用的規則」，但這句話講起來抽象，今天想具體走一次這個過程——不是一次坐下來寫完的，是一次犯錯開始的。
假設有一個團隊，AI 負責處理日常的 bug 修復任務。有一次，AI 接到一個回報,直接動手改了程式碼、跑過測試、開了 PR。人審查時發現：這段程式碼原本完全沒有測試覆蓋,AI 改完之後也沒有補測試,只是確認「原本能動、改完也能動」就算完成。
使用者當場指出這個問題——沒有測試覆蓋的程式碼,改動前後「看起來一樣能動」不代表真的沒有影響到其他情境,只是沒有東西能告訴你改壞了。這個修法本質上是在賭運氣。
AI 接受了這個糾正,但這時候只是「這一次被糾正」,還不是一條規則。如果下一次遇到類似情境,AI 有沒有可能又忘記先確認測試覆蓋,直接動手改?機率不低——因為這個糾正還只存在於這一次對話裡,沒有被保留下來。
於是這件事被記進一則備忘：AI 動手改任何程式碼前，要先確認這段程式碼有沒有測試覆蓋；沒有覆蓋的話,要先停下來回報,不能直接動手（除非任務本身就是「補測試」）。 備忘裡同時記下「為什麼」——不是規則本身要求要有測試,是「沒有測試覆蓋的改動,沒辦法驗證有沒有意外影響到其他情境」這個更根本的理由。
這一步很關鍵，但很多團隊到這裡就停住了——備忘寫了,下次任務開始前卻不會主動去翻,因為備忘散落在一堆其他記錄裡，沒有明確的觸發時機告訴 AI「現在該讀這一條」。
備忘要變成真正能發揮作用的規則,還差一步：要有明確的觸發情境,讓它在對的時候被讀到，而不是靜靜躺在一堆紀錄裡等人記得。 於是這條備忘被提煉成一支 skill——內容不是逐字複製備忘,而是重新組織成「動手改程式碼前，先確認測試覆蓋」這條規則,加上「這支 skill 什麼時候該被套用」的明確描述,讓它在「要修改既有程式碼」這類任務出現時自動被載入。
用一組對照來看這兩個階段的差異：
❌ 只停在「記進備忘」：
備忘裡寫著「上次因為沒確認測試覆蓋被糾正過」，
但沒有明確的觸發情境,下次任務開始時
不會主動被讀到,只有剛好想起來才會翻出來看
→ 教訓存在,但沒有機制保證它會在對的時候被套用
✅ 提煉成有明確觸發情境的 skill：
skill 開頭寫明「這支 skill 在『要修改既有程式碼』
這類任務時要套用」，內容是重新組織過的規則,
不是備忘的逐字複製
→ 教訓變成一個會在對的時機自動出現的規則,
不需要仰賴「剛好記得要去翻」
這個過程最容易被誤解的地方是：以為 skill 是「先想清楚規則、再寫成文件」，實際上大部分真正管用的 skill,是先有一次具體的犯錯,才反推出規則該長什麼樣子。 先寫好的規則往往涵蓋不到真正會出錯的細節,因為那些細節只有真的犯過一次錯才會浮現。
不是每一次糾正都要立刻寫成 skill。判斷的依據回到 Day 04 講過的三個標準：這類情境會不會重複出現、影響範圍夠不夠廣、有沒有明確的觸發情境可以描述。 如果一次犯錯只是單純的手誤、跟特定情境高度綁定、不太可能在別的任務裡重演，記進備忘就夠了，不需要每次都升級成 skill——升級的成本不只是寫這份文件，還包括之後每次符合觸發情境時都要載入它，太多瑣碎的 skill 反而會製造 Day 03 講過的那種雜訊問題。
回想你自己團隊裡（不管是跟 AI 協作,還是跟人協作）曾經發生過的一次糾正：那次教訓,現在還活在某個人的記憶裡，還是已經變成一條會在對的時機被想起來的規則？
明天要講一個容易被忽略、但決定 skill 能不能被正確套用的細節：skill 開頭的「定位」段落，為什麼常常比規則本身還重要——這也是第一部（Day 1-7）的最後一篇，會簡短回顧這一週講的內容。
iThome鐵人賽
看影片追技術