從 8,429 個錯誤像素到 2 個：一年的前沿模型如何學會移植《波斯王子》

2026 年 9 月 25 日，一位署名 Priyan 的開發者在部落格上發表了一篇文章，靜靜登上 Hacker News 首頁。它可能是迄今為止最清晰的一份「前沿程式模型年度進度報告」。實驗設計簡單得近乎天真：把 Jordan Mechner 的《波斯王子》（Prince of Persia，1989，Apple II）原始 6502 組合語言原始碼——Mechner 在 2012 年從躺在盒子裡超過二十年的軟碟中救回的那份——交給 AI 模型，要求它把遊戲移植到 C#。人類唯一的工作，是玩遊戲、然後說哪裡不對。不讀程式碼、不親手修改，只有 prompt。

結論是一個數字：在第一關的第一個畫面，AI 移植版與 DOSBox 裡真實遊戲的像素差異，從 8,429 個降到 2 個——而剩下那 2 個像素，只是火把火焰被擷取在動畫的不同瞬間。把差距補到這個程度的是 Claude Opus 5.5，而且只用了一個 prompt。但真正值得細讀的，是四代模型如何一路「失敗」到這個數字的過程。

第一回合 — Opus 4.6：語言對了，架構錯了

2026 年 2 月的第一輪嘗試，prompt 樸素得可以：「這份原始碼裡有波斯王子的 6502 組語，用存檔關卡檔案，試著用 C# console 做出來。」兩天內，Claude Opus 4.6 依序產出了 C# console 遊戲、關卡編輯器、再到 Raylib 圖形版。它正確解析了原始關卡檔——房間、地磚、閘門、守衛位置——也畫出了看起來像 Apple II 原作的東西。

但它玩起來完全不是《波斯王子》。作者當時的錯誤回報像一場慢動作車禍：「畫面全是亂的」「角色出來了但移動全錯……王子不在地板上」「現在掉到地板下面，方向鍵不動」。核心問題——後來才診斷出來——是架構層的：AI 讓王子一次移動一整格，像棋子在格子間跳動；而真實遊戲是以逐格手繪動畫播放，每帧只移動一點點。Opus 4.6 讀得懂 6502、寫得出 C#，卻選錯了引擎，而且渾然不覺。

第二回合 — OpenAI Codex：在壞地基上拋光

同年 3 月，同一份程式碼交給 OpenAI 的 Codex：「這是 Claude 做的波斯王子組轉 C# 移植，圖形還是不行，你能修嗎？」Codex 給的修法都很合理：銳利像素濾波讓美術不再糊掉、精靈圖透明背景、可以走過的開啟閘門、不再當成牆的柱頂。但王子依然會卡進錯誤位置。它把表面拋得很亮，卻從未質疑地基，也從未把遊戲跑起來。

第三回合 — Opus 5：看得見遊戲的模型

9 月，實驗規則出現了一個比模型升級更重要的改變。作者寫了兩個 Claude Code skill——一個控制 DOSBox（啟動程式、發送按鍵、截圖），一個控制 Windows 程式——然後把 Opus 5 對準他自己那份 DOS 原版遊戲，下了一道指令：跟真品比對，做到成功，或做到早上六點。

它工作了一整夜。第一件事就是診斷出格狀引擎的架構問題，改以原作的影格序列設計重建引擎。接著它做得更遠：逆向 DOS 版的檔案格式，直接從真實檔案讀資料——王子每一帧動畫、地牢美術、全部 15 個關卡。它在 PRINCE.EXE 裡，靠著從 Apple II 原始碼認得的位元組模式搜尋，找出原版動畫表，而且每張表都先用第二個已知值驗證才肯相信。天亮時，遊戲已可遊玩、動畫是真實的。後續某一輪，作者在 DOSBox 裡玩開頭幾幕、讓模型看截圖，它自己找到了偵測 ledge 的 bug——修法是回頭讀原始組語常式。

但關卡畫面還是不對。磚牆、閘門、裝飾都有細微偏差，因為 Opus 5 是一塊一塊對著截圖擺放，擺不出來的就靠猜。

第四回合 — Opus 5.5：去找原廠「實際上怎麼做」

Opus 5.5 推出後，只拿到一個 prompt：「角色會走會跑會跳了，但閘門位置、磚塊全都不一樣，你是新模型，看你能改進什麼。」

它採取了本質上不同的策略：不是用眼睛微調座標，而是去找「原版遊戲實際上怎麼畫一個房間」——並且找到了答案：SDLPoP，由 Dávid Nagy 與 princed.org 社群多年來從反組譯重建的 DOS 版開源移植。Opus 5.5 把 SDLPoP 的繪製房間常式（src/seg008.c）逐行移植成 C# 的 DosRoomDrawer.cs，檔頭清楚標註來源與 GPL-3.0 授權。

這一步直接解開了前幾輪只能瞎猜的謎團：「隨機」的磚牆花紋根本不是隨機——原版以房間、列、行作為亂數種子，所以每次進來每面牆都長一樣。第一關起點那道閘門，在關卡資料裡其實是開的——是你落下時遊戲按了隱藏按鈕把它關上，所以你才聽到背後「哐」的一聲。

Opus 5.5 還自己抓到前代的兩個錯：PRINCE.EXE 其實用 Microsoft EXEPACK 壓縮過——前代找到的資料表純屬運氣，恰好落在壓縮器沒動的區段——於是它寫了一個解壓縮器，正確讀出繪磚表。另外，前代關於「模板色」的理論是錯的；那些顏色其實是出口門真正的藍綠色。

然後它自己驗收：對著 DOSBox 裡的真實遊戲逐像素比對，差異從 8,429 降到 2，第二個房間與第三關出口門也全部吻合。它並非零缺點——一項只驗證過單一朝向的精靈圖位置修改，讓王子轉向後會沉進牆裡，作者回滾了備份——但連失敗的方式都是新的：模型先證明所有測試 tick 中移動本身完全一致，再孤立出精靈圖 bug，最後只回滾那一小部分。

模型自己的誠實但書

值得稱許的是，作者問了那個顯而易見的問題：Opus 5.5 能不能只靠 DOS 執行檔自己算出這一切？他得到的回答值得整段引用，因為能這樣精準自我評估的模型是新的：

「老實說，一個 prompt 大概率做不到。我沒有逆向繪圖程式碼——我讀的是 SDLPoP 的重建成果，然後移植它。我能找到 PRINCE.EXE 裡的資料表，是因為 SDLPoP 告訴我內容該是什麼。前一個模型沒有這把鑰匙，把執行檔翻遍了也一無所獲。……我真正貢獻的是：知道 SDLPoP 存在、正確讀懂它、發現 EXE 被壓縮、然後逐像素證明結果。」

為什麼這件事超越懷舊遊戲

撥開情懷濾鏡，這個實驗孤立出三個基準測試看不到的變數。第一，架構勝過拋光：Codex 在格狀引擎上做再完美的像素濾波都一文不值，而找出影格序列設計價值連城。第二，驗證才是真正的解鎖——從 Opus 5 開始，模型看得見原作、能拿自己跟原作對打，人類不再是唯一的測試者。第三，「知道知識住在哪裡」正在成為一級能力：Opus 5.5 的優勢不是對著二進位檔硬推理，而是認出 SDLPoP 十年的逆向工程存在、正確讀懂它、並帶著出處移植。

對所有追蹤「AI 會寫軟體」論述的人，這裡還有一條警示線：致勝一步倚賴的是 GPL-3.0 授權的社群重建成果——而模型誠實處理了授權，把聲明帶進移植檔的檔頭，這也讓整個專案必須以 GPL-3.0-or-later 釋出。來源與授權衛生，如今是模型行為，而不只是人類行為。

實驗還沒結束。守衛與劍鬥、宮殿關卡、精確落地位置都還待解。作者說，下一個前沿模型推出時，他會再跑一次同樣的實驗，看它能走多遠。完整的歷程紀錄以 GPL-3.0 公開在 GitHub 上——這意味著下一個模型（以及下下一個），將能讀到它們所有前輩犯過的每一個錯。