vibe coding 安全嗎？上線前你必須知道的驗收清單

如果你用 Lovable（一種讓你用描述就能生出 app 的 AI 工具）、Replit 或 Cursor（同類工具）做出了一個「能動的東西」，而且準備接上客戶資料——這篇是寫給你的。

不是要嚇你，而是要幫你搞清楚：「能跑的程式」和「能上線的系統」之間，差的到底是什麼。

問題出在哪

vibe coding（讓 AI 直接根據你的描述生成整個應用程式的方式）讓非工程師也能快速做出 app，這是真的。
但問題從來不是「AI 寫的程式碼品質差」這麼簡單。

根本問題是：很多人以為「能跑」就等於「能上線」，於是跳過了驗收流程（acceptance criteria，也就是上線前確認系統是否符合安全與功能要求的步驟）、安全邊界，以及那個產業、那個場景本來就該有的工程判斷。

AI 壓縮了很多職能，也加速了單點執行。
但懂流程、知道哪個環節需要把關的人，反而會變成更稀缺的角色。

把判斷外包給 AI，最後很可能會用返工、錯誤資料，甚至資安事件，把前面省下的時間全部賠回來。

資安真實洩漏案

以色列資安公司 RedAccess 在 2026 年 5 月發布的「Shadow Builders」報告裡，掃描了約 38 萬個以 vibe coding 平台建立的應用。
他們發現約 5,000 個 app 含有敏感資料，其中超過 2,000 個在公開網路上沒有任何存取控制（access control，決定誰能看到哪些資料的把關機制）。

這裡要補一件事：RedAccess 是資安新創，有商業誘因讓結果看起來更嚴重。
38 萬個 app 裡出問題的約 1.3%，多數 app 並沒有被掃到嚴重漏洞。

但「只有 1.3%」這句話的另一面是：那 2,000 個 app 後面是真實的資料洩漏。
包含英國藥廠的臨床試驗狀態資料、巴西銀行的內部帳務、英國家具零售商的客服聊天記錄。

資安研究機構 Escape.tech 另外掃描超過 1,400 個 vibe-coded 產品，也發現三分之二存在安全問題。
兩份獨立研究互相佐證：vibe coding 的風險不是假議題，而是正在發生的現場問題。

這些案例反覆出現幾個結構性問題：
隱私設定預設公開、admin 存取預設開放、部署時沒有基本的存取控制。

這些不是單純的 AI bug。
而是驗收機制缺席的症狀。

AI 生成程式碼 漏洞數據怎看

資安公司 Veracode 的報告顯示，AI 生成程式碼的漏洞密度是人工撰寫的 2.74 倍，45% 的 AI 生成程式碼樣本引入了 OWASP Top 10（網站應用最常見的十大安全漏洞清單）裡的問題。

但這個數字需要加上一個限定詞：它可能混入了「用 AI 寫程式的人有很大比例是初學者」這個混淆因素。
更公平的比較，應該是在同等技術背景下，對照有 AI 與沒有 AI 的開發結果。

目前還沒有嚴格控制組的實驗能完整回答這件事。

這個批評成立。
但它不改變一個現場事實：大量非工程背景的人正在用 vibe coding 接上真實客戶資料。

他們的技術背景不會因為學術上的比較基線爭議而自動提升。
所以風險是存在的，不管最後歸因給 AI、平台，還是使用者本身。

另一個值得注意的平行事件，是 npm（全球最大的 JavaScript 程式碼套件管理平台，幾乎所有網頁 app 都依賴它）在 2026 年 6 月 25 日宣布的新政策：高影響力帳號在 email 變更後，會進入 72 小時唯讀（read-only）狀態。
這是為了封堵「竊帳、換信、發惡意套件」這條供應鏈攻擊路徑。

換句話說，AI 生態的安全問題不只在應用層。
也存在於你用來建 app 的工具鏈本身。

我的踩雷

我自己在建立自動化流程時，也走過非常類似的路。

最早一版，我把某個內容生產流程全部自動化，覺得「能動了、能輸出了」就差不多。
後來才發現，我根本沒有設定錯誤處理的邊界。

某次外部資料源格式一變，整條流程靜默出錯，結果產出了三批錯誤內容。
更糟的是，這不是流程主動報告給我，而是我在 QA（品質確認，上線前確認輸出是否正常的步驟）回頭掃時才發現。

那次讓我第一次深刻感受到：沒有驗收機制的自動化流程，只是讓錯誤跑得更快。

當時的自動迭代看起來很順，實際上問題正在安靜地累積。
後來我把 QA 改回人工掃一遍，流程才真的變健康。

這不是 AI 做了什麼。
而是我跳過了什麼。

上線差在哪

下面這張對照表，整理了多數 vibe-coded app 洩漏案例背後的共同結構問題，以及「能上線的系統」應該有的狀態：

常見的缺席項目｜「能跑」的狀態｜「能上線」應有的狀態
存取控制｜隱私設定預設公開，沒改過｜明確設定誰能看到什麼，並且預設私有
admin 權限｜後台預設開放，無角色區分｜設定角色與權限層級，admin 需另外保護
錯誤處理｜出錯時 app 靜默失敗，或顯示技術錯誤｜明確的錯誤訊息、錯誤記錄與通知機制
個資資料範圍｜不確定 app 暫存了什麼使用者輸入｜明確知道資料流向、暫存位置與刪除機制
部署前審查｜直接按下部署，沒有檢查清單｜對照安全清單，至少跑過一次 OWASP Top 10

這張表裡的每一項，AI 都可以幫你寫出功能。
但「這個 app 上線後，這些設定到底是不是對的？」這個判斷，需要人來做。

也就是說，vibe coding 可以幫你加速把東西做出來。
但它不會自動幫你完成上線前驗收。

vibe coding 個資法風險

如果你在台灣用 vibe coding 建立會接觸客戶個人資料的工具，《個人資料保護法》的責任框架是存在的。

這裡需要明確說：這不是法律建議，法律責任仍需要依個案判斷。
本文只能點出風險框架。

但有一點可以確定：「是 AI 幫我寫的程式」不會是資料洩漏事件發生後的免責理由。
開發者，包含非工程背景的使用者，同樣會落在這個法規框架下。

Georgia Tech（美國頂尖理工學院，其資安研究具國際參考地位）追蹤到，可歸因於 AI coding 工具的 CVE（已被公開登錄的安全漏洞編號），從 2025 年初的 6 個，一年內加速到 74 個。

AI 寫程式已經是常態。
2026 年 GitHub（全球最大的程式碼協作平台）上，已有 46% 的新程式碼由 AI 生成程式碼完成。

這條路不會回頭。
但 AI coding 成為常態，不代表法規框架會因此放寬。

AI寫程式 該怎麼自我判斷

核心判斷是：AI 幫你寫得出程式，但不代表它能幫你擋住漏洞。
中間差的那張驗收清單，才是你最需要補的東西。

這不是說 vibe coding 不能用。
Palo Alto Unit 42（美國頂尖資安公司 Palo Alto Networks 的威脅研究部門）的研究，也肯定了 vibe coding 的生產力收益，研究引述最高可提升 30% 到 50% 的日常開發任務效率。

所以解法不是禁用，而是在流程中加入安全層。
但前提是，你要知道安全層應該加在哪個位置。

對非工程背景的使用者來說，最大的卡點剛好在這裡：你不知道自己不知道什麼。

可以先用這三個問題做自我檢查：

你的 app 有沒有接觸到任何人的個人資料？
如果有，隱私設定是否預設私有，存取控制是否明確設定？

你有沒有辦法回答：「這個 app 出錯了，我怎麼知道？」
錯誤處理機制是否存在？

上線之前，你有沒有問過工程師朋友，或用 AI 對照 OWASP Top 10 跑過一次基本檢查？

如果三個問題裡，有任何一個答案是「不確定」——先暫停。
不要急著接上客戶資料，先把風險搞清楚再說。

vibe coding 安全常見問題

• vibe coding 做的 app 一定不安全嗎？
  不是。RedAccess 掃描約 38 萬個 app，有問題的約 1.3%，多數 app 沒有被發現嚴重漏洞。安不安全不只取決於是不是用 vibe coding 做的，而是取決於 AI 寫完之後，你有沒有做驗收。
• AI 生成的程式碼漏洞比人工多，是 AI 本身的問題嗎？
  Veracode 的數據確實顯示，AI 生成程式碼的漏洞密度較高，但這個數字可能混入「使用 AI 的人多半是初學者」的混淆因素，目前尚無嚴格控制組實驗能完全排除這個影響。AI coding 的漏洞問題是真實存在的，但把責任全推給 AI、忽略驗收機制缺席，結論會跑偏。
• 沒有技術背景，怎麼做安全驗收？
  最低門檻的做法是：把你的 app 描述丟給 AI，請它對照 OWASP Top 10 逐條問你問題，再根據 AI 的引導確認每一項設定。這不能取代真正的資安審查，但至少能幫你確認最基本的項目沒有漏掉。
• 用 vibe coding 平台本身的安全設定夠嗎？
  不一定夠。vibe coding 平台常見的結構問題包括：隱私設定預設公開、admin 存取預設開放、存取控制沒有設定完整。你需要主動檢查並修改這些設定，不能假設平台已經幫你處理好了。
• 台灣個資法對 vibe-coded app 怎麼規定？
  法律責任需要依個案判斷，本文不提供法律建議。但可以確定的是：如果 app 儲存或處理客戶個資，資料洩漏事件發生時，開發者仍有責任。「是 AI 寫的」不會是免責理由。如果你不確定自己的情況，建議諮詢有科技法律背景的律師。