Vibe Coding 是什麼？從直覺寫程式看開發方式的轉變

嗯…今天來聊聊一個最近很紅，但又有點…你知道的，有點玄的東西。叫做「Vibe Coding」。

你直接翻譯，大概是「憑感覺寫程式」？這詞是 OpenAI 的那個 Andrej Karpathy 在 2025 年初提出來的，聽起來超酷。簡單講，就是你不用真的去寫那些很繁瑣的程式碼，你只要出一張嘴，用自然語言去跟 AI 說：「欸，我想要一個 App，它可以掃描我冰箱裡的東西，然後提醒我蔬菜又買太多了」，然後…啪，AI 就把程式碼給你吐出來。

老實說，這聽起來有點像科幻小說。但它又不是完全的空想，因為現在很多工具，像是 Cursor 或 Replit，已經有類似的功能了。你跟它講話，它就幫你生成程式碼。這整個過程，就變得很…很「憑感覺」。

重點一句話

我自己是覺得，Vibe Coding 讓開發速度變快很多，超誘人，但如果沒有像 Azure Well-Architected Framework 這種穩固的架構在底下撐著，那你蓋出來的東西，說真的，可能比紙糊的還不牢靠。

聽起來很美，但現實是骨感的

一開始大家都很興奮。原文那篇就有提到一個例子，有個新創公司叫 NexTech Solutions，他們的技術長，聽說以前是咖啡師，用這套 Vibe Coding 的工具，三天就兜出一個點咖啡的 App 原型。沒有語法錯誤、不用半夜還在 Stack Overflow 上面找答案。純粹就是…嗯…靠 vibes。

但問題很快就來了。紐約時報的 Kevin Roose 也試著自己玩玩看，想做個冰箱管理 App，結果 AI 產生的程式碼動是會動，但動到一半就掛了。要怎麼除錯？Karpathy 形容得很好笑，他說那就像「把一盤義大利麵丟到伺服器機櫃上」，看能不能剛好黏對地方。你根本不知道問題出在哪。

更可怕的是資安。有個叫 Leo 的開發者，用 vibes 蓋了一個 SaaS 應用，結果上線幾小時就被黑了。漏洞是什麼？是一個…呃…連大一資工系學生都會覺得丟臉的 SQL Injection。MIT Technology Review 還寫了一篇文章，標題大概是「Vibe 街的惡夢」之類的。這就不是開玩笑的了。

所以你看，問題就出在這裡。速度和簡單的幻覺，背後藏著一堆你看不到的坑。

兩種開發模式，你選哪一種？

說到底，這就是兩種思維模式的拉扯。我整理了一下，你看完大概就有感覺了。

比較項目	Vibe-First 憑感覺優先	Architect-First 架構優先
開發速度	超快，真的。像在許願，講完 idea 就有東西跑出來，原型幾天就好了。	嗯…慢很多。要先開會、畫架構圖、想清楚所有安全性跟擴充性，很煩，但也很穩。
初期成本	看起來很低。不用請一堆貴桑桑的開發者，感覺超省錢。	比較高。你需要有經驗的架構師和工程師先打好地基，時間跟人力都是成本。
程式品質	…不一定。AI 會產生很多冗餘或沒效率的程式碼，像義大利麵一樣纏在一起。	相對好很多。程式碼是經過設計的，可讀性、可維護性都比較高。
安全性	這是最大的賭注。AI 常常忘記做一些基本的安全檢查，像上面說的 SQL injection 就是個例子。	從一開始就把安全性納入設計。會有威脅模型分析、程式碼掃描，比較不會有那種低級失誤。
長期維護	根本是惡夢。當初寫程式的不是你，是 AI，現在壞了要修，你可能根本看不懂它在寫什麼。	比較輕鬆。因為有文件、有結構，後來接手的人才知道怎麼改、怎麼擴充。
適合情境	做拋棄式的原型、驗證市場想法、或是辦個黑客松玩玩，就很適合。	任何想要長期經營、需要穩定可靠、處理敏感資料的「正式產品」。

那…雲端架構師還能幹嘛？

這就有趣了。不是說 Vibe Coding 出來，架構師就要失業了。我自己是覺得，角色反而更重要，只是工作內容變了。我們不再是那個從零開始蓋房子的人，而是…嗯…像是建築結構的稽核員。

原文裡那個 NexTech 的故事後來是這樣：他們的咖啡 App，每次有人點燕麥奶就當機。AI 給的建議亂七八糟，甚至把濃縮咖啡推薦給乳糖不耐症的客人。最後他們沒辦法，只好找來一位 Azure 架構師。

那個架構師做的事，就很關鍵。他沒有把整個 App 砍掉重練。他做的是導入「紀律」。

用它來做對的事：首先，他承認 Vibe Coding 在「快速原型」這塊是真的強。所以，繼續用它來發想新功能、做一些 UI 的雛形。這沒問題。
加上安全護欄：但是，所有 AI 產生的程式碼，都必須經過 Azure Policy 和 Security Center 的檢查。你可以把它想像成一個自動化的品管員，程式碼送進來，它就先掃一遍，看看有沒有明顯的漏洞、有沒有不符合公司規範的地方。有問題？直接退貨，不准上線。
建立自動化產線 (CI/CD)：再來，他導入了 Azure DevOps，建立起一套完整的 CI/CD 管線。意思是，從程式碼的整合、測試到部署，全部自動化、流程化。這樣可以確保每次的修改，都經過一樣的標準檢驗，而不是憑感覺部署。
監控一切：最後，用 Azure Monitor 和 Application Insights 把整個 App 的運作狀況全部監控起來。哪裡跑得慢、哪個功能容易出錯、資源有沒有被濫用…全部攤在陽光下。AI 產生的程式碼通常效率很差，IBM 的研究也說，AI 常常會過度配置資源，像用火箭筒開啤酒。沒有監控，你根本不知道錢是怎麼燒掉的。

你看，這個混合模式，才是比較現實的做法。讓 AI 當你的超強助手，但最後把關、建立規則的，還是人。

不只技術，還有成本跟…碳排放？

對，還有一個很實際的問題，就是錢。AI 寫的程式，常常「能動就好」，但效能奇差。NexTech 那個 App 後來發現，處理一筆燕麥奶拿鐵的訂單要花 20 秒，這在網路世界差不多等於一個世紀了。深入追查才發現，AI 寫的資料庫查詢爛到不行，繞來繞去，像個迷宮。

結果就是，Azure 的帳單每個月跟電話號碼一樣長。他們甚至用 Azure Kubernetes Service (AKS) 這種重量級的服務，去跑一個其實用 Azure Functions 就能搞定的小東西。

後來架構師導入 Azure Cache for Redis，調整了 Cosmos DB 的索引，才把延遲砍了七成。這就是人的經驗價值所在。

更有趣的是，這還牽涉到 ESG。微軟自己永續團隊的研究發現，沒效率的 AI 生成程式碼，碳排放量可以比人工優化的版本多出三成。這點在國外可能已經是個品牌風險問題了，我看美國那邊的大公司都很在意這個。在台灣，我們可能還在討論成本，但遲早也會走到這一步。如果你標榜自己是綠色企業，結果雲端服務的碳足跡高得嚇人，那不是很諷刺嗎？