[鐵人賽] Day 14：🤖 Vibe Coding 的迷思與我的反思

📰 事件引入：Vibe Coding 花掉一萬多元 API 的新聞

模型最擅長的是模仿人類的語氣與格式，編造細節就像呼吸一樣自然。

最近社群裡爆出一件大事：
有人用 Vibe Coding 在 Google AI Studio 做了一個生圖 App，開放給其他人使用。

介面看似允許使用者輸入自己的 API Key，但實際程式碼卻寫死了作者的 Key，結果所有請求都走作者的帳號 → API 花費一口氣暴衝到 一萬多元。

最後作者在文章裡大罵 Google，說這是平台的問題。

問題點在哪？

👉 程式錯了不是大事，但把責任推給 Google 就很奇怪。
Google 並沒有逼你把 Key 寫死在程式裡，這是開發者應該具備的基本程式邏輯。

更諷刺的是，這位作者還以「講師」身分在開課，教人怎麼用 AI 寫程式。
如果連程式碼結構都看不懂，那要怎麼 debug？

❌ Vibe Coding 的迷思

很多人誤以為 Vibe Coding 就是：
「丟一個需求 → AI 生成完整程式 → 直接丟到正式環境跑」

事實上，這樣的作法完全錯誤，因為：

1. AI 生成的程式碼不保證零錯誤
2. AI 生成的程式碼不保證安全
3. AI 生成的程式碼不保證符合場景需求

真正正確的做法應該是：

• 把需求切成小模組
• 每個模組單獨測試、debug
• 建立 Guideline 與 Check List 來降低風險

如果跳過這些步驟，那就只是「賭 AI 不會出錯」，而不是工程。

🙋 我的反思：我也曾經踩過坑

我一開始用 Vibe Coding 的時候，也犯過一樣的錯。
以為 AI 很厲害，結果它寫出來的程式 bug 一堆，我 debug 到快崩潰。

有一次在協助 成功大學數位證書平台，需要寫一個自動化 PDF 改名程式，結果它生成的 Python 腳本在處理中文檔名時狂出錯，字元編碼錯誤一大堆，檔案還會被覆蓋掉。最後還是我手動一行一行修正，才真正能穩定運作。

另外我在做 Raspberry Pi 機房監控時，AI 幫我生了一個 Linebot Alert 程式。程式看起來很完整，但執行後才發現排程邏輯寫錯。

還有一次，我寫了一個用 nc -zv 探測主機 port 狀態，再發送 Email Alert 的腳本最後我加上 timeout 檢查 + 發信頻率限制，才讓它不會亂炸警報。

這些過程說穿了，就是把「人類工程師該負的責任」放回來，而不是完全丟給 AI。

🔑 重點

即使這次主題是呼叫ollama來解決工作很多的問題，但如果你連程式碼都看不懂，就把 AI 產生的程式碼直接丟到公司正式環境，這樣就有點危險了

真正的工程師優勢，不在於「能不能寫出程式碼」，而在於 能不能理解程式碼背後的邏輯，並負責 debug 與維護。