WorldX：把一句话交给四个模型角色，换回一个能自己演下去的世界
One sentence creates an AI-driven world — generate maps, characters, and watch stories emerge on their own. 一句话生成一个AI自主驱动的世界.
秒懂
- 它是什么？
- WorldX 是一个 TypeScript 项目，用编排、绘图、视觉审查、模拟四个模型角色把一句自然语言描述变成可运行的像素世界。它的价值在架构分工，风险也在架构分工。
- 适合谁用？
- WorldX 适合想研究多智能体叙事、并且愿意自己承担模型调用成本与调试成本的开发者，也适合把它当作 Phaser 加 LLM 的参考实现来读代码。它不适合想开箱即用做商业产品的人：项目自述处于 Alpha 阶段，没有发布过 release，没有 Homepage，README 里的代理章节被截断，说明网络与供应商差异这类实际坑还没整理完。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 14 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
一句话到像素地图之间，站着四个不同的模型角色
多数生成式项目的做法是把所有请求丢给一个模型，靠提示词切换任务。WorldX 没有这么做。README 把模型分成四个角色，每个角色有独立的环境变量前缀：ORCHESTRATOR_ 负责设计世界结构、角色和规则，IMAGE_GEN_ 负责生成地图美术与角色立绘，VISION_ 负责审查地图质量并定位区域与元素，SIMULATION_ 负责驱动运行时的角色行为。
这个分工本身就是项目最重要的设计判断。世界生成是一次性的重活，需要强推理模型；角色行为是持续发生的高频调用，需要便宜模型。README 在推荐模型一栏里写得很直白：编排引擎用较强推理模型如 gemini-3.1-pro-preview，世界驱动用任意模型，便宜的就行，如 gemini-2.5-flash。把这两类负载拆成两组配置，意味着你可以在不牺牲世界质量的前提下压低运行成本。
代价是配置复杂度。四个角色各自需要 BASE_URL、API_KEY、MODEL 三个变量，一共十二行，再加上绘图模型独有的 IMAGE_GEN_PROVIDER。README 提供了 OpenRouter 一把梭、Google AI Studio 免费额度、以及混合搭配三套示例，其中混合搭配那套把世界设计放在 Google AI Studio、把模拟运行放在 DeepSeek，正是这个架构允许的用法。
VISION_ 这个角色暴露了项目的真实难点
四个角色里，绘图审查是最容易被忽略也最能说明问题的一个。VISION_ 的用途是审查地图质量、定位区域与元素，推荐多模态模型。换句话说，WorldX 不假设文生图模型一次就能画出可用的地图，它在流程里插了一个独立的检查环节，用另一个模型去看图并给出区域坐标。
这解释了为什么 README 在平台配置示例下面专门加了一段模型选择建议：图像生成模型建议使用 nano banana2（gemini-3.1-flash-image），并直言 gpt-image-2 在指令遵循上依然有欠缺，虽然画风显著比 nb2 好看，但在本项目中容易导致各类问题、影响最终效果。这是一个相当具体的工程结论，比任何泛泛的模型推荐都有用。它同时暗示了一个约束：画风好看的模型未必能画出结构正确的地图，而 WorldX 的后续流程依赖地图结构正确。
反过来说，这也是项目对模型供应商依赖最深的地方。VISION_ 需要多模态能力，IMAGE_GEN_ 需要文生图能力，两者都不是随便换个兼容 chat/completions 的端点就能替代的。README 提到除绘图模型支持 Google AI Studio 原生图片接口外，其余角色均采用 OpenAI 兼容协议，这句话的另一面是绘图模型存在协议分叉，IMAGE_GEN_PROVIDER 要在 openai-compatible 和 google-native 之间选。
从 npm install 到看到世界，需要填对哪些键
README 给了两条路径。快速运行那条针对只想看效果的人：克隆仓库、复制 .env.example 为 .env、只填 SIMULATION_ 三行、执行 npm install 和 npm run dev，然后打开 http://localhost:3200 选一个内置世界点播放。项目内置了两个预生成的世界，所以不需要配齐全部模型就能跑起来。
完整创建那条针对想自己造世界的人：填全部四组模型配置，执行 npm run dev，打开 http://localhost:3200/create 输入一句话。README 也提供了等价的命令行入口，npm run create 后面直接跟描述文本，示例是「赛博朋克风格的深夜拉面馆，黑客和仿生人在这里交换情报」。
环境变量的命名规则是 {ROLE}_BASE_URL、{ROLE}_API_KEY、{ROLE}_MODEL，其中 ROLE 取 ORCHESTRATOR、IMAGE_GEN、VISION、SIMULATION 之一。绘图模型额外支持 IMAGE_GEN_PROVIDER，默认值是 openai-compatible，适合 OpenRouter；换成 google-native 则对应 Google AI Studio 的图片生成接口。README 还留了一节代理问题，但内容在提供的材料里被截断，只剩一句建议，具体怎么配代理无法从现有材料确认。
Node 版本有一个窄区间，越界就跑不起来
前置条件里关于 Node.js 的说明值得单独拎出来，因为它不是常见的「建议 18 以上」那种宽松表述。README 写明需要 Node.js 22.13+，推荐 24 LTS，理由是数据库使用 Node 内置的 node:sqlite，安装依赖无需编译任何原生模块。
紧接着是一句更关键的话：完整可用区间是 >=22.13 <23 || >=23.4。22.5 到 22.12、以及 23.0 到 23.3 都不可用，因为那期间 node:sqlite 仍在 --experimental-sqlite 标志之后。这是一个精确到小版本的边界，意味着如果你的环境固定在 Node 23.2，WorldX 装不上，而且报错原因跟项目代码无关，纯粹是运行时能力缺失。
这个设计选择本身是加分项：不编译原生模块意味着 npm install 不会因为本地缺少编译工具链而失败，这在容器和 CI 里省事。代价是把兼容性押在了 Node 的版本节奏上，而 node:sqlite 从实验标志后移出的时间点决定了这个区间只能这么窄。
上帝模式与时间线：可介入性带来的状态管理问题
README 的特性列表里有两项在同类项目里不常见。一项是上帝模式，允许广播事件、编辑角色人设与记忆、与角色开展架空对话。另一项是时间线系统，同一个世界可以孕育多个不同时间线。
把这两项放在一起看，能看出 WorldX 对状态的态度：世界状态不是只读的模拟结果，而是可以被外部写入的对象。角色记忆和人格都能被编辑，意味着模拟循环每一轮都要从一份可被修改的状态里读取角色定义。架空对话则是绕过模拟循环、直接与某个角色交互的旁路。
这类设计的功能上限很高，但状态一致性得靠实现来保证。README 没有说明编辑记忆后正在进行的对话如何收敛，也没有说明多条时间线是共享底层世界还是各自独立存储。提供的材料里没有架构文档，这些只能从代码里读。对于想评估长期维护成本的读者，这是需要自己去仓库确认的部分，不能靠 README 判断。
Alpha 阶段意味着什么：没有 release，只有 main 分支
仓库信息显示默认分支是 main，最近一次 push 在 2026-09-01，没有检索到任何 release，没有 Homepage，未归档。README 自己标了 Status: Alpha 的徽章，并在正文里写「项目当前处于 Alpha 阶段，核心可用，持续优化中」。
这几条信息组合起来，对采用决策的影响比任何功能描述都大。没有 release 意味着没有版本化的稳定点，你 clone 到的就是当时的 main，升级只能整体跟进，没有 changelog 可以判断哪次改动会影响你。没有 Homepage 意味着文档入口就是仓库本身。
另一个实际影响是模型标识的时效性。README 里出现的 gemini-3.1-pro-preview、gemini-3.1-flash-image-preview、gemini-2.5-flash-preview 都带 preview 后缀，这类标识在供应商侧随时可能变更或下线。项目没有 release 也就没有地方记录「哪个版本配哪个模型标识验证过」，升级时你得自己重新验证一遍四组配置。
自建多智能体模拟与直接调用引擎的差别
如果目标只是让 LLM 驱动的角色在一个场景里互动，另一条路是用通用游戏引擎或自研循环，把角色决策直接接到一次 chat/completions 调用上，地图和美术另外找人做或手工做。这条路的差别在于：地图生成、视觉审查、世界结构设计这三块都要你自己处理，换来的是对每一环的完全控制。
WorldX 的取舍相反。它把「一句话到可运行世界」这条链路做成了默认路径，用 ORCHESTRATOR_ 产出结构、用 IMAGE_GEN_ 产出美术、用 VISION_ 校验地图，代价是你必须接受这条链路对模型的假设：编排需要强推理，绘图需要特定文生图模型，审查需要多模态。任何一环换成能力不足的模型，README 暗示的结果是「容易导致各类问题、影响最终效果」。
选择依据因此很清晰。如果你的场景固定、地图可以预先做好、只需要角色行为这一层，WorldX 的生成链路对你是多余的开销，直接写模拟循环更省事。如果你的需求恰恰是「用户输入一句话就要出一个新世界」，自己从零搭这条链路的工程量远大于配四组环境变量。
MIT 许可与模型账单是两笔独立的账
WorldX 采用 MIT 许可，仓库根目录有 LICENSE 文件。MIT 是宽松许可，允许修改和再分发，具体条款以 LICENSE 原文为准，这里不构成法律意见。需要注意的是，代码的许可与模型输出的许可是两回事：世界内容由你配置的模型供应商生成，那些内容受各自服务条款约束，MIT 只覆盖 WorldX 本身的代码。
运行成本方面，README 的架构描述已经给出了控制点。SIMULATION_ 是唯一在运行时按角色行为持续调用的角色，README 明确建议这一组用便宜模型，并在混合搭配示例里用 DeepSeek 承担。ORCHESTRATOR_、IMAGE_GEN_、VISION_ 只在世界创建阶段调用，属于一次性开销，可以用贵的模型。这套分层的意义就是把持续成本压在 SIMULATION_ 上。
维护成本则主要来自前面提到的无 release 状态。升级时没有版本边界可以回退，四组环境变量对应的模型标识又都带 preview 后缀，任何一次 git pull 之后都需要重新确认世界能否正常生成。这不是可以靠流程规避的问题，而是 Alpha 阶段项目的固有属性。
编辑结论
WorldX 适合想研究多智能体叙事、并且愿意自己承担模型调用成本与调试成本的开发者，也适合把它当作 Phaser 加 LLM 的参考实现来读代码。它不适合想开箱即用做商业产品的人：项目自述处于 Alpha 阶段，没有发布过 release，没有 Homepage，README 里的代理章节被截断，说明网络与供应商差异这类实际坑还没整理完。上手前先确认三件事：你的 Node 版本落在 >=22.13 <23 或 >=23.4 区间，否则 node:sqlite 不可用；IMAGE_GEN_MODEL 是否选了项目推荐的 gemini-3.1-flash-image-preview 一类模型，README 明确说 gpt-image-2 在指令遵循上容易出问题；以及 SIMULATION_ 这一组是否配了便宜模型，因为它是唯一按角色行为高频调用的角色。三件事都过了，再跑 npm run create。
社区笔记