Vibe Coding與工程：我的界線在哪裡

Andrej Karpathy於2025年2月創造了「vibe coding」一詞，描述一種開發風格：程式設計師「完全沉浸於感覺之中，擁抱指數級成長，忘記程式碼的存在。」¹

我讀到這段話時心想：這正是我一半的工作流程。另一半則恰恰相反。

TL;DR

我每天都用Claude Code進行開發。其中一部分是純粹的vibe coding：描述我想要的東西，接受輸出，繼續前進。另一部分則經過86個hook、一個git安全守衛、一個遞迴防護機制，以及一套會攔截含有AI痕跡或被動語態的提交的品質閘門系統。這兩者之間的界線並非隨意劃定。原型用感覺驅動，正式環境用工程驅動。最困難的部分在於判斷原型何時跨越了那條線。

---

我的實際工作流程

感覺驅動的一面

當我在探索一個想法時，我會毫不猶豫地vibe code。我的Ace Citizenship iOS應用程式始於一個週末實驗：「建一個針對USCIS公民考試題目的間隔重複測驗。」Claude Code產生了初始的SwiftUI視圖、題庫和排程演算法。我沒有逐行閱讀。我執行它、手動測試、然後透過描述哪裡感覺不對來迭代。

這個部落格上的互動元件（RAG決策樹、複利計算機）也是同樣的起點。「建一個帶有動畫轉場的決策樹，引導使用者在RAG與微調之間做選擇。」接受、測試、調整。部落格小工具中的bug影響範圍僅限於單一頁面。

工程驅動的一面

我的Claude Code hook架構是vibe coding的反面。每一個hook的存在都是因為曾經出過問題。

git-safety-guardian.sh的存在是因為Claude在早期的一次工作階段中對main分支執行了force push。這個hook現在會攔截每一個git指令，根據嚴重程度表進行模式比對（CRITICAL：force push到main；HIGH：新增.env檔案；MEDIUM：–no-verify），並在執行前注入警告。

recursion-guard.sh的存在是因為一個子代理產生了無限的子程序。這個hook透過JSON檔案追蹤代理譜系、強制執行深度限制，並管理一個產生預算模型，防止失控的代理鏈，同時允許合理的平行作業。

blog-quality-gate.sh的存在是因為AI產生的文章讀起來就像AI產生的文章。這個hook會在偵測到破折號、被動語態，或是「delve」、「crucial」、「landscape」等詞彙時，攔截對content/blog/的提交。

這些hook沒有任何一個是vibe code出來的。每一個都是逐行撰寫、針對真實失敗場景測試、並在部署前經過審查。這86個hook共同構成了感覺驅動與工程驅動之間的界線。

---

界線究竟落在哪裡

感覺驅動：用完即棄的原型

任何可能會丟掉的東西，我都用vibe code處理。只執行一次的資料轉換腳本、個人使用的CLI工具、測試某個API是否如文件所述運作的概念驗證。用完即棄的程式碼中出現bug，代價只是我自己的時間，而速度上的收益遠超除錯的風險。

感覺驅動：創意探索

當我在探索設計方向時，vibe coding讓我測試互動模式的速度比Figma更快。「建一個搜尋對話框，支援鍵盤導覽、結果高亮顯示和Cmd+K啟動」能在幾分鐘內產出一個可運作的原型。我評估的是感受，而非程式碼。²

工程驅動：任何觸及使用者的東西

當程式碼開始服務我以外的人時，它就跨越了那條線。我的部落格經過一套12模組的檢查工具，檢驗引用來源、標題層級、可讀性等級、圖片替代文字、內部連結密度和內容深度。這套檢查工具有77個測試。部落格有29篇文章。檢查工具的測試比部落格的內容還多。

工程驅動：任何會持久存在的東西

資料庫綱要、API契約、hook設定檔和部署清單都會接受完整的工程處理。這些決策會不斷累積。在vibe工作階段中設計的綱要，當三年的資料累積在上面時，就會變成遷移的惡夢。³

工程驅動：任何與安全相關的東西

AI產生的程式碼反映了其訓練資料的安全狀態，而訓練資料包含了為求簡潔而經常省略認證、輸入驗證和錯誤處理的教學文章和Stack Overflow回答。⁴我的hook能攔截部分問題（git安全守衛會標記.env新增、憑證檔案和force push），但與安全相關的程式碼無論如何都會經過人工審查。

---

理解落差問題

Vibe coding中最危險的模式不是糟糕的程式碼，而是在出問題之前一切正常運作的程式碼。

我為i18n翻譯系統產生了一個快取層。它在英文內容上運作完美。當我加入韓文和繁體中文時，快取鍵的產生在某些Unicode碼位上悄悄產生了碰撞。除錯花了四個小時，因為我從未閱讀過快取鍵的函式。這段程式碼對ASCII是正確的，而這正是訓練資料所著重的部分。⁵

教訓：vibe code出來的系統會在訓練資料低度涵蓋的邊界情況下失敗。如果您的使用者在這些邊界情況中運作（非拉丁字元、高併發、異常的網路條件），vibe code的實作就潛藏著隱性風險。

---

審查閘門

我系統中所有準備進入正式環境的程式碼，不論是我自己寫的還是Claude Code產生的，都會經過審查閘門：

1. 逐行閱讀。產生的程式碼是一位不受信任的貢獻者提交的pull request，請據此進行審查。
2. 驗證錯誤處理。確認錯誤路徑反映的是領域需求，而非通用的try-catch模式。
3. 稽核相依套件。AI在隔離狀態下解決每個提示，匯入任何能解決當前需求的函式庫。經過50個提示後，您可能會有三個日期函式庫和兩個HTTP客戶端。
4. 新增測試。產生的程式碼很少涵蓋您領域中特定的邊界情況。
5. 檢查安全性。執行靜態分析，驗證認證、授權和輸入驗證。⁶

審查閘門不是可選的。它是將AI作為力量倍增器與將AI作為拐杖之間的差異。

---

產業分化

軟體工程正在分化為兩個層級。第一個層級將AI作為力量倍增器：產生樣板程式碼、探索解決方案空間、加速實作已被充分理解的模式，同時維持理解力和品質標準。第二個層級在不理解輸出的情況下產生完整的應用程式，以短期速度換取長期脆弱性。⁷

這種分化如同早期的網頁開發。Squarespace等範本建構工具使網站發布民主化，產出了數百萬個功能正常的網站。專業網頁開發之所以持續存在，是因為正式環境的系統需要範本無法提供的品質、安全性和可維護性。

我刻意在這兩個層級中運作。我的hook系統和品質閘門的存在，正是為了捕捉第二層級的工作需要升級到第一層級標準的那個時刻。這86個hook不是官僚作業，而是讓我能自由vibe code的免疫系統，同時防止vibe code的產出在未經審查的情況下進入正式環境。

---

重點摘要

給每天使用AI的工程師： - 在探索與正式環境之間劃出明確的界線；用完即棄的工作可以自由vibe code，但在任何觸及使用者或持久存在的東西之前，必須執行審查閘門 - 建立自動化的防護機制（hook、檢查工具、品質閘門），而非僅依賴紀律；凌晨兩點紀律會失效，hook不會

給工程主管： - 在原型品質和正式環境品質的程式碼之間建立清晰的界線；滑入正式環境的vibe code原型會產生一種新型態的技術債 - 以成果（交付的功能、每個功能的bug數、使用者滿意度）而非速度指標來評估生產力；vibe coding會灌水程式碼行數，卻不會等比例提升成果

---

參考資料