Andrej Karpathy 談 Opus 5 與程序化世界生成的未來

Opus 5 程序化渲染《魔戒》

Andrej Karpathy 最近展示了 LLM 測試的一個轉變：從簡單的靜態資產（例如 SVG 中的「自行車上的鵜鶘」）轉向複雜的、程序化生成的 3D 環境。使用 Opus 5，Karpathy 提供《魔戒》的第一段文字、100 萬個 token 的預算，以及一個 Three.js 渲染請求。該模型花了約兩個小時生成了 5,500 行程式碼來程序化地渲染這個故事。

雖然產出的結果被描述為「笨拙（janky）」，但這項實驗證明了 LLM 現在可以編排 3D 座標中的多邊形資產，並編寫必要的動畫程式碼來賦予敘事生命。 Karpathy 指出，這代表了向「瞬時 GTA（ephemeral GTA）」體驗的轉型——即根據需求生成的超自定義世界，使用者可以潛在於其中作為旁觀者或角色進入故事。

LLM 的「耐力」與自定義的成本

這項實驗的主要啟發之一是 AI 的「耐力（stamina）」概念。Karpathy 主張，LLM 使得開發高度自定義軟體的成為可能，而人類開發者不會因為邊際效用過低而花費時間去構建這些軟體。當生成的成本變得微不足道（或「接近免費」）時，價值主張將從效率轉向創造量身定制、一次性體驗的能力。

然而，Hacker News 上的社群討論挑戰了這種「免費」的觀念，指出此類生成是由龐大的投資者資本和高昂的營運成本所驅動的。一些使用者指出，若以每段原始文本約 10 美元計算，渲染整部小說將會非常昂貴。

關鍵限制：視覺審核中的感知差距

儘管具備編寫數千行 Three.js 程式碼的原始能力，該實驗暴露了目前 LLM 的一個根本弱點：無法原生感知並審核其自身的視覺輸出。

為了精煉渲染效果，Opus 5 必須費力地在各個時間點截圖，並將其作為靜態圖像進行分析。這種「緩慢」的反饋迴圈導致了最終產品中的幾處錯誤與「笨拙感」。技術觀察者的共識是，若要讓 AI 超越基礎演示，它需要一種更有效率、線性或次線性的方式來感知影片與遊戲玩法，而非依賴「圖像轉文字再轉動作」的流程。

社群觀點與反論

這場演示引發了關於此類「基於氛圍（vibe-based）」基準測試與功能實用性之間有效性的辯論。

關於基準測試與「鵜鶘測試」

一些使用者認為，這些測試僅僅是「可愛」而已，與現實世界的實用性並不相關。一位評論者指出：

"LLMs should be tested in the same way people should be tested for a job interview... with tasks RELEVANT to usage. So you don’t just randomly pick some random thing to make the LLM randomly do... no stupid irrelevant pelicans on bicycles."

相反地，其他人則認為這些基準測試很有用，因為它們提供了一種簡單、主觀的方式來追蹤模型能力的進展。

Three.js 的角色

批評者指出，Three.js 是一個文件極其完善的函式庫，擁有眾多公開範例（包括類 Minecraft 克隆版和 FPS 演示），這可能使其成為針對網頁程式碼訓練的模型之「低垂果實（low-hanging fruit）」。他們認為，生成 Three.js 程式碼的能力並不一定代表對物理世界的通用理解，而僅僅是對特定且廣泛可用的 API 的熟練程度。

「拋棄式軟體」時代

一些觀察者建議我們正在進入一個「拋棄式軟體（throwaway software）」時代，這與廉價塑膠的興起類似。在這種範式下，軟體產出成本極低，以至於如果它壞了或有輕微錯誤，人們會直接將其丟棄並重新生成，而不是進行除錯與修補。