一個 skill 能活多久

Anthropic 在 7/24 發了一篇講 Claude 5 世代該怎麼餵 context 的文章，裡面有一句讓我停下來：他們把 Claude Code 的 system prompt 砍掉 80% 以上，效能沒有掉。

砍掉的是什麼？是過去這段時間大家辛辛苦苦疊上去的規矩——像「預設不要寫註解」「不要寫多段的 docstring」這種。以前是護欄，現在變成綁手綁腳。

這篇分享：那篇文章的重點、它反而讓我想到一個從來沒想過的問題（一個 skill 的壽命有多長），還有如果你從來沒做過實驗，你怎麼知道自己不是在鑽木取火。

【先講那篇在說什麼】

作者是 Anthropic 的 Thariq Shihipar。整篇在講一個轉向：以前是想辦法限制模型，現在是相信它的判斷。他列了一張前後對照表，我挑幾條：

給 Claude 明確規則 → 以前：給 Claude 明確規則 → 現在：讓 Claude 自己判斷

工具使用 → 以前：常會給 Claude 明確的工具使用範例 → 現在：更傾向把工具介面設計好

context → 以前：一次全部塞進去 → 現在：用到才載入

同一件事 → 以前：重複叮嚀 → 現在：工具描述寫清楚就好

記憶 → 以前：寫在 CLAUDE.md → 現在：用內建的自動記憶

其中最反直覺的是工具使用範例那條。他的說法是：提供工具使用範例，其實是把模型框在一個特定的探索空間裡。以前這是提升工具使用準確率的常見做法，現在更傾向把工具介面設計好。

他給的替代方案不是「少寫一點」，是「換個地方寫」。與其在 system prompt 裡叮嚀 AI 該怎麼用某個工具，不如把說明直接寫進工具定義；與其舉例，不如把參數設計得更會講話。他舉的 Todo 工具除了把狀態限定成 pending / in_progress / completed，也加上限制同時進行中項目數量的說明；透過更有表達力的介面，模型不必再依賴一長串工具使用範例。

skill（給 AI 的技能包，裝上去就多一套行為規則）也一樣：把它當成輕量的指引，讓 AI 需要的時候自己去找資訊，除非是特別重要的地方，不要寫得太死。太長的 skill 就拆解成多個檔案，用到哪份才載入哪份。

文章最後給了一個工具：在 Claude Code 打 /doctor，它會幫你檢查現有的 skill 跟 CLAUDE.md，看哪些該瘦身。

【那個我從來沒想過的問題】

看完我第一個念頭不是「我該去精簡 CLAUDE.md 了」，是另一件事：那我手上這堆 skill，有多少已經該退休了？

很多為了補足特定模型弱點而寫的 skill，可以視為當時模型的 patch；但記錄長期工作流程、領域規範或專案知識的 skill，不一定會隨模型換代失效。你會寫前一類 skill，是因為那時候的 AI 在某件事上做不好，你得手把手教。模型換代之後，AI 自己就會了——那份 patch 不會自動消失，它還躺在那裡，繼續把 AI 框在你半年前理解的那個做法裡。

Anthropic 自己刪掉 80% 的 system prompt，就是這件事的官方版本。他們有整個團隊在盯著模型能力，發現舊規矩過期了會動手清掉。我沒有。我的 skill 沒有一份標了日期，也沒有一份寫了「這條是為了繞過某個模型的弱點，那個弱點修好就刪」。

一個 skill 能活多久？我從來沒問過自己這個問題。

【你怎麼知道用了 skill 真的比較好】

再往下一層想，問題其實更早就開始了：我怎麼知道這些 skill 當初就真的有用？

我們裝一份 skill，通常是因為它看起來合理、作者有來頭，或者裝完那次剛好跑得很順。但這三件事都不是證據。沒有做實驗的話，你根本分不出來自己是在點火，還是在鑽木取火——旁邊明明就有打火機，只是你沒回頭看。

這件事 Day 63 那篇整理 eval（用一組固定任務去量 AI 表現的實驗）的時候寫過方法，土法煉鋼但很有效：替同一個專案開兩個獨立工作區（git worktree），A 裝 skill、B 不裝，跑同一批任務，然後比產出、比 AI 讀寫文字的用量（token）、比品質。同一套方法也能拿來比不同模型。

裡面還有兩個指標值得記一下：pass@k 是「k 次裡至少對一次」，pass^k 是「k 次全部都要對」。同樣 70% 的成功率，跑三次，pass@3 是 97.3%（約 97%），pass^3 是 34.3%（約 34%）。你要的是「能做到」還是「每次都做到」，量出來的數字差很多。

而且模型是會動的。Day 73 那篇我寫過一個比喻：AI 的產出像擲骰子，每次模型更新就像換一顆骰子——你沒辦法保證同一句 prompt 會擲出一樣的結果。一份 skill 在舊骰子上量出來的效果，換了新骰子之後還算不算數，只有重跑一次才知道。

【這個擔心不是空穴來風】

Day 128 我實測過一個真實案例。那時候我試 Google 工程師寫的 gws-forms（Google Workspace CLI 裡專門操作 Google 表單的那一組 skill），看起來夠有公信力了吧，結果跑出來是這樣：

有 skill：通過率 94.1% 沒 skill：通過率 96.9%

裝了 skill，錯得比較多。

原因回頭看，正好就是壽命問題。skill 裡寫死的做法過期了：Google Forms 的 API 預設會直接發佈表單，如果不要發佈，就得多帶一個 unpublished=true 參數，skill 沒寫到，AI 就照預設值做，使用者說「先不要發佈」還是建出一個已發佈的表單。另外三個 bug 也都是同一類——欄位寫法過時、JSON 格式不對、邏輯算錯。

沒裝 skill 的那版怎麼過關的？它沒有說明書，就直接去問 API 有哪些參數，從規格書裡看到 unpublished，用對了。

也就是說，那份 skill 不只是沒幫上忙，它反而讓 AI 發揮不出原本就有的能力：現場去讀最新的規格。這正是 Anthropic 那篇在講的——寫死的規則會把模型框在你當初理解的範圍裡。

【skill 會過期，那你的 harness 呢】

順著這條線再往上看一層，問題就更大了。

如果 skill 會過期，那你套在模型外面的整套控制機制（harness）也一樣會。這套機制包括：你給 AI 的指令（prompt）、技能包（skill）、在特定時機自動觸發的動作（hook）、串好的工作流程（workflow），以及不同 AI 執行者（subagent）怎麼分工。而且它是一層一層疊起來的：每加一層，都是你在某個時間點、對某個版本的模型、做的一個判斷。半年之後，底下那幾層還站不站得住腳，沒有人回頭確認過。

整疊東西搖搖欲墜，而且完全不會有任何徵兆。它不會壞掉，它只是悄悄變差——變慢、變笨、多繞路，而你以為那就是 AI 的正常水準。

【verify loop 是那張安全網】

這時候 verify loop（驗證迴圈：AI 做完之後再自己檢查一遍，沒過就重做）的價值就出來了。

Day 73 那場 meetup 聽到的一組數字，正好回答了這個問題：在 AI 準備結束工作時自動觸發的檢查（stop hook）裡掛上 verify 機制，跑五輪，可以讓單次完成度不高的模型收斂到 90 幾%；反過來，把一個完成度 80% 的 AI 執行者（agent）直接串五次、中間不檢查，最後只剩 30%。

verify loop 好在它不需要你先知道哪裡壞了。它不管你的 skill 是不是三個月前寫的、harness 那層判斷還成不成立——它只看最後的結果對不對，不對就重來。skill 是「我猜你這樣做會比較好」，verify 是「做完給我看結果」。skill 會過期；以最終結果為準的 verify loop 通常更耐模型換代，但它依賴的測試、rubric 與成功條件也必須持續更新。

主要成本是額外的 token、延遲與運算成本，而且只有在驗證條件能捕捉該錯誤時，verify loop 才擋得下來。跟你維護一整套可能已經過期的 skill 比起來，這樣還划算得多。

skill 有沒有過期，你可能永遠不會發現；但在驗證條件能抓到錯誤時，verify loop 會幫你擋下來。

最近開始做免費的一對一諮詢，幫你把 AI 接進自己的工作流程——有需要的話可以約：https://www.dawsonwang.com/

資料來源： The new rules of context engineering for Claude 5 generation models（Anthropic，2026-07-24，作者 Thariq Shihipar）https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models 擷取：2026-07-28

延伸閱讀： Day 63 驗證迴圈與 Eval——怎麼確保 Claude 的產出是對的 Day 73 Claude Code Meetup：被低估的 eval 與 verify Day 128 不要迷信 skill