Vibe-coding 可以很快，但安全不會因為你很紅就自動長出來

最近看到一段很寫實的描述：某個爆紅的 AI 工具專案，被作者自己形容成「vibe-coding 出來的」，同時也坦承有明顯資安風險、提示注入（prompt injection）還沒解。

我其實不意外。

因為 Agent 類工具的本質不是「聊天」，而是「替你動手」：讀檔、跑程式、連外、寫入、推送訊息……你把它接進工作流的那一刻，它就是一個高權限系統元件。

爆紅只代表需求被看見，不代表風險被處理。

## 1）為什麼「漏洞一堆也能爆紅」很合理？

因為市場在買的不是「安全」，是「立即可用的效率」。

尤其在早期，大家追的是：

• 看到 demo 就覺得明天可以少做一半雜事

• 能把工作流塞進聊天入口（LINE/Discord/Slack）

• 看起來像一個會自己把事情做完的同事

這種爽感太強。

但安全是反過來的：你通常要等到出事，才會真的感覺到它的價值。

所以早期爆紅的專案，常常是「功能衝得很快」的那一種；而不是「治理做得很完整」的那一種。

## 2）Agent 的安全問題，跟一般 App 不一樣：爆炸半徑更大

傳統 SaaS 出事，常見是資料外洩、帳號被盜。

Agent 出事，除了資料以外，還多了一個麻煩：它真的會動手。

你面對的風險類型會變成：

• 提示注入：把惡意指令塞在文件/網頁/圖片裡，讓 agent「以為那是你的指令」

• 工具濫用：它有讀檔權限，就可能把不該看的看了；它能連外，就可能把不該送的送走

• 執行層風險：讓模型產生/執行程式碼，本質上就是把 RCE 的門打開一條縫

而且最糟的是：很多時候你不會立刻知道它做錯了什麼。

## 3）把「vibe」變成「可用」：你需要的是治理，不是更多 prompt

我覺得比較健康的態度不是嘲笑 vibe-coding。

早期產品很多都得先用 vibe 把需求拉出來。

真正的分水嶺在於：你願不願意把它變成「可控的系統」。

最基本要補的三件事：

1. 最小權限：能不用的權限就不要給；工具與網域要 allowlist。
2. 可觀測與可回放：它做了什麼、讀了什麼、呼叫了什麼工具，要能查。
3. 人機邊界：哪些情況只能出草稿/提案，不能自動執行。

如果你把這三件事補起來，vibe 仍然可以是起點，但不會是終點。

## 4）給想「真的導入」的人：我會用這個問題做第一道篩選

「這工具很猛」我同意。

但我會先問一句：它的失誤成本你承擔得起嗎？

• 它能讀到哪些資料？（包含你忘記放在家目錄的 .env/.ssh）

• 它能對外連到哪？（有沒有預設全開）

• 它做錯的時候你怎麼知道？（log/審計/通知）

• 它能不能撤銷？（回滾/二次確認）

你如果答不出來，不代表你不能用；只代表你應該先把環境隔離、把入口管好、把權限收斂。

## 結尾

我不覺得「vibe-coding」是一個道德問題。

它更像一個階段：先把功能跑起來，市場會給你回饋；但當工具開始碰到真實工作流、碰到真實資料，安全就不是選配。

爆紅可以很快。

但安全永遠不會因為你很紅，就自動長出來。

#AIAgent #Security #PromptInjection #Clawdbot #Product