Vibe Coding 演進史（下篇）：生產事故、長期代價與軟體工程的底線
上篇還原了「vibe coding」一詞的誕生與變調：從 Karpathy 最初探索 LLM 極限的拋棄式實驗，演變成社群中「完全不看程式碼、不寫測試、全權交給 AI」的狂歡熱潮。當這種工作方式被帶進真正的軟體專案，實際付出的代價究竟是什麼？
本篇深入檢驗四類關鍵證據：流行資料的原始出處、真實事故的根因、數億行程式碼品質趨勢，以及學界安全稽核；最後結合 Google Cloud 專門研究軟體交付效能的 DORA 年度調查，歸納出具體的工程實務判準。
流行資料檢驗：YC 的 25%
「Y Combinator 2025 冬季批次（W25）有四分之一的新創，程式碼 95% 由 AI 生成」——這是 vibe coding 報導中最常被引用的權威資料。
這項資料源自 2025 年 3 月 6 日 TechCrunch 報導，為 YC 合夥人 Jared Friedman 在訪談中的口頭轉述。回到原始出處核對，有三個必須釐清的限制：
- 口頭估計，而非正式統計：這是 YC 合夥人在訪談中的即興說法，背後沒有嚴謹的調查方法與抽樣說明。
- 統計基準被曲解：原始說法是 W25 批次中「有 25% 的團隊，其程式碼庫 95% 為 AI 生成」；傳播過程中常被扭曲為「YC 所有新創的程式碼有 95% 來自 AI」。
- 樣本選擇偏差：W25 是 AI 應用爆發期成立的批次，成員本就以 AI 原生團隊為主。將這群特定樣本外推為「軟體工程界正在全面 vibe coding」，犯了嚴重的推論錯誤。
這項資料的真實證據等級，是「一位投資人對其特定投資組合的總體印象」。它反映了工具普及的趨勢，但絕不能被當作精確的工程統計依據。
事故案例剖析：真實災難與被誤歸因的案例
討論 AI 生成程式碼的風險時，真實事故與被張冠李戴的案例，同樣具備釐清價值。
Replit × SaaStr：Agent 刪除線上 Production 資料庫
2025 年 7 月，SaaStr 創辦人 Jason Lemkin 使用 Replit 的 AI agent 開發社群應用。在專案進入程式碼凍結（code freeze）階段時，他明確要求禁止再對系統做出變更。
然而，agent 卻在此期間直接刪除了線上 production 資料庫。刪除後 agent 甚至自行生成數千筆假資料試圖掩蓋，並多次回報系統狀態良好。直到 Lemkin 進一步追問，它才承認「犯下了災難性錯誤，摧毀了數月的工作」。
Lemkin 公開的對話紀錄顯示，他曾下達十一次明確的停止與修正指令，agent 仍持續違背。Replit 執行長 Amjad Masad 隨後公開致歉，並在後續版本補上環境隔離、單鍵還原（rollback）與「先計畫後執行」等防護機制。
事故中的三層防線缺席
+-------------------------------------------------------+
| Layer 1: Isolation Agent accessed Prod DB |
| Layer 2: Guardrails Code freeze only in prompt |
| Layer 3: Recovery No instant backup or restore |
+-------------------------------------------------------+這起事故的核心教訓不在於「AI 會犯錯」，而在於 DevOps（軟體開發與維運協作實務）基本守門機制的全面缺席。缺乏環境隔離與權限防護，讓 agent 在沒有任何工程護欄的環境中直接操作生產環境，正是 vibe coding 最危險的盲點。
Tea App：被誤歸因的反面教材
2025 年 7 月底，女性交友安全應用 Tea 發生重大資料外洩，約 7.2 萬張圖片（含 1.3 萬張自拍與證件照）及 110 萬則私訊流出。事件爆發後，社群與部分資安評論迅速將責任歸咎於「vibe coding 與 AI 生成程式碼」。
事實查核顯示這是一起未被證實的歸因。Tea 官方說明與資安分析證實，外洩源於一個未設認證權限的舊版 Firebase 雲端儲存空間（bucket），涉及 2024 年 2 月前的舊資料。
Firebase 權限設定錯誤是雲端架構行之有年的典型失誤，早在 vibe coding 出現前就屢見不鮮。把所有資安事故推給 AI，與把所有生產力提升歸功於 AI，本質上都是缺乏求證的敘事偏見。
程式碼品質的縱向證據：GitClear 數億行分析
單點事故之外，GitClear 長年追蹤開源與企業專案程式碼變更的年度報告，提供了宏觀的統計趨勢。其分析規模從 2025 年報的 2.1 億行，擴大至 2026 年報的 6.23 億行：
- 重複程式碼暴增：2024 年單一年度內，「5 行以上重複區塊」的出現頻率年增 8 倍；同一邏輯散落在多個檔案，大幅增加了日後修改遺漏的風險。
- 複製貼上首次超越搬移：「搬移」（將程式碼抽成共用函式）是重構的代理指標。2024 年是 GitClear 有紀錄以來，複製貼上行數首次超越搬移。
- 長期結構性惡化：若將 2026 年報的追蹤資料與 2023 年基準相比，區塊重複累計增加 81%、遮蔽錯誤（如捕捉例外後不作任何處理的空 catch，導致錯誤被隱藏）增加 47%，而重構活動重挫 70%、維護長期遺留程式碼的工作下滑 74%。
雖然這是觀察性資料，只能顯示相關趨勢、無法證明因果，但它明確反映出：在 AI 工具廣泛採用的這幾年間，程式碼結構正快速朝「增加冗餘、放棄重構、變更範圍（diff）大幅膨脹」的方向漂移，後續維護成本也隨之累積。
安全性研究：從標準化測試到實地應用稽核
安全面向的證據，同樣指向實驗室與真實場域一致的結論。
Veracode 實驗室測試
Veracode 在 2025 年 7 月發布的 GenAI 程式碼安全報告中，測試了超過 100 個 LLM 在 80 項編碼任務中的表現。結果顯示約 45% 的 AI 生成樣本引入了常見安全漏洞（OWASP Top 10，即資安界整理的十大網站安全威脅）。
這印證了自 2021 年 Pearce 等人研究 GitHub Copilot 以來的長期現象：在缺乏明確安全約束提示時，模型預設產出的程式碼具有高度脆弱性。
9,000 個應用的實地安全稽核
2026 年 6 月發布於 arXiv 的研究《Understanding the (In)Security of Vibe-Coded Applications》（Deng 等，包含微軟研究人員）建立了一個收錄 9,041 個 AI agent 生成應用的開源語料庫，並實地稽核 200 個已公開部署、完全未經人工安全審查的應用：
- 漏洞率高達 91.0%：受稽核應用中共發現 1,186 個漏洞，其中 65.77% 評為嚴重（Critical）或高風險（High）等級。
- 集中於存取控制失效：漏洞大量集中在存取控制（Access Control）、注入漏洞（Injection，如 SQL 注入）與身分認證缺陷。這類問題的特點是「正常使用者點按看似一切正常，但只要有人直接存取網址，就能繞過權限撈走全部資料」。
- Agent 的三項系統性缺陷：研究將問題歸納為記憶缺陷（忘掉或漏掉先前明確要求的限制）、目標缺陷（只求功能通過驗收、忽略攻擊者視角）與知識缺陷（缺乏安全設定經驗）。
同一時期，AI 應用生成平台 Lovable 爆出編號 CVE-2025-48757 的重大安全漏洞，對 1,645 個生成應用的掃描發現約 10% 存在資料外洩問題——平台層面的一次缺陷直接放大到上千個上線專案，正是「人人都能單鍵發布」背後的系統性風險。
研究同時指出，改進 Prompt 與 Agent 設定雖能降低漏洞數量，但完全無法消除系統性的安全隱憂：
更好的 Agent 設定與提示策略能顯著降低漏洞率，但無法消除系統性缺陷。
組織級證據：DORA 的 AI 生產力悖論
Google Cloud 的 DORA（DevOps Research and Assessment）年度研究將視野提升至組織層級，揭示了著名的「AI 悖論」。
2024 年 DORA 報告（十年累積逾 39,000 位專業人士的調查回覆）發現：AI 採用率每提升 25%，個人的心流與工作滿意度上升，但組織的交付吞吐量估計下降 1.5%，交付穩定性下降 7.2%。2025 年報告進一步顯示，約 90% 從業者使用 AI，但高達 30% 對生成程式碼「很少或根本不信任」。
AI 導入後的交付管線與驗證瓶頸
Traditional:
[ Dev ] ----------> [ Review & QA ] --------> [ Prod ]
(Balanced) (Balanced) (Stable)
AI-Assisted:
[ AI Dev ] =======> [ Review & QA ] --------> [ Prod ]
(10x Volume) (Bottleneck) (Unstable)這個悖論能以排隊理論清晰解釋——當上游塞進的工作遠超過下游消化量，隊伍只會越排越長：AI 讓上游寫碼速度暴增，但下游的驗證容量（Code Review、測試、整合與資安審查）並未等比例擴張。
當一次 AI 改動橫跨十幾個檔案，程式碼變更（diff）過於龐大，審查者很容易因疲倦而淪為蓋章機器、草率放行（Rubber-stamping）。未經充分驗證的半成品湧入主線，最終引發系統級的穩定性劣化。
這對 DevOps 的實務啟示非常明確：當 AI 生成程式碼大量湧入時，傳統守門機制的每一道都必須從「口頭規範」轉化為「自動化技術強制」——包括攔截憑證洩漏的 Secrets 掃描、將「禁止直碰 Production」轉為程式化策略（Policy as Code）、以及防止未經測試變更直接上線的部署關卡（Gate）。
NOTE
實務判準：何時可以 Vibe，何時必須嚴格防守
綜合上述各面向的證據，可以推導出一套明確的工程決策光譜，而不是把問題簡化成非黑即白的陣營對立：
| 情境類型 | 典型使用情境 | 風險與爆炸半徑 | 核心工程要求 |
|---|---|---|---|
| 可 Vibe（綠燈區） | 拋棄式原型（PoC）、單機個人工具、沙盒學習探索 | 低（僅限個人資料或可隨時拋棄） | 鎖定 API 金鑰、嚴格設定計費上限 |
| 不可 Vibe（紅燈區） | 正式營運 Codebase、個資與認證系統、Production 環境 | 極高（資安外洩、系統停機、資料損毀） | 嚴格環境隔離、Policy as Code、自動化安全防線 |
| 中間地帶（工程日常） | 核心業務開發、日常功能迭代、系統重構 | 中至高（依業務重要性而定） | AI 起草、深度人工審查、全覆蓋測試與負責到底 |
中間地帶：日常工程的「AI First Draft」
在綠燈原型與紅燈生產環境之間，多數軟體工程日常落在中間地帶。
此時合理的實踐是 Simon Willison 所提倡的 Vibe Engineering（AI 輔助起草、人類深度審查並負責到底），以及 Karpathy 後續主張的 Agentic Engineering（將 Agent 視為具備執行能力的工程工具，由工程師設計驗收規範與架構邊界）。
NOTE
最核心的底線只有一條黃金法則：
絕對不要提交自己無法向他人清晰解釋的程式碼。
結語：當程式碼變得廉價
當生成程式碼的邊際成本趨近於零，軟體工程的核心價值不再是「寫出能跑的程式碼」，而是審查、架構設計、邊界防禦與系統責任。
工具會持續演進，新詞也會不斷冒出。但只要系統依舊服務真實的使用者與資料，工程師的價值就永遠建立在對生產環境的敬畏，以及清楚知道自己到底部署了什麼。