SDD 到底救了誰？從 AWS Kiro 到 Spec Kit 的兩年實測真相

2025 年年中，生成式 AI 在軟體工程領域的狂歡正達到頂點，「Vibe Coding」的隨性探索開始顯露疲態——隨意聊天容易在複雜專案中迷航，提示詞的模糊迫使模型猜測無數未言明的邊界。

就在此時，AWS 正式發布了主打規格的 agentic IDE「Kiro」，隨後 GitHub 也推出了開源工具包「Spec Kit」。「規格驅動開發」（Spec-Driven Development，簡稱 SDD）自此被推向主流舞台。

這場工具發布伴隨著 GitHub 與 AWS 對未來開發範式的重新定調。GitHub 在官方部落格寫下震撼業界的口號：「我們正從『程式碼是真理源』走向『意圖是真理源』（From code is the source of truth to intent is the source of truth）。」OpenAI 的 Sean Grove 甚至在公開演講中宣告，工程師只有 10% 到 20% 的價值體現在程式碼，其餘 80% 到 90% 都在結構化溝通，因此「真正有價值的產物是規格，而不是程式碼」。

然而，兩年過去了。當第一批嘗試把整套 SDD 導入專案的團隊與工程師陸續交出實測報告時，這套宣傳框架與現實工程之間的落差才逐漸清晰。

規格的三層想像：我們究竟停在哪裡？

要理解 SDD 的現實落差，Thoughtworks 傑出工程師 Birgitta Böckeler 在 martinfowler.com 提出的「三層分類法」是一把關鍵的鑰匙：

  1. 規格優先（Spec-first）：在動手寫程式前先寫規格，理清思路，寫完任務即告完成。
  2. 規格錨定（Spec-anchored）：規格隨功能長期存在於儲存庫中，作為程式碼的說明與維護錨點。
  3. 規格即源碼（Spec-as-source）：人類未來只編輯規格，程式碼完全交由 AI 生成，不再手工維護。

大廠與布道者兜售的願景，幾乎都在描繪第三層——工程師只需要用自然語言交代意圖，系統就會自動生成無懈可擊的程式。

但現實的真相是：目前市面上的主流工具（GitHub Spec Kit、AWS Kiro），本質上都只能服務於動手前的第一層（Spec-first）；一旦試圖讓規格長期錨定並同步程式碼（Spec-anchored），系統就迅速分崩離析。

這種「實踐停在第一層、想像狂奔在第三層」的落差，正是隨後實踐中種種混亂的根源。

實踐者的真相：成功案例全部來自「個人手藝」

回顧公開社群中被反覆驗證、真正交付出可用成果的 SDD 案例，會發現一個鮮明的規律：它們全是一個人寫給自己看的規格。

Mitchell Hashimoto 的 Ghostty 功能實錄

HashiCorp 共同創辦人 Mitchell Hashimoto 在為他的終端機專案 Ghostty 新增非平凡功能時，採用了規格先行的方法。他先與 agent 透過一問一答產出計畫，存成 spec.md，接著將計畫切成小塊，並在 agent 實作每一塊之前進行嚴格的人工審查。他的心得核心只有兩個詞：互動（interactive）與小塊（smaller chunks）。規格不是交接公文，而是他引導模型思考的草稿。

Harper Reed 的三檔案工作流

前 Obama 競選 CTO Harper Reed 在 Spec Kit 問世前七個月，就公開了他著名的三檔案工作流：spec.md → prompt_plan.md → todo.md。他花十五分鐘與 AI 規劃、定義驗收條件，接著執行明確的小步迭代，人工逐條打勾。Reed 留下了一句關鍵結論：「成敗完全取決於第二步（規劃）做得有多好。」

安全演練系統的實戰

在台灣 iT 邦幫忙鐵人賽上，有開發者實測使用 Kiro 開發一套紅隊自動化演練系統。他發現結構化的規格確實能有效防止模型在長任務中「脫軌」，AI 甚至在分析需求時主動指出了架構中的潛在 Race Condition。這裡成功的關鍵不在於工具的自動化模板，而在於開發者主動將規格與 steering files 當成個人的控制桿，精確收斂上下文。

這些案例指向同一個結論：規格作為個人的「上下文導航儀」時非常強大。 它讓工程師在動手寫程式前把問題的邊界想清楚，由人掌舵，而不是把主導權交給工具的自動生成機制。

重型工具的泥淖：當規格變成官僚儀式

然而，一旦大廠將這個原本靈活的手藝制度化，演變成由「專案憲法（Constitution）」、規格、架構設計到任務層層堆疊的重型流程時，事情就迅速走向反面。

雙重審查與「大錘敲核桃」

Birgitta Böckeler 在 martinfowler.com 上分享了她實測 AWS Kiro 的震撼體驗：為了解決一個微小的錯誤，系統自動生成了 4 個使用者故事與 16 條驗收標準。面對這座突然冒出來的文件大山，Böckeler 留下了被廣泛引用的名言：「老實說，我寧願審程式碼，也不想審這一堆 markdown 檔。」

marmelab 創辦人 François Zaninotto 則在〈The Waterfall Strikes Back〉中記載了一個更具對比性的實驗：他讓 GitHub Spec Kit 實作一個「顯示當前日期」的簡單功能，系統一口氣產出了 8 個檔案、共 1,300 行規格文字。隨後他用傳統的無規格迭代方式，在 10 小時內就手搓出一個功能完整的 3D 雕刻工具。

台灣敏捷社群的 Justhings 直指這是「AI 時代的瀑布殭屍」：開發者變成了審查員，「花費 80% 的時間在閱讀冗長的規格，試圖在看起來很專業的廢話中抓出邏輯漏洞」。工作量非但沒有減少，反而因為要同時維護「文件」與「程式碼」兩套真相而翻倍。

規格漂移與無法驗證的自然語言

自然語言天生缺乏程式碼的精準度與編譯器的約束力。獨立開發者 Jakša Vucković 在實測 Spec Kit 的紀錄中，經歷了最經典的崩潰：在規格生成了 47 個任務、3 個使用者故事後，專案中出現了不一致；當他要求 agent 修正時，agent 只更新了部分文件，文件間錯綜複雜的依賴關係徹底失控。

Vucković 最後的專案產出是零測試、應用跑不起來，他感嘆自然語言規格讓人「同時承受了程式碼的複雜度與文件的不可驗證性（getting the worst of both worlds: the complexity of code and the lack of verifiability of documentation）」，在連一行程式碼都還沒寫之前，就已經快被文書工作淹死。

Agent 並不可靠地遵循指令

更直接的挫折來自模型能力本身。多方實錄證實，即便有詳盡的檢查清單，agent 依然經常跳過指令。Zaninotto 發現 agent 會自行將「寫單元測試」標記為完成，交出來的卻是一段手動測試說明；在既有大型專案（brownfield）的實測中，開發者 Rebekka Hubert 發現 AI 產生的架構文件在「結論上看似正確，但引用的底層機制完全是錯的」，普通審查根本抓不出來，只有人工調閱呼叫圖才抓到破綻。

業界專家的思維交鋒：支持思考，拒絕神話

面對這場辯論，軟體工程界的大師與資深從業者劃出了一條清晰的界線：擁抱規劃，但拒絕將規格神聖化。

規劃先行是高槓桿工藝

戳破「規格即程式碼」的神話

退潮與新生：2026 年的輕量化終局

市場與開源社群的腳步往往比理論宣傳更誠實。

到了 2026 年，連當初最激進的規格中心平台 Tessl，其官網首頁標語也已悄然從「規格即程式碼」轉向了「Skills are the new code」，不再死守重型規格的單一敘事。

在開發者社群端，這股反思轉化為實際的工具演化：

原生 Plan Mode 的勝出，背後隱含著一個深刻的範式轉移：它徹底放棄了長期維護文件的野心。 Plan Mode 是一種即用即拋的暫態上下文（ephemeral context）——在動手前花幾分鐘對齊思路，任務執行完畢，上下文就功成身退，不強求沉澱為儲存庫中的永久資產。正是這種「不建檔案神壇」的務實，讓它完美避開了規格漂移與雙重審查的陷阱。

結語：回歸真實的真理源

兩年來的實測證明，規格從來無法代勞軟體工程的核心本質。在 AI 時代，最稀缺的依然是人把問題與邊界想清楚的能力。

這場探索最終給軟體開發者留下了三份清晰的邊界思考：

  1. 規格的重量必須與任務嚴格匹配：修個小 bug 只需要在對話框交代一句話，只有複雜的大型變更才值得寫結構化的規劃。
  2. 永遠不要放棄審核程式碼：規格審查不能代替程式碼審查。測試套件與運行結果，永遠比自然語言文件更誠實。
  3. 程式碼依然是系統唯一的真理源：GitHub 當初宣稱的「意圖是真理源」是一場美麗的錯覺。自然語言充滿歧義與漂移，唯有可編譯、可測試、可運行的程式碼才是真實錨點。

把規格當成一張寫完即扔的便條紙，而不是供在神壇上的公文卷宗——讓規格回歸思考本身，輕裝上陣，才是與 AI 長久協作的清醒姿態。