玩家用 Claude 修復《上古卷軸 IV：遺忘之都》重製版效能：平均 FPS 最高提升 48%，卡頓宣稱減少 90%，AI 開始深入遊戲引擎底層

一、升級顯示卡仍然卡頓，問題可能不在 GPU

2026 年 10 月，一名使用 LTSharpe 名稱的玩家公開了《The Elder Scrolls IV: Oblivion Remastered》效能修復模組。他表示，即使將顯示卡從 GeForce RTX 2070 Super 升級至 Radeon RX 9070 XT，搭配 Ryzen 7 5800X 與 32GB DDR4 記憶體，在 Cheydinhal 等區域仍可能遭遇低 FPS 與明顯卡頓。這種現象提醒玩家：更換 GPU 不一定能解決由主執行緒、記憶體配置或世界資料載入造成的效能瓶頸。

這名玩家於 Reddit 分享，自己使用 Anthropic 的 Claude 協助分析遊戲執行行為，並將成果整理為開源模組 Oblivion Remastered Performance Fix。Tom's Hardware 在 10 月 20 日報導，模組於特定情境下呈現平均 FPS 最高約 48% 的提升，卡頓次數也被宣稱大幅下降。這些數字是特定測試結果，不等於每位玩家都能獲得相同增益。

二、為什麼不降低畫質也能增加 FPS？

一般玩家熟悉的效能優化，是降低陰影、反射、視距或輸出解析度，讓 GPU 每一幀需要處理的工作變少。但遊戲的每一幀不只有繪圖：CPU 還要更新世界狀態、處理 NPC、碰撞與物理、準備繪圖指令，並在玩家移動時載入新區域。

如果 CPU 端重複執行不必要的運算，或大量工作集中在單一執行緒，即使 GPU 尚有餘裕，整個畫面也必須等待。這次模組的主要方向，就是減少不必要的 CPU 工作，改善工作排程與資料處理方式，而不是直接犧牲影像品質。

因此，「不修改遊戲資產與視覺設定」不代表完全不改動遊戲。這款模組涉及 DLL 載入及執行期間的程式碼修補，修改的是遊戲如何工作，而非它要呈現哪些美術內容。

三、第一個瓶頸：每一幀重建太陽與月亮

LTSharpe 在 Reddit 說明，遊戲某些流程會在每一幀重新建立太陽、月亮相關狀態，進而引發場景物件光照的重複計算。若相關輸入沒有改變，這類工作就可能成為沒有必要的 CPU 負擔。

修復思路是將「每幀更新」改為「狀態發生變化時才更新」。這是事件驅動與快取思維的典型應用：不必重新計算已知且未變的結果。不過，外界尚未獨立確認所有遊戲版本與情境下的實際呼叫路徑，應將這項原因歸屬於模組作者的分析。

四、第二個瓶頸：反覆配置與釋放記憶體

另一項作者指出的問題，是遊戲頻繁進行記憶體配置與釋放。配置記憶體不一定很慢，但若在高頻率的遊戲迴圈內大量重複，可能造成配置器負擔、快取效率下降，並使某些幀的處理時間突然拉長。

模組採用可重用緩衝區等方式，減少短生命週期配置。這與遊戲引擎常見的 Object Pooling、Buffer Reuse 原則相近。改善的不一定只有平均 FPS，更可能是降低某些幀突然暴增的執行時間。

五、第三個瓶頸：單一執行緒塞滿工作

現代 CPU 有多個核心，但程式如果將繪圖指令準備或世界更新集中在一條主要執行緒，其他核心閒置也無法自動幫忙。作者表示，模組嘗試把部分可分割工作平行化，降低單一執行緒的壓力。

平行化並非把所有函式丟到多核心就能變快。工作之間可能存在資料相依性，過度切分還會增加同步、鎖定與執行緒切換成本。真正的難點在於辨識哪些操作可以安全地同時執行，並維持遊戲邏輯與畫面結果一致。

這也是 AI Agent 參與底層效能調校值得關注的地方：模型可以協助整理程式碼、提出假設、製作測試工具，但是否真的安全，仍需要重複測試與人工判斷。

六、第四個瓶頸：移動時載入新區域造成 Traversal Stutter

《遺忘之都》屬於開放世界遊戲。當角色穿過區域邊界，遊戲需要載入新 Cell、建立 NPC 與物件、連結物理系統，同時卸載不再需要的資料。若這些工作集中在少數幀內完成，就會出現 Traversal Stutter，也就是移動時突然停頓。

作者表示，修復方式之一是將部分工作分攤到數個影格處理，而非一次全部完成。這種設計的核心，是控制每一幀的工作預算。例如 60 FPS 的每幀時間預算約為 16.67 毫秒，若一次世界載入工作占用 60 毫秒，玩家就會明顯感覺到停頓。

分攤工作可以改善流暢度，但必須避免 NPC、碰撞物件或任務事件因延後建立而產生錯誤。因此，卡頓減少與遊戲正確性需要分開驗證。

七、48% FPS 與 90% 卡頓減少，究竟代表什麼？

新聞標題的兩個數字代表不同測量維度。平均 FPS 反映一定時間內的平均畫面產出速度；卡頓通常與影格時間的異常尖峰或超過特定門檻的事件次數有關。

假設一個場景從 50 FPS 提升至 74 FPS，平均 FPS 的相對增幅就是 48%。但這不代表每一幀都變快 48%，更不保證所有場景都會如此。

同樣地，卡頓事件減少 90%，需要知道測試採用的判定門檻、路線、時間長度與統計方法。不同工具對 Hitch、Stutter 的定義可能不同，不能把「事件次數下降」直接等同於「最低 FPS 提升 90%」。

Tom's Hardware 亦提及更高的極端場景增幅，但不同場景與統計指標不應混為一談。較合理的結論是：模組作者提供了令人關注的改善證據，仍需要第三方在多種 CPU、GPU、記憶體與遊戲版本上進行交叉測試。

八、AI 如何在沒有完整遊戲原始碼的情況下協助修復？

模組作者描述，他利用 Claude 協助建立可重複的效能測試流程，分析程式執行行為，並製作修補。這不等於 AI 自動取得所有商業遊戲原始碼。作者提到透過 Epic 的開發者授權取得 Unreal Engine 原始碼存取權限，而《遺忘之都》重製版自身的專有遊戲程式碼仍不是全面公開。

對封閉原始碼遊戲進行效能修復，常需要透過執行行為、反組譯、特徵碼定位與動態修補理解程式流程。此類 DLL 修補對版本相容性十分敏感：遊戲更新後，原本的機器碼位置或函式結構可能改變，模組就可能失效，甚至導致當機。

所以這個案例最值得研究的不是「一句提示詞讓 AI 把遊戲優化完」，而是玩家把 AI 當作分析與編程助手，透過持續測試、定位瓶頸、修改程式與回歸驗證，完成過去需要高度專業技能的工程工作。

九、AMD FSR、Frame Generation 與 Alt+Tab 問題

報導指出，部分修復與 AMD FSR 及影格生成有關，包括遊戲在 Alt+Tab 切換視窗後可能停用相關功能的問題。這類問題與 CPU 排程優化不同，屬於遊戲整合與狀態管理上的缺陷。

影格生成能提高螢幕顯示的影格數，但生成影格不等於遊戲模擬本身以同等幅度加速，也不必然降低輸入延遲。因此比較模組效能時，必須確認是否使用相同的升頻、影格生成與畫質設定，否則很容易把不同技術帶來的改善混算在一起。

十、為什麼這件事對遊戲產業重要？

過去 AI 寫程式的熱門話題，多集中在建立網頁、應用程式或自動化腳本。這次案例則展示另一條路：使用 AI 協助進行效能剖析、程式碼考古與既有軟體維護。

對開發商而言，這類工具可能加速追蹤長期存在的 CPU 瓶頸；對模組社群而言，AI 降低了接觸底層技術的門檻。但 AI 產生的二進位修補仍可能包含競態條件、記憶體錯誤、版本衝突與安全風險，不能因為跑分改善就免除程式碼審查。

更值得注意的是，遊戲最佳化的下一個焦點可能不只是更高的平均 FPS，而是穩定的 Frame Time、較好的 1% Low，以及更少的開放世界移動卡頓。對玩家而言，從 60 FPS 變成穩定 60 FPS，有時比從 100 FPS 變成 120 FPS 更有感。

十一、玩家該不該安裝？

有興趣的玩家應先確認模組支援的遊戲版本、相依元件與已知問題，從作者提供的 GitHub 或 Nexus Mods 官方專案頁取得檔案，保留原始設定及存檔備份。由於模組會修改程式執行行為，防毒誤報、與其他模組衝突或遊戲更新後失效都可能發生。

特別要注意：這不是 Bethesda 或 Virtuos 官方修補程式，新聞中的效能數據也不是普遍保證。若追求穩定，應先閱讀更新紀錄與其他使用者的硬體回報。

Tech English｜技術名詞中英對照

1. Frame Time（影格時間）：完成一個影格所需時間，常以毫秒表示，比單看平均 FPS 更能觀察瞬間卡頓。
2. Traversal Stutter（場景移動卡頓）：角色移動到新區域時，因資源載入、物件建立等工作造成的短暫停頓。
3. CPU Bottleneck（CPU 效能瓶頸）：CPU 無法及時完成模擬或繪圖準備工作，使 GPU 必須等待。
4. Memory Allocation（記憶體配置）：程式向系統取得記憶體的操作；過度頻繁可能增加額外成本。
5. Binary Patching（二進位程式修補）：在缺乏完整應用程式原始碼時，修改已編譯程式的部分執行邏輯。
6. Regression Testing（回歸測試）：修改程式後重新驗證既有功能，確保效能改善沒有引入新的錯誤。