SDD 不只是軟體工具——我用它規劃了一個物理專案

上次用十分鐘架好 WireGuard VPN，以為搞定了。兩週後 LINE 斷線、NAS 連不上，逐個排查才發現防火牆規則有問題。如果當初先跑 SDD Spec 階段，這些問題在規格書裡就會被列出來，不會等到出事才救火。

本文分享我如何把原本給軟體用的 SDD 框架，實際套用在網路架構規劃上，以及兩者之間的差異。

什麼是 SDD

規格驅動開發（Spec-Driven Development），核心概念很簡單：

先用自然語言把「你要做什麼」定義清楚，再交給 AI 執行。

不是叫 AI 直接幫你做事，而是先讓 AI 幫你想清楚，再動手。

這個框架原本是為寫程式設計的，但底層邏輯適用於任何需要「定義清楚再交付」的場景。今天我拿一個網路設定任務來試試。

我的任務：用 WireGuard 把兩個辦公室連起來

這個任務我們之前做過，還寫了一篇文章：把兩個辦公室連起來：用 WireGuard 十分鐘搞定。

這次我想試試：如果先跑 SDD 流程，會產生什麼不同？

完整 SDD 循環怎麼跑

SDD 有四個主要階段：Spec → Plan → Tasks → Implement

註：Implement 實務上是人工處理，所以這邊會移除這個步驟。

所以你看會出現這麼多步驟！這就是需要取捨的地方。SDD 在很多時候過於複雜或過度設計，導致很多人懶得使用。我的文章是一篇快速入門介紹，讓大家在 10 分鐘內跑起來，省略了防火牆解釋、精確的 AllowedIPs 設計，以及架構名詞的精確解釋。Spec 則是可實際部署的工程文件，兩者目的不同。

Step 1｜Spec（規格）

我給 AI 的輸入只有一句話：

「RouterOS 做 Server，Fedora 做 Client，Fedora 筆電要能相互訪問內網並存取 NAS。」

AI 產出的規格包含：

• 架構圖：兩端 IP 規劃、VPN 管理網段、Split Tunnel 流量走向
• User Stories：三個故事，分別對應「連上」、「多人同時連」、「開機自動連」
• 驗收條件：每個故事有明確的 Given / When / Then
• Edge Cases：firewalld 干擾、AllowedIPs 設錯、防火牆 rule 順序、內網回程路由……

光是 Edge Cases 這段，就把我上次踩過的所有坑都列出來了。

我之前怎麼知道這些問題的？靠踩坑。

Step 2｜Plan（實作計畫）

規格確認後，AI 產出實作計畫，把設定步驟分成三個 Phase：

Phase 0：產生金鑰、確認環境（零風險）
Phase 1：RouterOS + Fedora 實際設定
Phase 2：逐項驗證

每個步驟都附上可直接執行的指令，包含預期輸出是什麼。

Step 3｜Tasks（任務清單）

最後產出 39 個任務，標注哪些可以平行執行、哪些有相依性、MVP 交付點在哪裡。

遇到什麼問題、學到什麼

問題：內容太多，差點過度設計

跑完三個階段，我拿到的是一份工程等級的部署文件。

這和我原本那篇「十分鐘快速入門」的定位完全不同。

兩者的差距：

SDD 不是萬能的，它會把所有可能的問題都考慮進去，但你不一定需要全部。

取捨是你的工作，不是 AI 的工作。

Spec 階段為什麼最有感

對我來說，Spec 是整個流程最值得做的一步。

規格架構清楚了，可以少繞很多彎路。有些事情不做，才是最好的優化。當你不知道自己的真實需求，給 AI 時就會無限延伸成一個龐大的方案架構——其實你只是想要兩地 VPN 連線而已。限縮邊界、訂好需求，才是最重要的事。雖然後續內容閱讀與執行可能繁瑣，但精準確實，可以達成。

原因很具體：我上次設定 VPN 雖然連上了，但後來出現一堆問題——LINE 無法連線、時常斷連。花了大量時間各種問 AI 才一一排查。如果當初先跑 Spec，這些問題在規格階段就會被列為 Edge Cases，設定時就會一起處理，不用事後救火。

規格先行的優勢不是讓你做更多，而是讓你少走彎路。

結論：這個框架可以用在哪裡

SDD 適合用在：

• 你知道目標，但不確定邊界在哪裡（Spec 幫你劃清楚）
• 需要穩定、可重複執行的設定（Tasks 幫你不漏步）
• 多人協作或需要交接的場景（文件即流程）

不適合用在：

• 真的只是想快速試試看
• 一次性的小任務

我的快速入門文章和這次的 SDD 產出，目的不同，都有價值。

差別在於：你想要跑起來，還是想要跑得穩。

如果這篇對你有幫助，歡迎訂閱我的電子報。每週一篇，分享一個你可能沒想到的技術技巧或工作流程。

💬 或直接來信交流 [email protected]