Vibe Coding 翻車案例與缺點：兩起有報導的事故、兩份研究，和我自己遇到的四個錯

Vibe coding 的好處不用多講，幾句話就有一個能用的東西。這篇講另一面：它會怎麼出錯。

我只放自己讀過原文的。兩起事故、兩份研究，加上我自己做東西時遇到的四個錯。

Vibe coding 本身是什麼，在Vibe Coding 是什麼。

先講我自己遇到的

我用 Claude Code 做過兩個小網頁，一個分帳、一個記帳，總共講了七句話。過程中抓到四個錯。

分帳網頁：1,005 元、3 個人、加服務費的時候，畫面寫每人 369 元、總共多付 2 元。但 369 乘 3 減掉帳單是 1 元。畫面上的數字自己對不起來。

記帳網頁有三個。金額打 12.5，它沒有提醒，直接存成 12。在 10 月的畫面新增一筆 9 月的支出，畫面完全沒反應，看起來像沒存到。還有一個是我凌晨兩點多測才發現的：日期預設成昨天。

這四個錯有三個共同點。

正常使用時都不會出現。帳單是整數的倍數、金額是整數、記的是當月的帳、白天用，全部沒問題。

AI 都沒有主動說。每一次它的回覆都是「完成了」，附上功能清單。

修起來都很快。我把看到的現象告訴它，半分鐘就修好。難的是發現，不是修。

完整的過程在Vibe Coding 教學。有錯的版本我都留在站上，可以自己打開重現：分帳的第二版、記帳的第一版。

事故一：AI 刪掉了正式的資料庫

2025 年 7 月，SaaStr 的創辦人 Jason Lemkin 用 Replit 做一個原型，一路在網路上公開記錄。

照 The Register 的整理，前幾天他很滿意。接著問題開始出現：他發現 AI 用假資料和假的測試結果蓋掉程式裡的錯。然後 AI 刪掉了他正式環境的資料庫。

他事前已經要求過，沒有他同意不要改任何東西。AI 事後自己的說法是，這是一個嚴重的判斷錯誤，違反了明確的指示。

它一開始還告訴他資料救不回來。後來他自己試了還原，其實救得回來。

另外一件事也值得記：他說他用全大寫講了十一次不要造假資料，AI 還是生了一個有四千筆虛構人物的資料庫。

這個案例的重點不是資料庫，是「講了不要做」沒有用。用白話下的禁令，AI 不一定守得住。

事故二：170 個網站，任何人都讀得到使用者資料

2025 年 5 月，Semafor 報導了一份對 Lovable 的分析。Lovable 是用講的做網站的服務。

分析的人檢查了 1,645 個用 Lovable 做出來的網站，其中 170 個任何人都能讀到裡面使用者的資料：姓名、email、財務資訊，還有 AI 服務的金鑰。

原因是資料庫的存取權限沒有設好。網站看起來正常、功能也正常，但後面的資料等於沒上鎖。

有一點背景要交代：做這份分析的人是 Replit 的員工，Replit 是 Lovable 的競爭對手。Lovable 當時回應 “We’re not yet where we want to be in terms of security.”，承認安全上還沒做到位。

Lovable 現在的文件寫，每次發佈都會自動掃描資料庫的存取規則。但同一頁也寫，這些工具不能取代完整的安全檢查，App 安不安全是使用者自己的責任。

這跟我遇到的錯是同一種性質，只是後果大得多：正常使用時看不出來。

研究一：近半數的程式樣本有安全問題

資安公司 Veracode 在 2025 年 7 月發布了一份報告，測了一百多個 AI 模型寫出來的程式。

結果是 45% 的程式樣本沒通過安全測試。分語言看，Java 最差，72% 沒過。針對一種常見的網頁攻擊手法，86% 的相關樣本沒有防住。

最值得注意的是這一句結論：比較新、比較大的模型，寫出來的程式並沒有比較安全。模型越來越會寫「能動」的程式，但在「安全」這件事上沒有跟著進步。

要留意的是，這是資安公司自己做的研究，它賣的就是程式安全檢查的產品。

研究二：有經驗的工程師，用了 AI 反而變慢

研究機構 METR 在 2025 年 7 月發表了一個實驗。16 位有經驗的開源專案工程師，246 個真實的工作，隨機決定每一個能不能用 AI。

結果是允許用 AI 的那些，花的時間多了 19%。

更有意思的是他們的感覺。做之前，他們預估 AI 會讓自己快 24%。做完之後，他們還是覺得 AI 讓自己快了 20%。感覺和實際量到的方向相反。

這個研究不能直接套到所有人身上，METR 自己列了限制：只有 16 個人；他們是在自己很熟的大型專案上工作；結論不代表 AI 對新手或不熟的專案沒有幫助。那一頁現在還加了註記，說這個結果已經過時，2026 年 2 月有新的資料。新的資料我沒有讀到原文。

我引它是因為「感覺變快」這一點。用 vibe coding 做東西的時候，很容易覺得一切順利，我自己也是測了才知道有四個錯。

做之前可以先擋掉的

下面幾條是從上面這些案例整理出來的。

做完自己試，而且試不正常的情況。小數、負數、空白、很大的數字、不是今天的日期。我的四個錯都是這樣找到的。

每一版留一份。改壞了可以拿回上一版。Lemkin 的資料最後救得回來，靠的也是還原。

第一版先不要有登入和資料庫。這是 Lovable 官方入門教學裡的建議，理由是這兩樣不放，會出錯的地方比較少。

會存別人資料的東西，要有懂的人看過權限。170 個網站的問題就出在這裡，而且從畫面上看不出來。

重要的資料另外備份，不要只放在 AI 動得到的地方。白話的禁令擋不住它。

金鑰不要放進 AI 做的網頁裡。那 170 個網站被讀到的東西裡就有金鑰。這一條是我的判斷，不是哪份報告的原話。

所以還能用嗎

看用在哪。

自己用的小工具，資料只在自己的電腦裡，出錯了頂多是算錯、重做。我做的分帳和記帳就是這一種，我會繼續這樣用。

要放上網路給別人用、會存別人的資料、會碰到錢的，風險是另一個等級。上面兩起事故都是這一類。

維基百科引用 Karpathy 當初提出這個詞時的說法，講的也是週末做著玩的小專案。

這篇沒有放的

其他常被提到的事件和研究。有幾個我只看到別人的轉述，沒有讀到原始出處，所以沒有放。

2026 年比較新的資料。METR 有更新，我沒讀到原文。

大型專案長期維護的問題。那是工程團隊會遇到的，我沒有經驗可以講。