本文成文于 2026-11-04。信息来自三条研究通道：①arXiv 论文 HTML 全文（2610.33106v1）逐节精读，含全部五张数据表的原始数值；②GitHub 仓库 tettethu/VibeGame main 分支的目录结构与关键源文件（8 个智能体角色定义、构建工作流 skill、自进化 skill、骨架目录）的实读；③README、项目主页与 News 区的交叉核对。文中所有论文数据均来自我实际抓取的 HTML 表格，所有源码级论断均来自实际读取的文件内容；凡属推断处均显式标注。该项目迭代较快（截稿时 363 star / 24 commits），引用前请自行复核。

一、VibeGame 是什么：一句话与关键事实

VibeGame 的官方口号是 “Vibe Your Dream Game”1：用户用自然语言描述一个游戏想法（可选附一张参考图），一个八角色的 AI 智能体团队在 AI 原生引擎上把它建成可玩、可继续编辑的完整 2D 网页游戏。它于 2026 年 8 月首次发布，10 月 22 日在 arXiv 挂出论文《VibeGame: Prompt-to-Game Development with AI-Native Engine and Self-Evolving Adversarial Agent Team》（cs.MA）2，作者单位为南京大学 PRLab、南洋理工大学 S-Lab 与 Liblib.ai，通讯作者陈阳思（南京大学）3。代码 Apache-2.0 开源（附一条非约束性的商业部署邮件登记请求）1。

先给关键事实的全景表：

维度 内容
定位 提示词 → 完整可玩 2D 网页游戏的开源多智能体框架
三大支柱 AI 原生游戏引擎 + 八智能体对抗团队（AAT）+ 免训练自进化
依赖 Python ≥3.12、uv、tmux、Claude Code 或 Codex 任一 agent CLI（无需 Node.js/npm）1
引擎 Phaser 宿主的 2D 引擎，项目状态为 schema 验证的结构化文本，帧同步运行时控制 21
界面 Web Dashboard 四面板：Chat / Assets / Objects / Play 1
评测 GameCraft-Bench 子集 30 任务（15 游戏类型 × 2）：GPT-6.1-Sol 下 Overall 72.99，领先最强基线 Codex(P2G) 4.19 分；人类盲评平均胜率 72.7% 3
开销 未披露 token 成本；八智能体多轮循环 + opus 档模型的组合，开销显著高于单 agent（推断）
路线图 Godot、Unity 支持，2D → 端到端 3D 1

仓库演示过的原型包括：文明原型、空洞骑士 Boss 切片、街机格斗、地牢 Roguelike、水果忍者、跑酷、像素只狼、AI 狼人杀派对游戏1。这个清单本身就划定了它的能力形状——“切片与原型级”的 2D 游戏，而非完整商业作品。

二、原理：三大支柱如何咬合

论文的核心论点是：把 LLM agent 从”辅助写软件”推进到”独立做游戏”，卡点不在代码生成本身，而在三件事——游戏需要协调代码、场景、资产、动画、物理、配置这类异质工件；需要交互式测试验证它们组合后真的能玩；需要分工与审查避免单 agent 自写自验的自我盲区23。VibeGame 的三个支柱分别对准这三个卡点。

2.1 支柱一：AI 原生游戏引擎——”项目状态 = schema 验证的结构化文本”

传统游戏引擎（Unity/Godot/Unreal）的人机接口是 GUI 编辑器，文件格式是二进制场景或复杂序列化——这对 LLM 是灾难：不可读、不可 diff、不可靠 grep 定位。VibeGame 的做法是把引擎”AI 原生化”：

  1. 结构化文本表示。游戏的一切——场景结构、节点属性、精灵清单、动画剪辑、碰撞体、UI、调参配置——都是引擎读取的 JSON/文本（scene JSON、node JSON、manifest 元数据、config）24。智能体读写这些文本就等于”操作引擎”，git diff、grep、代码审查全部照常工作。
  2. 帧同步运行时控制。引擎暴露 Runtime API：智能体可以注入输入、逐帧推进、快照状态、截图，按自己的节奏检查游戏行为，而不是像人类一样只能实时游玩23。这是整个框架里我认为最关键的一块积木——它把”游戏能不能玩”从人类的模糊手感变成了智能体可断言、可存证的数据。
  3. 引擎即上下文。初始化时引擎的完整未编译源码被拷贝进项目目录，智能体随时可查确切 API、假设与实现细节3。源码里能看到对应的运行时家族：RuntimeClock.js、RuntimeController.js、RuntimeBridge.js、SceneTree.js、AnimationPlayer.js、ColliderFactory.js、InputMap.js、UiLayer.js 等——Phaser 承担渲染宿主（PhaserHost.js），但项目状态的唯一真相是结构化文本层5。

这套设计有一个明确的纪律约束，写死在自进化流程里：”引擎能表达的运行时事实必须留在引擎拥有的声明里“——缩放、偏移、轴点、碰撞体尺寸等不得在脚本里命令式地绕过引擎设置；无解释的硬编码数值（手感、物理、生成时机、UI 摆位）必须进配置4。这不是洁癖：只有把”事实”收敛到引擎可校验的声明层，vibegame check 的静态校验和自进化蒸馏才有可靠的抓取面。

消融数据证明这块积木的分量：去掉引擎，Overall 从 53.45 跌到 43.12（-10.33 分），是三个组件中贡献最大的3。而且引擎是可移植的——把同一个引擎接到裸 Codex 上（PA2G、全部 30 任务、GPT-6.1-Sol），Overall 从 64.44 升到 67.13（+2.69），最大增益恰在 Content Depth（+3.95），论文将此归因于”结构化项目表示帮助智能体扩展游戏内容”3。

2.2 支柱二：八智能体对抗团队（AAT）——实现与审查的对抗分离

仓库源码中实际存在八个角色定义567891011，对照论文”八个专职智能体”的表述2，构成一条清晰的流水线：

角色 模型档位 职责 生命周期
orchestrator（lead） — 拥有产品意图：从 GDD 切片生成 PRD、拆任务、路由、评审 plan、验收、面向用户交付 会话常驻
designer opus 撰写并维护 GDD.md；设计机制、系统、内容、UI 约定、关卡/Boss 构成；注入 MDA、动机、公平性等设计理论与模式库 常驻
artist opus 生成与后处理视觉资产、注册 manifest.json；强制”最终可出货质量”契约，禁止占位方块与程序化涂鸦充当最终资产 常驻
architect opus 单任务技术计划 plan.md + 每任务上下文配置（context.json）；不得发明产品行为，一切须可追溯至 PRD 按任务
programmer sonnet 在批准的任务契约内改代码，交付前自验；契约有错须上报而非即兴发挥 按任务
auditor sonnet 静态质量门：对照 PRD/plan 审代码、跑 vibegame check、做安全局部修复；不跑游戏 按任务
player sonnet 运行时验证：Runtime API 注入输入、推进帧、快照状态、截图、用 vibegame vlm 微调视觉数值；不读代码下结论 按任务
reviewer sonnet 最终质量门：以挑剔 QA 的姿态做一次完整终审，三维递进 Functionality → Visual Quality → Playability 按目标

三个设计细节值得展开，它们是这套团队真正区别于”一个 agent 拆成八个名字”的地方：

第一，auditor/player 的切分不是按”测试种类”而是按”证据获取成本”。auditor.md 里有一段罕见的坦诚论证：跑游戏会从同一会话里同时产出状态数据和截图，如果把”逻辑运行时”和”视觉运行时”拆给两个 agent，它们得各自启动运行时、重放相同输入、重复收集证据；而”静态审查”和”运行时审查”之间不共享任何机制，在那里切分是零成本的89。边界原则被写成一句话：”凡读代码、diff、规格和 vibegame check 输出能验证的归 auditor；凡需要游戏真跑起来才能回答的归 player”89。

第二，对抗性靠的是生命周期与信息隔离，而不只是”多一轮 review”。designer/artist 常驻（跨任务积累项目语境），architect/programmer/auditor/player 按任务生灭（每个任务拿到干净上下文与独立契约），reviewer 按目标常驻且只在所有任务完成后做一次完整终审——并明确要求”无论 lead 在通知里强调什么，都执行完整检查清单”10。reviewer 独立于实现四角色，源码里甚至要求它创建 review-lock.json 锁定终审状态10。实现者不知道终审者会怎么挑刺，终审者在任务进行中只了解目标不介入——这是把”作者评自己的稿”这个经典失效模式结构性排除掉了。

第三，产品真相有唯一链路。GDD.md（designer 拥有，全局玩法真相）→ prd.md（orchestrator 拥有，任务切片，禁止发明 GDD 没有的机制）→ plan.md（architect 拥有，技术计划 + 运行时状态契约 + 验证计划）→ 实现 → auditor 校验”PRD/plan → 代码”对齐 → player 校验运行时行为 → reviewer 终审。任何角色发现规格模糊、不可实现或与现实冲突，义务是上报而非补全511。构建工作流里甚至有一条强制的 GDD 保真度校验：把用户原话和 GDD 拼在一起喂给 VLM，让它逐条列出”遗漏、弱化、矛盾”，回复不是 NO DEVIATION 就打回 designer 重写——且明文规定”你自己读一遍 GDD 不能替代这个检查，因为那份 brief 就是你写的”12。这句自我怀疑式的机制设计，是整份源码里对”零信任”原则最生动的落地。

2.3 支柱三：免训练自进化——骨架、模块、协作契约

第三个支柱解决”每次从零开始”的浪费：每个通过验收的项目会被蒸馏成三类可复用先验，注入未来项目，全程不训练任何模型2：

  • 骨架（skeletons）：可运行的占位基线项目。截稿时已有五个子类型骨架：2d-action-boss-fight（空洞骑士/ Cuphead Boss / 2D 只狼式 1v1 切片：竞技场场景、玩家 FSM、Boss FSM、弹幕、FX、HUD）、roguelike-deckbuilder（杀戮尖塔式回合卡牌对战）、roguelike-dungeon-shooter（吸血鬼幸存者/元气骑士式俯视角地牢：程序化房间图、瓦片地图、敌人波次、Boss 房、小地图、升级三选一）、swipe-slice-arcade（水果忍者式划切）、2d-bounce-parkour（Celeste 风格精准踩弹平台跳跃）13。骨架的场景流转、比例、时序、碰撞体、HUD、运行时状态设计成可在替换美术后存活的形态——新项目从”换皮 + 轻改配置”起步。
  • 模块（modules）：11 个可直插的 Node 脚本组件：小地图、视差滚动背景、状态栏、划切、定时图像 VFX、升级三选一、磁吸拾取、遮罩 HUD、DOM 覆盖层、DOM 手牌管理、横版格斗5。构建工作流会先扫描模块目录：”凡是能通过 script: "XxxModule" 直接接线或子类扩展的，团队就不必重做”12。
  • 协作契约（contracts）：把”这类功能该由谁做什么”沉淀成规格文档，内含各角色的责任章节（Architect/Programmer、Player、Reviewer 与 Artist 章节）4。

self-evolve skill 的执行流程本身就是一套小型治理工程4：

  1. 自检先行——项目要先修到”引擎事实归引擎、无未解释硬编码、单节点配置内联”才能被蒸馏，防止把坏习惯固化成先验（”不要记录一个依赖脚本侧越权来弥补引擎参数缺失的骨架”）；
  2. 美术侧并行蒸馏（artist 走 artist-self-evolve skill 产出子类型绑定的 art-pack.md）；
  3. 按三类目的地独立并行搜索候选；
  4. 用户审批门——明文写着”这个门不可协商”（non-negotiable），因为”悄悄提升先验等于为每个未来项目锁定框架默认值”4；
  5. 骨架转换不走手工，而是开正式任务走完整工作流生成并验证；
  6. vibegame check 验证；
  7. CLI 提升且先 dry-run（vibegame evolve skeleton/module/contract -n ... --dry-run，审查复制清单后再实跑；CLI 永不 commit/push，目的地已存在则停下人工裁决）；
  8. 手动更新源索引4。

消融数据：在 10 任务消融集上，”加入 GPT-6.1-Sol 在 5 个集外任务上积累的经验”使 Overall 从 53.45 升至 56.37（+2.92）3。但论文同节坦白了一个反噬现象，我放在第六节细说。

2.4 实证：这套设计到底值多少分

评测协议本身有两点值得注意：四维指标为 Core Mechanics（M）/ Content Depth（D）/ Functional Visuals（V）/ Art & Presentation（A），总分 Overall = BUILD × (w_M·M + w_D·D + w_V·V + w_A·A)——其中 BUILD 是 0/1 门因子，游戏构建不出来或玩不了则直接零分3；打分由 LLM judge 多次通过取均值以降方差，并另用 GPT-5.5 judge 复核整张主表（结论排序不变）3。任务为 GameCraft-Bench 子集 30 个，覆盖 15 种游戏类型各 2 个：卡牌、Roguelike、恐怖、放置、开放世界、平台跳跃、解谜、竞速、节奏、射击、模拟、体育、策略、大亨、视觉小说3。

主结果（我实际抓取的表格数值）3：

Harness 模型 输入设定 M D V A Overall
Qwen Code GPT-5.6-Luna P2G 48.68 34.44 35.51 38.72 38.29
DSH GPT-5.6-Luna PA2G 52.96 36.13 32.40 35.62 37.95
VibeGame GPT-5.6-Luna P2G 58.31 43.15 39.07 57.82 49.99
Codex GPT-6.1-Sol P2G 87.18 63.05 62.48 69.25 68.80
VibeGame GPT-6.1-Sol P2G 86.26 67.81 62.29 76.97 72.99

三个读法：其一，同底模下 VibeGame(P2G) 稳定压过所有基线（含拿着现成资产库的 PA2G 设定）——GPT-5.6-Luna 下领先最强基线 +11.70 分，GPT-6.1-Sol 下领先 Codex(P2G) +4.19 分，且是靠 Art & Presentation（+7.72）和 Content Depth（+4.76）拉开的；其二，总分含 BUILD 门因子（构建不出或玩不了即零分），意味着”稳定可玩”是高分的先决条件——论文虽未披露各基线的 BUILD 失败率，但 VibeGame 的多轮对抗修复机制正是为守住这道门设计的（推断）；其三，人类盲评与 LLM judge 结论一致：VibeGame 对 GPT-6.1-Sol 的每个基线、在全部四个维度上全胜，平均总体人类胜率 72.7%3。

消融（10 任务消融集，GPT-5.6-Luna）3：

变体 Overall 差值
VibeGame 完整版 53.45 —
去掉 AI 原生引擎 43.12 -10.33
去掉对抗审查角色（AAT） 48.82 -4.63
加入自进化经验 56.37 +2.92

一句话总结原理：引擎把”游戏”翻译成智能体可读写可验证的结构化文本；团队把”做游戏”翻译成带对抗审查的分工流水线；自进化把”做过”翻译成下一款的起点。

三、怎么应用：从安装到交付

3.1 安装与启动

前提：Python ≥3.12、uv、tmux、以及 Claude Code 或 Codex 至少其一；不需要 Node.js/npm（Phaser 引擎随 CLI 打包分发）1。两个已知的首次使用坑：Claude Code 侧，VibeGame 以 claude --dangerously-skip-permissions 启动智能体，该旗标的首次同意界面无法在托管会话内完成，必须先在终端手动跑一次并接受；Codex 侧，需先 vibegame setup codex-hooks 写入 hooks，再进 Codex 的 /hooks 手动信任，否则 agent 在跑但永不注册、Dashboard 一直空白1。

标准流程（README 原文）1：

git clone https://github.com/tettethu/VibeGame && cd VibeGame
./setup.sh        # 或直接对 agent 说：Read and follow @docs/SETUP.md

mkdir my-game && cd my-game
vibegame init
vibegame start

端到端建一款游戏，用标准构建工作流发起：

/vibegame-build Build a compact roguelike dungeon with one boss encounter

其余常用命令：vibegame start --project ./my-game "Continue polishing the boss fight" 续跑既有项目、vibegame run --port auto 起服、vibegame close 关闭；开发侧还有 vibegame check（静态校验）、vibegame vlm（视觉验证）、vibegame lead/mate（团队管理）、vibegame evolve（先验提升）154。

3.2 用户侧的真实体验

一个容易被忽略的设计：用户被假定没有终端。orchestrator.md 明文规定”用户只通过你的消息和 Dashboard 的 Play 按钮与项目交互”，每次交付必须是一个自包含的交接包：做了什么 → 可点开的工件链接（绝对路径）→ 如何验证（指到 Dashboard 的哪个面板）→ 操作指南（键位、起点、失败条件、已知问题）→ 需要用户裁决什么5。

交互主要发生在 Web Dashboard 的四个面板1：

  • Chat：与智能体团队对话，发起构建、提改动、追进度；
  • Assets：预览动画、调整精灵边界——这是人工介入美术质量的主入口；
  • Objects：检查/配置游戏实体与角色的动画、属性；
  • Play：一键游玩当前合并构建。

3.3 构建工作流的五个阶段（人类该在哪几处出手）

vibegame-build 把一次完整开发组织为两阶段，人类有三个必须出手的关口12：

  1. Plan 阶段：orchestrator 并行探索代码库、模块目录、骨架目录；涉及玩法则派 designer 补设计层并更新 GDD（过 VLM 保真度校验）；涉及视觉且用户没给参考图，则派 artist 先产一张”实际游戏内观感“的项目参考图（明确不是概念图/情绪板/海报），迭代到你批准为止；然后划分宏观阶段与可并行的独立任务，写明每阶段的完成状态与测法。关口一：任务拆解必须交用户审批后才执行——合并/拆分/砍任务是你的决定权12。
  2. Run 阶段：spawn 常驻 reviewer；每个阶段内并行 spawn 无依赖的 programmer 任务（用 --blocked-by 声明依赖），每个任务走 architect → programmer → auditor → player 流水线。两种典型阶段模板：可玩垂直切片与美术包并行、随后视觉整合与终审；或接口先行、多系统全并行、再集成调手感12。
  3. 终审与自进化：全部任务完成后 reviewer 做一次完整三维终审；项目验收后可显式发起 self-evolve，把本作蒸馏为骨架/模块/契约——哪些先验入库同样要过用户审批门124。

换句话说，这套框架把人类的位置从”敲代码/画图的人”挪到了三道裁决席：参考图批准、任务拆解批准、先验入库批准。你要出的不再是工时，而是判断。

四、它能做出什么：实测能力与作品形态

4.1 评测覆盖面

GameCraft-Bench 子集的 15 类型 × 30 任务覆盖卡牌（自走棋、扑克）、Roguelike（战术、炼金）、恐怖（灯塔、磁带档案）、放置（地牢公会、工厂星球）、开放世界（驯兽师、天空群岛）、平台跳跃（变身、雷霆女武神）、解谜（重力反转、管道危机）、竞速（漂移、特技）、节奏（指挥家、音符高速）、射击（机甲出击、波次指挥官）、模拟（空管、公交）、体育（拳击、滑板）、策略（象棋变体、机器人工厂）、大亨（微小工厂主、贸易商队）、视觉小说（奥秘学院、法庭线索）3。人类盲评 72.7% 的总体胜率说明：在”小游戏/切片”的尺度上，它的产出在盲评里已经多数情况下赢过裸的顶级编码 agent。

4.2 仓库演示的形态上限

官方 demo 的八个样例——文明原型、空洞骑士 Boss 切片、街机格斗、地牢 Roguelike、水果忍者、跑酷、像素只狼、AI 狼人杀1——共同特征是：单屏到少量场景、单系统主导（战斗/划切/跑酷/对话）、小时级而非月级的完成体。评测里的开放世界（天空群岛）与策略（象棋变体）也都在这个量级。它的甜区可以概括为：2D、Web 端、玩法切片、独立游戏规模。

4.3 迭代与编辑能力

创建只是一半；论文 teaser 强调”文本创建、多模态输入创建、IP 风格迁移、游戏编辑”四类操作3，/vibegame-edit 工作流支撑后续演化。artist 的迭代纪律被写进角色契约：改动必须给 before/after 对比链接、最终资产优先展示、用户说”更饱和”这类模糊需求时自行判断出一版而非堆三个候选7。这意味着它定位的是可长期对话打磨的游戏草稿，而非一次性产物。

五、逐环节评估：游戏产业每个工种它能做什么

以下逐环节对照源码与论文证据给出判断。”能”指有直接证据支撑的现有能力；”做不到/弱”指无证据支持或结构性缺失的部分。

5.1 程序（游戏编程）

能做：完整 2D 网页游戏的实现——场景树、实体与 FSM（玩家/Boss 状态机）、碰撞体工厂、弹幕、输入映射、DOM HUD、相机跟随与震动缩放等，骨架目录里的五个基线就是证据13；接口先行的多系统并行开发（阶段模板二：先写稳定接口契约，boss/map/player 三任务全并行，各自带独立测试场景，再集成）12；静态校验（vibegame check）与运行时断言结合的自验闭环。做弱/做不到：Unity/Godot/主机/原生移动端（roadmap 但未落地）1；网络多人与服务端逻辑（仓库与论文均无证据，狼人杀是本地 AI 派对游戏）；大型代码库级工程（上下文与任务编排都按”小时级项目”设计）；性能敏感的原生优化。

5.2 美术（2D 资产）

能做：这条是 VibeGame 相对一般 coding agent 拉开差距最大的环节（A 维度 +7.72）3。artist agent 配有完整的图像工具链：生成（imagegen.py、分层生成 qwen_image_layered.py）、切分（cut.py）、合成（compose.py）、背景移除（rmbg.py）、像素化（pixel.py）、视频生成（videogen.py）、分析与标注（analyze.py、label.py）、精修（perfectify.py）5；质量契约强制”最终可出货”，禁止把占位方块、程序涂鸦（PIL 画图）交给玩家，也禁止”每个动作单帧凑合”——要动画就给真实运动帧7；风格一致性靠参考图机制系统性解决：先产一张经用户批准的项目级参考图，后续所有角色、敌人、UI、道具资产以它为风格锚点12。做弱/做不到：3D 建模/绑定/骨骼动画（无 3D 管线）；高精度主机级资产与复杂连段；designer.md 明确要求设计规格适配图像生成的可靠边界——artist 能稳定交付”语义命名的动作类别”（attack/run/jump/cast/death）与”名词类物件”（meteor/spike/arrow），超出这个形状的美术需求（精确像素级控制、多关节复杂动画）不在可靠区6；音频完全缺失——仓库 artist 工具链里没有任何音效/音乐生成文件，论文与 README 亦未提及音频管线（源码目录实读判断），这是当前最刺眼的工种空白。

5.3 策划（游戏设计）

能做：designer 是常驻角色，撰写与维护 GDD.md，职责包括机制、系统、内容、UI 约定、关卡与 Boss/遭遇构成6；启动时自动注入设计理论库（MDA、动机理论、公平性）与具体模式库（UI 惯例、Boss 遭遇设计、场景构成）6；角色契约要求它”不是被动的——主动挑战坏设计，指出会让玩家无聊或沮丧的机制，为每个建议提供理论背书”6。GDD 是全局玩法真相，新机制必须先进 GDD 再进 PRD，还有 VLM 保真度校验防止”设计文档悄悄偏离用户原话”12。做弱/做不到：玩法发明的原始创意仍来自用户 prompt 与理论库组合，它擅长的是”把方向收敛成自洽设计”而非”从零提出没人想过的玩法”；长线运营数值调优（留存、经济曲线）与市场/用户研究完全不在闭环内；设计品味的最终权衡按流程必须回到人（参考图与任务拆解两道批准门）。

5.4 关卡设计

能做：关卡/场景构成明确写在 designer 职责里（level/scene composition、boss/encounter design）6；骨架提供关卡级结构复用——roguelike 骨架内置程序化房间图与 Boss 房结构、跑酷骨架内置多阶段流程与每阶段尝试次数/最佳记录13；运行时验证让”这跳跳得过去吗”成为可断言命题（player 注入输入、推进帧、读坐标）9。做不到：大体量手工关卡的内容生产（3A 线性关卡数百小时的内容密度、开放世界数平方公里兴趣点填充）；关卡编辑器工具链本身的设计（它假设关卡以结构化文本存在，没有为人类关卡策划准备的所见即所得工具——Dashboard 的 Objects 面板只有属性级编辑）1。

5.5 游戏 UI

能做：UI 是引擎一级公民——引擎自带 UiLayer.js，模块库有状态栏、DOM 卡牌手牌、遮罩 HUD、覆盖层、升级选择等现成组件5；designer 的职责边界写得很细：它规定”按界面哪些值必须可读、同屏必须同时可见多少个、哪些状态变化必须告知玩家“，而长什么样、摆哪里归 artist 与实现者6；像素字体 HUD、DOM 卡牌前端在骨架中已是现成形态13。做不到：完整的设计系统/品牌级 UI（多产品统一的组件语言）；大规模本地化与 RTL 排版；无障碍的深度适配（读屏、色觉、输入替代）；复杂 UI 状态机的可用性测试闭环（player 能断言数值可见性，但”看不懂”这类认知问题超出其 VLM 验证范围——推断）。

5.6 QA / 测试

能做：这是框架投入最重、结构性最独特的环节——三层：auditor 静态门（规格-代码对齐 + vibegame check）8、player 运行时门（状态断言 + 截图证据存档到 Task dir/evidence/ + VLM 视觉微调回路）9、reviewer 终审门（Functionality → Visual Quality → Playability 三维递进，”发现第一个阻断性问题就停，报 blocker 而非罗列全部缺陷”，由 lead 决定下一步）10。消融显示这套对抗审查值 +4.63 分3。做不到：真人群测与手感收敛的最后一公里（reviewer 是”挑剔的 QA”仍是模型）；跨设备兼容性矩阵、性能压测、长时间 soak 测试；回归测试资产化程度有限（断言脚本随任务生灭，长期回归套件未见机制——推断）。

5.7 叙事 / 文案

能做：视觉小说类型在评测覆盖内（奥秘学院、法庭线索）3，designer 负责内容设计，GDD 承载叙事设定。做不到/无证据：长篇叙事的一致性管理（角色弧、伏笔回收、世界观圣经级别的设定库）；多语言文学性本地化；对话系统的分支深度管理未见专门机制。

5.8 制作人 / 项目管理

能做：orchestrator 实质上就是 AI 制作人——拆任务、定依赖（--blocked-by）、并行调度、评审技术方案、验收、面向用户交付，外加处理智能体卡死（检测 tmux 里的交互挂起、自行驱动窗格或引导用户）5。阶段划分模板（垂直切片优先 vs 接口先行并行）是标准的项目管理打法12。做不到：预算、里程碑对商业节点的对齐、团队人事、发行协调——这些被显式留给人（用户审批门）。

5.9 运营 / 发行 / 营销 / 音频

完全不做：商店页、预告片、社区运营、变现设计、数据埋点分析均不在框架范围内。音频如前所述是全链路空白。这两个环节目前是”提示词到游戏”这个范式整体（而非仅 VibeGame）的共有盲区。

六、剩下哪些事它做不到：边界清单

把证据收拢，VibeGame 的边界可以归纳为七条，按”结构性程度”排序：

1. 平台与维度天花板（结构性）。只有 2D Web（Phaser 宿主）。Godot、Unity 支持、端到端 3D 都在 roadmap 上但未交付1。主机、原生移动、VR 无从谈起。这不是工程进度问题，而是方法论边界：AI 原生引擎的那套”结构化文本 + 运行时控制”接口目前只在 2D Web 栈上成立。

2. 作品量级天花板（结构性）。评测与 demo 的全部样例都在”小时级、切片/原型”量级。72.99 分（GPT-6.1-Sol）是”盲评中压过裸 coding agent”的水平，不是”可上架商业作品”的水平。数十人月的内容填充、跨系统的大型状态管理、几百个实体的平衡矩阵，都超出任务拆解与上下文管理的设计容量。

3. 自进化的经验污染（论文自己承认的缺陷）。论文第 13 节原文：”我们观察到，当 VibeGame 持续开发不同类型的游戏时，自进化积累的经验反而会降低智能体表现。未来工作应进一步分析这一现象，并把通用经验与类型专属经验分开，以便各自自适应注入。”3 正因如此，主实验刻意用零经验版本跑，自进化只在消融里单独评。换句话说：“越用越强”目前只在类型收敛时成立，跨类型使用会把骨架/契约变成错误的先验。这是所有”经验库”路线的共同软肋在游戏领域的显形。

4. 音频与后端空白（管线缺失）。音效、音乐、配音无任何管线（仓库实读）；网络多人、账号、存档云同步、服务端权威逻辑无任何支持。它能做”单机 2D 网页游戏”这个矩形内的产品。

5. 创意裁决权仍在人（机制性设计，也是边界）。参考图批准、任务拆解批准、先验入库批准——三道门都明文要求显式人工批准124。框架刻意不替你决定”游戏应该是什么”。它把执行链自动化到了很高的程度，但”什么值得做、什么好玩”的判断被结构性地留在了流程外。这既防止了失控，也意味着它不产出创意源头。

6. 成本与模型依赖（工程性，未披露）。论文未披露任何 token 成本或耗时数据（全文实读确认）。八智能体多轮循环 + 三个 opus 档常驻/按任务角色 + VLM 验证回路 + 多 pass judge 的组合，开销必然显著高于单 agent 单轮（推断，论文无数据）。评测所用底模为 GPT-6.1-Sol / GPT-5.6-Luna 这类前沿闭源模型，本地小模型能否撑起这条流水线未有证据。

7. 评测与合规的外部性（方法论局限）。评测是 GameCraft-Bench 的 30 任务子集、LLM judge 打分（GPT-5.5 复核与人类盲评缓解但不能消除 judge 偏差）3；demo 中的空洞骑士/只狼/KOF 风格切片属于 IP 风格迁移演示，商用必然踩版权红线——生成资产的版权归属与训练数据合规是这个范式未解的外部问题。另有 Apache-2.0 之外那条非约束性的商业部署邮件登记请求1，不构成法律义务但需要商业团队知悉。

七、结语：它改变了什么，没改变什么

VibeGame 的真正贡献不是”AI 能做游戏了”这个标题，而是三块可复用的方法论积木：把项目状态做成智能体可读写可验证的结构化文本（引擎原生化的本质是”为非人开发者重新设计引擎接口”）、把实现与审查做成对抗性分工（auditor/player 按”证据获取成本”而非”测试种类”切分，是全文最值得移植到任何 agent 工程的设计）、把做过的事蒸馏成带审批门的先验（自进化不是玄学，是一套带 dry-run 与冲突停机的知识管理流程）。

它没有改变的：游戏作为产品的完整产业链（发行、运营、营销、音频、长线数值）、创意的源头裁决、3D 与主机级的工程规模、以及”好玩”的最终定义权。对独立开发者，它是今天的生产力工具——尤其适合把一个玩法切片从想法推进到可玩可迭代；对游戏工业，它是 2D Web 这个矩形内的一次完整可行性证明，而矩形外的每一堵墙（3D、音频、多人、内容量）都还立在那里，等下一代接口去拆。

参考文献

  1. tettethu. VibeGame (GitHub 仓库 README：安装要求、命令、Dashboard 四面板、Demo 列表、路线图、许可证说明). https://github.com/tettethu/VibeGame ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17

  2. Hu, W., Li, K., Wei, J., et al. VibeGame: Prompt-to-Game Development with AI-Native Engine and Self-Evolving Adversarial Agent Team. arXiv:2610.33106 [cs.MA], 2026-10-22. https://arxiv.org/abs/2610.33106 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  3. arXiv HTML 全文（2610.33106v1）：方法章节（引擎/AAT/自进化定义）、Table 1 主结果、Table 2 消融（数值：53.45 / 43.12 / 48.82 / 56.37）、Table 3 GPT-5.5 judge 复核、Table 4 评测任务清单、Table 5 Codex±引擎（64.44→67.13）、BUILD 门因子定义、72.7% 人类胜率、第 13 节自进化局限、作者机构. https://arxiv.org/html/2610.33106v1 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21

  4. 仓库源码 src/skills/self-evolve/SKILL.md（自检三规则、美术侧并行蒸馏、用户审批门 non-negotiable、CLI dry-run 提升流程、索引手动更新）. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  5. 仓库源码 src/.vibegame/orchestrator.md（编排者职责、GDD→PRD 链路、团队生命周期、交付交接包规范、vibegame lead 团队 API）；src/modules/ 目录列表（11 个模块）；src/engine/ 目录列表（RuntimeClock/RuntimeBridge/SceneTree/UiLayer 等）. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  6. 仓库源码 src/agents/designer.md（GDD 职责、设计理论库注入、主动挑战坏设计、”为图像生成美术而设计”的可靠边界）. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  7. 仓库源码 src/agents/artist.md（最终资产质量契约、禁止占位与程序涂鸦、before/after 迭代纪律、manifest 注册）. ↩ ↩2 ↩3

  8. 仓库源码 src/agents/auditor.md（静态质量门、auditor/player 边界原则及其成本论证、不跑游戏的约束）. ↩ ↩2 ↩3 ↩4

  9. 仓库源码 src/agents/player.md（运行时验证、Runtime API 状态断言与截图、vibegame vlm 视觉微调、证据存档）. ↩ ↩2 ↩3 ↩4 ↩5

  10. 仓库源码 src/agents/reviewer.md（终审三维 Functionality→Visual Quality→Playability、review-lock、完整检查清单要求、blocker 优先报告）. ↩ ↩2 ↩3 ↩4

  11. 仓库源码 src/agents/architect.md 与 src/agents/programmer.md（plan.md 所有权、PRD 可追溯性要求、任务契约约束与上报义务）. ↩ ↩2

  12. 仓库源码 src/skills/vibegame-build/SKILL.md（两阶段构建工作流、模块/骨架目录预扫描、GDD 保真度 VLM 校验 NO DEVIATION 机制、项目参考图流程、阶段模板、用户审批门）. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11

  13. 仓库源码 src/skeletons/index.md（五个子类型骨架的目录条目：2d-action-boss-fight / roguelike-deckbuilder / roguelike-dungeon-shooter / swipe-slice-arcade / 2d-bounce-parkour 及其适用/不适用判据）. ↩ ↩2 ↩3 ↩4