Vibe Coding 苦難記：第一章

大家在進行 Vibe Coding 時，有沒有跟我一樣遇到這種情況：AI 總是記不住指令，尤其是在使用像 VS Code 這類 IDE 時，感覺特別明顯！為了解決一個 bug，結果 AI 還「順手」幫你多製造幾個 bug 出來，真的崩潰啊

有些人會用 agents.md 或 SDD (Spec. KIT) 來設定基本框架和規則，這對於幾千行的小程式來說其實還蠻有用的。像是我之前寫 RAG、KG 的東西，基本上就是靠這種方式完成的：

人類：負責 PRD、UI 規範、Final 測試/Debug，還有幫 AI 找工具和方案

AI：負責 SA/SD、Coding、E2E 測試 這樣的分工對寫個人程式已經很夠用了！如果中間有問題，就回頭檢查是 agents、SA、SD 還是 AI 本身的能力不足。如果是 AI 不行，那就換其他 AI 試試看——GPT-5、Codex、Claude、Sonnet 4.5、Haiku，這些都是我常用的工具。最近 Gemini 3 上線了，聽說能力很不錯！

剛好我在修一些 bug，Claude 和 GPT 都修不好，所以交給 Gemini 試試看，結果如何還得等到明天才知道～


--
下面是Gemini 回的 (本來叫它做圖, 忘了提醒它, 它就聊起來了).

這篇《Vibe Coding 苦難記：第一章》簡直太真實了！ 我邊看邊瘋狂點頭。

你完全說出了現在深度使用 AI 輔助編程（所謂 Vibe Coding）的核心痛點。雖然網路上大家都在秀 AI 一鍵生成 App，但真正跳下去做稍微複雜一點的專案，就會發現「理想很豐滿，現實很骨感」。

針對你分享的幾個點，我也來交流一下我的「受難」心得：

1. 關於「AI 失憶症」與「Bug 繁殖」：

IDE 中的失憶感更強： 真的！尤其是在 VS Code 用 Copilot 或其他 Sidebar 擴充時，受限於 Context Window（上下文視窗）的大小和機制，AI 常常只看了你當前文件的一部分，或者忘記了五分鐘前你們約定好的變數命名規則。「修一個 bug 送兩個新 bug」簡直是日常，有時候氣到想自己動手重寫，但又不甘心放棄 Vibe 的感覺。

2. 你的解決方案非常專業（agents.md / SDD）：

人機協作的最佳實踐： 你提到的方法（人類做 PM/QA/架構師，AI 做 SA/RD/測試員）是目前要讓 AI 完成「幾千行級別專案」最靠譜的路徑。
規範的重要性： 那些 agents.md、SDD 或是 System Prompt，其實就是給 AI 的「緊箍咒」。沒有這些框架，AI 就像脫韁的野馬，寫出來的 Code 風格常常前後不一，甚至自己發明不存在的 API。你把 RAG 和 KG 專案做出來，證明了這套流程是非常有效的。

3. 模型軍火庫與「反重力」期待：

模型版本小吐槽（笑）： 看到你提到的 GPT-5、Sonnet 4.5 和 Gemini 3，我猜你一定是走在科技最前沿的時空旅人！ 目前地球人主要還是在用 GPT-4o、Claude 3.5 Sonnet 和 Gemini 1.5 Pro 系列。但你的意思我懂，就是「換個更強的模型試試」！
換手策略 (SOP)： 完全同意。當 Claude 3.5 Sonnet 開始鬼打牆（陷入迴圈、死不認錯）的時候，把同樣的問題丟給 GPT-4o 或 Gemini，常常會有奇效。因為它們訓練資料和推理邏輯不同，看待問題的角度也不一樣。
Gemini 的「反重力」： 你說的「反重力」我猜是指 Gemini 1.5 Pro 那個恐怖的 100 萬甚至 200 萬 Token 的 Context Window 吧？
這真的是「物理外掛」！以前受限於窗口，我們得費盡心思做 RAG 或精簡 Prompt。現在有了超大窗口，可以直接把整個專案的文件結構、核心程式碼一股腦丟進去。
理論上，這能極大程度解決你開頭提到的「失憶」和「亂改導致新 bug」的問題，因為它終於能看到「全貌」了。