過去八天，我們探索了各種 AI 開發工具和方法。從 AI-DLC 到 Claudable，從個人 Solo Sprint 到團隊協作，我們一直在追求一個目標：如何讓 AI 更好地幫助我們開發。

但有一個根本問題始終存在：AI 真的理解我們想要什麼嗎？

今天，我們要介紹 GitHub 最新推出的 Spec-Driven Development 方法論和 Spec Kit 工具，它可能是解答這個問題的關鍵。

從一個熟悉的場景說起

你一定經歷過這樣的對話：

你：「幫我做一個部落格系統」
AI：「好的！這是一個基本的部落格系統...」（生成 1000 行程式碼）
你：「等等，我需要支援多作者...」
AI：「了解，讓我修改...」（又生成 500 行）
你：「不對，還需要審核機制...」
AI：「明白了...」（再改 300 行）
你：（崩潰）「算了，我重新說一次...」

Vibe Coding 的陷阱

GitHub 團隊給這種現象起了個有趣的名字："Vibe Coding"。程式碼看起來對了，但實際上並不能正常運作。有時程式碼無法編譯，有時只解決了部分問題卻錯過了真正的意圖。
為什麼會這樣？問題不在於 AI 的編碼能力，而在於我們的方法。我們把 AI 當成搜尋引擎，但應該把它們當作需要明確指令的程式設計夥伴。

傳統開發的規格困境

在傳統開發中，規格文件常常是：

• 寫完就束之高閣的 Word 檔
• 過時到沒人敢看的 Wiki 頁面
• 散落在 Slack 的討論串
• 存在某個資深工程師腦中的「潛規則」

即使在敏捷開發中，User Story 也常常過於簡略，無法完整傳達意圖。

Spec-Driven Development：規格即程式碼的新時代

核心理念：活的規格

這就是為什麼我們要重新思考規格——不是作為靜態文件，而是作為隨專案演進的活的、可執行的工件。規格成為共享的真相來源。

四階段開發流程

Spec Kit 讓你的規格成為工程流程的中心。規格驅動實作、檢查清單和任務分解。你的主要角色是掌舵；AI 負責大部分的編寫工作。

Phase 1: Specify（規格定義）

這不是關於技術棧或應用設計，而是關於使用者旅程、體驗以及成功的樣貌。誰會使用這個？它為他們解決什麼問題？他們如何與之互動？什麼結果是重要的？

範例：任務管理工具的規格

# 任務管理工具規格書

## 核心價值主張
為忙碌的自由工作者提供簡單、快速的任務追蹤方案

## 目標使用者
- 主要：獨立工作的自由接案者
- 次要：小型創業團隊（少於 5 人）
- 特徵：需要簡單工具，不要複雜功能

## 使用者旅程
1. 早晨開啟 - 快速瀏覽今日任務（30 秒內）
2. 新增任務 - 一句話描述即可建立（無需填表單）
3. 工作中 - 拖放調整優先順序
4. 完成任務 - 打勾帶來成就感
5. 日終回顧 - 了解完成狀況，規劃明日

## 成功指標
- 使用者平均每日完成 5+ 個任務
- 從想法到建立任務 < 10 秒
- 每週至少 5 天開啟使用

Phase 2: Plan（技術規劃）

現在開始談技術。在這個階段，你向 AI 提供期望的技術棧、架構和限制條件，AI 生成完整的技術計畫。

範例：技術計畫

# 技術實施計畫

## 技術棧決策
- 前端：React + TypeScript（團隊熟悉）
- 狀態管理：Zustand（簡單易用）
- 樣式：Tailwind CSS（快速開發）
- 後端：Supabase（減少後端開發）
- 部署：Vercel（零配置部署）

## 架構限制
- 必須在 3 秒內載入
- 支援離線使用（PWA）
- 手機優先設計
- 無需註冊即可試用

## 安全與合規
- 資料加密存儲
- GDPR 合規（歐盟使用者）
- 每日自動備份
- 支援資料匯出

Phase 3: Tasks（任務拆解）

AI 將規格和計畫分解成實際工作。它生成小而可審查的區塊，每個都解決特定的問題。每個任務都應該是可以獨立實施和測試的。

範例：Sprint 1 任務清單

# Sprint 1 任務（核心 MVP）

## T001: 建立專案基礎架構
- 初始化 React + TypeScript 專案
- 設定 Tailwind CSS
- 配置 ESLint 和 Prettier
- 估時：2 小時

## T002: 實作任務資料模型
- 定義 Task interface
- 建立 Zustand store
- 實作 CRUD 操作
- 估時：3 小時

## T003: 設計任務列表 UI
- 建立 TaskList 元件
- 實作拖放功能
- 加入完成動畫
- 估時：4 小時

## T004: 整合本地儲存
- 實作 localStorage 持久化
- 處理資料同步
- 加入錯誤處理
- 估時：2 小時

Phase 4: Implement（實作）

你的 AI 逐一處理任務。但不同的是：你不再審查上千行的程式碼傾倒，而是審查解決特定問題的聚焦變更。

為什麼 Spec-Driven 有效？

1. 消除猜測

一個模糊的提示詞如「為我的應用加入照片分享」會強迫模型猜測潛在的數千個未明說的需求。AI 會做出合理的假設，而其中一些會是錯的。
有了明確的規格，AI 不需要猜測：

照片大小限制？規格裡有
誰可以分享？規格裡有
儲存在哪裡？計畫裡有

2. 累積式開發

傳統開發會將你鎖定在早期決策中，而規格驅動讓改變方向變得簡單：只要更新規格、重新生成計畫，讓 AI 處理其餘部分。

3. 知識的集中管理

對大型組織來說，這解決了另一個關鍵問題：你把所有關於安全政策、合規規則、設計系統限制和整合需求的要求放在哪裡？通常這些東西要麼存在某人的腦海中，要麼埋在沒人看的 wiki 中。

三個最適合的應用場景

場景 1：從零開始的新專案

當你開始新專案時，很容易就想直接開始寫程式。但是少量的前期工作來建立規格和計畫，可以確保 AI 建構你真正想要的東西，而不只是基於常見模式的通用解決方案。

最佳實踐：

• 花 30-60 分鐘寫規格
• 讓 AI 生成 3 個不同的技術方案
• 選擇最適合的開始實作

場景 2：在現有系統中加入新功能

這是規格驅動開發最強大的地方。為現有複雜程式碼庫添加功能很困難。透過為新功能建立規格，你強制澄清它應該如何與現有系統互動。

最佳實踐：

• 規格中明確標示整合點
• 計畫中列出所有相依性
• 任務要包含測試和文檔

場景 3：遺留系統現代化

當你需要重建遺留系統時，原始意圖往往已經隨時間流失。透過規格驅動開發流程，你可以在現代規格中捕捉核心業務邏輯，在計畫中設計全新架構，然後讓 AI 從頭開始重建系統。

最佳實踐：

• 先理解現有系統的「為什麼」
• 寫出理想狀態的規格
• 分階段遷移，降低風險

心態轉換

從今天開始，試著：

• 寫規格，而不是直接寫程式碼
• 描述意圖，而不是實作細節
• 相信 AI，但要驗證結果

結語：邁向意圖驅動的開發時代

我們正在從「程式碼是真相來源」轉向「意圖是真相來源」。因為 AI 讓規格變得可執行。當你的規格自動轉換成可運作的程式碼時，規格就決定了什麼會被建構。

Spec-Driven Development 不是另一個流程框架，而是一種新的思維方式。它讓我們能夠：

• 清楚表達意圖：不再有誤解和猜測
• 快速迭代想法：改規格比改程式碼容易
• 累積團隊智慧：規格成為知識的載體

最重要的是，它讓 AI 真正成為我們的夥伴，而不只是工具。

明天預告

明天我們將探討如何將 Spec-Driven Development 與我們的 AI-DLC Sprint 完美結合

參考資料：

• Spec-Driven Development
• Spec Kit