Godot 4.7：把 AI 生成的遊戲原型，收斂成可驗證的跨平台產品

Godot 4.7：把 AI 生成的遊戲原型，收斂成可驗證的跨平台產品

如果把 AI coding agent 當成「快速產生想法與程式碼的合作者」，我不會讓它直接決定遊戲專案的最後形狀。真正需要一個穩定邊界的地方，是場景如何組合、輸入如何處理、資產如何匯出，以及每次修改能不能被重現。

這也是我這次選 Godot 的原因。godotengine/godot 是一個 MIT 授權的開源 2D 與 3D 遊戲引擎，官方 README 明確把跨平台編輯、遊戲製作與匯出放在同一套工作流裡。GitHub API 在 2026 年 8 月 26 日查到它有 116,156 顆星、最近一次推送在 2026 年 8 月 25 日；4.7.2-stable 也在 8 月 18 日發布。它不是因為「有 AI」才值得看，而是因為它能把 AI 產出的原型拉回一個可執行、可測試、可交付的工程環境。

我先把問題拆成兩層

我會把 AI 與 Godot 的責任切開：

1. AI 負責探索：把模糊想法整理成玩法規格、場景樹、輸入映射、測試案例與小段程式碼。
2. Godot 負責收斂：用場景、節點、資源、訊號與匯出設定，讓這些結果成為能執行的專案。

這個切法很重要。AI 很適合一次提出五種角色控制方式，卻不適合在沒有邊界的情況下替你決定整個專案的狀態管理。Godot 的專案檔、場景檔與 GDScript 則提供了可以檢視的中間產物，讓我能逐項接受或拒絕修改。

為什麼 Godot 適合作為原型的收斂層

1. 場景是可檢查的組合單位

Godot 不只是一個畫面編輯器。場景可以由節點組合而成，再被實例化到其他場景。對 AI 輔助開發來說，這代表我可以把需求拆成「玩家場景」「敵人場景」「關卡場景」與「UI 場景」，要求 agent 一次只修改一個邊界，而不是讓它在整個程式庫裡自由搜尋並重寫。

2. GDScript 讓小步驗證成本很低

一個玩家控制器可以先保持非常小，先驗證輸入、速度與碰撞，再逐步加入動畫、特效與遊戲狀態。例如下面這段程式碼只處理移動，不把攝影機、音效或分數系統混進來：

extends CharacterBody2D

@export var speed := 220.0

func _physics_process(_delta):
    var direction := Input.get_vector(
        "ui_left", "ui_right", "ui_up", "ui_down"
    )
    velocity = direction * speed
    move_and_slide()

這種小單位很適合交給 AI 產生初稿，但驗收仍然由人與引擎共同完成：輸入動起來了嗎？碰撞是否符合預期？斜向移動有沒有不合理的速度？如果答案不清楚，就先不要繼續加功能。

3. 匯出是工作流的一部分，而不是最後才處理的事情

Godot 官方文件提供編輯器與命令列工作方式。對我來說，最實用的做法是把「可以開啟專案」與「可以產生目標平台建置檔」都放進驗證清單：

godot --headless --path . --editor --quit
godot --headless --path . --export-release "Linux/X11" build/game.x86_64

第一行用來提早發現專案、資源或腳本的載入問題；第二行則把匯出預設與輸出路徑明確寫出來。實際使用時，Linux/X11 必須替換成專案中已設定的 Export Preset，並在 CI runner 安裝相對應的 export templates。重點不是背下某一個平台名稱，而是讓「匯出成功」成為可重複執行的檢查。

我會怎麼安排一個 AI 輔助的 Godot 專案

一開始我不會讓 agent 直接說「做一款完整遊戲」。我會先建立一個可以在一天內驗證的垂直切片：一個場景、一個玩家、一個互動目標、一個成功條件。

專案結構可以先維持簡單：

project.godot
scenes/
  main.tscn
  player.tscn
scripts/
  player.gd
  game_state.gd
assets/
  placeholder.svg
build/

接著把任務分成幾個可回滾的步驟：

1. 規格：請 AI 將玩法寫成輸入、狀態轉移與完成條件，不先寫程式。
2. 場景：建立最小節點樹，確認每個腳本只掛在必要的節點上。
3. 行為：每次只加入一個可觀察行為，例如移動或撿取物件。
4. 驗證：用手動測試與 headless 匯入檢查，排除拼字、路徑與資源引用錯誤。
5. 匯出：在功能完成前就跑一次目標平台匯出，避免最後才發現模板或平台設定缺失。

我會給 coding agent 類似這樣的請求：

只修改 scripts/player.gd。使用 Godot 4 的 CharacterBody2D，加入四向輸入與可調速度。不要新增外部套件，不要改動場景樹。先列出你假設的 Input Map，再提供一個可以人工驗證的測試清單。

這種提示詞看起來比「幫我做角色控制」更慢，實際上反而更快，因為它把變更範圍、版本、禁止事項與驗收方式一次寫清楚。AI 產出不符合時，我可以直接退回這一個小步驟，不必從整個專案重新找差異。

我最在意的三個驗收點

資產與程式碼是否可追蹤

原型階段可以用 placeholder，但每個資產都要知道來源與授權。Godot 本身採 MIT 授權，不代表你匯入的字型、音效、圖片或模型也自動採用相同授權。AI 如果提出一個外部資產網址，我會要求它把來源、授權與放置路徑列成檢查表，而不是直接下載進專案。

場景與腳本是否有清楚邊界

當所有邏輯都塞進 main.gd，AI 之後很容易一次改壞整個遊戲。把玩家、關卡、UI 與遊戲狀態分開，並讓訊號承擔必要的事件通知，通常比「先做出來再整理」更省時間。可讀的場景樹也是一種文件，能幫人和 agent 都快速理解目前的系統。

匯出結果是否真的能執行

「編輯器裡看得到」與「交付檔案能啟動」是兩件事。我要在每次重要變更後至少跑一次 headless 檢查，並在接近里程碑時產出實際平台建置檔。若專案將來要支援 Web、桌面與行動平台，也應該把每個 Export Preset 的差異記錄在版本庫，而不是只存在某一台開發機的設定裡。

Godot 不會替你解決的事

我不會把 Godot 包裝成 AI 遊戲開發的捷徑。它解決的是引擎層的組合、執行與匯出；它不會自動替你判斷玩法是否有趣，也不會保證 AI 產生的程式碼沒有狀態漏洞。

因此我會保留三條底線：

• AI 只能提出變更，不能跳過測試與人工審查。
• 任何新增資產都必須有來源與授權紀錄。
• 每個垂直切片都要能在乾淨環境重新匯入與建置。

我的結論

高星數本身不是選擇 Godot 的理由。真正值得寫進 AI Chain 工程工作流的，是它提供了一個清楚的收斂面：AI 可以快速探索，Godot 則把探索結果變成節點、場景、腳本與可匯出的產品。

如果你正在用 AI 做遊戲原型，我建議不要先追求更多生成內容，而是先建立一條短而可靠的閉環：規格、最小場景、單一行為、可重複驗證、實際匯出。當這條閉環穩定之後，再把 AI 放進資產生成、關卡草稿或測試案例擴充，速度才不會以不可控的維護成本為代價。

參考資料

• Godot Engine GitHub repository
• Godot 4.7.2-stable release
• Godot 官方功能介紹
• Godot 官方命令列教學
• Godot 官方專案匯出文件
• CharacterBody2D 類別參考