【完整攻略】Claude Code 全方位協作指南 — 從 settings.json 配置到 AI 開發戰友的 17 個核心能力

每次使用 Claude Code 都要按 Allow?Hooks 到底能幹嘛?MCP 伺服器怎麼接?作為一個每天與 Claude Code 協作超過 8 小時的架構師,我將從實戰角度帶你走過 settings.json 的每一個關鍵配置,讓你從「不斷按確認」進化到「全自動化 AI 開發流水線」。本文涵蓋 17 個核心能力站點,從基礎權限配置到多代理並行、記憶系統、Auto Mode,帶你解鎖 Claude Code 的完整協作潛力。


🎯 為什麼你需要認真配置 settings.json?

Claude Code 的預設模式是「安全優先」——每個檔案操作、每條指令都要你點 Allow。這對初學者來說是好事,但對於每天寫上千行程式碼的開發者來說,這就像開車時每踩一次油門都要確認一次「你確定要加速嗎?」

settings.json 是 Claude Code 的控制中樞。配置得當,它能讓你的 AI 協作體驗從「手動擋」升級到「自動巡航」。

設定檔的三層架構

Claude Code 的設定採用三層覆蓋架構,就像 CSS 的層疊規則:

層級 檔案位置 Git 追蹤 適用場景
全域(User) ~/.claude/settings.json N/A 個人偏好,所有專案通用
專案(Project) .claude/settings.json ✅ 提交 團隊共用的規範和 Hooks
本地(Local) .claude/settings.local.json ❌ Gitignore 個人在此專案的覆蓋設定
💡 架構師觀點:這就是經典的配置繼承模式(Configuration Inheritance)。後層覆蓋前層,讓你在保持團隊一致性的同時擁有個人彈性。

⚡ 第一站:跳過權限提示(Permissions)

痛點

你正在讓 Claude Code 重構一個模組,它需要讀 50 個檔案、改 20 個檔案、跑 10 次測試。每一步都跳出 Allow 提示——你按了 80 次確認鍵。這不是 AI 協作,這是打地鼠。

解法:精細化權限控制

{
  "permissions": {
    "allow": [
      "Bash(git:*)",
      "Bash(mvn:*)",
      "Bash(npm:*)",
      "Bash(node:*)",
      "Bash(python:*)",
      "Bash(java:*)",
      "Bash(ls:*)",
      "Bash(mkdir:*)",
      "Bash(curl:*)",
      "Bash(gh:*)",
      "Read",
      "Edit",
      "Write",
      "Glob",
      "Grep",
      "WebFetch",
      "WebSearch",
      "TodoWrite",
      "NotebookEdit"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(DROP:*)",
      "Bash(format:*)"
    ]
  }
}

權限規則語法解析

  • 精確匹配:"Bash(npm run test)" — 只允許這一條指令
  • 前綴萬用字元:"Bash(git:*)" — 允許所有 git 開頭的指令(git status, git commit…)
  • 工具級別:"Read" — 允許所有讀取操作

三種權限模式

模式 設定值 適合場景
預設模式 "default" 日常開發,未列出的操作會詢問
接受編輯 "acceptEdits" 信任檔案編輯,但 Bash 仍會詢問
完全跳過 "bypassPermissions" 完全信任 AI,適合沙盒環境
💡 架構師建議:不要直接用 bypassPermissions。就像你不會給生產伺服器開 chmod 777,用 allow 清單做最小權限原則(Least Privilege)更安全。把你信任的操作明確列出,危險操作放進 deny

🔧 第二站:Hooks — 你的自動化管家

什麼是 Hooks?

Hooks 是 Claude Code 的事件驅動自動化機制。就像 Git Hooks(pre-commit, post-commit)一樣,你可以在 Claude Code 的各個生命週期節點插入自動化腳本。

核心事件一覽

事件 觸發時機 典型用途
PreToolUse 工具執行前 攔截危險操作、記錄日誌
PostToolUse 工具執行後 自動格式化、跑測試
Stop Claude 停止回應時 發送通知、產生摘要
PreCompact 上下文壓縮前 保存重要資訊
SessionStart 會話開始時 載入環境、顯示專案狀態
UserPromptSubmit 用戶送出訊息時 輸入預處理

實戰範例一:完成工作時彈出通知

這是我每天都在用的配置。Claude Code 完成一段工作後,Windows 會彈出通知視窗:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "powershell -Command \"[System.Reflection.Assembly]::LoadWithPartialName('System.Windows.Forms') | Out-Null; [System.Windows.Forms.MessageBox]::Show('Claude Code 已完成!', 'Claude Code 通知', 'OK', 'Information')\"",
            "timeout": 10,
            "statusMessage": "發送通知中..."
          }
        ]
      }
    ]
  }
}
📌 使用場景:你丟一個大任務給 Claude Code(例如重構整個模組),然後去泡咖啡。做完了它會彈窗通知你回來 review。

實戰範例二:寫完程式碼自動格式化

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_response.filePath // .tool_input.file_path' | { read -r f; prettier --write \"$f\"; } 2>/dev/null || true"
          }
        ]
      }
    ]
  }
}

每次 Claude Code 編輯或寫入檔案後,自動用 Prettier 格式化。再也不用擔心 AI 產出的程式碼風格不一致。

實戰範例三:記錄所有 Bash 指令

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.command' >> ~/.claude/bash-log.txt"
          }
        ]
      }
    ]
  }
}
💡 架構師觀點:這就是審計日誌(Audit Log)模式。當你讓 AI 自主執行指令時,保留完整的操作記錄至關重要。出了問題可以追溯,也能用來分析 AI 的行為模式。

進階:三種 Hook 類型

類型 說明 適用場景
command 執行 shell 指令 格式化、測試、通知
prompt 用 LLM 評估條件 語義級別的安全檢查
agent 啟動代理執行任務 複雜的自動化驗證
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "prompt",
            "prompt": "這個指令是否可能刪除重要檔案或造成不可逆的破壞?指令內容:$ARGUMENTS"
          }
        ]
      }
    ]
  }
}

用 AI 來審查 AI——這是多層防禦(Defense in Depth)的完美體現。


🌐 第三站:MCP 伺服器 — 擴展 Claude Code 的邊界

什麼是 MCP?

MCP(Model Context Protocol)是讓 Claude Code 連接外部服務的標準協議。透過 MCP,Claude Code 可以直接操作資料庫、呼叫 API、查詢股票行情——任何你能想到的整合。

實戰範例:接入台灣股票行情

{
  "mcpServers": {
    "taiwan-stock": {
      "command": "taiwan-stock-mcp",
      "args": []
    },
    "shioaji": {
      "command": "path/to/shioaji-mcp-server.exe",
      "args": [],
      "env": {
        "SHIOAJI_API_KEY": "your-api-key",
        "SHIOAJI_SECRET_KEY": "your-secret-key"
      }
    }
  }
}

配置完成後,你可以直接對 Claude Code 說:「查詢台積電今天的股價」或「分析我永豐金帳戶的未實現損益」。

MCP 的架構意義

從架構角度來看,MCP 本質上就是微服務的 Sidecar 模式。每個 MCP 伺服器就是一個獨立的服務,透過標準化協議與 Claude Code 通訊。這種設計的優點:

  • 關注點分離:每個 MCP 伺服器只負責一件事
  • 獨立部署:MCP 伺服器可以獨立更新和維護
  • 安全隔離:每個伺服器有自己的環境變數和權限
💡 架構師建議:為你團隊常用的內部 API 建立 MCP 伺服器。例如:公司的 JIRA API、內部知識庫、部署管線——讓 Claude Code 成為你的統一操作介面

🔐 第四站:Sandbox — 安全的沙盒環境

為什麼需要沙盒?

當你給 AI 越來越多的自主權時,安全邊界就越重要。Sandbox 配置讓你精確控制 Claude Code 可以存取的檔案系統範圍和網路資源。

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "network": {
      "allowedDomains": [ "github.com", "registry.npmjs.org", "pypi.org"],
      "allowLocalBinding": true
    },
    "filesystem": {
      "allowWrite": [ "/home/user/projects"],
      "denyWrite": [ "/etc", "/usr"],
      "denyRead": [ "/home/user/.ssh", "/home/user/.aws"]
    }
  }
}
💡 架構師觀點:這就是容器化思維的延伸。就像 Docker 的 --read-only--network 旗標,Sandbox 讓你在給 AI 自由的同時保持控制。特別注意 denyRead——防止 AI 讀取你的 SSH 金鑰和雲端憑證。

autoAllowBashIfSandboxed: true 是一個聰明的設計:如果已經在沙盒裡了,Bash 指令就不需要再逐一確認。安全邊界前移,讓操作體驗更流暢。


🌳 第五站:Git Worktree — 隔離的開發環境

痛點

你讓 Claude Code 做一個大型重構,但你同時需要在主分支上修一個緊急 bug。兩件事在同一個目錄下互相干擾。

解法:Worktree 配置

{
  "worktree": {
    "symlinkDirectories": [ "node_modules", ".cache", ".bin"],
    "sparsePaths": [ "src/", "tests/", "package.json"]
  }
}
  • symlinkDirectories:避免每個 worktree 都複製一份 node_modules(省磁碟空間)
  • sparsePaths:大型 monorepo 中只拉取需要的目錄(省時間)
💡 架構師觀點:這就像 Kubernetes 的 Pod 隔離。每個 worktree 是一個獨立的工作空間,有自己的分支和檔案狀態,但共享底層的 Git 物件庫。對於多代理並行開發的場景,worktree 是基礎設施級的支援。

🔌 第六站:環境變數與模型選擇

環境變數

{
  "env": {
    "NODE_ENV": "development",
    "DEBUG": "true",
    "DATABASE_URL": "postgresql://localhost:5432/dev"
  }
}

這些環境變數會注入到 Claude Code 的執行環境中,就像 Docker 的 -e 旗標。適合設定開發環境的連線資訊、除錯旗標等。

模型選擇與效能調校

{
  "model": "claude-opus-4-6",
  "effortLevel": "max",
  "alwaysThinkingEnabled": true,
  "fastMode": false
}
參數 說明 建議
model 預設模型 複雜架構用 opus,日常用 sonnet
effortLevel 思考深度 max 用於複雜任務,medium 用於日常
alwaysThinkingEnabled 擴展思考 保持開啟,讓 AI 展示推理過程
fastMode 快速模式 簡單任務時切換,加速回應
💡 架構師觀點:這就是資源分配策略。不是每個任務都需要最強的模型和最大的思考深度。就像你不會用 GPU 叢集來跑 Hello World,學會根據任務複雜度選擇合適的配置,能顯著降低成本並提升效率。

📡 第七站:SSH 遠端開發

{
  "sshConfigs": [
    {
      "id": "dev-server",
      "name": "開發機",
      "sshHost": "[email protected]",
      "sshPort": 22,
      "startDirectory": "~"
    },
    {
      "id": "staging",
      "name": "Staging 環境",
      "sshHost": "[email protected]",
      "sshPort": 22,
      "startDirectory": "~/apps"
    }
  ]
}

配置完成後,用 claude ssh dev-server 就能直接在遠端機器上啟動 Claude Code 工作。適合需要在 Linux 伺服器上開發、或存取特定硬體資源的場景。


🧩 第八站:Plugins — 技能擴展系統

{
  "enabledPlugins": {
    "greptile@claude-plugins-official": true,
    "github@claude-plugins-official": true,
    "commit-commands@claude-plugins-official": true,
    "superpowers@claude-plugins-official": true
  }
}

Plugins 賦予 Claude Code 額外的技能(Skills)。例如:

  • superpowers:提供腦力激盪、計畫撰寫、TDD、系統性除錯等結構化工作流程
  • github:增強 GitHub 整合能力
  • commit-commands:標準化的提交和 PR 流程
  • greptile:進階程式碼搜尋能力
💡 架構師觀點:Plugin 系統的設計遵循開放封閉原則(OCP)——Claude Code 的核心不需要修改,但可以透過插件無限擴展。這也是為什麼你可以建立自己的 Plugin Marketplace 來分享團隊專屬的技能。

🏗️ 完整配置範本:架構師的 settings.json

以下是一份經過實戰驗證的完整配置範本,你可以根據自己的需求調整:

{
  "permissions": {
    "allow": [
      "Bash(git:*)",
      "Bash(mvn:*)",
      "Bash(npm:*)",
      "Bash(node:*)",
      "Bash(python:*)",
      "Bash(java:*)",
      "Bash(ls:*)",
      "Bash(mkdir:*)",
      "Bash(curl:*)",
      "Bash(gh:*)",
      "Read", "Edit", "Write",
      "Glob", "Grep",
      "WebFetch", "WebSearch",
      "TodoWrite", "NotebookEdit"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(DROP:*)"
    ]
  },
  "model": "claude-opus-4-6",
  "effortLevel": "max",
  "alwaysThinkingEnabled": true,
  "hooks": {
    "Stop": [
      {
        "hooks": [{
          "type": "command",
          "command": "echo Done",
          "timeout": 10,
          "statusMessage": "通知中..."
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [{
          "type": "command",
          "command": "jq -r '.tool_response.filePath // .tool_input.file_path' | { read -r f; prettier --write \"$f\"; } 2>/dev/null || true"
        }]
      }
    ]
  },
  "env": {
    "NODE_ENV": "development"
  },
  "worktree": {
    "symlinkDirectories": [ "node_modules"]
  }
}

📋 第九站:CLAUDE.md — 你的專案操作手冊

為什麼需要 CLAUDE.md?

settings.json 控制的是 Claude Code 的行為規則,而 CLAUDE.md 定義的是專案上下文。就像你不會讓新進員工第一天就開始寫程式碼一樣——他需要先了解專案的架構、規範、禁忌和慣例。

CLAUDE.md 放在專案根目錄,Claude Code 每次啟動時會自動讀取,相當於給 AI 一份「新人入職手冊」

實戰範本

# 專案:電商平台後端

## 技術棧
- Java 17 + Spring Boot 3.2
- PostgreSQL 15 + Redis 7
- Maven 建構,模組化架構

## 程式碼規範
- 所有 Controller 方法必須有 @Operation 註解(Swagger)
- Service 層必須有單元測試,覆蓋率 > 80%
- 使用 Lombok @Slf4j,禁止直接 System.out.println

## 禁止事項
- 不要修改 core-common 模組的公開 API
- 不要直接操作生產資料庫連線字串
- 不要刪除任何已存在的測試案例

## 建構與測試
- 建構:mvn clean package -DskipTests
- 測試:mvn test
- 單一模組測試:mvn test -pl module-name

## 分支策略
- feature/* 從 develop 分出
- 每個 PR 需要至少一個 review
💡 架構師觀點:CLAUDE.md 的三層載入機制(~/.claude/CLAUDE.md → 專案根目錄 → 子目錄)就是配置繼承的延伸。你可以在全域設定通用規範,在專案層級設定特定規則,在子目錄中覆蓋模組級別的約定。

🗺️ 第十站:Plan Mode — 先謀後動

什麼時候用 Plan Mode?

當任務複雜到「先想清楚再動手」比「邊做邊改」更高效時,就該用 Plan Mode。典型場景:

  • 跨模組重構
  • 新功能設計(涉及多個服務)
  • 技術遷移(例如從 REST 遷移到 GraphQL)

實戰操作

# 進入計畫模式
# 在聊天中輸入 /plan 或按 Shift+Tab 切換

# 給出需求
「我需要為現有的訂單系統加入退款功能。
退款需要:
1. 支援全額和部分退款
2. 整合現有的支付閘道(綠界、LINE Pay)
3. 退款狀態需要即時通知用戶
4. 需要防止重複退款的並發控制」

# Claude Code 會產出:
# → 影響範圍分析
# → 架構設計建議
# → 分步實施計畫
# → 每步的驗證標準
💡 架構師觀點:Plan Mode 本質上就是技術設計審查(Design Review)的自動化。它強迫你和 AI 在動手之前達成共識——修改哪些檔案、用什麼模式、怎麼測試。這比「直接開幹然後改三輪」高效得多。

🤖 第十一站:多代理並行 — 分身術

核心概念

Claude Code 可以同時啟動多個子代理(Subagent),每個代理有獨立的上下文,互不干擾。這就像你有一個開發團隊,每人負責不同的任務,最後彙整結果。

實戰場景

場景一:並行研究

# 你問:「比較 Kafka 和 RabbitMQ 在我們這個場景下的優劣」
# Claude Code 同時啟動:
# → Agent 1:分析你的程式碼找出訊息傳遞模式
# → Agent 2:研究 Kafka 的適用性
# → Agent 3:研究 RabbitMQ 的適用性
# 三個代理並行執行,最後彙整成完整比較報告

場景二:實作 + 測試並行

# 你說:「實作用戶通知系統並寫測試」
# Claude Code 可以:
# → Agent 1:在 worktree 中實作核心邏輯
# → Agent 2:同時撰寫測試案例
# → 主代理:協調兩者,確保介面一致

場景三:Code Review 代理

# 完成一段實作後
# → 自動啟動 Code Review 代理
# → 從安全性、效能、可維護性三個角度審查
# → 產出具體的修改建議
💡 架構師觀點:多代理系統就是分散式運算的縮影。關鍵是任務分解(Task Decomposition)——把大任務拆成可並行的子任務。能並行的就並行,有依賴的就串行。這和你設計微服務時的思考方式完全一致。

🧠 第十二站:Memory 記憶系統 — 跨對話的知識累積

為什麼需要記憶?

每次開新對話,Claude Code 都是「失憶」狀態。Memory 系統解決了這個問題——它讓 AI 記住你的偏好、專案狀態、過去的決策。

四種記憶類型

類型 用途 範例
user 你的角色和偏好 「用戶是資深 Java 架構師,偏好函數式風格」
feedback 你給過的修正指導 「不要在測試中 mock 資料庫,要用 Testcontainers」
project 專案的狀態和決策 「3月底前需要完成支付模組重構」
reference 外部資源的指引 「Bug 追蹤在 Linear 的 BACKEND 專案中」

實戰操作

# 主動要求記住
「記住:這個專案的 API 回應格式統一用 ApiResponse 包裝,
不要直接回傳原始物件」

# Claude Code 會自動儲存為 feedback 類型的記憶
# 下次對話中,它會自動遵守這個規則

# 記住偏好
「記住:我喜歡用 Stream API 而不是 for 迴圈處理集合」

# 記住專案決策
「記住:我們決定用 Event Sourcing 模式重構訂單模組,
預計 Q2 完成」
💡 架構師觀點:Memory 系統就是 AI 的組織知識庫(Knowledge Base)。它解決了「每次都要重複解釋上下文」的問題。越用越聰明,因為它逐漸累積了你的技術偏好、專案脈絡、和過去的決策紀錄。

💬 第十三站:與 AI 溝通的真相 — 別演了,說人話

先打破一個幻覺

很多教學會告訴你:「給 AI 一個角色,例如『你是資深 Java 架構師』,回答會更專業。」

這是半個事實。

給角色確實會讓 AI 的回答看起來更專業——更多術語、更自信的語氣、更「完整」的方案。但研究和實際使用經驗都指出:角色設定會讓 AI 的正確率下降。

為什麼?因為「資深架構師」不會說「我不確定」。所以 AI 會:

  • 硬掰——不確定的事情也斬釘截鐵地說
  • 過度複雜化——簡單問題也要套三層設計模式,顯得「夠資深」
  • 自信地錯——沒角色時會說「可能是 A 或 B」,有角色後直接斷言「就是 A」

你得到的不是更好的答案,而是更有自信的答案。這兩件事差很遠。


「但我不知道該給什麼約束啊」

有人說:「那不要給角色,改給具體約束。」例如把「你是安全專家」改成「用 OWASP Top 10 標準審查程式碼」。

聽起來很合理,但這有一個致命的前提假設:你得知道 OWASP Top 10 是什麼。

現實是——如果你已經知道該用什麼約束,你大概也不太需要 AI 了。你使用 AI 的原因之一,正是因為你的知識有邊界。要你在邊界之外給出精確約束,這本身就是矛盾的。

這是一個雞生蛋的問題:

  • 要給好的約束 → 需要知道有哪些考量面向
  • 要知道有哪些考量面向 → 需要相關經驗
  • 如果你有相關經驗 → 你可能不需要問 AI

真正有效的溝通方式

解法一:讓 AI 來問你,而不是你來指揮 AI

❌「你是資深架構師,幫我設計退款系統」
❌「幫我設計退款系統,約束是 A、B、C」(你怎麼知道該約束什麼?)
✅「我需要退款功能。問我你需要知道的事情。」

AI 會反問你:支援哪些支付方式?要不要部分退款?退款時效?併發量多少?——這些約束由 AI 來挖掘,你只需要回答業務事實。你是最了解你的業務的人,AI 是最了解技術選項的那個。各司其職。

解法二:說痛點,不說方法

❌「用 Strategy Pattern 重構支付模組」
✅「支付模組每次加新支付方式都要改 5 個檔案,太痛苦了」

❌「幫我實作 Cache-Aside Pattern」
✅「這個 API 太慢了,每次都要查資料庫,有 500ms 延遲」

❌「用 Event Sourcing 重構訂單模組」
✅「訂單狀態變更的歷史記錄查不到,客服常常追不到問題」

你描述痛點,AI 來決定用什麼方法。你不需要知道 Strategy Pattern 這個詞——那是 AI 的工作。

解法三:給 AI 看失敗的例子

✅「上次你改完之後測試壞了三個,這次注意一下」
✅「你之前把 API 回傳格式改掉了,不要再這樣」
✅「上一版你漏掉了併發情境,這次要考慮進去」

這比任何「資深」角色都有效。你在用真實的失敗經驗告訴 AI 邊界在哪裡。


最危險的時刻:「看起來差不多了」

這是人機協作中最容易出事的瞬間

AI 給你一個方案,看起來完整、專業、邏輯通順。你看了看,覺得「嗯,差不多了」,然後就 GO 了。

問題是——你覺得差不多了,不是因為真的差不多了,而是因為 AI 的輸出「看起來」差不多了。

AI 不會主動告訴你它跳過了什麼。它不會說「欸,我其實沒考慮併發情境」或「這個方案在資料量大的時候會爆掉」。它產出的東西永遠看起來是完整的——因為它被訓練成產出看起來完整的回答。

煞車技巧:一句話打破 AI 的演出模式

你不需要學任何新技巧。只需要在覺得「差不多了」的時候,多問一句:

「你跳過了什麼?」

或是這些變體:

  • 「你在這個方案裡做了哪些假設?」
  • 「這個方案最可能在哪裡出事?」
  • 「你有沒有什麼想問我但沒問的?」
  • 「如果這個方案失敗了,最可能的原因是什麼?」
  • 「你對這個方案有多少信心?哪部分最不確定?」

這一句話的威力在於:你不是在問「做得好不好」,而是在問「藏了什麼」。它逼 AI 從「展示模式」切換到「誠實模式」。


而且這件事不該只是你的責任

理想的 AI 協作應該是雙向的。AI 在給出方案後,應該主動說

「這個方案我假設了 X、Y、Z。
我沒有處理的是 A 和 B。
你需要確認的是 C。
我最不確定的部分是 D。」

如果你的 AI 不會主動這樣做,你可以在 CLAUDE.md 中加入這個規則:

# AI 行為規範
- 每次提出方案後,必須列出:
  1. 你做了哪些假設
  2. 你沒有處理的邊界情境
  3. 你最不確定的部分
  4. 你建議我額外確認的事項
- 不確定的事情要說不確定,不要硬掰
- 寧可多問一個問題,也不要做錯一個假設

把這段放進 CLAUDE.md,AI 的行為會顯著改變。這不是「角色扮演」,而是行為契約


常見的協作陷阱與對策

陷阱 表現 對策
自信陷阱 AI 語氣非常肯定,但內容其實有誤 問「你有多少信心?」、「有沒有其他可能?」
完整性幻覺 方案看起來很完整,但跳過了關鍵場景 問「你跳過了什麼?」、「最可能在哪出事?」
過度設計 簡單問題給出複雜方案,顯得「專業」 問「有沒有更簡單的做法?」、「最小可行方案是什麼?」
附和陷阱 你提出一個想法,AI 不管對錯都說「好主意」 問「這個想法有什麼問題?」、「如果你反對,理由是什麼?」
術語轟炸 一堆專業名詞讓你不敢追問 直接說「用白話解釋」、「舉一個具體例子」
沉沒成本 AI 已經寫了很多程式碼,你不好意思說不對 程式碼隨時可以重寫,越早喊停成本越低

一個真實的反思

這段內容本身就是一個活生生的例子。這篇文章的前半段充滿了「架構師觀點」的包裝——設計模式、架構原則、專業術語。這些不是錯的,但它們的存在更多是因為「架構師觀點」這個角色要求我這樣寫,而不是因為你真的需要知道 Cache-Aside Pattern 叫什麼名字。

你真正需要的可能只是:「怎麼讓常用的 API 查詢變快」。而「Cache-Aside Pattern」只是其中一個可能的做法。

好的 AI 協作不是你學會說 AI 的語言,而是 AI 學會聽你的語言。


🚀 第十四站:Auto Mode — 全自動駕駛

什麼是 Auto Mode?

Auto Mode 讓 Claude Code 自行判斷是否需要詢問你權限。它使用一個 AI 分類器來評估每個操作的風險等級——安全的直接執行,有風險的才問你。

配置方式

{
  "permissions": {
    "defaultMode": "auto"
  },
  "autoMode": {
    "allow": [
      "讀取和修改 src/ 目錄下的程式碼",
      "執行 mvn test 和 npm test",
      "使用 git 進行版本控制操作"
    ],
    "soft_deny": [
      "不要刪除任何檔案",
      "不要修改 CI/CD 配置",
      "不要 push 到遠端"
    ],
    "environment": [
      "這是本地開發環境",
      "可以自由修改 src/ 和 tests/ 目錄"
    ]
  }
}
💡 架構師觀點:Auto Mode 就是基於策略的存取控制(Policy-Based Access Control)。你定義高層策略(允許什麼、拒絕什麼、環境是什麼),AI 分類器負責把每個具體操作映射到對應的策略。比逐條列出權限更靈活,但也需要更精確的策略描述。

🖥️ 第十五站:IDE 整合 — VSCode 中的 Claude Code

核心優勢

在 VSCode 中使用 Claude Code,你可以:

  • 選取程式碼直接提問:選中一段程式碼,右鍵問 Claude「這段程式碼在做什麼?」或「怎麼優化?」
  • @ 提及檔案:@filename 直接引用專案中的檔案,不需要複製貼上
  • 即時差異檢視:Claude 的每次編輯都以 diff 形式呈現,一目了然
  • 內嵌終端整合:Bash 指令的輸出直接顯示在對話中

高效工作流程

# 1. 選中有問題的程式碼 → 問 Claude
# 2. Claude 提出修改方案 → 你在 diff 中 review
# 3. 接受修改 → Claude 自動套用
# 4. 跑測試 → 確認沒有破壞既有功能
# 整個流程不離開編輯器
💡 架構師觀點:IDE 整合消除了「上下文切換成本」。你不需要在終端、瀏覽器、編輯器之間來回跳轉。所有的 AI 協作都發生在你最熟悉的工作環境中——這就是開發者體驗(DX)設計的核心理念。

⏳ 第十六站:背景代理與上下文管理

背景代理

有些任務不需要你盯著看——丟給背景代理,做完通知你:

# 啟動背景代理做耗時任務
# Claude Code 會在完成後通知你

# 適合背景執行的任務:
# → 大範圍的程式碼搜索和分析
# → 跨模組的相依性分析
# → 大型重構的前置調查
# → 文件生成

上下文管理

長對話中,Claude Code 的上下文窗口會逐漸填滿。掌握上下文管理技巧很重要:

  • /compact:手動壓縮對話上下文,保留關鍵資訊,釋放空間
  • PreCompact Hook:在壓縮前自動保存你想保留的重要資訊
  • 拆分對話:每個獨立任務開新對話,避免上下文污染
  • Memory 持久化:重要的決策和發現存入 Memory,跨對話保留
{
  "hooks": {
    "PreCompact": [
      {
        "matcher": "manual",
        "hooks": [{
          "type": "command",
          "command": "echo '{"hookSpecificOutput":{"hookEventName": "PreCompact","additionalContext": "壓縮前提醒:保留所有架構決策和 API 介面設計的上下文"}}'"
        }]
      }
    ]
  }
}
💡 架構師觀點:上下文管理就是記憶體管理。就像 JVM 的垃圾回收一樣,你需要平衡「保留有用資訊」和「釋放空間給新任務」。好的上下文管理策略能讓你在單次對話中完成更複雜的任務。

🔄 第十七站:TDD 與 Code Review 工作流

AI 驅動的 TDD 流程

# Step 1:先寫測試
「為 RefundService.processRefund() 寫測試案例:
- 全額退款成功
- 部分退款成功
- 超額退款應拋出 IllegalArgumentException
- 已退款的訂單不能重複退款
- 並發退款的樂觀鎖衝突處理」

# Step 2:確認測試(此時應全部失敗)
「跑一下測試,確認都是 RED 狀態」

# Step 3:實作程式碼讓測試通過
「現在實作 RefundService.processRefund(),讓所有測試通過」

# Step 4:重構
「測試都通過了。現在重構——有沒有重複程式碼或可以抽象的地方?」

雙代理 Code Review

# 完成實作後,啟動 Code Review 流程

# 方式一:使用 /review 技能
# Claude Code 會從多個角度審查你的程式碼變更

# 方式二:手動指定審查角度
「以 Senior Java Developer 的身份審查這次的 git diff:
1. 是否符合 SOLID 原則?
2. 異常處理是否完整?
3. 是否有潛在的效能問題?
4. API 設計是否符合 RESTful 規範?
5. 測試覆蓋是否足夠?」
💡 架構師觀點:TDD + AI Code Review 構成了一個持續品質迴圈。AI 寫測試確保功能正確,AI 審查確保品質達標。你的角色從「寫程式碼」轉變為「定義品質標準」和「做最終判斷」。

📊 協作能力總覽:你能用 Claude Code 做什麼

階段 能力 核心配置/工具 效率提升
環境設定 跳過權限提示 permissions.allow 消除 80% 的中斷
環境設定 自動化護欄 Hooks 零人工品質檢查
環境設定 外部服務整合 MCP Servers 統一操作介面
需求階段 腦力激盪 Skills: brainstorming 結構化需求探索
設計階段 計畫模式 Plan Mode 先謀後動,減少返工
設計階段 專案上下文 CLAUDE.md AI 自動遵守規範
開發階段 TDD 工作流 Skills: TDD 測試先行,品質保證
開發階段 多代理並行 Subagents 任務並行,加速 N 倍
開發階段 背景代理 Background agents 非阻塞式工作
開發階段 隔離環境 Git Worktree 互不干擾的並行開發
審查階段 Code Review Skills: code-review 多角度自動審查
部署階段 全自動模式 Auto Mode AI 自主判斷,減少打擾
跨對話 記憶系統 Memory 知識累積,越用越聰明
跨對話 上下文管理 /compact + Hooks 更長的有效工作時間
日常 IDE 整合 VSCode Extension 零上下文切換
日常 SSH 遠端 sshConfigs 隨處開發

🎯 結語:從工具到戰友,但要是誠實的戰友

這篇文章從 settings.json 的基礎配置出發,一路展開到 Claude Code 的完整協作生態。17 個核心能力站點分為三層:

  • 基礎設施層(第 1-8 站):權限、Hooks、MCP、Sandbox、Worktree、環境變數、SSH、Plugins——你的「硬體配置」
  • 工作流程層(第 9-13 站):CLAUDE.md、Plan Mode、多代理、Memory、溝通技巧——你的「操作系統」
  • 自動化層(第 14-17 站):Auto Mode、IDE 整合、背景代理、TDD/Code Review——你的「自動駕駛」

但如果你只記住一件事,請記住這個:

AI 最危險的時候不是它出錯的時候——是它看起來沒出錯的時候。

所有的配置、Hooks、自動化,都是為了讓協作更高效。但高效的前提是正確。而正確的前提是你敢對 AI 的輸出踩煞車,問它:「你跳過了什麼?」

不要追求「完美的 Prompt」。不要花時間研究該給 AI 什麼角色。把那些時間拿來:

  1. 描述你的痛點(而不是指定解法)
  2. 讓 AI 問你問題(而不是你猜它需要什麼)
  3. 在「看起來差不多」的時候多問一句(而不是直接 GO)
  4. 把失敗經驗告訴它(而不是只給它成功案例)

好的人機協作不是人學會說機器的語言,而是建立一個雙方都誠實的溝通環境。

你配置 Claude Code 的方式,反映的不只是技術能力——更是你對「什麼是好的協作」的理解。

本文基於 Claude Code 2026 年 3 月版本撰寫,並包含真實的人機協作反思。所有配置範例均經過實戰驗證。

留言

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *