STMAXFlow：STMAX 的規格驅動開發流程
我們把這套工作方式稱為「STMAX 規格驅動開發流程｜STMAXFlow v2」：先說清楚要解決的問題與驗收條件，再安排設計、實作及驗證。規格驅動開發（Specification-Driven Development，SDD）是既有的工程方法；STMAXFlow 是 STMAX 整合與執行這些方法的流程名稱。
它結合需求分析、架構與資料設計、AI 協作、測試及人工審查。並不是按下按鈕就完成網站，也不代表每一個專案都需要同樣厚度的文件。
01：先整理使用情境
我們會了解誰使用、目前怎麼作業、資料從哪裡來，以及真正卡住的地方。接著把第一版必做與未來擴充分開。案主不需要先懂程式，提供一筆真實的作業範例，就能開始討論。
02：把期待變成可驗收的規格
例如「預約要方便」太抽象；「訪客選擇服務與時段，送出後看到預約結果；同一人員同一時段不得重複預約」就能檢查。規格還要包含失敗情境、權限、取消規則與資料保留方式。
這個階段確認功能邊界與不包含的項目，並將頁面、資料、角色及驗收條件連起來。報價及時程因此有共同依據。
03：拆成可展示的小階段
依需求規劃畫面、資料模型與介面，將工作拆成任務。先交付可以操作的核心流程，再擴充細節。AI 可以協助分析、產生初稿與測試，但輸出仍要經過工程檢查，必要時修正架構與邏輯。
選擇物件分析、設計模式或較細的架構，取決於問題複雜度；小型官網不應為了方法名稱而增加不必要的成本。
04：測試與人工確認一起做
依範圍安排功能、權限、錯誤情境與回歸測試；適合自動化的部分才加入自動化驗證。案主則依規格試用主要情境。我們會留下已知限制與待處理事項，不用「測試都過了」代替實際驗收。
05：交付後，變更也有依據
新需求先評估影響，再更新規格、費用與排程。交付內容可包含操作說明、設定資訊、原始碼或部署安排，以合約約定為準。這樣下一次修改不必重新猜測當初的決定。
常見問題：用 WordPress 也能採這套流程嗎？
可以。需求確認、權限盤點、測試與交接同樣適用；實作可使用 WordPress、既有服務或客製程式。工具要服務目標，不由方法名稱決定。
參考：GitHub Spec Kit 對規格驅動開發的說明。也可看 完整方法介紹與 系統開發作品。
