每次使用 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 | 個人在此專案的覆蓋設定 |
⚡ 第一站:跳過權限提示(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": "發送通知中..."
}
]
}
]
}
}
實戰範例二:寫完程式碼自動格式化
{
"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"
}
]
}
]
}
}
進階:三種 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 伺服器可以獨立更新和維護
- 安全隔離:每個伺服器有自己的環境變數和權限
🔐 第四站: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"]
}
}
}
--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 中只拉取需要的目錄(省時間)
🔌 第六站:環境變數與模型選擇
環境變數
{
"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 |
快速模式 | 簡單任務時切換,加速回應 |
📡 第七站: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:進階程式碼搜尋能力
🏗️ 完整配置範本:架構師的 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
🗺️ 第十站:Plan Mode — 先謀後動
什麼時候用 Plan Mode?
當任務複雜到「先想清楚再動手」比「邊做邊改」更高效時,就該用 Plan Mode。典型場景:
- 跨模組重構
- 新功能設計(涉及多個服務)
- 技術遷移(例如從 REST 遷移到 GraphQL)
實戰操作
# 進入計畫模式
# 在聊天中輸入 /plan 或按 Shift+Tab 切換
# 給出需求
「我需要為現有的訂單系統加入退款功能。
退款需要:
1. 支援全額和部分退款
2. 整合現有的支付閘道(綠界、LINE Pay)
3. 退款狀態需要即時通知用戶
4. 需要防止重複退款的並發控制」
# Claude Code 會產出:
# → 影響範圍分析
# → 架構設計建議
# → 分步實施計畫
# → 每步的驗證標準
🤖 第十一站:多代理並行 — 分身術
核心概念
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 代理
# → 從安全性、效能、可維護性三個角度審查
# → 產出具體的修改建議
🧠 第十二站: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 完成」
💬 第十三站:與 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/ 目錄"
]
}
}
🖥️ 第十五站:IDE 整合 — VSCode 中的 Claude Code
核心優勢
在 VSCode 中使用 Claude Code,你可以:
- 選取程式碼直接提問:選中一段程式碼,右鍵問 Claude「這段程式碼在做什麼?」或「怎麼優化?」
- @ 提及檔案:用
@filename直接引用專案中的檔案,不需要複製貼上 - 即時差異檢視:Claude 的每次編輯都以 diff 形式呈現,一目了然
- 內嵌終端整合:Bash 指令的輸出直接顯示在對話中
高效工作流程
# 1. 選中有問題的程式碼 → 問 Claude
# 2. Claude 提出修改方案 → 你在 diff 中 review
# 3. 接受修改 → Claude 自動套用
# 4. 跑測試 → 確認沒有破壞既有功能
# 整個流程不離開編輯器
⏳ 第十六站:背景代理與上下文管理
背景代理
有些任務不需要你盯著看——丟給背景代理,做完通知你:
# 啟動背景代理做耗時任務
# Claude Code 會在完成後通知你
# 適合背景執行的任務:
# → 大範圍的程式碼搜索和分析
# → 跨模組的相依性分析
# → 大型重構的前置調查
# → 文件生成
上下文管理
長對話中,Claude Code 的上下文窗口會逐漸填滿。掌握上下文管理技巧很重要:
- /compact:手動壓縮對話上下文,保留關鍵資訊,釋放空間
- PreCompact Hook:在壓縮前自動保存你想保留的重要資訊
- 拆分對話:每個獨立任務開新對話,避免上下文污染
- Memory 持久化:重要的決策和發現存入 Memory,跨對話保留
{
"hooks": {
"PreCompact": [
{
"matcher": "manual",
"hooks": [{
"type": "command",
"command": "echo '{"hookSpecificOutput":{"hookEventName": "PreCompact","additionalContext": "壓縮前提醒:保留所有架構決策和 API 介面設計的上下文"}}'"
}]
}
]
}
}
🔄 第十七站: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. 測試覆蓋是否足夠?」
📊 協作能力總覽:你能用 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 什麼角色。把那些時間拿來:
- 描述你的痛點(而不是指定解法)
- 讓 AI 問你問題(而不是你猜它需要什麼)
- 在「看起來差不多」的時候多問一句(而不是直接 GO)
- 把失敗經驗告訴它(而不是只給它成功案例)
好的人機協作不是人學會說機器的語言,而是建立一個雙方都誠實的溝通環境。
你配置 Claude Code 的方式,反映的不只是技術能力——更是你對「什麼是好的協作」的理解。
本文基於 Claude Code 2026 年 3 月版本撰寫,並包含真實的人機協作反思。所有配置範例均經過實戰驗證。
發佈留言