WorldX：用一句話生成世界，代價是四個模型角色同時上線
One sentence creates an AI-driven world — generate maps, characters, and watch stories emerge on their own. 一句话生成一个AI自主驱动的世界.
秒懂
- 它是什麼？
- WorldX 把「一句話生成世界」拆成編排、繪圖、視覺審查、世界驅動四組模型呼叫，用 Phaser 3 前端呈現像素地圖與自主 Agent。它的門檻不在程式碼，在模型配置與 Node 版本。
- 適合誰用？
- WorldX 適合已經有至少一組可用 LLM API Key、想觀察多 Agent 湧現行為、且能接受 Alpha 階段介面變動的開發者；只想跑一個現成遊戲、或不想為四個模型角色分別處理配額與費用的讀者應該先跳過。動手前先確認 Node 版本落在 >=22.13 <23 或 >=23.4，因為 22.5 到 22.12 之間 node:sqlite 還在 --experimental-sqlite 標誌後面，裝了也跑不起來；接著只填 SIMULATION_ 三行跑內建世界，確認整條鏈路通了再補齊 ORCHESTRATOR_、IMAGE_GEN_、VISION_。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 15 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
一句話到一個世界，中間隔著四組 API Key
WorldX 想解決的問題很具體：把「北宋汴京的夜市街，有算命的、當鋪掌柜、小偷、捕快，還有一個穿越來的現代人」這類場景描述，變成一個能持續跑下去、角色會自己動起來的模擬環境。README 對這件事的定位是「AI 角色們會在這個世界里自主生活：他們做決策、與場景交互、建立關係、開展對話、記憶並思考」。
目標讀者不是玩家，是願意調模型參數的人。README 在快速開始裡直接分成兩條路徑：方式 A 只填 SIMULATION_ 三行環境變數，跑專案內建的兩個預生成世界；方式 B 才需要配齊全部四組模型，從零生成自己的世界。這個切分本身就是一個判斷：作者知道完整流程的配置負擔不輕，所以先給一條只驗證執行時期的短路徑。
如果你的目的是「我想看看生成式 Agent 跑起來長什麼樣」，方式 A 就夠了。如果你要的是「我要一句話生出自己的地圖和角色」，那你要準備的是四個模型角色的額度，而不是一份程式碼。
編排、繪圖、審查、驅動：四個模型角色各管一段
WorldX 把 LLM 呼叫拆成四個獨立角色，每個角色有自己的環境變數前綴、自己的 BASE_URL 和自己的 MODEL。這是整個專案最值得看的設計決定。
ORCHESTRATOR_ 負責設計世界結構、角色與規則，README 建議用推理較強的模型。IMAGE_GEN_ 負責生成地圖美術與角色立繪，是四個角色裡唯一不強制走 OpenAI 相容協議的一個，可以透過 IMAGE_GEN_PROVIDER 切換成 google-native，直接打 Google AI Studio 的原生圖片介面。VISION_ 負責審查地圖品質、定位區域與元素，需要多模態模型。SIMULATION_ 驅動執行時的角色行為，README 對它的建議是「任意模型，便宜的就行」。
拆成四個角色的好處是成本可以分層：世界生成是一次性的，可以用貴的模型；角色行為是每回合都在呼叫的，用便宜模型壓成本。README 的混合搭配範例就是這個思路，用 Google AI Studio 免費額度做設計與美術，用 DeepSeek 跑模擬。代價是配置面積變成四倍，任何一個角色的 BASE_URL 或 MODEL 寫錯，症狀不會是啟動失敗，而是世界生成到一半卡住或美術品質崩掉，除錯時你得先判斷是哪一層出的問題。
值得注意的是 IMAGE_GEN_ 與 VISION_ 之間存在一條回饋鏈：繪圖模型出圖，視覺模型審查並定位區域與元素。README 沒有說明這條鏈是否會重試、重試幾次、失敗後如何降級，這一塊是文件最薄的地方。
Node 版本是硬門檻，不是建議值
WorldX 用 Node 內建的 SQLite（node:sqlite）做資料庫，因此安裝依賴時不需要編譯任何原生模組。這是選型的優點，但也把 Node 版本變成硬性約束。
README 寫得很明確：完整可用區間是 >=22.13 <23 或 >=23.4，推薦 24 LTS。22.5 到 22.12 以及 23.0 到 23.3 不可用，因為那段期間 node:sqlite 仍在 --experimental-sqlite 標誌後面。這意味著如果你的環境被固定在 Node 22.10 之類的版本上，你不是「可能會有小問題」，而是直接跑不起來。
啟動流程本身很短：
git clone https://github.com/YGYOOO/WorldX.git cd WorldX cp .env.example .env npm install npm run dev
服務跑在 http://localhost:3200，建立世界的頁面在 http://localhost:3200/create。除了網頁介面，也提供命令列入口：npm run create -- "賽博朋克風格的深夜拉麵館，黑客和仿生人在這裡交換情報"。命令列入口對自動化或批次生成場景比較實用，因為它繞過了前端互動。
README 在結尾提到代理問題，原文在此處被截斷，只留下「注意：建議在你的」幾個字。如果你的網路環境需要代理才能連到 OpenRouter 或 Google AI Studio，這一段的內容需要直接去看倉庫裡的完整 README，不要靠推測。
上帝模式與時間線：可介入性帶來的狀態管理問題
WorldX 的差異化在於它不滿足於讓模擬自己跑。README 列出兩個機制：上帝模式與時間線系統。
上帝模式允許你廣播事件、編輯角色的人設與記憶、以及與任意角色展開一場架空對話。時間線系統則允許同一個世界孕育多個不同時間線。這兩者合起來意味著世界狀態不是單一線性的，而是可以被外部注入修改、被分支的。
從工程角度看，這是比生成地圖更難的部分。角色記憶被編輯之後，後續行為如何與被改寫的記憶保持一致；多條時間線之間是否共享角色狀態、是否共享地圖，README 都沒有交代。它只說了「同一個世界也可孕育多個不同時間線」，沒有說時間線的儲存結構或切換成本。
如果你打算把 WorldX 當成研究多 Agent 記憶一致性的平台，這一塊需要先讀原始碼而不是讀 README。如果你只是要一個能跑、能看、能介入的沙盒，現有的上帝模式介面已經覆蓋了主要操作。
圖像模型的選擇會直接決定專案能不能用
README 在平台配置範例裡放了一句不常見的直白建議：圖像生成模型建議使用 nano banana2（gemini-3.1-flash-image），並且明確說 gpt-image-2「在指令遵循上依然有欠缺（雖然畫風顯著比 nb2 好看），在本項目中容易導致各類問題、影響最終效果」。
這句話值得單獨拿出來看，因為它揭示了 WorldX 對圖像模型的真實要求：不是畫得好看，是指令遵循要準。原因在於 IMAGE_GEN_ 的輸出不是給人看的插圖，是要被 VISION_ 審查、被定位區域與元素、最後對應到 Phaser 3 前端上的像素地圖與角色立繪。畫風再漂亮，只要地圖元素位置和編排引擎的設計對不上，下游就接不起來。
這是一個容易被低估的採用成本。你在選模型時，評測標準不該是出圖美感，而是它能否穩定產出符合結構要求的地圖。README 只給了一個建議型號，沒有給出替代方案清單或失敗案例的具體描述，所以最終還是得自己拿幾組提示詞試。
它不適合誰：想要開箱即用遊戲的人
WorldX 的 README 自己標註了 Status: Alpha，並寫著「項目當前處於 Alpha 階段，核心可用，持續優化中」。倉庫沒有檢索到任何 release，這意味著沒有版本化的發布節點可以鎖定，你拉到的 main 分支就是你能拿到的全部。
如果你的期待是「clone 下來、填一個 Key、得到一個能玩的遊戲」，WorldX 不是這個東西。它的前端是 React 19 加 Phaser 3，呈現的是像素風地圖與角色對話側欄，但整個系統的價值在於生成與模擬，不在於遊戲性。
另一個不適合的場景是把它當成穩定的後端服務。四個模型角色意味著四個外部依賴，任何一個供應商限流或回應格式變動，都會直接影響世界生成或模擬推進。README 沒有描述重試策略、逾時設定或降級行為。
如果你要的是一個成熟、有版本、有 SLA 的生成式 Agent 框架，WorldX 現階段給不了。如果你要的是一個可以讀、可以改、可以觀察多 Agent 行為的 TypeScript 專案，它的架構透明度反而是優點。
授權與維護：MIT 之下的實際成本在 API 帳單
WorldX 採用 MIT 授權，README 頂部有對應的 License 徽章，倉庫根目錄有 LICENSE 檔案。MIT 對商用與修改都相對寬鬆，具體條款仍應以 LICENSE 原文為準，這裡不構成法律意見。
需要留意的是，MIT 只覆蓋這個倉庫裡的程式碼。你透過 ORCHESTRATOR_、IMAGE_GEN_、VISION_、SIMULATION_ 呼叫的模型服務，各自受其供應商的條款約束；生成出來的內容是否可以商用、是否有使用限制，取決於那些服務的條款，不是 MIT。
維護成本的主要來源不是升級程式碼，是模型配置。README 的建議型號帶有 preview 字樣（例如 gemini-3.1-pro-preview、gemini-3.1-flash-image-preview），這類模型標識會隨供應商調整而失效，屆時你需要改的是 .env 裡的 MODEL 欄位而不是程式。四個角色共用同一個 .env，任何一次模型更換都要確認對應角色的協議是否仍然相容，特別是 IMAGE_GEN_PROVIDER 在 openai-compatible 與 google-native 之間切換時。
倉庫最後推送時間為 2026-09-01，沒有發布任何 release，因此沒有版本升級路徑可言，只能追 main 分支。對需要可重現建置的團隊來說，這代表你得自己 fork 或鎖定 commit。
編輯結論
WorldX 適合已經有至少一組可用 LLM API Key、想觀察多 Agent 湧現行為、且能接受 Alpha 階段介面變動的開發者；只想跑一個現成遊戲、或不想為四個模型角色分別處理配額與費用的讀者應該先跳過。動手前先確認 Node 版本落在 >=22.13 <23 或 >=23.4，因為 22.5 到 22.12 之間 node:sqlite 還在 --experimental-sqlite 標誌後面，裝了也跑不起來；接著只填 SIMULATION_ 三行跑內建世界，確認整條鏈路通了再補齊 ORCHESTRATOR_、IMAGE_GEN_、VISION_。
社群筆記