第一章：AI 鬼打牆怎麼辦？打斷重來的藝術與 Git 基礎回退策略

在 Vibe Coding 的過程中，最常遇到的問題絕對是：「AI 突然開始亂改程式碼，而且越改越錯！」這就是俗稱的「AI 鬼打牆」。本章將帶你深入了解為什麼會發生這種情況，以及如何透過「打斷重來」與「Git 回退」來完美解決這個問題。

為什麼 AI 會鬼打牆？

AI 大語言模型（如 GPT-4, Claude 3.5 Sonnet）的本質是文字接龍。當上下文（Context Window）中充滿了錯誤的邏輯、無效的修補（Patch）、或者是互相矛盾的 Prompt 時，AI 的注意力機制（Attention Mechanism）就會被這些雜訊干擾。

具體來說，鬼打牆通常發生在以下情境：

連續修補（Band-aid Fixes）：你發現了一個 Bug，AI 給了一個解法，結果引發了另一個 Bug。你繼續貼上新 Bug，AI 繼續修補... 最後整個檔案面目全非。
上下文污染：對話串太長，AI 忘記了最一開始的系統架構設定。
幻覺（Hallucination）：AI 虛構了不存在的套件或 API 函式庫。

核心心法：打斷重來的藝術

當你發現 AI 連續兩次修改都無法解決同一個問題，甚至引發更多紅字時，請立刻停止對話！ 不要再試圖說服 AI 去修復那個已經爛掉的程式碼了。你需要做的是「打斷重來」。

什麼是打斷重來？

放棄當前的對話串（Context）。
將程式碼回退到「上一個會動的狀態」（Working State）。
開啟一個全新的對話串，重新描述問題。

實戰教學：如何使用 Git 安全回退

在 Vibe Coding 中，我們強烈建議你「每完成一個小功能就 Commit 一次」。這樣當 AI 搞砸的時候，你才能一鍵還原。

情境模擬

假設你正在開發一個登入按鈕，原本按鈕長得很漂亮，但你請 AI 加上動畫後，按鈕消失了。你跟 AI 討論了 20 分鐘，結果整個頁面都白屏了。

步驟一：確認目前的修改狀態

打開你的終端機（Terminal）或 Cursor 的 Git 面板，輸入：

git status

你會看到一堆被修改的紅字檔案。

步驟二：狠下心來，全部放棄

如果你還沒 Commit 這些壞掉的程式碼，你可以直接用以下指令放棄所有修改：

# 放棄所有未暫存的修改（警告：此動作無法復原）
git checkout .

# 如果有新增但還沒追蹤的檔案，可以用這招清除
git clean -fd

步驟三：如果已經 Commit 了怎麼辦？

如果你不小心把爛扣 Commit 上去了，不用慌，我們可以使用 git reset。首先，查看歷史紀錄：

git log --oneline

找到你上一個會動的版本（例如 hash 為 a1b2c3d），然後執行：

git reset --hard a1b2c3d

砰！你的專案瞬間回到了那個美好的時刻。

重啟對話的 Prompt 技巧

退回安全點後，我們要開啟一個全新的對話（New Chat）。不要在舊的對話裡繼續，因為舊對話已經被污染了。

使用以下 Prompt 結構來重啟對話：

[目標] 我要在 LoginButton.tsx 加上 Framer Motion 的 Hover 動畫。

[目前的程式碼] （貼上你還原後、乾淨會動的程式碼）

[剛剛失敗的教訓] 我剛才嘗試直接包一層 <motion.div>，結果導致原本的 flex 排版跑掉，按鈕消失。請特別注意不要破壞原本的 className="flex items-center" 結構。

總結

AI 鬼打牆的根本原因是上下文污染。
遇到連續兩次修不好的 Bug，立刻停止。
用 Git 回退到上一個安全點。
開新對話，總結失敗教訓，重新發出 Prompt。

掌握這個心法，你在使用 Cursor 或 ChatGPT 寫程式時，效率將會提升 300%，再也不會被 AI 氣到砸電腦了！

🔄 Git Vibe Coding 工作流程實戰

建議的 Commit 頻率策略

在 Vibe Coding 中，強烈建議「每完成一個最小可運作功能就 Commit」。這樣當 AI 搞砸時，你才能一鍵還原。

| 情境 | 建議 | 原因 | |------|------|------| | 剛新增一個元件 | ✅ git commit | 元件本身可運作 | | 剛修正一個 Bug | ✅ git commit | 修復是可驗證的 | | AI 正在嘗試修復 | ❌ 不要 Commit | 狀態不確定 | | 跟 AI 糾纏 10 分鐘 | ❌ git checkout . 重來 | 避免爛扣被保存 |

分支保護策略

永遠不要在 main 分支上直接請 AI 改程式碼：

git checkout -b vibe-experiment/v1  # 實驗分支
# 跟 AI 玩耍...
# 成功 → git merge
# 失敗 → git branch -D 刪除分支

🎯 真實案例：鬼打牆救援流程

# 1️⃣ 發現連續兩次失敗 → STOP
git checkout .  # 還原所有修改

# 2️⃣ 開新對話，重新描述
# 「請在 ProductCard 加上 hover:scale-105 效果」
# 「⚠️ 不要修改外層父元件的 CSS 結構」

關鍵：第一次失敗後，第二次要加限制條件，而不是重複同樣的 Prompt。

關鍵要點

✅ Vibe Coding = 用自然語言描述需求，AI 生成程式碼
✅ 精準的 Prompt = 角色 + 目標 + 格式 + 約束
✅ AI 鬼打牆時：打斷重來 > 繼續糾纏
✅ .cursorrules / CLAUDE.md 是規範 AI 行為的關鍵
✅ Terminal 報錯訊息是 AI 除錯最重要的線索

Prompt 框架

角色：你是一個 [資深 Python 工程師]
目標：[幫我建立一個 FastAPI 使用者 CRUD API]
格式：[回傳完整的 Python 程式碼]
約束：[使用 Pydantic v2, SQLAlchemy async, PostgreSQL]

💡 Vibe Coding 的黃金法則

法則一：小步快跑

每次只請 AI 做一個最小的可驗證的改動。例如，不要一次說「幫我建立整個購物車系統」，而要拆成：

「幫我建立 CartItem type」
「幫我建立 addToCart 函數」
「幫我建立 CartContext」
「幫我建立 CartIcon 元件」

法則二：每次改動後立刻驗證

AI 寫完程式碼後，不要急著叫它寫下一段。先確認：

npm run build 通過了嗎？
瀏覽器畫面上顯示正常嗎？
功能操作符合預期嗎？

法則三：建立檢查清單

# 每次請 AI 改動後的檢查清單
- [ ] TypeScript 編譯無錯誤
- [ ] Linter 無警告
- [ ] 畫面渲染正確
- [ ] 功能操作正常
- [ ] 手機版排版正常

錯誤訊息解讀：看懂電腦在說什麼

Error Message 的四個要素

| 要素 | 範例 | 解讀 | |:----|:----|:----| | 錯誤類型 | TypeError | 型態錯誤——用了錯誤的資料型態 | | 錯誤訊息 | Cannot read properties of undefined | 試圖讀取 undefined 的屬性 | | 檔案位置 | at Object.fetchUser (app/page.tsx:15:23) | 第 15 行第 23 個字元 | | Stack Trace | 呼叫堆疊 | 從哪裡呼叫到哪裡 |

常見錯誤類型與解法

| 錯誤類型 | 意思 | 常見原因 | 解法 | |:--------|:----|:--------|:----| | ReferenceError | 變數未定義 | 打錯變數名稱、忘記 import | 檢查拼字和 import | | TypeError | 型態錯誤 | null.xxx、undefined.xxx | 檢查資料是否為 null/undefined | | SyntaxError | 語法錯誤 | 缺少括號、逗號 | 檢查語法（編輯器通常會提示） | | RangeError | 超出範圍 | 遞迴太深、陣列長度異常 | 檢查終止條件 |

下一章預告：console.log 除錯

讀懂錯誤訊息只是第一步。下一章教你用 console.log 策略性地找出問題根源。