整個時間線都在叫你裝 skill。只有一個人叫你刪。而且他真的刪了兩個，其中一個只活了三天。
一句話結論：Claude Skills 太多的真正代價不是佔 token，是有些 skill 會偷偷改寫「這件事做完的定義」—— swyx 團隊刪掉的那個 JFDI，就讓 agent 一口氣跑了 7 小時 23 分還不肯收工。
2026 年 8 月 10 日，swyx（Shawn Wang）在 X 上發了一句很不合時宜的話：「定期提醒你一下，去刪掉你的 skill。」他的理由是，當你的時間線每天被「這個 skill 改變了我的人生！！你一定要試！！」轟炸，你會囤積一堆東西：好一點的情況只是吃掉 context，壞一點的情況是它們會用你想不到的方式互相打架，而你不去看 traces 根本不會發現。
這句話不是隨口說的。他附了一篇同團隊的事故報告：〈We Deleted Two Skills That Tried to Help〉（我們刪掉了兩個想幫忙的 skill），2026 年 8 月 8 日發表在 SmolForge Field Notes。這篇文章難得的地方在於，它不是心得文，是一份帶時間戳、帶 commit hash、帶反例的完整 postmortem。
以下內容全部對照官方原文，包含官方自己承認「還沒證明」的部分，這點中文圈的轉述通常會漏掉。
第一個被刪的 skill，到底做錯了什麼？
它叫 JFDI，檔案是 jfdi/SKILL.md。目的聽起來完全正當：執行一個已經批准的任務時，不要每一步都回頭問使用者「可以嗎」。任何用過 AI agent 的人都懂那種每三十秒被問一次的煩躁。
事發當天，團隊正在處理一次難搞的發布。卡了三個小時之後，操作者為了省掉授權往返，直接打了一句大意是「全部批准，直接 ship」的指令。意圖很清楚：別再問了，走最短的安全路徑上線。
skill 把這個批准理解得更寬。它接下來做的事，全部都在它自己的授權範圍內。
那幾行指令，單看每一行都很合理
JFDI 給了十類「常設批准」。原文列出的關鍵幾行是這樣的：
- 持續執行，直到驗收條件達成，或證實有永久性的外部阻塞
- 修好連帶的後端、前端、文件、CLI、遙測、發布合約缺口
- 當請求說「ship」或「全部做完」時，可以推送或合併到正式 main
- 可以做一次小範圍的供應商政策或綁定白名單擴充
- 可以套用已簽入的編號 migration
- 中斷的執行可以做一次指定 SHA 的重試
- Forge 自己發布不了的時候，可以本機建置並上傳 runner／API bootstrap
單獨拿任何一行出來，都說得過去。問題出在它們加起來，把三個本來應該分開的決定壓成了一個：
| 混在一起的決定 | 本來的意思 | 實際變成 |
|---|---|---|
| 權限 | 例行動作不用再問一次 | 把旁邊的變更也當成已預先批准 |
| 範圍 | 把這次要的發布改進做完 | 把連帶的平台缺口一併吸收進來 |
| 持續性 | 保持推進 | 一直做到一個會移動的驗收條件成立為止 |
那個 skill 其實有安全邊界：不准 force push、不准造成不可逆的資料損失、不准無上限花錢、不准替換運行中的部署。這些都是重要的護欄，但它們沒有回答真正致命的那個問題 —— 一次發布嘗試，應該在什麼時候停止接收新的責任？
候選版本 → 平台或供應商出錯 → 修政策、綁定、控制器、元件 → 新的候選版本 → 換一種錯 → 再修一次
報告裡最精準的一句話是：agent 在局部始終是理性的，而整件任務在全局上變得荒謬。每一個新暴露的失敗，都被 skill 的字面契約解釋成「這也算連帶缺口」，於是變成繼續擴張的許可。
7 小時 23 分，是不是因為雲端很慢？
不是。這是整篇報告最有說服力的一段舉證。
包含那句「直接 ship」的那一輪對話，總共持續了 7 小時 23 分。團隊把這輪拆開對照，裡面有 13 次正式的發布控制器嘗試，加起來的機器時間是 3 小時 26 分。另一輪 6 小時 57 分的對話，包含 18 次嘗試、4 小時 25 分機器時間。
然後他們把單次發布的真實耗時貼出來：
| 動作 | 實際耗時 |
|---|---|
| 一次完整 bootstrap | 6 分 3 秒（驗證 1 分 25 秒＋runner 2 分 50 秒＋部署 21 秒＋deploy-control 44 秒） |
| 指定分支 CI | 5 分 15 秒 |
| 重複佇列 CI | 3 分 56 秒 |
| 安全公告閘 | 4 秒 |
| 單輪 agent 對話 | 7 小時 23 分 |
確實有卡住的時候：某次 runner 在已經產出可用建置證據之後，還開著 30 分鐘。但那本來收成一張「終止事故單」就該結束。實際發生的是 agent 繼續盯著、診斷 runner、提出通用化的復原方案，然後回到架構循環。
報告的結論很值得抄下來：昂貴的資源不是算力，是被綁在一個會移動的目標上、沒有上限的 agent 注意力。
最後把它停下來的不是人，是另一個 agent。一條獨立的審查對話讀完發布歷史之後，給了一句很不客氣的診斷：「你在最佳化這套發布系統，而不是在發布。」
而團隊的第一反應，其實犯了跟原本一模一樣的錯：他們開始寫一個新的 release-stop-loss skill，還打算加優先級規則去仲裁幾個 skill 之間的衝突。是操作者把這件事叫停的：「不，我要刪東西，不是加新的 skill。」
最後 JFDI 被整個刪掉，commit 519dff9，總共 90 行（86 行指令檔＋4 行 UI manifest），沒有補上任何替代政策。它從 8 月 5 日活到 8 月 8 日，三天。
第二個 skill 沒有任何危險權限，為什麼也要刪？
因為它改的不是「agent 可以做什麼」，是「agent 認為做完長什麼樣」。這一段才是對一般使用者最有用的部分。
第二個被刪的叫 Codebase Maintainability Guardrails，63 行，commit 243a0c6。它完全沒有部署權限，也沒有「做到成功為止」那種指令。它的殺傷力全部集中在觸發條件那一行：
「用於大部分實質性的編碼工作，特別是前端／全端應用、全新專案、生產環境重構、UI 遷移，以及功能開發。」
看出問題了嗎？「大部分實質性的編碼工作」幾乎已經涵蓋所有你會交給 AI 做的事。於是這個 skill 每次都會載入，而它一載入，一個普通的小修改就自動繼承了一整份清單：檔案大小限制、模組邊界、集中式契約、純邏輯抽離、持久化狀態相容、結構化日誌、錯誤邊界、測試強化、多視窗 UI 檢查。
每一條建議單獨看都是好習慣。壞掉的是組合。它讓一個窄小的修補，在做完之前都顯得「還不完整」。報告記錄的實際後果是：在那條「恢復並簡化發布流程」的對話裡，agent 明確宣告自己正在套用「維護性指引」，然後又多花了一個小時做分析和加固，而原本要恢復的那條發布路徑並沒有被恢復。
兩個 skill，兩種壞法，同一個結果：
| JFDI | Maintainability Guardrails | |
|---|---|---|
| 賣點 | 少問你幾次授權 | 程式碼品質更好 |
| 擴張了什麼 | agent 可以做的範圍 | agent 認為應該做的範圍 |
| 危險權限 | 有（推 main、改政策、跑 migration） | 完全沒有 |
| 結局 | 整個刪除，90 行 | 整個刪除，63 行 |
報告從這裡推出第二條審查標準，我認為是全文最值得記住的一句：觸發範圍本身就是一種對範圍的權力。一個到處都會載入的 skill，不需要執行任何危險指令，就能把你每一個任務都撐大。
同一次整理裡，另外兩個 skill 被收窄而不是刪除：Test Strategy Hardening 改成「使用者明確要求把測試當成一套系統來處理」時才觸發，不再是「任何實作需要一個回歸測試」就啟動；Autoreview 改成只在被要求或儲存庫政策要求時才跑。
為什麼 skill 裝多了會互相打架？
因為決定「什麼時候載入」的，是你寫在 description 那一欄的文字，而不是你的意圖。
Agent Skills 的載入機制叫漸進式揭露（progressive disclosure），分三層：開機時 agent 只讀每個 skill 的名稱和描述（每個大約一百個 token 的量級）；當你的請求配得上某個描述，它才把完整的 SKILL.md 讀進 context；再深的檔案要用到才讀。
這個設計本身很好，也解釋了兩件事：
- 裝很多 skill 的開機成本，其實沒有大家想的那麼可怕。沒被觸發的 skill 只有名稱和描述在 context 裡。單純用「省 token」當理由去刪，力道其實不強。
- 真正的成本發生在觸發那一刻。描述寫得越寬，越常在不該載入的時候載入；一旦載入，它的全部內容就變成這次任務的隱形需求。兩個描述都寫得很寬的 skill 同時載入，你就會拿到一份誰也沒單獨要求過的合併指令。
swyx 說的「它們會用你想不到的方式互相打架」，機制就在這裡。這也是為什麼他強調要看 traces。因為在最終輸出上，你只會看到 AI「做了很多額外的事」，看不到是哪一份 SKILL.md 在旁邊加碼。
順帶一提，這跟我們之前寫過的讓 agent 跑 200 小時不忘記目標的 LoopX 剛好是同一枚硬幣的兩面：一邊在解決「agent 忘記目標」，一邊在處理「agent 太記得一堆不相干的目標」。YC QM 那套把 50 個 AI 助理管到爆炸之後重寫的共用框架，處理的也是同一類問題。
你的 skill 該刪哪些？6 題自檢
官方 postmortem 給了六個審查問題，核心是：能授權生產環境動作的 skill，要用審查程式碼的標準來審。我把它改寫成一般人也答得出來的版本，做成下面這個小工具。挑一個你最近裝的 skill，照著答。
第 3 題是最多人漏掉的一題。「做到成功為止」聽起來很勵志，但它不是一個有邊界的重試策略，這正是 JFDI 那 7 小時的來源。
我們去 repo 對了一次，發現什麼？
兩個被刪的 skill，官方都給了 commit hash，所以這件事是可以驗的。我們在 2026 年 8 月 12 日打開 github.com/swyxio/skills 對了一次：
- 整個 repo 目前有 23 個 skill 資料夾、55 次 commit、38 顆星。
jfdi資料夾確實不在了。刪除屬實。- 被收窄而不是刪除的
test-strategy-hardening和release-readiness-hardening，都還在。跟報告說法一致。 - 但是
codebase-maintainability-guardrails還在 repo 裡，而且 README 到今天仍然把它描述成「預設工程標準、always-on 規則」，也就是那份 postmortem 認定為問題根源的「到處都會載入」定位。
需要說清楚的是：GitHub 的 commit 歷史頁面是前端渲染的，我們沒有辦法從外部確認它是被還原、被重寫後重新加入，還是 README 單純沒更新。所以這裡不下結論，只講可觀察到的事實 —— 「刪掉」在實務上比一篇 postmortem 說得複雜。順帶一提，報告裡提到被收窄的 Autoreview，並不在這個公開 repo 的清單中。
另一件中文轉述常常會走樣的事，是官方自己的保留。報告白紙黑字寫著：他們沒有做過「有 skill 對無 skill」的對照實驗，所以不能宣稱刪掉之後部署時間中位數下降了多少；那個 7 小時 23 分的數字裡也混了帳號復原、任務交接和多次人為介入，不是乾淨的前後對照。如果你在別的地方看到「刪 skill 之後快了幾成」這種說法，那是轉述時加上去的。
這種對照原文的落差，跟我們拆OpenAI Astra 踩到 Critical 紅線那次的四個誤讀是同一類問題：報告本身很克制，轉述一層就變成斷言。
只是用 Claude 桌面版的人，需要在意這件事嗎？
需要，而且比工程師更需要 —— 因為你更看不到 traces。
工程師至少會發現「怎麼多改了 12 個檔案」。一般使用者叫 AI 整理一份報表，它多做了三件沒要求的事，多數人只會覺得「它今天比較認真」。我自己裝 skill 的節奏也偏激進，從那份收錄一千多個現成技能包的清單到把一本技術書變成 skill 的 book-to-skill，看到好用的就先裝再說。這篇報告讓我改了三件事：
- 描述比內容更需要審。裝一個 skill 的時候，先讀它的 description 那一行，而不是先讀它的功能說明。那行決定它多常出現在你不需要它的場合。看到「大部分」「任何情況」就自己改窄。
- 刪掉的東西不要用新的 skill 補。團隊差點寫一個
release-stop-loss去管其他 skill，被叫停了。多一層政策，就是多一組要仲裁的衝突。 - 用一個月為單位盤點。你每個月裝的 skill 幾乎一定多過刪的。答不出「上個月它幫了什麼」的，就是候選。
順序上，我會建議先做減法再做加法。真的要加的時候，Skill Recorder 這種錄一次工作自動寫成技能、或是用訓練方式打磨一份 skill.md 的 SkillOpt，都比在時間線上看到什麼就裝什麼可靠，至少它們的觸發範圍是從你的實際工作長出來的。Karpathy 那四條 AI 編程鐵律其實早就講過同一件事：給 AI 的指令，少而準勝過多而全。
如果你的痛點真的是 context 被吃掉，那是另一個問題，該用砍 token 帳單的工具或讓 agent 只讀該讀的檔去解，不必拿刪 skill 當藥方。這篇報告真正在講的，從頭到尾都不是 token。
報告最後那句話值得放進任何人的 AI 使用守則：當自然語言寫成的政策開始授予生產環境權限時，它就是生產環境的程式碼。用審程式碼的標準去審它的範圍、重試次數和終止狀態。有時候最安全的修補，不是寫一份更詳細的指令，而是刪掉那份教 AI 永遠不要停下來的指令。
常見問題
裝很多 Claude Skills 會不會拖慢 AI？
沒被觸發的 skill 只有名稱和描述留在 context，開機成本不高。真正的代價發生在觸發之後：描述寫得寬的 skill 會在不該載入時載入，然後把它的整份清單變成這次任務的隱形要求。
怎麼知道兩個 skill 有沒有在打架？
看 traces 或執行紀錄，確認 AI 這次載入了哪些 skill。徵兆是：它做了你沒要求的事，而且會主動說明「依據某某指引」。SmolForge 報告裡的 agent 就明確宣告自己在套用維護性指引。
swyx 刪掉的兩個 skill 分別是什麼？
一個是 JFDI，90 行，給了十類常設批准又沒有停止條件；一個是 Codebase Maintainability Guardrails，63 行，沒有任何危險權限，但觸發條件寫成「大部分實質性的編碼工作」，等於每次都載入。
刪掉 skill 之後要不要寫一個新的來取代？
官方的做法是不補。他們刪掉 JFDI 時沒有加任何替代政策，也中止了原本要寫的 stop-loss skill，理由是多一層政策就多一組要仲裁的衝突。
刪 skill 真的能讓 AI 做事變快嗎？
官方明確表示還沒證明。他們沒做過對照實驗，所以不宣稱部署時間下降了多少。已經確定的只有一件事：那個 skill 的指令直接對應到觀察到的失控行為，所以它被刪了。
資料來源：SmolForge Field Notes〈We Deleted Two Skills That Tried to Help〉（2026 年 8 月 8 日）、swyx 於 X 的貼文（2026 年 8 月 10 日）、github.com/swyxio/skills（2026 年 8 月 12 日查閱）、Anthropic Agent Skills 文件。本文為工具與工作流程分析，不構成任何投資建議；文中提及的 skill 行為會隨版本更新而改變，實際使用前請自行確認最新版本。
發佈留言