別讓大腦去搬貨：談 Claude Skills + n8n 的『三明治架構』實戰筆記

最近在看 Anthropic 剛推的 Claude Skills，官方文件把這東西定義成「AI 的職前訓練手冊」。

根據 Anthropic 官方定義與技術文件，所謂的「Claude Skill」（正式名稱通常稱為 Agent Skills）是一個非常獨特且強大的功能模組。

關於 Claude Skills 的官方技術文件，看完後確實很有意思。 特別是它提到的核心概念：「漸進式揭露 (Progressive Disclosure)」。

簡單說，以前我們寫 Agent，是把所有規則一次塞給它；但 Claude Skills 是讓它像人類員工一樣，平常只知道自己「有這個技能」，等到真的要寫信、分析報表時，才去打開那個 SKILL.md 檔案讀 SOP。

這在邏輯上非常合理，把 Token 省下來，準度也提高。但當我試著把官方範例那個 professional-email-writer 真正放進商業流程跑過後，發現這中間有些「理論與實戰」的摩擦點

---

一、 Claude Skills 有什麼特別之處？

與一般 LLM 的「Tool Use (Function Calling)」不同，Claude Skills 的設計核心在於「漸進式揭露 (Progressive Disclosure)」與「情境注入」。

1. 漸進式揭露 (Progressive Disclosure) - 最核心的差異

   • 一般做法： 通常我們會把所有規則寫在一個超長的 System Prompt 裡，這會佔用 token 且讓模型分心。

   • Claude Skills： 技能以資料夾形式存在。Claude 平時只知道「我有這個技能的名稱與簡介」。只有當你要求它執行相關任務時，它才會「打開」這個資料夾，讀取裡面的 SKILL.md (詳細指令) 與相關檔案。這極大地節省了上下文空間，並提高了執行精準度。

2. 檔案系統導向 (Filesystem-based)

   • 一個 Skill 就是一個資料夾。裡面可以包含說明書 (SKILL.md)、範本 (templates/)、甚至可執行的程式碼 (scripts/)。Claude 可以像人類員工一樣，去翻閱這個資料夾裡的參考資料或執行裡面的腳本。

3. 模組化與可攜性

   • 你可以把「撰寫 Code Review 的標準」、「公司品牌設計規範」或「財務報表分析流程」打包成不同的 Skills。只要把資料夾分享給同事（或放入專案中），每個人的 Claude 就都學會了這套標準。

---

二、 如何使用 (Usage)

Claude Skills 目前主要應用於 Claude Code (CLI 工具) 以及透過 API 構建的 Agent 系統中。

1. 建立技能的結構

一個標準的 Skill 是一個資料夾，結構如下：

Plaintext

my-skill-folder/ <-- 技能根目錄
├── SKILL.md <-- 核心檔案 (必備)
├── scripts/ <-- (選用) 輔助腳本，如 Python/Bash
│ └── analyze_data.py
└── templates/ <-- (選用) 輸出範本
└── report_format.md

2. 撰寫 SKILL.md (官方範例格式)

這是 Skill 的靈魂。它必須包含 YAML Frontmatter (標頭資訊) 與 Markdown 本文 (指令)。

範例：一個「專業電子郵件撰寫」技能

Markdown

---
name: professional-email-writer
description: 當使用者需要撰寫正式、婉轉且符合商務禮儀的電子郵件時使用此技能。適用於回應客戶投訴、商務提案或跨部門溝通。
---

# Professional Email Writer Instructions

你現在是一位資深的商務溝通專家。當使用者請求撰寫 Email 時，請嚴格遵守以下流程：

## 1. 分析階段
在撰寫任何內容之前，先確認：
- **對象 (Audience)**: 收件人的職位與關係。
- **目的 (Goal)**: 希望達成的具體結果（例如：安撫情緒、獲得批准）。
- **語氣 (Tone)**: 堅定但有禮、或是道歉且誠懇。

## 2. 撰寫規則
- 使用 "BLUF" (Bottom Line Up Front) 原則：第一段即說明來意。
- 避免使用被動語態，除非是為了不指責對方。
- 結尾必須包含明確的 Call to Action (CTA)。

## 3. 範本使用
若使用者未指定格式，請參考以下結構：
> [稱呼]
> 
> [核心訊息摘要]
> 
> [詳細背景或理由]
> 
> [後續步驟/請求]
> 
> [結尾敬語]

## 4. 自我檢查 (必須執行)
輸出草稿前，請檢查：
- 是否有過度承諾？
- 是否有情緒化用語？

3. 如何啟用與呼叫

在 Claude Code (CLI) 中：

1. 將上述資料夾放在專案的 .claude/skills/ 目錄下，或是全域目錄 ~/.claude/skills/。

2. 直接對話：你不需要輸入特殊指令，只要在對話中提到相關需求，Claude 就會自動偵測並載入該技能。

User: "我需要寫一封信給客戶解釋為什麼專案會延期，對方是重要的大客戶，語氣要誠懇但不能示弱。"

Claude (系統內部):

1. 偵測到意圖匹配 professional-email-writer 的 description。

2. 動態載入 SKILL.md 的內容。

3. 依照 Instruction 執行分析與撰寫。

在 API 開發中：

開發者需使用 Anthropic 的 Tools API 或 MCP (Model Context Protocol) 來實作。你需要將 SKILL.md 的內容在適當的時機注入到 System Prompt 或作為 Tool Definition 提供給模型。

應用模式策略：

大腦僅輸出「結構化意圖」，而非執行

這是最穩健的做法。Claude Skills (大腦) 絕對不直接呼叫外部世界，也不直接寫死「我已經幫您退款了」這種文字。

• Skill 的職責： 分析用戶需求，輸出一個 JSON 物件（或 XML），而非最終回覆的 Email。

• Workflow (n8n) 的職責： 接收 JSON -> 驗證業務邏輯 -> 執行 API -> 將結果回傳給 Claude -> Claude 根據結果生成最終 Email。

流程範例：

1. Skill (思考)：讀取客訴，判斷需要退款。

   • Output: {"intent": "refund_request", "amount": 100, "reason": "delay", "draft_tone": "apologetic"}

2. n8n (手腳)：

   • 檢查資料庫：該用戶是否符合退款資格？

   • Case A (符合): 呼叫 Stripe API 退款。回傳 {"status": "success", "transaction_id": "tx_123"} 給 Claude。

   • Case B (不符): 回傳 {"status": "denied", "reason": "policy_limit"} 給 Claude。

3. Skill (生成)：根據 n8n 回傳的狀態，生成最終信件。

   • Case A 信件: 「...我們已為您辦理退款 (單號 tx_123)...」

   • Case B 信件: 「...雖然我們無法直接退款，但我們能提供...」

優點： 解決了「過度承諾」問題，因為 Agent 是在「執行結果確認後」才寫信的。

將 Skills 定義為「唯讀 (Read-Only)」與「規劃 (Planning)」

將 Skill 的權限嚴格限制在「資訊獲取」與「策略建議」。

• Skill (Role: 參謀長)：

  • 可以讀取：SKILL.md 中包含產品規格、歷史案例、FAQ。

  • 產出物：一份「行動建議書 (Action Plan)」。

• n8n (Role: 執行官)：

  • 這是一個「Human-in-the-loop」的環節。

  • n8n 將 Claude 擬好的草稿與建議操作（例如：退款 $50）發送到 Slack/Teams 給人類員工。

  • 人類點擊「Approve」按鈕後，n8n 才真正去打 API 並寄出信件。

優點： 解決了「黑盒效應」與「信任度」問題。在擴張期，讓非技術人員（如客服主管）作為最後把關者。

沙盒模擬 (The Dry-Run Pattern)

如果您希望全自動化，可以在 n8n 中設計一個「預檢 (Pre-flight check)」機制。

• Skill 設定： 在 SKILL.md 中明確定義：「在承諾任何補償前，必須先呼叫 check_compensation_limit 工具」。

• 運作邏輯：

  • Agent 想要賠償 -> 觸發 check_compensation_limit。

  • n8n 攔截請求 -> 檢查當日賠償額度 -> 回傳 true/false。

  • Agent 收到 true -> 寫入信件並標記 execute_refund。

---

總結建議

回到您最初的觀察，「現階段最穩的打法，是把 Claude Skills 嚴格限縮在『內容生成與策略建議』」 —— 這句話完全正確，但我們可以再往前推一步：

把 Claude Skills 當作「業務邏輯的編譯器 (Compiler)」與「最後一哩路的文案潤飾師」，而把「狀態管理 (State Management)」與「副作用 (Side Effects)」完全交給 n8n。

範例：高語意理解型 (適合 Claude Skill)

場景： 「公關危機處理與社群回覆」 情境： 當有人在粉專留言抱怨產品（非結構化文字），你需要判斷情緒強烈度，並擬定回應。這件事很難寫成 if-else 腳本，因為語言太微妙了。

檔案結構

social-media-manager/
├── SKILL.md
└── guidelines/
    ├── brand_voice.txt   (品牌語氣：調皮、正經或溫暖)
    └── forbidden_words.txt (公關禁語表)

SKILL.md 內容範例

---
name: crisis-response-specialist
description: 處理社群媒體上的負面評論與客訴，產出安撫性回覆並判斷是否需要升級處理。
---

# Crisis Response Instructions

你現在是 [公司名稱] 的資深公關經理。你的目標是化解公開場合的衝突，將對話引導至私訊 (DM)。

## 1. 情緒分析 (Sentiment Analysis)
讀取用戶留言，並評分 (1-5，5為極度憤怒)。
- 若分數 >= 4：必須標記 `escalate_to_human: true`。
- 若提及 "詐騙", "法律", "提告"：必須標記 `legal_risk: true`。

## 2. 回覆撰寫原則 (參考 guidelines/brand_voice.txt)
- **Empathy First**: 第一句話必須同理對方的困擾。
- **No Excuses**: 不要解釋技術原因（客戶不在乎），專注於解決方案。
- **Move Channel**: 對於具體個案，請對方提供訂單號並引導至私訊。

## 3. 輸出格式 (JSON Only)
為了讓後端自動化系統 (n8n) 處理，請**嚴格**輸出以下 JSON，不要包含其他文字：

```json
{
  "sentiment_score": 4,
  "escalate_to_human": true,
  "legal_risk": false,
  "suggested_reply": "Hi @User，非常抱歉讓您有這樣的體驗。我們完全理解您的焦急...",
  "internal_note": "用戶抱怨物流延遲，情緒激動，建議由客服主管手動審核後再發出。"
}

#### 💡 這裡為什麼用 Skill？
因為 n8n 無法精準判斷「酸民」跟「真正受委屈的客戶」語氣上的差別。Skill 這裡扮演的是**「大腦（認知與決策）」**。

---

### 實戰範例二：結構化資料轉換型 (適合 Skill + n8n 混合)
**場景：** **「非結構化收據/發票辨識」**
**情境：** 員工上傳一堆亂七八糟的 PDF 或照片文字檔（OCR 後的結果），你需要把這些變成 ERP 系統能吃的格式。

#### `SKILL.md` 內容範例
```markdown
---
name: invoice-parser
description: 將 OCR 掃描後的雜亂文字轉換為符合會計標準的 JSON 格式。
---

# Invoice Parsing Logic

你是一個會計資料輸入員。接收 OCR 文字，並正規化資料。

## 1. 資料提取規則
- **Vendor**: 找出商家名稱。若名稱類似 "7-ELEVEN" 或 "Seven Eleven"，統一輸出 "7-11"。
- **Date**: 將所有日期格式 (2024/01/01, Jan 1st '24) 統一轉換為 `YYYY-MM-DD`。
- **Items**: 忽略 "小計", "折扣" 等行，只抓取具體品項。

## 2. 邏輯檢查
- 檢查 `Total Amount` 是否等於所有 `Items` 價格的總和。
- 若不符，請在 `validation_error` 欄位說明原因。

## 3. 輸出格式
```json
{
  "vendor_normalized": "Starbucks",
  "date": "2024-10-25",
  "items": [
    {"name": "Latte", "price": 150},
    {"name": "Cake", "price": 120}
  ],
  "total": 270,
  "validation_error": null
}

這裡為什麼用 Skill？

Regex (正規表達式) 在處理千奇百怪的格式時非常痛苦。 Claude 可以用「常識」去理解哪一行是店名，哪一行是總金額。

---

什麼時候用 Skill？什麼時候用 n8n？

這是一個「黃金交叉點」的判斷表，給大家參考：

評估維度	適合用 Claude Skill (AI)	適合用 n8n (Rule-based)
輸入資料 (Input)	非結構化、雜亂 (Email, 客戶對話, OCR 文字, 長篇報告)	結構化、固定 (Webhook JSON, 資料庫欄位, API 回傳值)
處理邏輯 (Logic)	模糊、需要「理解」或「創作」 (摘要, 語氣轉換, 翻譯, 意圖判斷, 提取關鍵字)	明確、布林邏輯 (Boolean) (If X > 100 then Y, 格式轉換, 數學運算, 路由分流)
容錯率 (Tolerance)	可接受微小誤差 (回信稍微換個詞沒關係, 摘要抓重點即可)	零容錯 (金流計算, 更新資料庫 ID, 發送 API Key)
成本與速度	慢且貴 (Cost per token) 每次呼叫都要錢，且有延遲。	快且便宜 幾乎即時，成本極低。
外部依賴	無/低 (主要依賴模型內建知識或上下文)	高 (主要負責連接 Gmail, Slack, SQL, CRM)

整合建議

回到之前提到的「痛點」，最穩健的架構通常是 "n8n 包夾 Claude" (The Sandwich Pattern)：

1. n8n (前處理/手腳)：
   • 監聽 Webhook (例如收到新 Email)。
   • 去資料庫抓客戶的基本資料 (CRM Data)。
   • 把「Raw Text」+「CRM Data」打包，丟給 Claude。
2. Claude Skill (核心大腦)：
   • 只負責思考，不執行。
   • 載入 SKILL.md。
   • 分析語意，根據 SOP 決定要不要退款、要回什麼話。
   • 輸出 JSON (如範例一)。

3. n8n (後處理/手腳)：

   • 解析 Claude 回傳的 JSON。
   • If escalate_to_human is true Then 送 Slack 通知主管。
   • Else 呼叫 Gmail API 寄出 suggested_reply。
   • Finally 寫入資料庫 Log。

• n8n 是工廠的傳送帶與機械手臂（負責搬運、按按鈕）。
• Claude Skill 是傳送帶旁那位看著顯微鏡的品管員（負責判斷好壞、寫檢驗報告）。

不要讓品管員去搬貨（Skill 直接 Call API），也不要讓機械手臂去寫報告（n8n 硬寫複雜 Regex），這樣系統就會穩。

總結

Claude Skill 的「必殺技」在於它允許你用寫文件的方式來寫程式。你不需要懂複雜的 Python 邏輯控制，只要用清晰的 Markdown 寫下你的 SOP，Claude 就會嚴格遵守這些步驟，這對於企業內部導入 AI 進行標準化作業非常有用。

skill 目前也默默成為大家的共識標準之一，主要是可以省去許多重複的 prompt, 大家在開發的時候應該也很經常遇到這樣的問題，目標就是懶還可以更懶， AI 自動還可以更自動。

回到問題點，身為開發者，到底 AI 時代的價值和定義是什麼？留給大家思考？