Vibe coding誕生僅一年，編程已變天
整理版優先睇
Vibe Coding 誕生一年，AI 編程已由語音取代鍵盤，但代價係失去對代碼嘅掌控，核心業務仍需深入理解。
呢篇文章係講 Andrej Karpathy 提出嘅「vibe coding」概念。佢用 Cursor Composer 加 Sonnet 呢套組合，完全靠語音輸入指令，唔使掂鍵盤，連 code 都唔使睇，就可以整到一個功能模塊。作者想帶出嘅問題係：呢種靠感覺嘅編程方式真係可行咩？代價係咩？佢嘅結論係：vibe coding 好適合一次性嘅週末項目，但如果係核心業務邏輯、效能關鍵路徑或者安全相關嘅 code，就必須深入理解，唔可以靠 AI。
一年前我哋仲討論緊 Copilot 能否補全函數，而家已經可以語音指揮 AI 完成整個功能。Karpathy 自己做嘅實驗係：用語音講「將側邊欄 padding 減少一半」，永遠 Accept All，唔睇 diff，遇到報錯就複製貼上，通常就搞掂。呢種做法嘅代價係失去對 code 嘅掌控，code 變成黑盒，出事時 AI 搞唔掂，自己又睇唔明，只能繞路或者重做。
作者用開車做比喻：自動駕駛可以帶你到目的地，但唔識駕駛嘅話，系統失靈就冇辦法。同樣，vibe coding 奪走咗編程嘅樂趣同調試能力。作者建議：UI 調整、樣式微調、重複性 CRUD 可以用 vibe；核心邏輯、效能關鍵、安全相關一定要深入理解。總括嚟講，工具進步好快，但編程本質冇變：理解問題、設計方案、實現功能，AI 幫到你實現，但理解同設計仲要靠你自己。
- Vibe coding 係指靠感覺語音指揮 AI 完成編程，唔需要睇 code，適合一次性項目。
- 具體方法係用 Cursor Composer + Sonnet，永遠 Accept All，報錯複製貼上，唔加註釋。
- 最大差異係失去對 code 嘅掌控，變成黑盒，調試能力歸零，出錯只能繞路或重做。
- 啟發：效率同樂趣之間要取捨，核心業務必須深入理解，UI 調整可以放手。
- 可行動點：UI、樣式、重複性 CRUD 用 vibe；核心邏輯、安全相關自己寫或深度 review。
Andrej Karpathy 嘅原推文
關於 vibe coding 概念嘅原始推文
Vibe Coding 係咩？
Andrej Karpathy 將 vibe coding 定義為
「完全交給感覺，擁抱指數級變化，甚至忘記代碼的存在」
。佢嘅實際操作係用 Cursor Composer 配合 Sonnet，連鍵盤都唔使，直接語音輸入，要求例如「將側邊欄嘅 padding 減少一半」。
佢嘅習慣係
永遠 Accept All，從唔睇 diff
，遇到報錯就複製貼上，唔加任何註釋。呢個就係 vibe coding 嘅標準流程。
代碼膨脹到佢睇唔明？冇問題，只要
能跑就得
。LLM 搞唔掂嘅 bug？繞過去，或者隨便改改直到佢消失。呢個唔係編程，而係
同 AI 傾偈，然後嘢就做出嚟咗
。
點解可行同代價
可行係因為 LLM 夠強大。Karpathy 用嘅 Cursor Composer 配 Sonnet，呢套組合已經強大到
你唔需要理解代碼，只需要描述需求
。就好似你唔需要理解汽車引擎原理都可以揸車一樣，但更準確嘅比喻係
你坐喺副駕駛，AI 揸車
，你只需要話「左轉」、「右轉」、「停車」。
呢個代價即係話，vibe coding 好適合
週末嘅一次性項目（throwaway projects）
，但唔適合需要長期維護嘅核心系統。
一年嘅變化
2024 年初 Karpathy 提出 vibe coding，2025 年初佢話「先得一年咋」。言下之意係變化太快：一年前我哋仲討論緊 Copilot 能否準確補全函數，而家已經可以語音指揮 AI 完成整個功能模塊。再過一年，可能連 vibe 都唔需要，直接話「我要一個電商網站」就有。
效率提升係真實嘅，但編程嘅樂趣同樣真實——理解系統點運作、掌控每個細節、解決棘手問題嘅成就感，呢啲係 vibe coding 俾唔到嘅。
更重要嘅係，當你唔理解代碼時，就失去咗調試能力。AI 生成嘅 code 出問題，AI 又搞唔掂，你
連 code 都睇唔明，就只能乾瞪眼
。
幾時應該用 Vibe Coding？
答案好簡單：
睇段 code 重唔重要
。
- 核心業務邏輯？必須深入理解。
- 效能關鍵路徑？必須深入理解。
- 安全相關代碼？必須深入理解。
- UI 調整？可以 vibe。
- 樣式微調？可以 vibe。
- 重複性 CRUD？可以 vibe。
將時間花喺刀刃上。
該深入嘅深入，該放手嘅放手
。作者仲建議，如果你未試過 Cursor，至少去體驗嚇，知道工具已經進化到邊個地步。
最後，記住：
工具在變，但編程的本質沒變——理解問題，設計方案，實現功能
。
寫喺前面
前幾日碌Twitter，見到Andrej Karpathy嘅一條推文，突然醒起一個事實：vibe coding呢個詞，先啱啱誕生一年咋。
一年。
由概念提出到成為現實，只不過用咗一年。呢個速度快到人有啲恍惚。
vibe coding係乜嘢
Karpathy俾佢嘅定義好有趣：完全交俾感覺，擁抱指數級變化，甚至忘記代碼嘅存在。
聽落好似好玄？我哋嚟睇下佢嘅實際操作。
佢用Cursor Composer配合Sonnet，連鍵盤都費事掂，直接語音輸入。佢提嘅需求蠢到咩程度？「將側邊欄嘅padding減少一半」——因為唔想揾嗰行代碼喺邊。
永遠撳Accept All從來唔睇diff。
遇到錯誤？複製貼上，唔加任何註釋。通常就搞掂咗。
代碼膨脹到佢睇唔明？冇問題，行得鬱就得。LLM搞唔掂嘅bug？繞過佢，或者亂咁改下，直到佢消失。
呢個唔係編程。呢個係同AI傾偈，然後啲嘢就整咗出嚟。
點解可行
因為LLM實在太勁喇。
Karpathy用嘅係Cursor Composer配Sonnet。呢套組合已經強大到咩地步？你唔需要理解代碼，只需要描述需求。
就好似你唔需要理解汽車引擎點樣運作，都可以揸車一樣。
但呢個比喻其實唔係太準確。更準確嘅比喻係：你坐喺副駕駛，AI喺度揸車，你只需要話「左轉」、「右轉」、「停車」。
架車點樣轉？引擎點樣運作？你唔知，亦唔關心。
代價係咩
Karpathy自己講得好清楚：呢個適合週末嘅一次性項目。
留意呢個定語。週末。一次性。throwaway。
點解？因為你失去咗對代碼嘅掌控。
代碼好似一個黑盒，你知道輸入輸出，但唔知入面發生咩事。平時冇問題，出問題嘅時候就麻煩喇。
AI搞唔掂點算？你自己都睇唔明。唯有繞過佢，或者推倒重來。
就好似你揸住一架自動駕駛嘅車，突然系統失靈。你唔識揸車，又唔識整車。你唯有等救援。
一年嘅變化
2024年初，Karpathy提出vibe coding呢個概念。
2025年初，呢條推文話：先一年咋。
言下之意係咩？變化太快喇。
一年前，我哋仲喺度討論Copilot可唔可以準確補完整個函數。而家，我哋已經可以語音指揮AI完成成個功能模塊。
再過一年呢？
會唔會連vibe都唔需要？直接話「我要一個電商網站」，然後就有咗？
我哋應該點做
老實講，我幾矛盾。
效率提升係真嘅。可以10分鐘搞掂嘅嘢，點解要花2個鐘？
但編程嘅樂趣都係真嘅。理解系統點樣運作，掌控每個細節，解決棘手問題嗰陣嘅成就感——呢啲係vibe coding俾唔到嘅。
更加重要嘅係，當你唔理解代碼嗰陣，你就失去咗除錯能力。
AI生成嘅代碼出咗問題，AI又搞唔掂，你可以點做？
如果你連代碼都睇唔明，就唯有乾瞪眼。
一個類比
令我諗起揸車呢件事。
自動駕駛出現之後，好多人話：以後唔需要學揸車喇。
但你會發現，真正嘅老司機反而更鍾意手波因為佢哋享受嘅唔係「到達目的地」，而係「揸車」呢個過程本身。
編程都係一樣。
vibe coding可以幫你到達目的地，但佢奪走咗揸車嘅樂趣。
你想要嘅係咩？快啲到達？定係享受過程？
幾時應該vibe
我覺得答案好簡單：睇呢段代碼重唔重要。
核心業務邏輯？一定要深入理解。
效能關鍵路徑？一定要深入理解。
安全相關代碼？一定要深入理解。
UI調整？可以vibe。
樣式微調？可以vibe。
重複性CRUD？可以vibe。
將時間使喺刀口上該深入嘅就深入，該放手嘅就放手。
總結
vibe coding先啱啱一年咋。
但佢已經改變咗唔少人嘅工作方式。
呢個係好事定係壞事？我唔知。
我只知道，工具喺變，但編程嘅本質冇變——理解問題，設計方案，實現功能。
AI可以幫你實現，但理解同設計依然要靠你自己。
至少而家係咁。
P.S. 如果你未試過Cursor，建議去體驗下。無論你接唔接受vibe coding，至少應該知道工具已經進化到咩地步。
參考資料
Andrej Karpathy嘅原推文：https://x.com/karpathy/status/1886192184808149383
寫在前面
前幾天刷推特，看到 Andrej Karpathy 的一條推文，突然意識到一個事實：vibe coding 這個詞，才誕生一年。
一年。
從概念提出到成為現實，只用了一年。這速度快得讓人有點恍惚。
vibe coding 是什麼
Karpathy 給它下的定義很有意思：完全交給感覺，擁抱指數級變化，甚至忘記代碼的存在。
聽起來很玄學？我們來看看他的實際操作。
他用 Cursor Composer 配合 Sonnet，連鍵盤都懶得碰，直接語音輸入。提的需求蠢到什麼程度？"把側邊欄的 padding 減少一半"——因為懶得找那行代碼在哪。
永遠點 Accept All。從不看 diff。
遇到報錯？複製粘貼進去，不加任何註釋。通常就修好了。
代碼膨脹到他看不懂了？沒關係，能跑就行。LLM 修不好的 bug？繞過去，或者隨便改改，直到它消失。
這不是編程。這是和 AI 聊天，然後東西就做出來了。
為什麼可行
因為 LLM 太好了。
Karpathy 用的是 Cursor Composer 配 Sonnet。這套組合已經強大到什麼程度？你不需要理解代碼，只需要描述需求。
就像你不需要理解汽車引擎的工作原理，也能開車一樣。
但這個比喻其實不太準確。更準確的比喻是：你坐在副駕駛，AI 在開車，你只需要說"左轉"、"右轉"、"停車"。
車怎麼轉的？發動機怎麼工作的？你不知道，也不關心。
代價是什麼
Karpathy 自己說得很清楚：這適合週末的一次性項目。
注意這個定語。週末。一次性。throwaway。
為什麼？因為你失去了對代碼的掌控。
代碼像一個黑盒，你知道輸入輸出，但不知道里面發生了什麼。平時沒問題，出問題的時候就麻煩了。
AI 修不好怎麼辦？你自己也看不懂。只能繞過去，或者推倒重來。
這就像你開着一輛自動駕駛的車，突然系統失靈了。你不會開車，也不懂修車。你只能等救援。
一年的變化
2024 年初，Karpathy 提出 vibe coding 這個概念。
2025 年初，這條推文說：才一年而已。
言下之意是什麼？變化太快了。
一年前，我們還在討論 Copilot 能不能準確補全函數。現在，我們已經可以語音指揮 AI 完成整個功能模塊。
再過一年呢？
會不會連 vibe 都不需要了？直接說"我要一個電商網站"，然後就有了？
我們該怎麼辦
說實話，我挺矛盾的。
效率的提升是真實的。能 10 分鐘做完的事，為什麼要花 2 小時？
但編程的樂趣也是真實的。理解系統如何運作，掌控每個細節，解決棘手問題時的成就感——這些是 vibe coding 給不了的。
更重要的是，當你不理解代碼時，你就失去了調試能力。
AI 生成的代碼出了問題，AI 又修不好，你該怎麼辦？
如果你連代碼都看不懂，就只能乾瞪眼。
一個類比
這讓我想起開車這件事。
自動駕駛出現後，很多人說：以後不需要學開車了。
但你會發現，真正的老司機反而更喜歡手動擋。因為他們享受的不是"到達目的地"，而是"駕駛"本身。
編程也一樣。
vibe coding 能幫你到達目的地，但它奪走了駕駛的樂趣。
你要的是什麼？快速到達？還是享受過程？
什麼時候該 vibe
我覺得答案很簡單：看這段代碼重不重要。
核心業務邏輯？必須深入理解。
性能關鍵路徑？必須深入理解。
安全相關代碼？必須深入理解。
UI 調整？可以 vibe。
樣式微調？可以 vibe。
重複性 CRUD？可以 vibe。
把時間花在刀刃上。該深入的深入，該放手的放手。
總結
vibe coding 才一年。
但它已經改變了很多人的工作方式。
這是好事還是壞事？我不知道。
我只知道，工具在變，但編程的本質沒變——理解問題，設計方案，實現功能。
AI 能幫你實現，但理解和設計還得靠你自己。
至少現在是這樣。
P.S. 如果你還沒試過 Cursor，建議去體驗一下。不管你接不接受 vibe coding，至少應該知道工具已經進化到什麼程度了。
參考資料
Andrej Karpathy 的原推文：https://x.com/karpathy/status/1886192184808149383