測驗：Commands 自訂斜線命令
共 5 題，點選答案後會立即顯示結果
1. Claude Code 中，Rules 和 Commands 最核心的差別是什麼？
2. 如果你建立了一個檔案 .claude/commands/code-review.md，要怎麼在 Claude Code 中觸發它？
3. 使用 /plan 命令時，Claude 在什麼階段才會開始寫代碼？
4. /code-review 命令的三層檢查中，哪一層包含「密碼寫死在代碼裡」的問題？
5. 你想寫一個自訂命令 /migrate，讓使用者可以指定目標環境（如 /migrate staging）。在命令的 Markdown 檔案中，應該用什麼來接收使用者輸入的參數？
一句話說明
Commands 是你在 Claude Code 裡的「快捷鍵」——輸入 /plan 就啟動規劃流程，輸入 /tdd 就進入測試驅動開發，一個斜線命令觸發一整套工作流。
為什麼要關心 Commands？
上一篇我們學了 CLAUDE.md 與 Rules——那是「被動規則」，Claude 每次對話都會自動載入。但有些工作流你不需要每次都跑，比如：
- 開始新功能時才需要規劃
- 準備提交時才需要代碼審查
- 遇到 bug 時才需要測試驅動修復
這些「需要時才觸發」的工作流，就是 Commands 的用武之地。
Rules vs Commands 快速對照
| Rules（被動規則） | Commands（主動指令） | |
|---|---|---|
| 觸發方式 | 自動載入，每次對話都生效 | 手動輸入 /命令名稱 觸發 |
| 用途 | 編碼風格、專案慣例 | 工作流程、多步驟任務 |
| 類比 | 開車時「靠右行駛」的交通規則 | 按下「導航」按鈕啟動路線規劃 |
| 檔案位置 | .claude/rules/ |
.claude/commands/ |
| 執行頻率 | 永遠生效 | 需要時才用 |
白話翻譯：Rules 是告訴 Claude「你平常該怎麼做」，Commands 是告訴 Claude「我現在要你做這件事」。
Commands 的檔案結構
Commands 的結構非常簡單——就是放在 commands/ 目錄下的 .md 檔案，檔名就是命令名稱。
.claude/
commands/ # 你的自訂命令都放這裡
plan.md # 輸入 /plan 時觸發
tdd.md # 輸入 /tdd 時觸發
code-review.md # 輸入 /code-review 時觸發
deploy.md # 輸入 /deploy 時觸發
Code language: PHP (php)命名規則翻譯
檔名：plan.md → 使用方式：/plan
檔名：code-review.md → 使用方式：/code-review
檔名：multi-plan.md → 使用方式：/multi-plan
就這麼簡單：檔名（去掉 .md）= 命令名稱。用連字號 - 來分隔多個單字。
31 個預設命令一覽
everything-claude-code 這個知名的開源配置庫，提供了 31 個精心設計的命令。我們按用途分成五大類：
規劃類：動手前先想清楚
| 命令 | 用途 | 什麼時候用 |
|---|---|---|
/plan |
架構規劃，列出步驟與風險 | 開始新功能前 |
/multi-plan |
多模型協作規劃 | 複雜功能需要多角度分析 |
/orchestrate |
多代理依序執行工作流 | 大型任務需要完整流水線 |
開發類：寫代碼的各種流程
| 命令 | 用途 | 什麼時候用 |
|---|---|---|
/tdd |
測試驅動開發（先寫測試再寫代碼） | 寫新功能、修 bug |
/build-fix |
逐一修復建構錯誤 | 建構失敗時 |
/multi-backend |
後端多服務協作開發 | 微服務架構開發 |
/multi-frontend |
前端多服務協作開發 | 前端元件開發 |
/multi-execute |
多代理協作執行 | 需要並行處理多任務 |
/multi-workflow |
通用多服務工作流 | 跨領域服務整合 |
品質類：確保代碼品質
| 命令 | 用途 | 什麼時候用 |
|---|---|---|
/code-review |
代碼審查（安全性 + 品質） | 提交前 |
/verify |
跑驗證迴圈 | 確認修改沒有破壞東西 |
/eval |
評估代碼品質 | 需要品質報告時 |
/test-coverage |
測試覆蓋率檢查 | 想知道測試是否足夠 |
/refactor-clean |
移除死代碼 | 代碼庫清理 |
/e2e |
端對端測試（Playwright） | 整合測試 |
/go-review |
Go 語言專用審查 | Go 專案代碼審查 |
/go-test |
Go 語言 TDD | Go 專案測試 |
/go-build |
Go 建構錯誤修復 | Go 建構失敗時 |
/python-review |
Python 專用審查 | Python 專案代碼審查 |
學習與知識管理類：累積經驗
| 命令 | 用途 | 什麼時候用 |
|---|---|---|
/learn |
從當前工作中萃取可重用知識 | 解決了難題之後 |
/skill-create |
從 git 歷史生成技能 | 想把經驗沉澱為技能 |
/instinct-status |
查看已學習的直覺模式 | 了解 Claude 學了什麼 |
/instinct-import |
匯入直覺模式 | 從外部載入經驗 |
/instinct-export |
匯出直覺模式 | 分享經驗給團隊 |
/evolve |
把直覺聚類成技能 | 整理累積的經驗 |
工具類：管理開發環境
| 命令 | 用途 | 什麼時候用 |
|---|---|---|
/checkpoint |
存檔與比對進度 | 想在關鍵步驟建立存檔點 |
/sessions |
管理對話歷史 | 找回之前的對話 |
/setup-pm |
設定套件管理器 | 專案初始化 |
/pm2 |
PM2 服務管理 | 管理背景服務 |
/update-codemaps |
更新代碼地圖 | 代碼結構變更後 |
/update-docs |
更新文件 | 代碼修改後同步文件 |
重點命令詳解
/plan：動手前先規劃
這是最常用的命令之一。輸入 /plan 後，Claude 會進入「規劃模式」：
你輸入：/plan 我要加一個使用者通知功能
Claude 會做的事：
1. 重新描述需求 → 「你要的是：當特定事件發生時，透過 email/推播通知使用者」
2. 識別風險 → 「注意：需要考慮通知頻率限制、使用者偏好設定」
3. 列出步驟 → 「Phase 1: 資料庫設計 → Phase 2: API → Phase 3: 前端 → Phase 4: 測試」
4. 等你確認 → 「這個計畫 OK 嗎？要調整什麼？」
關鍵設計：Claude 在你確認之前不會寫任何代碼。這就是 /plan 的安全機制——先想好，再動手。
什麼時候該用 /plan：
- 開始一個新功能
- 做架構調整
- 複雜的重構
- 會影響多個元件的修改
/tdd：測試驅動開發
/tdd 命令讓 Claude 嚴格遵循「紅燈 → 綠燈 → 重構」的經典 TDD 流程：
你輸入：/tdd 實作一個計算折扣價格的函式
Claude 會做的事（依序）：
1. 定義介面 → 先寫出函式簽名和型別
2. 寫失敗測試 → 寫測試，跑一次確認是紅燈（失敗）
3. 最小實作 → 寫最少的代碼讓測試通過
4. 確認綠燈 → 跑測試確認通過
5. 重構 → 改善代碼結構，確認測試還是綠燈
6. 檢查覆蓋率 → 目標 80% 以上，關鍵邏輯要 100%
白話翻譯：TDD 的核心理念是「先寫考試題目，再寫答案」。這樣你才知道答案是對的。
/code-review：提交前的品質關卡
這個命令會對你的修改做全面審查：
你輸入：/code-review
Claude 會做的事：
1. 用 git diff 找出你改了什麼
2. 三層檢查：
- CRITICAL（嚴重）：有沒有密碼寫死在代碼裡？有沒有 SQL 注入？
- HIGH（重要）：函式有沒有超過 50 行？有沒有漏掉錯誤處理？
- MEDIUM（建議）：能不能用更好的寫法？測試夠不夠？
3. 產出報告
4. 如果有 CRITICAL 或 HIGH 的問題，會阻止提交
核心原則：「絕不放行有安全漏洞的代碼。」
/learn：把解題經驗存起來
當你在開發過程中解決了一個棘手的問題，可以用 /learn 把經驗沉澱下來：
你輸入：/learn
Claude 會做的事：
1. 回顧這次對話中你解決了什麼問題
2. 從四個維度萃取知識：
- 錯誤解法：什麼壞了、為什麼、怎麼修的
- 除錯技巧：不明顯的診斷方法
- 繞路方案：套件的坑、API 的限制
- 專案慣例：這個代碼庫的架構模式
3. 存成技能檔案到 ~/.claude/skills/learned/
Code language: JavaScript (javascript)白話翻譯：/learn 就像寫「踩坑筆記」，讓 Claude 下次遇到同樣問題時能直接用。
如何撰寫自訂 Command
看完預設命令，你一定想問：「我能自己寫命令嗎？」當然可以。
基本結構
一個 Command 就是一個 Markdown 檔案。最簡單的結構：
# 命令標題
[描述這個命令要做什麼]
1. 第一步：[做什麼]
2. 第二步：[做什麼]
3. 第三步：[做什麼]
Code language: CSS (css)就這樣。沒有特殊語法，沒有 YAML 前置，就是普通的 Markdown。
Prompt 設計的三個技巧
技巧一：明確的步驟指令
# Deploy
部署當前專案到正式環境：
1. 先跑測試，確認全部通過
2. 檢查 git 狀態，確認沒有未提交的修改
3. 建構正式版本
4. 顯示部署前的檢查清單，等待確認
5. 確認後才執行部署
Code language: PHP (php)每一步都是具體的動作，Claude 會依序執行。
技巧二：定義停止條件
停止條件：
- 如果測試沒有全部通過，停止並回報
- 如果有未提交的修改，提醒使用者先 commit
- 等待使用者確認後才實際部署
告訴 Claude 什麼時候該停下來，避免它自作主張。
技巧三：指定輸出格式
最後顯示摘要：
- 部署環境：[正式/測試]
- 部署版本：[git SHA]
- 測試結果：[通過/失敗]
- 狀態：[成功/失敗]
Code language: CSS (css)指定你想看到什麼資訊，Claude 就會照格式給你。
實戰：建立自訂的 /deploy 命令
讓我們動手寫一個完整的自訂命令。
第一步：建立檔案
# 確保 commands 目錄存在
mkdir -p .claude/commands
# 建立 deploy 命令檔案
touch .claude/commands/deploy.md
Code language: PHP (php)第二步：撰寫命令內容
把以下內容寫入 .claude/commands/deploy.md：
# Deploy 部署流程
執行完整的部署前檢查與部署流程。
## 前置檢查
1. 執行所有測試：
- 跑 `npm test`（或專案對應的測試命令）
- 如果有任何測試失敗，停止流程並回報失敗的測試
2. 檢查 git 狀態：
- 執行 `git status`
- 如果有未提交的修改，列出檔案並提醒使用者先提交
- 如果有未推送的 commit，提醒使用者先推送
3. 檢查建構：
- 執行 `npm run build`（或專案對應的建構命令）
- 如果建構失敗，停止並回報錯誤
## 部署確認
通過所有檢查後，顯示以下摘要並等待使用者確認：
- 部署分支：[當前分支名稱]
- 最新 commit：[commit SHA 與訊息]
- 測試結果：全部通過（N 個測試）
- 建構狀態：成功
**必須等待使用者輸入「確認」才能繼續。**
## 執行部署
使用者確認後：
1. 執行部署命令（依專案設定）
2. 等待部署完成
3. 回報部署結果
## 部署後檢查
1. 確認服務正常運行
2. 顯示最終報告：
- 部署時間
- 部署版本
- 服務狀態
Code language: PHP (php)第三步：使用命令
# 在 Claude Code 中直接輸入
/deploy
Code language: PHP (php)Claude 就會按照你寫的流程，逐步執行部署前檢查、等你確認、然後部署。
進階用法：帶參數的命令
你的命令 Markdown 裡可以使用 $ARGUMENTS 佔位符來接收參數：
# Migrate 資料庫遷移
對目標環境執行資料庫遷移。
目標環境：$ARGUMENTS
1. 確認目標環境是 staging 或 production
2. 如果是 production，額外確認一次
3. 備份當前資料庫
4. 執行遷移腳本
5. 驗證遷移結果
Code language: PHP (php)使用方式：
/migrate staging → $ARGUMENTS 會被替換為 "staging"
/migrate production → $ARGUMENTS 會被替換為 "production"
Code language: PHP (php)Vibe Coder 檢查點
看到專案裡的 Commands 設定時，確認這些事：
- [ ]
commands/目錄在.claude/底下嗎？（正確路徑是.claude/commands/） - [ ] 每個
.md檔案有沒有明確的步驟？（模糊的指令會讓 Claude 自由發揮） - [ ] 有沒有定義「停止條件」？（避免 Claude 自作主張）
- [ ] 關鍵操作前有沒有「等待確認」？（特別是部署、刪除等破壞性操作）
- [ ] 命令名稱直覺嗎？（團隊成員看到
/deploy就知道是部署）
常見問題
Q：Commands 跟在對話裡直接打指令有什麼差別？
直接打指令：每次都要重新描述你要什麼，Claude 可能每次理解不同。 用 Commands：步驟固定、結果一致、團隊共用。就像把常用操作錄製成巨集。
Q：Commands 可以互相呼叫嗎？
可以。例如 /orchestrate 命令就是依序呼叫 /plan → /tdd → /code-review 的工作流。你可以在命令裡寫「完成後執行 /verify」來串接命令。
Q：命令寫得太簡單或太複雜會怎樣？
太簡單（只寫「部署專案」）：Claude 會自己決定怎麼做，結果不可預測。 太複雜（寫了 200 行指令）：Claude 可能會遺漏中間步驟。 建議：每個命令控制在 5-15 個步驟，太長就拆成多個命令。
本篇重點回顧
| 概念 | 一句話 |
|---|---|
| Commands 是什麼 | 放在 .claude/commands/ 的 .md 檔案，輸入 /檔名 就能觸發 |
| 跟 Rules 的差別 | Rules 自動生效，Commands 手動觸發 |
| 命名規則 | 檔名就是命令名，用連字號分隔 |
| 怎麼寫命令 | 用 Markdown 寫步驟，加上停止條件和確認點 |
| 帶參數 | 用 $ARGUMENTS 佔位符接收使用者輸入 |
下一步
你已經學會了用 Rules 設定被動規則、用 Commands 建立主動工作流。下一篇，我們將深入探討 Claude Code 的 MCP（Model Context Protocol）整合——讓 Claude 連接外部工具和服務，進一步擴展它的能力。
進階測驗：Commands 自訂斜線命令
共 5 題，包含情境題與錯誤診斷題。