Vibe Coding 熱潮下的軟體工程危機：當企業擁抱 AI 卻忽視架構品質，為什麼降本反而帶來反效果？

生產力提升的承諾，正在企業與開發團隊之間引發一場認知落差。當人工智慧模型能夠快速生成程式碼，許多組織直覺地認為傳統的軟體工程師角色可以被大幅裁減，只要保留少數人員下達指令，就能以極低的成本產出軟體產品。然而，實際的產品研發週期卻顯示，缺乏嚴謹架構規劃的 AI 程式碼生成，正在大量製造難以維護的系統。

這種被稱為「Vibe Coding」的現象，指的是開發者或非專業人員仰賴自然語言提示，讓 AI 模型不斷生成並堆疊程式碼，直到應用程式能運作為止。這種做法在軟體雛形開發階段確實帶來了極大的速度優勢，也讓產品經理或設計師具備了獨立產出可用元件的能力。但在這股浪潮下，企業很快會發現一個現實：軟體能跑，不等於軟體能夠被維護。

被誤解的軟體開發：從畫畫到蓋大樓

許多人對軟體開發的誤解，在於將其視為一種隨興的創作過程。這種認知認為，開發就像是畫一幅畫，只要把各種美好的想法與功能隨手加到畫布上，就能完成一件完美的作品。生成式 AI 工具的出現，進一步強化了這種錯覺，讓大眾以為只要透過自然語言描述，就能毫無 friction 地把腦海中的產品藍圖具現化。

然而，真實的軟體工程更像是在蓋一棟大樓。產品是一層一層疊起來的，每一層之間都存在著緊密的相依性。這種依賴關係不僅存在於程式碼層面，更貫穿了整個產品的結構。從產品需要解決什麼問題、解決誰的問題、用什麼形態解決，一路延伸到視覺架構、體驗架構與資訊架構。只有當這些基礎穩固建立後，工程架構才能妥善回應最上層的期待。

如果在蓋大樓的過程中，工人已經蓋到第五層，決策者突然要求在第三層和第四層之間加入一個空中花園，這在現實中是不切實行的。但在軟體工程實踐裡，這種需求變更屢見不鮮。需求變更可以來自任何一個層級，但變更發生的層級越基礎，牽涉到的產品變動就越廣泛，整體結構也會越不穩定。

當非工程人員透過 Vibe Coding 直接生成程式碼時，往往會採取一種「先隨便把東西塞進去交差，剩下的以後再說」的策略。經過幾次這樣的迭代，整個系統就會變得極度脆弱，如同用木頭樁子四處支撐的違章建築，拆掉任何一個環節都可能導致系統崩潰。

技術債的失控與演算法代價

工程架構的品質是會隨著產品演進而自然劣化的。這種劣化如果沒有透過重構來控制，維護成本就會以指數級上升。在傳統的開發流程中，資深工程師會透過程式碼審查與架構設計來控制技術債的累積速度，這與我們先前探討過的AI 工程師集體改用 Mac 背後的工具鏈慣性有著異曲同工之妙，工具的選擇與嚴謹的工程紀律，都是為了確保產出的穩定性。

但在缺乏架構意識的 AI 輔助開發中，這個劣化過程被急遽壓縮。未經規劃的程式碼生成，會在系統內部留下大量的暫時性解決方案。這些解決方案包含了複製貼上的重複邏輯、打結的非同步事件流、以及難以追蹤的資料狀態。

疏於維護的架構會造就心力交瘁的開發者，而心力交瘁的開發者為了趕上交付期限，會更依賴 AI 產出更多未經深思熟慮的程式碼，製造出更龐大的技術債。這是一個無法持續的惡性循環。當企業自豪於前端開發速度的提升，並且以此為由削減工程預算或購買 AI 模型的 API 額度時，他們實際上是在透支產品的生命週期。這與AI 生成的垃圾修補淹沒開源維護管線所引發的危機如出一轍，當生成端的成本趨近於零，審查與維護端的成本卻會被推向極限。

角色錯位的代價：從生產力到破壞力

Vibe Coding 時代催生了一種新型態的優越論。產品經理認為工程師不再重要，因為他們可以自己完成從零到一的開發；設計師認為他們能夠獨立做出優雅的產品；工程師則認為自己可以指揮 AI 完成所有工作。大公司也紛紛加入這場狂歡，認為裁減人力、購買 Token 是最有效率的商業策略。

但現實的考驗很快到來。產品經理產出的系統充滿錯誤，設計師做出的介面效能極差，工程師未經規劃做出的產品沒有使用者願意買單。當企業從 AI 帶來的初期多巴胺快感中清醒，發現系統無法擴展、錯誤難以修復時，往往只能默默地重新聘用被資遣的工程師，回頭處理那些已經糾纏不清的底層架構。

問題的核心在於，軟體研發流程中的每一個角色都至關重要，但他們的重要性體現在不同的層面。產品經理負責釐清問題的本質與市場定位，設計師確保資訊架構與體驗的流暢，工程師則確保底層邏輯的穩固與可擴展性。當任何一個角色試圖用 AI 跳過其他專業的思考過程，直接生成最終成品時，他們其實是在基礎未定的情況下任意向上堆疊需求。

重新定義 AI 在開發流程中的位置

要避免降本反而帶來災難，企業與開發團隊必須重新理解 AI 在軟體工程中的定位。AI 模型是一個極度高效的程式碼生成器，但它本身並不具備系統架構的全局視野。

地基的品質決定了建築物能搭多高，反映在工作實踐上，就是在架構設計階段必須進行縝密思考。開發紀律決定了系統能搭多快。如果頻繁發生需求變更，且不留出架構修補的時間，那麼開發速度一定會越來越慢。如果開發者本身不整理架構，單純依賴 AI 把功能塞進去，一個難以維護的技術迷宮就會成型。

降本增效的前提，是將 AI 視為強化專業產出的輔助工具，而非取代專業判斷的萬靈丹。產品經理可以利用 AI 加速驗證想法，設計師可以利用 AI 生成介面原型，但當這些想法要轉化為實際的商業級軟體時，仍然需要嚴謹的架構設計與工程實踐來把關。只有在穩固的工程架構之上，AI 帶來的生產力紅利才能真正轉化為商業價值，避免在系統崩塌時將先前的節省連本帶利歸還。