當 Andrej Karpathy 在社群上拋出「Vibe Coding」一詞時，無數人驚嘆於軟體開發的門檻已被徹底夷平：你只要抱持著某種氛圍（Vibe），對著編輯器說幾句自然語言，LLM 就會在幾秒鐘內吐出可運行的全端應用。
然而，在狂歡經過數個月的沉澱後，第一線工程團隊開始撞上一堵殘酷的現實之牆。Hacker News 上近期獲得極高迴響的一則短評，一針見血地道破了這個範式轉移的代價：
「Vibe coding made writing cheap. It made reading expensive.」 （Vibe coding 讓寫代碼變得廉價，卻讓讀代碼變得無比昂貴。）
這不是懷舊工程師對新工具的抵抗。當生成代碼的邊際成本趨近於零時，真正決定軟體生死與團隊產能的，早已不再是手打語法的「技術實現力」，而是人類工程師的品味（Taste）——一種能夠在海量平庸輸出中識別壞味道、收斂邊界，並對 AI 產出堅決行使「否定權」的架構裁決力。
零邊際成本的程式碼生成
自然語言降低了語法門檻，但引發極高的熵增：AI 傾向吐出體積肥大、充滿隱形技術債的平庸程式碼（AI Slop）。
架構品味：深模組與狹窄介面
拒絕上帝服務類別。強迫 Agent 將複雜實作封裝於簡潔深度的介面之後，杜絕跨目錄的散彈槍式修改。
驗證品味：可重現的失敗證據
不問「功能能跑嗎」，只問「在哪些預期條件下會失敗」。以紅燈測試作為驗收防線，不交給 AI 盲目自嗨。
編輯品味：行使拒絕平庸的否定權
敢於推翻 AI 產出的前三種方案。品味是將 AI 從「製造垃圾的怪獸」轉化為「高保真執行手」的主權核心。
語法平民化後的代價：軟體垃圾掩埋場（Software Landfill）
過去二十年，傳統工程師的核心技能壁壘建立在「實現複雜度」上：精通語言語法、記住框架的生命週期鉤子、熟練操作資料庫驅動。誰能手刻出無 bug 的底層通訊，誰就是無可替代的資深專家。
但 LLM 把這座壁壘打成了碎石。今天任何一個剛學寫程式兩週的實習生，都能靠著提示詞讓 AI 生成出包含 JWT 認證、Redis 快取與非同步任務隊列的模組。問題在於：AI 具備近乎無限的生成能力，卻對系統的長期連貫性與維護成本毫無感知。
在 Reddit 的 r/webdev 社群中，工程師們正在頻繁討論這場蔓延開來的危機。當有人試圖淡化 AI 生成代碼的架構缺陷時，開發者直言不諱地指出：這絕不是什麼看不見的隱憂，而是一場「顯而易見且完全可預測的技術債危機（an obvious, incredibly-predictible technical debt crisis）」，只是眾人習慣把問題掃到地毯下。
缺少品味牽引的 Vibe Coding，正以驚人的速度製造社群口中的「軟體垃圾掩埋場（Software Landfill）」：
偽解法膨脹（Phantom Architecture）
- 現象：為了解決一個簡單的狀態同步問題，AI 自動引入了三個全新的依賴庫、一層複雜的 Event Bus 以及八百行難以追蹤的封裝。
- 後果：當系統在高負載下死鎖或拋出幽靈錯誤時，團隊中沒有任何一個人真正理解內部狀態機的流轉機制。
隱形邊界穿透（Context Bleeding）
- 現象：AI 為了「讓單元測試綠燈」，隨手在 Controller 層直接呼叫 ORM 甚至外部第三方 API，把原本清晰的領域邊界撕開無數破口。
- 後果：代碼庫退化成散彈槍式修改（Shotgun Surgery）的噩夢，任何微小改動都會引發無預期的連鎖崩塌。
「品味」不是玄學：工程審美背後的三大硬核裁決
很多人把「品味」誤解為純粹的美學主觀偏好——像是按鈕的圓角、顏色的調校或崇拜某種流行框架。但在高可靠性軟體工程中，品味是高密度的架構直覺與模式識別能力，是資深工程師歷經無數次線上事故與踩坑經驗後，所凝結出的嚴苛篩選漏斗。
具體落到工程實踐中，能夠阻斷 AI Slop 的品味主要由三個維度構成：
1. 架構品味：深模組與狹窄介面（Deep Modules & Narrow Seams）
- 評判標準：John Ousterhout 在《A Philosophy of Software Design》中強調的「深模組（Deep Module）」原則——介面極度簡單狹窄，內部實作極度深厚有力。
- 品味落地：面對 AI 吐出的十幾個互相呼叫的抽象工廠與薄類別，具備品味的工程師會立刻判定這是不及格的「淺模組淺層垃圾」，強制要求 Agent 消除中間層，封裝成只有三個公開方法的純淨介面。
2. 邊界品味：不變量與防禦深度（Invariants & Blast Radius）
- 評判標準：清楚劃分「誰永遠不能取得什麼」，並把最糟情況下的爆炸半徑（Blast Radius）嚴格限制在單一隔離單元內。
- 品味落地：拒絕接受只靠前端隱藏按鈕的「表面安全」；強制驗收每個端點是否自帶授權防線、跨帳號資源讀取是否回傳 403，以及併發計費是否在資料庫層具備絕對原子性。
3. 簡約品味：敢於對 80% 的生成代碼說「不」（The Courage to Say No）
- 評判標準：Antoine de Saint-Exupéry 的名言：「完美不是在無法再加入任何東西時達到，而是在無法再減少任何東西時達到。」
- 品味落地：AI 會本能地提供它最先想到的暴力解法。有品味的工程師不會照單全收，而是毫不留情地連續駁回三次方案，直到 Agent 找到那個代碼行數最少、狀態最單純、零外部依賴的優雅解答。
當資深者掌握品味，初學者迷失在語法幻影
社群在討論 Vibe Coding 時揭示了一個有趣的世代分水嶺。擁有多年分散式系統經驗的資深工程師在 r/webdev 上坦言：他們在工作流程中廣泛運用 AI，但主要把 AI 當成「CRUD 加速器」與「模板打底工具」，並且在生成完成的第一秒就嚴密檢查代碼是否符合預設架構規範。
相反地，缺乏底層訓練的初學者正在遭遇嚴重的成長陷阱。許多工程團隊在盤點新人培訓時赫然發現：因為第一天就全盤依賴 AI Vibe Coding，新進工程師甚至無法描繪出整個系統的核心架構與資料流向。
當提示詞（Prompt）成為唯一的輸入，工程師若缺乏足夠的理論底蘊與踩坑直覺，他就無法分辨 AI 給出的是「業界驗證的最佳實踐」還是「隨機拼湊的垃圾」。這種失去審查能力（Loss of Verification Authority）的狀態，會讓工程師徹底淪為 AI 的文字搬運工，而非系統的主人。
# 團隊應落地的 Vibe Coding 裁決契約範本
architectural_invariants:
- 介面表面積最小化：任何新增的公開 API 必須具備充分的單元測試與自描述型別
- 封裝內部化：功能實作不得洩漏 ORM 連線或跨目錄引發幽靈相依
- 失敗預期優先：提交代碼前，必須提供可重現「邊界失敗」的紅燈測試證據
- 零盲目依賴：未經架構審查，嚴禁引入未列入信任清單的第三方套件下一步：如何將品味具象化為工作流約束？
如果你的團隊也正享受著 Vibe Coding 帶來的飛速交付，卻同時隱約感受到代碼品質逐漸失控的焦慮，請不要試圖「禁止使用 AI」，而是把你的工程品味編譯為可被機器執行的硬性約束。
在下一輪任務指派給 Agent 之前，立即在工作流中執行這三個動作：
- 建立紅燈測試護城河（Test-First Seam）：在讓 Agent 寫任何商業邏輯前，先由人類定義出核心斷言與預期拋出錯誤的邊界測試。沒有失敗案例，就不准開始實作。
- 鎖定垂直切片與目錄邊界（Vertical Slice Isolation）：要求 Agent 的一切改動必須限制在獨立的功能切片內，嚴禁未經確認跨層竄改公共服務。
- 行使兩次駁回權（The Rule of Two Rejections）：養成不接受 Agent 第一版輸出的工作習慣。問它：「這個實作有哪三個潛在的架構壞味道？如果把代碼行數砍半，你會如何重新設計？」，逼迫模型從自身生成的平庸模式中躍遷出來。
技術語法會過時，生成工具會迭代，但對架構邊界的感知、對複雜度的敬畏，以及拒絕妥協的品味，永遠是軟體工程師無法被演算法取代的立足之地。