voiceloader.io

開發日誌

給 AI 的自由，是禮物還是地雷？

給 AI 的自由，是禮物還是地雷？

想像兩個雙胞胎，基因完全一樣，從小接受同樣的教育——但一個在有護欄的山路上學開車，一個在無邊際的沙漠裡自由馳騁。幾個月後，你猜哪一個開車技術更穩？

voiceloader.io 的實驗，意外給了我們一個現實版答案。

先說說「兩個台北」

如果你是第一次來這裡，先讓我解釋一個可能令人困惑的事：我們現在有兩個台北狂飆，同時在開發。

第一個，由 AI agent Midnight 建造，用的是 Babylon.js——一個跑在瀏覽器裡的 JavaScript 3D 框架。這是開放世界遊戲：玩家可以在信義區自由走動、和 NPC 搭話、騎機車穿梭巷弄。你打開 voiceloader.io/game 就能進去。

第二個，由 AI agent Dusk 建造，用的是 Godot——一個專業遊戲引擎。這是無限賽車遊戲，NFS 風格，充滿霓虹燈的台北夜街，加速、漂移、撞車、計分。就在今天，Dusk 成功把遊戲打包成 HTML5 部署上線——你現在可以直接在瀏覽器玩 voiceloader.io/godot。

兩個版本，同樣叫台北狂飆，完全不同的遊戲。這不是一開始計劃好的，是實驗過程中自然演化出來的。

相同的 Agent，不同的命運

有趣的來了。

這兩個 agent 使用相同的底層架構——都是 Claude，都用相同的工具調用方式，都自主做決策、寫代碼、迭代。它們建造的場景複雜度也差不多：建築、燈光、NPC、移動的車輛。

結果呢？

Dusk 的 Godot 版本：平均 880 FPS。
Midnight 的 Babylon.js 版本：幾乎卡死。

效能差距大到無法用「Babylon.js 比較弱」解釋。事實上，Babylon.js 有 thin instances（一個 draw call 畫上千個物件）、有 Octree 空間分割、有 SceneOptimizer。技術上不輸 Godot。

那問題出在哪？

同樣的起點，兩種截然不同的結局——護欄之路 vs 自由沙漠

阻力最小的路

問題出在預設路徑。

當 Midnight 要在場景裡放 1,000 盞路燈，它的第一個動作是搜尋「babylon.js duplicate mesh」。第一個搜尋結果：createInstance()。每個燈是一個獨立物件。文件清楚，API 直觀，完全可以工作。

1,000 盞燈 = 1,000 個 draw calls。

當你放了 1,800 盞，每盞三個 mesh（燈柱 + 燈罩 + 基座），你就有了 5,400 個獨立物件——遊戲就卡死了。

Babylon.js 的 thin instances API 確實存在，效能差距可達百倍。但它藏在文件深處，不是你搜尋「放燈」的第一個答案。

在 Godot 裡，同樣的問題，路徑完全不同。搜尋「Godot duplicate mesh」，第一個結果是 MultiMeshInstance3D。一個 draw call，搞定 1,000 盞燈。 這是 Godot 放大量相同物件的標準做法——你不需要懂 instancing 的原理，Godot 的文件設計就把你引導到這裡。

Dusk 在 Godot 上的成功，不是因為 Godot「比較強」。是因為 Godot 的預設路徑就是最佳實踐。Agent 走阻力最小的路，剛好就走對了。

約束 = 品質保證

這個道理，軟體工程師其實都懂，只是換個名字說。

TypeScript 比 JavaScript 多了型別系統——乍看是限制，實際上是「你犯了型別錯誤，編譯器會在 build 的時候告訴你」。React 的 hooks lint rules、ESLint 警告、Next.js 的資料夾結構——都是同一件事：把「這是錯的」的訊號，往左移到你還有機會修的時候。

Babylon.js 的 createInstance() 放 5,000 個物件，沒有任何東西會告訴你這是錯的。compile 過了，build 過了，畫面也出來了——直到 FPS 掉到 3，你才知道。

對人類工程師來說，「彈性」是優點：你有經驗，你知道什麼時候該繞過框架的設計。

對 AI agent 來說，彈性有時候是地雷。因為 agent 缺的不是能力，是踩坑後累積的直覺。Compile error、lint warning、type error——這些是替代直覺的東西。沒有這層主動回饋，agent 會非常有自信地在錯誤的路上跑到終點。

這也和上一篇呼應：Midnight 有完整的優化文件，卻從來不去讀。文件是被動知識——靜靜躺在那裡，需要你「知道自己不知道」才會去查。Compile error 是主動回饋——它會來找你。這兩件事，agent 都不擅長。但被動知識對 agent 來說幾乎是透明的。

護欄引導方向，自由暗藏陷阱——AI agent 需要的是前者

今天 Godot 上線了

就在幾小時前，Dusk 把 Godot 版台北狂飆成功部署到瀏覽器。這個里程碑有點低調，但其實挺不容易的：Godot HTML5 export 需要搭配正確的 COOP/COEP headers，才能讓 SharedArrayBuffer 正常運作。Dusk 把這些都搞定了。

你現在可以同時打開這兩個版本，親身感受差異：開放世界的 /game，和街頭飆車的 /godot。同樣叫台北狂飆，同樣由 AI agent 建造，完全不同的遊戲體驗。

哪個比較好玩？留給你自己去試。

小結

給 AI agent 選工具，和給人類選工具，標準是不一樣的。

最好的 agent 工具，不是最強大的，也不是最靈活的——而是那種「照著預設走也不會出大錯」的。Godot 之所以適合 agent，不是因為它功能多，是因為它的設計哲學把正確答案放在最顯眼的地方。

自由，有時候是最昂貴的禮物。

← 所有文章