前言：便利背後的風險
Vibe Coding 可說是降低了很多人的技術門檻，讓不懂寫程式的人也能快速打造應用程式。但大家千萬別忘了：當你把應用對外開放時，背後牽涉的金鑰、資源配額、安全機制，就可能成為致命漏洞。
最近LINE 社群就看到一條消息：一位教 Vibe Coding 的老師，用 Google AI Studio 的 Build 功能打造了一款很受歡迎的應用程式，分享給粉絲使用。結果沒想到，短短幾天就被燒掉一萬多元額度！🔥
深入瞭解後才知道：他讓使用者輸入自己的 Gemini API 金鑰，看似讓使用者「自己授權」，但實際上後端仍使用他自己寫死或設定在 Cloud Run 的那把金鑰。因此，所有用戶的請求都跑在他的配額內，最終都是他在「燒錢」。這個設計錯誤，其實在保哥三個月前的直播就講過了，果然還是有人踩到這坑。
這種把金鑰寫在專案／設定檔裡的行為，是程式設計裡最忌諱的資安問題。即便是私有專案，也應該把敏感金鑰放在環境變數、Key Vault 或做加密處理，永遠不要硬塞在專案資料夾中。
警語建議：每次在推廣／教學 Vibe Coding 時，就應加上一句標示：「Vibe Coding 一定有風險，生成結果可能有錯誤，發布前應詳閱程式碼與安全設計」。正如基金的風險說明：投資有賺有賠，購買前請詳閱說明書。
為什麼會「燒到自己」？
輸入金鑰界面只是表象
使用者看到的是讓他們輸入自己的金鑰，但後端根本沒用它。後端仍用開發者本人的金鑰
無論多少流量、按多少次請求，都是算在開發者那把金鑰額度上。資源濫用／配額被爆
若應用被大量或惡意使用，就可能瞬間爆額度、資源被燒完，成本驚人。缺乏監控與警戒設計
如果沒有設速率限制、配額監控、異常警報，就算發生也可能來不及反應。
安全發布與部署完整策略
1. 開發階段：切勿用生產金鑰做測試
- 使用測試金鑰、有額度限制的金鑰進行開發與驗證
- 模擬不同流量情境做極限測試
2. 金鑰與秘密管理
- 把金鑰放在環境變數、秘密管理平台 (Secret Manager, Key Vault, KMS 等)
- 若擔心資料安全，可對金鑰做加密處理（如 OS 加密、DPAPI 等）
- 授權最小原則 (Least Privilege)：只給予 API 所需最小權限
3. 授權與金鑰使用設計
- 若要讓使用者輸入金鑰，後端必須確保真的使用該把金鑰
- 不可設計後端偷偷用開發者的那把金鑰替代
- 調整使用者金鑰的作用範圍與權限
4. 部署與分享策略
- 儘量使用 Google AI Studio 的官方分享／部署機制，不要自己手動下載回去部署
- 若必須自行部署 (在 Cloud Run、Functions、VM 等)，務必在部署環境中引入金鑰管理設計
- 設計環境變數、IAM 權限、角色與 API 存取控制
5. 發布前審查 + Code Review
- 把最終版本的程式碼貼給 AI 或人工審查，找出是否有硬寫金鑰、過寬權限、資源濫用等隱患
- 檢查所有依賴 (library、模組) 是否安全、有無後門或不良設計
6. 宣講與教學時加入警語
⚠ 宣傳／教學必註：Vibe Coding 有風險，生成結果可能有錯誤，請在發布前詳讀程式碼與安全設計。
這句話應比照投資工具的風險說明，一併在你的課程、社群或文章中出現。
7. 上線後監控與風險防範
- 設定配額／速率限制 (Rate Limiting)
- 建立異常使用警報 (當流量過高、短時間內請求激增時觸發通知)
- 若發現異常，即時停用該接口或切斷金鑰
- 日誌記錄 (Logging)／追蹤 (Tracing)，便於事後查源頭
結論：降低風險但不可掉以輕心
Vibe Coding、AI 助手與無程式碼平台帶來的是「高效率開發」與「低門檻創造」的能量，但同時也吸引更多人在「不知不覺中踩到資安地雷」。
- 即使你不會寫程式，也要對產出的程式碼有基本理解或審查能力
- 構建與分享應用時，部署與金鑰管理才是重中之重
- 推廣或教學時，別忘了加入警語與風險宣告
- 上線後要有監控與防禦機制，不要把錢包也一起分享出去