Claude Skills 不就是把提示詞存個文件夾嗎？

哈嘍，大家好，我是劉小排。

最近這段時間，我在反復研究和使用 Claude 新發布的 Skills 功能。

很多朋友問第一眼看過去會覺得：

這不就是把提示詞存成一個文件夾嗎？

再用一用，會覺得：

這和MCP有啥區別？

估計 Anthropic 自己也被問懵了，于是官方干脆寫了一篇長文：《Skills explained: How Skills compares to prompts, Projects, MCP, and subagents》，專門來解釋這幾個名字聽上去就很反人類的概念。

https://claude.com/blog/skills-explained

這篇文章來得非常及時。對我們這些做 AI 產品的人來說，它其實在講一件更大的事：

有區別，而且區別非常大。 通俗一點講：Skills 是把「提示詞工程」，升級成了「流程工程」。

下面這篇是我站在「AI 產品創業者」的視角，把官方內容全部捋一遍，再加上我自己的理解。

提前說一句：很長，但是值得耐心看完。

接下來我會按這個順序來講：

1. Claude 生態里到底有幾塊「積木」？

2. Skills：讓 Claude 真正「學會干活」

3. Prompts：依然是主角，但天生是一次性的

4. Projects：給每一個重要主題一個「專屬上下文空間」

5. Subagents：給每個子任務配一個「專職 AI 同事」

6. MCP：把所有外部系統接成一張網

7. 一個完整的「研究 Agent」案例：這幾塊積木怎么拼在一起？

8. 官方 FAQ 里的幾個關鍵信息

9. 實際上手：不同類型用戶怎么用 Skills

10. 作為 AI 產品創業者，我自己的一個判斷

下面的文字很長！再次提醒，做好準備！

一、Claude 生態里到底有幾塊「積木」？

先把名字捋順，否則后面全是霧

• Prompts：你在對話框里敲給 Claude 的那一段話

• Skills：一個個「能力文件夾」，里面是可復用的流程、腳本和資源

• Projects：帶自己知識庫和歷史記錄的「項目空間」

• Subagents：專門干某件事的小助手，像「子 AI」

• MCP（Model Context Protocol）：把 Claude 接到你各種外部工具和數據源上的「通用連接層」

如果用一句人話總結：

Prompts 是“當場吩咐一句”， Skills 是“把做事的方法寫進操作手冊”， Projects 是“給 AI 搭一個項目檔案室”， Subagents 是“請來一堆專職的 AI 同事”， MCP 是“打通所有外部系統的總線”。

下面我們一個個拆。

二、Skills：讓 Claude 真正「學會干活」
1. Skills 是什么？

官方定義是：

Skills 是一些文件夾，里面放著指令、腳本和資源，當 Claude 覺得當前任務需要它時，就會動態加載。Claude

你可以把它想象成：
給 Claude 寫的一本本“崗位說明書 + SOP + 工具包”。

比如一個「品牌規范 Skill」，里面可以寫清楚：

• 品牌主色、輔色、漸變怎么用

• 標題字體、正文字體分別是什么

• PPT 的版式有哪些固定模板

• LOGO 在任何地方出現的尺寸和留白規則

• 不允許出現的低級審美錯誤

以后你再讓 Claude「幫我寫一份路演 PPT」，它會自動套用這套規范，不需要你每次重新科普一遍品牌手冊。

2. Skills 在后臺是怎么工作的？

這里有個很有意思的設計：漸進披露（progressive disclosure）。

大致流程是這樣的：

1. 先讀“封面簡介”
   Claude 會先掃描所有可用 Skills 的「元數據」——幾句描述，大約 100 tokens 左右。
   目的只是判斷：這個 Skill 跟當前任務有沒有關系。

2. 覺得相關，再讀“說明書正文”
   一旦判斷相關，它才會加載整個 Skill 的詳細說明（SKILL.md），官網提到上限大約是 5k tokens，這里面通常是：

• 步驟、流程

• 注意事項

• 輸出格式要求

• 風格偏好等
  

真的需要代碼時，才加載腳本和文件
有些 Skill 還會帶腳本或參考文件（比如模板、示例）。
只有在真正需要執行相關操作時，Claude 才會把這些東西「拎進上下文」。

這個設計的意義在于：

你可以給 Claude 裝很多 Skills， 但不會一上來就把上下文撐爆， 它只會在需要的時候，把需要的那一本“手冊”翻開。

官方給了三個典型場景：

• 組織級工作流

• • 品牌規范

  • 法務／合規流程

  • 各種標準化文檔模板、

• 某個專業領域的「經驗總結」

• • Excel 公式、常用數據分析套路

  • PDF 處理的流程

  • 安全審計、代碼 Review 的標準

• 個人偏好 & 習慣

• • 你的筆記結構

  • 你的代碼風格

  • 你的研究方法

一句話：

任何你不想一遍遍重新解釋的東西，都可以長久地寫進 Skill。

三、Prompts：依然是日常交互的主角，但不適合作為「長期記憶」
1. Prompts 是什么？

這個大家都熟：

Prompts 就是你在對話里用自然語言給 Claude 下的那些指令，是實時的、對話式的、一次性的。Claude

比如：

• 「幫我總結這篇文章」

• 「把剛才那段話的語氣改得更專業一點」

• 「幫我分析一下這份數據，看有什么趨勢」

• 「用項目符號重新排版一下」

甚至可以是非常完整的一段復雜 prompt，比如官方舉的「請你對這段代碼做一個完整的安全審計」，后面跟了詳細的檢查項、嚴重程度定義、修復建議要求等等。

2. Prompts 的局限在哪里？

Claude 官方直接說了：

Prompt 是你和模型交互的主要方式，但它不會在不同對話之間自動保留。

也就是說：

• 你今天費心寫了一個很長的「代碼安全審計」提示詞

• 明天開新對話，還得重新粘一遍

• 換個項目、換個窗口，又得重來

于是他們給出一個很自然的建議：

如果你發現自己在多個對話里反復敲同一類 Prompt，那就該把它升級成 Skill 了。

比如這些典型句型：

• 「請按照 OWASP 標準對這段代碼做安全審計」

• 「請總是給出‘高層摘要 + 關鍵發現 + 建議’這三個結構」

這類東西，適合寫進 Skill，變成「永遠的工作方式」，而不是「今天一時想起來的提示詞」。

官方也推薦你先看他們的 prompt library、最佳實踐、以及一個「智能 Prompt 生成器」，這個就不展開了。

四、Projects：給每一個重要主題一個「專屬上下文空間」
1. Projects 是什么？

在 Claude 的付費方案里，Projects 是一個個獨立的工作區：

• 有自己的聊天記錄

• 有自己的知識庫

• 有自己的「項目級」指令
  

每個 Project 有一個大上下文窗口（官方說是 200K tokens 級別），你可以往里面上傳各種文檔、資料，讓 Claude 在這個空間下工作。

當知識量很多的時候，Claude 會自動切換成類似 RAG 的模式，把項目知識進行檢索，整體可擴到原來上下文的 10 倍左右。

2. 什么時候適合用 Projects？

官方建議：

• 需要長期存在的背景知識

• • 某個產品線

  • 某個大客戶

  • 某個長期課題

• 需要把不同工作分“項目隔離”

• • Q4 產品發布

  • 某一場活動運營

  • 某一輪融資材料

• 團隊協作（Team / Enterprise）

• • 共享歷史對話

  • 共享知識庫

• 項目級的自定義指令

• • 這個項目里，所有輸出都要偏「To B、專業、嚴謹」

  • 另一個項目里可以更輕松一點

官方例子：

建一個「Q4 Product Launch」項目，把市場研究、競品分析、產品規格都扔進去，以后在這個項目里的所有對話都會自動帶著這些背景。

這一點很關鍵。官方一句話概括得非常好：

Projects 解決的是「你要知道什么」（背景知識）。 Skills 解決的是「你要怎么做事」（流程方法）。

換個比喻：

• Project 像「整個項目的檔案室＋學習資料」

• Skill 像「公司內部的一份份標準操作手冊」

Project 是局部的——只在這個項目空間里生效。
Skill 是全局可用——任何對話、任何項目，只要相關，都能調出來用。

五、Subagents：給每個子任務配一個「專職 AI 同事」
1. Subagents 是什么？

在 Claude Code 和 Claude Agent SDK 里，你可以創建很多「子代理（subagents）」。它們具備：

• 自己的上下文窗口

• 自己的系統提示

• 自己的一組工具權限

你可以把它們理解成：

Subagents = 一個個崗位明確、權限有限、職責清晰的 AI 員工。

官方給了 4 類典型用途：

• 任務專業化

• • 專門做代碼審查

  • 專門生成單元測試

  • 專門做安全審計

• 上下文的拆分

• • 主對話保持干凈

  • 把“重活”丟給 subagent 做

• 并行處理

• • 一個 subagent 做市場調研

  • 另一個做技術分析

  • 再一個做文檔整理

• 工具權限隔離

• • 某些 subagent 只有只讀權限

  • 它永遠不能寫入、不能刪東西

例子：

建一個「代碼審查 subagent」， 只給它 Read / Grep / Glob 權限，不給 Write / Edit。 每次代碼有改動，Claude 會自動把審查任務丟給它， 這樣就能保證有安全審查，而不會誤改代碼。

官方推薦是：

• 多對多

• • 一個 subagent 可以使用多個 Skills（例如語言規范、領域 Best Practice）

  • 多個 subagent 也可以共享某些 Skills（比如統一的寫作規范 Skill）
    

你可以這樣理解：

Skill 更像“知識＋流程”； Subagent 更像“帶著這些知識/流程去執行任務的具體人”。

Model Context Protocol（MCP）是一個開放協議，用來把 AI 助手接到各種外部系統上。

簡單理解：

你不用再給每個系統寫一套單獨的集成， 只要對接 MCP，就可以用統一方式連接各種數據源和工具。

官方舉的典型連接對象：

• 外部數據源：Google Drive、Slack、GitHub、數據庫等

• 業務工具：CRM、項目管理系統

• 開發環境：本地文件、IDE、版本控制

• 自研系統：你們自己公司的內部平臺

你把這些系統包裝成一個個 MCP server，Claude 作為 MCP client 去連它們。

2. MCP 和 Skills 怎么配合？

非常重要的一點是：

MCP 負責“接通數據和工具”， Skills 負責“告訴 Claude 要怎么用這些數據和工具”。

比如：

• MCP：讓 Claude 能訪問你的數據庫

• Skill：規定「查詢時必須先按日期過濾」「查詢結果要按某種格式輸出」

• MCP：連接你的 Excel 文件

• Skill：規定「生成報表時必須使用哪些公式」「怎么排版」

未來比較理想的狀態是：

每接入一個新系統（MCP）， 最好配一套相應的使用說明和流程（Skill）。

如果你只想知道「這個東西怎么用在真實工作里」，下面這個“研究 Agent”的例子是最值得耐心看完的一段。

官方給了一個很完整的例子：

構建一個用于競品研究的綜合 Agent， 同時用到 Projects、MCP、Skills 和 Subagents。

我們按步驟拆：

第一步：建一個 Project——「競爭情報」

把下面這些東西都扔進去：

• 行業報告、市場分析

• 競爭對手的產品文檔

• CRM 里的用戶反饋

• 你們之前寫過的研究總結

并且加一段項目級指令：

分析競品時要站在我們自家產品戰略的視角， 尤其關注差異化機會和新興趨勢， 給出的結論要帶證據、要可執行建議。Claude

打開幾個 MCP server：

• Google Drive：訪問共享研究文檔

• GitHub：看競品的開源倉庫

• Web 搜索：查實時的市場信息

比如叫competitive-analysis，里面可以包含：

• 公司內部 GDrive 的目錄結構

• 搜索時的最佳實踐

• • 先從哪個目錄下手

  • 優先看最近 6 個月的文檔

  • 最終確認「權威版本」的方式

• 一個標準化的研究工作流：

1. 明確研究主題

2. 在對應的目錄里組合關鍵詞搜索

3. 選 3–5 個最新 / 最關鍵文檔

4. 和戰略文檔交叉引用

5. 輸出時標注來源文件名和日期

這就是一個非常典型的「流程型 Skill」。

第四步：配置 Subagents（在 Claude Code / SDK 里）

比如兩個子代理：

1. market-researcher

• 優先使用權威來源（Gartner/Forrester 等）

• 關注市場份額、增長率、融資情況

• 需要給出帶引用和置信度的結論

• 負責：市場趨勢、行業報告、競品定位

• 工具：Read、Grep、Web-search

• 系統提示里寫清楚：

technical-analyst

• 分析技術棧、架構模式

• 評估可擴展性和性能

• 找出技術優勢和短板，并給出對你有用的啟示

• 負責：技術架構、實現方式、工程決策

• 工具：Read、Bash、Grep

• 系統提示：

你現在問 Claude：

「幫我分析一下我們前三個主要競品最近發布的 AI 功能，它們是怎么定位的？我們有哪些可利用的空檔？」

背后到底會發生什么？（重點來了）

1. Project 上下文加載：

• Claude 拿到你之前上傳的研究文檔、戰略文檔

MCP 聯通數據：

• 去 GDrive 里找最新競品材料

• 去 GitHub 拉開源倉庫

• 用 Web 搜索補實時信息

Skill 啟用：

• 用competitive-analysis這個 Skill 提供的工作流框架來組織分析

Subagents 并行工作：

• market-researcher去研究市場定位

• technical-analyst看技術實現

你通過 Prompt 微調方向：

• 比如補一句：「重點關注醫療行業的企業客戶」

最終，你拿到的是一份：

• 有來源

• 有結構

• 有可執行建議

• 又符合你戰略視角的競品研報。
  

這就是「幾塊積木組合起來」的威力。

八、官方 FAQ 里的關鍵點

最后，官方在文末做了一段 FAQ，總結得很好，我給你濃縮一下：

1. Skills 是怎么保持「高效」的？

靠的就是前面說的「漸進披露」：

• 先掃 metadata

• 再按需加載完整說明

• 有代碼和文件再按需加載

所以你可以放心地給 Claude 裝很多 Skills，它不會一開始就被上下文壓垮。

2. Skills vs Subagents：什么時候用哪個？

• 用Skills：

• • 當你希望「任何 Claude 實例」都能加載某種能力，比如安全審計流程、數據分析方法

• 用Subagents：

• • 當你需要一個完整的「小代理」，自己帶上下文、帶工具權限，能獨立跑完整工作流

最推薦的姿勢是：

Subagent ＋ Skills 組合使用。 讓一個專職“代碼審查 subagent”去調用「語言特定 best practice Skill」， 相當于給這個小同事配一堆教材。

• 用Prompts：

• • 一次性指令、即時交互、補充上下文

• 用Skills：

• • 當你有一套流程／專業經驗，需要反復使用

  • 當你希望 Claude 能自己判斷「什么時候應該套這套流程」

比較理想的模式是：

用 Skills 打地基，用 Prompts 在每次任務上做具體微調。

官方原話的對比非常精煉：

• Projects：

• • 「這是你需要知道的東西」（知識、文檔、背景）

  • 總是在項目里加載

• Skills：

• • 「這是你應該怎么做事」（流程、代碼、方法）

  • 動態按需加載，節省上下文

你可以把它記成一句話：

Project = 知識場景，Skill = 能力模組。

答案是：可以，而且非常推薦。

在 Claude Code 和 Agent SDK 里，Subagent 可以和主 Agent 一樣使用 Skills。

比如：

• python-developersubagent

• • 用pandas-analysisSkill 按你團隊習慣來做數據處理

• documentation-writersubagent

• • 用technical-writingSkill 固定 API 文檔的寫法和格式

如果你是劉小排的讀者，那你可以看這篇 和這篇

官方給了三類用戶的路徑，你可以按自己場景選：

1. 如果你是 Claude.ai 網頁用戶

• 在 Settings → Features 里把 Skills 打開

• 去 claude.ai/projects 創建你的第一個項目

• 在一個具體分析任務里嘗試「Project + Skill」聯合使用

• 去看文檔里關于 Skills endpoint 的部分（支持通過 API 管理 Skills）

• 打開官方的「skills cookbook」倉庫，看他們給的 Skill 示例

• 通過插件市場安裝 Skills

• 同樣可以參考「skills cookbook」，照著抄一遍先跑起來

十、作為 AI 產品創業者，我的一個小結論

讀完這篇官方文檔，我腦子里冒出的最強烈一個念頭是：

Prompt Engineering 只是上半場， 真正的下半場，是「流程工程（Workflow / Skill Engineering）」。

• Prompt 解決的是「怎么和模型說話」

• Skill/Project/Subagent/MCP 解決的是
  「模型在一個復雜環境下，怎么長期、穩定、可維護地為你干活」

對于做 AI 產品的人來說，這是幾個非常現實的落地點：

1. 你的差異化，將越來越體現在 Skills 設計上

• 把領域經驗、工作流、組織規范，沉淀成一套 Skills 庫

• 這是你產品的護城河，而不僅僅是“調了哪個大模型”

你的產品架構，會越來越像「Agent 積木組合」

• 某個功能 = 若干 Project + Skills + Subagents + MCP 的組合

• 未來甚至可以對外開放自己的 Skill Store

你的團隊，遲早需要一個“Skill Engineer / AI Workflow Architect”角色

• 不再只是寫 prompt 的人

• 而是真正負責「把經驗變成可復用的 AI 工作流」的人

現在很多人還沉迷在“寫花式 Prompt”，但從 Skills / Projects / MCP / Subagents 這套組合來看，趨勢已經非常明顯了：

做 AI 產品，如果只停留在 Prompt 層，就是停留在 Demo 層；要往真正的“業務系統”走，就繞不開流程工程和 Skill 設計。

我自己現在已經用 Skills 做很多件事：

• 一個是「寫公眾號 Skill」，比如標題怎么寫、導語怎么設計、配圖比例怎么選，都寫死在里面；

• 一個是「代碼性能分析Skill」，性能涉及到很多方面，比如數據庫設計（索引、事務等）、Redis和數據庫的配合、代碼中的算法和架構等等、緩存策略等等，單獨靠MCP或Subagent是很難完成的，需要一整套流程。

• 一個是「產品更新日志 Skill」，我只管往里丟 changelog，它會自動幫我改成對用戶友好的版本。

• 一個是「產品idea頭腦風暴Skill」，我有新的idea的時候，不再是直接問ChatGPT，而是有一個特定的流程。

• 一個是「域名討論Skill」，做新產品時，想域名是一個頭疼的事，可以通過Skill來找到后選域名、查詢是否可用

謝謝你看到這里！期待你的反饋。