實戰複盤：高強度 Vibe Coding 一個月，用 Claude 開發遊戲本機儲存的感受

這一個月來，我在工作上深度體驗了一把高強度的 Claude Vibe Coding（因為個人專案一直是用 Gemini）。剛好公司這個月給了非常充裕的 API 額度，而我手邊近期在負責開發一個全新的遊戲內本機相簿儲存功能。於是順勢轉變了開發模式：由我來負責設計整體需求和架構，讓 Claude Opus 4.6 作為主力來編寫核心程式碼。

經過一個月的實戰，最大的感受是：當需求明確時，AI 是極佳的輔助工具；但在不斷完善需求和修復問題時，人類工程師的經驗依然不可或缺。

需求明確時，AI 程式碼完成度極高

在專案初期搭建框架時，只要提供清晰的需求邊界，AI 就能快速產出符合預期的程式碼。

例如，在處理本機相簿檔案完整性時，要求實作防資料損壞功能。Claude 立刻領會了意圖，並完美借鑒了 SQLite 的 WAL（預寫式日誌）模式。它準確地實作了暫存檔寫入、原子替換和崩潰恢復邏輯。在這個階段，只要需求明確，AI 就能把細節處理得很好，省去了大量手寫樣板程式碼（Boilerplate）的時間。

修復問題時，AI 暴露了侷限性

然而，當專案進入需求迭代或問題修復階段，Claude 的侷限性就體現出來了。

AI 最大的痛點在於缺乏全局視角的把控。遇到邏輯衝突時，它的第一反應往往是「貼狗皮膏藥」：老是喜歡新增欄位，或者開闢新的 if-else 分支，而不是從整體系統的角度去融入新功能。這時候如果完全聽從 AI 的安排，程式碼很快就會變得難以維護。

典型踩坑案例：Texture2D 快取引用計數

在開發 C# 端的 Texture2D 快取引用計數功能時，遇到了一個典型的案例。

該功能主要用於管理相簿的記憶體。整體架構設計了兩個快取區：活躍頁和非活躍頁。如果有引用，就丟進活躍頁；如果沒引用，就退到非活躍頁，隨時準備被淘汰清理。

結果在處理非同步回呼（Async Callback）與快取引用的結合時，出了一個 Bug。起因是 Claude 寫了一段錯誤的時序邏輯：先將頁面推入非活躍頁，然後才去標記引用。這會導致一個致命的競爭危害（Race Condition）：如果當前容量剛好超限，第一步推入非活躍頁後，頁面會直接被清理掉，導致隨後的引用標記徹底失效。

為了修復這個 Bug，Claude 給出的方案是：加一個 is_early_marked（提前標記）的欄位，試圖用增加新欄位的方式來繞過生命週期錯誤。

這個方案直接被我否決了。憑藉對整體生命週期的理解，重新給它下達了明確的指示：整體檢測非活躍頁面並執行清理的階段必須做延遲，保證該階段發生在非同步操作標記引用之後。透過調整整體時序，問題乾脆俐落地解決了，完全沒有增加任何冗餘的髒欄位。

總結

這次經歷證明，AI 極大地提升了開發效率，但也容易掩蓋架構上的隱患。

如果是沒有經驗的工程師，遇到上述的併發 Bug，大概率會直接採納 Claude 的建議。那麼標記欄位和分支只會越來越多，最終導致模組徹底失控變成「屎山」。在 Vibe Coding 的模式下，具體細節可以不用自己摳，但整體框架的視角和防範爛程式碼的底線，依然需要人類開發者來堅守。