注意，本文「現成工具」部分，會講解「敏捷開發」流程
SDD 是什麼？
Spec-Driven Development, SDD，一般翻成「規格驅動開發」
但沒聽過的，誰知道那什麼鬼
SDD 指「先寫好規範文件，再依規格實作程式碼」白話文就是「按圖施工」，先畫設計圖 (規格文件)再施工 (寫程式)
# 軟體圈很愛用各種簡稱，裝出一副博大精深的樣子
為什麼特別講 SDD？
不就是先寫文件，很厲害嗎？
SDD 的好處
許多開發者，習慣腦中構思完就直接動手
專案搞定後，再著手寫文件
這沒什麼問題，反正藍圖在腦裡，東西最後也會生齊
但對企業來說，有一些缺點：
- 協作不易
你寫程式寫很爽，但專案太大，公司想加速
又或者你專門刻演算法，前後端想丟給旁人
結果同事要幫忙前，還得先迷失在程式碼中
花大把時間理解專案，才有辦法開始做事
# 若沒文件或架構圖，複雜專案很難三言兩語講清楚
- 交接困難
假設你在某爛公司，東西做到一半被挖角
原本就想逃了，何況別家出更多錢
於是你輕鬆愉快地跳槽，留下一堆意義不明的程式碼
問題來了，非技術背景的 PM (專案 / 產品經理)、老闆，能教懂下一個人嗎？
完美 🎉，搞爛一間破公司！
如有文件說明 API 規格、系統架構與設計可參照，接盤俠比較不會崩潰
這可能粉碎你捅公司一刀的美夢，但從公司角度來看，此做法再好不過
# 至於有沒有做，就交給公司去煩惱
- 管理方便
假設你是技術出身的高層，除了開發，更可能負責制定產品規格
系統架構師 (System Architect)、系統設計師 (System Designer)便屬此類
你只需規劃產品藍圖，剩下丟給碼農工程師實作
降低「習慣不同」導致的程式差異，最大限度管控產品結構
# 輕視規劃、架構的公司不少，也因此程式碼一團亂
- 容易維護
規格統一、確立，專案才不會像天書一般，雜亂無章難以維護
Java 就是個極度適合寫系統的語言，因為硬性規範明確
當實作方式已被限定，文檔又清楚載明規格
產品通常會很工整，要抓錯、調整都很容易
# 當然，其他程式語言也能辦到，只是 Java 設計初衷就是寫大系統
我又不是資方，哪管他那麼多
是的，你可以不管
不過在 AI 時代，尤其 Vibe coding 盛行，人人都能當開發者
# Vibe coding 最初指「用自然語言開發，程式碼不需全看懂」
不過好的軟體，往往不是無腦做成，「規劃」仍扮演要角
更何況全自動開發想避免做歪，規格、架構寫清楚很重要
哪怕是 AI 寫的規格、AI 畫的架構也行
有現成的工具嗎？
工具可多了，那麼美妙的東西，怎麼可能沒人做呢？
當初 Amazon Kiro，就是打響 AI SDD 的開發環境
# 缺點是要錢、閉源
有幾款基於 SDD 開發，受歡迎的專案：
應該算最完備的，角色和規範模板都幫你寫好了
主要使用敏捷開發框架、相容於各主流整合開發環境 (IDE)、文件說明充足
基本流程：
1. 分析師 (Analyst)和你討論點子，一同發想、調研競品、並製作專案簡介
# 此步驟可略
專案簡介是份文檔，給下一個 agent 看的
2. 專案 / 產品經理 (PM)製作專案需求文件 (PRD)
若上一步有文檔產生，他可以直接看文件生 PRD
若無，則和你互動釐清需求，聊聊天就生完了
3. 使用者介面、體驗設計師 (UI / UX)設計畫面
# 此步驟亦可略，或許你沒要畫面
4. 系統架構師 (SA)繪製架構圖
這可是後續開發的精髓呢！
有架構圖，工程師就能按圖施工，是 SDD 的核心要件
# 之後是可略的測試架構，此處不贅述
5. 專案擁有者 (PO)審核文件
不滿意就發回重審，滿意則切分文檔，準備進入敏捷開發
PO 會依功能或需求，將文件切分 (shard)成獨立單位 (Epic)
每個 Epic 就是個主要功能、計畫，需數個 sprint (迭代)完成
例如「製作線上會議平台」，就可當一個 Epic
敏捷開發，動手！
6. 團隊指導者 (Scrum Master, SM)
參考 Epic 草擬用戶故事 (Story)，若高風險則可先讓 QA 檢查
Story 指「用戶故事」，從用戶角度出發，依 INVEST 原則設計
# INVEST：獨立、可協商、有價值、可估算、小且可測試
一個 Epic 可有多個 Story
E.g. 「我想要端對端加密」、「我想要即時串流」，就是兩個 Story
此時有個「用戶 (i.e. 你)核准」環節，會暫停自動過程
這是故意設計的，為避免 AI 開發失控，須人類明確審核
算是種 Human in the loop (人在圈套裡人類參與迴圈)作法
# 就是 AI 自動化過程，有人類參與的意思
都通過的話，SM 就再將 Story 切成任務 (Task)，準備實作
Task 指 Story 中的具體工作，設計給單次迭代 (sprint)施行
E.g. 「設計會議軟體畫面」、「撰寫串流模組」、「創建測試腳本」是三個 Task
Epic 包含多個 Story、Story 下有多個 Task
Epic
|
|-- Story
|
|-- Task
|-- Task
|-- Story
|
|-- Task
|-- Task
|-- Task
接著就是你我熟悉的「Vibe coding」囉！
7. 開發者 (dev)實作
沒什麼好講的，就是 AI 按照架構圖、任務、規範等施工
像個碼農一樣生完程式碼，並執行測試
測試通過後，再強制使用者核准
8. 品保 (QA)確定產品沒問題，就完成啦！
# 也可以不經 QA，直接強行闖關
看起來很複雜，但過程多半自動化，用不同文檔定義每個角色
你只要前段生完需求書，按下 enter ⏎ 就能去玩桌遊、打電動了
# 中斷都沒問題，回來時再讓 AI 讀上一步的文檔即可
一局結束看一下，輪到你核准沒
直接無腦全給過檢查內容無誤，就繼續壓榨 AI
至於為何講那麼細？
因為它把經典的開發流程，完全重現在 AI 工具中
可順便學 SDD，也把敏捷開發搞清楚
前半部類似瀑布式開發，後半部像敏捷開發
結合「妥善規劃」和「即時彈性」優勢，截長補短
# 然後你就贏許多公司了
後面工具就概述，有興趣可自行查閱
名字很直接，就叫規格工具組
和 BMAD 相比，是簡單易用版
且設計邏輯非「角色」，而是「工作流」
E.g.
/constitution會建構整個專案的規範/specify釐清需求 (i.e. 你想做什麼)/clarify確認漏掉的細節 (若有)/plan擬定專案實行計畫/tasks同前述，切分任務/analyze分析各文檔一致性 (e.g. task 是否缺漏、或多出冗餘)/implement實作嘍！
不是定義角色身份，而是每步要做什麼
因為過程較簡略，適合小專案
# 支援多種 AI 開發環境，可參閱官方文件
相容的 IDE 多閉源，且功能陽春
主要分三層架構：
- 準則 (Standard)：
你想用的框架、寫程式的風格、開發路線 (e.g. BDD、TDD)
- Product
具體任務內容、技術選擇、產品規劃圖...
- Specs
就是文件啦～
這種由上而下 (Top-down)的做法，有助於專案擴展
各階段定義明確，且不用「寫完程式還得寫文件」，文件早早就生完了
還能確保文件和程式、專案總體的一致性，解決很多台商爛流程導致的問題
