下樓梯遊戲 AI：從規則引擎到控制理論的失敗實驗

2026年1月10日 · wemee (with AI assistant)

game-ai control-theory failure-analysis javascript

前言

延續上一篇關於打磚塊 AI 的成功經驗，我試圖將「物理模擬 + 最佳路徑搜尋」的方法套用到「下樓梯 (NS-Shaft)」遊戲中。結果卻遭遇了滑鐵盧。這篇文章不只記錄失敗，更試圖從控制理論與演算法的角度分析原因。

系統差異分析

首先，我們必須認知到兩個遊戲本質上的不同：

特性	打磚塊 (Breakout)	下樓梯 (NS-Shaft)
決策頻率	低頻 (每回合一次)	高頻 (每幀一次, 60Hz)
決策性質	離散 (Discrete)	連續 (Continuous)
狀態可逆性	部分可逆 (球會彈回來)	不可逆 (時間/樓梯一直往上)
最佳化目標	單次收益極大化	生存時間極大化 (動態規劃)

失敗迭代史

1. 規則驅動 (Rule-based) 的侷限

最初，我嘗試了簡單的啟發式規則：「找下方最近的樓梯，移動到其中心」。這導致了 AI 「貪婪地」 停留在當前樓梯上，因為它認為「我已經在目標正上方了」，卻忽略了不跳下去就會被天花板夾死的後果。

2. 物理模擬與單步預測

為了改進，我引入了物理引擎模擬，預測未來 1.5 秒的狀態。

// 模擬 Time-To-Live (TTL)
if (sim.y < -20) score = -20000; // 觸頂死亡 (Immediate Death)
if (sim.y > canvasHeight) score = -5000 + survivalTime; // 掉底死亡 (Delayed Death)

雖然加入了區分死亡類型的權重，但 AI 依然表現糟糕，經常在平台邊緣瘋狂抖動。

3. 震盪效應 (Oscillation)

這是一個典型的控制理論問題。當 AI 每幀都在「向左」與「向右」之間評估分數時，如果兩者的預期收益極為接近（例如站在平台邊緣時），AI 就會變成一個沒有遲滯 (Hysteresis) 的 Bang-bang Controller：

Frame 1: 向左安全 (+100分) → 執行向左
Frame 2: 向左一點點後發現右邊好像更好 (+101分) → 執行向右
Frame 3: 重複…

結果就是 AI 像抽筋一樣在原地抖動，直到被地形殺死。

4. 鎖定機制 (Locking Mechanism) 的雙面刃

為了消除抖動，我加入了「動作鎖定」：一旦決定方向，就執行到底直到著陸。這解決了抖動，卻帶來了新問題：無法應對動態變化。當移動樓梯突然轉向，或者新的障礙物出現時，鎖定的 AI 無法及時修正，只能眼睜睜看著自己衝向死亡。

核心問題：貪婪演算法 vs 動態規劃

目前的失敗，本質上是因為我們試圖用貪婪演算法 (Greedy Algorithm) 解決一個需要動態規劃 (Dynamic Programming) 甚至 強化學習 (Reinforcement Learning) 的問題。

在下樓梯中，當下的「最佳位置」往往不是「全域最佳解」。為了活得久，有時候必須先去一個看似危險的地方（如邊緣），以便能夠接上下一個出現的樓梯。這種跨時間尺度的策略規劃，是簡單的物理模擬難以做到的。

未來展望：邁向強化學習

手工打造的決策樹 (Decision Tree) 在這種高動態環境下維護成本過高。下一階段，我計畫引入 Deep Q-Network (DQN) 或 PPO 演算法。

與其告訴 AI 「怎麼走」，不如定義好 Reward Function（活越久分越高），讓神經網路自己去從數萬次的死亡中「學會」生存的藝術。

這才是通往「最強 AI」的正確道路。

本文由 AI 協助撰寫，記錄真實的試錯與反思。