跳到主要內容

別讓大腦去搬貨：談 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 時代的價值和定義是什麼？留給大家思考？

標籤：

留言

張貼留言

這個網誌中的熱門文章

Vibe Coding：為什麼 Junior 更快上手？Senior 要如何追趕？

現象層面（市場觀察） 最近有篇文章討論 junior & senior 開發者在 AI 時代的角色轉變，非常熱門。 身為 Cympack 產品開發團隊 ，我們也一直關注這個議題，在閱讀這篇文章時觀察到一些有趣的現象，對我們來說，這正好反映出 AI 正在改變開發生態，junior 借力 AI 快速成長、senior 則需要在 「架構思維」 與 「多 agent 協作」 中找到新定位，其中有些啟發（insight) 可以跟大家分享。 為什麼 Junior 更容易上手 vibe coding？ 心智負擔低 → Junior 沒有太多傳統 code workflow 的框架包袱 敢於嘗鮮 → Gen Z / 年輕工程師天生習慣用 prompt-based 工具、跟 LLM 互動 少「優雅程式設計」的束縛 → 不太糾結「這樣寫會不會不夠優雅」，反而 embrace 快速迭代、快速出成果 反觀 Senior： 熟悉大型系統設計 有豐富的「工程正統流程」知識（架構設計、測試策略、效能優化、設計模式） 對 AI 生成 code 的品質 / 維護性通常比較保留 部分 10+ 年資深工程師，對 prompt engineering 沒那麼熟練，還在觀望 技能面（未來的關鍵能力） Vibe coding 本質上 = prompt engineering + AI co-pilot 管理能力 能力項目 誰目前比較有優勢？ Prompt 撰寫 / AI 互動 Junior 較強（熟悉 chat-based 流程） 系統設計 / 架構把關 Senior 較強 AI 生成 code 驗證 / Bug 察覺能力 Senior 較強（能看出潛在問題） 快速疊代 / Hackathon 式開發 Junior 較強 長期維護性 / 穩定性 Senior 較強 總結 Junior 確實更快適應 vibe coding，並且更習慣以 「chat-based coding」 的工作流開發。 Senior 擁有驗證 AI 產物與系統設計的深度能力，但若不主動練習 vibe coding，長期會逐漸落後於新一波開發潮流。 就如同在 GAI 技術年會分享，希望帶給各位的感受， 『與 AI 協...
張貼留言
繼續閱讀>>

Vibe Coding 協作到自建 Dev Agent？從 Claude / Codex 到 OpenHands

過去一年，越來越多工程師開始 把 AI 真正帶進工作流程 。從一開始用 ChatGPT、Claude 來問語法問題，到後來很多人愛上 Cursor，直接在編輯器裡讓 AI 幫忙改 code、補 test case、甚至自動整理 PR。這樣的開發體驗，已經大大改變了我們寫程式的方式。 更現實的是，在很多企業內部、政府單位、或涉及機密資料的專案裡， 其實根本不能直接用 Cursor 或雲端 LLM 工具。   畢竟這些服務通常會把資料傳到雲端模型做處理，萬一專案裡有未公開的技術、敏感客戶資料，或是受限於法規 （像金融、醫療、政府標案） ，直接用雲端 AI 工具就會踩 紅線 。  因此，許多團隊反而更希望 「自己架一套 Dev Agent」 ，可以在內網執行，資料完全掌握在自己手上，該整合的內部工具、該讀的私有 repo、該串的 CI/CD pipeline，全部客製化、安全可控。 這時候，像 OpenHands 這樣的開源 Dev Agent 框架就特別有價值。它的出發點不是單純的 AI 助手，而是讓你能夠打造出一個真的可以跑在自己環境裡、可以理解整個開發流程的 AI 工程師。從建置到部署，從 CLI 操作到瀏覽器查詢， 從多檔案編輯到自動測試，全部都能自己完成，甚至還能針對不同專案調整專屬的工作流。 對很多開始探索 AI 協作開發的團隊來說，這是一條 從 「AI 幫你寫一段程式」，走向「AI 幫你解決一整個任務」 的進化路徑。而且，還是在可控、可自定義、安全的環境裡完成的。 🧩 主要概述 OpenHands 是由 All‑Hands AI 開發的開源「軟體開發代理人平台」，能模仿人類工程師從建立程式、修改程式碼、執行指令，到瀏覽網頁、呼叫 API……等一整套開發流程 它提供雲端（OpenHands Cloud）與本地 Docker 運行版本，用戶能配置 LLM（如 Claude、OpenAI、Gemini…) 📚 核心特性與怎麼使用 代理人的工具能力 支援代碼編輯、命令行、執行環境、網頁瀏覽、API 呼叫—接近人類開發者完整技能。其中 OpenHands Cloud 版本提供 $50 試用額度讓大家方便使用，又或者如果自己本機有 docker 的話，可以自己Local 版本透過 Docker 自架環境。 ...
張貼留言
繼續閱讀>>

Google Gemini 全端 AI Agent 快速入門 - 打造「思考」的 AI 助理

一套從搜尋、反思到輸出的全端 AI 代理人範例，讓你看懂什麼叫 Research Agent 在 AI 工具百家爭鳴的今天，大家都在問一個問題： 「我能不能不只問 AI 答案，而是讓它像一位助理一樣，有流程、有反思、還有出處，真正幫我完成一件事？」 Google 最近釋出了一個相當具有指標意義的開源專案 gemini-fullstack-langgraph-quickstart ，正是為了解這個問題而誕生。 這套系統到底是什麼？ 這個範例不是傳統 Chatbot，而是展示一個完整的 AI research agent ： 它會根據使用者的提問，自動發想搜尋關鍵字、查資料、整合重點，最後給出答案還附上引用來源。背後的邏輯設計得非常扎實，不只是能跑，更是具備可讀性、可擴展性與可商用性。 它的流程大致如下：  1. 使用者輸入問題（例如：「抖音是否影響台灣選舉？」）  2. Gemini LLM 幫你想出關鍵字（不只是照抄問題）  3. 呼叫 Google Search API 抓資料   4. LangGraph 控制流程 → 判斷資料夠不夠 → 若不足，自動補查  5. 整合最終答案，並產生 citation（來源說明） 你可以想像這就像一位實習助理幫你寫報告， 不只輸出一段內容，而是會 去查、會判斷、會補資料，而且說明「我為什麼這樣說」 。 LangGraph 是什麼角色？ LangGraph 就是整個 Agent 背後的控制系統 。 用白話講，它幫你定義 AI 每一步要幹嘛、遇到什麼狀況該走哪條路、要不要反思、要不要再查，甚至可以定義條件邏輯與資料流動。 這就不像寫一個單純的 Chat API，而是比較像「把一個流程圖變成可以跑的程式」。 對工程師來說，它提供了從 prompt 到流程控制的設計彈性；對產品設計來說，它讓 AI 有了 「多步驟任務執行」 的能力。 技術架構與使用方式 這整套系統是 Fullstack 架構，前後端都幫你整好了，技術選型也非常實用：   前端：Vite + React + TailwindCSS + Shadcn UI  後端：FastAPI + LangGraph...
張貼留言
繼續閱讀>>