Claude Code 配置指南：Rules、Skills、Workflow 如何組合使用？

結論先說：Claude Code 的配置不是「往一個檔案裡堆提示詞」，而是四層分工——CLAUDE.md 放始終需要知道的專案事實，Rules 放硬性約束與路徑作用域慣例，Skills 放可復用的多步流程，Workflow 則把 Skills、Hooks、定時任務和 CI 串成團隊可複製的自動化。搞混層級是最常見的翻車原因：把 40 行部署清單寫進 CLAUDE.md，會話一啟動就吃掉幾千 token；或者把「禁止 force push」這種紅線散在 Skill 裡，壓縮上下文後 Claude 照樣忘。

這篇文章面向正在用或準備上 Claude Code 的 iOS、Flutter 與 AI 應用開發者——尤其那些考慮把主力開發遷到 Cloud Mac、Remote Mac 租賃環境的團隊。我們按 2026 年 8 月官方文件與實測，給出目錄結構、YAML frontmatter 範例、組合決策表，以及和 Apple Silicon 雲 Mac 長期執行相關的注意點。

資料核對日期：2026 年 8 月 5 日。配置行為以 Claude Code Skills 官方文件 與 Anthropic 部落格為準；不同版本 frontmatter 欄位可能略有增減。

為什麼需要分層，而不是一個大 CLAUDE.md

很多團隊的第一反應是：既然 Claude Code 能讀專案檔案，那就把所有約定寫進根目錄的 CLAUDE.md，一勞永逸。問題在於 Claude Code 的上下文預算是共享的——始終載入的內容越多，留給程式碼 diff 和工具輸出的空間越少。更糟的是，程序性內容（「先跑測試、再 bump 版本、再 tag、再 push」）和事實性內容（「主 scheme 叫 MyApp-Prod，憑證在鑰匙圈 Profile XYZ」）混在一起，維護時改一處可能牽動全局。

Anthropic 在 Steering Claude Code 官方部落格 裡把客製手段分成七類：CLAUDE.md、Rules、Skills、Subagents、Hooks、Output Styles、系統提示追加。對多數工程團隊，前四類加 Workflow 編排就夠覆蓋 90% 場景。如果你已經在用 Cursor + Claude Code + OpenRouter 三件套，終端側的配置分層和 IDE 側的 .cursor/rules 可以類比，但目錄與載入時機並不相同，不要直接複製貼上。

我們見過一個典型失敗案例：五人 Flutter 團隊把 Code Review 清單、Archive 步驟、Git 分支策略全部塞進 CLAUDE.md，檔案超過 400 行。結果是 Claude 在改一個 widget 時仍背著整本 runbook，回應變慢，且壓縮上下文後經常「忘記」後半段的測試要求。拆成 path-scoped Rules 和三個 Skills 後，同樣任務平均少消耗約 30% 的輸入 token，Review 遺漏率反而下降。

核心概念：四層各自解決什麼問題

CLAUDE.md：專案的「常駐記憶」

CLAUDE.md（或 .claude/CLAUDE.md）在每次會話啟動時載入，適合放短、穩、全員共識的資訊：

• 一鍵建構與測試命令（如 xcodebuild -scheme MyApp test）
• Monorepo 目錄地圖（apps/ios、packages/core 各負責什麼）
• 當前活躍的 Skills / Rules 索引（一行描述 + 路徑）
• 團隊級禁忌的摘要（細節放 Rules）

官方建議控制在可讀篇幅內；超過 200 行就該警惕是否把流程錯放進來了。CLAUDE.md 不是 wiki，而是 Claude 的「開機自檢單」。

Rules：約束與路徑作用域慣例

Rules 是 .claude/rules/ 下的 Markdown 檔案，給 Claude 特定約束。與 CLAUDE.md 的關鍵差別：

• 可以path-scoped：只有編輯匹配檔案時才載入（例如 paths: ["**/*.swift"]）
• 在上下文壓縮（compaction）後會重新注入，適合安全紅線
• 語氣偏「必須 / 禁止」，而非「建議按以下 12 步操作」

適合寫進 Rules 的內容：禁止提交金鑰、Swift 命名規範摘要、資料庫遷移必須可回滾、Agent 不得執行 git push --force。我們在 Black Hat USA 2026 AI Agent 安全驗收清單 裡強調過：終端 Agent 的權限邊界應寫成可稽核的規則，而不是口頭約定。

Skills：可復用的程序性流程

Skills 位於 ~/.claude/skills/（使用者級）或 .claude/skills/（專案級），每個 Skill 是一個目錄，核心是 SKILL.md。根據 官方 Skills 文件，採用漸進揭露：

• 會話啟動：只載入各 Skill 的 name 與 description
• 呼叫時：才讀入完整正文與捆綁腳本
• 多個 Skill 共享 token 預算，最早呼叫的可能被擠出

適合 Skill 化的任務：TestFlight 發布檢查清單、PR Review 步驟、Flutter 國際化批量替換、OpenAPI 客戶端重新產生。透過 YAML frontmatter 可配置 allowed-tools（預授權工具）、disable-model-invocation: true（僅手動 /skill-name 觸發）、context: fork（在子 Agent 中執行）等。

Workflow：把元件串成團隊節奏

Workflow 不是第五個資料夾，而是編排方式：Hooks 在 git commit 前跑 formatter；定時任務夜間呼叫 /refactor-module Skill；CI 裡用非互動模式跑 Claude Code 做遷移腳本；雲 Mac 上用 launchd 保持會話環境一致。Workflow 回答的是「誰在什麼時機觸發哪一層配置」。

組合對照：什麼放哪一層

實操：從零搭一套 iOS 團隊配置

以下目錄結構在 2～6 人 iOS / Flutter 混合倉庫實測可用，可按團隊裁剪：

your-repo/
├── CLAUDE.md                    # 建構命令、scheme 列表、技能索引
├── .claude/
│   ├── settings.json            # 團隊共享設定（勿放金鑰）
│   ├── settings.local.json      # 本機覆寫，gitignore
│   ├── rules/
│   │   ├── global-security.md   # 禁止讀 .env、禁止 force push
│   │   ├── ios-swift.md         # paths: ["**/*.swift"]
│   │   └── flutter-dart.md      # paths: ["lib/**/*.dart"]
│   └── skills/
│       ├── release-testflight/
│       │   └── SKILL.md
│       └── pr-review/
│           └── SKILL.md

第一步：寫 CLAUDE.md（控制在 80～120 行）。 開頭用表格列出 scheme、最低系統版本、測試入口；中間放目錄說明；末尾用 bullet 列出可用 Skills（名稱 + 一句話）。不要在這裡寫逐步操作。

第二步：拆 Rules。 全局安全規則單獨檔案；語言規範按路徑拆分。path-scoped 範例 frontmatter：

---
paths:
  - "**/*.swift"
  - "**/*.xcodeproj/**"
---

# iOS / Swift 約束
- 新增 UI 必須附帶 Preview 或說明為何省略
- 不得修改 Signing & Capabilities 中的 Team ID
- 網路層改動必須更新對應單元測試

第三步：建第一個 Skill。 從最高頻、最易出錯的流程開始——多數 iOS 團隊是 TestFlight 發布或 PR Review：

---
name: release-testflight
description: "Archive 主 scheme 並上傳 TestFlight；在發版日或使用者說「發版」時使用"
disable-model-invocation: true
allowed-tools: Bash(xcodebuild *) Bash(fastlane *)
---

## 發版前檢查
1. 確認 `main` 已合併且 CI 綠燈
2. 讀取 `CHANGELOG` 最新條目與版本號一致
3. 執行 `xcodebuild -scheme MyApp -destination 'generic/platform=iOS' archive`
4. 呼叫 fastlane `upload_testflight` lane
5. 在 PR 留言 build 號與處理組

disable-model-invocation: true 表示只有開發者手動輸入 /release-testflight 才會載入，避免 Claude 在改 UI 時誤觸發發版。敏感操作務必加這一行。

第四步：接 Workflow。 在 .claude/settings.json 裡配置 Hooks（如 PreToolUse 攔截危險命令），在雲 Mac 或本機用同一套 .claude 目錄——這樣 Remote Mac 上 SSH 進去的行為與本地一致。團隊共享配置走 Git；個人 API Key 與 settings.local.json 走 gitignore。

與 Cloud Mac / Apple Silicon 的關聯場景

Claude Code 本質是終端 Agent，執行環境的品質直接決定你敢不敢放手讓它跑。在 VPSSpark 這類 Cloud Mac / Remote Mac 租賃場景中，配置分層帶來三個實際好處：

• 環境可固化：把 .claude/、Homebrew 依賴、Ruby fastlane 版本打進映像，換節點不用重配 Skills。
• 長會話更穩：Apple Silicon M4 統一記憶體適合同時開 Xcode、模擬器與 Claude Code；待機約 4W，適合夜間掛 /refactor 類 Skill。
• 權限隔離：雲 Mac 上單獨系統使用者跑 Agent，Rules 裡限制讀鑰匙圈路徑，比在個人主力機上裸跑更安全。

典型 Workflow：開發者在本地 Cursor 改程式碼 → push 到 Git → 雲 Mac CI 拉取後用非互動 Claude Code 跑遷移 Skill → fastlane 上傳。Rules 保證 CI 環境不會執行 force push；Skills 保證步驟與人工發版一致。Flutter 團隊可把 flutter build ipa 與 iOS 簽章步驟同樣 Skill 化，共享同一套安全 Rules。

若你使用 OpenRouter 等路由降低 API 成本，Skills 的 allowed-tools 與模型選擇無關，但 Workflow 裡應監控：子 Agent（context: fork）並發時的記憶體峰值——M4 16GB 節點同時跑兩個 fork Skill + Xcode Archive 可能觸頂，建議在 Rules 或 Skill 裡註明「Archive 時禁止並行第二個 fork Skill」。

成本、效能與風險對比

Token 成本： 臃腫 CLAUDE.md 每次會話多付「背景稅」；Skills 漸進揭露能省，但一次會話連續呼叫多個 Skill 會爭搶共享預算。定期用 /context 或官方 token 統計查看哪層占大頭。

維護成本： Rules 與 Skills 可 code review、可版本化，比口頭約定便宜；但超過 15 個 Skill 需要專人做索引與退役，否則新人找不到該用哪個。

風險： allowed-tools 預授權會在 Skill 啟動的當輪降低確認門檻——只應對可信 Skill 開啟。雲 Mac 共享節點務必用 settings.local.json 隔離個人金鑰。Hooks 誤配可能導致無法 commit，先在分支上試跑。

與「什麼都不配置、每次口頭交代」相比，初期多花 2～4 小時搭分層，通常在第三週就能從減少的重複解釋和失敗重試上回本。與「全部堆進 CLAUDE.md」相比，分層配置的長期 token 帳單和遺漏率都更可控。

FAQ

Claude Code 的 Rules 和 Cursor Rules 能共用嗎？

概念類似，但路徑與格式不同。Cursor 用 .cursor/rules，Claude Code 用 .claude/rules/。可以維護同一份 Markdown 源檔案，用腳本同步到兩處，但不要指望自動互通。

Skill 可以呼叫外部腳本嗎？

可以。Skill 目錄下可放 scripts/，正文中指示 Claude 執行；配合 allowed-tools: Bash(./scripts/*) 減少反覆確認。腳本本身應 code review，避免 Agent 執行未稽核的 shell。

團隊如何審核新增 Rule 或 Skill？

建議與程式碼同 PR：新增 .claude/rules/foo.md 或 skills/bar/SKILL.md 須有人類 reviewer 簽核，檢查是否與安全 Rules 衝突、是否重複 CLAUDE.md 已有內容。可參考 Claude Code Settings 文件 中的 skillOverrides 做臨時停用而不刪檔案。

壓縮上下文後 Claude 忘了 Skill 裡的步驟怎麼辦？

長會話中較早呼叫的 Skill 可能被擠出共享預算。對策：關鍵步驟拆成 Hook（確定性）；或在 Skill 末尾要求 Claude 輸出檢查清單到檔案；發版類 Skill 保持 disable-model-invocation: true 由人觸發，縮短會話長度。

只有我一個人開發，值得搭這套嗎？

值得，但極簡即可：一份 50 行 CLAUDE.md、兩條 Rules（安全 + 語言）、一個你最常做的 Skill（如 /ship）。一人團隊的優勢是迭代快——每週花 15 分鐘整理，比每次重新打字交代 build 命令划算。

總結：先畫工作流，再寫設定檔

Claude Code 的 Rules、Skills、Workflow 組合，本質是「把人的經驗拆成機器可載入的模組」。CLAUDE.md 回答「這是什麼專案」，Rules 回答「絕不能做什麼」，Skills 回答「複雜事按什麼步驟做」，Workflow 回答「什麼時候自動做」。搞清四層再動手，比一上來寫五百行提示詞省心得多。

落地順序建議：本週寫好 CLAUDE.md 骨架 → 下週加兩條安全 Rules → 再做一個最高頻 Skill → 最後在雲 Mac 或 CI 上接 Hook。每加一層都在真實任務裡試一輪，看 token 與遺漏率是否改善。