Claude Code SKILL 是一套讓 AI 記住「怎麼做事」的機制——不是記住你的偏好，而是記住完整的工作流程。CLAUDE.md 解決「AI 記住你是誰」，SKILL 解決「AI 記住怎麼做事」。當你有 14 個 Skill 串成一條 pipeline，從寫文章到發布社群只需要一句話觸發。這篇從我自己每天在用的 AI 辦公室系統出發，帶你從「每次重複交代」進化到「一句話搞定整條流程」。
你用 Claude Code 是不是每次都要重新交代一樣的事？
「幫我整理成表格、時間用 24 小時制、最後算總工時。」
Claude 做得到。做得很好。
但下次開新對話，你又要再說一遍。
「請用繁體中文、段落之間空一行、結尾加 CTA。」
又做到了。但這次你還要補一句：「對了，社群貼文 LinkedIn 要正式一點，Threads 可以口語。」
它不是不會做事——它是每次都忘了怎麼做。
坦白說，我自己一開始也沒搞清楚這件事。
我把所有東西都塞進 CLAUDE.md——寫作風格、發布流程、社群排程規則、圖片規格、WordPress 設定。結果那份文件長到超過三千字，AI 每次對話都要讀完，但其中 90% 跟當下的任務根本無關。更慘的是，塞太多東西之後，AI 反而開始搞混——該用表格的時候用了列表，該口語的地方寫得像論文。
那一刻我才意識到：把所有事情都塞進「AI 記住你是誰」裡面，跟「AI 記住怎麼做事」是兩回事。
CLAUDE.md 解決的是前者。後者需要另一個東西。
先講結論：
- CLAUDE.md = 入職手冊。告訴 AI 你是誰、你的偏好、你的工作風格。
- SKILL = SOP 手冊。告訴 AI 這件事怎麼做、有哪些步驟、哪些例外要處理。
一句話版本：CLAUDE.md 告訴 AI 你喝美式不加糖，SKILL 告訴 AI 怎麼幫你泡咖啡。
為什麼要分開？
因為「你是誰」和「事情怎麼做」是兩種完全不同的知識。你的寫作風格、語言偏好、資料夾命名規則——這些放 CLAUDE.md 沒問題，因為它們是「通用規則」，每次對話都會自動載入。
但當你有一套完整的工作流程——步驟多、有邏輯順序、有品質關卡、有例外處理——全部塞進 CLAUDE.md 會怎樣？
它會變成一份三千字的文件，AI 每次對話都要讀完，但其中 90% 跟當下的任務無關。
💡 SKILL 的核心設計哲學是「需要的時候才載入」。 AI 不會每次都讀你所有的 SKILL，它只在判斷「現在這個任務需要」的時候才去拿。這跟 CLAUDE.md 的「每次都讀」完全不同。
講直白一點：CLAUDE.md 是讓 AI 認識你，SKILL 是讓 AI 取代你。取代你每次重複做的那些事。
如果你用過 claude.ai 網頁版，側邊欄有一個「Projects」功能——你可以建一個 Project，在裡面設定系統指令（Custom Instructions）和上傳參考文件，之後在這個 Project 底下開的每一次對話，Claude 都會自動帶入那些指令。
聽起來跟 Skill 很像？其實解決的問題不太一樣。
claude.ai 的 Projects 比較像「一間設定好的辦公室」——你走進去，牆上貼的規矩、桌上放的參考資料都固定在那裡。每次進來都是同一套。適合的場景是：你有一組固定的指令和文件，希望每次對話都自動套用，不用重複貼。
Claude Code 的 Skill 比較像「你隨身帶的工具箱」——你不用走進特定的房間，而是走到哪裡、遇到什麼任務，就從工具箱裡拿對的工具出來。而且工具之間可以串接。
而且最關鍵的差異：Skill 可以疊加在同一條工作流裡。你可以在同一次對話中，先觸發 article-copilot 寫文章，寫完觸發 publish-to-wordpress 發布，再觸發 mixpost-scheduler 排程社群——三個 Skill 串成一條 pipeline。在 claude.ai Projects 裡，你沒辦法在一個 Project 中動態切換不同的 SOP。
SKILL 的本體就是一個資料夾，裡面放一份 SKILL.md。
.claude/skills/└── mixpost-scheduler/ ← 你的 Skill 名稱
└── SKILL.md ← 核心檔案SKILL.md 裡面有三個關鍵部分：
第一：description（觸發條件）
寫在檔案最上方的 frontmatter 裡，告訴 AI「什麼時候該用這個 Skill」。
第二：步驟與規則
你希望 AI 按什麼順序做事、有哪些硬性規則、哪些地方不能出錯。
第三：references 子資料夾（進階）
當你的 SOP 太長，可以拆成多個檔案放在 references/ 裡，SKILL.md 只放入口和索引。
---name: meeting-notes
description: “當用戶說「整理會議記錄」或貼上會議逐字稿時觸發”
會議記錄整理
- 用「 會議摘要」開頭，3 句話總結
- 列出所有「行動項目」，格式：
- [ ] 負責人：內容（截止日） - 按主題分段整理討論內容
- 結尾加「 下次會議追蹤」
就這樣。一個 Skill 就是一份 Markdown 文件。不需要會寫程式，不需要裝任何東西。
我自己的 article-copilot Skill 的結構長這樣：
.claude/skills/article-copilot/├── SKILL.md ← 入口（精簡版）
├── full-spec.md ← 完整規範
└── references/
├── style-guide.md ← 寫作風格指南
├── personal-context.md ← 身份背景（防止 AI 編造）
├── research-methodology.md ← 研究方法論
├── workflow-details.md ← 工作流程索引
├── modular/
│ ├── 01-triggers-and-stage-map.md
│ ├── 02-stage-gates.md
│ └── 03-output-and-handoff.md
└── workflow/
├── stage-1-style-alignment.md
├── stage-2-research.md
├── stage-3-outline.md
├── stage-4-writing.md
├── stage-4.5-self-check.md
├── stage-4.6-critic-review.md
├── stage-5-finalize.md
└── stage-6-blog.md是的，一個 Skill 可以有 15 個以上的參考文件。
這不是故意搞複雜。這是因為「寫一篇好文章」本身就是一個複雜流程——它有 6 個階段、有品質關卡（情緒推力自檢、批判審查）、有風格指南、有研究方法論。
💡 Skill 的複雜度應該反映任務的複雜度。 會議記錄 10 行就夠，但一套完整的內容產出流程，10 行根本不夠用。
SKILL.md 裡面最重要的一行，不是步驟，不是規則，是 description。
因為 description 決定了：AI 什麼時候會自動去拿這個 Skill。
原理很簡單——當你跟 Claude Code 說話時，它會掃描所有可用的 Skill，把你說的話跟每個 Skill 的 description 做比對。如果匹配度夠高，它就會自動載入那個 Skill。
所以 description 的寫法，直接決定觸發的準確率。
看到差異了嗎？
好的 description 寫得像「使用者會說的話」。 你不會跟 Claude 說「請啟動社群工具」，你會說「幫我排程社群貼文」——所以 description 裡要寫「排程社群貼文」，不是「社群工具」。
我的 mixpost-scheduler Skill 的 description 是這樣寫的：
description: |透過 Mixpost API 排程社群貼文到多個平台。
觸發時機：
- 當用戶說「排程社群貼文」、「發布到 Mixpost」、「schedule social posts」
- 當用戶想要排程 Facebook、LinkedIn、Instagram、Threads 等平台的貼文
- 當用戶完成文章發布後，想要排程社群宣傳貼文
- 當用戶說「post to Mixpost」、「排程貼文」、「安排社群發布時間」
注意，我把使用者可能會說的每一種講法都列上去了。中文的、英文的、口語的、正式的。
這不是多此一舉。這是從無數次「AI 沒有自動觸發」的經驗中學到的。
💡 description 的黃金法則：把你可能會對 AI 說的每一種觸發語句，都寫進去。 寧可多寫幾行，也不要讓 AI 漏觸發。
到這裡，你已經知道一個 Skill 怎麼寫、怎麼觸發了。
但說實話，單個 Skill 的威力有限。真正讓我的工作效率產生質變的，不是「一個好用的 SOP」，是「一整套 SOP 被串成自動化流水線」。
我每天用來產出內容的專案裡，有 14 個 Skills：
重點不是數量多。重點是這些 Skill 可以被串成一條 pipeline：
寫文章（article-copilot）→ 生成配圖（article-image-generator）
→ 生成縮圖（kie-thumbnail-generator）
→ 上傳 WordPress（publish-to-wordpress）
→ 等 public URL
→ 社群文案 + 排程（mixpost-scheduler）
→ 電子報（newsletter-to-kit）以前，這條流程要我手動操作 2-3 小時。打開 WordPress 後台、手動上傳圖片、一個一個平台排程貼文、再去 ConvertKit 排電子報。
但說真的，最讓我不舒服的不是「花時間」——是我突然意識到，每次手動操作這些步驟的時候，我就是在當 AI 的人肉記憶體。AI 會寫文章、會排版、會分析數據——但它不記得「寫完之後要幹嘛」，所以我得在旁邊一步一步提醒它。這不叫「善用 AI」，這叫「你在幫 AI 打工」。
現在，我只要說一句「幫我跑完整的內容發布流程」，就觸發整條 pipeline。
而且更關鍵的是——每一步的品質都有 Skill 在控制。不是「隨便做完就好」，是每個 Skill 裡都寫了品質標準。
article-copilot 有「情緒推力自檢」——8 個維度、每個維度 1-10 分，總分低於 6 要打回重寫。
publish-to-wordpress 有「配圖密度檢查」——每 600-900 字至少一張圖，不達標不能發。
mixpost-scheduler 有「平台格式規範」——LinkedIn 正式、Threads 口語，自動切換。
💡 Skill 不只是「記住步驟」，更是「記住品質標準」。 當你把品質關卡寫進 Skill，AI 每次執行都會自我檢查，不需要你在旁邊盯。
如果你只用一個 Claude Code 對話窗口，Skill 就是「一個人的 SOP 集合」。
但當你開始用 Agent（子代理人），Skill 就變成「組織架構」了。
我的專案裡有 7 個以上的 Agent，每個 Agent 有不同的角色和專屬 Skill：
這代表什麼？
代表我可以說「幫我分析這週的 GA4 數據，然後根據數據建議下週的內容方向」——content-strategist agent 會去調用 data-analyst-ga4 的能力，拿到數據後再用自己的 Skill 做策略分析。
Agent 之間會協作。而 Skill 就是每個 Agent 的「能力說明書」。
Claude Code 掃描兩個位置的 Skill：
~/.claude/skills/→ 全域，所有專案都能用你的專案/.claude/skills/→ 專案級，只在這個專案生效
我的做法：
- 全域放「跟個人習慣有關的」（如通用寫作風格、Git 慣例）
- 專案級放「跟這個專案有關的」（如 article-copilot、publish-to-wordpress）
為什麼要分？因為我不只一個專案。我的美股投資內容用不到 article-copilot 的情緒推力自檢，但需要投資類文章的利益揭露規範。不同專案、不同 Skill 組合。
💡 Skill 的分層設計，讓你可以用同一套工具，在不同專案裡表現出不同的行為。 這就是從「個人助手」到「組織系統」的關鍵跨越。
如果你現在用的是 ChatGPT 的 GPTs 或 Google 的 Gems，你一定經歷過這種痛苦：
你有一個「寫作機器人」、一個「翻譯機器人」、一個「資料分析機器人」。每次要做事，你得先想：「這件事要找哪個機器人？」然後切換過去，再把上下文重新交代一遍。
這就是「人去找工具」。
Skill 的做法完全相反。
你不需要切換任何東西。你就在同一個 Claude Code 對話裡說話，AI 根據你說的內容，自動判斷要用哪個 Skill。
「幫我把這篇文章排程到社群。」→ 自動觸發 mixpost-scheduler
「幫我分析上週的流量數據。」→ 自動觸發 data-analyst-ga4
「幫我把這篇轉成電子報。」→ 自動觸發 newsletter-to-kit
你只需要「說你要做什麼」，不需要「去找誰能做」。
這是工具來找人。
而且 Skill 還有一個 GPTs 做不到的優勢：它是純文字檔，你完全擁有它。
- 你可以用 Git 做版本控制（上週改壞了？回退一個 commit）
- 你可以跨裝置同步（家裡的電腦和辦公室的一模一樣）
- 你可以分享給團隊（把
.claude/skills/資料夾 push 到 repo） - 你可以隨時修改（打開 VS Code，改完存檔，下次對話就生效）
GPTs 掛了、平台改規則了、API 格式變了——你只能等 OpenAI 修。
Skill 壞了？你自己打開 SKILL.md 改兩行，30 秒搞定。
看到這裡，你可能覺得「14 個 Skill + 7 個 Agent」太嚇人了。
不用一步到位。
判斷標準很簡單：如果你連續三次在不同對話中跟 Claude 講同一件事，那就是一個 Skill。
以下是三個幾乎所有人都能立刻開始用的 Skill：
---name: meeting-notes
description: “當用戶貼上會議逐字稿、說「整理會議記錄」或「幫我整理這個會議」時觸發”
會議記錄整理 SOP
- 用「 會議摘要」開頭，3 句話總結重點
- 列出所有行動項目：
- [ ] @負責人：具體事項（截止日期） - 按討論主題分段整理，每段有小標題
- 結尾加「 下次追蹤事項」
- 時間格式統一用 24 小時制
---name: social-post
description: “當用戶說「幫我寫社群貼文」、「發 IG」、「寫一篇 LinkedIn」、「social post」時觸發”
社群貼文 SOP
平台規格
- Facebook：300-500 字，口語化，可用 emoji
- LinkedIn：200-400 字，專業但不僵硬，段落分明
- Threads：100-200 字，最口語，像跟朋友聊天
- X/Twitter：280 字以內，精煉有力
結構
- Hook（前 2 行決定生死）
- 核心觀點（1-3 個重點）
- CTA（提問或邀請互動）
規則
- 每個平台各一版，不是複製貼上改長度
- 繁體中文
—name: reading-notes
description: “當用戶貼上書摘、文章摘要，或說「幫我整理閱讀筆記」「整理這本書的重點」時觸發”
閱讀筆記 SOP
格式
- 書名 / 文章標題 + 作者 + 日期
- 一句話總結：這本書 / 文章在說什麼
- 三個核心觀點：每個觀點用 2-3 句話解釋
- 我的反思：這跟我現在的工作/生活有什麼關聯
- 行動項目：讀完之後，我可以立刻做什麼
規則
- 不要照抄原文，用自己的話重述
- 「我的反思」是最重要的部分，不能省略
這三個加起來，大概花你 15 分鐘。但從此以後，你再也不用重複交代這些事了。
Skill 只是 Claude Code 記憶系統的一層。
這篇講的是 Skill 這一層，但 Claude Code 的記憶系統其實有三層——身份記憶（CLAUDE.md）、程序記憶（SKILL）、跨對話持久記憶。如果你想看完整架構，這篇是入口：
OpenClaw 三層記憶系統：讓 AI 真正記住你是誰、記住怎麼做事、記住上次聊到哪
而如果你想看「一個人管一間 AI 公司」的全貌——多個 Agent 怎麼分工、Skill 怎麼被調度、pipeline 怎麼串——這篇會幫你把圖像拼完整：
OpenClaw AI Company Mission Control：一個人的 AI 辦公室怎麼運作
如果你想更深入學習怎麼從零開始建立自己的 AI 自動化系統，我在《AI 效率革命聯盟》社群裡有完整的實戰模板和工作流程，500+ 位學員已經在用。不是教你概念，是直接給你可以跑的系統。有興趣可以先從免費社群逛逛，感受一下。
如果你現在已經在用 Claude Code，但總覺得效率沒有想像中高——回頭看看你每次對話的前五分鐘在做什麼。如果你在「交代 AI 該怎麼做」，那你還在幫 AI 打工。把那些交代的內容寫成 Skill，讓 AI 自己記住。
如果你是剛開始用、或還在觀望的人——不用急著搞什麼 14 個 Skill 的系統。先寫一個。就一個。下次你又要跟 Claude 說「用表格、24 小時制、結尾算總工時」的時候，把它寫成 SKILL.md。
等你寫到第十個 Skill 的時候，你會回頭發現——你不是在用一個工具，你是在建一間公司。
CLAUDE.md 是「身份設定」，用來存放你的偏好、風格和通用規則，每次對話自動載入。SKILL 是「工作流程 SOP」，用來定義特定任務的步驟、格式和品質標準，只在 AI 判斷需要時才載入。兩者互補，分開管理可以避免 CLAUDE.md 過長導致 token 浪費。
完全可以。SKILL.md 就是一份 Markdown 純文字文件，不需要任何程式語言。你甚至可以直接跟 Claude 說「幫我把剛剛這段對話整理成一個 SKILL」，它會自動幫你建立資料夾和檔案。核心技能是「把你每次重複交代的事情寫清楚」，這是文字能力，不是程式能力。
description 要寫得像「使用者會說的話」，而不是工具的功能描述。把你可能會對 Claude 說的每一種觸發語句都列上去——中文、英文、口語、正式的說法。例如「排程社群貼文」、「發布到 Mixpost」、「schedule social posts」都要寫進去。觸發語句越完整，AI 自動偵測的準確率越高。
Claude Code 掃描兩個位置：~/.claude/skills/（全域，所有專案共用）和 你的專案/.claude/skills/（專案級，只在該專案生效）。建議把「跟個人習慣相關的 Skill」放全域（如 Git 慣例、通用寫作風格），把「跟特定專案相關的 Skill」放專案級。這樣不同專案可以有不同的 Skill 組合，不會互相干擾。
沒有硬性上限。簡單的 Skill 可以只有 10 行（如會議記錄格式化），複雜的 Skill 可以有 15 個以上的參考文件（如我的 article-copilot，包含風格指南、研究方法論、品質關卡等）。關鍵原則：Skill 的複雜度應該反映任務本身的複雜度。不要為了簡單而省略必要的品質標準，也不要為了炫技而把簡單任務搞複雜。
關於作者：追日Gucci（Gucci Chang）
前美商 Micron 大數據工程師，2019 年離開穩定高薪，專職投入內容創業。2023 年 AI 浪潮興起，憑藉數據工程背景快速切入——從 Make、n8n、 到 Vibe Coding、AI Agent，持續站在 AI 應用的最前線。
透過 YouTube 頻道《AI 效率革命聯盟》（5.3 萬訂閱）和 500+ 學員的實戰驗證，幫助數位工作者用 AI 系統取代蠻力——有系統地把工作效率槓桿數十倍。
YouTube | Skool 付費社群
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/251873.html