在 AI 編程工具（如 Claude Code, Cursor）大幅降低寫程式門檻的今天，開發者面臨的新挑戰不再是「怎麼寫」，而是「怎麼讓 AI 精準地寫出我想要的」。
GSD (Get Shit Done) 框架應運而生，它將傳統的開發流程翻轉，推行一套以規格 (Spec) 為核心的開發方法論，確保 AI 不再只是「瞎猜指令」，而是成為高效的執行工程師。什麼是 GSD 規格驅動開發？
GSD 本質上是一套情境工程 (Context Engineering) 框架。它認為：高品質的程式碼產出，取決於高品質的情境輸入。
不同於傳統隨性的對話式編程（Vibe Coding），GSD 強調在動手寫程式碼之前，必須先建立結構化的文件作為 AI 的「導航地圖」。這套地圖通常包含：
- PROJECT.md：定義專案願景、核心技術棧與開發規範。
- REQUIREMENTS.md：具體的功能需求與邊界條件，這是 AI 執行的唯一標準。
- ROADMAP.md：開發優先順序與里程碑，防止 AI 在開發過程中迷失方向。
- STATE.md：記錄目前的開發進度、已解決的問題與下一個待辦事項。
GSD 的三大核心優勢
1. 消除 AI 幻覺與誤差
透過「單一事實來源 (Single Source of Truth)」，AI 會在讀取程式碼前先閱讀規格。這大幅減少了 AI 因對上下文理解不足而產生的邏輯錯誤。
2. 強制測試驅動 (TDD)
在 GSD 流程中，規格通常會直接對應到測試案例。實作 Agent 必須寫出能通過這些測試的程式碼，且被嚴格禁止修改測試規格，確保開發結果完全符合預期。
3. 解決專案膨脹問題
當專案規模變大時，AI 常會忘記之前的約定。GSD 透過自動化的「狀態同步」機制，讓 AI Agent 每次啟動時都能精確掌握專案現況，適合處理長期且複雜的開發任務。
如何開始實踐？
GSD 最早起源於 Claude Code 的社群實踐，你可以透過以下步驟導入：
- 定義腳手架：使用
gsd init等指令建立標準化文件目錄。 - 先規劃後執行：每次新增功能時，先在
REQUIREMENTS.md更新規格，並讓 AI 確認邏輯無誤。 - 迭代驗證：利用
gsd sync讓文件與程式碼同步，確保文件永遠不會過時。
結語
GSD 框架並不是要增加開發者的文書工作，而是將「思考」與「執行」分離。在 AI 代理 (Agentic Workflow) 逐漸成為主流的未來，掌握如何編寫「機器可理解的規格」，將是資深開發者最具競爭力的技能。
