AI 寫程式怎麼評？用三款頂級AI模型（Gemini 4/Claude/ChatGPT） 寫3D 遊戲實測教學

「幫我做一個 3D 小遊戲。」同一句話交給不同 AI，常常每一套都交出看起來很厲害的畫面。但真的玩下去，角色會不會穿牆？按下重新開始，東西有沒有全部重設？這些才是阿正老師這次想弄清楚的事。

這次阿正老師先請 ChatGPT（Codex）設計測試題，再交由 Claude 審題，帶回意見後由 ChatGPT（Codex）再評估並定稿。開發時使用的是GPT-6 Astra、Opus 5.5與Gemini 4 Argon等三套頂級AI模型。GPT、Claude、Gemini 三份同題作品的瀏覽器實測、邏輯測試與評分，也由同一個 ChatGPT（Codex）對話執行，最後補測一開始無法確認的項目。本文把這段過程整理成教學，你也能拿同一套方法比較 AI 做的網站、小工具或遊戲。

先說結果：三套遊戲都確實收齊五顆核心並成功通關；本次作品最後得到 GPT 100 分、Claude 95 分、Gemini 90 分。不過，這是這三份作品的驗收結果，不能直接推論成所有程式任務的模型排名。

一、先把「做得好」寫成可檢查的條件

如果你只要求「好玩、漂亮、順暢」，各家 AI 很容易各做各的，最後很難公平比較。阿正老師這次選的是「能量核心逃脫」：用 WASD 移動、空白鍵跳躍，在九十秒內收集五顆核心，再走到出口。

這個題目不大，卻能一次檢查幾件事：障礙物有沒有碰撞、平台能不能跳上去、碰到敵人會不會扣血、出口是否真的等到集滿才開啟。再加上暫停與重開，就能看出程式有沒有把前後狀態處理完整。

二、請另一套 AI 審題，補掉容易漏的細節

Claude 審題補充：第一版由 ChatGPT（Codex）提出功能與評分方向；Claude 審過之後，補上了單一 HTML 檔案、指定 Three.js 版本、固定敵人路線，以及讓測試工具讀取遊戲狀態的介面。這裡審的是測試題目，不是宣稱 Claude 已經審過三份程式或這篇文章。

ChatGPT（Codex）再評估補充：阿正老師把 Claude 的修改版帶回同一個對話，再檢查出下表五項「文字看起來很嚴謹，實際卻可能誤判」的地方：

如果你也想請另一套 AI 審題，可以先貼上自己的需求，再加上這段：

請審查這份測試題，不要先寫遊戲。
找出模糊、互相衝突、難以驗收或可能被表面功能蒙混的要求。
請把每個問題改成可以操作檢查的條件，並解釋修改原因。
保留題目規模，避免為了嚴謹而把它改成大型專案。

三、把定稿提示詞交給不同 AI

題目定稿後，再交給不同 AI 各自製作。可複製的排版整理版放在本文附錄，也預留 純文字提示詞檔；附件上傳前，可先複製附錄內容。一般讀者不必先看懂裡面每個工程名詞；那些細節是交給 AI 執行、方便後續驗收用的。

如果要自己重做比較，請固定同一份提示詞、相同工具權限與修改次數。第一版和修正後版本分開記錄；能操作瀏覽器的 AI 與只能輸出文字的 AI，也要註明差別。

這次保留了交付檔案與測試紀錄，但沒有完整還原各 AI 當時的生成過程、全部工具權限及修改輪數，因此本文評的是實際收到的作品，沒有拿生成速度或成本評比。

收到 index.html 後怎麼開？

如果使用的 AI 工具有網頁預覽，先照它的方式開啟。若你已安裝 Python，也可以把檔案放在獨立資料夾，在該資料夾開啟終端機並執行：

python -m http.server 8000 --bind 127.0.0.1

再用瀏覽器開啟 http://127.0.0.1:8000/。完成後回到終端機按 Ctrl+C 結束。這是本機預覽，不是把遊戲公開上網；若電腦找不到 python 指令，先使用 AI 工具的預覽，或請它協助確認 Python 環境。命令用法可參考 Python 官方文件。

本次遊戲仍會從網路載入 Three.js，所以不是離線遊戲；「只交一個檔案」也不等於完全不需要網路。

下圖為阿正老師使用VS Code，搭配Claude、Codex與Antigravity擴充套件來同時開發遊戲的畫面：

四、不會寫程式，也能做的驗收

阿正老師建議先花五分鐘初篩，照下面順序操作。五分鐘是找明顯問題，不是宣稱完成全部驗收；測完勝敗、重開與補測，還需要更多時間。

發現問題時，記下「從哪個畫面開始、按了什麼、原本應該怎樣、實際變成怎樣」。例如「浮空平台下看不到角色」，就比「鏡頭很爛」更容易讓 AI 修正。

這次驗收也有遇到工具限制：第一輪無法確認真實繪圖資源與小視窗效果，所以先保留五分。後來再用本機 Chrome 自動操作補測，確定數字與畫面都正常，才把這五分加回去。沒有量到的項目，先寫待驗，別讓 AI 用一句『應該沒問題』代替證據。

五、本次評測結果：三套都能玩，差在細節

以下是一般讀者版的簡化評測，日期為 2026 年 10 月 23 日。三份遊戲都正常通關，差距主要在鏡頭可視性與暫停後的輸入處理。

評分者 ChatGPT（Codex）與得到 100 分的 GPT 作品同屬 OpenAI 系列，讀者解讀分數時要知道這一點。本次不是獨立或匿名評測；扣分項目有重現步驟與原始資料，但留下證據不代表已消除評測偏誤。

手機閱讀時，可左右滑動下表查看完整分項。

本次沿用原定配分，每一小項採完整通過、部分通過、未通過的方式評分。GPT 的 100 分代表這次評分表內的受測項目取得滿分，不是保證程式永遠不出錯。費用、生成速度、模型整體能力與長期維護，都不在這張表的範圍內。

GPT 作品：這次的狀態管理較完整

GPT 作品能收集全部核心並完成逃脫；鏡頭遇到遮擋時會調整距離，暫停與重開的處理也較完整。本輪已驗證的項目，沒有發現確定需要扣分的缺陷。開啟 GPT 遊戲試玩。

Claude 作品：平台能完成，但走到下面會被擋住

Claude 做出一段由低台、浮空台到高塔的路線，確實能正常跳上去、收齊核心。不過走進浮空台下方時，平台會遮住角色，影響判讀位置。本次在「移動與鏡頭」項目部分通過，因此總分是 95 分。開啟 Claude 遊戲試玩。

Gemini 作品：能通關，出生鏡頭和恢復輸入仍有問題

Gemini 同樣能通關，但一開始玩家會被南側牆面擋住。另一個問題是在按鍵事件的邏輯測試中，暫停恢復後，仍按住的方向鍵可能因鍵盤重複事件再次啟動移動；這一項是程式邏輯測試確認，沒有宣稱已用真人持鍵操作重現。兩個項目各扣五分，最後得到 90 分。開啟 Gemini 遊戲試玩。

以上三張截圖是由自動化瀏覽器（Playwright）在本機 Chrome 擷取的真實畫面，非 AI 生成圖。

三套都通過的補測

補測使用本機 Chrome 與 RTX 5070，將相同版本的遊戲副本先預熱，再重開十次。三套的繪圖資源數量都沒有增加；視窗縮成 800×600、再回到 1280×720，選單、狀態列與受測按鈕也都能正常使用。

三份作品的原始標示分別為「GPT-6 Astra／推理：高」、「Claude Opus 5.5／推理：高」、「Gemini 4／推理：高」。這裡沿用交付標示，沒有額外驗證後端模型身分；因此正文用「GPT／Claude／Gemini 作品」稱呼。截圖與分數對應本次存檔版本，試玩網址日後可能更新。

六、遇到問題，這樣請 AI 修正

第一輪看的是交付能力；把具體問題貼回去，才看得到除錯能力。阿正老師會建議一次整理好同輪發現的問題，讓 AI 修完後，再重測受影響的功能。

以下是我實際發現的問題：
1. 重現步驟：［從什麼畫面開始，依序做了哪些操作］
2. 預期結果：［應該發生什麼］
3. 實際結果：［實際發生什麼，可附截圖］

請先解釋可能原因，再修正並交付完整 index.html。
保留原本已完成的功能，列出改了什麼與需要重新測試的地方。
請分開列出實際執行的測試與尚未驗證的項目。

如果它修好鏡頭，卻讓平台不能跳，這次修正就還沒完成。同樣地，重新開始後不再加速，也要確認生命、核心和敵人位置沒有漏掉。

七、附錄：完整提示詞與簡化報告

想直接做同題比較，可以複製以下提示詞。本版為排版整理，規格內容與交給三套 AI 的定稿相同。想快速分享這次結果，也預留 簡化評測報告（含三款截圖）。報告把測試重點、分數與限制放在同一頁，不需要先讀懂程式碼。

你是一位遊戲工程師。請製作一款可在桌面瀏覽器玩的 3D 小遊戲：「能量核心逃脫」。

目標是交付完整、可玩、狀態正確且方便驗收的遊戲。

【交付方式】
1. 程式只交付單一 index.html，CSS 與自行撰寫的 JavaScript 全部內嵌。請完整輸出檔案內容，不得省略。
2. 使用 Three.js 0.160.0，透過 importmap 從以下 jsDelivr 網址載入：
https://cdn.jsdelivr.net/npm/three@0.160.0/build/three.module.js
3. 除上述 Three.js 外，不使用其他外部函式庫或資源。場景只用幾何圖形與程式產生的材質，不使用外部圖片、模型、字型或音效。
4. 不需要建置、後端、帳號或付費服務。在檔案所在資料夾執行 python -m http.server，再以瀏覽器開啟 http://localhost:8000 即可遊玩。載入 CDN 需要網路。
5. 不得用 TODO、假按鈕、「其餘類推」或示意程式代替功能。
6. 程式碼後可附簡短交付說明，但不得要求另外建立程式檔案。

【遊戲內容】
1. 場景約 40×40 單位，包含地面與四周邊界、至少 6 個障礙物（不含邊界與平台）、至少 2 個高度不同的平台。
2. WASD 移動、空白鍵跳躍、P 或 Esc 切換暫停／繼續。滑鼠拖曳可水平旋轉第三人稱跟隨鏡頭。畫面須顯示操作說明。
3. W 朝鏡頭觀看方向在水平面的投影前進，S 反向，A／D 向左右移動。斜向移動速度須與直向一致。
4. 場上共有 5 顆能量核心，每顆只能收集一次。至少 1 顆必須跳上平台才能取得。收集判定須包含垂直距離，不能站在平台下方隔空收取。
5. 有 2 個敵人沿固定路線巡邏。玩家初始有 3 點生命，每次有效碰撞扣 1 點。
6. 受傷後有 1.5 秒無敵時間，以遊戲時間計算。無敵期間角色須閃爍或變色；持續接觸不得瞬間扣光生命。
7. 收集完全部核心前，出口須呈現鎖定外觀，且不能觸發勝利。收集完成後，出口變色開啟；玩家到達出口即勝利。
8. 開始遊戲後倒數 90 秒。生命歸零或倒數歸零即失敗。
9. HUD 顯示生命、已收集核心數（x/5）及剩餘秒數。
10. 提供開始畫面、暫停／繼續、重新開始，以及勝利與失敗畫面。選單期間不得開始倒數。勝敗後停止遊戲模擬，直到玩家重新開始。

【關卡與操作正確性】
1. 所有核心與出口均須能由出生點正常抵達。平台高度與間距須配合角色跳躍能力。
2. 角色不能穿過障礙物或邊界、掉穿地面，並須能站在平台上及正常離開平台。
3. 不得在空中連跳。跳躍由新的按鍵按下動作觸發，按住空白鍵不得落地後自動連跳。
4. 暫停、視窗失焦與重新開始時，清除按鍵及滑鼠拖曳狀態。恢復後，未重新按鍵不得自行移動。
5. 暫停快捷鍵須忽略鍵盤自動重複事件，避免按住按鍵時連續切換狀態。
6. 地圖配置、核心位置、出生位置與敵人巡邏起始狀態須固定。每次重新開始應得到相同的初始關卡。

【時間與狀態管理】
1. 移動、敵人、跳躍、無敵時間與倒數須依經過時間更新。可使用 delta time，或以累積時間驅動固定步長模擬。不得用畫面幀數直接決定遊戲速度。
2. 在約 30 FPS 與 60 FPS 下，移動速度、跳躍高度及倒數速度應大致一致。可使用碰撞子步進等方式避免低幀率穿透。
3. 暫停時，玩家、敵人、倒數與無敵時間全部停止。可以繼續繪製畫面，但不能推進遊戲狀態。
4. 切換到其他分頁或視窗失焦時，若原本正在遊玩，應自動進入暫停。回來後必須由玩家手動繼續。不得把選單或勝敗畫面切換成遊玩狀態。
5. 恢復時須重設時間基準，不得補算暫停期間時間、突然扣血或造成瞬移。
6. 重新開始須重設玩家位置與速度、鏡頭、敵人位置與巡邏進度、核心、生命、無敵狀態、倒數、出口及勝敗狀態。按下重新開始後直接進入 playing。

【工程要求】
1. 重新開始不得累積動畫更新鏈、事件監聽或場景物件。
2. 自行撰寫的每幀更新程式應重用暫存物件，避免反覆建立 geometry、material 與不必要的 Vector3。getState() 建立測試快照不在此限。
3. 若重建資源，須妥善處理不再使用的資源；也可重用原本場景物件。
4. 重開 10 次後，在相同遊戲階段與視角下比較，場景物件及渲染資源數量不應隨重開次數持續成長。
5. 視窗縮放後須更新畫面比例，HUD、操作說明與按鈕不得被裁切或無法操作。
6. 結構清楚、有必要註解，不追求過度架構。

【測試介面】
請在全域暴露 window.__game，至少包含：
1. renderer：實際使用的 Three.js renderer，可讀取 renderer.info。
2. getState()：回傳獨立的狀態快照，格式固定為：
{ phase, hp, cores, timeLeft, playerPos: { x, y, z } }
phase 為 'menu' | 'playing' | 'paused' | 'won' | 'lost'。
hp 為 0～3 的整數；cores 為已收集數量（0～5 的整數）；timeLeft 為非負的剩餘遊戲秒數，可含小數；playerPos 為有效的玩家世界座標。
修改回傳資料不得影響遊戲內部狀態。此介面僅用於觀測，不得改變正常遊戲規則。
3. loopCount：由實際動畫迴圈啟停邏輯維護的有效動畫更新鏈數量，不得以固定常數代替。遊玩時應為 1，其他階段可以是 0 或 1，但不得因重開而增加。此數值只是輔助診斷，不能代替實際驗證。

【完成後請簡短列出】
1. 啟動方法。
2. 已實作功能與已知限制。
3. 取得平台核心的操作路線。
4. 你實際執行過的測試、測試環境與結果。
5. 尚未實際驗證的項目。
若無法執行瀏覽器，請直接說明。不要把閱讀程式、推測能運作或預期結果寫成實測通過。
  

延伸閱讀：想找更多 AI 遊戲與提示詞案例，可看 本站的 AI 遊戲與互動網站介紹；想了解不同評測各在比什麼，可看 AI 模型排行榜整理。這篇的做法，則是把題目換成你自己真的會用到的需求。