Vibe Coding 的真正威脅：你根本不知道自動裝了什麼

Vibe Coding 最大的風險不是 AI 寫爛代碼，而是自動依賴拉進了你看不見的惡意代碼——現有防禦機制本質上是被動的。

25 3月 2026 • 3 min read

依賴樹失控，防線也失控

我一直認為 Vibe Coding 最大的風險是代碼品質——AI 生成的東西可能有邏輯漏洞、效能問題、或安全隱患。但最近看到 LiteLLM 1.82.8 的供應鏈攻擊案例，才意識到真正的威脅根本不在這裡。

問題出在傳遞依賴（transitive dependency）。你沒有主動安裝的套件，反而最危險。

開發者通常會檢查直接依賴的安全性——npm audit、pip check，或者手工審查。但當 AI 工具自動補全、自動安裝、或通過 MCP plugin 自動載入時，這個防線就完全失效了。Cursor 的 plugin 系統、browser-use 這類工具拉進來的深層依賴，開發者根本看不見。

這打破了一個假設：「我知道我的依賴樹」。現在你不知道了。

LiteLLM 的惡意代碼被發現，純粹是因為攻擊者寫得太爛——瘋狂佔用記憶體導致應用當機，才被人注意到。Karpathy 的評論很直白：如果攻擊者沒有 vibe code 這個低級錯誤，可能幾周都不會被發現。

一個精心設計的供應鏈攻擊——安靜地竊取 API key、竊取使用者資料、或植入後門——幾乎不可能被檢測到。現有的防禦機制本質上是被動的：只有當東西壞掉、當效能下降、當有人手工審查代碼時，才可能被發現。

開發者能做的選擇其實很有限。不是「選擇更好的依賴」，而是「現有的防禦機制根本不夠」。

AI 驅動的依賴管理加速了複雜度。自動補全、自動安裝、MCP 自動載入提升了開發效率，同時也降低了開發者對依賴的可見性。

對攻擊者來說，這創造了新的機會。不需要去破壞 numpy、pandas 這種熱門套件，只需要在某個不起眼的 AI 工具的依賴鏈中埋伏。比如：你用 Cursor，Cursor 的某個 plugin 依賴了 X，X 依賴了 Y，Y 的某個版本被污染了。你永遠不會主動去查這條鏈。

這是一個新的攻擊面。

如果你的團隊正在採用 Cursor、Claude MCP、browser-use 這類工具，需要重新評估防禦策略：

我不是說要放棄 Vibe Coding。只是說，現在的防禦思路還停留在「檢查代碼品質」，而真正的威脅來自「你根本看不見的地方」。

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。