In English — This game exists because of a homework prompt. I teach an AI workshop, and the advanced challenge in my handout says: build a complete, playable mystery puzzle game from one prompt. I had to prove it works, and I also wanted to stress-test OpenAI's new GPT-5.6 Sol model in Codex. It delivered a genuinely complete game — four chained puzzles with unique solutions, synthesized audio, GPT Image 2 scene art, 32 self-written tests — and then ran out of quota one step before deployment, after burning nearly my whole week's allowance in a day. Claude Code took over the last mile: deploy, domain, portfolio. The interesting part is how it took over — through a shared memory system where both AIs log their work. Reading those logs, Claude found that months of Chinese text had been silently stored as "????", traced it to a one-line Windows PowerShell encoding bug, and fixed it for every AI agent on my machine at once.
The relay baton drops at the finish line
額度在部署前一步歸零 | Death by quota, not by bug
7 月 12 日凌晨,遊戲已經做完了。32 項自動測試全數通過,完整破關流程驗證過,串接四個關卡的謎題鏈也對過。我對 Codex 說:推上 GitHub、部署到 Vercel。
然後它就停了。
不是程式出錯——是 ChatGPT Plus 的週額度燒完了。一個做完了 99% 的專案,卡在最後 1% 的部署,而負責它的 AI 要好幾天後才能「上班」。
這是 vibe coding 時代的新型專案死法:不是 bug,不是需求不清,是額度。
解法後面再說。先講這個遊戲為什麼存在。
A homework prompt needs a proof
出給學員的題目,自己得先交卷 | I assigned it, so I had to ship it
我在帶一個 AI 工作坊,講義最後放了一題進階挑戰:用一個 prompt,讓 AI 做出一款「可以從開始畫面一路玩到結局」的深夜醫院解謎遊戲。
出題的人有交卷義務。如果我自己都沒把這個 prompt 跑到「真的能玩」,它就只是一段好看的文字。
剛好 OpenAI 出了新模型 GPT-5.6 Sol,我也想知道它在 Codex 裡的 agentic 能力到哪——一次餵一整份遊戲規格書,它能自己走多遠?這就成了一石二鳥的實驗:prompt 要驗證,模型也要實測。
跟上次的坦克遊戲一樣,我不會寫程式。我能做的還是同一件事:把「做好」定義清楚。這次的 prompt 重點不在功能清單,在堵死 AI 的偷懶路徑——不可只有靜態畫面、不可有假按鈕、謎題必須唯一解、線索必須遊戲內找得到、錯誤操作不可造成死局、不可宣稱測過實際沒測的功能。完整 prompt 全文照樣附在文末,可以直接複製去玩。
One day, one game
一天做完的遊戲長什麼樣 | What GPT-5.6 Sol delivered
Codex 拿到 prompt 後,先自己寫了設計文件(評估三種架構、選了零框架的 vanilla JS)、再寫遊戲、再給自己出考卷。一天後交出來的東西:
- 四個互相鎖扣的關卡:護理站找出病房號 → 檢驗室比對檢體 → 藥局掃描處方 → 地下機房重建資料鏈。前一關拿到的物品,下一關真的要選取、使用
- 謎題答案不存在任何地方——由場景資料即時推導,還附了一套獨立的 oracle 測試驗證「線索到答案」的邏輯鏈
- 32 項 Node 自動測試 + 瀏覽器全流程測試:完整破關、錯誤回饋、存檔續玩、手機直橫向、鍵盤無障礙
- 自動保存、三階段提示、四個隱藏物件、Web Audio 合成音效
場景背景是 GPT Image 2 生成的:同一套「電影感深夜醫院」美術規格,四張場景圖風格完全統一——深藍空間、青綠終端光、走廊盡頭的冷白燈。效果好到我沒有改過任何一張。

代價也很誠實:這一天幾乎燒光了我一整週的 Codex 額度。Agentic 開發是 token 焚化爐——它自己規劃、自己寫、自己測、自己修,每一輪迭代都是實打實的 token。以 Plus 訂閱的額度,一個這種規模的遊戲大概就是一週的預算。這是我這次實測最具體的收穫:模型很強,但強是有單價的。
The second AI reads the first AI's diary
兩個 AI 的交接,靠一本共享筆記 | The shared-memory handoff
額度歸零後,我把專案丟給 Claude Code:「看看這個專案,寫 CLAUDE.md,接手部署。」
有趣的地方在這裡。我的機器上裝了一套跨 agent 共享記憶系統——Claude Code、Codex、Gemini CLI 的每個 session 都會自動把工作記錄寫進同一個本地資料庫。理論上,第二個 AI 接手時,可以直接查到第一個 AI 做了什麼。
實測結果:真的可以。Claude 查共享記憶,撈出了 Codex 前一天的完整開發軌跡——寫了哪些檔案、測試輸出、最後那筆 commit,以及它斷線前收到的最後一個指令(就是那句「部署到 Vercel」)。交接不用我複述,它自己讀完了前任的日記。
但日記有個問題:所有中文都變成了 ????。
一行程式碼,三個 AI 的中文 | One line, every agent's Chinese
Claude 順藤摸瓜查下去,查出了根因:記憶系統的擷取腳本用 Windows PowerShell 5.1 的 Invoke-WebRequest 送資料,而這個指令在沒指定編碼時,會把文字用 ISO-8859-1(一個不含任何中文的西歐編碼)送出——每個中文字都被換成一個問號,悄悄地、不報錯地,持續了好幾個月。
修復是一行:把文字先轉成 UTF-8 bytes 再送。因為三個 AI 共用同一支腳本,修一處,全部治好。Claude 還做了 before/after 對照:修復前存進去是 ????,修復後是 編碼測試,四個字完好。
這件事給我的感受很微妙。壞消息:幾個月的中文記錄永久失真,救不回來。好消息:如果不是這次跨 AI 交接,這個 bug 可能永遠不會被發現——因為每個 AI 自己都「寫得出去」,只有下一個來「讀」的才會看到滿頁問號。
Ten minutes of playing, again
又是真人十分鐘 | The bug automation missed, again
部署上線後,我自己玩了一局通關。結局畫面大字「病例恢復成功」——字的上緣被平平切掉一條。
32 項測試綠燈、全流程瀏覽器測試通過,沒有任何一項抓到這個。原因很技術:標題用了漸層填字的 CSS 技巧,行高設了 0.94——對英文字母夠用,但中文字形的墨跡幾乎填滿整個字身,超出繪製範圍的部分直接隱形。自動測試驗的是「元素存在、文字正確」,不會知道字被切了頭。
上次坦克遊戲,43 項測試漏了重生 bug,被我十分鐘玩出來;這次 32 項測試漏了截字,又是玩一局就看到。兩個專案、同一個教訓,現在我可以把它升級成定律了:自動化測試驗證你想到的,真人遊玩發現你沒想到的。

修復後,遊戲住進了自己的網域:game-hospital.tingyudeco.com。
Takeaways
- Agentic 開發的成本要用「額度」思考,不是「次數」——一個完整遊戲 ≈ Plus 一週的 Codex 額度。排程重要工作前,先看油表
- AI 之間可以交接,而且比你想的順——共享記憶讓第二個 AI 直接讀第一個的工作記錄;multi-agent 工作流的基礎設施值得投資
- 寫的路徑不報錯,不代表讀出來是對的——中文變
????悄悄持續了幾個月,直到有「另一個讀者」出現。定期抽查你的自動化管線的輸出,不要只看它有沒有跑 - CJK 使用者的老朋友:編碼——Windows 上任何「文字送出去」的環節都可能是 ISO-8859-1 / cp950 陷阱,中文變問號就往編碼查,九成是它
- 真人遊玩不可省,第二次驗證:測試全綠 ≠ 畫面是對的
Links | 所有連結
- 🎮 線上遊玩:game-hospital.tingyudeco.com
- 🕹️ 上一個遊戲的故事:IRON VANGUARD — 不會寫程式,但我上線了一款坦克遊戲
- 🛠️ 更多工具:tingyudeco.com/portfolio/tools
- 📚 AI Workshop:這個 prompt 是課程講義的進階挑戰題
Appendix: the full prompt | 附錄:完整 Prompt 全文
以下是工作坊講義裡的原始 prompt 全文,也就是餵給 Codex 的唯一輸入。按右上角按鈕可整份複製,自由取用改造。
你是一位資深遊戲設計師、前端工程師、UI/UX 設計師與品質保證測試工程師。
請獨立規劃、設計、實作並測試一款可直接在瀏覽器遊玩的單頁解謎遊戲。
遊戲名稱
《深夜醫院:遺失的病例》
核心任務
玩家在深夜醒來,發現醫院局部停電,一份重要病例從醫療資訊系統中消失。玩家必須依序探索四個區域、解開四個互相關聯的謎題,取得最終密碼並離開醫院。
遊戲必須可以從開始畫面一路正常遊玩到結局,不可只建立靜態畫面、展示型介面、無效按鈕或尚未完成的功能。
執行方式
請先在內部完成需求拆解、遊戲流程、資料結構、畫面架構與測試策略,再直接開始實作。
除非遇到無法繼續的外部權限問題,否則不要要求使用者逐步確認,也不要停留在提案、規格書或程式碼片段階段。
請自行完成:
- 遊戲企劃
- 謎題設計
- 視覺設計
- HTML、CSS、JavaScript 程式實作
- 遊戲狀態管理
- 響應式版面
- 功能測試
- 錯誤修正
- 最終交付
技術規格
建立一款可在現代桌面與行動瀏覽器執行的網頁遊戲。
優先使用:
- HTML5
- CSS3
- Vanilla JavaScript
如環境適合,也可以使用 React、Vue 或其他前端框架,但不得增加不必要的部署複雜度。
遊戲必須:
- 可直接開啟並遊玩
- 不依賴付費 API
- 不要求登入
- 不要求後端伺服器
- 不使用真實病人資料
- 不使用受版權限制且未授權的素材
- 不可只有文字冒險,必須具備完整視覺介面
- 不可使用 alert 作為主要互動方式
- 不可出現失效按鈕或假功能
- 不可把謎題答案直接顯示在程式介面上
- 避免把所有解答以明文集中寫在容易被查看的位置
遊戲背景
深夜 02:17,醫院突然發生局部停電。
玩家在一間無人的值班室醒來,桌上的電腦顯示:
「病例資料不完整。系統將於 30 分鐘後自動清除暫存紀錄。」
一份關鍵病例已從系統中消失。
玩家必須前往以下四個區域:
- 護理站
- 檢驗室
- 藥局
- 地下機房
每一區都必須有獨立場景、互動物件與謎題。前一關獲得的物品或資訊,必須實際用於下一關。
遊戲流程
開始畫面
包含:
- 遊戲標題
- 簡短背景故事
- 「開始遊戲」按鈕
- 「遊戲說明」按鈕
- 音效開關
- 清楚的醫院夜間視覺氛圍
第一關:護理站
場景元素可包括:
- 交班白板
- 病房配置圖
- 護理紀錄
- 電話
- 抽屜
- 時鐘
- 閃爍的緊急照明
謎題方向:
玩家必須比較交班紀錄、床號與時間資訊,找出正確病房編號。
完成後取得:
- 一張檢驗申請單
- 或一組可用於檢驗室的識別碼
謎題必須依靠觀察與推理,不能只靠隨機猜測。
第二關:檢驗室
場景元素可包括:
- 檢體架
- 血液分析儀
- 條碼標籤
- 檢驗報告
- 冰箱
- 顯微鏡
- 警示燈
謎題方向:
玩家根據上一關取得的識別碼,找到對應檢體,再依提示排列數值、色碼、符號或檢驗項目。
完成後取得:
- 藥品代碼
- 藥櫃位置
- 或一張部分損毀的處方
不得要求玩家具備專業醫學知識;所有必要資訊都必須在遊戲中提供。
第三關:藥局
場景元素可包括:
- 藥櫃
- 處方籤
- 分裝台
- 藥袋
- 冰箱
- 條碼掃描器
- 上鎖抽屜
謎題方向:
玩家根據檢驗室獲得的線索,從多個藥袋、圖示、編號或顏色中找出正確組合。
完成後取得:
- 機房門禁卡
- 維修代碼
- 或四位數密碼的一部分
藥名可以使用虛構名稱,避免形成真實用藥建議。
第四關:地下機房
場景元素可包括:
- 伺服器機櫃
- 電力控制盤
- 網路拓撲圖
- 門禁終端
- 故障螢幕
- 備援電源
- 資料恢復主機
謎題方向:
玩家必須整合前三關獲得的資訊,完成最後的電力、網路或資料排序謎題。
最後輸入唯一正確的恢復密碼,找回病例並解除醫院封鎖。
結局
完成最終謎題後,顯示:
- 病例恢復成功
- 醫院照明逐步恢復
- 玩家成功離開
- 遊戲完成時間
- 使用提示次數
- 找到的隱藏物件數量
- 「重新遊玩」按鈕
可加入一個合理的小反轉,但不能破壞故事邏輯。
謎題設計規則
四個謎題必須符合以下條件:
- 每個謎題都有唯一解。
- 所有必要線索都能在遊戲中找到。
- 前一關的結果會影響下一關。
- 不可依靠外部搜尋或專業知識。
- 不可使用純粹隨機答案。
- 不可因操作順序不同而導致無法破關。
- 玩家輸入錯誤時,要提供合理回饋。
- 玩家不得因誤操作永久失去必要物品。
- 提示內容應逐步揭露,不可第一次提示就直接給答案。
- 請自行驗證所有謎題從線索到答案的邏輯完整性。
核心功能
遊戲至少包含:
- 四個完整場景
- 場景切換
- 可點擊互動物件
- 物品欄
- 物品選取與使用
- 場景調查文字
- 對話框或資訊面板
- 謎題輸入介面
- 錯誤答案回饋
- 三階段提示系統
- 遊戲進度顯示
- 音效開關
- 重新開始功能
- 勝利畫面
- 遊戲計時
- 提示使用次數統計
- localStorage 自動保存進度
- 清除存檔並重新開始
- 鍵盤與滑鼠基本操作
- 行動裝置觸控操作
- 基本無障礙標籤
視覺風格
整體採用:
- 電影感深夜醫院
- 懸疑但不恐怖
- 深藍、青綠、冷白與少量警示紅
- 柔和光影
- 清楚易讀的繁體中文
- 現代化遊戲 UI
- 醫療資訊系統與復古解謎介面的混合風格
- 桌面版與手機版都要有良好可讀性
避免:
- 血腥畫面
- 驚嚇圖像
- 真實病人照片
- 過度陰暗而看不清互動物件
- 大量小字
- 低對比文字
- 廉價預設按鈕
- 只有文字與色塊的簡陋介面
畫面素材規則
請自行製作遊戲所需的視覺素材。
優先順序:
- 自行繪製 SVG
- CSS 圖形與光影
- Canvas 繪圖
- 若系統具備圖像生成工具,可自行生成場景背景並整合進遊戲
所有圖像必須保持統一風格。
如果無法直接呼叫生圖工具,仍須使用 SVG、CSS、圖示與版面設計完成具有完整視覺層次的遊戲,不可因此省略畫面。
不要使用來源不明的外部圖片。
音效
可加入簡單音效,例如:
- 按鈕點擊
- 解鎖
- 取得物品
- 輸入錯誤
- 電力恢復
- 伺服器啟動
音效必須可以關閉。
若無法合法取得音效,可使用 Web Audio API 生成簡單提示音,不要因缺乏音效素材而停止開發。
介面配置
建議包含:
- 上方:場景名稱、進度、計時器
- 中央:主要場景
- 側邊或底部:物品欄
- 角落:提示、音效、重新開始
- 彈出式面板:文件、謎題與調查內容
互動物件應有適度的 hover、focus 或觸控提示,但不要讓答案過度明顯。
狀態管理
請建立清楚的遊戲狀態,包括:
- 目前場景
- 已調查物件
- 已取得物品
- 已完成謎題
- 已解鎖區域
- 玩家選取中的物品
- 提示使用階段
- 遊戲開始時間
- 已經過時間
- 音效設定
- 隱藏物件紀錄
- 遊戲是否完成
重新載入頁面後,遊戲應能從最近進度繼續。
測試要求
完成實作後,請實際測試並修正問題。
至少測試:
- 從新遊戲開始到正常破關的完整流程。
- 每一關輸入正確答案。
- 每一關輸入錯誤答案。
- 未取得必要物品時嘗試進入下一關。
- 對同一物件重複互動。
- 不按預期順序調查物件。
- 使用提示系統。
- 重新整理頁面後讀取存檔。
- 清除存檔並重新開始。
- 勝利後重新遊玩。
- 手機尺寸畫面。
- 桌面尺寸畫面。
- 鍵盤焦點與基本無障礙操作。
- 所有按鈕是否有效。
- 是否存在無法繼續、無限循環或死局。
- 四個謎題是否真的具有唯一解。
- 所有線索文字與最終答案是否一致。
發現問題後直接修正並重新測試,不要只列出尚未解決的錯誤。
程式品質
請確保:
- 結構清楚
- 函式與變數命名合理
- 避免重複程式碼
- 不在 console 留下錯誤
- 不建立無用途的套件依賴
- 不把主要內容全部塞在單一巨大函式
- 重要邏輯有必要的註解
- 介面文字使用繁體中文
- 遊戲資料與畫面邏輯適度分離
最終交付要求
最終交付必須包含:
- 可直接執行的完整遊戲檔案。
- 清楚的啟動方式。
- 遊戲操作說明。
- 完整破關流程的測試結果。
- 已完成與已驗證功能清單。
- 如有任何技術限制,必須如實說明。
- 不要只提供部分程式碼。
- 不要只提供設計稿。
- 不要只提供開發計畫。
- 不要宣稱已測試實際上未執行的功能。
請以「可完整遊玩、可驗證、無假功能」為最高優先級,視覺華麗程度其次。




