# 策展 · X (Twitter) 🔥🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：rody (@0x_rody) · 平台：X (Twitter) · 日期：2026-06-08

> 原始來源：https://x.com/0x_rody/status/2063549084695158936

## 中文摘要

# 如何建立 Claude Code Slash Command 函式庫（內附精確模板）

你每週有 20 次都在對 Claude Code 輸入同樣的 30 秒指令。

這意味著你每個月大約花了 10 個小時在重複輸入那些本該只需一個指令就能搞定的情境。

大多數開發者從未設定過捷徑系統，因為他們覺得這很複雜。其實一點也不。

以下是解決這個問題的完整模板👇

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780886669784-iaHKMrmNoW4AAs5ARjpg.jpg)

## 什麼是 Slash Command（斜線指令）

Slash Command 本質上就是存放在單一檔案中的預設 Prompt。當你輸入 `/review` 時，Claude 會將該檔案載入為 Prompt，並帶入你輸入的任何參數來執行。

概念就是這麼簡單。不需要 plugin、不需要建置步驟、也不需要註冊表。就只是資料夾裡的 Markdown 檔案而已。

有兩個位置很重要：

```
~/.claude/commands/       ← 全域，適用於每個專案
.claude/commands/         ← 專案專屬，提交到 git 以供團隊使用
```

檔案名稱即為指令名稱。`review.md` 會變成 `/review`。子資料夾則會變成命名空間：`.claude/commands/team/review.md` 會變成 `/team:review`。

## 基礎模板

每個 Slash Command 都遵循相同的結構：頂部是 YAML frontmatter，下方則是 Prompt 本體。

```yaml
---
description: 顯示在 /help 中的單行摘要
argument-hint: <參數格式說明>
allowed-tools: Read, Grep, Glob, Bash
model: sonnet
---

Prompt 本體寫在這裡。使用 $ARGUMENTS 來插入使用者在指令名稱後輸入的所有內容。使用 $1, $2, $3 來代表位置參數。
```

每個 frontmatter 欄位都是選填的，但 `description` 最為重要。這是 Claude 用來判斷該選哪個指令的依據，也是當你輸入 `/` 時選單中顯示的內容。

`allowed-tools` 用來限制指令能做的事。限制越嚴格，指令執行起來就越快、越安全。文件更新工具不需要 Bash，程式碼審查工具也不需要 Write 權限。

`model` 是選填的。日常工作用 `haiku`，大多數任務用 `sonnet`，需要安全性與複雜推理時則用 `opus`。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780886669759-iaHKMwxMqWAAEaWYXjpg.jpg)

## 7 個即刻可用的指令

將以下任何一個指令放入 `.claude/commands/{name}.md` 即可使用。

## 1. /review

```yaml
---
description: 審查目前的 diff 以檢查 Bug、安全性與風格問題
argument-hint: [選填：檔案或 commit 範圍]
allowed-tools: Read, Grep, Glob, Bash(git diff:*, git log:*)
model: sonnet
---

你是一位擁有 15 年生產系統開發經驗的資深程式碼審查員。

審查以下變更：
- 若提供了 $ARGUMENTS，請審查 `git diff $ARGUMENTS`
- 否則，請審查 `git diff HEAD`

重點關注：
1. 作者遺漏的 Bug 與邊緣案例
2. 安全性問題（注入攻擊、身分驗證繞過、暴露的機密資訊）
3. 效能回退
4. 對公開 API 的破壞性變更

輸出格式：
- Critical (必須修正)：file:line 以及一句話的修正建議
- Important (建議修正)：同上格式
- Nitpicks (選填)：同上格式

絕不批准帶有 Critical 問題的程式碼。請直接了當，不要說「考慮重構」這種模糊的話。
```

## 2. /test

```yaml
---
description: 為接下來的檔案或函式撰寫測試
argument-hint: <檔案或函式名稱>
allowed-tools: Read, Write, Edit, Bash
model: sonnet
---

為以下目標撰寫測試：$ARGUMENTS

步驟：
1. 讀取目標檔案並識別所有分支、邊緣案例與錯誤路徑
2. 讀取現有的測試檔案以了解慣例，並與其保持一致
3. 撰寫在實作錯誤時會失敗的測試，而不是只會複製實作邏輯的測試

優先順序：邊緣案例 > 錯誤路徑 > 正常路徑。跳過瑣碎的 getter/setter 測試。
撰寫完成後執行測試套件以確認一切通過。
```

## 3. /migrate

```yaml
---
description: 將程式碼從一種模式、函式庫或版本遷移到另一種
argument-hint: <從> 到 <到> (例如 "axios to fetch")
allowed-tools: Read, Edit, Grep, Glob, Bash
model: sonnet
---

遷移任務：$ARGUMENTS

步驟：
1. 使用 Grep 找出所有使用舊模式的檔案
2. 先列出檔案清單。在進行任何變更前，先向我展示計畫。
3. 經批准後，一次編輯一個檔案。每次編輯後執行測試套件。
4. 如果測試失敗，請停止並解釋發生了什麼事。

絕不要進行批次搜尋並取代。每個檔案都需要獨立的情境。
```

## 4. /audit

```yaml
---
description: 對後續的檔案或路徑進行安全性審計
argument-hint: <檔案或路徑>
allowed-tools: Read, Grep, Glob, Bash
model: opus
---

審計目標：$ARGUMENTS

檢查項目：
- 硬編碼的機密資訊、API 金鑰、憑證
- SQL 注入、指令注入、路徑遍歷
- 身分驗證繞過、缺少權限檢查、IDOR
- 未經驗證的使用者輸入流入危險的接收端 (sinks)
- 機密資訊被記錄在日誌中、在錯誤訊息中回傳，或發送給第三方

輸出每項發現，包含：
- file:line
- 嚴重程度 (critical/high/medium)
- 一句話描述攻擊情境
- 一句話描述修正方式

保持警覺。假設輸入內容皆帶有惡意。
```

## 5. /doc

```yaml
---
description: 更新文件以符合目前的程式碼
argument-hint: [選填：路徑]
allowed-tools: Read, Edit, Grep, Glob, Bash(git diff:*)
model: haiku
---

更新文件以符合以下程式碼變更：$ARGUMENTS (預設為目前的 diff)

步驟：
1. 執行 `git diff` 查看變更內容
2. 搜尋 docs 資料夾與 README 中對變更符號的參照
3. 僅更新那些已經過時的章節
4. 不要重寫、重構或「優化」其他任何內容

如果某個功能完全沒有文件，請標記出來。除非被要求，否則不要建立新的文件檔案。
```

## 6. /triage

```yaml
---
description: 對 Bug 回報或 Issue 進行分類處理
argument-hint: <Issue 描述或連結>
allowed-tools: Read, Grep, Glob, Bash
model: sonnet
---

待處理的 Bug：$ARGUMENTS

步驟：
1. 閱讀 Issue。提取：預期行為、實際行為、重現步驟。
2. 若可能，嘗試在本地重現。
3. 識別 Bug 所在的檔案與可能的行數。
4. 評估嚴重程度：critical / high / medium / low
5. 建議修正方向。暫時不要撰寫修正程式碼。

輸出：
- 一句話描述根本原因
- 受影響的 file:line
- 嚴重程度與理由
- 1-3 點條列式的建議修正方案
```

## 7. /refactor

```yaml
---
description: 以安全第一的方式重構目標
argument-hint: <檔案或函式> [目標]
allowed-tools: Read, Edit, Bash
model: sonnet
---

重構目標：$ARGUMENTS

規則：
1. 先進入計畫模式。在進行任何編輯前，先向我展示計畫。
2. 未經詢問，絕不觸碰明確目標以外的程式碼。
3. 重構前先執行測試以取得基準。
4. 每次變更後都執行測試。
5. 如果測試失敗，請停止並解釋。未經我批准，不得繼續。

目標：維持行為不變，提升可讀性與可維護性。
如果無法在不改變行為的情況下做到，請停止並詢問。
```

## 如何呼叫這些指令

有三種方式：

輸入 `/`，Claude 會顯示包含描述的完整選單。選擇一個，自動完成功能會填寫剩餘部分。

直接輸入完整指令：`/review` 或 `/audit src/api/auth.ts`。參數接在空格之後。

對於子資料夾中的命名空間指令：`/team:review` 會執行 `.claude/commands/team/review.md`。

參數會以 `$ARGUMENTS` 形式傳入整個字串，或是以 `$1, $2, $3` 傳入位置參數。因此，`/migrate axios to fetch` 會得到 `$1=axios`, `$2=to`, `$3=fetch`，而 `$ARGUMENTS="axios to fetch"`。

## 毀掉你 Slash Command 的常見錯誤

描述太模糊。「Review code」無法告訴 Claude 何時該使用它。「Review the current diff for bugs, security, and style issues」才是你想要的。

`allowed-tools` 設定太寬鬆。如果你沒有列出工具清單，指令會繼承所有權限。這對於受信任的指令沒問題，但對於會觸及敏感路徑或執行 Shell 指令的指令，請務必嚴格限制範圍。

誤用 `$1` 而非 `$ARGUMENTS`。`$1` 僅代表第一個以空格分隔的 token。如果你需要整個參數字串，請使用 `$ARGUMENTS`。

位置錯誤。專案指令放在 `.claude/commands/`，全域指令放在 `~/.claude/commands/`。放錯位置就無法顯示。

沒有將專案指令提交到 git。`.claude/commands/` 應該包含在你的 repo 中。這樣你的隊友在 clone 專案的同時，就能獲得相同的捷徑。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780886669790-iaHKMxwqjXUAA77itjpg.jpg)

## 15 分鐘快速上手

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780886670033-ediaHKMxzdWMAAgrRjpg.jpg)

3 分鐘：挑選一個你每週會做 5 次以上的任務。複製上面的對應模板。

3 分鐘：針對你的技術堆疊調整 Prompt。包含你的測試框架、Linter、以及開發慣例。

2 分鐘：儲存為 `.claude/commands/{name}.md`。

2 分鐘：在實際任務上執行一次以確認運作正常。

5 分鐘：建立下一個指令。

完成。用一個專屬指令取代重複輸入的 Prompt。每天建立一個，一週後你就會有 7 個指令處理 80% 的日常工作，而那些你過去每次都要重新輸入的長指令，現在只需按一下鍵就能完成。

感謝閱讀！

我會在我的 Telegram 頻道分享關於 AI、金融與 vibe coding 的每日筆記：https://t.me/zodchixquant

## 標籤

Claude Code, CLI, 教學資源, 自動化, Anthropic, Claude