小編精選 - 技術文章翻譯 · 06月01日

將所有程式設計工作交給 ClaudeCode 和 Codex，進行商用等級的 Unity 遊戲開發【後篇】

ClaudeCode 與 Codex 完全負責編碼，打造商用級別的 Unity 遊戲開發【後篇】

大家好，我是 Lise。

在現在的遊戲開發現場，大概不管是哪間公司、哪個專案，應該都多少有在使用 ClaudeCode 或 Codex 來輔助 AI 開發；也有在遊戲 Jam 等活動中，出現「試著讓 AI 做個小型遊戲程式看看」這類嘗試。

不過即使是已經在活用 AI 的工程師，心裡多少還是會有一個疑問：

「能不能把整個遊戲開發和設計都直接丟給 AI 呢？」

這篇文章就是我嘗試「從零開始用 AI 進行遊戲開發」的備忘錄。

作業儲存庫

前篇的回顧

前篇的總評與結論是：

「可以把所有編碼都交給 ClaudeCode/Codex 來完成 Unity 遊戲開發。」

但這並不是說可以毫無準備地全丟給 AI，而是建立在以下前提之上：

先「設計資料結構」，減少技術債產生的空間
從「以程式碼審查反推」的方式建立程式品質指南，效率地打造不易產生技術債的護欄

這次就接續前篇，整理實際持續進行遊戲開發後所得到的知見。

標題中「商用級別」的定義

前篇沒有提到，這裡指的是以下內容。

技術性負債能控制在「人類工程師可以開發的一般遊戲開發水準」

觀點包括：

不要做出 AI 實作時常見的「只要能跑就好」的義大利麵程式碼
功能設計要考量未來的擴充性
即使 AI 不能再使用，也要有足夠的程式品質，讓人類工程師能接手與修改

可能有人會想：「可是我本機上明明就能跑啊？」
但如果從零開始設計就直接丟給 AI，常常會被塞成一個檔案 5000 行之類的狀況，
根本無法在專案啟動階段當作可用的開發基礎。

這次要談的，就是如何設法解決這件事。

成果物

其實和前篇相比，方針轉換或手法上的大變化並沒有很多。
這是非常好的消息，代表我們能持續輸出一定水準的成果。

（不過實際上，必須先把這些成果物用來量產遊戲，才算真正達成目標。）

後篇會解說這套工作流程與思考方式，以及 AI 會使用的規則文件。

如果你想直接看成果，可以從這裡開始。
分支是 develop2。（因為不小心把 develop 當成前篇的參照分支了）

關於遊戲

因為不是本文重點，所以我只簡單附上做了什麼遊戲的圖片、影片與 WebGL Build。

有用 AI 做遊戲的人可能有經驗：
如果隨便讓它做，大概在到達這種複雜度之前就會卡住。

↑可以透過 WebGL Build 實際遊玩

攝影機移動：WASD
樓層切換：Q/E
滑鼠選取

單用 AI 實作 Unity 遊戲的工作流程

雖然和前篇有些重複，但如果中途才開始看，可能會不太容易理解，所以我還是從頭說明。
反正會看這篇的人，大概也讀過很多 AI 相關文章了，所以我只會聚焦在我認為重要的部分。

先講一點，這整套工作流程的核心就是在作業間隙進行的文件化（docs 化）。
第 2 步我會詳細說明。

1. 先決定要做什麼遊戲

「決定」的意思，就是要真的決定。

你可能會想：「大概已經有方向了吧？」
但如果帶著模糊的遊戲印象就開始讓程式動工，最後一定會迷路。

請在這裡先決定好：是什麼類型、什麼畫面、有哪些 UI、能做哪些操作、遊戲循環是什麼、玩家會得到什麼體驗。
請把它打磨到你閉上眼睛時，能在腦中完整重現遊戲的程度。

也可以先拿去和 Claude 對談。
如果這一步不先決定，規格的模糊性就會在後面的資料設計裡，以「悶棍」的形式慢慢反撲上來。

2. 產生資料設計用的提示詞

資料設計一般來說可分成主資料（Master Data）與 Domain 物件兩種，
不過先按照「主資料 → Domain 物件」的順序來設計，心情會比較輕鬆。

「主資料」是指遊戲執行期間保持不變的資料。
如果以寶可夢來說，就是名稱、種族值、出現的道路等資訊。

「Domain 物件」是指遊戲執行期間所處理的資料物件中，用於商業邏輯的那些。
如果以寶可夢來說，就是「存在、具有狀態、而且會變化的所有東西」。
雖然這個比喻好像也沒很精準，但大致上就是指遊戲執行時狀態會變動的資訊。

主資料

先從主資料的資料表清單開始做。
這次的「冒險者公會經營遊戲」大概會像這樣：

角色
- 角色表
- 冒險者能力值表
- 冒險者外觀表
- 怪物能力值表
- 怪物外觀表
- AI 表
- 等級表
- ...
道具
- 道具表
- 武器表
- 裝備表
- ...
地城
- 樓層表
- 怪物生成表
- 地城生成設定表
- 地城外觀表
- ...

在開始寫程式之前，最好先只保留資料表名稱與欄位名稱，並做到第三正規化。
再讓 ClaudeCode 或 Codex 幫你整理得漂亮一點。

參考 commit（雜訊稍多）

Domain 物件

Domain 物件無法一開始就一次完成，因為遊戲功能會在之後持續增加。

這個階段應該特別注意的是：

Domain 物件的本質是「持有狀態」
只定義遊戲最低限度循環所需的狀態

一開始，若是角色的話，只需要主資料 ID 和座標資訊就夠了。

最後會變成這樣的型態。

角色的名稱、種族是什麼，這類資訊則透過持有主資料的 key 來表現。

在作業間隙做 Docs 化（超重要）

這裡插入 docs 化的話題。這不是工作流程中的某個特定步驟，而是要在步驟 1～6 的整體開發過程中同步進行。

AI 遊戲開發工作流程裡最重要的就是docs 化。
Unity 程式在一般作法下是 1 個檔案對應 1 個類別，
但檔案數一多，AI 就無法在單次 context 中掌握整體，對於讀取介面與類別間關係來說效率很差，而且雜訊很多。

我理解世界上會有人說「實作不就是規格書嗎」，但 AI 每次重連 session 都需要重新讀取，
如果直接從程式碼去反推，不只 token 消耗量大，最重要的是精度會被資訊雜訊掩蓋。

能用自然語言記錄註解與未來構想，也是很重要的一點。

AI 的作業可以說是從 docs 開始，也以 docs 結束

這不只是「這樣做比較好」的程度，而是一定要做。
不過，不需要你親手寫。

先和 AI 來回對談，把想法收斂之後，再請它把內容寫進 docs 即可。

文件的種類

如前所述，ClaudeCode 與 Codex 由於其特性，需要定期重置 session。
如果不重置而持續使用，token 效率會逐漸下降，原本像資深工程師的氣場也會消失，甚至會不太聽從你輸入的提示詞。

就像新進工程師加入專案時一樣，
要先讓它讀文件、
要讓它能快速上手，
因此必須事先準備好文件架構。

在這次驗證開發中，我最後整理出的文件種類如下 4 種。

1. design

放置遊戲規格的資料夾。
想到的內容、未來構想、遊戲系統、功能等全部放在這裡。
主資料與 Domain 物件的設計意圖也會記錄在這裡。

例如：
- 遊戲整體規格
- 戰鬥系統
- 遊戲循環
- 角色可以做的行為
- 道具與金幣系統

2. guidelines

放置遊戲實作規則的資料夾。
可供其他專案沿用的內容放在這裡。

這次的驗證開發，本身就是為了建立與擴充 guidelines，並提升其精準度而製作的遊戲。

例如：
- 程式撰寫規則
- 除錯方法
- 框架的使用方式
- 程式審查指南
- 自我審查提示詞

理想狀況是，之後新做一款遊戲時，只要把這些檔案複製過去即可。

3. roadmap

遊戲實作的路線圖。
roadmap → phase → task 之間是父子關係。
（phase 是把 roadmap 內的作業，以群組方式切分的單位，例如「戰鬥系統」「道具系統」等）
當 guidelines 穩定後，即使把整個 roadmap 單位直接丟給 AI，也能交付品質相當不錯的實作。

後面會提到，這部分也會交給 AI 文件化，再由人類審查。

「請將遊戲開發完成所需的路線圖，建立成 docs/roadmap 底下的 md 檔案」

4. self-review

自我審查的存放處。
會讓 ClaudeCode 與 Codex 各自進行自我審查。
兩者只是性格不同，但都能提出相當適切的指摘，因此會把審查內容合併，再讓它們自己修正，反覆進行。

在思考規格、製作新功能時當然如此，
即使因為自我審查導致結構改變，也務必要寫進 docs 中永久保存。

3. 將資料設計落實到程式碼

（現在回想起來，當初應該把 commit 再切得更細一點。）

將建立好的主資料與 Domain 物件實際落地到程式碼中。

不過如果為了主資料在這個時間點導入 SQLite 或 MasterMemory，成本太高，
而且最重要的是 ClaudeCode 與 Codex 也不會很輕鬆地幫你修改。

這次全部都先用 Dictionary 以硬編碼方式建立。

以道具為例，請先確認它是 immutable。
每個主資料表對應建立一個類別。

主資料

Domain 物件

Prefix/Suffix 補充說明（給會看儲存庫的人）

以下整理 Prefix 與 Suffix 的用途。
（這裡只說我自己是這樣用，不列一般性定義）

~Table
- 表示主資料表的類別
- 最終會變成 SQLite 或 MasterMemory，所以隨著開發進行會被移除
~Master
- 表示主資料的一筆記錄
- 不可變（immutable）的資料類別
- 內容必須與主資料一致
~Spec
- 由主資料組合而成的不可變資料類別
- 本身不持有狀態，但可以加工處理
- 當單一主資料不足以表現時使用
- 例如在生成角色時，根據生成表 ID 去查主資料，取得角色種類、位置、初始武器、裝備等資訊，並以方便使用的形式提供
~Orchestrator
- 可以呼叫多個 UseCase 的 Application 層 UseCase
- 換句話說，~UseCase 只能有單一責務（若超出則需要升格為 Orchestrator）
Advance~
- 定期更新的處理
- 因為 Update 這個詞太多義，所以常用這個
Product~
- 當產品端要覆寫中介軟體等內容時使用的前綴
- 因為直接用專案名稱會讓意圖不清楚，所以統一使用 Product
- 如果沒有這個規則，名字可能會變成 DungeonInnCameraManager 之類，非常慘
其他

4. 製作 Orchestrator/UseCase

接著製作 Orchestrator 與 UseCase。
Orchestrator 就是可以呼叫 UseCase 的 UseCase。

一般而言，常見的做法是「UseCase 可以呼叫其他 UseCase」，
但因為我不喜歡依賴關係像蜘蛛網一樣糾纏在一起，所以把它們分開了。

如果不知道 UseCase 是什麼，請搜尋「Clean Architecture」。

順便附上我一時興起做的「ずんだもん的 Clean Architecture 解說」：
https://github.com/lisearcheleeds/Lighthouse/blob/master/Docs/ja/zundamon/CleanArchitecture.md

簡單來說，「UseCase」就是依照資料操作步驟所建立的類別。

其實到了這個階段，如果 design 文件已經很完整，主資料與 Domain 物件也已經穩定建立，這部分就可以全部交給 AI。

這個步驟只要一句：

「請依照 design 的內容製作 UseCase。」

AI 之所以會開始做出莫名其妙的實作，原因就在於你同時要它處理「資料設計」與「使用這些資料的處理」。
Claude 和 Codex 在既有架構上的修正與擴充能力強到不必多說。

5. roadmap 的製作

接著正式開始依照 roadmap 進行作業。

雖然也可以從資料設計直接定義 roadmap，
但資料設計要調教到 Claude/Codex 能穩定配合，通常要花很多工夫；
在那之前先亂排程，效益也不大。

另外，這套工作流程中建立 roadmap 的 md 檔案，目的是為了「讓 AI 可以直接接手處理」。

請根據 design 中記載的遊戲內容，製作一份能完成實作與收尾的 roadmap，並以 md 檔案形式輸出。
請將 roadmap 依照容易作業且可確認動作的單位切分成檔案。
請在 roadmap 中記載目標與適用範圍。

這樣就足夠了。

如果一開始就在所有 roadmap 裡把每項實作細節都寫得太具體，
等到真的要開始執行該 roadmap 時，反而會變成雜訊。

先只寫抽象層級的計畫即可。

6. 實作 roadmap 的作業

接下來就是反覆進行這份 roadmap 的作業。
不過進行方式很重要。

在開始 roadmap 作業的正前方，先補上該 roadmap 的內容。

Step 1. 記錄功能細節

請詳細分析 roadmap{N} 的內容，並具體記錄需要哪些功能

Step 2. 記錄功能的理想設計

請詳細分析 roadmap{N} 的內容，並在參考實際程式碼的同時補充理想設計。
但不要做任何為了維持相容性而存在的實作或繞路。
所有為理想設計而進行的破壞性修改都可以接受。

Step 3. 實作功能

請實作 roadmap{N} 的內容

重點是在實作之前插入這兩個步驟。

Step 1 是因為在前面的作業中，專案狀態可能已經改變，或方針可能有所調整，因此要在這個時間點看過程式碼後，將具體作業方針寫進 roadmap。

Step 2 則是為了抑制 ClaudeCode 或 Codex 為了趕快完成功能，而做出偷工減料的實作。

AI 特別容易寫出「雖然可以動，但這樣的實作真的沒問題嗎？」的程式碼，
原因就在於它們的設計目標是「讓它動起來」。

資深工程師能在寫程式的同時，一邊組出理想設計；
但 AI 就像 NavMesh 一樣，如果不先幫它鋪好路徑，它就會一直撞牆。

這點非常重要，請直接複製使用。

那麼，結論是否達到了商用級別的程式品質？

結論是，確實做出了具有足夠程式品質的遊戲。

雖然離完美設計、完美實作還差得很遠，
但已經能維持容易增加內容、具備高延展性的遊戲設計。

以我的經驗來說，若放在實際遊戲開發現場，大概是偏差值 55 左右的程式品質。

作業時間大致是 GW（4/29～5/6）的連假 + 週六或週日 + 平日晚上 1～2 小時，約 10 個人日左右，我認為已經是相當不錯的成果。

副產物總結

Codex + 叫被動編碼用的 AGENTS.md

程式編寫規則

Domain 設計指南

其他

感想與教訓

在遊戲開發中，不需要一開始就要求 AI 達到 100 分
- 擅長設計的人就負責設計，擅長實作的人就負責實作，只要各自拿到 50 分 + 50 分即可
- 也就是所謂的 divide and conquer 🍆
開發過程中，只要發現有需要改善的行為，就持續追加到 guidelines
定期（每個里程碑）進行自我審查
不只要做 EditModeTest / PlayModeTest，也要實際執行起來測試
- 感謝 UnityCLILoop 幫忙實作