Gamystery

YJ 遊戲技術站

長文

AI模型是否可以撰寫Verse語言

在長文【 藍圖的黃昏與 Verse 的黎明：從 AI 自動化推演到社群的震撼教育】中，我注意到開發社群目前對於藍圖取代Verse不滿，都圍在「Verse 對不同族尋使用者的友善程度」，不管事對於既有的藍圖、非程式專業、未來學習的開發者。

換個方式想，如果Verse現在已經是是一個完善、AI 高度整合的功能，讓個類型的開發者的能以低門檻、可預期的方式轉換，相信社群的反彈力度會降低許多。

在AI Coding的能力急速進步下，不論開發者屬於何種身份，轉換至Verse 最佳的路徑應該是「AI 驅動」的模式，能讓各族群轉換的門檻接降至最低。未來大量的遊戲邏輯不管底層或是撰寫採用的語言，都能在AI的助力下， 運用指定的工具完成遊戲創作本身。

Verse 不同於如C++這類型的古老語言，社群普遍對於AI 能否學會Verse，抱持壞疑。

該問題可以拆解成兩個層次：

  1. AI模型是否可以撰寫未曾訓練過的程式語言

  2. AI模型是否可以撰寫Verse語言

AI模型是否可以撰寫未曾訓練過的程式語言

個人主觀、直覺的判斷，如果AI可以「 學習一個特定對象的寫作風格」，則「可以撰寫未曾訓練過的程式語言」。之所兩者類比，互相存在一定的相似性，例如語法、用字習慣…等等，程式語言可以被視為另一種「寫作方式」。類似的能力在語言學與機器學習中被稱為跨語言遷移（Cross-lingual Transfer）與語法上下文學習（In-Context Grammar Learning）。

Coding 九成九以上英文， 比起將其視為另一種「語言」，視為「寫作方式」更為貼切，是另一種英文與符號的排列方式。

目前根據網路上，深度運用AI 寫作的文字工作者分享，以及我個人的使用體驗，前者是完全可以成立的。雖説，風格的相似涉及一點主觀認定，但不可忽視，是有社群認同 AI能學習寫作風格。

然而，直覺的推論就算成立，也難以作爲「AI模型是否可以撰寫未曾訓練過的程式語言」的直接證明，最多當作間接證據。

於是YJ我研究是否有學術實驗，可作為「AI模型是否可以撰寫未曾訓練過的程式語言」的論述的直接證據。

參考幾個研究整理出，幾個重點：

  1. 語法泛化能力

    研究人員進行了「極限壓力測試」，將 AI 完全斷網並餵給它一門全新、不存在的語言。實驗證實，只需在 Prompt 中提供語法手冊（EBNF）與極少數範例，AI 就能在零預訓練數據的背景下，直接寫出語法正確的代碼。

    • Syntax Without Semantics 與 CangjieBench 等研究直接證實：AI 絕非單純死記硬背，而是具備「在線學習未知語法」並進行符號排列組合的泛化能力。

  2. 跨語言潛在概念遷移

    研究指出，不論程式語言的外在形式如何變化，其底層的計算思維（如迴圈、條件分支、記憶體指派）是完全通用的。

    • AI 已在海量傳統語言（C++, Java, Python）的訓練中建立了抽象的「邏輯世界」。面對全新語言時，它無需重新理解概念本身，只需快速學會該語言如何用特定符號（如 []）來表達既有的邏輯。

  3. 語法與語意的斷層 (Syntax vs. Semantics)

    「外表語法正確」絕不等於「編譯執行成功」。AI 雖然能高度模仿新語言的皮毛（外觀風格與縮進），但由於缺乏對底層運行時（Runtime）的微觀物理模擬，極易翻車。

    • 以 Verse 的效果追蹤系統或軟體事務記憶體（STM）為例，AI 寫作時會慣性地將 C# 或 Python 的執行期思維套進來，導致寫出看似漂亮、實則底層邏輯完全崩塌的死代碼。

  4. 神經符號控制框架

    為了解決 AI 盲猜盲寫、容錯率極低的困境，最新的頂尖工程實踐不再依賴單一的靜態 Prompt，而是將 AI（神經網絡）與編譯器/語法解析器（符號系統）強制綁定，形成動態修正的閉環。

    • 透過 Anka 框架 與 VS Code 的 Versly 插件 等技術，當 AI 符號排列出錯時，編譯器的報錯會化為毫秒級的「即時回饋」，引導 AI 在不中斷流程的情況下自動導正代碼，大幅提升落地成功率。

AI模型是否可以撰寫Verse語言

每個語法的底層設計方式有可能存在顯著差異，就算模型展現出一定的語言泛化能力，在面臨實物時未必能有良好表現， Verse就屬於AI 無法良好掌握的語言之一。

現階段，AI撰寫 Verse 表現不定的原因，除了**缺性的訓練樣本，**在於 Verse 獨特的語言設計, 其特性包涵：

  1. 可失敗運算式（Failable Expressions）

  2. STM 回滾機制

  3. 效果追蹤系統（Effect Tracking）

  4. 縮進與大括號的雙軌制

  5. 異步協作與時序黑盒

什麼是「可失敗運算式（Failable Expressions）」？

在一般語言（如 Python）中，如果我們去抓一個清單（List）裡不存在的索引，程式會直接崩潰（Crash）或跳出異常。 但在 Verse 中，「失敗（Failure）」被當作一種控制流程。任何「有可能會失敗」的事情，都必須被放在一個「允許失敗的上下文（Failure Context）」裡（最常見的就是 if 塊）。

AI 常犯的錯

AI 很習慣像寫常規語言一樣，直接去抓陣列的值：

# 這樣寫編譯會報錯！因為陣列訪問可能會因為「索引超出範圍」而失敗
# 編育器會警告：This expression is failable and must be called in a failure context.
Item : int = MyList(0)

正確的 Verse 寫法

你必須用 if 搭配陣列透過方括號 []取值。如果成功拿到值，就執行裡面的事；如果失敗（例如陣列是空的），程式不會崩潰，而是直接跳過 if。

# 正確：方括號用於可能失敗的操作，並放在 if 上下文中
if (Item := MyList[0]):
    Print("成功拿到第一個元素：{Item}")

什麼是STM 回滾機制？

其概念很像「玩遊戲時的存檔與讀檔（S/L 大法）」。

在 Verse 裡，當你執行一連串動作時，如果其中一個步驟失敗了，Verse 擁有一個厲害的能力：它會把剛才那幾秒內做過的所有改變，通通「時空倒流」，恢復原狀（這就是回滾）。

而你要進行這套「預測執行」的動作，必須寫在 if 的縮排裡。

想像一個商店功能：「扣除玩家 100 金幣」→「把神劍放進背包」。

正常常規語言（如 C#）

你必須先用 if 檢查金幣夠不夠，不夠就跳出；如果夠，扣錢，再給道具。萬一扣了錢但給道具時當機，玩家的錢就平白消失了。

Verse 的做法

# 在 if 的方括號環境中，這兩件事是「綁定」的
if:
    Player.DecreaseCoins[100]  # 嘗試扣 100 元（可能失敗）
    Player.GainItem[GodSword]  # 嘗試給神劍（可能失敗）
then:
    Print("交易成功！")

如果玩家有 100 元，扣錢成功了，但下一秒發現背包滿了（給神劍失敗）。Verse 會自動把那 100 元還給玩家，好像扣錢這件事從來沒發生過一樣！

AI 常犯的錯

AI 非常習慣傳統 C# 的思維，混淆「可變動狀態」的邊界，導致數據沒能成功回滾會把步驟拆開，寫成兩個獨立的 if 塊：

#  AI 錯誤示範：拆成兩個獨立區塊
if (Player.DecreaseCoins[100]):
    # 到這裡第一個存檔點已經結束並提交了！
    if (Player.GainItem[GodSword]): 
        Print("交易成功！")
    else:
        # 這裡失敗了，但金幣已經扣除，STM 無法自動幫你回滾上一個 if！

什麼是效果追蹤系統（Effect Tracking System）？

Verse 為了確保遊戲在大量玩家同時在線時不會卡頓或出錯，強制要求每個函數都要標注它會帶來什麼「副作用（Effect）」。這就像是給函數貼上安全標籤。

最常見的兩個標籤是：

  • <decides>：代表這個函數內部有可能會失敗。

  • <suspends>：代表這個函數是一個異步（Async）協程，它可以中途「暫停」（例如等待 3 秒再繼續執行），而不會把整個遊戲畫面凍結。

    AI 常犯的錯

    **普通函數裡用時間暫停，或忘了標記，**AI 想要寫一個「受傷後等待 2 秒補血」的功能，它可能會寫：

# 這樣寫會報錯！因為 Sleep 函數會「掛起」時間，但這個函數沒有標記 <suspends>
HealPlayer() : void =
    Sleep(2.0) 
    Print("補血！")

正確的 Verse 寫法

只要函數內部有用到了會暫停時間、或者可能失敗的操作，函數名稱後面就必須嚴格加上標籤：

# 正確：加上 <suspends> 告訴引擎這是一個可以跨越時間運作的異步函數
HealPlayer() <suspends> : void =
    Sleep(2.0) # 現在可以安全地暫停 2 秒了
    Print("補血！")

縮進（Indent）與大括號 {} 的雙軌制

Verse 為了同時照顧到喜歡 Python（用縮進排版）和喜歡 C++/C#（用大括號）的開發者，它同時支援兩種語法結構！

可以寫純縮進的程式碼：

if (PlayerScore > 100):
    Print("你贏了！")
    SpawnPrize()

也可以寫帶大括號的程式碼：

if (PlayerScore > 100)
{
    Print("你贏了！");
    SpawnPrize();
}

AI 的「縮進幻覺」

雙重支援的規則，影響AI 生成的一致性 。當程式碼嵌套很多層（例如：如果玩家在區域內、且按了按鈕、且金幣足夠...），AI 寫著寫著就會大腦錯亂。它會在同一個檔案、甚至同一個函數裡，前半段用縮進，後半段突然冒出大括號，或者縮進的空格數（2個空格變4個空格）對不齊，導致 Verse 語法解析器完全看不懂。

什麼是「異步協作與時序黑盒」？

在遊戲裡，很多事情是「同時發生」且「互相競爭」的。

例如：

  • 狀況 A： 玩家正在倒數 5 秒傳送。

  • 狀況 B： 在第 3 秒時，玩家被敵人打死了。

    這時候，傳送應該要被立刻取消，對吧？Verse 內建了非常強大的時間管理語法（像是 race），可以讓多個時間線互相比賽。

    AI 的「時序」幻覺

    AI 雖然知道語法怎麼寫，但它沒有真正的「時間感」。它不知道遊戲引擎每一幀（Tick，大約 1/60 秒）是怎麼運作的，所以它寫出來的多任務程式碼，容易發生「死鎖（兩邊互相等待，程式卡死）」或者「邏輯洩漏（人都死了，2 秒後居然還原地復活）」。

    正確的 Verse 使用 race 語法

    race 的意思是「看誰先跑完，贏的人留下，輸的人腳本立刻被引擎強制中斷」。

# 讓「等待傳送」和「等待死亡」兩條時間線比賽
race:
    block:
        Sleep(5.0) # 跑 5 秒
        TeleportPlayer()
        Print("傳送成功！")
    block:
        Player.DeathEvent.Await() # 隨時等待死亡事件觸發
        Print("玩家在傳送前死掉了，傳送取消！")

在這個機制下，如果玩家在第 3 秒死掉，第二個 block 贏了。Verse 引擎會非常精準且強硬地把第一個 block（還剩 2 秒的傳送）直接抹除。

這些問題不能在prompt 裡明確提出改善嗎

可以，但效果有其極限，這也是為什麼它被稱為「困境」。

在 系統提示詞（System Prompt）裡明確加入規則，在軟體工程上被稱為「提示詞約束（Prompt Constraints）」。雖然這樣能擋掉大約 70% ~ 80% 的低級錯誤，但 AI 還是會頻繁「違規」，主要有以下三個深層原因：

  1. 記憶力與硬性指令的上限（Attention Decay）

    主流的大型語言模型，雖然擁有很大的上下文視窗（Context Window），可以吃下幾萬字的資料，但它們在單次推理時能「嚴格遵守」的硬性指令上限大約只有 150 到 200 條。

    • 當你把 Verse 的所有嚴格語法（不能在 if 外用 []、異步要加 <suspends>、不能混用大括號）通通寫進 Prompt 時，就已經佔滿了 AI 的注意力。

    • 這會導致「顧此失彼」：AI 專注於檢查方括號時，可能轉頭就忘了縮進，或者在處理複雜的遊戲邏輯時，把這些語法規則拋到腦後。

  2. 訓練樣本的「基因缺陷」（Data Scarcity）

    AI 的底層邏輯是「機率模型」。它在預訓練階段看過數以億計的 C++、C#、Python 代碼，但看過的 Verse 代碼可能只有萬分之一。

    • 肌肉記憶太強： 當 AI 寫到多層嵌套或陣列存取時，它的「直覺（機率權重）」會瘋狂灌輸 C# 或 Python 的寫法給它。

    • 即使你在 Prompt 裡寫了「請用[]取值 與 if 處理可失敗運算」，但在生成複雜邏輯的瞬間，AI 常常會抵擋不住幾億條傳統代碼的「肌肉記憶」，慣性地寫出圓括號 ()。

  3. 缺乏即時的「編譯回饋」

    常規的 Prompt 是一次性的（Static Generation）。AI 在吐出代碼的那個當下，它其實不知道這段代碼能不能跑，它只是在猜下一個字是什麼。

    • Verse 的效果追蹤系統（Effect Tracking）是鏈條式的（例如：A 函數呼叫了帶 <suspends> 的 B 函數，A 函數自己也必須標記 <suspends>）。

    • 這種鏈條關係在代碼變多、架構變複雜時，AI 沒辦法在「大腦」裡模擬出完整的編譯器檢查。

目前工程上變通優化方案

只靠 Prompt 無法做到 100% 完美，目前的專業開發團隊通常會結合工具鏈來補強：

  1. 否定性約束（微調 Prompt）： 在 Prompt 裡，「不要做什麼」的效果遠好於「要做什麼」。

    • 正向描述：「請記得在可能失敗的地方使用方括號。」

    • 否定描述：「絕對不要在失敗上下文之外對可失敗變數進行普通賦值。」

  2. 搭配 編譯器驅動的 AI 工具, 建立Harness Engineering：

    • 例如使用 VS Code 的 Verse 專用插件（如 Versly），這種工具不是只靠 Prompt，而是會在 UEFN 編譯器報錯時，自動抓取錯誤日誌丟回給 AI 靜默修復。讓 AI 透過「寫錯 -> 被編譯器打臉 -> 馬上修正」的閉環來解決問題。

從語法模仿到邏輯深化：「環境反饋」會是官方給 AI 的終極解方嗎？

從客觀的工程實踐來看，現階段 AI 掌握 Verse 確實正經歷一段尷尬的「陣痛期」。社群普遍的懷疑並非憑空而來——在現行的機率模型下，AI 想要在短時間內洗掉海量傳統語言（如 C#、Python）灌輸給它的「肌肉記憶」與「基因缺陷」，確實存在結構性的困難。

Epic Games 當初提前公布 Verse 的商業決策，背後無疑是出於對未來元宇宙生態的「超前部署」與好意。他們深知傳統語言在萬人並發、數據安全上的極限，才大膽推出了具備 STM 與效果追蹤系統的 Verse。然而，這種技術上的超前，卻因為「工具鏈與 AI 輔助尚未完全到位」的速度差，在社群中意外觸發了嚴重的生存焦慮。Epic 遞出了一把未來的硬核武器，卻還沒來得及幫創作者裝上好用的 AI 瞄準鏡。

但這堵技術高牆，也絕非遙不可及。

正如我們在「語法泛化能力」與「潛在概念遷移」的研究中所見，AI 的底層早就在無數傳統代碼的洗禮下，建立了一套抽象的邏輯世界。它目前之所以在 Verse 裡頻繁翻車，現階段可歸納於：它只是在模仿皮毛，尚未真正「內化」Verse 更為核心、且顛覆傳統的底層設計機制。

幸好，官方目前的解題思路顯然也意識到了這個斷層，正朝向深度整合「引擎即時反饋」與「優化原生 AI 助手」的方向全速前進。當 AI 盲猜的代碼能直接被編譯器糾正，並在底層默默完成動態修正時，Verse + AI 或許能成倍社群接受的方案。

至於這場人機協作的陣痛期還會持續多久？Epic 能否完美兌現這個 AI 整合的藍圖？這一切的成效如何，終究得交由時間與社群的真實體驗來證明。

如果你喜歡或是這樣的內容對你有幫助的話，可以訂閱「YJ 遊戲技術站」，即時收到每周的電子報與長文。或是追蹤FB專頁，你的追蹤是我持續撰寫的最大動力。