Vibe Coding 第一篇, 一個香港夢：
與 AI 共建小熊諾樂GO！
從夢想到行動：AI送我一對翼
我是數據科學家和AI工程師。我用Python編碼都超過10年了，主要從事數據科學、機器學習工程和AI工程。Pygame？我有聽過，玩過幾次基本的Programming，但從未敢夢想打造一個完整的遊戲。但門檻太高了。我不擔心學習這套語言，我擔心的只是必須投入的大量時間去完成一隻game。
我想創造一些有趣的東西，令香港人產生共鳴。就好似能像給年輕一代留下一些遺產，希望佢哋唔會忘記美好嘅香港。但我的想像力超出了我的技能。如果要自己一個人去做地圖佈局、動畫、遊戲邏輯、遊戲編碼，就好似是在沒有裝備的情況下攀登一座山一樣困難！
我本身訂閱了多個 AI 服務。我嘅感覺係，如果你在某個領域已有基礎，甚至乎是專業知識，AI是非常有幫助，能大大提升效率。但如果你在某個領域完全是新手，AI 就幫不上太多忙。直到有了 Grok 3（最近聽到 Gemini 2.5 Pro 的好評，我都很想試試）。有了 Grok 3 作為我的副駕，vibe coding都形成改變了一切。突然間，我不再只是幻想《小熊諾樂GO！香港版》，我真的可以自己建造它。只用了四周的時間，不是幾年，我就有了可用的原型：玩家能擲骰子，在地鐵站之間來回走動，購買物業，躲避颱風等季節性事件。冇錯，這個遊戲很像桃太郎電鐵，因為我自己本身是桃太郎電鐵的fans，我在中學的時候，已很想有一個香港的版本。
如果沒有 AI，我還是在盯著空白的 IDE，感到老鼠拉龜一樣根本無所適從。有了AI，我完成了我從未想過能做到的事情。正如某位開發者所說（抱歉我忘了是誰在哪裡說的）：「AI 把程序員變成了巫師 ，指一指，許個願，就能看到魔法發生。」這正是我現在的感覺。
半人半機械：共同合作的力量！
Grok 3 很出色，但它暫時還是無法取代人類的創造力。這個項目我會說我和AI的工作分成大約是 50/50。我帶來了願景、計劃、測試、調試和解決方法等；Grok 負責生成大量通用代碼（我當然也有編碼，完全只有AI暫時還是不可能的）。你可以。把它想像成終極編碼助手，我只需說：「嘿，給我做一個帶 3D 按鈕的HUD」，70% 的時間它就能完美呈現我腦中的畫面。另外 30% 呢？嗯，AI 會犯錯，我需要自己寫。它會幻想語法，誤解意圖，或者生成看起來完美但崩潰得很厲害的代碼。這時我就得介入（其實長期都需要介入，哈！）比如當火車傳送到地圖以外的地方，我們需要引導 Grok 回到正軌。
AI 不僅幫我視覺化我的思維導圖，還讓我的夢想成真。但上圖還是我經過一天手動整理後的遊戲棋盤。
我啟動這個項目的另一大原因是想看看 vibe coding 究竟能帶我走多遠。在早期概念驗證 (POC) 階段，Grok 3 讓人驚嘆 ！因為它幾乎能一次就實現我想要的東西。（我稍後會在我的 repo 中分享《小熊諾樂GO！》的文本版 POC。）這一點就讓我震驚。但真正的考驗是轉向 2D 遊戲棋盤版本時開始的。情況就很像，你被美女吸引了之後拍拖，但是拍拖後發現他的性格有點難⋯⋯
Grok 3 無法克服的一個巨大障礙是將車站的 x 和 y 坐標映射到 2D 地圖上。給他一個分辨率很高的簡單地圖之後，我的第一個提示很簡單：「給我一個簡化地圖上車站的大約 x 和 y 坐標。」但是它失敗了。於是我不斷反覆調整 — 每次都會給 Grok 更多的細節：譬如車站名稱、大概的位置、它們之間的關係，甚至把地圖縮小到只有一小部分。儘管如此，Grok 3 還是無法給出合理的車站位置列表。
最後，我只好自己手動繪製了地圖。這個單一項目就已經要花幾天到大約一星期的時間完成。之後，我的地圖看起來還是有一點亂。於是我再次求助 Grok：「你能整理一下嗎？如果車站大致在直線上，就把它們整齊排列。」即使多次優化提示，Grok 還是沒能搞定。車站仍然歪歪扭扭的。
AI 能取代人類嗎？也許能，但一兩年內我覺得絕對不行。它暫時還只是一個工具，不是大腦。在我提出一個想法，比如為車站設計問答系統，Grok 會給出一個不錯的草案。但細緻的設定，如當玩家的現金變成負數，遊戲沒能正確處理債務時，我得親自測試，實時調整邏輯，甚至乎自己編寫程式。AI 無法「感覺」遊戲流程；它抓不到只有人類玩遊戲時才能發現的細微錯誤。Hossein Mohammadi 先生也說過類似的話：他的 LinkedIn 帖子稱 AI 是一個「從不睡覺、工作快如閃電、偶爾犯下搞笑錯誤的天才實習生」。
平衡的藝術：AI 的問題
說到遊戲流程，平衡是 AI 另一個掙扎的領域，這不是它的錯，平衡是主觀的，與人類的情感和感覺相關。譬如到達目的地應該獎勵 $500 還是 $1000？季節性事件應該觸發的頻率是 10% 還是 20%？我請 Grok 調整這些，但它的建議要麼太機械（固定百分比），要麼離譜（$10,000 的獎金打破了遊戲內的平衡）。即使在人類之間，平衡也爭論不休 。你只要看看任何遊戲論壇，玩家都在爭論什麼「我覺得這樣比較好」，「我覺得那樣比較好。至於《小熊諾樂GO！》，我最終還是自己調整了事件、概率和獎勵，一輪又一輪地玩，直到找到既具挑戰又有趣的「甜蜜點」。AI 還無法品嚐那種感覺。
索引繁重問題：人類的觸感
還有的就是「索引繁重的工作」 — AI大致上都不能勝任涉及複雜結構化數據的任務，儘管模式是很明顯和簡單的。以 stations.py 中的 map_layout 為例。每個車站是一個nested dict（data的一種種類），包含 "name"、"x"、"y"、"connections" 和 "assets" 等鍵。以下是一個簡單例子：
map_layout = {
0: {"name": "香港", "line": "TCL", "connections": [25, 108], "x": 3516, "y": 3063, "type": "city", "assets": [...]},
1: {"name": "九龍", "line": "TCL", "connections": [2, 104, 106], "x": 2752, "y": 3063, "type": "city", "assets": [...]},
2: {"name": "奧運", "line": "TCL", "connections": [1, 3], "x": 2952, "y": 3063, "type": "city", "assets": [...]},
...
}我想讓車站對齊，比如將「香港」、「九龍」和「奧運」在水平線上均勻間隔。我告訴 Grok：「這三個在東涌線上，將它們的 x 坐標在 2752 到 3516 之間均勻分布，保持 y 一致。」很簡單，對吧？不。Grok 要麼算錯間距，要麼忽略 y 對齊，要麼搞亂車站 ID。超過 100 個車站，錯誤迅速累積，坐標重疊，連接斷裂，地圖看起來像幼兒塗鴉。
為什麼？像 Grok 這樣的 LLM 一般從「模式」中學習，例如文本、語法、邏輯流程。但正正是因為這項任務太依賴「模式」；這項任務是空間和關係性的，有數百個重疊和相似的值。當我叫AI驗證連接（例如確保「香港」連接到「中環」）時，它會漏掉一半檢查，或無法分辨新舊索引。我最終只好全手動自己編寫完成。我自己重新連接和對齊車站，驗證每個鏈接。對於少量條目，AI 或許能應付，但擴展到 10 個以上的數據時，就亂來了。請不要誤會，這不是對 Grok 的批評 — 我還是超喜歡它，只是LLM先天是不擅長這種工作。
統計數據
我在 3 月 1 日左右開始這個項目，帶著滿滿的 vibe coding 能量投入其中。白天和晚上都在弄 — 平日在本地政府工作後都最少會做6小時，週末加到 18 小時。一天都沒曾休息過。對，我就是那種一年365日都沒有放假的那類型。期間每一次嘗試遊戲時，我都會保留一個log。現在數起來，就見到了 109 個開發腳本，和 950 個日誌文件堆積在我的記錄中。即使是動畫，看似簡單，每個只有 3 幀，但平均每個集合花了我超過 4 小時才弄好。
無論如何，都叫完了個心願！
儘管有波折，《小熊諾樂GO！》還是出世了。玩家現在可以在充滿活力的地鐵地圖上擲骰子，購買像「殯儀館」這樣的物業，迎接「King Rexy 的入侵」等（向香港現今的怪趣混亂致敬）。但是當然它還不完美 — 整體的平衡仍需要時間，地圖還能更精緻 — 但它是我的，是我給香港人的。與 Grok 3 的 vibe coding 給了我開始的推動力、建造的工具和完成的信心。
如果你準備好投身這個以火車為主題的冒險旅程，或只是想體驗與AI一起編碼的獨特氛圍，那就來試試《Lorye Go! 香港版》吧！我很期待聽到你的想法，看看你的精彩遊戲時刻，甚至可以幫你調整屬於你的香港靈感創意！
免費下載香港開發遊戲：Lorye Go! 首頁
GitHub 儲存庫：entzyeung/LoryeGo
Windows 或者 Mac版本安裝方法：遊戲安裝方法
香港人，開心遊戲吧！快跳上車，一起感受這股熱血氛圍！
支持作者
如果覺得這篇文章有用，請考慮透過 PayPal小額贊助 捐款支持我！
如果你享受這段旅程，或只是想感謝我將香港的熱鬧混亂化為遊戲的一部分，歡迎透過PayPal小額贊助 或 成為GitHub贊助者。你的支持讓火車繼續奔馳、程式碼持續流動，也讓每位玩家的熱情氛圍永不止息。
謝謝你！
