AI 寫的 code 一直要打掉重練？Spec Kit 想用一份可執行規範終結 vibe coding

我用 AI 寫 code 兩年多，最常打掉重練的，不是那些真的很難的演算法，而是一句話沒講清楚惹出來的麻煩。

「幫我做一個檔案上傳功能。」AI 三十秒丟回一坨能跑的東西，介面有了、錯誤處理也有了。然後我才發現：它預設存本地磁碟，而我要的是上傳到物件儲存；它沒驗副檔名；50MB 的檔直接讓記憶體爆掉；前端完全沒有上傳進度。於是我追加一句 prompt，它改；再追加一句，它改歪了別的地方，把剛才好好的錯誤處理弄不見了。一個下午過去，那個「三十秒就好」的功能還在原地打轉。

這不是模型笨。是我從頭到尾沒給它一份講清楚的合約。

三十秒生出來的東西，為什麼一個下午還收不了尾

這就是現在大家在做的事，英文叫 vibe coding——憑感覺對 AI 下指令，看它生出什麼，不對再喊它改。它的賣點是快，問題也是快：你把「想清楚要什麼」這件事，從動手前延後到了看到結果之後。

延後不等於省掉。需求遲早要補完，邊界遲早要劃清，只是現在改的對象，從你腦袋裡的設計，變成了一坨已經寫出來、還在長大的 code。改三次還行，改到第八次，新的 prompt 開始把前幾次講好的決定蓋掉——AI 不是忘了，是它老實照你最新一句話做，而你最新那句剛好沒提到前面那條約束。

我認為 vibe coding 真正的代價，不是寫得慢，是返工。它把規範的成本從事前挪到了事後，而事後永遠比事前貴。

2026 年 6 月初，GitHub 開源的 Spec Kit 衝破 10 萬星。它想處理的就是這件事。

Spec Kit 到底做了什麼

一句話：把流程從「讓 AI 直接 build」改成「先把規範寫成可執行的文件，再讓 AI 照規範實作」。

它不是又一個聊天框，而是一套裝進你現有 AI 工具的工作流。裝法是先用 uv 把 CLI 拉下來，再在專案裡初始化：

# 安裝 specify CLI（注意：它不在 PyPI 上，得從 git 裝，
# @vX.Y.Z 換成 Releases 頁面的最新版本號）
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z

# 在專案裡初始化，指定你用哪個 AI 工具
specify init my-project --integration claude

--integration 後面可以接 Claude Code、Copilot、Codex CLI、Gemini CLI、Cursor 等等，官方說支援 30 種以上的 AI coding agent。初始化之後，它會在你的 AI 工具裡塞進一組 slash command，整個流程照這個順序走：

/speckit.constitution   # 先定下這個專案的鐵則（技術棧、風格、不可碰的紅線）
/speckit.specify        # 寫需求和使用者故事——只講「要什麼」，不講「怎麼做」
/speckit.clarify        # 讓 AI 反問你規範裡含糊的地方（選用，但建議做）
/speckit.plan           # 根據規範產出技術方案
/speckit.tasks          # 把方案拆成一條條可執行的任務
/speckit.implement      # 照任務清單逐項實作

關鍵在前三步。constitution 是專案憲法，把「這專案一律用 PostgreSQL、不准引第三方 UI 庫、所有 API 回統一錯誤格式」這種會反覆出現的約束寫死一次，往後每一步都受它管。specify 強迫你把需求和實作分開——你只准描述行為，不准描述技術選型。clarify 則反過來，讓 AI 把你規範裡的洞挑出來反問你，例如「上傳大小上限是多少」「副檔名白名單還黑名單」。

我前面那個檔案上傳的下午，就是死在這三步全跳過了。

我一開始覺得這是在開倒車

老實說，第一眼看到 Spec Kit 我是有點抗拒的。

先寫一堆規範文件、定義驗收標準、拆任務，再讓人（這裡是 AI）照著做——這不就是瀑布式開發嗎？我們花了二十年才從「先寫三個月規格書再動工」掙脫出來，現在 AI 來了，反而要繞回去先寫文件？而且 AI 最大的好處不就是快，把這套流程套上去，快還剩多少？

我想了幾天，結論是：這個質疑問錯了方向。

瀑布式的問題從來不是「先寫規範」，而是「規範寫完就鎖死，之後不准改」。Spec Kit 的規範是活的——它是 code 的上游，你改規範、重跑 /speckit.plan，下游跟著重生。它要的不是一份簽字封存的合約書，是一份隨時可以重新編譯的原始碼。差別在這裡。

至於快，我換個算法就想通了。AI 寫 code 本來就快到不是瓶頸了，真正的瓶頸是「AI 寫完之後，你要花多久發現它寫的不是你要的、再來回喊它改」。Spec Kit 慢的是前面那十五分鐘的規範，省的是後面那兩小時的返工。對小東西不划算，對稍微有點規模的功能，這筆帳是賺的。

規範不是文件，是給 AI 的合約

不過先別管時間帳怎麼算。Spec Kit 真正讓我停下來想的是一個更根本的東西，而且就算你根本不裝它，這個觀念都值得借走。

我們一聽到「寫規範」就想到那種沒人看的 Word 文件，寫給人類看、寫完歸檔、跟 code 各過各的。但給 AI 的規範不一樣——它是 AI 接下來每一個決定的依據，是真的會被「執行」的。你在 specify 階段漏寫「檔案要驗毒」，AI 就真的不會驗，這個漏洞會原封不動長進 code 裡。

所以這份規範的精確度，直接決定產出的精確度。人類工程師會腦補——看到「做個上傳功能」會自己補上「大概要驗一下檔案吧」；AI 不會，你沒寫到的它不補。規範裡的每一個含糊，都是 code 裡的一個賭注。

/speckit.clarify 之所以重要，就是它把這些賭注在動手前一次攤開來問你。與其讓 AI 猜錯再返工，不如先花五分鐘把該講的講完。

但別把每個小腳本都塞進這套流程

講了這麼多好話，得潑點冷水，免得你以為從今天起每行 code 都該先寫憲法。

不是。一個三十行的資料清洗腳本、一個改 CSS 顏色的小調整、一次性的 migration——這些東西套 Spec Kit 的六步流程，純粹是儀式性的浪費。你寫 constitution 的時間夠你手刻三遍了。

Spec Kit 划算的區間，是那種「需求有好幾條、彼此會互相牽動、而且你還會回來改」的功能。一個有權限分級的後台、一條牽涉三方對接的金流、一套要支援多種匯出格式的報表。這種東西的特性是：邊界條件多到你光用嘴講會漏，而漏掉的每一條都是 AI 的一個錯誤實作。

判準很簡單：如果你能一口氣把需求講完不會漏，那就直接 vibe；如果你講到一半發現「啊還有那個情況」、「對了還要處理這個」，那就是該寫規範的訊號了。

我自己其實在用 Spec Kit 之前，就習慣讓 AI 先寫一份 plan、我審過再讓它動手——Claude Code 本來就有這個 plan 模式。Spec Kit 等於把這套「先想清楚再動手」的土法，做成了有版本、有結構、可重跑的標準流程。對一個人的小專案，我的土法夠用；對要交接、要協作、要長期維護的專案，標準化是有價值的。

規範寫好了，AI 就一定照做嗎

不一定。這是 Spec Kit 的宣傳不會強調的部分。

clarify 把含糊攤開來問你，但它管不到 implement 階段 AI 會不會自己飄。實作到一半，AI 還是可能為了「讓眼前這段 code 跑起來」繞過規範裡的某條約束——它不是不認得規範，是當下那個局部問題的引力比較大。所以 tasks 那層你還是得逐條看，規範不是免死金牌。

還有一個更現實的坑：需求會變，規範要跟著改。正確的做法是回頭改 spec、重跑 plan，讓下游一起重生；偷懶的做法是直接在 code 層面打補丁，繞過規範。一旦你開始打補丁，spec 和 code 就各說各話了，Spec Kit 的整個前提也跟著垮掉。規範是活的沒錯，前提是你真的回去維護它——這部分沒有工具能幫你，得靠紀律。