VibeGame

一个把一句话变成可玩二维浏览器游戏的开源框架。它是两层叠起来的。底下是一个建在 Phaser 之上的引擎，场景树、资源与脚本全部从普通 JSON 和 JavaScript 里加载，所以一个游戏就是一个可编辑的文件目录，而不是一个二进制。上面是一套多智能体工装，它跑在一个普通的编码 agent 里——Claude Code 或 Codex——把工作分给一队具名角色，彼此之间用一串文档衔接。已发布的演示包括一个文明原型、一段《空洞骑士》Boss 切片、一个街机格斗、一个地牢 roguelike、一个跑酷游戏，以及一个由 AI 主持的狼人杀派对游戏。

谁做的Tet 的账号资料里填的机构是西安交通大学；kiyotakali 是第二位维护者，也是商业部署通知的收件地址。项目配了技术报告、Discord 服务器和微信群，致谢部分把它和其他同领域的研究工作放在一起而不是单独站着——这更接近一次研究发布，而不是一个个人工具。

1. 01

   两层，而重点在上面那层

   这个仓库既是一个游戏引擎，也是一套 agent 工装，而 README 很诚实地说明后者才是主题。引擎这一侧刻意做得很朴素：底子是 Phaser 3，一个游戏由 project.json、若干 .scene.json、.node.json 模板、继承引擎 Node 类的 JavaScript 脚本，以及一份声明要预载哪些资源的 manifest 来描述。任何动态的东西——子弹、敌人、拾取物——都是从模板在运行时生成，而不是用裸对象拼出来，指令里就是这么写的。引擎目录里的六个 JSON schema 分别定义节点、场景、瓦片地图、manifest、工程文件和输入映射，于是整个游戏状态都是 agent 可以读写的东西，而不必碰编译后的代码。第一层存在的意义主要是让第二层成为可能：agent 需要一个由文本文件和 schema 组成的世界，而游戏引擎是造出这样一个世界的好借口。

2. 02

   一支带对抗环节的队伍

   这套工装定义了八个角色。orchestrator 掌握产品意图——决定做什么、拆成任务、审阅计划、验收结果。它下面是设计者和美术，两者常驻；再往下是架构师、程序员、审计员和玩家，各自限定在一个任务内；外加一个负责最终质量门的评审者。任务流程是编号的，而顺序本身有意义：对齐需求、勘察可复用之物、连同书面功能规格建任务（规格要覆盖触发条件、初始状态、流程、终止状态与边界情况），然后架构、然后审计划、然后实现、然后审计、然后玩。这些阶段里有两个存在的目的就是抓别的阶段。审计员拿完成的代码去对计划和需求；而玩家必须真的把游戏玩过，任务才算验收。 把最终发言权交给一个不写代码的角色，和把评审者放进回路是同一个直觉，只是又往前推了一步：最后一句话属于一个表现得像用户的东西。

3. 03

   有归属者的文档，以及文档之间的一致性检查

   这些角色不是靠聊天协作，而是靠有明确归属者的文件协作，而归属规则是写下来的。一份游戏设计文档持有全局玩法事实，一个新机制必须先落到那里，才能出现在需求文档里——orchestrator 被明确要求绝不在需求切片里发明机制。架构师拥有一份计划，内含技术设计、运行时状态契约和验证计划。一份日志文件只允许追加，按顺序保存程序员、审计员、玩家之间的交接。最有意思的是谁检查谁：架构师在动手规划之前核对需求与设计文档是否一致，审计员在实现之后核对代码与需求、计划是否一致。每一次交接都是一份人之后能读的实体文档，于是失败可以被定位到某个阶段，而不是归咎于某个模型。

4. 04

   一份被强制执行的术语表

   仓库里比较不动声色地聪明的一样东西，是一份要求所有 agent 使用、且禁止改述的术语表。它把引擎的词汇定义得很精确，而且在好几个条目里直接点名了不许用的词：场景树里的一个单位叫 node，不得叫 entity、actor、GameObject 或 prefab——哪怕后两个正是从 Unity 或 Godot 过来的人会顺手用的词。可复用的节点定义叫 template 而不是 prefab。规则还补上：术语不得在轮次之间切换；而向非开发者介绍术语时，agent 应当先给一次大白话类比，之后一直使用规范术语。单是 pivot 一个条目就写了一整段，规定 clip、sprite、group 三级设置之间的级联，以及碰撞体那条独立的级联。提示漂移通常被当成模型问题；这里把它当成词汇问题，解法就是把词典写下来。

5. 05

   工装本身，以及安装它的代价

   orchestrator 自己的指令有三万八千字符，背后有九个 Python 钩子支撑，分别在既定时刻触发——会话开始、提交提示、子 agent 停止、队伍建立、队伍模式强制、目标捕获、状态栏、队友消息，以及一个 web 钩子。它们合起来是真的在强制队伍结构，而不只是描述它。安装环节是最容易露馅的地方，而 README 在这方面异常坦白。框架用那个跳过所有权限询问的标志启动 agent，并且警告说：没用过这个标志的人必须先在一个终端里跑一次，因为首次运行的同意界面无法在受管会话里回答，不先做这一步 agent 就起不来。Codex 用户则必须先跑一条安装命令，然后另外打开 Codex、输入一条命令并信任装进去的钩子；README 说，这两步都做完之前，agent 照样在跑但永远不会注册，面板一直是空的，启动会一直等待一个永远不会出现的会话。这是一个具体、不体面的失败模式，被写下来给下一个人看——好的安装文档就是这个样子。

6. 06

   读起来像伤疤的规则

   交给 agent 的引擎指令里有几条规则，只可能是在出过事之后才写得出来。一条禁止在整个工程范围内使用那个按模式匹配的 kill 命令，理由就写在规则里：它会把整支 agent 队伍、面板、运行时和终端会话一起杀掉。另一条要求删除文件必须走可恢复的方式，而不是永久删除。再一条让 agent 在动手前先读设计文档、资源清单和引擎规格，不许猜游戏状态或有哪些资源。第四条说，向用户展示文件路径时必须用指向绝对路径的 markdown 链接，而且特别不要用 file 协议那种形式——那是 agent 很可能会顺手写出来的东西。第五条是一小块值得照抄的提示工程：禁止 agent 使用结构化的提问工具，必须把问题和选项以纯文本打印出来，因为一个模板化的对话框会打断整套工装正在努力维持的流程。

7. 07

   数字长什么样，以及一条不寻常的许可条款

   二十一次提交换来二百五十六颗星和十八个 fork，这个比例不寻常，而原因是这个项目是什么：一次研究发布，配技术报告、八段录制演示和一篇发布公告，而不是一个在公开环境里慢慢长出来的东西。两位贡献者，一位提交了十六次，另一位五次。三百九十四个文件、十一 MB、没有 release、没有 tag，总共只开过一个 issue——一位读者问能不能把演示链接都放上来好在线玩，以及那些游戏是一句话生成还是经过了几轮调整。回答是两者都有，随后又有一条跟帖说演示玩不了，结果发现是那位读者看的是视频展示区，而不是页面下方更远处的试玩区。许可是 Apache-2.0，外加一条值得复述其要点的补充：商业部署被请求发一封通知，写明机构、产品名和一段简短说明。文本明确写道，这只用于项目追踪与社区联系，不需要批准、不收取费用、也不修改 Apache-2.0 授予的任何权利。把这样一条挂在宽松许可后面并不常见，而把自身的限度写得这么清楚，正是它能够被接受的原因。路线图上写着：先 Godot，再 Unity，然后是三维。