2026年9月23日 下午 8:06
AI 設計AI × GAME DEV · 2026
QUICK ANSWER
用 GPT-6 Astra 做 3D 動作 RPG，先把工作分清楚：Astra 搭 Codex 負責讀專案、改程式、跑測試；Three.js 負責瀏覽器裡的場景與戰鬥；Blender 負責角色模型。真正決定成品的，是你能不能把畫面想像寫成可驗收的規格：小怪 → 首領 → 勝敗 → 重開，每完成一段就實測，再依結果修下一個最小的問題。
打開瀏覽器，走進被森林吞噬的聖殿。石橋下有溪流，破碎拱廊間透著月光，主角揮出發亮的劍弧，清掉幾隻守衛後，一名巨型鹿角騎士踏進戰場。
這樣的 3D 動作 RPG，可以從 Three.js 和 AI 程式代理開始做。上一篇我用 ChatGPT 和 Codex 做了台北機車競速遊戲《歐兜賣尬車》，這篇把模型換成 GPT-6 Astra，題材換成暗黑奇幻，帶你完成一個「小怪 → 首領 → 勝敗 → 重新開始」的短篇動作遊戲。你會拿到可以直接使用的提示詞，知道每個階段該看什麼，也知道角色不像、技能方向錯誤、畫面卡頓時該怎麼處理。
先講清楚：這是一套製作方法和驗收方法，貼上一段程式碼就得到完整遊戲的套件並不存在。第一個合理的目標，是做出一段完整、好玩、美術一致的關卡，再逐步往上疊品質。
CHAPTER 01 · WHO DOES WHAT
GPT-6 Astra 是模型，能理解需求、分析圖片、寫程式並規劃修改。OpenAI 把它定位在複雜推理、程式開發和需要多步驟處理的工作，發布重點我在〈一次看懂 GPT‑6 Astra〉整理過。Codex 則是讓模型參與開發工作的工具環境：在授權範圍內讀取專案、修改檔案、執行指令、檢查結果，實際能做多少，取決於你用的介面、裝了哪些工具和給了什麼權限。
Three.js 負責在瀏覽器顯示 3D 場景，但移動、攻擊、敵人行為、介面和勝敗流程仍然要寫成程式。Blender 負責角色、場景模型、材質、骨架和動畫。在這個範例裡，Astra 參與的是「製作遊戲」這件事；做完之後，角色移動與攻擊都由遊戲程式自己執行，玩家按技能鍵時並不會向模型送出請求。
TOOLKIT · 每個角色交出什麼、你要檢查什麼
GPT-6 ASTRA ＋ CODEX
分析需求、修改程式、協助測試與修正
你要看的是實際檔案、執行結果和修改差異
THREE.JS
場景、鏡頭、模型顯示、光影與特效
你要看的是瀏覽器裡的實際畫面
BLENDER
角色與場景模型、骨架、動畫、匯出
你要看的是可編輯模型和它在遊戲裡的表現
圖像生成工具
設計稿、貼圖草稿、宣傳封面
你要看的是可用素材和它的來源紀錄
你自己
決定風格、手感與取捨
你要回答的是：真的好玩、好看、可交付嗎
圖像生成與 3D 建模是兩件事。一張漂亮的角色設定圖提供視覺方向，還得經過模型、材質、動畫和匯出流程，才能進到遊戲裡。
CHAPTER 02 · GETTING STARTED
NOTE
這篇的介面與模型選項，是依 2026 年 9 月 24 日核對的官方文件寫的。實際看到什麼，以你使用當下的文件和帳號顯示為準。
依官方快速入門安裝桌面應用程式、登入，開啟專案資料夾；要做軟體開發就選 Codex。如果你看到的是整合版 ChatGPT 桌面介面，從下拉選單切到 Codex 即可。第一次用 Codex 可以先看〈Codex 是什麼？〉。
接著在輸入區下方的模型控制項選 GPT-6 Astra，並設定可用的推理強度。模型能不能選，仍受帳號、版本和工作環境影響。第一次使用，先建一個空的 forest-rpg 資料夾交給 Codex 開啟，再輸入：
PROMPT · 01 開工前的環境確認
請先檢查這個專案資料夾及可用的開發工具。
我要用 Three.js 製作一款可在瀏覽器直接遊玩的單人動作 RPG。
請確認能否建立檔案、執行開發伺服器及進行瀏覽器測試。
若本機有 Blender，確認能否透過可用工具執行建模腳本。
只回報實際確認的能力，不要把尚未安裝或未授權的工具當成可用。
接著建立最小專案，讓我能在瀏覽器看到場景與可移動角色。
如果沒有提供瀏覽器或 Blender 操作工具，Astra 仍然可以幫你寫程式和腳本，但執行、截圖、把結果交回來這幾件事就落在你身上。先確認這件事，才不會把「模型說可以」誤認成「已經操作完成」。
官方說明指出，提高推理強度可能有助於複雜工作，但會增加時間與用量。以下是我建議的使用分配，它是工作方法，不是效能保證：
REASONING · 推理強度分配建議
如果眼睛的位置畫錯，提高推理強度可能有幫助，但更有效的資訊是：「眼睛太靠外，請把正面參考與模型放在相同大小比較。」需要大量日常修改時，也可以把便宜的 Sol 或 Luna 排進來分工，怎麼派我在〈GPT-6 三個模型怎麼選？〉寫過。
完成 Codex CLI 安裝與登入後，進入專案資料夾啟動：
CLI · 啟動指令
codex -m gpt-6-astra
工作中可用 /model 調整模型與推理強度、/status 查看設定、/review 檢查程式修改。這些是 Codex 的操作指令，跟遊戲本身的程式碼無關。
▲ OpenAI 官方影片〈Figma Gave GPT-6 Astra a Moonshot〉：Figma 團隊把一個大型任務交給 GPT-6 Astra 的第一手紀錄，看它怎麼處理長時間、多步驟的工作
CHAPTER 03 · THE SPEC
「畫面要像 AAA」能傳達企圖心，但指導不了開發。比較有效的做法，是先定義一段能完成的遊戲：
SCOPE · 第一版的範圍
✦ 一張森林聖殿地圖，採斜俯視跟隨鏡頭
✦ 一位原創角色，具備移動、普攻、翻滾、格擋和補血
✦ Q、W、E、R 都是攻擊技能，各有用途與節奏
✦ 擊敗 6 名守衛後，直接出現一名首領
✦ 有生命、魔力、冷卻、首領血條、勝敗及重開介面
— 第一版不加入接任務、守城、多人連線或大型開放世界
這樣的範圍，讓每次修改都有清楚的目的。玩家能走完完整流程後，再投入角色細節、材質與光影，投入的美術才有地方發揮。
PROMPT · 02 第一段正式製作提示詞
請在這個專案裡，用 Three.js 製作可玩的 3D 單人動作 RPG。
核心流程：進場 → 擊敗 6 名守衛 → 首領登場 → 勝利或失敗 → 重新開始。
不需要接任務、守城或建造系統。
美術方向：森林吞噬的哥德式聖殿、破碎高塔、拱廊、苔蘚石橋、
溪流瀑布與營火。主角先用簡單模型，之後替換原創角色。
操作：方向鍵或滑鼠右鍵移動，左鍵普攻，空白鍵翻滾，Shift 格擋，
數字 1 補血。QWER 全部保留給攻擊技能。
請依序完成：
1. 可執行的場景、鏡頭與移動。
2. 普攻、受傷、死亡及重開。
3. 小怪、首領與完整關卡流程。
4. 四個攻擊技能與繁體中文 HUD。
5. 美術、音效及效能調整。
每完成一段都啟動驗證，再繼續下一段。
攻擊動畫、特效和命中判定必須使用一致的朝向。
結束時提供啟動方法、實際測試結果及尚未完成的項目。
QWER 與 WASD 都會用到 W，這種衝突要在規格階段解決。想保留四個技能鍵，就改用方向鍵、滑鼠點地，或另外設計可重設的按鍵配置。
CHAPTER 04 · THE PROJECT
新手可以讓 Codex 建立 Vite 的 JavaScript 專案，再加入 Three.js。Vite 提供開發伺服器與正式建置流程，適合這類瀏覽器專案。想自己建，以下是起點，請先裝好符合當前 Vite 要求的 Node.js：
TERMINAL · 建立專案
npm create vite@latest forest-rpg -- --template vanilla
cd forest-rpg
npm install
npm install three
npm run dev
這些指令只建立開發環境，遊戲內容仍要由後續實作補上。保留鎖定依賴版本的檔案，其他人才能重建相同環境。隨著內容增加，可以要求 Astra 把職責拆開：
FOLDER · 建議結構
src/
main.js 場景啟動、載入與遊戲迴圈
player.js 移動、朝向、角色狀態
combat.js 攻擊、命中與傷害
skills.js 技能資料及施放流程
enemies.js 守衛與首領行為
world.js 地形、建築、燈光與碰撞
effects.js 劍弧、法陣、雷電與粒子
ui.js HUD、暫停、勝敗與重開
public/assets/ 模型、貼圖與聲音
tests/ 戰鬥及流程檢查
不必第一天就建出所有檔案。當「改技能時容易弄壞介面」或「世界檔案裡混了角色傷害」時，就是拆分職責的時機。
另外建一份精簡的 AGENTS.md，保存不該每次重講的規則。OpenAI 對 Astra 的提示設計建議，也強調要重新整理冗長、重疊或互相衝突的指令。
AGENTS.MD · 專案規則
本專案使用繁體中文介面。
玩法維持小怪後直接打首領，不新增任務或守城系統。
QWER 皆為攻擊技能；移動按鍵不得與技能衝突。
修改前先讀取現有實作，避免建立重複系統。
新技能必須同步處理動畫、命中、消耗、冷卻與介面。
測試不得覆寫玩家正式存檔。
回報時分清楚已實測、僅靜態檢查及尚未驗證的部分。
CHAPTER 05 · GAME FEEL
第一版可以用膠囊或簡單人形。此時要確認：移動速度舒不舒服、鏡頭跟不跟得上、角色會不會卡進牆壁、按下攻擊有沒有立即回應。
斜俯視鏡頭可以從偏離正上方約 35～50 度的視角開始試。鏡頭跟隨要有一點緩動，但不能拖到玩家已經轉向、鏡頭還在另一邊。狹窄拱廊擋住主角時，可以淡化遮擋物、抬高鏡頭，或直接調整關卡幾何。
把輸入、遊戲狀態更新和畫面繪製分開。移動量要依時間計算，否則不同幀率會跑出不同速度；切回分頁時，也要避免一次套用過大的時間差。較完整的版本可以用固定時間步長更新戰鬥與碰撞，再獨立繪製畫面。
PROMPT · 03 只修手感
先只改善移動、鏡頭與普攻手感。
使用簡單模型，在有牆、有轉角、有高低差的測試區操作。
檢查不同幀率下的移動速度、鏡頭遮擋、斜向移動及視窗失焦後的按鍵狀態。
請保留目前可玩的版本，完成後列出具體修正與實測方式。
CHAPTER 06 · CHARACTER
把參考圖丟給 AI、再要求「做得一模一樣」，常常得到配色接近、五官卻不對的角色。原因是角色辨識不只靠衣服顏色，還包括頭身比、臉型、眼距、髮束形狀和側面輪廓。
比較穩定的做法，是提供一組可以公開使用的原創設定：正面、側面、背面，加上少量表情。每張圖都說明用途，例如「正面用來判斷臉型，側面用來確認額頭與下巴」。在 Blender 製作時，把檢查順序分成四層：
CHECK ORDER · 角色四層檢查順序
01
輪廓
頭身比例、頭部寬度、髮型剪影、衣服外形。
02
五官
眼睛大小與位置、嘴巴高度、臉頰曲線。
03
服裝
領口、袖口、腰帶、鞋子及重要配件。
04
表面
材質粗糙度、髮絲層次、布料與金屬細節。
前兩層還沒接近參考時，增加髮絲數量通常救不了相似度。先做一個頭部展示頁，提供正面、左右側面和三分之四角度；用固定焦距、固定燈光比較，才分得出差異來自模型還是鏡頭。
PROMPT · 04 角色修正
請先製作獨立的頭部檢視場景，暫時不要修改戰鬥或地圖。
以附件中的原創設定圖為依據，先校正輪廓與五官比例。
目前問題：臉太長、眼睛太靠外、側面後腦勺太扁。
請保留已確認的配色與辨識特徵，只修改這三項。
輸出相同角度、相同尺寸與相同燈光的修改前後比較。
確認正面、側面與三分之四角度後，再接回完整角色。
本機工具允許的話，Codex 可以幫忙寫 Blender Python 腳本；成品質感仍然要反覆看渲染和遊戲畫面。腳本能重建模型，免除不了美術判斷。Astra 在 Blender 裡從零建模的實際流程，我在〈不會 Blender 也能建 3D？〉拆過。
要匯入 Three.js，用 GLB 格式、由 GLTFLoader 載入。Blender 的 glTF 匯出支援物件變換、骨架蒙皮和形態鍵等動畫資料，匯出選項依你使用的版本查閱。匯出後一定要重新檢查比例、朝向、透明材質和動畫：Blender 裡看起來正常，進了瀏覽器不一定相同。也要分清楚「轉動分開的手臂物件」和「具有權重的完整骨架蒙皮」，前者適合原型，後者更適合需要自然彎曲的角色。
CHAPTER 07 · COMBAT
動作遊戲最容易毀掉手感的問題，是劍向右揮、敵人卻在左邊受傷；或特效看起來很大，命中範圍卻完全對不上。
每次攻擊都應該記錄一份施放資料：起點、方向、開始時間、命中時間、作用範圍，以及已命中的敵人。角色動作、劍弧和傷害判定都讀同一份資料。例如，專案若約定角色正前方為本地座標 +Z，可以把開始攻擊時的朝向記錄成 attackYaw。以下只示範平面扇形判定，沒有包含牆壁阻擋、敵人碰撞體或完整戰鬥邏輯：
CODE · 平面扇形命中判定
// 範例：yaw = 0 面向 +Z；正角度朝 +X 旋轉。
function inAttackCone(origin, target, attackYaw, range, halfAngle) {
const dx = target.x - origin.x;
const dz = target.z - origin.z;
const distance = Math.hypot(dx, dz);
if (distance > range) return false;
if (distance < 0.00001) return true;
const forwardDot = (
Math.sin(attackYaw) * dx + Math.cos(attackYaw) * dz
) / distance;
return forwardDot >= Math.cos(halfAngle);
}
TRAP · 零度陷阱
角度 0 是有效值，所以不要寫成 attackYaw || playerYaw，那會把合法的零度當成沒有值。改用明確的狀態，或在允許缺值時用 ??。
攻擊也需要時間結構：起手、有效命中、收招。普攻可以在揮劍中段觸發傷害；重擊可以有更長的起手，換取較大範圍或硬直。同一次揮擊要記錄已命中的目標，避免每一幀都重複扣血；技能刻意設計成多段傷害的話，就讓每一段擁有自己的命中記錄。
高速投射物要檢查前後位置之間的路徑，只看這一幀有沒有碰到敵人，很可能直接穿過目標。
CHAPTER 08 · SKILLS
四個按鍵如果只是不同顏色的爆炸，玩起來很快就會重複。更好的方法，是讓技能分別處理追擊、包圍、預判與爆發。以下是一組可用於第一輪試玩的示範數值，還沒經過完整的平衡驗證：
SKILL SET · 四個技能，四種用途
Q
裂空劍氣
戰鬥用途
向前發射，追擊遠處敵人
視覺重點
細長劍波、清楚的拖尾
冷卻起點 2.5 秒
W
迴旋斬
戰鬥用途
被包圍時造成近身範圍傷害
視覺重點
兩段不同半徑的圓弧
冷卻起點 5 秒
E
雷印轟擊
戰鬥用途
預判前方位置，延遲落雷
視覺重點
地面符印、短暫蓄光、垂直雷擊
冷卻起點 8 秒
R
天劍審判
戰鬥用途
首領空檔中的大範圍爆發
視覺重點
巨型法陣、降下巨劍、環形衝擊
冷卻起點 18 秒
技能可以共用一個流程：「檢查能否施放 → 扣除資源 → 進入起手 → 觸發命中 → 收招 → 清理特效」。冷卻與魔力消耗最好集中成資料，HUD 直接讀同一份狀態，才不會出現介面顯示可用、按下去卻放不出來。
PROMPT · 05 技能實作
請新增 QWER 四個攻擊技能，依技能表實作不同用途。
每個技能都要有起手、有效命中時間、收招、消耗與冷卻。
施放開始時記錄角色朝向，角色動作、武器、特效與傷害共用該方向。
Q 檢查投射物移動路徑，W 明確區分兩段命中。
E 的預告圈要與實際落雷範圍一致。
R 的主要爆發不能完全遮住敵人的攻擊提示。
請實測面向前、後、左、右及零度朝向，
並檢查死亡、翻滾、暫停及重開時，不會殘留傷害事件或特效。
特效的帥氣來自節奏和層次。先有小幅蓄力，再有一個清楚的主要形狀，最後用粒子與殘光收尾。整段都開到最大亮度，反而會失去重點。
CHAPTER 09 · LEVEL FLOW
這類短篇動作遊戲，可以把關卡寫成幾個明確的狀態：
LEVEL STATES · 關卡狀態機
STATE 01
守衛戰
存活守衛數 6 → 0
STATE 02
首領覺醒
約兩秒辨識時間、鏡頭、音效、血條
STATE 03
首領戰
半血進入第二階段
STATE 04
勝利
結算與重開
↓
任一戰鬥狀態
失敗
玩家死亡即進入，不分守衛戰或首領戰
勝利／失敗
重新開始 → 回到守衛戰
清掉舊敵人、粒子、計時器與殘留傷害事件
只有當存活守衛數從 1 變成 0、而且狀態仍在守衛戰時，才觸發首領覺醒。這樣可以避免多個死亡事件讓首領重複出生。首領登場前給玩家約兩秒辨識新威脅，搭配鏡頭、音效與血條。要不要補給生命或魔力屬於節奏設計：想讓玩家連續作戰就給少量補給，想讓資源管理更緊張就維持消耗。
首領招式要能閱讀。抬武器代表近身重擊、地面長條代表衝鋒、環形預告代表範圍爆發。半血進入第二階段時，先改變出招組合或節奏，讓玩家感受到策略變化。只把血量加倍，通常只會延長戰鬥；玩家需要的是「看懂 → 閃避 → 找空檔反擊」的循環。
CHAPTER 10 · ART DIRECTION
森林、廢墟、薄霧和營火放在一起，不一定就有電影感。先確定玩家第一眼會看哪裡：角色需要清楚的輪廓，道路需要引導，首領區要有比普通區域更強的視覺重心。
NEAR
近景
枝葉與石塊
保留接觸陰影，貼在玩家身邊
MID
中景
角色與戰鬥區
輪廓最清楚的一層，預告圈要看得見
FAR
遠景
破塔與山林
降低對比，空間才讀得懂
材質方面，石頭要有粗糙與濕潤的差異，苔蘚該出現在容易積水或背光的位置，布料與金屬要有不同反光。流水需要速度差、邊緣泡沫與落水霧氣；植被從根部固定、向葉端逐漸增加擺動。
調色之前先確認色彩管理正確。Three.js 用 Linear-sRGB 作為工作色彩空間，有顏色的貼圖和法線、粗糙度這類資料貼圖要依用途分開處理，不能全部套同一種色彩設定。陰影也要有預算：投射陰影的燈光會增加額外繪製工作，先讓主要光源負責陰影，其餘用補光或烘焙資訊撐畫面。
PROMPT · 06 畫面優化
請以目前實機畫面為準，找出最影響質感的三個問題並優先修正。
先處理構圖、角色可讀性、材質比例與接觸陰影，再調整後製。
霧氣要提供深度，仍需看清敵人的攻擊預告。
魔法爆發時保留角色輪廓，避免整個戰場變成白色光團。
提供同一位置、同一視角的修改前後畫面，以及效能變化。
「讓畫面更高級」太籠統；「法陣太亮，遮住角色腳下的紅色預告圈」才是可以立刻驗證的修改。
CHAPTER 11 · PLAYTEST
程式沒有報錯，不代表遊戲好玩；自動測試通過，也證明不了角色相似度或攻擊手感。我會把驗證分成三種：
VERIFY · 三種驗證各回答什麼
讓代理記錄重現步驟、預期、實際結果及驗證方式。尤其要分清楚正常遊玩與測試捷徑：直接把首領血量設成零，可以驗證勝利畫面，卻不能當作正常戰鬥已經通關的證據。
PROMPT · 07 驗收
請實際執行遊戲，完成一輪正常流程，並單獨驗證失敗與重新開始。
若目前沒有瀏覽器操作能力，明確說明，提供我可以重現的操作步驟。
請檢查：
1. 移動與 QWER 不衝突，失焦後不會持續走路或格擋。
2. 攻擊前方命中、後方不命中，零度朝向也正確。
3. 技能冷卻、魔力消耗及 HUD 一致。
4. 最後一隻守衛死亡後，只出現一隻首領。
5. 首領第二階段可辨識，玩家能正常受傷及死亡。
6. 重開後清除舊敵人、粒子、計時器與技能傷害事件。
7. 縮放視窗後，HUD 和按鈕仍能使用。
測試使用獨立資料，不能覆寫正式存檔。
回報哪些是正常操作、哪些是模擬測試、哪些尚未驗證。
CHAPTER 12 · PERFORMANCE
最漂亮的一張截圖，可能剛好出現在只有 15 FPS 的時候。效能要在「多個敵人同時攻擊、玩家施放大招」這種高負載場景量測。
可以從 1080p、一般畫質、目標接近 60 FPS 開始設定預算，但一定要寫下測試裝置與瀏覽器。60 FPS 約等於每幀 16.7 毫秒；最忙碌的一段花到 40 毫秒，就要先找瓶頸。
常見的處理方向：重複植被共用幾何或用實例化繪製、遠景降低細節、限制同時存在的粒子、回收用完的資源、控制陰影範圍，以及限制高密度螢幕的渲染解析度。
透明特效特別值得注意。大量重疊的光圈、煙霧和全螢幕閃光，會讓同一個像素被反覆繪製。把大光圈改成幾個更清楚的形狀，有時既改善可讀性，也降低負擔。另外別為了減少物件數，直接合併需要獨立動畫的角色部件，效能優化要保留骨架、形態鍵與必要的動畫結構。
PROMPT · 08 效能
請先記錄高負載戰鬥中的幀時間、繪製呼叫數與主要資源使用情況。
找出最主要的瓶頸後再修改，避免一次降低所有畫質。
提供低、中、高三檔設定，優先保留角色、技能預告與戰鬥可讀性。
在相同位置與相同操作條件下比較修改前後結果。
不能只回報「已優化」，請提供實際觀察到的差異。
CHAPTER 13 · LONG SESSIONS
和 Astra 合作時，最有效的回饋通常包含四件事：目前看到什麼、哪裡不符合預期、希望怎麼改、要保留什麼。例如：「現在角色靠近拱門時會被遮住；我希望戰鬥期間始終看得見上半身。保留目前鏡頭角度，先試遮擋物淡化，並檢查淡化後陰影是否奇怪。」
“
一次集中處理一個能驗證的問題，比反覆要求「再漂亮一點」更容易讓品質持續上升。
每次準備進入大幅修改前，先保留一個可玩的版本。每完成一段，也把現況寫回專案：哪些功能可用、哪一版角色已確認、目前已知問題、下一步是什麼。換對話或中斷後，都能從檔案恢復工作脈絡。
PROMPT · 09 保存進度
請先更新專案狀態文件：
目前可玩的流程、已確認的美術、已知問題、最近測試結果及下一個最小改動。
接著保存這個可玩的版本，再進行下一步。
如果新要求與現有規格衝突，指出具體衝突，不要同時保留兩套互斥行為。
同樣重要的是給足處理時間。角色造型和複雜戰鬥通常需要多次修正，急不來。
CHAPTER 14 · THE API
只是要完成遊戲，桌面 Codex 或 CLI 就足以當開發入口。想自己做「技能檢查工具」、或把模型接進開發流程，再考慮直接使用 API。
以下是 Node.js 的最小概念範例。它會取得一段分析文字，不會自行讀取你的專案、修改檔案或啟動瀏覽器；要做到這些，得另外提供工具和執行流程。OpenAI 官方程式生成指南就是用 Responses API 呼叫 gpt-6-astra。
先在獨立的開發工具目錄安裝 openai 套件，並在本機環境設定 OPENAI_API_KEY。金鑰不要放進遊戲前端或公開檔案。以下範例可存成 review-skills.mjs：
CODE · review-skills.mjs
import OpenAI from 'openai';
const client = new OpenAI();
const result = await client.responses.create({
model: 'gpt-6-astra',
reasoning: { effort: 'high' },
input: `請檢查以下動作 RPG 技能設計，指出實作時容易漏掉的邊界情況。
Q：前方直線劍氣，2.5 秒冷卻。
W：近身兩段旋斬，5 秒冷卻。
E：前方位置延遲落雷，8 秒冷卻。
R：巨劍範圍攻擊，18 秒冷卻。
請特別檢查朝向、重複命中、死亡中斷、暫停與重開清理。
請輸出可驗證的測試情境，不要宣稱已經執行測試。`,
});
console.log(result.output_text);
Astra 的 API 模型名稱是 gpt-6-astra，官方模型頁列出的 reasoning.effort 包含 low、medium、high、xhigh、max。桌面介面的選項不能直接當成 API 參數用。
NOTE
API 範例需要有效的 API 存取權限與額度。本文沒有實際呼叫這段範例，也不預估固定費用。開始自動化之前，先用小型輸入確認輸出有用，再擴大工作量。
CHAPTER 15 · TAKEAWAYS
能在開發者自己的瀏覽器運作，只完成了交付的一部分。至少要留下原始碼、依賴版本、模型與貼圖、操作說明、啟動方式和素材來源。用 Vite 的範例專案，可以要求整理成：
TERMINAL · 交付指令
# 首次安裝，專案需附有相容的 package-lock.json
npm ci
# 開發預覽
npm run dev
# 建立正式版本
npm run build
# 本機檢查正式版本
npm run preview
正式分享時部署建置輸出，並確認模型、貼圖與音效的相對路徑正確。開發伺服器顯示的 localhost 只代表那台電腦：關掉服務後連不上，並不等於遊戲檔案消失；同樣地，這個網址也不能當成所有人都能玩的公開連結。
交付前用乾淨環境或新的瀏覽器資料重新啟動，確認第一次載入、素材缺失提示、音訊開始播放和完整勝敗流程。宣傳封面如果是概念美術，也要跟實機截圖清楚區分。
公開文章和專案時，另外準備一份分享版本：只包含允許公開的素材，移除真實姓名、帳號、聊天截圖、本機絕對路徑、存檔、金鑰和私人角色設定。可辨識的角色外觀本身也可能是身分線索，匿名教學最好用重新設計的範例角色。
TAKEAWAYS
→
先分工：Astra 搭 Codex 管讀專案與改程式，Three.js 管畫面，Blender 管模型，每一段交出的東西都要能檢查。
→
規格先於美術：小怪 → 首領 → 勝敗 → 重開跑通了，角色細節和光影才有地方發揮。
→
戰鬥可信的三件事：方向、時機、範圍讀同一份施放資料，零度朝向也要測。
→
每一輪只修一個能驗證的問題，先量測再改，回報要分清楚已實測、靜態檢查和尚未驗證。
真正值得留下的成果，是一個你打得開、操作得了、看得出問題、還能繼續改善的遊戲。當 Astra 每一輪都拿到清楚的目標和實際證據，工作就會從「生成一個看起來像遊戲的畫面」，逐步走向有完整體驗的作品。
RELATED READS · 延伸閱讀
EXTRA · LINKS · 延伸資源
✦ GPT-6 Astra 官方模型說明（模型定位、API 名稱與 reasoning.effort 檔位）
✦ ChatGPT 官方快速入門（下載桌面版、切換到 Codex）
✦ 模型選擇與推理強度說明（模型控制項在哪、推理強度怎麼設）
✦ Codex CLI 官方介紹（安裝、登入、/model 與 /review）
✦ OpenAI〈Rethinking skills and prompts for GPT-6 Astra〉（AGENTS.md 與提示設計的官方建議）
✦ OpenAI 官方程式生成指南（Responses API 呼叫 gpt-6-astra 的範例）
✦ OpenAI〈Building games with Astra〉（本文兩張官方圖的出處，Void Explorer 的製作紀錄）
✦ Vite 官方入門（開發伺服器與建置流程）
✦ Three.js GLTFLoader 文件（GLB 載入）
✦ Blender glTF 匯出文件（骨架蒙皮與形態鍵的匯出選項）
✦ Three.js 色彩管理（Linear-sRGB 工作色彩空間）
✦ Three.js 陰影說明（陰影預算）
FAQ
A：在桌面應用程式開啟專案資料夾、切到 Codex，在輸入區下方的模型控制項選 GPT-6 Astra。習慣終端機的話，進專案資料夾執行 codex -m gpt-6-astra。模型能不能選，依帳號與版本而定。
A：能做出一段完整的短篇關卡。程式、套件、伺服器和除錯交給 Astra，你負責定規格、試玩、回報問題，每一輪只修一個能驗證的東西。
A：在規格階段就決定。想保留四個技能鍵，移動改用方向鍵或滑鼠點地，或另外設計可重設的按鍵配置，並在 AGENTS.md 寫死「移動按鍵不得與技能衝突」。
A：回到比例與輪廓。先開一個獨立的頭部檢視場景，用固定焦距、固定燈光比較正面、側面與三分之四角度，依序修輪廓、五官、服裝、表面，前兩層沒對上之前先別加髮絲細節。
A：要它分清楚正常操作、模擬測試和尚未驗證。直接把首領血量設成零能驗證勝利畫面，卻不能當作正常戰鬥通關的證據；沒有瀏覽器操作能力時，要它提供你能重現的步驟。
A：不用。桌面 Codex 或 CLI 就足以當開發入口。想自己做技能檢查工具、或把模型接進自動化流程，再用 Responses API 呼叫 gpt-6-astra。
A：是 AI 生成的教學概念美術。範例的騎士、聖殿與技能都是為了這篇重新設計的原創設定，實機畫面請以你自己專案的瀏覽器畫面為準。
