給 Vibe Coder 的終極指南：從 API Key 翻車事件學到的完整教訓
一個燒掉萬元的真實故事
有一個故事在社群裡傳得很兇。
一位老師，用 Google AI Studio Build 做了一個有趣的小應用。
他很用心，甚至做了「輸入 Gemini API Key」的介面，讓粉絲覺得自己在操作自己的額度。
結果，悲劇發生了。
用戶的金鑰其實沒生效，程式最後還是默默使用了老師自己放在 Cloud Run 裡的金鑰。
短短幾天，帳單就燒掉超過一萬元。
這就是典型的 「我做 App、別人玩、錢我付」。
1. 喧囂與反思
事件引爆的討論
故事一出，群眾立刻分成幾派。
有人說是 AI 工具害的，太不可靠。
有人則批評老師不專業，不該犯這麼低級的錯誤。
還有人提出另一個角度：
vibe coding 的課程，本來就不是訓練工程師去做部署與維運。
大多數時候，它只是帶人做 demo、做功能展示、快速做 MVP。
在這樣的情境裡，要求老師同時具備深厚的 SRE 或資安能力，會不會太嚴苛？
我的觀點：這不是誰對誰錯，而是角色定位問題
我自己覺得，這不是 AI 的錯，也不是老師單方面的問題。
真正的關鍵在於 角色定位與風險邊界。
vibe coder 的價值是「快」。可以快速讓想法跑起來，看到成果，測試概念。
這個角色本來就不是要一手扛起部署與維運的責任。
但一旦你決定要「發佈給別人用」，你就自動進入另一個遊戲規則。
那時候，你必須要為成本與安全負責。
而這件事，不管你想不想當工程師，都是逃不掉的。
為什麼會燒到作者？剖析「所有權錯覺」
其實技術原因一點都不複雜。
介面雖然收了用戶的 Key，但在呼叫模型的程式裡，最後使用的仍然是作者的金鑰。
可能是因為程式碼裡設了 fallback，
可能是因為環境變數優先，
甚至有可能是根本沒有把用戶輸入的金鑰傳進去。
不管原因是什麼，結果只有一個：
表面上你輸入了自己的卡號，
實際上後台刷的卻是別人的卡。
這就是典型的 「所有權錯覺」。
2. 建立不死的基本功
承認吧，部署不是 vibe coder 的強項。我們的長處是快速開發、驗證與展示。所以，與其強迫自己成為部署專家，不如先建立一套最小可行的「安全習慣」。
習慣一：費用感知 (Cost Awareness)
AI 的費用公式常常是「乘法」：輸出長度 × 批次大小 × 併發數 × 重試次數。
任何一項放大，帳單就可能直接爆。
所以，在發佈之前，請務必把這些參數寫死，設一個合理上限。
在發佈之後，每天花兩分鐘檢查用量，並且開好告警與費用上限。
習慣二：金鑰衛生 (Key Hygiene)
金鑰一定要放在 .env，不要寫死在程式碼裡。AI 也不能直接讀 .env，因為它有可能把內容印出來。最聰明的做法，是再做一個 .env.sample，內容是假的，但能讓 AI 知道有哪些變數存在。
為什麼要這樣？因為 AI 很好奇，如果你完全不給，它就可能幫你寫程式去偷看環境變數，這樣反而更危險。記住：一旦金鑰被看到了，就要馬上重置。
習慣三：最小可行的發佈流程
在你按下「部署」之前，請一定要對 AI 說一句：
1 |
|
這不是形式。不同的 LLM 互相檢查，真的能抓到你看不到的錯誤。要它檢查三件事：
- API Key 流向是否正確
- 有沒有炸帳單的風險
- 有沒有無限重試或缺少超時設定
我就親身遇過：自動生成的管理後台程式碼，直接把帳號密碼硬寫進去，最後是靠另一個 AI 的 code review 才被揪出來。
3. 從避坑到卓越的進階技巧
當你掌握了基本功，不再擔心生存問題後，就可以開始追求卓越，讓你的作品更穩健、更專業。
技巧一：選擇對的遊樂場 (Serverless 優先)
一個更聰明的選擇是 「Serverless 優先」。它就像一個美食街攤位，只有客人點餐時（觸發事件），你的攤位才需要開火（執行程式），並只為這一次的烹飪付費。
- 平台建議： Vercel、Netlify 非常適合前端應用；Google Cloud Functions 或 AWS Lambda 則適合處理獨立的後端邏輯。
- 核心優勢： Serverless 強迫你將功能模組化，大幅降低了因單一 Bug 導致整個服務崩潰與帳單失控的風險。
技巧二：用一句咒語升級你的 AI Code Review
「幫我 code review」太模糊了。下次試試這句咒語：
1 |
|
這句咒語透過賦予 AI 一個專家角色和明確目標，能讓審查結果的品質提升數個檔次。
技巧三：養成「防禦性寫作」的思維
防禦性寫作的核心思想是：「永遠不要相信任何外來的東西，並假設程式隨時可能在最糟的地方失敗。」
- 加上「超時」與「重試限制」： 在呼叫任何外部 API 時，務必設定超時時間與最大重試次數。
- 驗證使用者輸入： 任何來自使用者的資料，在使用前都要進行嚴格的驗證與清理。
- 學習 IAM 角色 (進階)： 當你更熟悉雲端平台後，嘗試用 IAM 角色來取代靜態的 API Key，安全性遠高於寫死的金鑰。
4. 將原則化為日常
「我不是工程師」與「我得負責」並不衝突
有人會說：課程是小白教小小白，真的要要求這麼多嗎？
我覺得這不是苛求，而是尊重。當你把作品發佈出去，別人的體驗裡，應該包含「不會意外花到你的錢」。安全、費用上限、告警，這些不是進階工程技巧，而是產品設計的一部分。
一個你可以建立的「安全開關」習慣
我想像一個最小的日常習慣：
- 先把 Usage 和 Billing 頁面加到書籤。
- 打開用量告警、費用上限、超額停用。
- 回到專案，對 AI 說出那句 code review 的咒語。
- 部署後，每天早餐時間花兩分鐘檢查用量。
- 有異常？馬上降參數、降併發，或停掉自動重試。
這樣就夠了。
最終心法：發佈前的三個靈魂拷問
在發佈之前，先問自己：
- 這個請求，現在刷的是誰的卡？
- 它最多能花多少？
- 出問題時，會自動停嗎？
能答出來，你就準備好了。答不出來，就先別急著上線。
結語
vibe coding 讓我們快，
但發佈，讓我們必須負責。
負責，不是要你立刻變成專業工程師，
而是學會關掉風險。
把平台當護城河，把 code review 當儀式，
把金鑰當保險箱，把每日兩分鐘檢查當刷牙。
這樣，你做的東西才能真的被放心使用，
而不是下一個 「我做 App、別人玩、錢我付」 的故事。
