那些認真對待上下文預算的人，會比那些無腦堆Skill的人，獲得更好的AI輔助體驗。
文章作者、來源：0x9999in1，ME News
TL;DR
- 當前主流AI編程助手的Skill/插件生態，正經歷"野蠻生長後的消化不良"——重複、冗餘、殭屍技能堆積，嚴重侵蝕寶貴的上下文窗口資源。
- 龍蝦之父（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內置庫
- 插件緩存
- 代碼庫
- 個人技能根目錄
跨層級掃描同名、描述相似、功能重疊的技能，標記冗餘項。
為什麼會有重複？原因很多。
官方內置了一個"代碼格式化"Skill，你不知道，又從社區裝了一個功能幾乎一樣的。兩個Skill，做同一件事，佔兩份預算。
或者更隱蔽的：你半年前寫了一個自定義Skill處理JSON解析，後來官方更新，內置庫里加了一個更好的。你的舊版本還在，沒人告訴你該刪了。
重複檢測不只看名字。名字不同但描述高度相似的，一樣會被標出來。這才是真正有技術含量的部分——它要做語義層面的相似度比對，不是簡單的字符串匹配。
功能三：未使用技能篩查
基於歷史日誌，識別長期未被調用的"殭屍技能"。
這個邏輯很清晰：如果一個Skill在過去30天、60天、90天裡從未被觸發過，大概率說明兩種情況——要麼你的工作流不需要它，要麼它的觸發條件設計有問題導致模型從不選擇它。
無論哪種，結論一樣：它在白白消耗預算。
這個功能輸出的是一份"清理候選清單"。注意，是"候選"，不是直接刪除。最終決策權在用戶手裡。這個設計很剋制，也很聰明——它知道自己的邊界在哪裡。
有些Skill確實是低頻但關鍵的。比如"數據庫遷移輔助"，你可能三個月才用一次，但用的時候救命。所以篩查結果是參考，不是判決。
功能四：技能根目錄審計
這個功能偏"運維"屬性，但極其實用。
它做的事：統計所有Skill的來源目錄，標註啟用/禁用狀態，梳理加載鏈路。
為什麼需要這個？因為Skill的來源是多元的。有的來自全局配置，有的來自項目級配置，有的來自插件自動注入，有的來自用戶手動創建。
當Skill數量少的時候，你心裡有數。當數量膨脹到幾十個，你已經搞不清"這個Skill是從哪來的""我能不能安全地刪掉它""刪了會不會影響其他東西"。
根目錄審計就是給你畫一張地圖。告訴你每個Skill住在哪裡、誰加載了它、它現在是活的還是死的。
有了這張地圖，你才能安全地動手術。
功能五：描述精簡優化
最後一個功能，看起來最"小"，實際上槓杆極大。
它做的事：找出那些描述過於冗長的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列表裡那些殭屍技能，就是噪聲。
幹掉它們。
參考引用
- Adams, G. S., Converse, B. A., Hales, A. H., & Klotz, L. E. (2021). People systematically overlook subtractive changes. Nature, 592(7853), 258–261.
- Shannon, C. E. (1948). A Mathematical Theory of Communication. Bell System Technical Journal, 27(3), 379–423.
- OpenAI. (2024). GPT-4 Turbo context window and token limits documentation. https://platform.openai.com/docs/models
- Anthropic. (2025). Claude model card: Context window utilization and system prompt overhead. https://docs.anthropic.com/en/docs/about-claude/models
- Cursor Team. (2025). Rules & Skills: How custom instructions are loaded into context. Cursor Documentation.
- npm Documentation. (2025). npm-audit, npm-prune: Managing package lifecycle. https://docs.npmjs.com/cli
- 龍蝦之父. (2026). Skill Health Check Meta-Skill [開源項目]. GitHub Repository.
- Sculley, D., et al. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems (NeurIPS), 28.
