# SDD 導入團隊這件事，我最近一直在想 工具怎麼用不是最難的，難的是這個： AI 只會做**內部邏輯對齊**——它會自動腦補，讓規格看起來無懈可擊，卻和現實完全對不上。 不成文的商業規則、使用者真實的操作習慣、系統現在的限制——這些 AI 不會問你，它會自己填。所以審核規格的能力，不是「看懂文件」，而是**用你腦袋裡的現實去跑一遍，看哪裡卡住**。 測試案例也是同一個問題。測試和規格一起偏離現實，兩個同樣錯——覆蓋率漂亮，上線還是災難。 這件事很難教，但我認為這才是 SDD 真正的核心。 --- ## 為什麼我們需要 SDD？ 現在 RD 都在用 AI 開發，但有兩個問題一直困擾我： 第一，AI 產出太快，Code Review loading 會被瞬間拉爆。最後一道防線變成瓶頸。 第二，A 同事用 AI 開發完某個功能，B 同事今天要修改，他沒有參與當初的開發，難道直接叫 AI 自己去看然後就改？我是會怕。你得先搞清楚技術細節，才知道怎麼下提示詞——但細節在哪裡？ SDD 的核心解法就是：**先定義清晰的規格，再進行實作，而且規格要留存下來。** 這樣即便要改別人做的功能，AI 也能讀這份規格獲得上下文，你也可以透過文件先理解細節再動手。 --- ## 我最近在用 OpenSpec，流程大概長這樣 工具裝好之後（細節去看 [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec)），就三個指令： ``` /opsx:new 產生規格 /opsx:apply 執行 task /opsx:archive 歸檔 ``` 產出的規格大概這些檔案： ``` proposal.md — 為什麼做、改了什麼 specs/ — 需求與情境 design.md — 技術方向 tasks.md — 實作清單 ``` ### 我實際跑一次的過程是這樣： 先開 Claude CLI，把任務細節說清楚——我要做什麼 API、有哪些驗證、資料結構長怎樣，有想討論的就先問 AI 再決定。說完之後 `/opsx:new` 產出 `proposal.md`。 掃過一遍確認沒問題，`/opsx:continue` 繼續產 `design.md`。這時候我發現有些內容不夠，就請它一起修正 proposal + design，補上我要的細節。 接著產 `specs.md`——它是 BDD 格式（Given / When / Then），把需求和情境都寫清楚了，例如： ``` ### 需求：建立訂單時對商品執行庫存凍結 #### 情境：庫存充足，凍結成功 - WHEN Inventory.Available >= 請求的 Quantity - THEN Inventory.Available 減少 Quantity - THEN Inventory.Reserved 增加 Quantity #### 情境：庫存不足 - WHEN Inventory.Available < 請求的 Quantity - THEN 系統回傳庫存不足錯誤 - THEN 不寫入任何 Order 紀錄 ``` **這一步是最重要的。** 我會仔細確認所有情境是否符合我真正想保護的地方，不夠就叫它補，直到對齊我的現實認知為止。 確認 specs 沒問題，產 `tasks.md`，掃過一遍，就切換去 Copilot 叫它按照 tasks + 規格產 code（它也會讀 `copilot-instructions` 理解專案 code style），基本上 one shot 就能完成。 然後我回到 Claude 繼續討論下一份規格，Claude 燒完燒 Copilot，兩個輪著用。 > 💡 **小訣竅**：Claude CLI 是按 token 計費，適合長時間討論規格；Copilot 是按 request 計費，適合一次性執行任務。兩個輪著用，成本控制和效率都到位。 最後 `/opsx:archive` 把完成的規格收好。 --- ## 目前的感想 這個工作模式，我覺得還不錯。 還在多多練習，感覺練熟之後就可以定義出一套穩定的 RD 開發流程——不只是自己用，而是整個團隊都能照著走，產出也會穩定很多。 最難的還是那件事：規格和測試有沒有對齊現實，工具幫不了你，只有你自己知道。