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

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

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

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

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

從混亂到有序：Spec Kit 帶來的轉變

問題出在哪？

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

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

但 AI 不會。

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

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

Spec Kit 做了什麼？

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

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

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

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

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 命令把整個專案拆成了十幾個小任務：

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

每個任務都很小，大概 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 上。

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

未來會怎樣？

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

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

Spec Kit 只是開始。

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

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

推薦資源：

試試看吧。

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

本文最初發布於 HackMD @BASHCAT。

搜尋此網誌

BASHCAT