Claude Code 自訂 Slash Commands：打造你的專屬 AI 工作流
如果你還不熟悉 CLAUDE.md 或 Claude Code 的基本設定，建議先閱讀： 📖 打造 AI 友善的專案文檔：CLAUDE.md 完整指南（上） 📖 Claude Code 權限控管：用 settings.local.json 保護你的專案
🎯 前言
用 Claude Code 一段時間後，你會發現一個問題：每次開始新任務，都要重複下達同樣的指示。
「先別急著改 code，先問我問題」「commit 的時候不要加 Co-Authored-By」「分析之前先探索 codebase」——這些話我說過幾十次。
Claude Code 的 Custom Slash Commands（自訂斜線指令）正是解決這個問題的方式。你只需要寫一個 Markdown 檔案，定義好流程，之後只要打 /interview 或 /commit，Claude 就會照著你設計的劇本走。
這篇文章分享我在 AppSystem 專案中實際使用的幾個自訂指令，其中 /interview（需求訪談模式）是最核心的一個。
📂 自訂指令的基本結構
Custom Slash Commands 存放在專案的 .claude/commands/ 目錄中：
.claude/
└── commands/
├── interview.md ← /interview
├── commit.md ← /commit
├── ultra-think.md ← /ultra-think
└── reset.md ← /reset規則很簡單：
- 每個
.md檔案就是一個指令 - 檔名就是指令名稱（
interview.md→/interview） - 檔案內容就是 Claude 收到的 prompt
基本格式
---
description: 指令的簡短描述（顯示在指令列表中）
argument-hint: [可選參數的提示文字]
---
# 指令標題
這裡寫你要 Claude 執行的完整指示...$ARGUMENTS 變數會自動替換為使用者在指令後面輸入的內容。例如 /interview 我想優化查詢效能，其中「我想優化查詢效能」就是 $ARGUMENTS。
🎤 核心指令：/interview（需求訪談模式）
這是我最常用、也最推薦的自訂指令。它解決了一個根本問題：Claude 太急著動手。
沒有 /interview 的時候，對話通常是這樣的：
我：我想加一個匯出功能
Claude：好的，我來幫你實作！[直接開始寫 code]
我：等等，我還沒說要匯出什麼格式...
Claude：抱歉，讓我重新來...有了 /interview，Claude 會被迫先做完整的需求釐清，再探索 codebase，最後才提出執行計畫。
/interview 的完整設計
---
description: Interview Mode (project)
argument-hint: [optional context or specific area to focus on]
---
# Interview Mode
當進入此模式時，執行以下流程：
## 階段一：問題收集
一次列出核心問題，讓用戶回答：
🎤 Interview
請回答以下問題（可以簡答，我會追問細節）：
1. **Why** - 為什麼要做這個？想解決什麼問題？
2. **What** - 具體要做什麼？範圍包含哪些？
3. **How** - 有偏好的做法或技術限制嗎？
4. **Edge cases** - 有需要特別處理的例外情況嗎？
**如果用戶提供了 $ARGUMENTS**，
將其作為初始上下文，但仍然要問完整的 4 個問題來確保理解完整。
## 階段二：動態追問 + 自主探索
### A. 追問模糊點（最多 3 輪）
根據用戶回答，針對模糊或不完整的部分追問：
- 如果範圍不清楚 → 追問具體檔案或模組
- 如果做法不明 → 提供 2-3 個選項讓用戶選擇
- 如果有潛在風險 → 主動提醒並確認
- 如果用戶回答「不確定」「你決定」→ 說明建議方案並確認
**追問規則**：
- 一次只問一個重點，保持簡短
- 如果用戶明確說「就這樣」「開始吧」→ 停止追問，進入探索
### B. 自主探索 codebase（關鍵增強）
告知用戶：「讓我先探索一下相關的程式碼...」
**使用工具理解現況**：
1. **Glob** - 找出相關檔案
2. **Grep** - 搜尋關鍵字或模式
3. **Read** - 讀取關鍵檔案理解邏輯
**探索重點**：
- 找出會被影響的檔案
- 理解現有實作方式
- 發現潛在衝突或依賴
- 確認是否有現成可用的 pattern
## 階段三：生成詳細計劃
基於問答 + 探索結果，整理成結構化計劃：
📋 執行計劃
## 目標
{一句話描述目標}
## 現況分析（探索發現）
- 相關檔案：{列出關鍵檔案}
- 現有機制：{簡述現有實作}
- 潛在影響：{列出會影響的地方}
## 執行步驟
1. **{動作}** ({影響範圍})
- {具體改動}
## 影響範圍
- {檔案列表，附行號或函數名}
## 風險提醒
- {如有潛在風險列出，沒有就省略}
## 驗證方式
- {如何確認改動成功}
---
確認執行？回覆「確認」開始，或告訴我要調整的地方。
## 階段四：執行
用戶確認後：
1. 依序執行每個步驟
2. 每完成一步，標記進度
3. 全部完成後，簡短總結改動四個核心設計原則
| 原則 | 說明 |
|---|---|
| 不進入 Plan Mode | /interview 本身就整合了規劃能力，確認後直接執行 |
| 探索與執行分離 | 階段二只讀不改，階段四才真正動手 |
| 保持計劃一致性 | 執行中遇到計劃外的歧義會暫停再問，不偷偷多做或少做 |
| 工具分階段使用 | 探索階段用 Glob/Grep/Read；執行階段才用 Edit/Write/Bash |
實際使用範例
# 直接進入訪談模式
/interview
# 帶上下文
/interview 我想優化資料庫查詢效能
# 針對特定功能
/interview 新增使用者權限管理功能一個典型的完整流程：
我：/interview 優化登入查詢效能
Claude：🎤 Interview
請回答以下問題：
1. Why: 為什麼要做這個？
2. What: 具體範圍？
3. How: 偏好做法？
4. Edge cases: 例外情況？
我：
1. 登入太慢，使用者抱怨
2. 優化 auth.php 的查詢
3. 不確定
4. 要保持現有功能
Claude：讓我先探索一下相關的程式碼...
（使用 Glob 找出 auth*.php）
（使用 Read 讀取 auth.php）
發現：使用 SELECT *、無 index、無快取
📋 執行計劃
## 目標
優化登入查詢效能
## 現況分析
- 相關檔案：AppSystem/class/auth.php
- 現有機制：SELECT * FROM users，無快取
## 執行步驟
1. 修改查詢語句（auth.php:45）
- SELECT * 改為只查必要欄位
2. 新增快取機制
- 使用 Session 快取 5 分鐘
確認執行？
我：確認
Claude：（開始按步驟執行）
✓ 完成為什麼 /interview 比直接下指令好？
| 場景 | 直接下指令 | 用 /interview |
|---|---|---|
| 需求明確 | 可以直接做 | 過程稍長，但更安全 |
| 需求模糊 | Claude 猜測 → 返工 | 先釐清再做 → 一次到位 |
| 複雜任務 | 容易遺漏細節 | 結構化拆解，不遺漏 |
| 跨模組修改 | 可能漏改某個檔案 | 探索階段找出所有相關檔案 |
我的經驗：大約 70% 的任務用 /interview 會更有效率。剩下 30% 是很明確的小修改（修 typo、改一個 CSS），直接說就好。
🔧 其他實用的自訂指令
/commit：安全的 Git 提交流程
團隊有自己的 commit message 格式？寫成指令就不用每次提醒：
# Commit - 安全的 git commit 流程
執行以下步驟：
1. 執行 `git status` 查看狀態
2. 執行 `git diff` 查看未暫存的改動
3. 執行 `git diff --cached` 查看已暫存的改動
4. 如果沒有暫存改動，詢問要暫存哪些檔案
5. **詢問用戶 issue 編號**（例如：001）
6. 根據改動內容生成 commit message，格式：
issue-{編號} {改動描述}
7. 顯示完整 commit message 讓用戶確認
8. 用戶確認後執行 `git commit`
## 規則
- **不要** 加 Co-Authored-By
- **不要** 加 Generated with Claude Code
- **不要** 自動 push
- commit message 第一行必須是 `issue-{編號}` 開頭
- 如果用戶沒有提供編號，必須詢問效果：打 /commit 就好，Claude 會自動走完整個流程，還會遵守你的 commit message 格式。
/reset：重置安全狀態
如果你有用 hooks 做安全檢查（例如追蹤修改檔案數量），有時候需要重置狀態：
# Reset - 重置 safety hooks 狀態
清空 `.claude/hooks/state.json` 的追蹤資料。
## 會重置的內容
- 已修改檔案列表
- 已確認的操作記錄
- 錯誤計數
## 不會影響的內容
- hooks 規則本身
- Git 狀態
## 執行
執行 Python 腳本刪除 state.json，完成後告知用戶。簡短、明確、一次性任務——完美的指令候選。
/ultra-think：深度分析模式
遇到架構決策或複雜問題時，讓 Claude 從多個角度深入分析：
---
description: Deep analysis and problem solving
argument-hint: [problem or question to analyze]
---
# Deep Analysis Mode
1. **多維度分析**
- 技術面：可行性、效能、可維護性
- 業務面：價值、時程、風險
- 使用者面：需求、體驗、邊界情況
2. **產生多個方案**（至少 3 個）
- 每個方案列出優缺點
- 包含實作複雜度和風險評估
3. **挑戰與精煉**
- 用魔鬼代言人的角度質疑每個方案
- 考慮二階效應（改 A 會不會影響 B？）
4. **結構化建議**
- 推薦方案 + 理由
- 實作路線圖
- 風險緩解策略使用場景：
/ultra-think 我們應該繼續用 MySQL 5.7 還是遷移到 8.0？
/ultra-think 多租戶架構要不要改成 schema-per-tenant？💡 設計自訂指令的技巧
技巧 1：明確定義「不要做什麼」
## 規則
- **不要** 自動 push（讓用戶自己決定）
- **不要** 修改不相關的檔案
- **不要** 跳過確認步驟「不要做什麼」往往比「要做什麼」更重要。Claude 很容易「好心辦壞事」，明確的禁止清單能有效防止。
技巧 2：分階段，而非一次全做
## 階段一：分析（只讀）
...
## 階段二：計劃（輸出但不執行）
...
## 階段三：執行（用戶確認後才開始）
...分階段設計讓你在每個階段都有機會介入和修正方向。
技巧 3：善用 $ARGUMENTS 做條件分支
**如果用戶提供了 $ARGUMENTS**：
- 將其作為初始上下文
- 但仍然要問確認問題
**如果沒有 $ARGUMENTS**：
- 從頭開始問技巧 4：指定工具使用規則
## 探索階段的工具使用
- ✅ 使用 Glob、Grep、Read
- ❌ 不要使用 Edit、Write、Bash
## 執行階段的工具使用
- ✅ 使用 Edit、Write、Bash
- ❌ 不要使用 Bash 執行破壞性指令技巧 5：定義輸出格式
發現問題時，用以下格式輸出：
| 檔案 | 行號 | 問題 | 建議 |
|------|------|------|------|
| ... | ... | ... | ... |統一的輸出格式讓結果更容易審閱和追蹤。
📋 我的指令清單總覽
| 指令 | 用途 | 使用頻率 |
|---|---|---|
/interview | 需求訪談 → 探索 → 計劃 → 執行 | 每天 |
/commit | 安全的 git 提交流程 | 每天 |
/ultra-think | 深度分析複雜問題 | 每週 |
/reset | 重置 hooks 安全狀態 | 偶爾 |
🎉 結語
自訂 Slash Commands 的本質是把你的「工作流程」變成可重複執行的劇本。
與其每次都告訴 Claude「先問我問題再動手」、「commit 要用 issue 編號開頭」，不如寫一次，之後只要打一個 / 就好。
我的建議：先從 /interview 開始。這個指令能解決最大的痛點——Claude 太急著動手。用了一段時間後，你會自然發現哪些流程值得再包裝成指令。
指令不需要一開始就很完美。先寫一個粗略版本，用幾次後根據實際體驗迭代修改，就會越來越順手。
📎 相關文章：