放假前最後一個工作日下午5點，你鼠標都摸好了，就等着準點開溜。產品經理走過來了：“有個小需求，用户列表加個篩選和排序，很簡單！老闆説客户明天就要看。”你嘴上説着好的，心裏已經演完了八百集血壓拉滿的內心劇。算了，反正看起來也不復雜。

你熟練地打開 Cursor，輸入：“幫我實現用户列表的篩選和排序功能。”三分鐘，真的只用了三分鐘，AI嘩啦啦吐出兩百行代碼。你隨手點了幾個案例，居然都能跑通。那一瞬間，你內心的獨白是：爽！這就是我+AI編程的魅力！下班！

然而，放假回來後，新需求來了：“加個高級篩選吧。”你信心滿滿地打開當初那份代碼，然後——愣住了。

data1、temp、result2… 這變量名是閉着眼睛取的嗎？if-else 層層嵌套，像俄羅斯套娃，改篩選，排序崩了；修排序，分頁掛了。你硬着頭皮讀了一小時，還是沒搞懂所有分支邏輯。最後，你咬着牙做了一個決定：這坨代碼，不能要了。

推倒重寫，花了兩天。

3分鐘寫完的代碼，用了2天來償還。

我們到底被AI偷走了什麼？

第一，代碼質量簡直在開盲盒。
AI生成的代碼是能跑，但為啥能跑？不知道。每次生成的結果都像抽卡，變量命名全憑AI心情，架構設計基本靠運氣。前期確實爽，像吃外賣——香就完了，誰管後廚乾不乾淨？問題是，技術債這玩意兒，利滾利起來，可比高利貸狠多了。

第二，我們成了“方向盤焦慮患者”。
簡單任務全扔給AI，自己只負責Ctrl+C/V；複雜架構也想靠AI，但又不敢完全放手。你在“全權託管”和“親力親為”之間反覆仰卧起坐，就是找不到那個該接管的瞬間。AI不像工具，倒像個不太靠譜的同事，永遠不知道他下一步會挖個什麼坑。

第三，我們正在喪失“架構手感”。
你有沒有發現？現在接到需求，第一反應已經不是“我該怎麼設計”，而是“我去問AI”。就像用慣了導航，沒了它你連小區門口的路都認不全。我開始害怕，再這樣下去，我們會不會從“工程師”退化成“AI的搬運工”？

那麼問題來了：這些困擾，是因為AI不夠聰明嗎？

恰恰相反。是因為AI太強了，強到我們還沒學會怎麼和它相處。

記住，你才是那個“定義問題”的人

我們必須想清楚一件事：在AI時代，程序員的真正價值到底是什麼？

AI是執行力超羣的工具，但它不是決策者。我們能理解業務、判斷價值、為結果負責——這才是我們不可替代的部分。所以正確的關係是：我們決定“做什麼”和“為什麼做”，AI負責“怎麼做”。

而不是我們説一句“幫我做個篩選”，AI就自由發揮，我們被動接盤。

這聽起來像是常識，但實際情況卻是越來越少人這樣做。你有沒有發現？以前開發至少還會查閲官方文檔、原型驗證，現在AI一來，直接從模糊需求跳轉到代碼，“意圖走樣”得連親媽都不認識。

根本原因就在於：我們缺了一份明確的“規格説明書”。

機-會

技術大廠，前端-後端-測試，新一線和一二線城市等地均有機-會，感興趣可以試試。待遇和穩定性都不錯~

你好，Spec-Kit：把“圖紙”交給AI

GitHub前不久推出了一個叫Spec-Kit的工具包，我試用後的最大感受是：跟AI結對編程有戲了。

它的理念非常直接：在寫代碼之前，先把規格説清楚。

就像裝修房子，你不會直接跟工人説“幫我裝一下”，而是先出設計圖、定水電、標材質。Spec-Kit做的就是這件事：它不是要取代AI，而是讓AI變得更有用。官方説法是，它能和GitHub Copilot、Cursor、Claude 這些工具無縫配合，讓你輸入得更準，AI輸出得更穩。

Spec-Kit四步工作法，請你記好：

1️⃣ /specify —— 別急着寫代碼，先説話
用自然語言説清楚你要什麼、邊界在哪、未來可能怎麼變
AI 會幫你整理成結構化的規格文檔

2️⃣ /plan —— 讓AI出方案，你來拍板
AI 根據規格生成技術方案：數據模型、設計模式、測試用例…
記住：你審核，你點頭，不是你被動接受

3️⃣ /tasks —— 拆任務，一步步來
生成可執行的任務清單，誰做什麼、先做啥後做啥，清清楚楚
推薦 TDD：先寫測試，再寫實現

4️⃣ /implement —— 帶着鐐銬跳舞
AI 開始寫代碼，但必須在規格和方案的框架內
你始終掌握主導權，AI 是執行者，不是設計師

這和vibe coding最大的區別在哪？
Vibe coding是：“AI，幫我做個功能。”→ AI隨意發揮 → 你祈禱別出bug。
Spec-Kit 是：“我先想清楚我要什麼。”→ AI按圖紙施工 → 你全程監工。
關鍵在於：誰在定義問題？

一個真實故事：30小時 vs 9小時

來看一個我親身經歷的例子：用户權限管理系統。一開始只要兩個角色：管理員和普通用户。但真實世界哪有這麼簡單？後續一定會迭代。

❌ 使用前：Vibe Coding模式

第一版（2小時）：對AI説“做個用户權限系統”，AI生成了一堆 if (role === 'admin')。測試通過，上線。
第一次迭代（4小時）：要加“審核員”角色。一看代碼我傻了，8處硬編碼！是該勉強改成 || 'reviewer'，還是重構？戰戰兢兢改完，生怕漏了一個地方。
第二次迭代（24小時，整整三天！）：產品説要支持“權限組”（一個用户多個角色）。結果發現之前的架構是 user.role（字符串），根本沒法擴展成 user.roles（數組）。只能推倒重來。

累計時間：30 小時。心態？每次迭代都想離職。

✅ 使用後：Spec-Kit模式

第一步（2小時）：寫規格 + 技術規劃

用户權限管理規格：

• 要支持靈活擴展，以後加角色是必然
• 用户可以有多個角色
• 權限檢查不能寫死，要可插拔
• 注意無權限、權限衝突的情況

AI據此給出方案：User、Role、Permission、UserRole 四張表，多對多關係，用策略模式做權限檢查。我審核通過。

第二步（6小時）：按任務列表實現，AI輔助寫代碼。

初版花了 8 小時，比vibe coding慢 6 小時。

但精彩的來了：

第一次迭代（5分鐘）：加“審核員”？在Role表裏插一條數據就行，代碼一行不用動。
第二次迭代（1小時）：加“權限組”？架構本來就是這樣設計的，只需要加一張PermissionGroup表和相關關聯。

累計時間：9.1 小時。心態平穩，甚至有點期待下一次需求。

數據不説話，但數據最震耳欲聾：

    
        維度
        Vibe Coding
        Spec-Kit
        差距
    


    
        初版速度
        2h
        8h
        慢 6h
    
    
        第一次迭代
        4h
        0.1h
        快 3.9h
    
    
        第二次迭代
        24h（重構）
        1h
        快 23h
    
    
        累計時間
        30h
        9.1h
        節省 20.9h
    
    
        代碼質量
        債台高築
        架構清爽
        天壤之別
    
    
        我的心態
        日常崩潰
        從容自信
        這才是人過的日子
    

你看，前期多花6小時，後期省下21小時。什麼叫“慢就是快”？這就是。

那三個困擾，是怎麼被解決掉的？

關於代碼質量：
規格就是最好的藍圖。變量名不再隨心所欲，邏輯結構有設計模式指引，邊界條件有測試覆蓋。AI就像一位嚴格按菜譜做菜的廚師，出品穩定，絕不翻車。

關於人機協作：
分工從沒這麼清晰過。我負責定義業務、審核方案、拍板決策；AI負責出方案、寫代碼、幹髒活累活。我是導演，AI是攝影師。戲怎麼演，我説了算。

關於架構能力：
不僅沒退化，反而被鍛鍊得更強。因為每次寫規格，都在逼我做需求分析；每次審核方案，都在訓練我的架構判斷；每次考慮擴展，都在培養我的前瞻思維。AI成了我的“架構陪練”，而不是“思考替代器”。

想試試？三步就能開始

▎第一步：安裝，五分鐘搞定

用 uv 裝（推薦，快）

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

或者 pip 也行

pip install git+https://github.com/github/spec-kit.git

裝完初始化一下：

specify init --here --ai cursor

除了 cursor，也支持 claude / chatgpt / copilot

項目裏會多一個 specs/ 文件夾，之後所有規格文檔都會規規矩矩躺在這裏。

▎第二步：從寫第一個規格開始

不用追求完美，就像平時和同事溝通那樣説人話就行：

/specify 我想做個用户篩選，能按註冊時間、狀態、角色來篩，條件可以組合，要分頁。
以後很可能還要加別的篩選維度。

AI會幫你把這段話整理成結構化的規格文檔。

▎第三步：讓AI出方案，你來審核

輸入 /plan，AI會基於規格給出技術方案。注意：這一步你一定要動腦子！ 審核它，挑戰它，而不是閉着眼睛通過。

接着用 /tasks 拆解任務，最後用 /implement 讓AI在框架內寫代碼。

我的實戰建議：

別一上來就挑戰超級複雜的功能，選個中等難度、以後可能會改的。
第一次用，不求完美，感受一下“先設計再編碼”的節奏。
有興趣的話，可以同一個功能用vibe coding和Spec-Kit各做一版，親自體會一下那個巨大的心理落差。

當然，Spec-Kit不是銀彈

下面這些情況，我勸你別用：

❌ 一次性腳本（用完就扔）
❌ 火燒眉毛的緊急修復（沒時間給你寫文檔）
❌ 純粹的學習實驗（方向都不明確）
❌ 簡單到幾行代碼就能搞定的功能

那什麼時候該用？我送你三個判斷問題：

這功能以後會改嗎？→ 會，用。
別人要看懂這代碼費勁嗎？→ 費勁，用。
出問題了你能快速定位嗎？→ 沒把握，用。

想象一下，還是那個放假前的下午5點，產品經理還是那句“有個小需求”。

但這一次，你沒有急着打開AI就開幹。你花了20分鐘，寫下一段簡單的規格：到底要什麼？邊界在哪？以後可能會怎麼變？然後你才把這份“圖紙”交給AI，讓它出方案，你來審核。

初版是多花了一小時。但兩週後產品要加新功能，你只用了十分鐘就搞定。更重要的是，你始終握着方向盤，代碼沒有變成一座你不敢碰的屎山。

AI時代，比的不是誰讓AI寫代碼更快，而是誰能把問題定義得更清楚。

Spec-Kit不是在讓你“慢下來”，而是在幫你“想清楚”。而想清楚了再動手，往往是最近的路。

記住，在這場人機協作中，我們，必須是那個定義問題並且最終拍板的人。

——轉載自：觀默