AI 時代的新 SDD：從 Windsurf 的 25 個 Spec Files 談起
我今天使用 Windsurf 配合 25 個詳細 Spec Files 一次性生成高品質應用的案例，標誌著一個重要的開發典範轉移。這不僅僅是運氣，而是驗證了一種更成熟的 「個人版 SDD（Spec-Driven Development）」 模式。
這篇文章將解釋為什麼我這次會成功、Windsurf 與競品（Kiro/Trae）的本質差異，以及如何將這套流程標準化。
1. 成功復盤：為什麼「25 個 Spec Files」是關鍵？
通常開發者使用 AI 編碼失敗，多半是因為「意圖模糊」導致 AI 在實作時必須「猜測」。而我這次的成功，建立在兩個核心基礎上：
A. 規格即契約 (Spec as Contract)
25 個檔案看似繁瑣，但對 LLM 而言，這是最完美的輸入。我將 Domain Logic（領域邏輯）、Use Cases（使用案例）、Edge Cases（邊界條件） 以及 Non-functional Requirements（非功能需求） 全部具象化。
-
消除歧義： Windsurf 不需要「試探」我的需求，因為所有的定義都在這 25 個檔案裡。對 AI 來說，這不僅是 Prompt，這是一套 可計算的契約（Computable Contract）。
-
上下文密度： 這些檔案提供了極高的「資訊密度」。AI 不需要依賴通用的訓練數據來填補邏輯漏洞，而是直接執行我定義的邏輯。
B. Windsurf 的 Repo-Level 能力
Windsurf 的強項在於其強大的 RAG（檢索增強生成）與 Context Window 管理：
-
Mental Model 構建： 它能將這 25 個檔案視為一個整體，先在內部建立專案的 Mental Model（心智模型）。
-
計畫優先： 它不是寫一行想一行，而是基於全域視野（Global Context）規劃架構，因此生成出來的程式碼能一次到位，無需多輪修補。
2. 工具戰略定位：Windsurf vs. Kiro vs. Trae SOLO
我的作法（高品質 Spec + Windsurf）與市場上另外兩款熱門工具 Kiro 和 Trae SOLO 有著本質上的路線差異。
| 特性 | Windsurf (我的用法) | Kiro (AWS) | Trae SOLO |
|---|---|---|---|
| 核心理念 | User-Guided Execution 我給契約，它執行。 |
Strict Process SDD 強制性的軟體工程紀律。 |
Autonomous Agent 全自動工頭，一條龍服務。 |
| 主導權 | 我 (Architect) + AI (Coder) | 工具 (Manager) + 我 (Worker) | AI (Project Lead) |
| 規格形式 | 我的 Spec Files (Markdown/Code) | 強制性的 Req / Design / Task 結構 | 自產 PRD (通常較簡略) |
| 自動化層級 | 高 (但在我的框架內) | 中 (需按部就班審核) | 極高 (從需求直達部署) |
| 適合場景 | 個人版 SDD、架構控、複雜邏輯 | 團隊協作、合規性要求高、企業級專案 | MVP、PoC、快速原型、舊專案翻新 |
深度解析差異
-
Windsurf：最強大的執行者
我這次的體驗證明了 Windsurf 是目前最適合「架構師型開發者」的工具。它不強迫我走特定流程（像 Kiro），也不會擅自決定架構（像 Trae），它完美地扮演了「資深工程師」的角色——讀懂我的詳細 Spec，然後精準實作。
-
Kiro：嚴格的合規官
Kiro 就像是一個嚴格的 Tech Lead。它強制將開發拆解為 Requirements -> Design -> Tasks。這對於需要長期維護、多人協作的專案非常有價值，因為它留下了完整的 Audit Trail（審計軌跡）。如果我想要「被工具管」，Kiro 是首選。
-
Trae SOLO：全自動外包團隊
Trae SOLO 走的是「Context Engineering 一條龍」。我給一個模糊指令，它幫我把 PRD、架構、前後端、部署全包了。
-
優點： 速度極快，適合 0 到 1 的 MVP 或簡單專案。
-
缺點： 對於在意架構潔癖（Clean Architecture / DDD）的人來說，Trae 自產的架構可能「能跑但不好維護」。
-
3. Trae SOLO 的「一條龍」深度剖析
雖然我偏好 Windsurf 的精準控制，但了解 Trae SOLO 的能力邊界對我的工具箱也是一種補充。
它實際在做什麼？
Trae SOLO 運用了多層次的 Context Engineering：需求解析 → 任務拆解 → 工具編排（寫碼、跑 Terminal、開瀏覽器） → 執行 → 自我修復（看 Log 修 Bug）。
什麼時候該用它？
-
驗證想法 (PoC)： 當我不在乎程式碼是否符合我的 Spec 標準，只想看「這點子行不行」時。
-
大規模重構 (Refactor)： 例如「把這個 Repo 從 JS 轉 TS」，Trae 的 SOLO Coder 在這種機械性但繁瑣的任務上表現優異。
-
髒活累活： 寫測試、寫文檔、補註解。
對我的潛在風險
如果我習慣了 Spec-Driven，會發現 Trae 的「黑箱感」很重。我必須花費大量時間 Review 它的 PRD 和 Code，這有時比自己寫 Spec 給 Windsurf 還要累。
4. 下一步升級：打造我的「個人 SDD 標準化流程」
既然「25 個 Spec Files + Windsurf」這條路已經跑通，接下來的目標是降低邊際成本並提高穩定性。建議可以從以下兩點著手升級：
升級一：引入「Plan 中間層」 (The Plan Artefact)
不要直接讓 Windsurf 生成 Code，而是先生成一份 plan.md。
-
操作方式： 在餵入 Spec 後，Prompt 下達：「請閱讀所有 specs，並生成一份
implementation_plan.md。列出建議的檔案結構、每個模組對應的 Spec ID，以及開發順序，不要寫 Code，先寫 Plan。」 -
價值：
-
校準 (Alignment)： 在寫 Code 之前，先檢查 AI 的理解是否正確。如果 Plan 錯了，改 Plan 比改 Code 快得多。
-
追蹤 (Traceability)： 這份 Plan 之後可以變成 Checklist，讓我清楚目前的進度。
-
升級二：萃取「Spec 模板」 (The Spec Kit)
我這次的 25 個檔案其實隱含了一套 Pattern。可以將其抽象化，建立一套屬於我的 Spec-Kit：
-
Core Domain Specs: 定義實體、值物件、核心規則。
-
Interface Specs: 定義 API Schema、UI Component Props。
-
Behavior Specs: 使用類似 Gherkin 或 User Story 的格式描述行為。
-
System Specs: 定義 Tech Stack、Folder Structure、Naming Convention。
未來流程：
新專案啟動 → 填寫 Spec-Kit (約 8-10 個關鍵檔) → Windsurf 讀取 → 產出 Plan → 確認 → 一鍵生成 App。
結論
我今天的成果印證了一個觀點：在 AI 輔助編碼的時代，工程師的核心競爭力從「寫 Code 的速度」轉變為「寫 Spec 的品質」。
-
Trae SOLO 適合想當「產品經理」的人（給需求，拿產品）。
-
Kiro 適合想當「工程經理」的人（管流程，控品質）。
-
Windsurf + 我的 Spec 則是 「架構師」 的終極型態——我用嚴謹的契約定義世界，AI 負責構建世界。
下一步建議：
不用急著換工具。試著把這 25 個檔案結構整理成一個 GitHub Template，下次做新專案時，先試試看「Spec -> Plan -> Code」這個三步走策略，會發現這套個人版 SDD 會變得更穩固、更可複製。