docs(analysis): 改准 OpenGame 文档里 VLM Bench↔九门 的说法
创始人指出:九门不是 VLM Bench 的等价物。改准为——九门更强的只是机制层(Build Health,能不能跑);VLM 的 Visual Usability/Intent Alignment 那两轴九门判不了,对应我们偏弱的 player 软门(M3 视觉软门),是待补强缺口非已赢项;OpenGame 的 VLM Bench 代码其实未开源(只论文)。改表格行/已有等价物段/收口结论/_index 指针 4 处。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
f1fae3f5e3
commit
c450552051
@ -114,7 +114,7 @@ OpenGame 论文卖的是三大支柱,但深读源码后必须诚实区分**哪
|
||||
| Template Skill 骨架库 | 五段流水线 + family 自进化 | **完全没有** | 高 | 离线进化,SAA 外挂库 |
|
||||
| Debug Skill 活协议 | (sig,cause,fix) + 升格规则 | 规划过、MVP 简化 | 高 | diagnose/repair 节点 + checkpoint |
|
||||
| 资产流水线 | I2V/抠图/多级回退/装配 | 走 mmx-cli | 中 | asset 节点接 mmx |
|
||||
| 可玩性验收 | README 宣称,代码是空的 | **九门 harness + 真机 CDP + VLM 截图** | 已领先 | 已有 |
|
||||
| 可玩性验收 | 论文宣称三轴 VLM,**代码未开源** | 机制层=九门真机 CDP(强);语义层=player 软门 M3 截图判(弱) | 机制已领先·语义待补强 | 机制已有;语义软门待做厚 |
|
||||
| 专训模型 | GameCoder-27B(权重不在仓) | 便宜通用模型 + harness | 不抄 | 路线不同 |
|
||||
|
||||
**第一类,设计可直接抄进 SAA 节点(价值最高):**
|
||||
@ -133,7 +133,9 @@ Template Skill 可以抄它的范式(结构化源项目模板的 KEEP/copy/hook
|
||||
|
||||
**第三类,我们其实已有等价物、甚至更强:**
|
||||
|
||||
OpenGame-Bench 的三轴 VLM 验收,在它开源代码里是空的(只有 README)。而我们的九门 harness 加真机 CDP 真玩加 VLM 截图 judge,**实际上比 OpenGame 开源出来的更完整、更硬**——OpenGame 的 Debug Loop 只验证到 build + test 不验证可玩性,而真玩门正是我们的强项。所以这块**别照抄它的弱验证**,我们要做的顶多是补一个"三轴打分"的形式化呈现(把九门结果归纳成 Build Health / Visual Usability / Intent Alignment 三个轴的评分形态),让验收报告对外更可读,仅此而已。
|
||||
OpenGame-Bench 那套三轴 VLM 验收,有个必须点破的事实:**它在开源代码里根本不存在**——README 描述得很全(headless 浏览器跑生成的游戏、VLM 沿 Build Health / Visual Usability / Intent Alignment 三轴打分),但全仓 grep `VLM|screenshot|judge` 零命中,只留一句“will be released soon”。所以单比已经开源出来的东西,我们确实更硬:我们有真机 CDP 真玩的九门加 M3 截图判,OpenGame 放出来的只有 build + test、并不验证可玩性。
|
||||
|
||||
但这里要分清两层、别就此自满——这也正是不该把“九门”简单当成 VLM Bench 等价物的原因。九门判的是**机制**:能不能装载、跑不跑帧、响不响应输入、到不到终态,全是确定性的,这一层我们确定性地领先,没有疑问。可 VLM 的另外两轴——Visual Usability(好不好看)、Intent Alignment(是不是用户要的那个游戏)——**九门根本判不了**;这两件事在我们这边对应的不是九门,而是 **player 软门(M3 视觉模型看截图)**,而 player 软门是软的、跑便宜模型、不成体系,这恰恰是我们的弱项而非强项。所以正确的动作**不是**“把九门结果套个三轴外壳就交差”(九门产不出“好不好看”“对不对”这两轴),而是**把 player 软门那条做厚**:让“是不是要的游戏、好不好看”有更系统、可复现的判定——独立于生成方的交叉校验,甚至一个离线 bench。OpenGame 论文那套三轴设计,正是这一层值得我们抄的蓝本,即便它代码并没放出来。
|
||||
|
||||
**第四类,刻意不走、抄不动也不必抄:**
|
||||
|
||||
@ -143,6 +145,6 @@ OpenGame 的命令式自主主循环、重型 PTY 沙箱、@google/genai 的 MCP
|
||||
|
||||
---
|
||||
|
||||
**收口结论。** 我们和 OpenGame 走的是两条路,但终点一致:都靠"把开放式游戏生成收敛成受控填空"来让不够强的模型也能稳定产出。OpenGame 用命令式 agent 循环加 system-reminder 接力来收敛,我们用 SAA 图来收敛——**在这一点上我们不是落后,而是用了更确定的范式。** 真正的差距集中在三处:一是**生成约束的厚度**(物理优先分类 + GDD 契约 + template_api 清单,这是设计可直接抄的最高价值项,且与"结构化源项目"基座天然契合);二是**经验复利层**(Template/Debug Skill,我们几乎从零,但设计可抄、且能用九门当原版缺失的质量门);三是**资产线**(接 mmx 替代)。而 OpenGame 论文最响的两个卖点——专训 27B 和 VLM Bench——一个我们刻意不走,一个我们其实已有更强的等价物。
|
||||
**收口结论。** 我们和 OpenGame 走的是两条路,但终点一致:都靠"把开放式游戏生成收敛成受控填空"来让不够强的模型也能稳定产出。OpenGame 用命令式 agent 循环加 system-reminder 接力来收敛,我们用 SAA 图来收敛——**在这一点上我们不是落后,而是用了更确定的范式。** 真正的差距集中在三处:一是**生成约束的厚度**(物理优先分类 + GDD 契约 + template_api 清单,这是设计可直接抄的最高价值项,且与"结构化源项目"基座天然契合);二是**经验复利层**(Template/Debug Skill,我们几乎从零,但设计可抄、且能用九门当原版缺失的质量门);三是**资产线**(接 mmx 替代)。至于 OpenGame 论文最响的两个卖点,得分开说。专训 GameCoder-27B 我们刻意不走——走便宜通用模型加 harness 兜底,而它自己框架的 model-agnostic 设计反而证明了专训模型不是跑通的必需。VLM Bench 则要说准:**它的三轴验收在开源代码里其实没放出来、只在论文里**,所以单比已开源的,我们的真机九门已经更硬;但别把“九门”当成 VLM 的等价物——九门更强的只是“能不能跑”这一层(Build Health),而 VLM 的“是不是要的游戏、好不好看”那两轴九门判不了,对应的是我们偏弱的 player 软门,那是待补强的缺口,不是已经赢了的项。
|
||||
|
||||
**最该立刻动手的,按优先级是:① 把 template_api(LittleJS 插件库公开 API 清单)和 GDD 契约补上,这是一切约束的靶子和最高价值杠杆;② 把 Debug Skill 的"签名→已验证修复→重复升格"活协议落成 diagnose/repair 节点加 checkpoint;③ 把 Template Skill 的骨架进化库按 gameDefinition 重写,并强制加入库前过九门的质量门。** 这三件做完,我们这条 SAA 配置式流水线就补齐了 OpenGame 真正值钱的那部分,而且是用我们自己更确定、更可验收的方式补齐的。
|
||||
|
||||
@ -26,7 +26,7 @@
|
||||
|
||||
### 生成主线设计链(现行架构)
|
||||
- ★ `2026-06-19-生成平台架构演进-review.md` — **多架构师综合·架构演进总方案(review·待创始人评审)**:**零 rewrite/大面积 keep**;病根=策略下沉机制层(多源漂移)+生成质量未达门+验收 oracle Goodhart;演进=策略外置(数据驱动·prompt/模型/品类提为契约)+九门去自评闭环(**latch 胜利/弃守区分=P0**+fail-closed)+单轨化,全程 flag-off 不破灰度;迁移序列挂 plan-001/002 不另起。承 [[agentic编排-SAA]]+固定架构设计链。
|
||||
- ★ `2026-06-20-OpenGame对照分析与复刻缺口.md` — **OpenGame(CUHK MMLab,Qwen-Code 二次 fork)真源码深读 + 复刻缺口**(散文·5 agent 读真码综合):它靠 4 原子工具+六阶段 SOP(system-reminder 接力·无中央编排)+物理优先分类→GDD 契约→多模态资产→确定性贴图;**我们 SAA 图比它命令式循环更确定,核心不落后**;真缺 3 处=①约束厚度(template_api+GDD 契约·最高价值)②经验复利层(Template/Debug Skill)③资产线(走 mmx);它两卖点(27B 专训/VLM Bench)一个刻意不走、一个九门已是更强等价物。源码 clone 在 `/root/oss/OpenGame`。
|
||||
- ★ `2026-06-20-OpenGame对照分析与复刻缺口.md` — **OpenGame(CUHK MMLab,Qwen-Code 二次 fork)真源码深读 + 复刻缺口**(散文·5 agent 读真码综合):它靠 4 原子工具+六阶段 SOP(system-reminder 接力·无中央编排)+物理优先分类→GDD 契约→多模态资产→确定性贴图;**我们 SAA 图比它命令式循环更确定,核心不落后**;真缺 3 处=①约束厚度(template_api+GDD 契约·最高价值)②经验复利层(Template/Debug Skill)③资产线(走 mmx);它两卖点:27B 专训刻意不走;VLM Bench **代码其实没开源(只论文)**,单比已开源的九门已更硬,但**九门只覆机制层(能不能跑),VLM 的意图/视觉那两轴对应我们偏弱的 player 软门、是待补强缺口,非已赢项**。源码 clone 在 `/root/oss/OpenGame`。
|
||||
- `2026-06-17-固定游戏架构与SAA-agentic-studio-execution.md` — **ACTIVE · 当前生成主线架构 execution**(固定游戏架构=轻量声明式领域模型+2D 适配器 / SAA studio 9+1+1 agent / 8 契约 / 救场阶梯 / 缓存三段式;**两 spike 已绿**:缓存经 new-api 透传 76-93%、classify tickModel 100%)
|
||||
- `2026-06-17-固定游戏架构与SAA-agentic-studio-review.md` — 配套**设计 review**(含深析 §10 + 创始人决策;承原 v2 生命周期原则)
|
||||
- `2026-06-12-游戏生成系统总体架构-review.md` — 生成系统总体架构纲领(三级生成 / W-G0~G4 路线 / 意图矩阵)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user