Vibe Coding 最大的坑：需求漂移

Sun, 14 Jun 2026 23:11:10 +0800

很多人討論 Vibe Coding 的風險，第一反應是程式碼品質差、安全漏洞多、後期難維護。這些問題都真實存在，但對一個人長期做專案來說，更致命的往往是另一件事：需求漂移。

需求漂移不是某個 bug，也不是一次明顯的錯誤提交。它更像專案裡的方向感慢慢變鈍：功能還在增加，程式碼還在運行，文件也沒有完全丟失，但你已經說不清當初為什麼要這樣拆模組、為什麼保留這個約束、下一步到底該接在哪個位置上。

等到你想加一個看似簡單的新功能時，問題就會集中爆發。改這裡，那裡壞；修那裡，這裡又變形。你開始讓 AI 一輪輪補丁式修復，最後發現真正缺的不是程式碼，而是你對專案的完整地圖。

為什麼長期專案特別容易漂

Vibe Coding 的爽感來自速度。你說一句模糊需求，AI 很快就能生成一屏程式碼；你再補一句，它繼續往前接。短任務裡這很高效，但長期專案裡會帶來兩個疊加問題。

第一，模型會忘。這裡的「忘」不一定是完全看不見上下文，而是長上下文裡的關鍵資訊權重下降。早期的產品目標、架構取捨、命名約定和邊界條件，隨著對話變長，會被大量除錯細節、臨時修復和中間狀態淹沒。上下文窗口越吵，模型越容易抓錯重點。

第二，人也會忘。AI 把寫程式碼的阻力降得太低，原本會逼你停下來想清楚的過程被跳過了。以前需求不清楚，你寫不下去；現在需求不清楚，AI 也能先寫出一版。模糊的意圖被快速固化進程式碼，後面再回頭解釋，就越來越困難。

這也是個人專案最容易撞牆的地方。你同時是產品經理、開發者、測試和維運。寫程式碼時你希望快速推進，做產品判斷時又必須慢下來想清楚「我到底要什麼」。AI 加速的是前者，卻不能替你完成後者。

程式碼能描述系統做了什麼，卻很難說明當初為什麼這麼做。

一個專案失控，常常不是因為某一段程式碼寫得特別糟，而是因為決策背後的意圖散落在長對話、臨時提示、腦內記憶和零碎提交裡。等你再次打開專案，只能看到結果，看不到理由。

這時 AI 也幫不上太多。它可以讀程式碼、找呼叫鏈、補測試，但它無法可靠還原當初的取捨。它甚至可能基於當前局部程式碼繼續「合理化」錯誤方向，讓漂移越修越深。

所以 Vibe Coding 裡的關鍵問題不是「如何讓 AI 永遠不忘」，而是「不要把專案記憶只放在對話裡」。

對抗需求漂移，最有效的做法是把意圖、約束和狀態落到倉庫裡，讓每次新會話都能重新讀取。

最輕量的一步，是寫一份 CLAUDE.md、AGENTS.md 或類似規則文件。它不需要很長，但要清楚寫明：

這份文件的價值不是「提示詞更高級」，而是把最容易漂走的約束固定在每次會話的開頭。它應該短、穩定、可讀，避免塞滿臨時細節。

再往上一步，是寫規格文件。不要直接讓 AI「做一個功能」，而是先把需求拆成可檢查的規格：

規格文件的作用，是讓 AI 圍著明確意圖工作，而不是圍著你隨口的一段提示工作。對個人專案來說，這一步尤其重要，因為沒有產品經理替你把模糊想法壓成清晰需求。

長期專案不要指望一個會話從頭打到尾。會話越長，除錯噪聲越多，越容易出現判斷品質下降。

更穩的做法是把每次工作結束前的狀態寫進文件，例如 PROGRESS.md、TODO.md 或某個任務日誌：

然後再提交程式碼。這樣下一次開啟新會話時，AI 不需要從漫長聊天記錄裡猜專案狀態，而是直接讀取倉庫裡的交接材料。

這件事看起來笨，但很管用。它把記憶從易漂移的對話，轉移到了可版本管理的檔案系統裡。

如果你已經遇到這些現象，就該暫停生成新功能，先整理專案：

這時繼續 Vibe Coding 只會把混亂堆得更高。更好的順序是先補專案地圖，再寫程式碼：整理模組說明、補規格、刪除廢棄路徑、補測試、把重要決策寫成 ADR 或簡短設計記錄。

AI 可以幫你寫程式碼、查 bug、補測試、重構局部實作，但它不能替你長期持有產品意圖。

一個人做專案，最該守住的不是「每次都讓 AI 多寫一點」，而是你始終知道這個東西為什麼存在、下一步為什麼做這件事、哪些邊界不能讓步。只要這部分還清楚，AI 是加速器；一旦這部分漂掉，AI 只會更快地擴大偏差。

所以 Vibe Coding 最重要的習慣，不是追求一個完美提示詞，而是定期把需求、進度、約束和決策寫回倉庫。對話可以很快，專案記憶必須很穩。

原文連結：