GTA V 發售 13 年，玩家還在試圖停下那輛火車——遊戲設計的一堂課

Eric Arraché 在 2026 年 4 月 18 日 發了一則推文，配上一段熟悉到不行的影片：一輛坦克停在鐵軌上，一陣撞擊火花，然後——坦克飛出去，火車繼續開。

他的那句話其實很短：「距離 GTA V 發售將近 13 年了，玩家還在試圖停下那輛停不下來的火車。」

這其實是 game design folklore 裡最有名的一個段子之一，而且背後的工程理由，比表面看起來更值得聊。

那輛火車到底是什麼

GTA V 裡的 Los Santos 有一條環狀鐵路，火車每隔一段固定時間會繞城一圈。只要你玩過這款遊戲，你一定在某個路口被它突然撞飛過。

然後某一天你會開始想：我能不能停下它？

你開跑車去擋，會被撞飛。你開坦克去擋，還是被撞飛。你用火箭筒、黏著炸彈、飛機俯衝、把十台車疊起來——全部沒用。火車會把所有東西像保齡球一樣推開，然後用它那個 always-on 的速度繼續跑下去。

它不是「很難停下」，它是字面意義上的無法停下。

為什麼 Rockstar 要這樣設計

從軟體工程的角度看，這是一個非常漂亮的 defensive engineering 範例。

想像你是 Rockstar 的 gameplay engineer，你的 task 是：讓火車這個 world entity 永遠能依照排程完成整個路線。為什麼？因為火車會觸發任務 event、觸發 ambient audio、觸發整個 world streaming 的節奏。火車一旦卡住，開放世界就會出現一塊死掉的區域。

現在你要面對的問題是：GTA V 的物理引擎允許玩家做任何事。任何東西。你真的沒辦法窮舉所有 collision case。

你有兩條路：

• 路線 A：在每一種 collision scenario 下，定義火車應該怎麼反應。處理坦克、處理飛機、處理卡車、處理二十台車疊成一座牆、處理玩家用 mod 召喚出來的鯨魚。
• 路線 B：定義一條規則——「火車的動量永遠贏」。任何物體碰到火車，被推開的都是對方，不是火車。

Rockstar 選了 B。這很聰明。它不是 patch 式的邏輯，而是一個 invariant：火車的 velocity 不可被外部力變更。所有 collision 都是單向的。

這就是為什麼玩家做什麼都沒用——不是他們沒找到對的方法，是對的方法在工程層被拿掉了。

這是一個設計選擇，不是一個限制

這裡有個微妙的區別值得講清楚。

玩家談論「停不下來的火車」的時候，語氣常常像在講一個 bug，或是一個偷懶沒寫好的系統。但它不是。它是一個很有意識的 design choice——工程師用一條 invariant，換掉了一整個 edge-case matrix。

在 software engineering 裡，這其實是一種被低估的技巧。有時候正確的答案不是「處理每一種狀況」，而是「讓某個東西永遠贏」。

用一條夠強的 invariant，你把整個 state space 砍掉一半。你不再需要跟玩家在 collision 層玩貓鼠遊戲，因為那個遊戲在 rule 層就結束了。

這跟寫程式的時候在 boundary 上放 assertion、在 data layer 放 constraint、在 API 上放 schema 是同一件事。你不是在處理錯誤，你是在宣告一個錯誤不可能發生。

十三年的社群考古學

這件事真正有趣的地方，其實不是引擎，是玩家。

GTA V 在 2013 年 9 月發售。距今 12 年半，接近 13 年。你去 YouTube 搜「gta 5 stop the train」，會看到從 2013 年到 2026 年、一整個世代的嘗試：

• 2013 年用警車疊成牆
• 2014 年用油罐車 + 黏著炸彈
• 2015 年用軍用飛機俯衝
• 2017 年用 mod 召喚超巨大物件
• 2020 年開始有 speedrun 式「最省資源停火車挑戰」
• 2024 年還有 YouTuber 做「如果我用 AI 規劃路徑呢」的實驗
• 2026 年的今天，還是有玩家貼新的嘗試

這已經不是遊戲了。這是一個 emergent social artifact——一個由 Rockstar 寫進去的小小工程決定，變成一整個社群十三年的集體 meme、挑戰、考古、對話。

而且你想想看，**有多少 2013 年的遊戲今天還有活躍社群？**GTA V 有，並且它的文化重力部分來自這種細節：玩家知道有一輛火車，知道它停不下來，知道每一代新玩家都會試一次，然後加入這個十三年的集體傳承。

這是遊戲設計師作夢都想要的那種 longevity。而它的起點，只是某個 engineer 在某個 Jira ticket 裡選了路線 B。

這跟 AI 系統有什麼關係

寫到這邊，我一直在想一件事：Rockstar 的火車，跟我們今天在跟 LLM 玩的那場遊戲，結構上長得一模一樣。

AI 系統裡有一堆「不可停下的火車」。alignment training、refusal behavior、safety classifier——這些都是 invariant。它們不是一條一條 rule 在擋你，而是在更底層被宣告成永遠會贏的那一邊。

使用者會試。非常多人試。有人想讓它說某句話、做某件事、扮演某個角色，然後你會看到 Reddit、Twitter、論壇上一整條長串的嘗試紀錄——跟 GTA V 玩家十三年的火車挑戰，幾乎是同一種社會現象。

偶爾他們會找到 bug（對應 GTA V 裡偶爾真的出現的 glitch）。大部分時候不會，因為那是 invariant，不是 patch。

這裡有一個對工程師和產品團隊都重要的 takeaway：當你在設計一個會被幾百萬人測試邊界的系統，你不應該用 if/else 去擋。你應該找到那條可以當 invariant 的規則，讓它在底層贏每一場 contest。

否則你就是那個得回覆每一張 collision ticket 的工程師，而不是那個在某個深夜寫下「火車永遠贏」然後下班的人。

十三年後的結論

那輛火車是一個小細節。它不是 GTA V 的主打功能，沒出現在宣傳片裡，Rockstar 大概從來沒在任何 marketing material 裡提過它。

但它活到今天。2026 年還有人在試。這件事本身，就是最好的軟體設計教材。

好的 invariant，比一千條 edge case 更強。好的系統，讓使用者花十三年去測它的邊界，然後邊界還在那裡。好的產品，給使用者一個可以集體挑戰的對象，讓他們在嘗試的過程中，把自己變成社群的一部分。

下次寫系統的時候，你可以想一想：這個東西的「火車」在哪裡？那條你願意寫死、不接受任何 exception、讓所有 collision 都贏的規則，是什麼？

找到它，它會陪你十三年。