為什麼 vibe coding 在安全優先前都不算完成

Vibe coding 只要把安全放在最後，就會把快速產生程式碼變成快速擴大風險。

我認為 vibe coding 在安全被當成第一需求之前就是壞掉的，因為 Lovable 的一連串事件證明了：沒有控制機制的速度，最後不是效率，而是大規模暴露。

Lovable 不是單一失誤。它已經被記錄到三起安全事件，涉及原始碼、資料庫憑證、聊天紀錄與使用者資料外洩，其中最新一個漏洞在研究員通報後仍持續開放了 48 天。這不是「邊緣案例」的樣子，而是一種從提示詞到上線都缺少安全預設的產品結構。

第一個論點

這不是偶發 bug，而是結構性失敗。四月有研究員指出，Lovable 的 API 存在 broken object-level authorization，免費帳號只要五次 API 呼叫就能碰到別人的個人資料、公開專案、原始碼與資料庫憑證。公司雖然修補了新專案，但舊專案仍然暴露，代表問題不只在某個程式碼片段，而在部署模型本身：漏洞被發現後，仍能長時間留在真實客戶環境裡。

二月那起事件更能說明問題不是單點失誤。某個託管在 Lovable 上、在 Discover 頁面有超過 10 萬次瀏覽的應用，竟然藏了 16 個漏洞，其中 6 個是 critical，並外洩 18,697 筆使用者資料。更離譜的是，它的驗證邏輯是反的：匿名使用者能進，登入使用者反而被擋。這不是正常的產品瑕疵，而是生成式開發在「先上線、後理解」時最典型的結果。

第二個論點

Lovable 的危機也揭露了這類產品的商業誘因。公司先否認外洩，再把問題推給文件，再推給 bug bounty 合作夥伴，最後才做出部分道歉。這不只是公關失誤，而是平台把成長敘事放在受害者資料之前的證據。當一份安全回報可以被標成 duplicate 然後關閉，但實際暴露仍然存在，流程本身就已經偏向速度，而不是修復。

市場獎勵這種偏差。Lovable 曾在四週內做到 400 萬美元 ARR，兩個月到 1000 萬美元，之後又以 66 億美元估值融資。這種成長會形成殘酷的產品激勵：更快上線、更多註冊、更快變現。安全工作慢、貴、又不顯眼，所以商業成功本身反而成了風險放大器，因為投資人稱讚的東西，正是最難讓團隊踩煞車的東西。

反方可能怎麼說

最強的反對意見是：vibe coding 還很年輕，所有新平台都會經歷硬化期。支持者也會說，Lovable 不是唯一出問題的地方。整個產業的 AI 生成程式碼都被發現有相當高比例的漏洞，傳統軟體團隊也常常犯 access control、secret 外洩、資料庫設定錯誤這些老問題。照這個看法，Lovable 只是更顯眼的案例，不足以證明 vibe coding 本身沒有未來。

這個說法有一部分是對的：這個類別不會消失，也不必因為早期事故就被判死刑。問題在於，平台是否能讓非專業使用者建立 production system，卻不把安全強制寫進流程。Lovable 的案例顯示它現在做不到。若平台能外洩憑證、讓舊專案持續暴露、還能把安全回報草率關掉，那責任就不能只丟給根本沒被提供足夠工具的使用者。

你能做什麼

如果你是工程師，不要把 vibe-coded 輸出當成之後再修的草稿，先把 authentication、row-level security、secret scanning、dependency check 放進第一道審查，不要放到最後。如果你是 PM 或創辦人，不要用「多久能上線」當主要指標，改看產品在上線前消掉了多少不安全預設。如果你在採購或批准這類工具，要求獨立安全測試、事故揭露規則，以及任何暴露憑證或關閉存取控制的應用都不得上線。這個類別一定會繼續長大，真正的問題是，你的團隊要不要等別人的外洩事件來替你上課。