要論寫代碼最能打的模型，非claude家的莫屬。但論其他的，可能就一般了。

10月16日，Anthropic 又開始講故事了。這次的名字叫 Claude Skills，宣傳語是"可定制的專業(yè)能力"，聽起來挺唬人。發(fā)布會搞得很隆重，PPT 做得精美，演示流暢，案例動人，仿佛 AI 要上天了。這明顯是嘗到了MCP當年推出的甜頭，想要再復制一波流量。

結果呢？

作為一個寫了十幾年代碼的老油條，我看完之后笑了：Cursor 的 cursorrules 早在一年前就這么玩了，RAG的 Retrieval 早就做了無數實踐，你現在告訴我這是創(chuàng)新和顛覆？

說穿了，這就是 RAG（檢索增強生成）的一種增強版本。Anthropic 給它包裝了個"漸進式披露"的名字，聽起來很高級，實際上還是在做檢索、匹配、加載這套流程。

本質上，不管是 Tools、MCP、cursorrules 還是 Skills，干的都是同一件事：給模型補充必要的上下文信息。只不過形式不同、名字不同罷了。

大模型優(yōu)化的三板斧

在揭穿 Claude Skills 之前，咱們先聊聊大模型優(yōu)化這件事。現在市面上，無非就三招。

第一招是砸錢練模型。說人話就是：燒錢、燒數據、燒算力，讓模型天生聰明。好處是一次訓練到處能用，推理快。但問題是貴到離譜啊，GPT-4 訓練成本超過 1 億美元，你以為在開玩笑？而且迭代慢，3-6 個月才能更新一次，等得花兒都謝了。知識烙進模型里了，想更新？重新訓練吧。這是 GPT-4、Claude 3.5 這些家里有礦的主兒才玩得起的。

第二招是硬塞長上下文。管它三七二十一，把所有信息都塞進去，讓模型自己找。這招簡單粗暴，工程師喜歡，信息也不會漏掉。這次還是燒錢，不過這次是燒客戶的錢了。

第三招是管理上下文。說白了，就是給模型補充必要的上下文信息。不管你叫它 RAG、Tools、MCP、cursorrules 還是 Skills，本質都一樣。區(qū)別只是管理方式：是全量加載？還是檢索匹配？還是智能篩選？

處理這些額外規(guī)則和上下文的方式，無外乎兩種：元數據管理（打標簽、分類，然后匹配）和檢索（語義搜索或數據庫查詢）。你把 Skills 存在 Markdown 文件里，還是存在數據庫里，還是存在向量庫里，只不過是換了個形式而已。

說到這你就明白了，第三招的各種變體（RAG、Skills 等），本質上都在做同一件事，只是包裝不同。每種方案都有坑，都有問題。

本質上都是在管理上下文

好，現在我們來扒一扒 Claude Skills 到底干了什么，以及它和其他方案的區(qū)別在哪。

先說結論：不管是 Tools、MCP、cursorrules 還是 Skills，本質上都是在給模型補充上下文信息。區(qū)別只是形式和管理方式不同。

當這些額外的規(guī)則和上下文信息太多時，能夠處理它的技術其實只有一種：先語義化處理前置信息，然后有選擇地使用。

具體怎么做？處理方式無外乎兩種：

第一種：元數據管理。給每個 Skill、Rule、Tool 打上標簽、分類、描述，然后根據任務特征去匹配。這就是 Claude Skills 宣稱的"漸進式披露"——掃描技能庫、自動匹配相關技能、按需加載。聽起來高級，但本質就是元數據匹配。當然你也可以分層，把描述越來越細（注意，你的工作量也會越來越多）。

第二種：檢索。可以是語義搜索（向量相似度匹配），也可以是精確的數據庫搜索（關鍵詞、標簽查詢）。不管你的 Skills 是存在 Markdown 文件里，還是存在數據庫里，還是存在向量庫里，只不過是換了個形式而已。底層邏輯都是檢索。

所以你看：

• 傳統 RAG：檢索（語義搜索或關鍵詞匹配）→ 注入 Context → 調用模型
• Cursor Rules：元數據管理（全量加載所有規(guī)則）→ 塞進 System Prompt → 調用模型
• Claude Skills：元數據管理（智能匹配）+ 檢索（按需加載）→ 注入 Context → 調用模型

看出來了嗎？Claude Skills 只是把元數據管理和檢索結合了一下，給它起了個新名字叫"漸進式披露"。技術上有優(yōu)化嗎？有一點，比如可以包含可執(zhí)行代碼，減少了一些 token 浪費。算顛覆性創(chuàng)新嗎？對不起，談不上。

那問題來了：既然只是把現有技術組合了一下，為啥要包裝成 "Skills"？

答案很簡單：為了好賣！

"Custom Instructions" 聽起來就是個配置項，沒意思。"Rules" 聽起來像是在約束我，不爽。但 "Skills"？哇，聽起來像我變強了！

你看，技術組合包裝成革命性功能，換個名字感覺立馬不一樣。這是產品經理的勝利，是營銷的勝利。

換湯不換藥，該踩的坑一個都沒少

別以為換了個管理方式就能逃脫，不管你用元數據管理還是檢索，核心問題一個都沒解決。

先說召回率和精準度的問題。這是所有上下文管理方案的死穴：

• 全量加載（Cursor Rules）：信息完整，但稀釋效應嚴重，模型容易懵
• 檢索匹配（傳統 RAG）：檢索太少漏關鍵信息，檢索太多噪音一堆
• 智能匹配（Claude Skills）：聽起來美好，但匹配不準怎么辦？該匹配的沒匹配上，不該匹配的塞進來了

而且"稀釋效應"無論如何都存在。不管你是全量加載，還是智能篩選，只要上下文信息多了，模型表現就會下降。多個 Skills 互相沖突？模型就像精神分裂一樣，行為不一致。

這不叫"解決問題"，這叫"換個方式踩坑"。

Claude Skills 的按需加載不算創(chuàng)新。而且，這個"按需"到底有多準？如果匹配算法不夠聰明，該加載的沒加載，不該加載的加載了一堆，那成本優(yōu)勢就沒了。而且"掃描技能庫 + 自動匹配"本身也要消耗計算資源。

你說 Anthropic 不是有 Prompt Caching 嗎，緩存命中便宜 10 倍？首先，其他模型也有。其次，本質上是把 Token 成本轉嫁給了計算成本（緩存要錢的，只是你看不見），把成本轉嫁給了用戶（訂閱制你看不到單次賬單，但 Anthropic 心里門兒清）。而且緩存策略還得精心設計，不然命中率上不去，錢照樣燒。

天下沒有免費的午餐，該付的錢一分都少不了。

人家要賺錢，你別當傻子

說實話，從商業(yè)角度看，Anthropic 這波操作沒毛病。競爭這么激烈，不搞點新名詞怎么活？"Skills" 聽著就比 "Custom Instructions" 好懂，讓用戶覺得"只有 Claude 有 Skills"，這就成了。"Skills 功能僅限 Pro 用戶"——要用？掏錢！OpenAI 也這么干（GPTs）、Google 也這么干（Gems）、微軟也這么干（Copilot GPT）。這是行業(yè)常規(guī)操作，不寒磣。

但作為技術人，咱得保持清醒。

Low 的表現是什么？"臥槽，Claude Skills 太牛了！這是顛覆性的創(chuàng)新啊！我要趕緊把所有項目遷移到 Claude！"看到這種發(fā)言，我只能說：兄弟，你該醒醒了。

專業(yè)的態(tài)度應該是："哦，又是一個上下文管理的變體。把元數據管理和檢索結合了一下，加了智能匹配和漸進式披露。本質上還是在做 RAG 那一套，只是工程上優(yōu)化了一點。先看看實際效果和成本，測測匹配準確率，再決定用不用。

技術圈最怕什么？概念通貨膨脹。明明都是在做上下文管理，非要起一堆新名字；明明是工程優(yōu)化，包裝成"架構革新"；明明是參數調整，包裝成"算法突破"。

保持獨立思考，是技術人的底線。看穿本質，別被營銷牽著鼻子走。

曾經的MCP，想綁你上賊船

Anthropic 曾經出了個玩意兒——MCP（Model Context Protocol），配合 Skills 和 Tools，說是要構建"完整的生態(tài)"。聽起來很美好？咱們看看本質是什么。

MCP 干的事兒就是提供標準化接口，讓 Claude 能訪問外部資源：數據庫、API、文件系統、其他服務。等等，這不就是任何一個 REST API 服務器干的事兒嗎？不就是 OpenAI Function Calling 嗎？換湯不換藥，又是舊酒裝新瓶。

Cursor 告訴我們，事情本可以不用這么復雜。Cursor 也能讀寫文件系統、執(zhí)行終端命令、調用 LSP、集成 Git、支持多種模型（Claude、GPT-4、Gemini）。重點來了：Cursor 不綁定任何一個模型。它提供了一個完整的 IDE 環(huán)境，模型只是其中一個可替換的組件。今天用 Claude，明天換 GPT-4，后天上 Gemini，隨便換。這才是健康的架構。

很多公司看到 MCP 后，眼睛都亮了，趕緊開發(fā) MCP Gateway（把其他協議轉成 MCP）、MCP Proxy（統一管理 MCP 連接）、MCP Hub（MCP 服務市場）。

6 個月后的真實情況：使用量遠低于預期，甚至有點慘淡；Claude 新版本一出，協議又改了，你的代碼白寫了；OpenAI 的 Function Calling 生態(tài)已經很成熟了，用戶不愿意換；應用場景有限，看起來像個大型玩具，生產上不可控；公司悄悄把 MCP 相關項目標記為"維護模式"（其實就是放棄了）。

歷史總是驚人的相似。還記得 Google Wave 嗎？協議設計得多好啊，結果沒人用。還記得 SOAP vs REST 嗎？復雜的最終輸給了簡單的。還記得各種區(qū)塊鏈聯盟鏈嗎？熱度過后一地雞毛，現在連提都不提了。

技術圈最不缺的就是"下一個大事件"，但大部分都是曇花一現。工程師的時間很寶貴，別浪費在追風口上。

xjjdog的思考：大模型的未來：別再把它當工具了

現在所有人都在搞 RAG、Skills、MCP，但說白了，都是把大模型當成工具：我有數據 → 喂給模型 → 模型吐結果。工具歸工具，數據歸數據，兩回事。

問題在哪？LLM 對你的數據沒有記憶，每次對話都像第一次見面。每次都在"重新認識你"，上次說過的事，這次還要再說一遍。知識永遠是"外掛"的，不是模型的一部分，只是臨時喂進去的。無法真正個性化，你用的和別人用的本質上是同一個模型。

我有個想法，估計廠商們都沒想過，或者想過但很難做：大模型應該能實時訓練，隨著你的使用不斷進化。

現在的玩法是：模型（固化死的） + 數據（外掛臨時喂）。我說的玩法是：模型（持續(xù)進化） = 基座智能（IQ）+ 你的個人知識（數據）。聽起來很科幻？其實不是。

具體怎么搞？不是共享一個大模型，而是每個用戶有一個獨立的模型副本，連LoRA都不是。你用得越多，模型就越懂你。不是靠什么 RAG 檢索，而是真正"記住"你。

每次你和模型對話，對話內容被編碼，微調你的個人權重，重要知識直接寫入神經元，模型逐漸"理解"你的思維方式和工作習慣。用一個月后，模型記住你的項目結構（不用每次都加載進 Context），知道你的編碼風格（不用寫 .cursorrules），懂你的專業(yè)術語（不用每次解釋），能預測你的意圖（甚至主動給建議）。這才是真正的"個人助理"，不是那種每次對話都失憶的傻瓜機器人。

關鍵問題是怎么把"智力"和"知識"分離開？Base Model 是共享的"智商"：推理能力、語言理解、代碼生成、通用常識。Personal Layer 是你的專屬"知識"：你的項目代碼和架構、你的工作文檔和筆記、你的編碼偏好和習慣、你的歷史對話和經驗。

怎么實現？可能的技術路徑有：Mixture of Experts（基座模型 + 你的個人 Expert 模塊）、Adapter Layers（基座模型凍結不動，只訓練你的 Adapter）、Memory Networks（顯式的記憶存儲層）、Neural Compression（把你的知識壓縮到少量參數里）。

為什么這是通向 AGI 的必經之路？因為 RAG 是死胡同。知識永遠在"外面"，不是模型的一部分；模型無法對知識進行深度推理，只能表面理解；檢索到的知識是"死"的文本，不是"活"的理解。

舉個例子你就明白了。RAG 模式下，你問："項目中 UserService 的設計有問題嗎？"AI 檢索 UserService 代碼，然后分析："可能有并發(fā)問題"。個人化模型呢？你問："UserService 有問題嗎？"AI 說："你上周提到的并發(fā)問題還沒解決吧？我注意到你在 OrderService 里也用了類似的模式，建議一起重構。根據你的編碼習慣，我已經生成了一個方案，你看看..."

看出區(qū)別了嗎？RAG 每次對話都像"初次見面"，需要重新介紹自己。個人化模型真正"認識你"，知道你的過去，理解你的習慣。

技術上能做到嗎？現在的障礙是：訓練成本高，每個用戶都訓練一個模型？瘋了吧？隱私問題，個人模型怎么管理？放哪？存儲問題，幾千萬用戶 × 每人一個模型 = 爆炸。

聽起來不可能？其實有辦法。現在也有一些嘗試，比如 LoRA + 量化，個人層其實只有幾 MB，不是整個模型都要存。聯邦學習，本地訓練你的個人層，云端只管基座模型。邊緣計算，個人模型跑在你本地，隱私也解決了。增量學習，不是全量訓練，而是持續(xù)微調，成本可控。

清醒點，別被忽悠了

回到最開始的問題：Claude Skills 是不是創(chuàng)新？

商業(yè)角度：是的，營銷很成功，包裝很漂亮。

技術角度：算不上顛覆性創(chuàng)新。本質上，Claude Skills 只是 RAG 的一種增強版本，把元數據管理和檢索結合了一下。它確實在工程上做了些優(yōu)化——漸進式披露、智能匹配、可執(zhí)行代碼，這些都是實實在在的改進。

但說到底，不管是 Tools、MCP、cursorrules 還是 Skills，都沒有跳出"上下文管理"這個框架。處理方式無外乎兩種：元數據管理和檢索（不管是語義搜索還是數據庫查詢，不管存在 Markdown 還是向量庫，只是換了個形式）。

核心問題（召回率、精準度、稀釋效應、成本）依然存在，只是換了種方式存在。和 Cursor Rules 相比，Claude Skills 更智能了一點，但沒有質的飛躍。

給技術人的幾句話：

別被營銷話術忽悠瘸了，但也別一棒子打死。透過現象看技術原理，認清它們本質上都是在做上下文管理。根據實際需求選工具，別追概念追風口。別把基礎設施綁在單一廠商上，哪天坑你你都不知道。真正的創(chuàng)新在"個人化模型"，不在上下文管理的第 N 次優(yōu)化。

大模型的終極形態(tài)，不應該是我們不斷"喂數據"的工具，而應該是一個真正"理解我們"、隨我們一起進化的智能伙伴。

在那一天到來之前，保持清醒，別為每個新概念買單。技術人的價值，在于看穿迷霧，認清本質。