# 別再開盲盒式寫代碼：GitHub Spec Kit 如何讓 AI 編程變得靠譜

上週又跟 Claude 來回改了十幾次代碼。

你懂的，那種感覺——明明給了很清楚的需求，AI 卻生成了一堆看起來能跑但完全不是你要的東西。然後你再解釋一次，它又理解偏了。最後花了兩小時，還不如自己手寫來得快。

我開始懷疑，這些 AI 編程助手到底有沒有真的幫到忙，還是只是讓我變成了一個全職的「AI 保姆」？

直到我看到 GitHub 推出了一個叫 Spec Kit 的工具。


## 問題出在哪？

說實話，問題不在 AI，而在我們自己。

我們習慣了跟人類溝通的方式——「欸，幫我做個登入頁面」、「加個購物車功能」。人類夥伴會理解你沒說出口的那些：你的技術棧是什麼、這個功能要怎麼跟現有系統整合、有哪些邊界條件要考慮。

但 AI 不會。

它就像一個非常聰明但完全不了解你專案背景的外包工程師。你給它什麼，它就做什麼。你沒說清楚的部分？它就自己想像填補。

這就是為什麼我們常常覺得 AI 生成的代碼「很聰明但不實用」。

## Spec Kit 做了什麼？

GitHub 的團隊顯然也遇到了同樣的問題。他們在九月推出的 Spec Kit，本質上是把軟體工程最基本的原則——「先想清楚要做什麼，再動手寫代碼」——用一種 AI 能理解的方式重新包裝。

它不是什麼黑科技，也不是新的 AI 模型。

它就是一套工作流程，一套讓你跟 AI 溝通時「說人話但說得夠清楚」的框架。

Spec Kit 把整個開發過程分成四個階段：


### 1. Specify（規範階段）

你用自然語言描述你想做什麼，為什麼要做，要達到什麼效果。

重點是「為什麼」，不是「怎麼做」。

AI 會幫你把這些想法轉換成一份正式的規範文件（`spec.md`）。這份文件包含用戶故事、驗收標準、邊界情況——就像你跟產品經理開完會後寫的 PRD，但更技術化。

### 2. Plan（計劃階段）

有了規範，AI 會根據這份規範生成一個完整的技術實作計劃（`plan.md`）。

這裡會包含技術選型、架構設計、資料模型、API 規劃。它會告訴你「我打算用 Vite + SQLite 來做」、「資料庫結構是這樣設計的」。

你可以在這個階段檢查，確認方向對了再往下走。不用等到代碼寫完才發現「欸不對，我不想用這個框架」。

### 3. Tasks（任務階段）

計劃確認了，接著 AI 會把大計劃拆成一個個可執行的小任務。

不是那種「建立前端」這麼籠統的任務，而是「建立相簿列表元件」、「實作照片上傳 API」、「新增拖曳排序功能」這種具體到可以直接動手的層級。

### 4. Implement（實作階段）

到這裡，AI 才真正開始寫代碼。

但它不是一次把所有代碼丟給你，而是按照任務清單，一項一項完成。每完成一項，你可以檢查、測試、調整。出問題？沒關係，只影響這一小塊，改起來也快。

## 我實際用了一次

看起來很美好對吧？我也半信半疑。

上週末我試著用 Spec Kit 做一個照片管理應用——選這個案例是因為官方文件就是用這個當示範，我想看看能不能複製出同樣的效果。

### 初始化專案

安裝過程出乎意料的順暢：

uvx --from git+https://github.com/github/spec-kit.git specify init photo-manager

跑完這行命令，它會問你要用哪個 AI 助手。我選了 Claude Code，因為我已經習慣它的對話風格。

幾秒鐘後，專案結構就建好了。打開 VS Code，你會看到一堆 `.claude` 資料夾裡的命令檔案——這些就是 Spec Kit 的「魔法」，預先寫好的提示詞模板。

### 從 Specify 開始

我在 Claude Code 的對話框裡輸入 `/specify`，然後用大白話描述需求：

> 「我想做一個照片管理應用，讓使用者可以建立不同的相簿，上傳照片，並且用拖曳的方式調整照片順序。」

Claude 接手後，生成了一份詳細的 `spec.md`。我打開來看，裡面把我隨口說的需求整理成：

- 使用者故事（「身為使用者，我想要建立多個相簿來分類照片」）
- 驗收條件（「相簿名稱不可重複」、「照片支援 JPG、PNG 格式」）
- 邊界情況（「上傳檔案大小限制」、「拖曳時的順序更新邏輯」）

說真的，這份文件比我平常寫的設計文件還要完整。

### 接著是 Plan

輸入 `/plan`，Claude 開始生成技術計劃。

它選了 Vite 做前端建置工具，用原生 JavaScript（不用框架），後端用 Node.js + Express，資料庫選 SQLite。

更讓我驚訝的是，它連資料表結構都設計好了：

albums (id, name, created_at)
photos (id, album_id, filename, order, uploaded_at)

這個階段最大的好處是，如果你不喜歡這個技術選型，現在就可以調整，不用等到代碼都寫完才推倒重來。

### 拆解任務

`/tasks` 命令把整個專案拆成了十幾個小任務：

1. 建立專案基礎結構
2. 設定資料庫和資料模型
3. 建立相簿列表 UI
4. 實作建立相簿功能
5. 實作照片上傳
6. 實作拖曳排序
7. ... (還有幾個)

每個任務都很小，大概 15-30 分鐘可以完成的量。

### 開始實作

這是最神奇的部分。

Claude 會按照任務清單，一個一個完成。它不會一次生成幾千行代碼讓你不知道從哪裡看起，而是每次處理一個功能模組，生成幾十到一百多行代碼。

做完一個任務，你可以跑起來測試看看。有問題？馬上就知道是哪個環節出錯，調整起來很快。

大概兩個小時後，我有了一個可以跑的照片管理應用。

前端能建立相簿、上傳照片、拖曳排序。後端 API 處理檔案上傳和資料存取。資料庫正確記錄所有資料。

而且——這是重點——**代碼結構很清晰，註解很完整，跟我自己寫出來的不會差太多**。

## 這到底有什麼不同？

用完 Spec Kit，我想通了一件事。

傳統的 AI 編程方式，就像你直接把一個完全不懂你專案的工程師丟到編輯器前面說「開始寫」。當然會亂寫。

Spec Kit 的方式，是讓 AI 先當你的產品經理、架構師、專案管理，把所有「該想清楚的事情」都想清楚了，最後才動手寫代碼。

這才是軟體工程該有的樣子。

而且這樣做有幾個意外的好處：

**Token 效率更高**：因為 AI 知道它在做什麼，不會生成一堆「試試看」的代碼。我這次用下來，感覺 Token 用量大概只有以前的一半。

**代碼品質更好**：有了規範和計劃做基礎，生成的代碼都是有目的性的。不會出現「看起來有用但實際上不知道幹嘛」的代碼片段。

**可維護性強**：三個月後你再回來看這個專案，`spec.md` 和 `plan.md` 會告訴你當初為什麼這樣設計。比翻代碼註解清楚多了。

**團隊協作友善**：把規範文件丟給新成員，他們馬上就能理解專案在做什麼。不用花半天看代碼猜意圖。

## 不是萬能藥

當然，Spec Kit 也不是完美的。

它目前只支援 Claude Code、GitHub Copilot 和 Gemini CLI。如果你用 Cursor 或其他工具，可能需要自己調整一下。

而且規範階段需要你真的想清楚要做什麼。如果你自己都不確定需求，AI 也沒辦法幫你釐清——它只是把你的想法結構化，不會幫你做產品決策。

還有就是學習成本。習慣了「直接叫 AI 寫代碼」的人，可能會覺得這套流程太囉嗦。但說真的，這些步驟本來就該做，只是以前我們偷懶省略了。

## 值得一試嗎？

如果你符合以下條件，我強烈建議試試看：

- 你已經在用 AI 編程助手，但覺得效果不夠穩定
- 你的專案不是那種「寫完就丟」的一次性腳本，而是需要長期維護
- 你在團隊裡工作，需要跟別人協作
- 你想提升 AI 生成代碼的品質和可控性

Spec Kit 是開源的（MIT 授權），完全免費，代碼都在 [GitHub](https://github.com/github/spec-kit) 上。

設定很簡單，大概十分鐘就能跑起來。

## 未來會怎樣？

我覺得 Spec Kit 指出了一個方向：**AI 編程的未來不是讓 AI 更聰明，而是讓我們跟 AI 的溝通更結構化**。

就像我們從「用機器語言寫代碼」進化到「用高階語言寫代碼」，現在我們正在經歷「從隨意對話」進化到「結構化協作」的階段。

Spec Kit 只是開始。

也許未來會有更多工具幫我們把「人類的模糊想法」翻譯成「AI 能精確執行的指令」。也許 AI 會學會主動問問題，確認需求，而不是憑猜測行動。

但現在，如果你厭倦了跟 AI 來回修改代碼，厭倦了那種「開盲盒」式的不確定感，Spec Kit 可能是個不錯的解法。

---

**推薦資源：**

- [Spec Kit GitHub Repository](https://github.com/github/spec-kit)
- [官方部落格文章](https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/)
- [詳細教學影片](https://www.youtube.com/watch?v=-9obEHJkQc8)

試試看吧。

或許你會發現，原來 AI 編程可以這麼靠譜。