「vibe coding」這個詞的提出者最近提醒了一件很多人其實心裡有數、但常被熱潮蓋過的事：AI 寫出來的程式碼，依然可能很「尷尬」甚至「噁心」。最值得先留意的不是 AI 能不能寫，而是你是否看得出哪些地方正在變成日後的維護地獄。我的判斷很直接：vibe coding 很適合把想法拉到能跑，但一旦你把它當交付標準，真正被交付出去的是技術債。
有些人把 vibe coding 誤解成「不用懂也能做」。但它更像是「先讓東西動起來，再用專業把它修成能活下去」。
速度會把你送到終點線；品質才決定你能不能留在賽道上。
「尷尬」與「噁心」到底指什麼？不是不好看，而是不好活
AI 程式碼最常見的問題，往往不是語法錯，而是「長得像可維護、其實不可維護」。我把這類尷尬感拆成三種最常見、也最致命的型態：
1) 為了看起來完整，硬塞一套過度設計
你要的是一個小功能，AI 卻自動長出：抽象層、介面、工廠模式、通用化參數、未使用的擴充點。它看起來「工程化」，但每一層都是未來除錯的迷宮。
你會看到的徵兆：
– 檔案變多、類別變多，但核心邏輯沒有更清楚
– 「以後可能用到」的彈性比「現在能讀懂」更重要
2) 邊界條件處理混亂：錯誤處理像拼貼
AI 會把不同來源的範例揉在一起：這裡丟例外、那裡回傳 null、某段又改成回傳 { success: false }。最後你得到的是「每個函式都有自己的脾氣」。
你會看到的徵兆：
– 同一種失敗情境，在不同地方用不同手法處理
– 呼叫端要一直猜：到底會 throw？還是回傳錯誤物件？
3) 安全與資料一致性被當成「之後再說」
vibe coding 常發生在「我先把功能做出來」的節奏裡；AI 也很會迎合這個節奏：先給你能跑的，再把權限、輸入驗證、速率限制、敏感資料遮罩留白。
你會看到的徵兆：
– 把 token、API key 當參數一路傳
– 對輸入只做「有沒有值」，沒做「值是不是可信」
AI 最擅長把「能動」偽裝成「可靠」。
兩個你很可能遇到的真實情境：為什麼會「看起來對、用起來痛」
情境一：你用 AI 把內容「一鍵發佈」到 WordPress，結果最痛的是後續維護
你可能想做的是：把 Markdown 草稿自動發佈到 WordPress，順便補上 SEO 欄位、精選圖片、分類標籤。
現在這類自動化流程確實成熟，甚至有人把「Markdown → 中介層 → WordPress」串成一條指令式工作流（例如把草稿轉成區塊、補 SEO 欄位、產生精選圖片等）。問題是：AI 很容易幫你「拼出一條能跑的管線」，卻沒幫你處理「一條能長期運作的管線」。
常見的尷尬點會長這樣：
– 一次成功，十次有兩次失敗（因為圖片上傳、權限、超時、重試策略都寫得很隨意）
– Gutenberg 區塊轉換能動，但遇到表格、程式碼區塊、引用樣式就變形
– SEO 欄位「有寫」，但規則不一致：slug 有時自動、有時硬編碼
這時你才發現：你省下的是第一次發文的 15 分鐘，付出的是每次出錯都要「重新理解一次整個系統」的 2 小時。
情境二：你讓 AI 進入你的開發環境「幫你做事」，PR 變成閱讀理解測驗
新一代工具正在把 AI 從「聊天視窗」推進到「能操作工具與環境」：能看畫面、點擊輸入、審 PR、開多個終端機，甚至透過 SSH 連到遠端環境一起做事。這類能力一旦跟 vibe coding 合流，確實能把迭代速度拉到很誇張。
但另一面是：AI 會在你沒注意時，為了「把任務完成」做出大量微小改動——加一個 wrapper、搬一次邏輯、順手抽一個 util、再補幾個看似合理的參數。最後 PR 不是「一個變更」，而是「一堆看起來都合理的小決定」。
你會遇到的痛點：
– Code review 很難抓重點：每行都像對，但整體設計沒人負責
– Debug 很難回溯：改動分散在多個檔案，沒有清楚的設計理由
把 vibe coding 用得不尷尬：我會用這 4 個檢查點「把醜碼關在門外」
你不需要反 AI，你需要一套「把生成物變成工程」的檢查點。
1) 先問「核心不變量」是什麼，再看 AI 有沒有破壞它
例如：資料一致性、權限邊界、錯誤處理策略、效能上限。
2) 看它有沒有「假通用」
如果你現在只有一個用例，它卻寫成能支援五種情境，通常代表它在用抽象掩蓋不確定。
3) 看測試是不是跟著需求走，而不是跟著程式走
AI 很會寫「讓現有程式碼通過的測試」，卻不一定寫得出「保護需求的測試」。
4) 看介面是否一致：同類問題同一種解法
錯誤處理、回傳格式、命名風格、資料結構要一致。這是把尷尬感壓下去最快的方法。
我對 vibe coding 的底線：可以快，但不能不負責
我會這樣定位它：
- 用來做原型：非常好用。你要的是「方向」，不是「完美」。
- 用來上線：可以，但必須重寫關鍵路徑。尤其是權限、資料處理、付款、登入、後台管理。
這也很像 WordPress 做 SEO：外掛可以幫你管理標題、描述、站點地圖，但排名上不去往往不是外掛問題，而是結構與內容策略方向錯了 keywordseo.com.tw。AI 程式碼同理：工具很強，但你不能把「有產出」誤判成「有品質」。
一個反直覺的結論：你越依賴 AI，越需要「策展能力」
我特別喜歡「策展」這個比喻：不是把所有東西都倒出來，而是挑出你要被看見、要被長期使用的部分。WordPress 社群甚至出現了以「策展」為核心的 llms.txt 產生與維護外掛：你不是自動丟出所有網址，而是挑頁面、補描述、做驗證、追蹤爬蟲，讓檔案變成可維護的資產 wordpress.org。
vibe coding 也是同一件事：
– 生成很便宜
– 挑選、修剪、統一規格很昂貴
如果你沒有把第二件事變成習慣，第一件事只會讓你更快累積混亂。
結語：尷尬不是缺點，是警報
AI 寫的程式碼會尷尬、會噁心，這不是因為 AI 沒用，而是因為它把「完成任務」放在「長期可維護」之前。
vibe coding 的正確用法，是用它換速度，然後用你的判斷把速度換回品質。當你開始覺得某段 AI 生成碼「怪怪的」，請相信那個直覺：那不是潔癖，是工程嗅覺。
追蹤以下平台，獲得最新AI資訊：
Facebook: https://www.facebook.com/drjackeiwong/
Instagram: https://www.instagram.com/drjackeiwong/
Threads: https://www.threads.net/@drjackeiwong/
YouTube: https://www.youtube.com/@drjackeiwong/
Website: https://drjackeiwong.com/
