2025 年 2 月，前 OpenAI 聯創 Andrej Karpathy 在 X 上隨手丟了一條推文。他叫這種寫代碼方式叫 vibe coding——「fully give in to the vibes, embrace exponentials, and forget that the code even exists」。完全跟著感覺走，擁抱指數增長，忘記代碼本身的存在。
14 個月後的今天，這條推文已經演變成一個 66 億美元的產業。Collins Dictionary 把 vibe coding 評為 2025 年度詞。MIT Technology Review 把它列入 2026 年 10 大突破科技。美國 92% 的開發者每天都在用 AI 寫代碼。
聽起來像是 AI 寫代碼的勝利。但上週，2026-05-09，GitHub 親手開了一個新的 repo，叫 Spec-Kit。讀完介紹我就笑了——它要對付的，就是 GitHub 自己平台上長出來的那波 vibe coding。
5 天，9 萬星，8 千 fork。GitHub 上週悄悄踩了煞車。
Spec-Kit 到底是什麼？一句話：先給規格書，AI 才下筆
傳統的 AI 寫代碼流程，是你打開 Cursor 或 Claude Code，丟一句「幫我做一個照片整理 App」，然後 AI 就嘩啦啦生出一堆代碼。能跑就算贏，bug 慢慢修。
這就是 vibe coding。你不知道它寫了什麼，你也不在乎，反正能跑就好。
Spec-Kit 把這個流程改成四步，每一步都產出一份 markdown 文件，AI 必須照著文件走：
- Constitution（憲法）——先寫專案的「治理原則」：代碼品質要求、測試標準、UX 一致性、效能門檻。AI 之後做的所有決策，都要符合這份憲法。
- Specify（規格書）——描述要做什麼、為什麼做。重點放在 what 和 why，不寫技術棧。
- Plan（實作計畫）——這時才指定技術棧（Vite、SQLite、vanilla JS……）、架構決策。
- Tasks + Implement（任務拆解 + 實作）——把計畫拆成一個個可執行的小任務，AI 依序完成。
用法簡單到離譜。安裝完 specify CLI 後，在你的 AI agent 裡敲：
/speckit.constitution Create principles focused on code quality, testing standards... /speckit.specify Build an application that can help me organize my photos... /speckit.plan The application uses Vite with minimal libraries... /speckit.tasks /speckit.implement
五個斜杠指令。從一句話想法到能跑的 App。中間每一步都有 markdown 文件當作 AI 的「劇本」，不是讓 AI 自己即興演出。
為什麼 GitHub 自己要踩煞車？三個血淋淋的理由
第一，vibe coding 寫出來的東西沒人能維護。
新創團隊用 Cursor 兩週弄出個 MVP，看起來能跑。第三週要加新功能，AI 把舊代碼改得面目全非。第四週要修 bug，沒人記得當初為什麼那樣寫。我見過好幾家公司把 vibe coding 的 codebase 整個丟掉重寫，原因不是技術問題，是連寫的人自己都看不懂了。
第二，AI 越強，vibe coding 的成本越高。
GPT-5.5 在 SWE-bench 已經做到 82.7%。Claude Opus 4.7 是 69.4%。模型越強，一次 vibe 出來的代碼量越大。問題是——錯誤也是指數放大的。Karpathy 自己上個月承認，他用 AI 寫的東西也得花一週理解才能改。當「忘記代碼本身」變成「永遠看不懂自己的 codebase」，這就不是擁抱指數，是被指數爆頭。
第三，企業根本不敢讓 AI 隨便寫。
銀行、保險、醫療、政府的工程主管問的第一個問題永遠是：這段代碼為什麼這樣寫？合規嗎？能審計嗎？vibe coding 在 toy app 很爽，但企業要的是「我能告訴稽核這段代碼來自哪份 spec」。Spec-Kit 剛好填這個洞——每段代碼都有一份規格書做 paper trail。
vibe coding 是給玩具用的，spec-driven 是給生產用的。GitHub 不是在打臉 Karpathy，是在告訴你：玩夠了，回來幹活。
跟現有工具比，Spec-Kit 強在哪裡？
截至 2026 年 5 月，AI coding 工具的主流玩家有這幾個：
| 工具 | 定位 | 限制 | 支援 Spec-Kit？ |
|---|---|---|---|
| Cursor | IDE-based AI 編輯器 | 仍偏 vibe coding 流程 | ✅ 透過 specify CLI |
| Claude Code | CLI agent，Anthropic 官方 | 缺結構化 spec 流程 | ✅ 30+ 官方整合之一 |
| GitHub Copilot | autocomplete + chat | 適合補完，不適合 0→1 | ✅ 原生整合 |
| Gemini CLI / Codex CLI | 大廠的 CLI 助手 | 各自為政，無統一規格 | ✅ |
| Windsurf / Forge / Kiro | 新一代 IDE-agent | 百花齊放，缺標準 | ✅ |
注意這張表的最後一欄。Spec-Kit 不挑 AI——它支援 30+ 個 coding agent，包括 Copilot、Cursor、Claude、Codex、Gemini、Windsurf、Forge、Kiro。換句話說，它不是要取代你的 AI，它是給你的 AI 加一個劇本。
這也是 GitHub 真正聰明的地方。它沒有再做一個 AI，而是做了「給所有 AI 用的標準流程」。標準贏家通吃，這個位置一旦佔住，所有 AI 廠商都得來跟它整合。
實際試一下：5 分鐘安裝，10 分鐘跑通
我把 Spec-Kit 接到 Claude Code 上實測一輪，記錄一下流程。前提是你已經裝好 Python 3.11+ 跟 uv。
- 安裝 Specify CLI：
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git - 初始化專案：
specify init my-photo-app --integration claude（也可以改 cursor、copilot、codex 等） - 進入專案目錄，打開 Claude Code
- 依序敲入
/speckit.constitution、/speckit.specify、/speckit.plan、/speckit.tasks、/speckit.implement - 每一步 Claude 會生出一份 markdown，存在
.specify/目錄底下。你看得到、改得了、commit 得進 git。
跟以前 vibe coding 最大的差別是：當 AI 寫到一半亂掉，你不用整個重來。你只要回去改前一步的 markdown，然後讓 AI 重新從那一步開始。這對寫過 AI agent 的人來說是天大的解放——終於不用每次都從零開始喊一輪。
什麼人現在就該用？什麼人可以再等等？
現在就該用：
- 用 AI 寫 side project 但每次都寫到一半放棄的人——你缺的不是 AI，是流程
- 團隊 codebase 已經被 AI 寫得四不像，正在找救命方法的工程主管
- 想做 AI agent 應用但被「上下文管理」搞瘋的開發者
- 準備把 AI 寫代碼導入企業流程、需要審計痕跡的 IT 部門
可以再等等：
- 只是想快速做個 demo 給投資人看的——Spec-Kit 會拖慢你 30%，反而不如直接 vibe
- 單純改個 Bug、寫個小 script 的——殺雞用牛刀
- 還沒被 AI 寫代碼坑過的——你會覺得這些流程很多餘，等被坑一次就懂了
Tony 的判斷：這意味著 AI 寫代碼 2.0 時代開始了
過去兩年，AI 寫代碼的競賽是「誰的模型更會猜你想要什麼」。Cursor、Copilot、Claude Code、Codex 全在比這件事。
Spec-Kit 開了第二條賽道：誰的「規格書 → 代碼」轉換最可靠。這條賽道沒有模型壁壘，門檻是流程設計、prompt 工程、跨工具整合。GitHub 用 spec-kit 把這條賽道的標準先佔住，後面所有人都得照它的格式來。
對普通開發者來說，這代表三件事：
- 學會寫好規格書，比學會 prompt 更重要。半年內，AI coding 的核心技能會從「會 prompt」變成「會把需求拆成 spec」。
- vibe coding 不會消失，但會降級到玩具區。你週末做 hackathon 還可以 vibe，週一進公司會被要求附上 spec markdown。
- 產品經理跟工程師的邊界會更模糊。spec-kit 的 constitution 跟 specify 步驟其實是 PM 的工作。會寫 spec 的 PM 直接用 AI 上線 MVP，會 vibe 的工程師反而會被淘汰。
我自己已經把 Spec-Kit 加進 daily workflow。下一篇我會拆一個具體案例：怎麼用 Spec-Kit + Claude Code 做出一個能用的交易訊號回測工具，從 spec 到代碼一個下午搞定。有興趣的訂閱一下，這篇不會在推特發完整版。
結論：別再嘲笑「先寫文件」了
過去 20 年，「先寫規格書再寫代碼」被新創圈嘲笑為瀑布式開發、是過時的企業流程、是阻礙創新的官僚產物。敏捷、lean、MVP、vibe coding——每一波都在嘲笑這件事。
結果 14 個月後，AI 強到可以一次寫 1000 行代碼，大家才發現：當「寫代碼」這件事被 AI 自動化了，剩下的工程價值就只在規格書裡。
GitHub 5 天 9 萬星，不是在跟風 vibe coding。是在告訴所有人：vibe 完了，回來認真寫 spec。
下次有人跟你說「AI 取代了寫代碼的人」，你回他一句：是的，所以現在能值錢的，是會寫規格書的人。
免責聲明：本文為 AI 工具使用心得分享，所有數據引用自 GitHub 官方 README、GitHub Blog、Visual Studio Magazine 等公開來源（2026-05-14 查核）。AI 工具版本與功能更新頻繁，建議以官方文件為準。本文不構成任何投資或職涯建議。
發表迴響