Vibe Coding也需要遵循的軟體開發原則

Vibe Coding，很多人叫它「許願式編程」——你許願，AI 實作。聽起來很美好，但在實踐中，大家的看法差很多。

我從 2023 年就開始用 AI 工作，那時候 claude sonnet 還在 3.5 版本。很多人對 AI 抱持消極態度，但我不同意——即使在那時候，它就已經幫我處理了很多事情。到現在疑慮大多打消了，其實是部分朋友的用法不太對導致的誤判。

這篇想分享的是：即使在 Vibe Coding 的做法下，那些傳統編程的觀念，有些依然不能丟。關於 Vibe Coding 和傳統開發的更多比較，可以看這篇。

Clean Architecture——還是適用

在 Vibe Coding 還沒出現的年代，軟體開發就有一堆方法論來處理複雜度：Clean Architecture、人月神話、DDD……各有各的經典。

進入 Vibe Coding 時代之後，有些概念已經不重要了。但有些事情，每個掌舵的人還是需要懂。因為 AI 的 context 即使再大，也會在長時間工作中被稀釋，而且 AI 的關注點沒有你想的那麼受控——需要人來抓方向。

Clean Architecture 的核心概念其實很簡單：降低複雜度，讓某一層的複雜度只留在那一層。 把語言抽象做對，核心業務不需要知道外層細節；外層從外而內，一步步幫內層降低複雜度。這個原則對 Vibe Coding 完全適用——你讓 AI 在正確的分層下工作，它就不會把 UI 邏輯和資料庫查詢混在一起。

熵——AI 可以幫你降，但要你主動

談到複雜度，就不能不提熵。簡單說：每次修改程式，混亂度都會增加一點。反覆來回修改又不重構的話，就像有一個混亂度的進度條，滿了就救不回來了——軟體歷史上的慘案很多。

差別在於，現在我們有了更多可控的智力（感謝 Opus）。你可以讓 AI 在正確的架構下審查、重構、把熵降下來。但前提是你得主動叫它做——AI 不會自己說「這個檔案太亂了，我幫你整理一下」。在結構正確的情況下定期降熵，後續開發會靈活可靠很多。

Context 是怎麼運作的——沒有魔法

我整理了幾個在實踐中很好用的原則：

• 用 CLAUDE.md 夾帶通用指令。 但不要把所有訊息都寫進去——只放最重要、每次對話都要讓 AI 記得的東西
• 讓 AI 把重要事項註釋在程式碼上。 github issues 的連結也可以貼在相關註釋旁邊，規範 AI 的行為
• 先做總體設計，讓 AI plan 到你覺得沒問題再執行。

為什麼需要這些？因為 AI 模型的原理其實很樸素：每次對話都是文字進、文字出。AI 知道之前發生什麼，是靠客戶端把之前的對話記錄重新送出去——沒有魔法。有些廠商有做 Cache 可以復用 Session，但基本原理就長這樣。

所以 context 送出去的時候，更早的訊息可能被 compact 吃掉，AI 就「忘記」了。CLAUDE.md 是每次必送的，確保最重要的東西不會被沖掉。但反過來，如果你什麼都往裡面塞——每次對話都夾帶不重要的訊息，token 燒得快、冷卻來得快，極端情況下甚至會擠壓到有效對話的空間。

Prompt 到執行之間，有一大段空白

你懂吧——你說了一句「請幫我完成一個 TodoList App」，AI 就開始寫了。但它可能直接用 JavaScript、LocalStorage 存資料、一個檔案寫到底。

有經驗的工程師一看就知道問題在哪：為什麼是 LocalStorage 而不是雲端 API？為什麼是 JavaScript（如果你想要跨平台）？為什麼新增刪除修改都能跑，但多個列表之間的剪貼就卡住了？如果是因為一開始沒有根據 UI model 切好資料結構，耦合太重，後續返工會特別多。

就像開了自動導航的車——它能到目的地，但不是你希望的那條路徑。你的 PM 有未來的計畫、產品有產品的方向，AI 不知道這些。它只會用最通用的方式做出來。

這就是資深工程師在 Vibe Coding 時代的核心價值：對產品有概念的工程師，能夠比 AI 更可靠地判斷，哪些通用做法適用於這個場景、哪些不適用。 AI 的強化學習讓它往「更自信的語言」方向走，但現實業務的資訊 AI 拿不到，它沒辦法做出真正貼近現實的判斷（不然 AI 炒股早就無敵了⋯⋯但我們都知道，讓 AI 炒股的人並沒有真的成功）。

對現實的可靠判斷——這就是目前資深工程師相對於 AI，最能把控的部分。