010. 導言｜真正的問題不是 Skills 太多，而是舊指令沒有被清掉
Nate Herk 這支影片的標題很有挑釁性：他刪掉所有 Claude Skills 之後，Claude 反而變聰明了。
但影片真正有價值的地方，不是鼓吹大家立刻把 Claude.md、skills、hooks 全部清空。它談的是一個更細的現象：當模型能力升級時，舊模型時代留下來的補丁，可能會從「幫助模型」變成「限制模型」。
來源影片在這裡：Nate Herk：I Deleted All My Claude Skills... And Claude Got Smarter。
影片引用了 Claude Code 共同創作者 Boris Cherny 在 Y Combinator 訪談中的說法。Boris 提到，Claude Code 作為產品與 harness 一直在變；每次新模型推出，Anthropic 都會刪掉一批 system prompt、修改工具集合，也會重寫工具 prompt。原因很簡單：不同模型有不同缺陷、不同強項，也需要不同提示方式。對 Opus 5 這類更聰明的模型來說，很多原本用來補救弱點的系統提示，模型現在自己就做得到。
這個觀點對所有 agent 使用者都很刺耳。過去幾年我們一直被教導：要寫更完整的 prompt，要累積更多偏好，要把 workflow 變成 skills，要把每個細節都交代清楚。可是如果模型變強了，這些「好習慣」沒有更新，就可能變成累贅。
這篇導讀的立場會保守一點：不是「刪掉所有東西」，而是「定期重新審查哪些指令還有價值」。你要留下的不是一堆過時規則，而是模型真的無法從任務本身推導出來的 context、成功標準與驗證方法。
021. Anthropic 刪掉 80% system prompt｜這不是極簡主義，而是版本適配
影片一開始引用 Boris 的訪談。主持人提到 Claude Code 新版本曾刪掉超過 80% 的 system prompt，Boris 的回應不是「我們討厭 prompt」，而是說 Claude Code 的 prompt、工具與工具描述本來就會隨模型變動。
這句話的關鍵是「每個模型都很不同」。三個月前為了某個模型寫下的限制，到了下一個模型未必還成立。有些提示原本是在修正模型做不到的行為；當新模型已經會做，那些提示就不是保護，而是干擾。
Nate 把這件事接回自己的經驗。他原本也覺得 Opus 5 在某些任務上變差，甚至有時會回到 4.8 拿更好的結果。看完 Boris 的說法後，他開始懷疑：會不會不是模型退步，而是自己的 skills 和 Claude.md 仍然用舊模型的方式綁住新模型？
這裡有一個很好的類比。你教十歲小孩做簡報，可能要把每一頁標題、顏色、格式、順序都講清楚；但如果你把同一份超細指令交給一個做過幾百份簡報的資深工作者，反而會擋住他的判斷。模型升級後也類似：過度指定「先做一、再做二、再做三」可能會讓它無法用自己的能力解題。
所以 80% 這個數字不是重點。重點是：prompt 不是一次寫完就永久有效的配置檔，它更像產品介面，需要隨模型版本重新修剪。
032. 刪掉測試｜沒有 context 的輸出比較醜，但內容可能更活
Nate 後來做了一個測試。他複製自己的 repo，拿掉 Claude.md 和 skills，再請 Claude 根據同一支訪談影片做 YouTube resource guide。
結果有點矛盾。帶著原本 context 的版本，看起來更像他的品牌：有固定 header、顏色、YouTube 頻道連結，也會連回他的 AI 系統。換句話說，外觀與品牌一致性比較好。
但沒有 skills、沒有 Claude.md 的 fresh session，產出的內容反而讓他更喜歡。雖然版面比較粗糙、沒有品牌 header，也不像他的標準 resource guide，可是它自己把影片拆成幾個主題，每個主題附上 timestamp，例如 prompts are disposable、rebuild from observation 這類概念。Nate 覺得那份內容的想法更有趣。
這個結果很重要，因為它說明「context」和「創造性」之間不是單向關係。context 可以讓模型穩定地符合品牌與格式，但過度具體的 context 也可能把模型導向舊模板，讓它少做一些本來會做的分析。
Nate 最後沒有得出「刪光」的結論。他比較像是在說：把品牌必需品留下來，把任務方法交還給模型。像 resource guide 這種工作，也許 skill 不該規定每一段怎麼拆，而是只說：請使用這張 header 圖、放上 YouTube 連結、頁尾連到 AI 系統；至於內容怎麼組織，讓模型依來源自行判斷。
這個分界很實用。模型不知道你的品牌素材在哪裡，不知道你的頻道連結，不知道團隊約定的輸出位置，這些需要 context。但模型可能知道如何閱讀一支訪談、如何抽取主題、如何組織一份導讀，這些不一定需要被舊 skill 逐步指定。
043. 不要盲目套用建議｜Boris 的處境，不一定是你的處境
影片中段 Nate 補了一個重要提醒：不要看到 Boris Cherny、Andrej Karpathy、YouTuber 或社群高手的建議，就原封不動套到自己的工作流。
Boris 的建議來自他的位置。他在設計 harness、處理大型 codebase、觀察模型能力邊界，也在思考產品層級的 agent experience。這種經驗很珍貴，但它不等於所有人的日常。
Nate 說自己的日常比較偏研究、knowledge work、文件與 deliverable，而不是每天在大型軟體系統裡建產品。對他來說，品牌規範、圖像位置、固定連結、輸出風格仍然很有價值。直接把所有 skills 刪掉，未必比重新設計 skills 更好。
這也是魚塘讀者最該保留的一層判斷：你要先看自己怎麼用 AI。若你主要在寫程式，很多過去為弱模型設計的 orchestration skill 可能真的該砍。若你主要在做內容、簡報、研究報告，完全砍掉品牌與格式 context，可能只會讓結果變得不穩。
更好的做法，是把 skills 拆成兩類。
第一類是「不可推導的 context」：品牌語氣、素材位置、檔案結構、客戶偏好、一定要附上的連結。這些資訊模型不會憑空知道，應該保留。
第二類是「過時的方法指定」：要求模型照某個固定步驟寫、限制它只能用某種拆解方式、把舊模型的缺陷當永久規則。這類最該定期重看，因為模型能力一變，它們就可能變成負擔。
054. Skill 不是鐵軌，是欄杆｜讓模型 cook，但先說清楚邊界
影片裡最核心的一段，是 Boris 談「hobbling」與「product overhang」。
hobbling 指的是模型本來做得到，但產品或 prompt 設計反而擋住它。product overhang 則是在說：今天的模型其實已經有很多能力，只是產品還沒把那些能力釋放出來，使用者也還不知道它能做到。
Boris 的建議是，給模型一個比你以為它能做的稍微更難的任務。不要一開始就把方法拆成十幾個步驟，規定它必須先做什麼、再做什麼、用哪個路徑到結果。對現代模型，比較好的方式是描述任務、guardrails、exit criteria，然後讓模型自己做一段，再回來檢查。
這裡的重點不是放任。guardrails 仍然存在。你要說清楚不能做什麼、成功條件是什麼、哪些品質標準不能破。但你不一定要替模型規定每個中間步驟。
用工作流語言說，舊式 skill 像鐵軌：模型只能照固定路線走。新式 skill 更像欄杆：它知道邊界在哪裡，但中間路徑可以自己找。當模型變強時，欄杆通常比鐵軌更能讓它發揮。
對 Claude Code 使用者來說，這可以變成一個很具體的檢查問題：你的 skill 裡哪些句子是在定義「結果要長什麼樣」？哪些句子只是在 micromanage「它應該怎麼想」？前者通常值得留下，後者值得刪或縮短。
065. Goal 與 Verification｜少寫步驟，多寫如何證明完成
影片後半把焦點轉到 goal 和 verification。Nate 說，如果輸出很普通，也許不是模型不行，而是你沒有告訴它「好」長什麼樣。
這句話聽起來像 prompt engineering 老生常談，但 Boris 的版本更精準。他說，現在的 skill 比較不是傳統 prompt engineering，而是兩件事：怎麼給 Claude 一個看起來稍微太難的任務，以及怎麼讓 Claude 在過程中驗證自己的工作。Boris 特別強調，verification 可能是大多數人最常沒做好的地方。
這可以改寫成一個很簡單的 skill 骨架：
先定義目標：你要的不是 prototype，不是 demo，而是能交付、能被使用、符合標準的結果。
再定義邊界：哪些資料不能外流、哪些檔案不能碰、哪些風格不能偏、哪些需求必須保留。
最後定義驗證：跑哪些測試、檢查哪些輸出、如何證明不是只做了一半、如何讓模型自己迭代到通過。
Nate 舉的 prompt 例子比較情緒化。他會在 slash goal 後面加上類似「我不是要 prototype 或 proof-of-concept，我要的是已經測試、迭代十次、QA 完成、明天可以上市的東西」。這種語氣未必適合所有場景，但它反映的是同一件事：標準要清楚，而且要要求模型自己驗證。
這也是「少寫提示」不等於「少給標準」。真正該減少的是冗長角色扮演、重複格式規定、過時流程；真正該增加的是成功條件、品質門檻、檢查方法。
076. 編輯觀點｜不要外包理解，只外包思考
影片最後 Nate 把 agent management 類比成管理人。他說，好的 manager 不會只會 micromanage；他們會給方向、檢查、保有 judgment 和 taste，同時也讓團隊成員使用自己的腦袋。
這個類比很適合用在 AI agent。你開一個 session、派一個 agent、讓它做研究或寫 code，是因為你想借用它的思考能力。若你把所有步驟都綁死，只讓它照單執行，就等於把一個能思考的系統用成模板引擎。
但 Nate 也補了一句更重要的話：outsourcing the thinking, but never outsource the understanding。思考可以分出去，理解不能分出去。最後的方向、品質、取捨、產品感，仍然要由使用者掌握。
所以這支影片對魚塘讀者的 takeaway 不是「今天把所有 Claude Skills 刪光」。比較好的練習是：
每隔一段時間，把 Claude.md、skills、hooks 拿出來做一次清理。先問：這條規則是在補模型真的不會的東西，還是在補舊模型曾經不會的東西？這條規則是必要 context，還是過度干涉？這個 skill 是讓輸出更可驗證，還是只是讓模型更像過去那個模板？
如果答案偏後者，就刪掉、縮短，或改寫成 goal + guardrails + verification。
AI 工作流的下一階段，可能不是累積更多 prompt，而是更懂得何時把提示拿掉。真正成熟的 skill，不是把模型綁到最緊，而是用最少的文字把結果、邊界與驗證說清楚，然後讓模型把能力拿出來。
給讀者的 Takeaway
- Claude Code 團隊會隨模型版本刪改 system prompt，代表 prompt/skill 不是永久資產，而是需要維護的產品介面。
- 「刪掉 skills」不是放棄 context，而是清掉過度具體、過時、會 hobble 模型的方法指定。
- 品牌素材、檔案位置、輸出連結、團隊偏好這類模型無法推導的 context，仍然值得保留。
- 對更強的模型，skill 應該更像欄杆：定義目標、邊界與成功條件，而不是規定每一步怎麼走。
- Verification 是核心能力。好的 goal 不只描述結果，也要說明模型如何證明自己已經做到。