Those who take context budget seriously will have a better AI-assisted experience than those who mindlessly stack Skill.

文章作者、來源：0x9999in1，ME News

簡而言之

• 當前主流AI程式設計助手的技能/外掛生態，正經歷「野蠻生長後的消化不良」——重複、冗餘、僵尸技能堆積，嚴重侵蝕寶貴的上下文視窗資源。
• Lobster Dad 開源了一個專為 Skill 設計的元技能（Meta-Skill），涵蓋五大核心功能：預算審計、重複檢測、閒置篩查、根目錄審計、描述精簡。
• 上下文窗口是AI大模型最稀缺的資源之一，每一個冗餘Skill的存在，都在用無意義的token搶佔你真正需要的推理空間。
• 這個工具的核心價值不是「又多了一個 Skill」，而是用一個 Skill 去治理所有 Skill——它是基礎設施級別的。
• Skill 生態的混亂不是個別現象，而是結構性問題。沒有審計機制的插件系統，終將走向熵增。
• 開源意味著社區可以在此基礎上進行迭代，這可能是 Skill 治理標準化的起點。

先說現狀：你的 Skill 倉庫，可能已經是個垃圾場

這話難聽。但你打開自己的AI助手配置，數一數裝了多少Skill，再想想上一次用到的是哪幾個。

答案大概率讓人沉默。

從2025年下半年開始，Cursor、Windsurf、Codex、Claude Code 等 AI 編程工具集體進入 "Skill 軍備競賽"。社區貢獻者瘋狂輸出，官方內置庫不斷膨脹，個人配置層層疊加。

結果呢？

一個典型的重度用戶，Skill 數量輕鬆突破 50 個。其中能被日常觸發的，可能不到 10 個。剩下的 40 個，安靜地躺在那裡，每次對話啟動時被加載進上下文，默默吃掉 token 預算，然後——什麼都不做。

這不是浪費。這是犯罪。

為什麼這麼說？因為上下文窗口並非無限。即便到了2026年，主流模型的有效上下文長度在128K到200K token之間，聽起來很多對不對？但你算算：系統提示詞、對話歷史、代碼片段、文件內容、工具定義、Skill描述……真正留給「思考」的空間，遠沒有你想象的寬裕。

每多一個無用 Skill 的描述文本佔據 200 個 token，50 個就是 10000 token。一萬個 token，夠模型多讀 400 行代碼了。

這不是理論推演。這是每天都在發生的事。

為什麼沒人管？因為「加」比「減」容易一萬倍

人類有一個根深蒂固的心理偏誤：添加偏好（Addition Bias）。

面對問題，我們本能地想「加點什麼」來解決，而不是「減掉什麼」。2021 年發表在《Nature》上的研究明確指出，人類在改進事物時系統性地忽略「減法方案」，即便減法更有效。

Skill 生態完美複現了這個偏差。

社區貢獻者撰寫了新的 Skill 並發布。用戶覺得「说不定有用」，安裝。官方認為「功能覆蓋面廣」，內置。

誰來刪除？誰來審計？誰來說「這個 Skill 跟那個重複了，幹掉一個」？

沒有人。

因為刪除沒有激勵。寫一個新 Skill，能獲得 star、能被社區認可、能寫進簡歷。清理一個舊 Skill？什麼都得不到。

這就是結構性困境。不是技術問題，是激勵機制問題。

直到有人決定：我不管激勵，這事我來幹。

龍蝦之父出手：用一個 Skill，治理所有 Skill

誰是龍蝦之父？如果你混跡於 AI 編程工具社區，這個 ID 你不會陌生。長期活躍於 Codex 和 Claude 生態的深度玩家，以系統性思考和工程化潔癖著稱。「龍蝦之父」這個稱呼本身就帶有社區的認可——能被冠以「之父」，說明在某個垂直領域，他就是那個繞不過去的人。

這次他開源的東西，本質上是一個元技能（Meta-Skill）。

什麼是元技能？就是「管理技能的技能」。它不會幫你寫代碼，不會幫你調用 API，也不會幫你生成文檔。它只做一件事：為你現有的所有 Skill 進行一次徹底的、量化的、可執行的體檢。

五大功能，逐個拆解。

這是最硬核的一個。

它所做的事很直接：計算每個 Skill 占用的上下文 token 空間，算出各自佔總預算的百分比，然後給出優化建議。

為什麼這很重要？因為絕大多數用戶對「Skill 到底吃了多少資源」這件事，完全沒有感知。

你以為安裝了一個 Skill 只是多了一個功能。實際上，每個 Skill 的描述文字、參數定義、範例代碼、觸發規則，全部都要寫進系統提示詞。模型每次推理，都要先「讀」一遍這些內容，才能決定是否調用。

這就像你背著一個登山包，裡面裝了 50 件工具。你以為「帶著不虧」，但每多一公斤，你的體能消耗就多一分。等你真正需要衝刺的時候，你已經沒力氣了。

預算審計所做的，就是打開你的背包，告訴你：「這把瑞士軍刀重3公斤，但你從未使用過，扔掉吧。」

這個功能解決的問題，可能比你想像的嚴重。

它的掃描範圍覆蓋四個等級：

• Codex 內置庫
• 插件緩存
• 代碼庫
• 個人技能根目錄

Scan across tiers for skills with the same name, similar descriptions, or overlapping functions, and flag redundant items.

為什麼會有重複？原因很多。

官方內置了一個「代碼格式化」Skill，你不知道，又從社區安裝了一個功能幾乎一樣的。兩個 Skill，做同一件事，佔兩份預算。

或者更隱蔽的是：你半年前寫了一個自定義 Skill 處理 JSON 解析，後來官方更新，在內置庫中新增了更好的版本。你的舊版本仍在，卻沒有人告訴你該刪除它。

重複檢測不只看名字。名字不同但描述高度相似的，一樣會被標出來。這才是真正有技術含量的部分——它要做語義層面的相似度比對，不是簡單的字串匹配。

Based on historical logs, identify long-inactive "zombie skills".

這個邏輯很清晰：如果一個 Skill 在過去 30 天、60 天、90 天裡從未被觸發過，大概率說明兩種情況——要麼你的工作流不需要它，要麼它的觸發條件設計有問題，導致模型從不選擇它。

無論哪種情況，結論都一樣：它在白白消耗預算。

此功能輸出的是一份「清理候選清單」。請注意，這是「候選」，而非直接刪除。最終決策權在用戶手中。此設計非常克制且聰明——它清楚自己的界限所在。

有些技能確實是低頻但關鍵的。例如 "資料庫遷移輔助"，你可能三個月才用一次，但用的時候救命。所以篩查結果是參考，不是判決。

這個功能偏「運維」屬性，但極其實用。

它會統計所有 Skill 的來源目錄，標註啟用／禁用狀態，並梳理載入鏈路。

為什麼需要這個？因為 Skill 的來源是多元的。有的來自全局配置，有的來自項目級配置，有的來自插件自動注入，有的來自用戶手動創建。

當 Skill 數量少的時候，你心裡有數。當數量膨脹到幾十個，你已經搞不清「這個 Skill 是從哪來的」「我能不能安全地刪掉它」「刪了會不會影響其他東西」。

根目錄審計就是給你畫一張地圖，告訴你每個 Skill 住在哪裡、誰加載了它、它現在是活的還是死的。

With this map, you can perform the surgery safely.

最後一個功能，看起來最「小」，實際上槓桿極大。

它會找出描述過於冗長的 Skill，並推薦簡化方案。

為何描述長度如此重要？回到前面所說：Skill 的描述需要寫入系統提示詞中。每個字都是 token。如果一個 Skill 的描述能從 200 token 壓縮到 80 token，節省的空間乘以 Skill 數量，總量非常可觀。

許多社區貢獻的 Skill，描述寫得像論文摘要——背景、動機、適用場景、注意事項、示例輸入輸出，洋洋灑灑。寫的人用心良苦，但從工程角度看，這是過度設計。

模型所需的描述需精準、唯一、可區分。用最少的詞讓模型明白「這個 Skill 做什麼、何時調用它」即可。多餘的每一個字，都是對上下文預算的浪費。

簡化此功能，本質上是進行「提示詞工程的逆向優化」—— 不是撰寫更佳的提示詞，而是將現有提示詞壓縮得更短，同時不損失資訊量。

價值在哪？不是功能，是思維方式

五個功能已拆解完畢。單看每一個，似乎都算不上「驚天動地」。但當它們結合在一起時，代表的是一種思維範式的轉變：

從「創造更多 Skill」到「治理現有 Skill」。

這件事的價值，不在程式碼量，不在演算法複雜度，而在——終於有人把這個問題當成「一等公民」來對待了。

過去兩年，AI 工具生態的注意力全在「做加法」。更多模型、更多功能、更多插件、更多 Skill。跑得快，跑得猛，沒人回頭看。

但任何有工程經驗的人都知道：系統的複雜度增長到一定程度，如果沒有對應的治理機制，它會坍塌。

不是可能。是一定。

在軟體工程中，有一個概念稱為「技術債」。每一個臨時方案、每一次「先這樣吧」、每一個未清理的冗餘，都是在借債。借得越多，利息越高，直到某一天你發現所有精力都在還債，沒有餘力做新事情。

Skill 生態的技術債，已經到了必須正視的時刻。

龍蝦之父這個工具，本質上是一個債務審計器。它不幫你還債，但它告訴你：你欠了多少、欠在哪裡、哪些該優先還。

這比「又寫了一個好用的 Skill」有價值得多。

開源的意義：從個人工具到社區標準

龍蝦之父選擇開源，這個決策本身值得說道。

他完全可以將這個工具做成付費插件。市場需求明確，痛點真實存在，付費用戶不會少。但他選擇了開源。

為什麼？

我猜有兩層考量。

第一層：這個工具要真正發揮價值，需要社區共建。不同AI平台的Skill加載機制不同、日誌格式不同、目錄結構不同。一個人適配不過來，但一百個貢獻者可以。

第二層：他可能想推動的不只是一個工具，而是一個標準。Skill 治理應該怎麼做？審計的維度有哪些？預算分配的最佳實踐是什麼？這些問題，需要社區共識才能形成答案。

開源是達成共識的最佳方式。

回顧軟體工程歷史，ESLint 之於 JavaScript 代碼規範、Black 之於 Python 格式化、Prettier 之於前端代碼風格——這些工具之所以成為事實標準，都是因為開源讓社區參與了規則的制定。

龍蝦之父的這個 Meta-Skill，有沒有可能成為 Skill 治理的 ESLint？

現在判斷太早。但方向是對的。

一個更深的問題：Skill 系統本身該不該重新設計？

審計工具解決的是「存量問題」。但如果我們把視角拉高一層，會發現一個更根本的問題：

為什麼 Skill 會失控？

答案是：當前的 Skill 系統缺乏生命週期管理。

一個 Skill 被創建之後，它就永遠存在了。沒有過期機制、沒有版本淘汰、沒有活躍度衰減。它像一個永遠不會死的進程，佔著資源，直到有人手動 kill 它。

對比操作系統的進程管理：有創建、有調度、有休眠、有終止。生命週期完整閉環。

再對比一下包管理器的依賴管理：npm audit檢查安全漏洞、npm outdated檢查過期依賴、npm prune清理無用包。治理工具是生態的一部分。

Skill 系統呢？建立→使用→……就沒了。中間缺失了大量環節。

龍蝦之父的工具，本質上是用外部工具彌補系統設計的缺失。它很有用，但它也暴露了一個事實：AI 工具平台在 Skill 治理方面的基礎設施，還處於原始階段。

這不是批評。這是發展階段的必然。2024到2025年，平台方的首要目標是「讓生態跑起來」，治理可以後面再說。但到了2026年中，生態已經跑起來了。是時候補課了。

最後一提

回到最初的問題：你的 AI 助手中，有多少 Skill 是活的？

如果你答不上來，說明你需要做一次體檢。

龍蝦之父提供了工具。免費的。開源的。五個維度，全面覆蓋。

用不用，是你的事。

但我非常確定：那些認真對待上下文預算的人，會比那些無腦堆疊 Skill 的人，獲得更好的 AI 輔助體驗。

因為 AI 不是萬能的。它的注意力有限、它的記憶有限、它的推理資源有限。你給它的資訊越精準、越乾淨，它回饋你的輸出就越好。

這不是玄學。這是資訊理論。

Shannon早在1948年就告訴我們：信道容量有限，噪聲越多，有效資訊傳輸率越低。

你 Skill 列表裡那些殭屍技能，就是噪聲。

Eliminate them.

參考引用

1. Adams, G. S., Converse, B. A., Hales, A. H., & Klotz, L. E. (2021). People systematically overlook subtractive changes. Nature, 592(7853), 258–261.
2. Shannon, C. E. (1948). A Mathematical Theory of Communication. Bell System Technical Journal, 27(3), 379–423.
3. OpenAI. (2024). GPT-4 Turbo 上下文視窗與標記限制文件。 https://platform.openai.com/docs/models
4. Anthropic. (2025). Claude 模型卡：上下文視窗利用率與系統提示開銷。 https://docs.anthropic.com/en/docs/about-claude/models
5. Cursor Team。 (2025)。規則與技能：自定義指令如何載入至上下文。Cursor 文件。
6. npm 文件說明。 (2025)。 npm-audit、npm-prune：管理套件生命週期。 https://docs.npmjs.com/cli
7. 龍蝦之父。 (2026)。Skill Health Check Meta-Skill [開源項目]。GitHub Repository。
8. Sculley, D., 等人 (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems (NeurIPS), 28.