別讓 Vibe 變成債：開發者如何在速度與工程責任間找到平衡點？

現在大家都在用 AI 寫程式：一句自然語言，模型就能給你一堆能跑的實作，這就是所謂的 vibe coding。

舒服是真舒服，但一旦專案要進生產、要有人為系統長期負責，vibe coding 和工程責任之間的矛盾就開始冒頭了。

1. Vibe Coding 帶來的真實好處

先別急著批判，它確實有明顯價值：

• 起步更快：不用翻半天文件、從空檔案寫起，AI 可以幫你產生頁面、介面、範例程式碼，很適合做原型和驗證想法。

• 學習更直接：試一個函式庫、一個框架、新的 API，丟給 AI 幾個任務，看它怎麼寫，比純看文件更有感。

• 小工具很高效：內部腳本、簡單自動化、一次性頁面，用 vibe coding 搞定，性價比非常高。

問題不在於 vibe 本身，而在於：很多人把 「能跑」 和 「能負責」 混在了一起。

2. 工程視角在乎的那些東西

一旦你站在工程視角，關注點就變了：

• 系統性：模組怎麼拆、邊界在哪裡、資料怎麼流，出了問題有沒有地方可以下手查。

• 可維護性：半年後改需求，能不能不用重寫一半；新人進來，看不看得懂你現在的結構。

• 穩定性和可靠性：在高併發、有髒資料、有奇怪使用者行為時，系統還能穩不穩。

• 責任：誰是最後那個對系統交付和線上行為負責的人，而不是「AI 沒寫好」的那個人。

這幾件事，本質上是在問：你是系統的主人，還是只是一個 AI 使用者？

3. 速度 vs 可維護：衝突到底在哪裡？

當我們用 vibe coding 寫業務程式碼時，幾個典型衝突會不斷出現：

• 為了快，結構被壓縮成一堆「勉強能跑」的實作：到處是臨時判斷、複製貼上、長函式，沒人願意碰。

• 為了趕上線，測試和監控變成「回頭再補」的 TODO，結果上線後才發現邊緣情況壓根沒被考慮過。

• 為了方便改提示，把很多邏輯藏在 prompt 裡，程式碼只是結果，這會讓團隊難以統一理解和複盤決策。

還有一件事，很多人一開始沒有意識到：不要輕易讓 AI 一次幫你改太多程式碼。

在理想場景裡，AI 是幫你補一個函式、最佳化一段邏輯；但在實際使用中，它很容易一口氣動好幾個檔案：路由、資料結構、呼叫鏈、測試，全都一起改。

如果你頻繁點擊「接受所有改動」，過上幾輪，腦子就會跟不上整個程式碼庫的演化節奏——你只知道「現在能跑」，卻不知道「到底改了什麼」。

結果就是角色錯位：

• 你慢慢從「程式設計師」變成「測試和驗收的人」，只關注報錯有沒有消失、頁面有沒有正常顯示。

• AI 變成了真正的「寫程式碼的人」，在程式碼庫裡自由發揮結構和命名，而你既來不及，也不太想去深追。

長期這樣下去，程式碼是否合理、結構是不是爛、技術債堆到了什麼程度，你可能都沒有精力，也沒有動力去管。

這就是為什麼在工程視角下，要刻意控制 AI 的改動範圍，並且每次合併前留出理解和審查的時間：不然，你只是把工程責任徹底讓渡給一個不會替你值班的「同事」。

換句話說：速度是立刻看得見的好處，維護成本是慢慢長出來的代價。

如果沒人刻意把工程視角拉回來，專案就會在「今天很爽、以後很痛」這條路上一路到底。

4. 一個簡單的平衡框架：什麼時候 Vibe，什麼時候 Engineer？

為了解決這個衝突，先別急著給 vibe coding 貼標籤，不如給自己定一套簡單規則。

可以用兩條軸來判斷：犯錯成本 和 時間尺度。

犯錯成本低、時間尺度短

比如個人原型、內部小工具、一次性頁面、低風險 UI。 在這些地方，可以大膽 Vibe Coding：

• 用 AI 快速產生實作，

• 多試幾個方案，

• 用最小的工程約束兜一下底，比如基礎異常處理。

這裡的重點是：快驗證、快學習。犯錯成本低，工程就不必太重。

犯錯成本高、時間尺度長

比如支付、認證、權限、訂單、交易、風控、長期維護的主業務系統。 在這些地方，必須切回工程模式：

• 明確邊界和模組拆分

• 認真做測試、日誌、監控、告警

• 對 AI 生成的程式碼做有意識的審查和重構

這裡的重點是：系統安全、可持續演化，你不能說「我就 vibe 一下試試」。

可以記一句很實用的話：

Vibe 用來發現和驗證想法；工程用來承載和守護這些想法。

只要專案一旦從「試試」進入「要長期負責」，你的工作模式就應該從 Vibe Coding 切到工程模式。

5. 在 AI 時代，工程責任具體長什麼樣？

很多人覺得「工程責任」是抽象詞，其實在 AI 時代，它可以被拆得很具體：

• 不再追求「每行程式碼都我手寫」，而是追求「關鍵路徑和關鍵決策我說了算」：知道系統的核心邏輯在哪裡，知道出問題時往哪查。

• 把 AI 當「超級實習生」，而不是「背鍋同事」：讓它產生程式碼、補測試、給建議，但最終合併的結構和行為，要經過你的理解和判斷。

• 刻意訓練自己的程式碼審美和系統直覺：看得出什麼是技術債、什麼是好結構，而不是只是看語法是否正確。

• 把一部分精力投入到業務理解、架構規劃和品質守護上，而不是只停留在「寫程式碼的人」。這些才是 AI 暫時替代不了的部分。

用一句話壓縮就是：AI 可以幫你快寫程式碼，但不能替你承擔工程責任。 你享受速度沒問題，但你得自己決定：哪些地方只需要快，哪些地方必須穩。

6. 一個開發者可以立刻用上的 checklist

最後給一個日常可用的小 checklist，當你在用 AI 寫程式碼的時候，可以簡單過一遍：

• 這塊功能，出問題的代價大不大？如果大，就別只靠 vibe。

• 半年後，這段邏輯還會有人維護嗎？如果會，就從今天開始按工程方式組織。

• 如果線上炸了，我能不能解釋清楚系統的行為？如果不能，就說明現在對它還不夠了解。

• 這次用 AI，是為了快點試試，還是為了上生產？前者可以多一點 vibe，後者必須多一點工程。

有了這樣的自我檢查，你就不會在「寫得很爽」的同時，把自己和團隊推到「維護得很痛」的局面。