Select Page
Claude Code 如何接 Cloudflare GLM 5.2?完整命令與避坑整理

Claude Code 如何接 Cloudflare GLM 5.2?完整命令與避坑整理

Cloudflare Workers AI 拿來接 Claude Code 的做法很簡單:Cloudflare 跑模型,LiteLLM 在本機當轉接橋,Claude Code 只需要改 Anthropic 相關環境變數,就能把請求送到本機 proxy。

這篇整理的是一個比較務實的路線。它不是要你把所有模型成本都消失,而是讓你知道免費額度在哪裡、帳單風險在哪裡、命令怎麼下、哪些設定一定要看清楚。

先講結論

Cloudflare Workers AI 有免費額度,官方價格頁寫明 Free plan 每天有 10,000 Neurons,GLM 5.2 目前也在 Cloudflare Workers AI 模型列表裡,可以透過 Cloudflare API 呼叫。這代表你可以把 Claude Code 的模型入口改成本機 LiteLLM proxy,再由 LiteLLM 轉送到 Cloudflare 的 @cf/zai-org/glm-5.2。

但「免費」不是「無限」,Cloudflare 的計費單位是 Neurons,免費額度用完後會受到方案限制,更重要的是,Cloudflare AI Gateway 也能接外部模型,如果你把 OpenAI 或 Anthropic 這類外部模型接進去,那就不再是 Cloudflare Workers AI 的免費模型邏輯,帳單會回到外部供應商那邊。

Claude Code 透過 LiteLLM proxy 接 Cloudflare Workers AI GLM 5.2 的架構圖
Claude Code 只改成本機 Anthropic 入口,真正的模型請求由 LiteLLM 轉到 Cloudflare Workers AI。

這個架構在解什麼問題

Claude Code 很好用,但長時間寫程式、重構、跑測試、修錯時,模型成本會變得很有感。若只是一些低風險任務,例如產生腳手架、改小工具、做簡單 demo、先跑一輪想法,Cloudflare Workers AI 的免費額度可以拿來當低成本緩衝層。

這和 用 Claude Code 搭配 LM Studio 與 Ollama 的思路很像,只是這次不是跑本地模型,而是把免費雲端額度接進本機開發流程。若你的工作流已經在用 Claude Code、Codex 和 skill 組合工作流,這種 proxy 入口會很有彈性。

完整操作命令

下面命令以 macOS 或 Linux 為主。你需要先有 Cloudflare 帳號,並在 Cloudflare dashboard 取得 Account ID 和 API Token。API Token 建議只給 Workers AI 需要的最小權限,不要用過度寬鬆的全域 token。

0. 安裝 Claude Code

npm install -g @anthropic-ai/claude-code

1. 用 curl 單測 GLM 5.2

先確認 Cloudflare 端可以呼叫模型。把 `你的ACCOUNT_ID` 和 `你的API_TOKEN` 換成自己的值。

curl https://api.cloudflare.com/client/v4/accounts/你的ACCOUNT_ID/ai/run/@cf/zai-org/glm-5.2 \
  -H "Authorization: Bearer 你的API_TOKEN" \
  -d '{"messages":[{"role":"user","content":"用一句話介紹你自己"}]}'

2. 安裝 uv

LiteLLM proxy 用 uvx 跑,可以固定 Python 3.12,避開較新 Python 版本造成的編譯問題。

curl -LsSf https://astral.sh/uv/install.sh | sh

3. 驗證 LiteLLM 能跑

uvx --python 3.12 --from 'litellm[proxy]' litellm --version

4. 建立 cf-config.yaml

建立 `cf-config.yaml`。`你的ACCOUNT_ID` 有兩處要換。`cf-glm-5.2` 給 Claude Code 主要模型用,`cf-small` 給較輕量任務用。

model_list:
  - model_name: cf-glm-5.2
    litellm_params:
      model: openai/@cf/zai-org/glm-5.2
      api_base: https://api.cloudflare.com/client/v4/accounts/你的ACCOUNT_ID/ai/v1
      api_key: os.environ/CLOUDFLARE_API_TOKEN
  - model_name: cf-small
    litellm_params:
      model: openai/@cf/meta/llama-3.1-8b-instruct-fp8
      api_base: https://api.cloudflare.com/client/v4/accounts/你的ACCOUNT_ID/ai/v1
      api_key: os.environ/CLOUDFLARE_API_TOKEN

litellm_settings:
  use_chat_completions_url_for_anthropic_messages: true

5. 啟動 LiteLLM 翻譯橋

這個終端視窗要保持開啟。Claude Code 之後會連到 `localhost:4000`。

export CLOUDFLARE_API_TOKEN=你的token
uvx --python 3.12 --from 'litellm[proxy]' litellm --config cf-config.yaml --port 4000

6. 新開視窗測 proxy

curl http://localhost:4000/v1/models -H 'Authorization: Bearer sk-1234'

7. 把 Claude Code 指到本機 proxy

export ANTHROPIC_BASE_URL=http://localhost:4000
export ANTHROPIC_AUTH_TOKEN=sk-1234
export ANTHROPIC_MODEL=cf-glm-5.2
export ANTHROPIC_DEFAULT_HAIKU_MODEL=cf-small

接著啟動 Claude Code,若跳出自訂 API 設定就選是。進入後用 `/status` 確認 Base URL 指向 `localhost:4000`。

claude

8. 把設定寫進 shell profile

如果你確定要長期使用,可以把上面四行 `ANTHROPIC_` export 加到 `~/.zshrc` 或 `~/.bashrc`。我會建議先手動跑幾次確認沒有問題,再寫進 profile。

Windows PowerShell 寫法

PowerShell 不用 `export`,改用 `$env:`。

$env:ANTHROPIC_BASE_URL="http://localhost:4000"
$env:ANTHROPIC_AUTH_TOKEN="sk-1234"
$env:ANTHROPIC_MODEL="cf-glm-5.2"
$env:ANTHROPIC_DEFAULT_HAIKU_MODEL="cf-small"

若要永久保存,放進 PowerShell 的 `$PROFILE`。Windows 跑 AI Agent 時,環境隔離也很重要,可以延伸看 Windows 跑 AI Agent 為什麼要用 WSL

保命提醒:不要把外部模型當免費額度

最容易出事的地方,是把 Cloudflare Workers AI、Cloudflare AI Gateway、OpenAI、Anthropic 混在一起。這篇的低成本前提,是 Cloudflare config 裡的模型走 `@cf/` 開頭,例如 `@cf/zai-org/glm-5.2`。這類模型用的是 Cloudflare Workers AI 額度。

如果你把 Gateway 接到 GPT 或 Claude,那些請求可能會回到 OpenAI 或 Anthropic 的帳單。Cloudflare 只是通道,不代表外部模型突然免費。真正要保命,就是把模型名稱、api_base、API key 來源逐一檢查,並在 Cloudflare 後台看用量。

官方價格頁目前寫得很明確:Free plan 每天 10,000 Neurons,Paid plan 也有每天 10,000 Neurons 免費額度,超出後依 Neurons 計費。免費方案超出額度通常是操作失敗,不是自動無限跑。這點比「無限免費」四個字重要太多。

省額度的三個做法

第一,任務分層。小任務用 `cf-small`,複雜推理再用 `cf-glm-5.2`。第二,讓 Agent 先輸出計畫再執行,避免一次丟太長上下文。第三,把重複流程寫成腳本或 skill,減少模型反覆讀同一批資料。

這也是我一直看好的方向:不要只追求模型本身,而是把模型接到穩定工具鏈。像 Playwright CLI 讓 Codex 操作瀏覽器,或 讓 Agent 自己搜尋和使用 skills,本質上都是把昂貴推理留給真正需要判斷的地方。

我會怎麼用

我不會把這套當成主力模型的完全替代品,而是當成低成本實驗層。適合拿來跑 demo、試 prompt、生成小工具、做簡單 code review、補文件、處理一次性腳本。真正重要的架構決策、複雜除錯、長上下文專案,還是要保留更強模型或本地大模型選項。

如果你已經在用 Codex 和 ChatGPT Work 這類 AI 代理工作流,這套 Cloudflare Workers AI + LiteLLM 的做法可以當成另一個模型入口。它的價值不是讓你省到零,而是讓你有更多成本可控的實驗空間。

延伸資源

FAQ

Cloudflare Workers AI 接 Claude Code 真的免費嗎?

不是無限免費。Cloudflare Workers AI 有每日免費 Neurons 額度,超出後會依方案限制或計費。要把它當成低成本額度,不要當成沒有上限的模型。

為什麼需要 LiteLLM?

LiteLLM 在本機當 proxy,把 Claude Code 發出的 Anthropic 入口請求轉成 Cloudflare Workers AI 可接受的 OpenAI 相容請求。

最容易踩到哪個帳單風險?

最容易把 Cloudflare AI Gateway 接到外部 GPT 或 Claude,卻以為仍在用 Cloudflare 免費 @cf 模型。設定時要確認模型名稱是 `@cf/` 開頭,並檢查 API key 來源。

這套適合取代主力 Claude 嗎?

不建議直接取代。它比較適合低成本實驗、簡單任務、小工具和批次工作。複雜架構、長上下文和高風險任務,仍應保留更強模型。

Orca ADE 是什麼?讓 Codex、Claude Code 多 Agent 並行開發

Orca ADE 是什麼?讓 Codex、Claude Code 多 Agent 並行開發

Orca 是 AI coding agent 的控制台,它把 Codex、Claude Code、OpenCode、Pi 這些 CLI agent 放進同一個開發環境,並且用 Git worktree 把每個任務隔離開來。這對已經開始同時使用多個 AI 編程工具的人很關鍵。

單一 Agent 的時代,問題通常是模型會不會寫,多 Agent 的時代,問題變成誰負責哪個分支、誰改了哪些檔案、怎麼比較成果、怎麼把最好的解法合回主線,Orca 想解的是後面這一段。

先講結論

Orca 是 stablyai 開源的 AI Development Environment,官方用法是把 Codex、Claude Code、OpenCode、Oh My Pi(OMP) 或其他 CLI agent 並排跑起來,每個 Agent 都在自己的 Git worktree 裡工作,最後由使用者比較差異、審查結果,再決定要合併哪一版。

我會把 Orca 看成 OpenWork 這類 OpenCode 工作台 的更完整版本,OpenWork 偏向把本地 Agent 工作桌面化,Orca 則更強調多 Agent orchestration、worktree 隔離、手機 companion、任務恢復和差異審查。

Orca 多 Agent 透過 Git worktree 隔離並行開發的流程圖
Orca 的核心不是多開終端,而是讓每個 Agent 有隔離環境,最後可以比較成果再合併。

Orca 解決的是多 Agent 失控問題

只跑一個 Codex 或 Claude Code 時,管理成本還可以接受,但當你同時讓三個 Agent 嘗試三種解法,麻煩就來了,檔案會互相覆蓋,終端輸出會混在一起,分支會弄亂,最後還要靠人回頭找哪一版比較好。

Orca 的做法是把每個 Agent 放進獨立 worktree。你可以把同一個 prompt 丟給多個 Agent,讓它們各自改一份程式碼,互不干擾。這很適合用在 bug 修復、重構、UI 改版、測試補齊和規格探索。

這和 用 Superpowers 建立 AI 開發紀律 的方向很接近。差別是 Superpowers 偏向規範和方法,Orca 偏向把這些工作流做進工具介面。

支援哪些 Agent

官方 README 的說法很直接:只要是能在 terminal 裡跑的 CLI agent,就可以放進 Orca。目前官方列出的包含 Claude Code、Codex、GitHub Copilot CLI、OpenCode、OpenClaude、OMP、Hermes Agent 等。這表示 Orca 不是綁定單一模型,而是把現有工具收進同一個 cockpit。

AgentOrca 裡的角色適合任務
Codex通用 coding agent改程式、跑測試、整理專案
Claude Code強推理與長任務重構、架構判斷、需求拆解
OpenCode本地或自訂模型入口低成本實驗、本地 agent 工作流
OMP、Hermes 等其他 CLI agent特定工具或特定模型路線

如果你已經在用 Codex 與 ChatGPT Work 的 AI 代理工作流,Orca 的價值會更明顯。它不是要取代 Codex,而是讓 Codex 可以和其他 Agent 同場協作。

Parallel Worktrees 是核心

Orca 最重要的功能是 Parallel Worktrees。你可以把同一個需求發給多個 Agent,讓它們各自在不同 Git worktree 裡完成任務。完成後再比較 diff、測試結果和實作品質。這比在同一個 working tree 裡輪流叫不同 Agent 改檔安全很多。

我會把它想成「平行探索」。不是每個 Agent 都要成功,而是讓不同模型或不同 prompt 策略同時試錯。最後人做判斷,挑一個最好的版本進主線。這比盲信單一 Agent 更符合真實工程工作。

Terminal Splits 和任務恢復

Orca 也把多面板和多終端做進介面。Terminal Splits 讓你可以把多個 Agent、測試、伺服器和 logs 並排放著看。對前端專案、後端 API、資料庫 migration 這類需要同時觀察多個輸出的任務,這會比一直切 tab 順很多。

任務恢復也很重要。AI coding agent 常常不是一次跑完,尤其遇到長時間編譯、測試失敗、rate limit 或你臨時離開電腦。Orca 把任務狀態集中管理,讓你能回到原本的 Agent session,而不是重新猜它剛剛做到哪裡。

手機遠端和語音輸入不是噱頭

Mobile Companion 乍看像附加功能,但對長時間 Agent 任務其實很實用,你可以在手機上看 Agent 是否完成,收到通知後補一句 follow-up,或遠端啟動下一個任務。這讓 AI coding 從坐在電腦前等待,變成可以非同步監看。

語音輸入也類似,很多時候我們不是缺鍵盤,而是缺一個快速把想法丟給 Agent 的入口,若搭配清楚的任務模板,語音輸入可以用來快速交代需求、補充限制或要求重跑測試。

GitHub Issue 和定時審查

Orca 官方也強調 GitHub 和 Linear 的原生整合。你可以在 app 裡看 issue、PR、project board,並從任務直接開 worktree。這讓「看任務 → 啟動 Agent → 產生改動 → review diff」變成一條線,而不是在瀏覽器、終端、IDE、Git UI 之間來回切。

定時審查 repository 是另一個有意思的方向,它適合拿來做每日或每週檢查,例如 dependency 更新、測試覆蓋率、錯誤 logs、未完成 issue、重複程式碼。這類任務不一定需要最強模型,但需要穩定排程和可追蹤結果。

和 Playwright CLI、OpenWork 怎麼搭

Orca 管的是多 Agent 和 worktree。Playwright CLI 管的是瀏覽器自動化。OpenWork 管的是 OpenCode 和本地 Agent 桌面工作台。這些工具其實不是互斥,而是分別解決 AI 開發流程中的不同層級。

我的理想組合會是:Orca 負責多 Agent 任務隔離,Codex 或 Claude Code 負責實作,Playwright CLI 負責跑 UI 驗證,Graphify 或 OpenWiki 負責專案知識。這樣 Agent 就不是聊天框,而是完整開發系統的一部分。

安裝與使用入口

Orca 官方下載入口在 onOrca.dev,支援 macOS、Windows、Linux。Windows 使用者官方 README 也提醒可以抓較新的 RC 版本,因為有 Windows fixes。手機 companion 則提供 iOS App Store、TestFlight 和 Android APK。

  • 桌面版:到 onOrca.dev/download 下載
  • 原始碼:stablyai/orca GitHub
  • 手機 companion:官方 README 提供 iOS、TestFlight 和 Android APK 連結
  • 支援 Agent:Codex、Claude Code、OpenCode、GitHub Copilot CLI、Pi、Hermes Agent 和其他 CLI agent

我的判斷

Orca 的價值,不是讓你同時叫五個 Agent 然後期待奇蹟發生。真正有用的是隔離、比較、恢復、審查和合併,多 Agent 不是數量遊戲,而是工程流程問題。

如果你只是偶爾用 Codex 改一兩個檔案,Orca 可能有點重,但如果你已經常常同時開 Claude Code、Codex、OpenCode,或想把 issue 修復、UI 測試、code review 分配給不同 Agent,Orca 就值得試,它比較像從單兵作戰進入小隊協作。

延伸資源

FAQ

Orca ADE 是什麼?

Orca 是 AI Development Environment,可以把 Codex、Claude Code、OpenCode、Pi 等 CLI agent 放在同一個介面裡並行工作。

Orca 為什麼要用 Git worktree?

Git worktree 可以讓每個 Agent 在獨立工作區修改程式碼,避免互相覆蓋檔案,也方便最後比較 diff 和測試結果。

Orca 適合所有開發者嗎?

如果只是偶爾用一個 Agent 改小檔案,Orca 可能太重。若你常用多個 Agent、需要任務隔離、差異比較、手機遠端和任務恢復,Orca 就很適合。

find-skills 安裝與使用教學:讓 Agent 自己搜尋、發現並推薦 Skills

你可以把 find-skills 想成是 Agent 專用的「Skill App Store」。

當你未來想問:

「有沒有適合做 React 優化的 Skill?」

「有沒有可以幫我寫 changelog 的 Skill?」

「有沒有支援 PR Review、測試、自動化部署的 Skill?」

安裝 find-skills 之後,Agent 就可以根據你的需求,去搜尋相關 Skills,並提供安裝建議。


為什麼第一個要裝 find-skills?

一般人在剛開始使用 Agent Skills 時,最常遇到的問題不是「不會安裝」,而是「不知道有哪些 Skills 可以用」。

以前要找 Skills,可能要靠別人分享、GitHub 搜尋、社群文章,或自己慢慢翻各種資源庫。這種方式有幾個缺點:

  1. 很容易找不到真正適合的 Skill
  2. 搜尋過程會打斷目前工作流程
  3. 不知道哪些 Skill 比較可信
  4. 不知道該用什麼關鍵字搜尋
  5. 找到之後還要自己判斷怎麼安裝

find-skills 解決的就是這個問題。

它讓 Agent 可以根據目前任務,協助你搜尋、比較、推薦甚至安裝其他 Skills。換句話說,安裝它之後,你的 Agent 就不只是被動執行任務,而是能開始主動幫你擴充能力。


find-skills 是什麼?

find-skills 是 Vercel Labs Skills 專案中的一個官方 Skill。

官方頁面說明:
https://github.com/vercel-labs/skills/blob/main/skills/find-skills/SKILL.md

它的主要功能是協助使用者從 open agent skills 生態系中發現與安裝 Skills。當你問 Agent「我要怎麼做某件事?」、「有沒有某種 Skill?」、「能不能幫我找某類工具?」時,find-skills 就可以派上用場。

它適合用在這些情境:

  • 你想找某個特定用途的 Skill
  • 你想知道某個任務是否已經有人做成 Skill
  • 你想擴充 Agent 的能力
  • 你想搜尋工具、範本或工作流程
  • 你想讓 Agent 幫你推薦適合目前任務的 Skill

安裝 find-skills

建議直接使用 Vercel Labs 官方 Skills CLI 安裝。

npx skills add https://github.com/vercel-labs/skills --skill find-skills

這是我建議所有 Agent Skills 使用者第一個安裝的指令。

官方頁面:
https://github.com/vercel-labs/skills/blob/main/skills/find-skills/SKILL.md

下載 / 安裝來源:
https://github.com/vercel-labs/skills

SKILL.md 原始檔下載:
https://raw.githubusercontent.com/vercel-labs/skills/main/skills/find-skills/SKILL.md


關鍵指令整理

安裝完成後,最常用的指令有以下幾個。

1. 搜尋 Skills

npx skills find "find skills"

也可以換成更具體的搜尋字,例如:

npx skills find "react performance"
npx skills find "seo meta"
npx skills find "pr review"
npx skills find "changelog"
npx skills find "wordpress"

搜尋關鍵字越具體,結果通常越準。

例如你要找 SEO 相關 Skills,不建議只搜尋:

npx skills find "seo"

可以改成:

npx skills find "seo meta"
npx skills find "seo tags"
npx skills find "wordpress seo"

這樣比較容易找到符合任務的 Skill。


2. 安裝 Skill

如果你已經知道要安裝哪個 Skill,可以使用:

npx skills add <package>

例如:

npx skills add https://github.com/vercel-labs/skills --skill find-skills

3. 列出已安裝 Skills

npx skills list

這個指令可以查看目前已安裝的 Skills。

不過要注意,如果某些 Skills 不是透過 npx skills add 安裝的,可能不一定會被完整列出。


4. 檢查更新

npx skills check

這個指令可以檢查已安裝的 Skills 是否有更新。


5. 更新 Skills

npx skills update

這個指令會更新已安裝的 Skills。

建議不要盲目更新所有 Skills。更新前最好先確認來源是否可信、更新內容是否合理,尤其是在正式專案或公司環境中使用時,更應該謹慎。


使用 find-skills 的推薦流程

我會建議用這樣的流程:

Step 1:先描述你的需求

不要只丟一個太籠統的詞。

例如不要只說:

npx skills find "design"

可以改成:

npx skills find "ui design system"
npx skills find "accessibility review"
npx skills find "figma to react"

Step 2:查看搜尋結果

搜尋結果出現後,不要只看名稱。

建議至少確認:

  • Skill 名稱
  • 來源作者或組織
  • 安裝數
  • GitHub repo
  • 是否有文件
  • 是否近期仍有人維護
  • 是否符合你的實際任務

Step 3:優先選可信來源

如果是正式專案使用,我會優先選擇這幾類來源:

  • 官方組織
  • 大型開源專案
  • GitHub 星數較高的專案
  • 安裝數較多的 Skill
  • 有清楚文件與範例的 Skill

不要只因為搜尋結果排在前面就直接安裝。


Step 4:安裝後再測試

安裝完成後,建議先用小任務測試。

例如你安裝了 SEO 相關 Skill,可以先讓 Agent 幫你產生一篇文章的:

  • SEO 標題
  • Meta description
  • WordPress 標籤
  • 文章摘要
  • 內部連結建議

確認結果符合預期後,再放進正式工作流程。


find-skills 適合哪些人?

我認為 find-skills 特別適合這幾種使用者。

1. 剛開始使用 Agent Skills 的人

你不需要一開始就知道所有 Skills。先裝 find-skills,讓 Agent 幫你找。


2. 經常做不同任務的開發者

如果你平常會做:

  • React
  • Next.js
  • WordPress
  • Docker
  • GitHub Actions
  • 測試
  • 部署
  • 文件產生
  • Code Review

find-skills 很適合當成你的 Skill 搜尋入口。


3. 想打造個人 Agent 工作流的人

如果你希望 Agent 不只是聊天,而是變成真正的工作助理,Skills 會是很重要的擴充方式。

find-skills 則是幫你管理這個擴充入口的第一個工具。


4. 想建立團隊標準工具集的人

公司或團隊也可以先用 find-skills 找出常用 Skills,再建立自己的標準清單。

例如:

  • 前端開發 Skills
  • 測試 Skills
  • 文件 Skills
  • DevOps Skills
  • SEO Skills
  • WordPress Skills
  • 安全檢查 Skills

這樣可以讓團隊的 Agent 能力更一致。


使用 find-skills 的注意事項

find-skills 很方便,但不是所有搜尋結果都應該直接安裝。

使用時建議注意以下幾點。

1. 不要盲目相信搜尋結果

搜尋到 Skill,只代表它可能相關,不代表它一定適合你的任務。

正式使用前,仍然要確認來源、文件與內容。


2. 安裝前先看來源

尤其是來自不熟悉作者的 Skill,要更謹慎。

如果 Skill 會執行命令、讀寫檔案、存取專案內容,就更應該先檢查內容。


3. 搜尋關鍵字要具體

find-skills 的搜尋品質,很大程度取決於你的關鍵字。

比起搜尋:

npx skills find "seo"

更建議搜尋:

npx skills find "wordpress seo meta"

比起搜尋:

npx skills find "test"

更建議搜尋:

npx skills find "playwright e2e test"

4. 更新 Skills 要小心

npx skills update 雖然方便,但在正式專案中不要隨便全部更新。

建議先檢查:

npx skills check

確認更新內容後,再決定是否更新。


我的建議:find-skills 是 Agent Skills 的第一個必裝工具

如果你只打算先安裝一個 Skill,我會選 find-skills

因為它能讓 Agent 具備「找工具」的能力。

這跟一般單一功能 Skill 不一樣。一般 Skill 是讓 Agent 多一項能力,而 find-skills 是讓 Agent 開始知道「還有哪些能力可以被安裝」。

這也是為什麼我會把它稱為 Agent 的 Skill App Store。

先安裝它,之後要找 SEO、WordPress、React、測試、部署、文件、設計、Code Review 等 Skills,都會更有效率。

用 skill-creator 建立 Skill:Claude Code 自訂技能完整教學

skill-creator 是 Anthropic 官方 skills 專案中的一個 Skill 開發助手,可以協助使用者建立 Claude Code 可使用的自訂 Skill,透過 Skill,你可以把固定工作流程、專業知識、工具使用方式、文件格式與腳本包裝成可重複使用的能力,讓 Claude 在特定任務上更穩定、更一致,也更符合你的實際工作需求。

什麼是 Skill?

在 Claude Code 的使用情境中,Skill 可以理解成「給 AI 使用的操作說明書」。

它不是單純的一段 prompt,而是一個可重複使用的能力包。通常一個 Skill 會包含:

skill-name/
├── SKILL.md        # 核心說明文件,必要
├── scripts/        # 可執行腳本,選用
├── references/     # 參考文件或知識資料,選用
├── assets/         # 圖片、範本、範例檔案等資源,選用

其中最重要的是 SKILL.md
這個檔案會告訴 Claude:

  • 這個 Skill 是做什麼的
  • 什麼情境下應該使用
  • 要遵守哪些流程
  • 輸出格式是什麼
  • 是否需要使用特定工具、腳本或範本

簡單來說,Skill 的目標是讓 Claude 不只是「聽懂一次指令」,而是能長期穩定地執行某一類工作。


skill-creator 是什麼?

skill-creator 是 Anthropic 官方提供的 Skill 建立助手,收錄在官方 skills 專案中。

它的作用是協助你從零開始建立一個 Skill,包含:

  • 釐清 Skill 的用途
  • 設計觸發情境
  • 撰寫 SKILL.md
  • 建立參考文件
  • 設計測試案例
  • 評估 Skill 使用前後的效果
  • 最後打包成 .skill 檔案

如果你只是手動寫 SKILL.md,很容易漏掉使用情境、輸出格式、邊界條件或測試流程。
skill-creator 的價值就在於,它會像一個 Skill 顧問一樣,逐步問你問題,幫你把需求整理成可以實際使用的 Skill。


官方網頁與下載連結

官方 GitHub 專案:
https://github.com/anthropics/skills/tree/main

skill-creator 官方目錄:
https://github.com/anthropics/skills/tree/main/skills/skill-creator

下載 Anthropic skills 專案 ZIP:
https://github.com/anthropics/skills/archive/refs/heads/main.zip


安裝 skill-creator

如果你已經在使用 Claude Code,可以透過以下方式安裝 skill-creator

方法一:使用 npx skills add

npx skills add https://github.com/anthropics/skills --skill skill-creator

方法二:使用 claude install

claude install anthropics/skills/skill-creator

安裝完成後,就可以在 Claude Code 中呼叫:

/skill-creator

接著 Claude 會開始引導你建立 Skill。


用 skill-creator 建立 Skill 的基本流程

使用 skill-creator 建立 Skill,通常可以分成以下幾個階段。

1. 說明你想建立的 Skill

一開始,你可以用自然語言描述需求,例如:

我想建立一個 Skill,用來把會議逐字稿整理成結構化會議紀要。

或是:

我想建立一個 Skill,用來分析 WordPress 網站錯誤訊息,並提供排查步驟。

這時候不需要一次寫得非常完整,因為 skill-creator 會繼續追問細節。


2. 回答 skill-creator 的需求問題

skill-creator 通常會確認幾個重點:

  • 這個 Skill 主要要完成什麼任務?
  • 使用者在什麼情境下會觸發它?
  • 輸入資料可能是文字、檔案、程式碼還是圖片?
  • 輸出格式要用 Markdown、表格、JSON、Word 文件,還是其他格式?
  • 是否有固定流程、固定語氣或固定檢查清單?
  • 是否需要使用特定工具、腳本或外部文件?

這一步非常重要。
如果需求沒有講清楚,後面 Skill 產生的結果就可能不穩定。


3. 自動產生 SKILL.md 草稿

確認需求後,skill-creator 會協助產生 SKILL.md

一個基本的 SKILL.md 會長得像這樣:

---
name: meeting-minutes
description: Convert meeting transcripts into structured meeting minutes with decisions and action items.
---

# Meeting Minutes Skill

Use this skill when the user provides a meeting transcript and wants a structured meeting summary.

## Output Format

Include the following sections:

1. Meeting topic
2. Date and time
3. Participants
4. Key discussion points
5. Decisions
6. Action items with owner and deadline

## Guidelines

- Keep the summary concise.
- Preserve important decisions.
- Do not invent missing attendees or dates.
- If information is missing, mark it as "未提供".

這份 SKILL.md 就是 Claude 之後使用 Skill 時會讀取的核心說明。


4. 加入參考資料與範本

如果你的 Skill 需要固定格式,可以把範本放進 references/assets/

例如:

meeting-minutes/
├── SKILL.md
├── references/
│   └── meeting-template.md
├── assets/
│   └── company-style-guide.pdf

常見的參考資料包括:

  • 公司品牌規範
  • 文件格式範本
  • 常用表格
  • API 使用說明
  • 程式碼規範
  • 工作流程 SOP
  • 檢查清單

這樣 Claude 在執行任務時,不只會依照 prompt 回答,也會參考 Skill 內部的固定資料。


5. 設計測試案例

建立 Skill 後,最好不要馬上投入正式工作,而是先做測試。

你可以準備幾組測試資料,例如:

測試一:正常格式的會議逐字稿
測試二:缺少參與人資訊的會議紀錄
測試三:內容很長、決議很多的會議
測試四:只有零散重點,沒有完整逐字稿

測試的目的不是只看 Claude 有沒有回答,而是要比較:

  • 有使用 Skill 時,結果是否更穩定?
  • 輸出格式是否一致?
  • 是否遵守你指定的規則?
  • 是否能處理邊界情況?
  • 是否有少編造、少漏項?

6. 根據測試結果修改 Skill

第一次產生的 Skill 通常不會完美。

常見需要調整的地方包括:

  • 描述太模糊,導致 Claude 不知道何時使用
  • 輸出格式不夠明確
  • 邊界條件沒有寫清楚
  • 範例太少
  • 沒有說明錯誤情況要怎麼處理
  • 沒有限制 Claude 不要自行補資料

建議你把 Skill 當成一份「可持續最佳化的 SOP」。
每次遇到輸出不符合預期,就回頭修改 SKILL.md


7. 打包成 .skill 檔案

當 Skill 測試穩定後,就可以打包成 .skill 檔案,方便匯入、分享或部署。

打包後的 Skill 就像一個可攜式能力包,可以用在支援 Skill 的 Claude 環境中。


skill-creator 適合用在哪些情境?

skill-creator 很適合用來建立以下類型的 Skill:

文件處理類

例如:

  • 會議紀要整理
  • 合約摘要
  • 報告格式化
  • WordPress 部落格文章產生
  • SEO 文章檢查
  • 論文格式整理

開發工作類

例如:

  • Code Review
  • 安全檢查
  • API 文件產生
  • Git commit message 規範
  • Docker 部署檢查
  • WordPress 錯誤排查

企業流程類

例如:

  • 客服回覆 SOP
  • 品牌語氣檢查
  • 行銷企劃產生
  • 業務提案格式
  • 專案週報整理

個人自動化類

例如:

  • 每週工作回顧
  • 讀書筆記整理
  • 投資研究筆記格式化
  • 學習計畫產生
  • 旅遊規劃模板

建立 Skill 時的實用建議

1. description 要寫清楚

description 不只是說明文字,它會影響 Claude 判斷什麼時候該使用這個 Skill。

不建議這樣寫:

description: 幫我整理資料

建議改成:

description: Use this skill when the user provides meeting transcripts and wants structured meeting minutes with decisions, discussion points, and action items.

越清楚,Claude 越容易正確觸發。


2. 輸出格式要固定

如果你想要表格,就直接指定表格欄位。
如果你想要 Markdown,就明確寫出標題層級。
如果你想要 JSON,就提供完整 schema。

例如:

## Output Format

Return the result in Markdown with the following sections:

# 會議紀要
## 一、會議基本資訊
## 二、討論重點
## 三、決議事項
## 四、待辦事項

3. 明確說明不要編造資料

這一點很重要,尤其是處理會議、合約、財務、法律或客戶資料時。

可以在 Skill 中加入:

## Accuracy Rules

- Do not invent missing information.
- If a field is not provided, write "未提供".
- Preserve names, dates, numbers, and deadlines exactly as given.

4. 加入好範例與壞範例

Skill 裡面可以放 Examples,讓 Claude 更容易理解你要的品質。

例如:

## Examples

Good:
- Clear action item with owner and deadline.
- Concise summary without unnecessary commentary.

Bad:
- Inventing a deadline that was not mentioned.
- Mixing discussion points with final decisions.

常用指令整理

安裝 skill-creator

npx skills add https://github.com/anthropics/skills --skill skill-creator

使用 claude install 安裝

claude install anthropics/skills/skill-creator

呼叫 skill-creator

/skill-creator

從官方 GitHub 下載 skills 專案

git clone https://github.com/anthropics/skills.git

或直接下載 ZIP:

https://github.com/anthropics/skills/archive/refs/heads/main.zip

做好 Skill 後,如何移植到其他系統?

建立好 Skill 之後,不一定只能放在 Claude Code 裡使用。
如果 Skill 的設計夠清楚,也可以移植到其他 Agent 系統,例如 Hermes Agent、Codex,或是你自己架設的本地 AI Agent 平台。

不過要注意一件事:
Skill 的核心不是某一個平台的格式,而是裡面的工作流程、判斷規則、輸出格式、參考資料與可執行腳本。

也就是說,真正有價值的是這些內容:

SKILL.md
references/
scripts/
assets/
examples/

只要把這些內容轉成目標 Agent 系統可以讀懂的格式,就可以完成移植。


Skill 移植的核心概念

一個 Skill 通常可以拆成五個部分:

1. 任務說明:這個 Skill 是做什麼的
2. 觸發條件:什麼情況下應該使用
3. 操作流程:執行任務時要照什麼步驟
4. 輸出格式:最後要產生什麼格式
5. 工具資源:是否需要腳本、範本、參考文件或 API

不同 Agent 系統的格式可能不同,但這五個部分通常都可以保留下來。

因此,移植 Skill 的重點不是「直接複製檔案」,而是把原本的 SKILL.md 改寫成目標系統的規則檔、角色設定、工具說明或 system prompt。


建議的 Skill 通用資料夾結構

為了方便未來移植,建議你在建立 Skill 時,就使用比較通用的結構:

my-skill/
├── SKILL.md
├── README.md
├── references/
│   └── knowledge-base.md
├── examples/
│   ├── input-1.md
│   └── output-1.md
├── scripts/
│   └── helper.py
├── assets/
│   └── template.md
└── manifest.json

其中:

  • SKILL.md:給 Claude 或支援 Skill 的 Agent 使用
  • README.md:給人類維護者閱讀
  • references/:放背景知識、規則、範本
  • examples/:放輸入與輸出範例
  • scripts/:放可執行工具
  • assets/:放模板、圖片、表格等資源
  • manifest.json:給其他 Agent 系統讀取的設定檔

如果你未來要移植到 Hermes Agent 或 Codex,這種結構會比較容易轉換。


範例:建立一個通用 manifest.json

可以在 Skill 裡面額外放一個 manifest.json,用來描述這個 Skill 的基本資訊。

{
  "name": "wordpress-seo-writer",
  "version": "1.0.0",
  "description": "Generate Traditional Chinese WordPress blog posts with SEO title, tags, meta description, and structured article format.",
  "language": "zh-TW",
  "entry": "SKILL.md",
  "references": [
    "references/seo-guidelines.md"
  ],
  "examples": [
    "examples/input-1.md",
    "examples/output-1.md"
  ],
  "tools": [
    {
      "name": "keyword_checker",
      "type": "script",
      "path": "scripts/keyword_checker.py"
    }
  ]
}

這個檔案不一定是 Claude Code 必要的,但它很適合給自建 Agent 系統使用。
例如 Hermes Agent 可以讀取 manifest.json,知道這個 Skill 的名稱、用途、入口檔案、參考資料與可用工具。


移植到 Hermes Agent

如果你使用的是自建的 Hermes Agent,建議把 Skill 當成一個「Agent 能力模組」來管理。

可以設計成以下結構:

hermes-agent/
├── agents/
│   └── writer-agent/
│       ├── system.md
│       ├── tools.json
│       └── skills/
│           └── wordpress-seo-writer/
│               ├── SKILL.md
│               ├── manifest.json
│               ├── references/
│               ├── examples/
│               └── scripts/

Hermes Agent 在執行任務時,可以做三件事:

1. 根據使用者輸入,判斷是否需要啟用某個 Skill
2. 讀取該 Skill 的 SKILL.md 與 references/
3. 將 Skill 內容合併進 Agent 的 system prompt 或 task prompt

例如使用者輸入:

請幫我寫一篇 WordPress SEO 文章,主題是 skill-creator。

Hermes Agent 可以比對 Skill 的 description,找到 wordpress-seo-writer,然後載入:

skills/wordpress-seo-writer/SKILL.md
skills/wordpress-seo-writer/references/seo-guidelines.md
skills/wordpress-seo-writer/examples/output-1.md

接著再讓模型依照這些規則產生文章。


Hermes Agent 的 Skill 載入邏輯範例

如果是自己開發 Hermes Agent,可以用簡單的流程實作:

User Request
     ↓
Intent Router
     ↓
Skill Matcher
     ↓
Load SKILL.md
     ↓
Load references / examples / scripts
     ↓
Compose Agent Prompt
     ↓
Run Model
     ↓
Return Result

也可以設計一個簡單的 Skill Registry:

{
  "skills": [
    {
      "name": "wordpress-seo-writer",
      "description": "Write Traditional Chinese WordPress SEO articles.",
      "path": "./skills/wordpress-seo-writer",
      "trigger_keywords": [
        "WordPress",
        "SEO文章",
        "部落格文章",
        "中繼描述",
        "標籤"
      ]
    },
    {
      "name": "code-review-security",
      "description": "Review code for security, maintainability, and deployment risks.",
      "path": "./skills/code-review-security",
      "trigger_keywords": [
        "code review",
        "安全檢查",
        "漏洞",
        "重構"
      ]
    }
  ]
}

這樣 Hermes Agent 就可以根據關鍵字、語意比對或任務分類,自動決定要不要載入某個 Skill。


移植到 Codex

如果要移植到 Codex,建議分成兩層處理:

1. 專案層級規則:放進 AGENTS.md
2. 任務型 Skill:保留成獨立 Skill 資料夾

Codex 會讀取專案中的 AGENTS.md,因此可以把與專案相關的固定規則放在這裡,例如:

# AGENTS.md

## Project Rules

- Use Traditional Chinese when writing user-facing documentation.
- Do not modify database schema unless explicitly requested.
- Before changing code, inspect the existing architecture.
- Prefer small, reviewable changes.
- When writing WordPress articles, use the wordpress-seo-writer skill.

而真正的 Skill 內容則可以保留在專案目錄中:

project/
├── AGENTS.md
├── skills/
│   └── wordpress-seo-writer/
│       ├── SKILL.md
│       ├── references/
│       ├── examples/
│       └── scripts/

這樣做的好處是:

  • AGENTS.md 負責專案整體規則
  • SKILL.md 負責特定任務流程
  • references/ 保存知識與格式
  • scripts/ 保存可重複使用的工具

Codex 使用 Skill 的建議方式

如果 Skill 是用來處理開發工作,例如 Code Review、安全檢查、部署檢查,建議把 Skill 寫得更像工程 SOP。

例如:

# Code Review Security Skill

Use this skill when reviewing code changes for security, maintainability, and deployment risks.

## Review Checklist

1. Authentication and authorization
2. Input validation
3. SQL injection risk
4. Secrets and environment variables
5. File upload handling
6. Error handling
7. Logging and privacy
8. Deployment risk

## Output Format

Return the review in this format:

# Code Review Report

## Summary
## Critical Issues
## Medium Issues
## Low Risk Suggestions
## Recommended Patch
## Test Plan

然後在 AGENTS.md 裡加入:

## Skills

When the task involves security review, load:

skills/code-review-security/SKILL.md

這樣 Codex 在處理程式碼任務時,就可以依照固定流程執行,而不是每次都靠臨時 prompt。


Claude Skill、Hermes Agent、Codex 的對應關係

Skill 內容Claude CodeHermes AgentCodex
任務說明SKILL.md descriptionmanifest.json descriptionAGENTS.md 或 Skill description
操作流程SKILL.mdsystem prompt / task promptAGENTS.md / Skill
參考資料references/knowledge base / RAGproject docs / references/
腳本工具scripts/tools / function callingscripts / shell tools
輸出格式SKILL.mdresponse schemaAGENTS.md / task instruction
測試案例examples/evaluation settest prompts / eval cases

移植時最容易出問題的地方

1. Skill 觸發條件不清楚

如果 description 寫得太模糊,Agent 不知道什麼時候該使用。

不建議:

幫我處理文章

建議:

當使用者要求撰寫 WordPress SEO 部落格文章,且需要標題、標籤、中繼描述與繁體中文內容時,使用此 Skill。

2. 原本依賴 Claude 的功能,其他系統沒有

有些 Skill 可能假設 Claude Code 可以讀檔、執行 script 或打包 .skill
移植到其他系統時,要確認目標平台是否支援:

  • 讀取本地檔案
  • 執行 shell 指令
  • 呼叫 Python 腳本
  • 使用 MCP server
  • 使用 function calling
  • 存取 Git repo
  • 存取外部 API

如果不支援,就要改成純文字流程,或另外做工具橋接。


3. references 太大,模型上下文放不下

如果參考文件很多,不建議一次全部塞進 prompt。
比較好的方式是:

1. 先用 Skill description 判斷要不要使用
2. 再根據任務讀取必要 references
3. 只載入與當前任務相關的段落

這樣可以避免上下文太長,也能提升回答品質。


4. 腳本路徑與執行環境不同

例如你在 Claude Code 裡用的是:

python scripts/check.py

但移植到 Hermes Agent 的 Docker 環境後,可能要改成:

python /app/skills/wordpress-seo-writer/scripts/check.py

因此建議在 manifest.json 中明確寫出腳本路徑、執行方式與依賴套件。


建議:把 Skill 設計成可攜式能力包

如果你一開始就希望 Skill 可以移植到 Claude Code、Hermes Agent、Codex 或其他 Agent 系統,建議遵守以下原則:

1. SKILL.md 不要寫死特定平台專用語法
2. 把平台相關設定放到 adapters/ 目錄
3. 把核心流程寫在 core.md
4. 把範例輸入輸出放到 examples/
5. 把工具設定放到 manifest.json

可以設計成:

portable-skill/
├── core.md
├── SKILL.md
├── manifest.json
├── adapters/
│   ├── claude-code.md
│   ├── hermes-agent.md
│   └── codex-agents.md
├── references/
├── examples/
└── scripts/

其中:

  • core.md:保存跨平台共用的核心流程
  • SKILL.md:給 Claude Code 使用
  • manifest.json:給自建 Agent 系統使用
  • adapters/claude-code.md:Claude Code 專用說明
  • adapters/hermes-agent.md:Hermes Agent 專用說明
  • adapters/codex-agents.md:Codex 專用說明

這樣同一個 Skill 就不會被綁死在單一平台上。


移植檢查清單

在把 Skill 移到其他 Agent 系統前,可以用這份清單檢查:

□ Skill 的用途是否明確?
□ description 是否能讓 Agent 判斷何時使用?
□ 輸入格式是否定義清楚?
□ 輸出格式是否固定?
□ 是否有 examples?
□ 是否有 references?
□ references 是否可以被目標系統讀取?
□ scripts 是否能在目標環境執行?
□ 是否需要 API key 或環境變數?
□ 是否有測試案例?
□ 是否有平台專用 adapter?
□ 是否避免把敏感資訊寫進 Skill?

Skill 應該被設計成 Agent 的可攜式 SOP

skill-creator 產生的 Skill,最好不要只當成 Claude Code 的專用檔案。
更好的做法,是把它設計成一個「可攜式 AI 工作流程」。

Claude Code 可以使用 SKILL.md
Hermes Agent 可以使用 manifest.jsonreferences/ 與自訂 router。
Codex 可以透過 AGENTS.md、專案規則與 Skill 資料夾來載入任務流程。

只要核心流程設計清楚,Skill 就可以成為跨 Agent 系統共用的能力包,讓同一套工作方法在不同 AI 工具之間延續使用。