AI Game Dev 下一波 bottleneck：architecture 決定

2025 年，任何識少少 programming 嘅人都可以用 Cursor 或者 Claude 喺一個 weekend 整到一隻行得嘅 game prototype。2026 年嘅今日，呢啲 prototype 嘅數量大爆炸，但真正成功出到 early access、搵到玩家、留到人嘅 game，比例冇高過幾年前。點解？因為 AI 幫你寫到 code，但幫唔到你諗 architecture。當你嘅 game 由 1 個 scene 擴展到 50 個 scene，由 3 個 mechanic 增加到 30 個 mechanic，由你一個人寫到要同 AI agent 協作，你嘅 codebase 會喺兩星期內爛到連 AI 都救唔返。問題唔係 AI 唔夠勁，而係你嘅 foundation 唔夠好。

Architecture 決定 game 嘅生死上限

Indie game dev 圈好耐以嚟有個迷思：prototype 快就係贏。Quick and dirty、先整到出嚟再算、refactor 係之後嘅事——呢啲諗法喺 pre-AI 年代已經有代價，但喺 AI-native workflow 入面係致命嘅。點解？因為 AI 生成 code 嘅特性係「平均質素高但 consistency 低」。每一次你用 AI 生成一個新 system，如果冇清晰嘅 architectural boundary，AI 好大機會會亂 import、 duplicate logic、甚至自己 create 自己嘅 abstraction。三個星期後你打開 project，會見到五個唔同嘅方式處理同一件事、一堆冇用過嘅 class、同埋互相依賴到拆唔到嘅 module。

我見過唔少 indie dev 用 Unity-MCP 呢類 tool 去同 Claude 或者 GPT 連接 Unity Editor，直接 natural language 落指令整 system。呢個 workflow 嘅生產力提升係真實嘅——一個 component 由諗到寫好連測試，以前要半日，而家 20 分鐘搞得掂。但問題係：如果你嘅 architecture 唔清晰，你落俾 AI 嘅 instruction 就要越嚟越長、越嚟越 specific、越嚟越 fragile。到最後你花嘅時間唔係寫 code，而係「教 AI 點樣唔好整爛嘢」。呢個唔係 AI 嘅 limitation，係你嘅 architecture 唔夠好令到 AI 嘅 advantage 發揮唔到。

一個好嘅 game architecture 喺 AI 時代嘅定義好簡單：每個 module 嘅 responsibility 要夠細、夠獨立、interface 要夠 clean，令到 AI 可以睇住個 interface definition 就寫到 implementation，而唔需要了解成個 codebase。如果你做到呢點，AI 就係你嘅十倍生產力引擎；如果你做唔到，AI 就係你嘅 technical debt 加速器。

CCGS（Component-Concern-Gameplay Separation）作為新 paradigm

傳統 game architecture 主要係 ECS（Entity-Component-System）或者 OOP hierarchy。呢兩種 paradigm 喺人類寫 code 嘅時代好好用，因為人類 naturally 識得維持 mental model。但喺 AI 生成 code 嘅時代，我認為 game dev 需要一個新嘅 approach——CCGS（Component-Concern-Gameplay Separation），一個更適合 AI 協作嘅架構模式。

CCGS 嘅核心原則係將 game code 切成三層：第一層係純粹嘅技術 component（render、input、audio、network），呢啲應該係 stable 嘅、testable 嘅、同 game design 完全無關。第二層係 concern layer（resource management、state machine、event bus、data binding），呢啲係 medium-level abstraction，負責將技術 component 嘅能力轉化為 game design 可以用嘅工具。第三層先係 gameplay layer（player behavior、enemy AI、quest logic、UI flow），呢層係最 volatile 嘅、最需要頻繁改嘅、亦係 AI 貢獻最大嘅地方。

呢個 separation 嘅好處係：AI 可以喺 gameplay layer 自由發揮，因為佢嘅 dependency 只係 concern layer 嘅 API，唔會直接搞到底層技術 component。就算 AI 生成嘅 gameplay code 有 bug 或者 design flaw，影響範圍都被 confinement 喺 gameplay layer 入面，唔會炸爛你成個 render pipeline 或者 network system。Indie developer 只需要 maintain 好 concern layer 嘅 interface documentation，就可以 unleash AI 去做最花時間嘅 gameplay iteration。

Unity-MCP 嘅出現令呢個 pattern 更加 practical。你可以直接用 natural language 同 AI 講「幫我整一個 inventory system，用 commons/ItemContainer 同 commons/ItemDefinition API」，AI 就會生成完全符合你 concern layer 約定嘅 code。如果你嘅 architecture 夠好，你甚至唔需要睇 AI 生成嘅 code——直接落 build 跑 test，test pass 就得。呢個先係真正嘅 AI-native game development workflow。

Modular design 係 AI collaboration 嘅 prerequisite

好多 indie dev 忽略咗一個關鍵事實：AI agent 嘅 context window 係有限嘅。即使 GPT-4 或者 Claude 可以有 200K token，實際嘅 coding performance 喺 context 超過某個 threshold 之後會急劇下降。呢個唔係 model 嘅問題，而係 attention 嘅天性——太多不相關嘅 code 會 dilute 模型對當前任務嘅理解。

所以 modular design 唔再只係 software engineering 嘅 good practice，而係 AI collaboration 嘅 prerequisite。每一個 file 應該越短越好、每一個 class 應該越 focused 越好、每一個 folder 嘅 naming convention 應該越 predictable 越好。AI 唔似人類 developer 咁可以「心裡有個 mental map」，佢需要靠 file structure、import chain、同 function signature 去 infer 你嘅意圖。如果你嘅 project structure 混亂，AI 唔會話俾你聽「喂你個 architecture 有問題」，佢只會繼續 generate 更加混亂嘅 code，然後你自己喺一個月後崩潰。

我 recommend 所有 indie game project 都要有嚴格嘅 folder convention：src/Components/ 放 pure technical component，src/Concerns/ 放 cross-cutting concern，src/Gameplay/ 放 game-specific logic，src/Tests/ 放 unit test 同 integration test。每個 folder 入面再按 feature 拆分 subfolder。呢個 structure 可能睇落有點 over-engineered 對於一個細 project，但請相信我——當你嘅 AI agent 可以喺 10 秒內精準定位到要改嘅 file，而唔係要 scan 成個 project 先搵到，呢個 investment 嘅回報係 100 倍。

結尾：開始 building，但 building 之前先 plan

AI 令到 game development 嘅 entry barrier 前所未有咁低，但同時令到 good architecture 嘅價值前所未有咁高。我俾所有想用 AI 做 game dev 嘅香港 indie developer 三個 concrete 建議。

第一，建立你嘅「architecture bible」。唔需要好長，但一定要清楚定義你嘅 naming convention、module boundary、responsibility distribution。呢份文件唔係俾人類睇嘅，係俾 AI agent 做為 system prompt 嘅。每次開新 project 或者新 feature，先將呢份 architecture bible inject 入 context，再開始 generate code。

第二，投資時間喺 concern layer。唔好急住寫 gameplay，先整好你嘅 event bus、state machine、resource manager。呢啲 infrastructure code 係你同 AI 之間嘅溝通語言，quality 直接決定 AI 嘅 output quality。

第三，每一段 AI 生成嘅 code 都要有 test。呢個唔係因為 AI 會寫錯——人類都會寫錯——而係因為 test 係最快嘅 feedback loop。AI 生成 code → run test → fail → AI fix → pass → merge。呢個 loop 越快，你嘅 iteration speed 越快。Test coverage 低嘅 project，AI collaboration 嘅效率會指數級下降。

Game dev 嘅 future 唔係 AI 取代 developer，而係 developer 變成人類 architect + AI builder。Architecture 做得好嘅人會贏，就係咁簡單。