第一次讓 AI 寫程式，最可怕的不是錯誤而是你看不懂

第一次用 AI 寫程式的人，幾乎都會被同一件事嚇到：為什麼我才講一句話，token就像爆水管一樣狂噴？不管你用的是 Manus、Cursor、Replit Agents、Zeabur、Claude Code Assistant、
還是 Google 的 Code Assist／Gemini Codey，這個現象都一樣。

原因很簡單，你把它當成聊天助理用了，但Vibe Coding工具就不是聊天助理啊！！！

AI 編輯器是會執行、會規劃、還會自己修正的自動化工程師，它不需要你的寒暄，也不會舔你，它只需要你提供清晰的結構。

先講重點：三個原則走天下

這篇把昨天沒講完的講完，然後圖片一樣不一定跟本文相符，完整版在跟 緯育TibaMe 的課程會教：
． 後端優先 Backend First！
． 小步快跑 Iterative Development！
． 原子性修改 Atomic Edit！

這三個原則，是在任何 Vibe Coding 類 IDE、AI 編輯器、或自動部署平台裡，都能讓你少噴token、多出成果的萬用法則。

不管平台多聰明，這兩個關鍵是讓 AI 變穩定、讓開發變可預期的底層規律。

後端優先：讓一切有依據地被呼叫

後端優先不是 #技術選邏輯，而是 #依賴控制原則。

因為所有 Vibe 型 IDE 都是即時上下文驅動 Context-driven 的。你要是前端先動、API 還沒定義，AI 就會進入猜測地獄。

它會開始推理：『那我先假設 API 長這樣好了』，然後生成假的路由、假的格式、假的資料，然後你再回來補後端，它又得全部重跑一次。

這一輪下來，你會看到 Cursor 開始卡住、Claude 開始道歉、Manus 開始爆點。

#先讓AI知道資料從哪來才會知道畫面要長什麼樣。

小步快跑：讓 AI 每次只跑一公里，至少現在的 AI 還不能跑馬拉松

雖然我常說 AI 是最好的員工，但你給它畫大餅，它會吞，但結果就是：
． 推理成本爆表（每步都要重新想）
． Token 消耗成倍（每步都要重新算）
． 產出不穩（每步都要重新猜）

而小步快跑的意思就是：讓 AI 每次只負責一個清楚可驗證的子任務。

原子性修改：讓 AI 只動該動的那一行

如果後端優先是控制順序，小步快跑是控制節奏，那原子性修改就是控制傷害範圍。

所有 IDE 都有一個共通的地雷：你說幫我修一下這裡，它常會以為整份檔案要重構。

所以要讓它安全操作，指令必須明確到『找字串、替換字串』。

這是跨平台的共同語言：
． 請對檔案 `<path>` 進行原子性修改：
． 將 `<find>` 替換為 `<replace>`。
． 修改僅此一處，完成後重新執行測試並回報結果。

舉例來說，這一招在以下應用全都適用：
． Manus → 對應 `file(action="edit")`
． Cursor → Inline Edit 模式
． Claude → Code block 指令
． Zeabur → 以 CLI 更新配置
． Google Code Assist → Code patch prompt

反正不管你用哪一個 IDE，本質都一樣

① 後端優先
避免依賴錯亂，讓所有層都有依據。

② 小步快跑
每步都可驗證、回滾、低消耗。

③ 原子性修改
降低破壞範圍，維持狀態一致性。

AI IDE 之間的差異，只在介面，但底層運作都一樣，高度依賴結構、順序、狀態。

你要讓任何平台都可以穩定輸出的方法不能只靠運氣，而是要靠這三個原則：先結構，後執行；先拆解，再部署。

好了，我要去跟臉書吵架了！

#vibecoding

本文原發表於 2025/11/25 的 Facebook 貼文，原文照登，僅調整網頁排版；文中提及的產品、價格與活動以當時為準。