Slash Command：給 Claude Code 裝上可複用的快捷指令

Claude Code 內建了一批 slash command——/help、/clear、/compact。但真正讓工作流提速的，是你自己寫的那些。

本文講的是如何設計一套可複用的 slash command 體系，讓團隊裡每個人都能用上同一套提示詞，而不是每次靠記憶重新描述任務。

什麼是自定義 Slash Command

在 Claude Code 裡，自定義 slash command 就是一個 Markdown 檔案。你把它放在指定目錄，Claude Code 啟動時自動識別，輸入 /檔案名 即可觸發。

檔案內容就是發給 Claude 的提示詞。僅此而已。

沒有特殊語法，沒有設定格式，一個 .md 檔案就是一個 command。

檔案放哪裡

兩個位置，職責不同：

位置	路徑	作用域
專案級	.claude/commands/	僅當前專案，可隨程式碼提交 git
使用者級	~/.claude/commands/	所有專案，個人私有

專案級是團隊共享的核心。把 .claude/commands/ 提交進 git，clone 倉庫的每個人都自動擁有這套 commands。

使用者級適合放個人習慣類的指令，比如你自己偏好的程式碼風格檢查方式，或者只有你在用的工具整合。

建立第一個 Command

在專案根目錄：

mkdir -p .claude/commands

新建 .claude/commands/review.md：

審查當前改動的程式碼品質。重點檢查：

1. 邏輯錯誤和邊界條件
2. 命名是否清晰
3. 有沒有重複程式碼可以提取
4. 安全問題（SQL 注入、XSS、敏感資訊暴露）

給出具體的修改建議，不要泛泛而談。

重啟 Claude Code，輸入 /review 即可觸發。

用 $ARGUMENTS 接收參數

固定內容的 command 用途有限。$ARGUMENTS 讓 command 變得靈活——使用者在 /command 後面輸入的內容，會替換進提示詞裡。

例如 .claude/commands/test.md：

為以下內容編寫測試：$ARGUMENTS

要求：
- 覆蓋正常路徑和邊界情況
- 測試命名要能自解釋
- 不要 mock 能用真實資料的地方

使用時：

/test UserAuthentication 類別的 login 方法

Claude 收到的實際提示詞是：

為以下內容編寫測試：UserAuthentication 類別的 login 方法

要求：
- 覆蓋正常路徑和邊界情況
...

$ARGUMENTS 可以出現在提示詞的任何位置，也可以出現多次。

設計原則

一個 command，一個職責

不要寫一個「萬能助手」command，把所有任務塞進去。/review 只管程式碼審查，/test 只管寫測試，/pr 只管產生 PR 描述。粒度細的 command 更容易記憶，也更容易複用。

提示詞寫具體，不寫抽象

壞的寫法：

幫我優化這段程式碼


好的寫法：
```
優化以下程式碼的效能。優先考慮：
1. 減少不必要的資料庫查詢（N+1 問題）
2. 避免在迴圈裡做重複計算
3. 用更高效的資料結構替換線性查找

保持介面不變，只改內部實作。
```

具體的約束條件，才能讓 Claude 給出有針對性的結果。

給 command 加 frontmatter

在檔案開頭加上元資料，Claude Code 在命令列表裡會顯示 description，方便團隊成員快速了解用途：

---
description: 審查當前改動，給出程式碼品質反饋
---

審查當前改動的程式碼品質...

一套實用的專案級 Commands

以 Rails 專案為例，這幾個 command 覆蓋了日常開發的高頻場景：

.claude/commands/review.md — 程式碼審查

```markdown

description: 審查當前改動，檢查邏輯、安全和可讀性

審查 git diff 裡的改動。檢查：
- 邏輯錯誤和邊界條件處理
- SQL 注入、權限校驗等安全問題
- 命名可讀性
- 是否有重複邏輯可以提取

每條問題給出具體位置和修改建議。
```

.claude/commands/test.md — 產生測試

```markdown

description: 為指定程式碼產生測試案例

為這段程式碼寫測試：$ARGUMENTS

使用 RSpec。覆蓋：正常路徑、邊界值、異常情況。
測試命名格式：describe ... context ... it ...
優先用真實物件，只在必要時 mock 外部依賴。
```

.claude/commands/pr.md — PR 描述

```markdown

description: 根據當前改動產生 PR 標題和描述

根據 git diff 和 commit log，產生 PR 描述。

格式：

改動內容

（簡述做了什麼，2-3 句）

為什麼這樣改

（背景和動機）

測試方式

（如何驗證這次改動）

語氣簡潔，面向 code reviewer。
```

.claude/commands/explain.md — 解釋程式碼

```markdown

description: 解釋指定檔案或函式的作用

解釋 $ARGUMENTS 的作用：
- 整體職責是什麼
- 關鍵邏輯怎麼運作
- 有哪些值得注意的邊界情況

面向剛接手這部分程式碼的開發者，說清楚「為什麼」而不只是「做了什麼」。
```

使用者級 Commands：個人工作流程

有些習慣是個人的，不適合強加給整個團隊。放在 ~/.claude/commands/ 裡：

~/.claude/commands/standup.md — 晨會準備
```markdown
根據今天的 git log 和未關閉的 TODO，整理一份晨會摘要：
- 昨天完成了什麼
- 今天計畫做什麼
- 有沒有阻塞項

控制在 5 句話以內。
```

~/.claude/commands/refactor.md — 重構建議
```markdown
分析 $ARGUMENTS，給出重構建議。

只提真正有價值的改動，不要為了重構而重構。
每條建議說明：能解決什麼問題、改動量大不大、風險如何。
```

團隊推廣的關鍵：放進 git

自定義 command 最大的價值不在於個人提效，而在於讓團隊形成共同語言。

把 .claude/commands/ 提交進程式碼庫，在 README 或 CLAUDE.md 裡列出可用的 commands 和用途。新人 clone 倉庫後，直接就有了團隊積累的提示詞資產，不需要各自摸索。

隨著專案演進，commands 也會迭代——發現某個提示詞效果不好，改一行提交上去，全團隊生效。這是提示詞工程在團隊層面落地的最低成本方式。

目錄結構參考

.claude/
├── commands/
│   ├── review.md      # 程式碼審查
│   ├── test.md        # 產生測試
│   ├── pr.md          # PR 描述
│   └── explain.md     # 解釋程式碼
└── settings.json