掌握 Claude Code 的使用技巧，是提升開發效率的關鍵。從撰寫精準的 Prompt、管理大型專案的 Context、到有效控制 API 成本，每一個環節都直接影響你與 AI 協作的品質。本篇文章整理了 Anthropic 官方推薦與社群驗證的最佳實踐，涵蓋 Prompt 撰寫、專案策略、Code Review、Debug 流程、成本控制到團隊協作，幫助你從「能用」進階到「善用」Claude Code。
Prompt 撰寫技巧：讓 AI 精準理解你的意圖
Claude Code 的 Context Window（上下文視窗）是最重要的資源。每次對話中，你的訊息、Claude 讀取的檔案、執行指令的輸出，全部都會佔用 Context。當 Context 被填滿時，Claude 的表現會明顯下降，可能會「忘記」先前的指令或犯更多錯誤。因此，撰寫高效的 Prompt 是使用 Claude Code 的第一課。
具體明確，避免模糊指令
模糊的指令會讓 Claude 進行不必要的探索，浪費 Context 也浪費時間。具體的指令能讓 Claude 直接切入重點，減少來回修正的次數。
| 策略 | 不好的寫法 | 推薦寫法 |
|---|---|---|
| 限定範圍 | 幫 foo.py 加測試 | 幫 foo.py 寫測試，涵蓋使用者登出時的 edge case，不要用 mock |
| 指定來源 | ExecutionFactory 的 API 為什麼這麼奇怪？ | 查看 ExecutionFactory 的 git history，總結它的 API 是怎麼演變成現在這樣的 |
| 描述症狀 | 修復登入的 bug | 使用者回報 session timeout 後登入失敗，檢查 src/auth/ 的 token refresh 流程，寫一個能重現問題的失敗測試，然後修復它 |
| 參考既有模式 | 加一個日曆 widget | 看首頁現有 widget 的實作模式，HotDogWidget.php 是好範例，照這個 pattern 實作一個新的日曆 widget |
提供驗證標準
這是提升 Claude Code 輸出品質最有效的方法。當 Claude 能自行驗證結果時，表現會大幅提升。沒有明確的成功標準，Claude 可能會產出看起來正確但實際無法運作的程式碼。
# 不好的做法：沒有驗證標準
實作一個驗證 email 的函式
# 推薦做法：提供測試案例
寫一個 validateEmail 函式
測試案例：user@example.com → true, invalid → false, user@.com → false
實作完成後執行測試確認結果驗證方式不限於測試。你也可以提供螢幕截圖讓 Claude 比對 UI、指定 linter 規則、或給予預期的輸出格式。重點是讓 Claude 擁有自我檢查的能力，而不是完全依賴你來判斷。
善用 @ 符號與豐富的 Context
與其用文字描述檔案位置，不如直接用 @ 引用檔案，Claude 會在回應前先讀取該檔案。此外，你還可以透過多種方式提供豐富的 Context：
- 用
@file.ts直接引用檔案，比描述路徑更精準 - 直接貼上圖片或截圖，Claude 支援多模態輸入
- 提供文件或 API 的 URL，用
/permissions允許常用網域 - 用 pipe 傳送資料：
cat error.log | claude - 讓 Claude 自己用 Bash 指令、MCP 工具或讀取檔案來獲取需要的資訊
分步驟工作：探索→規劃→實作→提交
讓 Claude 直接跳到寫程式碼，可能會解決錯誤的問題。Anthropic 內部測試發現，未經引導的嘗試成功率只有約 33%。使用 Plan Mode 將探索與執行分離，能大幅提升成功率。
推薦的工作流程分為四個階段：
| 階段 | 模式 | 操作說明 |
|---|---|---|
| 探索 | Plan Mode | 讓 Claude 讀取檔案、理解架構，但不做任何修改 |
| 規劃 | Plan Mode | 要求 Claude 建立詳細的實作計畫，按 Ctrl+G 可在編輯器中修改計畫 |
| 實作 | Normal Mode | 切回一般模式，讓 Claude 依照計畫寫程式碼並執行測試 |
| 提交 | Normal Mode | 讓 Claude 用描述性的 commit message 提交並建立 PR |
# 階段一：探索（Plan Mode，按 Shift+Tab 進入）
讀取 /src/auth 了解我們怎麼處理 session 和登入
也看一下環境變數的管理方式
# 階段二：規劃（Plan Mode）
我想加入 Google OAuth，哪些檔案需要修改？
Session 流程是什麼？建立一個計畫
# 階段三：實作（Normal Mode，按 Shift+Tab 切回）
按照你的計畫實作 OAuth 流程
為 callback handler 寫測試，執行測試套件並修復失敗
# 階段四：提交
用描述性的 commit message 提交，然後開一個 PR值得注意的是，Plan Mode 會增加額外開銷，對於範圍明確的小修改（如修正錯字、加一行 log、重新命名變數），直接讓 Claude 執行即可，不必每次都走完四個階段。
大型專案策略：有效管理 Context 與 CLAUDE.md
在大型專案中，Context 管理是決定 Claude Code 效能的關鍵。一個除錯或程式碼探索的 Session 可能會產生數萬個 Token，如果不善加管理，Claude 的表現會急速下滑。
撰寫有效的 CLAUDE.md
CLAUDE.md 是 Claude Code 在每次對話開始時自動讀取的特殊檔案。你可以用 /init 指令根據專案結構產生初始版本，然後持續優化。它應該包含 Claude 無法從程式碼推斷出的資訊，例如建置指令、程式碼風格、工作流程規則等。
# CLAUDE.md 範例
# 程式碼風格
- 使用 ES modules (import/export)，不用 CommonJS (require)
- 盡量使用解構引入 (eg. import { foo } from 'bar')
# 工作流程
- 完成一系列程式碼修改後，務必執行 typecheck
- 效能考量，優先執行單一測試而非整個測試套件
# 建置指令
- 測試：npm run test
- Lint：npm run lint
- 型別檢查：npx tsc --noEmitCLAUDE.md 的核心原則是精簡。對每一行內容問自己：「拿掉這一行，Claude 會不會犯錯？」如果不會，就刪掉它。過長的 CLAUDE.md 反而會讓 Claude 忽略你真正重要的指令。
| 應該包含 | 不應該包含 |
|---|---|
| Claude 猜不到的 Bash 指令 | Claude 看程式碼就能推斷的資訊 |
| 與預設不同的程式碼風格規則 | Claude 本來就知道的語言慣例 |
| 測試指令與偏好的測試框架 | 詳細的 API 文件（改用連結） |
| 版本庫禮儀（分支命名、PR 慣例） | 經常變動的資訊 |
| 專案特有的架構決策 | 冗長的教學或說明文件 |
| 開發環境的特殊設定 | 逐檔說明程式碼庫結構 |
CLAUDE.md 的層級配置
CLAUDE.md 支援多層級配置，適用於大型專案和 Monorepo：
| 位置 | 適用範圍 | 建議用途 |
|---|---|---|
~/.claude/CLAUDE.md | 所有 Claude 對話 | 全域偏好設定 |
./CLAUDE.md | 此專案 | 提交到 Git，與團隊共享 |
./CLAUDE.local.md | 此專案（僅本機） | 個人專案筆記，加入 .gitignore |
| 父層目錄 | 自動繼承 | Monorepo 中 root 和子專案都會載入 |
| 子層目錄 | 按需載入 | Claude 處理該目錄檔案時自動載入 |
將 CLAUDE.md 提交到版本控制，讓整個團隊都能受益。這個檔案的價值會隨著時間累積而增長。你也可以用 @path/to/import 語法引入其他檔案的內容。
善用 Skills 與 Subagents 管理知識
如果 CLAUDE.md 包含太多特定工作流程的詳細指令（如 PR Review、資料庫遷移），即使你在做無關的工作，這些 Token 也會被載入。把專門的指令移到 Skills 中，Claude 只在需要時才會載入，保持基礎 Context 精簡。
# .claude/skills/api-conventions/SKILL.md
---
name: api-conventions
description: REST API 設計慣例
---
# API 慣例
- URL 路徑使用 kebab-case
- JSON 屬性使用 camelCase
- 列表端點必須包含分頁
- API 版本放在 URL 路徑中 (/v1/, /v2/)Code Review 工作流
Claude Code 可以成為你強大的 Code Review 夥伴。由於 Context 是最重要的限制，用全新的 Session 進行 Review 會比在同一個 Session 裡寫完程式再 Review 來得更有效——Claude 不會對自己剛寫的程式碼產生偏見。
Writer/Reviewer 模式
最有效的 Code Review 策略是使用兩個獨立的 Session：一個負責寫程式，另一個負責審查。這樣 Reviewer 擁有乾淨的 Context，能更客觀地發現問題。
| Session A（Writer） | Session B（Reviewer） |
|---|---|
實作 API 端點的 rate limiter | （等待 Writer 完成） |
| （等待 Review 回饋） | Review src/middleware/rateLimiter.ts 的 rate limiter 實作，檢查 edge cases、race conditions、以及是否符合現有 middleware patterns |
根據 Review 回饋修改：[貼上 Session B 的輸出] | （完成） |
使用 Subagent 進行 Code Review
如果不想開另一個 Session，你也可以用 Subagent 來進行 Review。Subagent 在獨立的 Context 中運行，不會污染你的主要對話：
# 在主 Session 中要求 Subagent Review
用一個 subagent 來 review 這段程式碼的 edge cases
# 建立專門的 Security Reviewer Subagent
# .claude/agents/security-reviewer.md
---
name: security-reviewer
description: 審查程式碼的安全漏洞
tools: Read, Grep, Glob, Bash
model: opus
---
你是資深安全工程師，請審查以下程式碼：
- 注入漏洞（SQL、XSS、command injection）
- 認證與授權缺陷
- 程式碼中的密鑰或憑證
- 不安全的資料處理
提供具體的行號參考和修復建議。你也可以用類似的方式讓一個 Claude 寫測試，另一個 Claude 寫通過測試的程式碼，形成 TDD（Test-Driven Development）的工作流。
Debug 流程與技巧
Debug 是 Claude Code 最常見的使用場景之一。正確的 Debug 策略能大幅減少來回修正的次數。
提供完整的錯誤資訊
不要只說「build 失敗了」，而是提供具體的錯誤訊息、發生的情境、以及你期望的結果。讓 Claude 能直接定位根因，而非猜測：
# 不好的做法
build 失敗了，幫我修
# 推薦做法
build 失敗了，錯誤訊息如下：
[貼上完整的錯誤訊息]
修復它並確認 build 成功，要解決根本原因，不要只是抑制錯誤善用 Plan Mode 進行調查
面對複雜的 Bug，先用 Plan Mode（按 Shift+Tab）讓 Claude 調查問題而不做任何修改。等 Claude 理解問題全貌後，再切回 Normal Mode 進行修復。這樣可以避免 Claude 急著修改但解決了錯誤的問題。
設定自動化回饋循環
在 Prompt 中加入驗證步驟，讓 Claude 能自己發現錯誤並修正，不需要你介入：
# 在 Prompt 中包含驗證步驟
修復 src/utils/parser.ts 中的解析錯誤
修完之後：
1. 執行 npm run test -- parser.test.ts
2. 執行 npm run lint
3. 確認所有測試通過
如果有失敗的測試，繼續修復直到全部通過你也可以用 Hooks 來自動化這個流程。例如設定一個 PreToolUse Hook，在每次 Bash 執行測試時自動過濾輸出，只顯示失敗的測試結果，減少 Context 消耗。
成本控制方法
Claude Code 的費用取決於 Token 消耗量。根據 Anthropic 官方數據，平均每位開發者每天花費約 6 美元，90% 的使用者日花費低於 12 美元，月均約 100-200 美元（使用 Sonnet 4.6）。以下策略可以幫你有效控制成本。
積極管理 Context
Token 成本與 Context 大小成正比。Claude Code 會透過 Prompt Caching（減少重複內容的費用）和 Auto-compaction（在接近 Context 上限時自動摘要）來優化成本。但你也需要主動管理：
| 策略 | 說明 | 指令 |
|---|---|---|
| 任務之間清除 Context | 切換不相關的工作時，過期的 Context 會在後續每則訊息中浪費 Token | /clear |
| 自訂壓縮指示 | 告訴 Claude 在壓縮時保留什麼資訊 | /compact 專注於程式碼範例和 API 用法 |
| 查看 Token 用量 | 即時追蹤當前 Session 的花費 | /cost |
| 快速提問不留痕跡 | 臨時問題用浮動視窗回答，不進入對話紀錄 | /btw |
| 部分壓縮 | 只壓縮某個時間點之後的對話，保留之前的 Context | Esc+Esc → 選擇 Summarize |
選擇適合的模型
Sonnet 能處理大多數程式開發任務且成本較低，Opus 適合保留給複雜的架構決策或多步驟推理。用 /model 在 Session 中切換模型，或在 /config 設定預設模型。對於簡單的 Subagent 任務，可以在設定中指定 model: haiku。
將冗長操作委派給 Subagent
執行測試、讀取文件、處理 Log 檔案會消耗大量 Context。將這些操作委派給 Subagent，冗長的輸出留在 Subagent 的 Context 中，只有摘要回到你的主對話：
# 委派調查工作給 Subagent
用 subagents 調查我們的認證系統如何處理 token refresh，
以及我們有沒有現成的 OAuth 工具可以重用
# 委派測試執行
用一個 subagent 執行完整的測試套件，
只回報失敗的測試和錯誤摘要其他成本優化技巧
- 安裝 Code Intelligence Plugin：對型別語言安裝程式碼智慧插件，提供精確的符號導航，減少不必要的檔案讀取
- 減少 MCP Server 開銷：MCP 工具定義預設是延遲載入的，用
/mcp檢視並停用未使用的 Server - 偏好使用 CLI 工具：
gh、aws、gcloud等 CLI 工具比 MCP Server 更節省 Context - 調整 Extended Thinking：用
/effort降低思考等級，或設定MAX_THINKING_TOKENS=8000限制思考 Token - 撰寫精確的 Prompt：模糊的請求如「改善這個程式庫」會觸發大範圍掃描，具體的請求如「在 auth.ts 的登入函式加上輸入驗證」能更高效地完成
與團隊協作的最佳實踐
當整個團隊都在使用 Claude Code 時，統一的實踐規範和共享的配置能讓協作效率倍增。
共享 CLAUDE.md 與 Skills
將 CLAUDE.md 提交到 Git，讓團隊成員都能貢獻和受益。同時，將團隊共用的工作流程封裝成 Skills，確保一致的開發標準：
# .claude/skills/fix-issue/SKILL.md
---
name: fix-issue
description: 修復 GitHub Issue
disable-model-invocation: true
---
分析並修復 GitHub issue：$ARGUMENTS
1. 用 `gh issue view` 取得 issue 詳情
2. 理解 issue 描述的問題
3. 搜尋程式碼庫中相關的檔案
4. 實作必要的修改來修復 issue
5. 撰寫並執行測試驗證修復
6. 確保程式碼通過 linting 和型別檢查
7. 撰寫描述性的 commit message
8. Push 並建立 PR團隊成員只需執行 /fix-issue 1234 就能按照統一的流程修復 Issue，確保每個人都遵循相同的品質標準。
善用並行工作模式
Claude Code 支援水平擴展，你可以同時運行多個 Session 來加速開發。主要有三種方式：
- Claude Code Desktop App：視覺化管理多個本地 Session，每個 Session 有獨立的 worktree
- Claude Code on the Web：在 Anthropic 安全的雲端基礎設施上運行，使用獨立的 VM
- Agent Teams：多個 Session 的自動化協調，支援共享任務、訊息傳遞和團隊領導
非互動模式自動化
用 claude -p "prompt" 在 CI Pipeline、Pre-commit Hook 或腳本中非互動式地使用 Claude Code。搭配 --output-format 選擇輸出格式：
# 單次查詢
claude -p "說明這個專案的功能"
# 結構化輸出供腳本使用
claude -p "列出所有 API 端點" --output-format json
# 串流處理即時輸出
claude -p "分析這個 log 檔" --output-format stream-json
# 批次處理多個檔案
for file in $(cat files.txt); do
claude -p "將 $file 從 React 遷移到 Vue，回傳 OK 或 FAIL" \
--allowedTools "Edit,Bash(git commit *)"
done設定團隊的權限與安全
對於團隊部署，建議先從小規模試點開始，建立使用模式後再擴大。管理者可以透過 Claude Console 設定 Workspace 花費上限和查看使用報告。根據團隊規模設定適當的 Token Per Minute（TPM）限制：
| 團隊規模 | 每人 TPM | 每人 RPM |
|---|---|---|
| 1-5 人 | 200k-300k | 5-7 |
| 5-20 人 | 100k-150k | 2.5-3.5 |
| 20-50 人 | 50k-75k | 1.25-1.75 |
| 50-100 人 | 25k-35k | 0.62-0.87 |
| 100 人以上 | 10k-20k | 0.25-0.47 |
團隊規模越大，每人的 TPM 越低，因為大組織中同時使用的比例較低。這些限制是在組織層級設定的，個別使用者在其他人不活躍時可以暫時使用更多額度。
常見錯誤與避免方法
以下是使用 Claude Code 時最常見的五大陷阱，早期辨識能省下大量時間。
Kitchen Sink Session（雜燴型 Session）
你從一個任務開始，中途問了不相關的問題，又回到第一個任務。Context 充滿了無關的資訊，Claude 的表現因此下降。
解法：在不相關的任務之間使用 /clear 清除 Context。把每個 Session 當作一個單一用途的工具。
反覆修正（Correction Loop）
Claude 做錯了，你修正它，還是錯，你再修正。Context 被失敗的嘗試污染，Claude 的表現越來越差。
解法：如果修正兩次都還不對，用 /clear 重新開始，寫一個更好的初始 Prompt，把你學到的東西融入其中。乾淨的 Session 搭配更好的 Prompt，幾乎總是勝過累積修正的長 Session。
過度膨脹的 CLAUDE.md
如果你的 CLAUDE.md 太長，Claude 會忽略其中一半的內容，因為重要的規則被淹沒在雜訊中。
解法：定期精簡。如果 Claude 在沒有某條規則的情況下已經能正確行為，就刪掉它。將特定工作流程的指令移到 Skills 中，目標是讓 CLAUDE.md 控制在 200 行以內。你也可以用強調語句（如「IMPORTANT」或「YOU MUST」）來提高關鍵規則的遵守度。
信任但不驗證（Trust-Then-Verify Gap）
Claude 產出了看起來合理的實作，但沒有處理 edge cases。你直接部署了，然後在生產環境發現問題。
解法：永遠提供驗證機制（測試、腳本、截圖）。如果你無法驗證它，就不要上線。在 Prompt 中包含測試案例是最高效的做法。
無限探索（Infinite Exploration）
你要求 Claude「調查」某個問題但沒有限定範圍。Claude 讀取了數百個檔案，Context 被佔滿，主要任務的效能受到影響。
解法：限縮調查範圍，或使用 Subagent 進行探索，讓探索結果不會消耗你主 Session 的 Context。
Session 管理技巧
Claude Code 的對話是持久且可逆的。善用這個特性可以讓你更大膽地嘗試。
| 操作 | 快捷鍵 / 指令 | 用途 |
|---|---|---|
| 中斷操作 | Esc | 停止 Claude 當前動作，Context 保留可重新導向 |
| 回溯 | Esc+Esc 或 /rewind | 回復到先前的 Checkpoint，還原對話和程式碼 |
| 撤銷變更 | 輸入「Undo that」 | 讓 Claude 撤回剛才的修改 |
| 重置 Context | /clear | 在不相關的任務之間清空 Context |
| 繼續對話 | claude --continue | 延續最近的對話 |
| 選擇對話 | claude --resume | 從最近的對話列表中選擇 |
| 命名 Session | /rename | 為 Session 取描述性名稱，方便日後查找 |
每個 Claude 的操作都會建立 Checkpoint。你可以放心讓 Claude 嘗試有風險的方案——如果不行，隨時可以回溯到之前的狀態。Checkpoint 跨 Session 保留，即使關閉終端機後也能回溯。
培養你的 AI 協作直覺
本篇文章介紹的最佳實踐不是死規則，而是經過驗證的起點。隨著使用經驗的累積，你會發展出自己的直覺——知道何時該具體、何時該開放，何時該規劃、何時該探索，何時該清除 Context、何時該讓它累積。
當 Claude 產出優秀的結果時，留意你做了什麼：Prompt 的結構、提供的 Context、使用的模式。當 Claude 遇到困難時，反問自己：Context 太雜亂了？Prompt 太模糊了？任務太大了？
高效使用 Claude Code 的工程師與一般使用者的差異，不在於 Prompt 的品質，而在於他們在 Claude 開始執行之前所建立的結構。從今天開始，用本篇文章的技巧優化你的工作流程，讓 Claude Code 真正成為你的 AI 程式開發夥伴。
