Vibe Coding 實戰：AI 輔助開發真正改變了什麼

「Vibe coding」這個詞現在很流行，意思大概是：你描述你想要什麼感覺，AI 幫你生成程式，你調整、測試、再描述，迭代下去直到你要的東西出現。

聽起來很美好。實際用起來，沒那麼簡單，但也沒那麼難——只是和你想像的不一樣。

以前是什麼感覺

在 AI 工具成熟之前，一個人要做一個有後端的 Web 應用，光是設計資料庫 schema、寫 API、處理認證、部署，就足以消耗掉大部分的精力。還沒開始做真正重要的東西（使用者體驗、產品邏輯），就已經累了。

很多想法就死在這裡。不是沒時間，是「開始一件事的摩擦力」太高了。

AI 工具不是讓你不需要懂技術。但它確實做到了幾件事：

一、第一版草稿的速度

以前要做 Supabase RLS 設定，需要先查文件、理解 policy 語法、測試、除錯。現在是描述「我要讓用戶只能看到自己的資料，但有一個 service_role 的 webhook 可以寫入所有人的記錄」，AI 給你一個接近可用的起點，你調整細節。

時間不是省了 10 倍，但「從零開始的恐懼感」大幅降低了。

二、不熟悉的領域

刷題神器用到了藍新金流的 webhook 整合。那套 API 文件不算友善，參數多，加密方式也要自己搞。以前碰到這種情況，光是看文件就要花一整天。

AI 可以幫你解讀文件、寫初版整合程式、指出你遺漏的欄位。你仍然需要懂發生了什麼，但「搞懂它」的時間短了很多。

三、重複性工作

玩樂學的每個遊戲結構類似：一個 HTML 檔案、一套觸控事件處理、一個動畫迴圈。做完第一個遊戲之後，後續遊戲的骨架生成幾乎可以完全交給 AI，你只需要專注在玩法邏輯本身。

產品判斷。 AI 不知道你的使用者是誰、他們在哪個步驟放棄、什麼樣的體驗才算「停不下來」。TARGET_STREAK = 3 這個數字是經過思考的設計決策——連續答對 1 次可能是猜的，3 次才代表真的記住了。這種判斷沒辦法問 AI。

架構決策。 玩樂學為什麼選 Vanilla JS 而不是 React 來寫遊戲？因為遊戲需要幀率流暢，virtual DOM 的更新機制在這個場景下是多餘的。這個判斷要先對兩邊的特性有足夠理解才能做。

除錯的最後一哩。 AI 生成的程式有時候在特定條件下才會出錯。找出那個條件、理解根本原因，還是要靠你自己去讀 stack trace、在瀏覽器 DevTools 裡追。

比較準確的描述是：AI 是個很快的初稿生成器，加上一個隨時可以問的同事。你的角色從「把所有東西從頭寫出來」變成「決定要做什麼、驗證做出來的東西是不是對的」。

這個角色轉換對一個人的工作室來說意義很大。刷題神器和玩樂學都能在相對短的時間內從想法變成上線的產品，AI 是很重要的原因之一。

但那個「一個人能做到的事的範圍明顯變大了」的感覺，前提是你對技術有基本的掌握——知道 AI 生的東西哪裡有問題，知道什麼問題值得深入問、什麼問題要自己想清楚再問。

完全沒有背景知識、純靠 AI 做出東西的例子，可以看沒有 WPF 背景做出滑鼠特效工具這篇；如果你完全不會寫程式也想試試，從 Gemini Canvas 開始是最低門檻的起點。

工具變強了，判斷力還是你自己的事。