Vibecoding 最忌諱的事——寫給任何想嘗試或者正在做的朋友
整理版優先睇
Vibecoding 最忌諱嘅係跳過架構設計，直接寫代碼，令到後期不斷打補丁。
呢篇文章係作者分享佢用 Vibecoding 方法整一個德州撲克加肉鴿卡牌遊戲嘅失敗經驗。佢用 React、PixiJS 同 Socket.io 整咗四個幾月，但因為一開波就亂寫，冇設計好渲染架構，搞到動畫亂序、同步錯誤，甚至要用 Math.random() 管 z-index 呢啲荒謬做法。佢花咗一個月打補丁，越修越亂，最後先發現問題根源係跳過咗架構設計。
作者後來揾熊師傅傾，對方一句「點解唔用遊戲引擎渲染？」令佢當頭棒喝。佢開始重構，先畫圖將 PixiJS 嘅 Stage 分成六層 Container，固定每層 z-index 範圍，動畫系統獨立用 Promise 控制，Socket 事件鏈路清晰曬。重構只用咗一週，但清咗 13 個隱藏 Bug，重寫 40% 前端代碼。
結論係 Vibecoding 本身冇問題，但要用得啱：業務邏輯、UI 交互呢啲可以 vibe，但渲染架構、網絡同步、數據存儲呢啲地基一定要先設計再寫。開工前應該問自己三個問題：分層結構係咩？有冇研究過成熟做法？規模擴大十倍仲頂唔頂得住？一日嘅架構設計真係可以省十週嘅補丁，佢親身驗證過。
- Vibecoding 最大忌諱係跳過架構設計直接寫代碼，後續補丁成本會爆炸性增長。
- 作者用 PixiJS 但冇用遊戲引擎嘅 Scene Graph 概念，導致渲染層混亂，連動畫順序都控制唔到。
- 補丁越打越離譜，竟然用 Math.random() 做 z-index，係無可救藥嘅行為藝術。
- 重構嘅關鍵係先畫圖，明確分層結構，然後逐步實作，唔好再 vibe 地基。
- 開工前問三個問題：分層結構？成熟做法？擴展性？一日架構設計可省十週補丁。
懸在半空嘅番茄：一個補丁地獄嘅開端
作者喺教研室摸魚嗰陣，用 PixiJS 整咗個德州撲克加肉鴿卡牌遊戲，前端 React 加 PixiJS，後端 Node.js 加 Socket.io。點知畫面上一張卡牌漂喺半空，旁邊個番茄竟然停住唔鬱——唔係卡，唔係掉幀，係真係唔動。呢個番茄成為咗惡夢嘅開始。
跟住幾日，微信羣陸續出現更多問題：下注動畫同抽牌動畫疊埋一齊、多人對戰時各人屏幕唔一致、結算特效播完但卡牌未翻過來。作者開始打補丁：加 delay、寫 z-index、手動監聽事件嚟同步動畫。有一段經典代碼：chipSprite.zIndex = Math.random() * 1000——居然用隨機數管渲染順序，真係行為藝術。
- 1 動畫數量唔多：抽牌、棄牌、加註、過牌、對策牌觸發、結算特效，每加一種要改五個地方，再重新測試所有組合。
- 2 作者當時唔覺得係架構問題，只係覺得自己唔熟 PixiJS，但其實根因係冇設計分層渲染。
熊師傅一句話點醒：點解唔用遊戲引擎？
捱到第二個禮拜，作者頂唔順揾熊師傅求救。對方睇完啲截圖，問咗句：「你點解唔用遊戲引擎嚟渲染？」呢個問題太基礎，但作者完全冇諗起。佢知道遊戲引擎有現成嘅 Scene Graph、分層渲染同動畫調度，但開工嗰陣完全無視咗。
之後佢決定重構，一個字代碼都冇寫，先畫圖。PixiJS 嘅 Stage 底下，六個獨立嘅 Container 一字排開：Background Layer（牌桌背景）、Board Layer（棋盤同社區牌）、Unit Layer（手牌同籌碼）、Animation Layer（特效及粒子）、UI Layer（按鈕文字）、Modal Layer（彈窗）。每層 z-index 範圍寫死，互不越界。
// GameRenderer 類，將六層按固定順序加到 stage 上
const layers = {
background: new PIXI.Container(),
board: new PIXI.Container(),
unit: new PIXI.Container(),
animation: new PIXI.Container(),
ui: new PIXI.Container(),
modal: new PIXI.Container()
};
// 固定 z-index 範圍：Background 0-99, Board 100-199, Unit 200-299, Animation 300-399, UI 400-499, Modal 500+
// 動畫系統獨立，播完返回 Promise，唔拖 UI
class GameRenderer {
constructor(stage) {
Object.values(layers).forEach(layer => stage.addChild(layer));
}
}重構用咗大約一週，邊查 PixiJS 文檔邊改，每步都扔畀 Codex 檢查。總投入 4 週（1 週打補丁，3 週重構），重寫 40% 前端代碼（2000+ 行），清除 13 個隱藏 Bug，包括多人同步、音效時序、粒子泄漏，重寫 60+ 個動畫用例，仲有被羣友嘲笑一週。
Vibecoding 真正嘅用法：分清楚邊啲可以 vibe，邊啲唔可以
作者唔係完全反對 Vibecoding，佢之前用 Claude 整咗個桌面 AI 助手，順利到而家仲用緊。嗰次開工前先同 Claude 詳閲官方文檔，寫咗 詳細嘅規格文檔同製作計劃，一路跟計劃行。同樣方法論，兩次結果唔同，關鍵係：遊戲嗰次佢一開波就寫代碼，覺得 PixiJS 夠輕量，冇諗過六種動畫併發會炸渲染層。
底層架構嘅修改成本唔係線性嘅
第一週改一層只需半個鐘，第三週改同一層要兩週，因為上面啲代碼全趴喺呢層上。所以 Vibecoding 用得啱就得：業務邏輯、UI 交互、玩法規則呢啲可以 vibe，改起嚟快，錯咗唔傷筋骨；但 渲染架構、網絡同步、數據存儲呢啲地基唔可以 vibe，地基歪咗每層都會歪。
- 先研究現有最佳實踐，例如做遊戲就睇下 Unity、Godot 嘅場景圖點分層，呢個概念叫 Scene Graph，幾十年前遊戲引擎已解決。
- 將計劃寫落文件，腦裏面嘅唔算，落到文件先算。作者個桌面助手順利，正正因為規格文檔寫完就定咗路線。
- 最後，記住嗰個懸空嘅番茄，重構後終於正常落地。但作者每次回想都覺得荒誕——佢對住一個靜態番茄修咗十週補丁，而真正問題係佢一開始就唔應該放錯容器。
! !
整輪子嘅代價
Vibecoding 嘅大忌
同學微信彈過嚟嘅時候，我正喺教研室摸魚。導師嘅任務冇鬱過，PixiJS 嘅渲染容器反而疊咗七八層。
「點解有時會睇唔到卡牌移動？」
我切返去瀏覽器，畫面上有一張卡牌正漂喺半空——問題係佢旁邊嗰個掟出去嘅番茄，都喺半空。
詭異嘅係番茄停咗喺度：
唔係卡，唔係掉幀，而係佢真係唔鬱。
就咁懸喺嗰度。卡牌繼續漂，番茄唔鬱。我睥住睇咗五秒，唔知由邊度開始整。
講道理，呢個項目本身都幾有創意，我感覺。德州撲克+肉鴿卡牌構築，2到10人網絡對戰，像素風。前端 React + PixiJS，後端 Node.js + Socket.io。跑咗四個幾月啦。
番茄只係開始。後面嗰幾日，微信羣裏嘅截圖越嚟越多——「落注動畫同抽牌動畫疊埋一齊」「多人對戰時我嘅屏幕同人哋嘅唔一樣」「結算特效播完卡牌仲未翻過嚟」。
我開始打補丁：
先俾動畫加 delay，
再俾唔同元素隨手寫個 z-index，
再手動監聽事件嚟「同步」動畫。
整好一個，炸兩個。有一段代碼我印象好深——chipSprite.zIndex = Math.random() * 1000。我竟然用緊亂數嚟管渲染順序。
深陷泥潭嘅進度
嗰陣時仲未意識到問題有幾大。只係覺得煩。覺得 PixiJS 好坑。覺得係自己唔熟。但其實唔係好啱。
到第三日，補丁變成咗補丁嘅補丁。為瞭解決動畫亂序，我寫咗一個 AnimationManager——個名聽落好似好正規，裏面係一個全局數組加一個遞歸 Promise 鏈。
偽代碼係咁樣：
將動畫掟入 queue，
isPlaying 係 false 就開始播放，
播完一個播下一個，
中間仲要檢查有冇新事件插入。
你品下呢句說話：「中間仲要檢查有冇新事件插入」。
一個渲染系統，竟然要中途打斷自己嘅播放隊列，去查有冇新消息，再重新排序。呢個已經救唔到㗎啦。呢啲係行為藝術。
最黑色幽默嘅係動畫數量——抽牌、棄牌、加註、過牌、對策牌觸發、結算特效。
每加一種，我要改五個地方，然後 QA 將所有組合重測一次。我當時唔覺得呢個係架構問題。我覺得係自己嘅問題（菜）。
講真，寫到呢度我自己都想笑。
第二個星期，我頂唔住啦。
揾咗個會開發嘅熊師傅傾偈，將渲染嗰一撻截圖發過去。佢睇咗十幾秒，問咗一句：
「你點解唔用遊戲引擎嚟渲染？」
我講唔出嘢。唔係佢問咗咩高深嘅問題——而係太基本啦。
我唔係專業做遊戲嘅，呢個只係興趣，但我知道 遊戲引擎有現成嘅場景圖、分層渲染、動畫調度。我知道。但開工嘅時候，我竟然完全冇諗起。
腦裏面淨係得返四個字：醍醐灌頂。然後係心痛。心痛前面嗰十個星期——所有補丁、所有 z-index = Math.random()、所有「整好一個炸兩個」嘅夜晚。嗰啲 token，嗰啲時間，本來一個字都唔應該使。
唔係 bug 整唔曬。而係路一開始就行錯咗。
重構自救路漫漫
決定重構之後，代碼一個字都冇掂過。第一件事：畫圖。
PixiJS 嘅 Stage 下面，六個獨立嘅 Container 一字排開：
Background Layer 管牌枱背景，
Board Layer 管棋盤同埋社區牌位置，
Unit Layer 管玩家手牌同籌碼精靈，
Animation Layer 管所有特效同粒子，
UI Layer 管按鈕文字，
Modal Layer 管彈窗。
每層 z-index 範圍寫死——Background 0-99，Board 100-199，到 Modal 500+。互相唔會過界。
然後寫咗一個 GameRenderer 類，將六層按固定順序加落 stage 度。
動畫系統徹底獨立，播完返番 Promise，唔掂 UI。
Socket 事件嘅鏈路都捋清楚咗：收到事件→更新遊戲狀態→觸發動畫序列→UI 自動響應。
socket.on 裏面直接改精靈位置嘅日子，完結咗。
由開始畫圖到代碼寫完，大概一個星期。
一邊睇 PixiJS 文檔一邊改，每改完一步就掟俾 Codex 檢查一次。冇 vibe 一把梭——每一步都對照，每一步都確認。
計一筆數：
總投入：4個星期，一個月。其中 1個星期喺度打補丁，3個星期喺度重構。
重寫代碼：前端 40%，2000+ 行全部推翻。
隱藏 Bug：13 個——多人同步、音效時序、粒子泄漏，五花八門。
測試用例：60+ 個動畫相關用例全部重寫。
尊嚴代價：俾羣友嘲笑咗一個星期。
呢一切嘅根本原因，係我喺第一日跳過咗一件事：畫一張渲染分層圖。
嗰張圖後嚟花咗唔夠一日畫完。如果第一日就畫咗呢？
Vibecoding 真正嘅用法
我唔討厭 vibecoding。講真，我用佢整成過嘢。
開學開始用嚟搭咗一個桌面 AI 助手，到而家仲用緊，變咗我嘅主力工具。
嗰次嘅開局同呢次完全相反：冇急住寫一行代碼，先同 Claude 將 Hermes 嘅官方文檔由頭睇到尾，寫咗一份詳細嘅規格文檔同製作計劃。
中間每一步都按計劃行，冇偏離預期。
同樣嘅方法論，兩次截然不同嘅結果。分別喺邊度？
遊戲嗰次，我一開頭就寫。
覺得 PixiJS 夠輕量，容器掟入去行得就得。冇諗過六種動畫同時發生嘅時候渲染層會炸，冇諗過多人 Socket 同步嘅時候動畫順序會亂。
PixiJS 本身唔強制分層架構，自由度全部交俾開發者。問題喺我——我將呢份自由度當成咗「容錯率」，以為後面出問題再改就得。
錯了！
底層架構嘅修改成本唔係線性嘅。
第一個星期改一層，半個鐘。
第三個星期改同一層，兩個星期。
上面嘅代碼全部依賴喺呢層上面，鬱地基等於拆樓。
所以 vibecoding 本身冇問題：
關鍵係要分清楚咩嘢可以 vibe
咩嘢唔可以
可以 vibe 嘅——業務邏輯、UI 交互、玩法規則。改起嚟快，錯咗都唔會傷筋動骨。
唔可以 vibe 嘅——渲染架構、網絡同步、數據存儲。地基歪咗，上面每一層都會跟住歪。
實際操作上，開工前先列一張清單。
列咩？列「呢樣嘢改一下要鬱幾多個地方」。如果一個改動預計會同時影響渲染、網絡、UI 三層——先設計再寫。
然後，研究現有嘅最佳實踐。
我要做遊戲，就應該先睇下 Unity、Godot 嘅場景圖係點樣分層嘅。
後嚟我先知道呢樣嘢有個學名叫 Scene Graph，遊戲引擎裏面幾十年前就解決咗，我連呢個關鍵詞都唔知就開幹了。
最後，將計劃寫低。
腦裏面嘅唔算，落到文件裏面嘅先算。我嗰個桌面助手之所以順利，係因為規格文檔寫完嗰一刻，路線就定咗。
嗰個懸喺半空嘅番茄，後嚟重構嘅時候終於正常落地啦。但每次諗返起都覺得荒誕——我竟然對住一個靜態番茄整咗十個星期嘅補丁，而真正嘅問題係：佢由一開始就唔應該被放進嗰個容器裏面。
後記：
如果你在用 vibecoding 做項目，動手前問自己三個問題：
呢個系統嘅分層結構係咩？呢個領域有邊啲成熟做法，我研究過未？呢個設計喺規模翻十倍之後仲用唔用到？
如果第三個問題嘅答案係「唔知」——停一停，先畫張圖。
一日嘅架構設計，真係可以慳返十個星期嘅補丁。我幫你驗證過啦。
以上，既然睇到呢度，如果覺得唔錯，順手點個讚、在看、轉發三連啦～
多謝你睇我嘅文章～～
! !
造輪子的代價
Vibecoding 的大忌
同學微信彈過來的時候，我正在教研室摸魚。導師的任務沒動，PixiJS 的渲染容器倒是疊了七八層。
「為什麼有時候看不見卡牌移動？」
我切回瀏覽器，畫面上一張卡牌正漂在半空——問題是它旁邊那個扔出去的番茄，也在半空。
詭異的是番茄停住了：
不是卡，不是掉幀，是它真的不動。
就懸在那。卡牌繼續漂，番茄不動。我盯着看了五秒，不知道從哪修起。
講道理，這項目本身挺有創意的我感覺。德州撲克+肉鴿卡牌構築，2到10人網絡對戰，像素風。前端 React + PixiJS，後端 Node.js + Socket.io。跑了四個多月了。
番茄只是開始。後面幾天，微信羣裏的截圖越來越多——「下注動畫和抽牌動畫疊一起了」「多人對戰時我的屏幕和別人的不一樣」「結算特效播完卡牌還沒翻過來」。
我開始打補丁：
先給動畫加 delay，
再給不同元素隨手寫個 z-index，
再手動監聽事件來「同步」動畫。
修好一個，炸兩個。有一段代碼我印象很深——chipSprite.zIndex = Math.random() * 1000。我居然在用隨機數管渲染順序。
深陷泥潭的進度
那時候還沒意識到問題有多大。只覺得煩。覺得 PixiJS 坑。覺得是自己不熟。但其實不太對。
到第三天，補丁變成了補丁的補丁。為了解決動畫亂序，我寫了一個 AnimationManager——名字聽起來正規，裏面是一個全局數組加一個遞歸 Promise 鏈。
偽代碼長這樣：
把動畫扔進 queue，
isPlaying 為 false 就開始播放，
播完一個播下一個，
中間還要檢查有沒有新事件插入。
你品一下這句話：「中間還要檢查有沒有新事件插入」。
一個渲染系統，居然要中途打斷自己的播放隊列，去查有沒有新消息，再重新排序。這已經救不了了。這是行為藝術。
最黑色幽默的是動畫數量——抽牌、棄牌、加註、過牌、對策牌觸發、結算特效。
每加一種，我要改五個地方，然後 QA 把所有組合重測一遍。我當時不覺得這是架構問題。我覺得是自己菜。
說實話，寫到這我自己都想笑。
第二週，我扛不住了。
找了會開發的熊師傅聊天，把渲染那一坨截圖發過去。他看了十幾秒，問了一句：
「你為什麼不用遊戲引擎來渲染？」
我說不出話。不是他問了什麼高深的問題——恰恰是太基礎了。
我不是專業做遊戲的，這個只是興趣愛好，但我知道 遊戲引擎有現成的場景圖、分層渲染、動畫調度。我知道。但開工的時候，我居然完全沒想起來。
腦子裏只剩下四個字：醍醐灌頂。然後是心疼。心疼前面那十週——所有補丁、所有 z-index = Math.random()、所有「修好一個炸兩個」的夜晚。那些 token，那些時間，本來一個字都不該花。
不是 bug 修不完。是路一開始就走錯了。
重構自救路漫漫
決定重構之後，代碼一個字沒碰。第一件事：畫圖。
PixiJS 的 Stage 底下，六個獨立的 Container 一字排開：
Background Layer 管牌桌背景，
Board Layer 管棋盤和社區牌位置，
Unit Layer 管玩家手牌和籌碼精靈，
Animation Layer 管所有特效和粒子，
UI Layer 管按鈕文本，
Modal Layer 管彈窗。
每層 z-index 範圍寫死——Background 0-99，Board 100-199，到 Modal 500+。互不越界。
然後寫了一個 GameRenderer 類，把六層按固定順序加到 stage 上。
動畫系統徹底獨立，播完返回 Promise，不碰 UI。
Socket 事件的鏈路也捋清楚了：收到事件→更新遊戲狀態→觸發動畫序列→UI 自動響應。
socket.on 裏直接改精靈位置的日子，結束了。
從開始畫圖到代碼寫完，大概一週。
一邊翻 PixiJS 文檔一邊改，每改完一步就扔給 Codex 檢查一遍。沒有 vibe 一把梭——每一步都對照，每一步都確認。
算一筆賬：
總投入：4周，一個月。其中 1周在打補丁，3 周在重構。
重寫代碼：前端 40%，2000+ 行全部推翻。
隱藏 Bug：13 個——多人同步、音效時序、粒子泄漏，五花八門。
測試用例：60+ 個動畫相關用例全部重寫。
尊嚴代價：被羣友嘲笑了一週。
這一切的根因，是我在第一天跳過了一件事：畫一張渲染分層圖。
那張圖後來花了不到一天畫完。如果第一天就畫了呢？
Vibecoding真正的用法
我不討厭 vibecoding。說真的，我用它做成過東西。
開學開始用搭了一個桌面 AI 助手，到現在還在用，成了我的主力工具。
那次的開局和這次完全相反：沒急着寫一行代碼，先跟 Claude 把 Hermes 的官方文檔從頭翻到尾，寫了一份詳細的規格文檔和製作計劃。
中間每一步都按計劃走，沒有偏離預期。
同樣的方法論，兩次截然不同的結果。差別在哪？
遊戲那次，我上來就寫。
覺得 PixiJS 夠輕量，容器丟進去能跑就行。沒想過六種動畫併發的時候渲染層會炸，沒想過多人 Socket 同步的時候動畫順序會亂。
PixiJS 本身不強制分層架構，自由度全交給開發者。問題在我——我把這份自由度當成了「容錯率」，以為後面出問題了再改就行。
錯了！
底層架構的修改成本不是線性的。
第一週改一層，半小時。
第三週改同一層，兩週。
上面的代碼全趴在這層上，動地基等於拆樓。
所以 vibecoding 本身沒問題：
關鍵是得分清楚什麼能 vibe
什麼不能
能 vibe 的——業務邏輯、UI 交互、玩法規則。改起來快，錯了也不傷筋動骨。
不能 vibe 的——渲染架構、網絡同步、數據存儲。地基歪了，上面每一層都會跟着歪。
實操上，開工前先列一張清單。
列什麼？列「這個東西改一下要動多少地方」。如果一個改動預計同時影響渲染、網絡、UI 三層——先設計再寫。
然後，研究現有的最佳實踐。
我要做遊戲，就應該先看看 Unity、Godot 的場景圖是怎麼分層的。
後來我才知道這玩意有個學名叫 Scene Graph，遊戲引擎裏幾十年前就解決了，我連這個關鍵詞都不知道就開幹了。
最後，把計劃寫下來。
腦子裏的不算，落到文件裏的才算。我那個桌面助手之所以順利，是因為規格文檔寫完的那一刻，路線就定了。
那個懸在半空的番茄，後來重構的時候終於正常落地了。但每次回想起來都覺得荒誕——我居然對着一個靜態番茄修了十週的補丁，而真正的問題是：它從一開始就不該被放進那個容器裏。
後記：
如果你在用 vibecoding 做項目，動手前問自己三個問題：
這個系統的分層結構是什麼？這個領域有哪些成熟做法，我研究過沒有？這個設計在規模翻十倍之後還能用嗎？
如果第三個問題的答案是「不知道」——停一下，先畫張圖。
一天的架構設計，真的能省十週的補丁。我替你驗證過了。
以上，既然看到這裏了，如果覺得不錯，隨手點個贊、在看、轉發三連吧～
謝謝你看我的文章~~