用了Spec-kit才知道，原先的AI編程白玩了..
整理版優先睇
Spec Kit 為 AI 編程注入清晰思維：先理清需求，再寫代碼
呢篇文章係由一個成日畀 AI 編程工具激到跳起嘅開發者所寫。作者開頭直接喺 Claude Code、Cursor 嗰類工具落 prompt 叫 AI 寫功能，點知成日出現理解錯需求、改完又改嘅情況，浪費咗好多時間。作者嘅結論係：問題唔係 AI 理解能力差，而係我哋自己冇畀夠清晰嘅指引。真正有效嘅方法係 Spec-Driven Development，即係先將需求、技術方案、任務拆解清楚，先至畀 AI 動手。
GitHub 開源嘅 Spec Kit 就係幫手做呢件事嘅工具。佢提供咗一套規範流程：先用 /speckit.constitution 訂立項目規範（即係項目的「憲法」），再用 /speckit.specify 詳細描述功能需求（呢個階段唔好提技術棧），然後用 /speckit.plan 制定技術方案，再用 /speckit.tasks 拆解成任務清單，最後用 /speckit.implement 一次過執行。呢個流程確保 AI 喺清楚嘅約束下寫代碼，唔會亂嚟，生成嘅代碼質量明顯高好多。
呢種做法唔單止提升效率，更重要係改變咗開發者嘅角色 — 我哋唔再係同 AI 鬥快打字，而係需要訓練自己更清晰咁定義問題、設計架構、引導 AI。Spec Kit 嘅出現，可能係 AI 時代軟件開發流程嘅一個新標準，由 GitHub 官方開源，支援市面上大部分 AI 編程工具。
- 核心結論：Spec-Driven Development 比直接畀 AI 寫 code 更有效，因為先理清需求再執行，大幅減少返工。
- 關鍵方法：Spec Kit 提供五步流程：定憲法、寫規格、規劃技術、拆任務、一鍵實現。
- 重要差異：傳統方式係求其一句話就叫 AI 開工，成日要改；Spec Kit 係先規劃後執行，效果天淵之別。
- 核心啟發：AI 時代開發者嘅價值唔再係打字速度，而係理清問題同引導 AI 嘅能力。
- 可行動點：安裝 spec-kit CLI，喺 Claude Code、Cursor 等工具中用 /speckit 命令即可開始。
GitHub - spec-kit
官方開源項目，包含完整文檔與安裝指引
直接叫 AI 寫 code？中伏多過中獎
作者最初用 AI 編程工具嘅方式好簡單：打開 Claude Code 或者 Cursor，扔一句「幫我寫個 XX 功能」，然後 AI 就瘋狂輸出代碼。表面上效率好高，但跑起嚟先發現完全貨不對辦，例如想整用戶管理系統，AI 就整咗個博客後台出嚟。
理解錯需求
於是就不斷改需求，AI 又繼續寫，又繼續發現問題，結果浪費咗成個下午。作者反省呢個就係傳統開發最忌諱嘅「邊寫邊改需求」，只係寫 code 嘅由人變咗 AI，但問題根本冇解決。
Spec-Driven Development：先諗清楚先做
Spec Kit 嘅理念完全唔同，佢提出一個叫 Spec-Driven Development 嘅概念。簡單講就係：先唔好急住寫 code，而係將需求、技術方案、任務分解呢啲嘢全部搞清楚，先至畀 AI 動手。
作者比喻：以前係「做個 XX 功能 → AI 直接開寫 → 發現唔啱 → 改需求 → 繼續寫 → 繼續改⋯」，用咗 Spec Kit 之後就變成「定義清楚需求 → 確定技術方案 → 拆解成任務清單 → AI 一次過搞掂」。呢個就係先規劃好路線先出發，同埋邊行邊睇地圖嘅分別。
五步流程，由混亂變清晰
Spec Kit 嘅流程分五步，每一步都對應一個命令，作者用保齡球網頁版遊戲做例子示範。
- 用 /speckit.constitution 訂立項目憲法，例如代碼質量、測試覆蓋率、用戶體驗一致性等規則，AI 之後所有 code 都會跟住呢啲規矩。
- 用 /speckit.specify 詳細描述需求，呢個階段完全唔好提技術棧；Spec Kit 會生成一份功能規格說明書，包含用戶故事、驗收標準等。
- 用 /speckit.plan 制定技術方案，先講清楚整體架構、數據模型、API 設計、點解揀某啲技術。
- 用 /speckit.tasks 將方案拆成任務清單，標明先後次序同依賴關係，每個任務會列出要改嘅檔案路徑。
- 最後用 /speckit.implement，AI 就會跟住憲法、規格、方案、任務一次過執行，作者話佢就飲住咖啡等佢做完。
呢份任務清單就係 AI 嘅施工圖紙
作者話最關鍵係今次生成嘅 code 質量好高，結構清晰、註釋完整、測試都寫埋，同以前改極都錯嘅體驗完全唔同。
AI 時代，開發者嘅新價值
作者總結：之前以為係 AI 理解能力差，而家先知係畀嘅資訊太模糊。AI 唔係人，冇辦法「意會」，一定要用清晰結構化嘅方式溝通。Spec Kit 就係將呢套溝通方法系統化。
AI 時代嘅編程，唔係寫得更快，而係思考得更清晰
當 AI 可以一分鐘生成一千行 code，開發者嘅價值在於理清問題、設計合理架構、引導 AI 交付高質量軟件。GitHub 開源 Spec Kit，唔係單純推一個產品，而係喺定義 AI 開發流程嘅標準，支援市面上幾乎所有 AI 編程工具（Claude Code、Copilot、Cursor、Windsurf、Gemini CLI 等）。
最近在用 AI 編程工具寫項目,真的快被氣死了。
你說這 AI 吧,寫代碼倒是賊快,噼裏啪啦一分鐘給你生成一堆。
但是你仔細一看,好傢伙,完全理解錯我的需求了。
我讓它做個用戶管理系統,它給我整了個博客後台...
改了三四次需求,最後發現還不如我自己寫來得快。
這不,又浪費了一下午時間。
直到前幾天,我想起來了朋友很久以前就給我推薦 GitHub 官方開源的這個 Spec Kit。
說 Vibecoding 一定要去試試，堪比架構師在指導你的開發。
一開始我是不屑一顧的，但用了快一週,我悟了 - 原來不是 AI 理解能力不行,是我的打開方式不對。
最前開我用 AI 編程,基本上就是:
打開 Claude Code 或者 Cursor,直接扔一句話:"幫我寫個 XX 功能"。
AI 就開始瘋狂輸出代碼。
看着屏幕上滾動的代碼,心裏還挺爽 - 這效率,真高!
但是跑起來一看,emmm... 這是個什麼玩意兒?
於是開始改需求,AI 又繼續寫,我又繼續發現問題,然後又繼續改...
這不就是傳統開發裏最忌諱的"邊寫邊改需求"嗎?
只不過寫代碼的從人變成了 AI,但問題還是那個問題 — 需求根本沒理清楚,就開始動手了。
而 Spec Kit 的思路完全不一樣。
它提出了一個叫 Spec-Driven Development 的概念。
簡單來說就是:先別急着寫代碼,咱們先把需求、技術方案、任務分解這些事情都整明白了,再讓 AI 動手。
對比一下:
我最開始的做法:
"做個 XX 功能" → AI 直接開寫 → 發現不對 → 改需求 → AI 繼續寫 → 又不對 → 繼續改...
用 Spec Kit 之後:
定義清楚需求 → 確定技術方案 → 拆解成任務清單 → AI 一次性搞定
這就像是,以前是讓 AI 邊走邊看地圖,現在是先把路線規劃好了再出發。
效率差了不是一點半點。
說實話,剛開始用 Spec Kit 的時候,我是有點不耐煩的。
心想,這玩意兒搞這麼多步驟和文檔,不是更慢了嗎?
但是真用起來,我發現這個流程設計得是真的合理。
第一步:給項目立規矩
第一次用的時候,它讓我先執行 /speckit.constitution 命令。
我當時還納悶,這是要幹啥?
原來是讓我給項目定個"憲法"——說白了就是告訴 AI:"我這個項目有什麼規矩,你得按我的標準來"。
比如:
• 代碼質量要達到什麼水平 • 測試覆蓋率不能低於多少 • 用戶體驗要保證什麼一致性 • 性能指標有啥要求
這一步雖然要花點時間,但後面你就會發現,這是真的值。
AI 後面生成的所有代碼,都會嚴格按照你這個"憲法"來,不會亂搞了。
第二步:說清楚到底要做什麼
然後用 /speckit.specify 命令,詳細描述你的需求。
重點來了:這個階段不要提技術棧!
對,你就說你要做什麼,為什麼做,但是別說用啥技術。
我第一次試的時候,寫了這麼一段:
"保齡球的網頁版遊戲，積分機制，支持雙人對局。"
就這樣簡單描述一下。
然後 Spec Kit 就給我生成了一份超詳細的功能規格說明書。
裏面有用戶故事、功能需求、驗收標準,該有的都有。
看完之後我才意識到,我之前跟 AI 說的那些需求,實在是太模糊了...
第三步:現在才談技術方案
需求理清楚了,接下來用 /speckit.plan 命令,這時候才開始說技術棧。
"使用HTML等前端技術棧“
Spec Kit 就給我整了份技術實施方案,包括:
• 整體架構怎麼設計 • 數據模型長什麼樣 • API 怎麼規劃 • 為啥選這些技術(這個很重要,不是瞎選的)
第四步:任務拆解得明明白白
接着用 /speckit.tasks 命令,把方案拆成一個個小任務。
這一步生成的 tasks.md 文件,我真的服了。
它會告訴你:
• 哪些任務得先做(比如先搞數據模型,再搞 API) • 哪些任務可以同時做(標了個 [P])• 每個任務要改哪些文件,路徑都寫得清清楚楚 • 如果要寫測試,還會把測試任務也排進去
這份任務清單,就是 AI 幹活的"施工圖紙"。
第五步:一條命令,坐等收工
前面準備工作都做完了,最後就一句命令 /speckit.implement。
AI 就開始按照:
• 你定的項目規矩 • 詳細的功能規格 • 技術實施方案 • 任務清單
一個任務一個任務地執行。
我就看着進度條走,喝着咖啡,等它幹完。
最關鍵的是,這次生成的代碼,質量是真的高。
結構清晰,註釋完整,測試也寫了,跑起來也沒啥大問題。
這和我以前那種"改了三遍還是不對"的體驗,完全是兩回事。
以前總覺得是 AI 理解能力不行,經常寫錯。
現在才明白,是我給的信息太少、太模糊了。
AI 不是人,它沒法像人一樣"意會"。你得把事情說清楚。
Spec Kit 就是幫你把這些"說清楚"的事情繫統化了。
並且 GitHub 把這東西完全開源了。
而且支持的 AI 工具特別全:
✅ Claude Code(我在用這個)
✅ GitHub Copilot
✅ Cursor(很多人用)
✅ Windsurf
✅ Gemini CLI
✅ 還有一堆...
基本上你能用的 AI 編程工具,它都支持。
之前我們用 AI,本質上還是人的開發方式,只不過讓 AI 來寫代碼。
但 Spec Kit 不一樣,它是真的為 AI 設計的開發流程:
• AI 擅長理解結構化的東西(規格說明書) • AI 擅長按清單執行(任務列表) • AI 擅長在明確約束下寫代碼(項目規範)
所以用起來特別順。
不是在和 AI "對抗",而是在和 AI "協作"。
怎麼開始用?
如果你也想試試,很簡單。
第一步:裝個 CLI 工具
打開終端,執行:
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git第二步:初始化項目
進到你的項目目錄:
specify init .注意那個 .,表示在當前目錄初始化。
或者創建新項目:
specify init my-project第三步:打開你的 AI 工具
比如我用的是 Claude Code。
在項目目錄裏打開,然後輸入 /speckit,就能看到所有命令了。
End
過去三年,我們目睹了 AI 從 Copilot 到 Claude Code,從 ChatGPT 寫代碼到 Cursor 全家桶,所有人都在說 AI 讓編程變快了。
但 Spec Kit 告訴我們的是另一件事 — AI 時代的編程,不是寫得更快,而是思考得更清晰。
你想想看,當 AI 可以一分鐘生成一千行代碼,開發者的價值在哪?
不是敬鍵盤的速度,而是把問題理清楚的能力。
不是記住多少語法,而是設計出合理架構的功底。
不是和 AI 比速度,而是學會引導 AI 交付高質量軟件的智慧。
而 Spec Kit 就是在告訴我們,如何在 AI 時代做一個“真正有價值的開發者”。
更有意思的是,這個工具是 GitHub 官方開源的。
你品品 GitHub 這個動作 - 作為全球最大的代碼託管平台,他們比誰都清楚,AI 編程的未來不在於更快的代碼生成,而在於更規範的開發流程。
所以他們率先把這套方法論開源出來,支持市面上幾乎所有的 AI 編程工具。
這不是在推一個產品,而是在定義一個標準。
那麼,當越來越多的開發者掌握了這種協作方式,當越來越多的 AI 工具開始支持這套標準,整個軟件開發行業會發生什麼樣的變化?
這個想象空間,真的太大了。
項目地址：https://github.com/github/spec-kit
如果這篇文章對你有幫助,歡迎點個「在看」,讓更多被 AI "理解錯需求"困擾的開發者看到。
加 V 可領取一份大禮包，包含 Dify/Coze 教程以及海量電子書資料。
這裏是艾倫，一個專注於用 AI 在自媒體和職場提效的公眾號主理人。
聲明：本文內容 90% 以上都是我自己的原創撰寫，僅在少量環節藉助了人工智能 AI 工具輔助。但所有文字都經過作者本人嚴格審閲與多重核實。文中配圖均來自真實可驗證的素材或 AI 自主生成的原創作品。文章的出發點在於分享積極向上的價值觀，不含低俗或不良導向，特此說明。