然而，實戰中最高頻發生的痛點往往不是「規格怎麼寫」，而是： 「開發到一半，發現之前的規格寫錯了，或者程式改了但規格沒跟上」。
當程式碼（Code）與規格書（Specs）產生落差，文件就變成了「廢紙」，技術債也隨之而來，本篇將進入更深層的技術細節，教你如何利用 Claude Code 的 Commands 功能，建立一套自動化機制：
在修復 Bug 或調整配置的同時，強迫 AI 回頭修正過時的規格文件。
🛠️ 核心思路：建立「同步回修」的指令樣版
Claude Code 允許我們自定義指令（Commands），我的做法是在專案中建立 .claude/commands/fix-bug.md，這不僅是一個指令，更是一份執行標準（SOP）。
定義指令樣版：.claude/commands/fix-bug.md
## 任務目標
修復以下問題：$ARGUMENTS
## 執行流程
1. **分析影響範圍**：掃描並找出與此變動相關的 `specs/`、`docs/` 或測試檔案。
2. **同步更新**：在修復程式碼的同時，必須同步回修對應的規格文件。
## 完成後請確認：
### 💻 程式碼修正
- [ ] 實際的邏輯修正或配置調整。
### 📄 文件與測試同步 (回修重點)
- [ ] **Specs 文件**：確認規格是否已根據最新異動完成更新？
- [ ] **測試案例**：測試代碼是否已同步修改或新增？
- [ ] **專案文檔**：Charter 或 README 是否有過時資訊需要同步？
🚀 實戰示範：當開發需求變更時
假設在開發階段，我們發現原本的 compose.yaml 漏了資料庫管理工具，這時我們不需要手動改完代碼再去翻 spec 檔案，直接下達指令：
/fix-bug @compose.yaml 在開發階段應該要有 adminer:5.4.1 來讓開發者查看資料庫內容。
AI 會幫你做什麼？
💡 為什麼這個做法能解決「規格失效」？
這套流程的核心在於「強制關聯」，很多開發者會習慣先改 Code，「等一下再補文件」，但那個「等一下」通常永遠不會到來。透過 .claude/commands，我們將「修改文件」定義為「完成修復」的必要條件。
• 減少認知負擔：你不必回憶這項改動影響了哪些 spec 檔案，AI 比你更擅長跨檔案檢索。
• 確保真理來源一致：透過 @檔案 提及功能，讓 AI 在 Context 中同時處理代碼與文檔。
• 預防測試斷層：當規格回修後，測試案例也會被要求同步，這讓整個開發循環（Spec -> Code -> Test）保持閉環。
結語
在使用 AI 輔助開發的時代，我們追求的不只是「寫得快」，更是「寫得準」。透過 Claude Code 的指令樣版，我們可以讓 spec-kit 不再只是起跑時的藍圖，而是隨著專案生命週期自動演進的活文件。
如果你也正受困於「文實不符」的窘境，不妨試試這套 /fix-bug 樣版！
