2026年4月16日 星期四

好站 : 高見龍老師的部落格 (SDD 規格驅動開發)

三月時內訓課程請到六角學院的高見龍老師來講 SDD 規格驅動開發, 讓我覺得獲益匪淺, 其實課程內容的精髓大部份都可以在其部落格找到 :


部落格中與 SDD 規格驅動開發有關的是這幾篇 :


其中 Spectra 是高老師為 OpenSpec 開發的 GUI 工具, 可以讓 OpenSpec 用起來更簡單更直覺, 剛好我最近正在學 OpenSpec 用得上 (雖然我只開發小專案, 但江湖在走, SDD 還是要有). 參考 :


我去年參加公司的 Hahow 企業版線上課程時就上了不少高老師的課 (Python, Javascript, 網頁前端), 不管是口條或內容都非常棒, 雖說 AI 時代學習這些技能似乎不那麼重要了, 但有基礎的人與菜菜小白終究是不同的. 


2026-04-23 補充 :

這幾天上完 TibaMe 的 SDD 課程後, 回頭來複習高老師的文章, 摘要整理如下 :


一. Vibe Coding 的問題 : 
  • AI 產出的程式碼風格不一致 :
    開啟不同的對話詢問相同需求, AI 可能用完全不同的方法跟架構來生成程式碼. 
  • AI 不會主動審查需求的完整性 :
    AI 通常是針對提問中的需求焦點實作, 不會補全其他需要搭配的功能, 導致東補西補或過度猜測實作了不需要的功能.
  • 可維護性與可擴展性較差 : 
    AI 生成的程式碼主要以能跑就好為目標, 忽略長期維護所需的架構設計, 對需要交接的大型專案維護不利. 

二. SDD 的核心概念 : 
  • 先寫規格再寫程式 :
    在寫程式之前先把規格寫清楚, 把規格變成 AI 和人類之間的共同語言. 
  • 規格是跟實作分開的, 可以用同一份規格去嘗試不同的技術組合, 看哪個最適合.
  • SDD 讓 AI 的產出更可控, 更符合我們的期待.
  • SDD 最重要的價值是把規格留下來備查. 
    如果開發的時候有留下 spec, 它記錄的不只是要做什麼, 還有為什麼要這樣做. 它是開發當下的決策脈絡, 是需求和實作之間的橋樑. 重點是這個 spec 不只是給人看的, 還能給 AI 看, 這才是 SDD 真正的亮點. SDD 不只是指揮 AI 做事, 而且還能讓專案的知識不會流失. 
  • Vibe coding 是「邊做邊想」, SDD 是「想清楚再做」.

三. SDD 工作流程的三個階段 (與所對應的 md 文件) :
  1. 需求階段 (對應文件 requirements.md) :
    此階段目標是將模糊的想法變成清晰可被驗證的需求, 需求要按照 User Story (使用者故事) 格式描述, 並附上具體的驗收標準. 使用者故事格式 : 
    作為 (角色), 我希望 (功能), 這樣我就能 (好處)
    例如 : 
    作為一個使用者, 我希望能夠用 Email 和密碼登入, 這樣我就能存取我的個人資料.
    驗收標準要用 EARS 格式撰寫, 例如 :
    當使用者輸入正確的 Email 和密碼的時候系統應該將使用者導向首頁.
  2. 設計階段 (對應文件 design.md) : 
    由 AI 幫忙產出一份技術設計文件, 包含系統架構圖, 資料流程, 資料模型, 錯誤處理策略, 測試策略等. 此階段的重點是讓我們有機會在寫程式之前就發現問題以降低修改成本, 不要等到等到程式都寫完了才發現. 可要求 AI 加入 wireframe mock 來確認介面的設計是否符合要求. 
  3. 任務階段 (對應文件 tasks.md) :
    根據需求和設計, 把工作拆成一個一個可追蹤的小任務, 每個任務同樣都有明確的目標和驗收標準且會追溯到最初的需求編號. 任務的顆粒度 (granularity, 切多大或多小) 很重要, 但這沒有一定要的標準答案, 只要小到可以在一個合理的時間內完成並驗證即可. 
這三份文件會隨著專案演進而同步更新, 亦即, 規格會跟程式碼保持同步. 


四. EARS (Easy Approach to Requirements Syntax) 格式 :
  • 此格式源自航空業, 使用固定順序的 When…shall… (then) 語法來撰寫需求, 它清楚地說明了觸發條件 (輸入正確的帳密) 和預期行為 (跳轉到首頁), 此種格式具有足夠的可讀性, 也具有機器讀取所需的結構性, 使需求更容易被測試, 減少了 AI 的猜測空間, 生成的結果更可預測. 

五. SDD 的三個層級 : 
  1. 規格優先 (Spec-first) :
    在寫程式之前先寫好規格, 然後用規格來引導 AI 生成程式碼. 此作法比 Vibe Coding 好的地方是至少有一份文件記錄當初想要什麼.
  2. 規格錨定 (Spec-anchored) :
    把規格保留下來且加進版本控制裡, 使其隨著專案演進而更新. 當要修改功能的時候不是直接去改程式碼, 而是先改規格, 讓程式碼跟著規格走. 這樣做好處是永遠有一份文件知道系統應該做什麼, 對團隊協作尤其有利. 
  3. 規格即原始碼 (Spec-as-source) :
    此為最激進層級, 只編輯規格不直接編輯程式碼, 程式碼完全由規格自動生成 (規格是真相的來源), 這樣就能確保兩者永遠一致. 但要把規格寫得非常非常精確, 才能確保生成的程式碼是正確的.

六. OpenSpec : 
  • 開源的輕量級工具 : https://github.com/Fission-AI/OpenSpec
  • Brownfield-first (棕地優先) : 
    不只適合從零開始的新專案, 更適合在現有系統上做修改.
  • 工作流程簡單 : proposal -> apply -> archive
  • 支援主流的 AI coding 工具 : Gemini CLI, Claude Code, Copilot, ...
  • 強調 "fluid not rigid, iterative not waterfall", 核心理念 "Agree before you build". 
  • 常用指令 :
    • /opsx:new 開一個新的變更
    • /opsx:ff 一口氣產生 proposal, specs, design, tasks
    • /opsx:apply 實作
    • /opsx:archive 歸檔 (留下完整的決策紀錄)

七. SDD 的缺點 : 
  • SDD 會讓開發速度變慢 : 
    SDD 適合有一定複雜度的專案, 小工具直接用 Vibe Coding 即可.
  • SDD 會改變工程師的角色 :
    程式員 -> PM 的掙扎 (how 變成 what) 
    從寫程式碼轉變成設計架構和審查結果.
  • 做好 SDD 需要學習新的技能 :
    寫好規格不容易, 需要時間訓練, 要學會如何把模糊的需求變成清晰的驗收標準, 如何設計可測試的系統.
  • 若既有系統本來就沒有規格文件, 導入 SDD 得先花時間把現有行為記錄下來, 這是導入成本. 
  • 同樣的 spec, 同樣的 prompt, 可能有不同的產出.

八. 結語 : 
  • SDD 適合大專案或團隊協作, Vibe coding 較適合小專案, 小工具, side projects, 或快速原型展示等應用, 而大型專案應該以 SDD 規格驅動開發為準繩.
  •  Vibe Coding 對兩種人很有幫助, 一是很有經驗的開發者, 他們懂得怎麼除錯和解決問題, 透過 AI 幫忙加速開發; 另一種是程式小白, 透過 AI 就可以把想法變成可以運作的軟體, 即使不懂程式設計也做得到.
  • 全自動的 Spec-as-source 可能還要再等等, 也許目前 Spec-anchored 會是比較好的解法. 
  • SDD 的價值不只是指揮 AI, 更是留下脈絡讓未來可以追溯.

於

沒有留言:

張貼留言