games-development-ai/docs/agent-specs/生成主线架构演进路线.md

date, topic, status

date	topic	status
2026-06-20	生成主线架构演进路线	SoT · 产物终态已由创始人拍板(2026-06-20:终态=src/ 工程,gameDefinition 仅中间脚手架);其余演进项待评审

这是生成主线“往哪走、先做什么”的单一 SoT。 它把两条分析线合并成一张图:一条是从我们自己 SAA 代码出发的内部诊断与加固(吸收并取代《2026-06-19 生成平台架构演进方案》,后者已归档为历史过程档);另一条是对标最强外部系统 OpenGame 的补能力(其逐行源码深析单独留作外部标杆参考档 2026-06-20-OpenGame对照分析与复刻缺口.md,本路线引其结论、不重复其考据)。 产出方式:多架构师评审 + OpenGame 真源码 5-agent 深读 → 合成散文,6c6g 编排+可读性打磨。承重锚点已抽查属实(见 §六 末)。

生成主线架构演进路线

一、定调:我们是什么,这份路线是什么

绘境AI 的游戏生成主线,本质上是一台被刻意设计成可靠的、固定相位的生成机器。它不是一个让强模型自由发挥的开放式编码 agent,而是用便宜通用模型驱动、用确定性的图编排约束控制流、用九门 harness 兜底验收的一条流水线。它的骨架是 Spring AI Alibaba 的裸 StateGraph,一共 16 个节点——从 render、classify、design、generate、validate、scaffold、asset、build,到 play 与 player、nreview、modify、escalate、repair,再到 emit 与 giveup。这些节点不是声明式 YAML,而是一段段实打实的 Java NodeAction;控制流由图的节点和边预先固定,而非由模型在运行时自由决定"下一步调什么工具"。模型这一层,我们硬编码了 11 个便宜通用模型(以 deepseek-v4-flash 打底),没有任何一个是为游戏代码专训过的;成本策略明确是"便宜模型加 harness 门兜底",而不是去训一个专用大模型来扛质量。这台机器的当前真实状态是:结构正确、控制流确定、底层验收很硬的流水线已经建成并合入主干,双证地基已经成立,但生成质量尚未稳定达到 80% 门,而且策略层下沉进了机制层。

这份路线要做的,是把过去两条独立的分析线合并成一张演进图。第一条是从我们自己的 SAA 代码出发的内部诊断——债压在哪里、阶段 0 到 5 怎么加固;它由本路线完整吸收,原《2026-06-19 生成平台架构演进方案》在此之后退役为历史过程档。第二条是从最强外部系统 OpenGame 出发的对照分析——它怎么把一句话变成游戏、我们缺哪几层能力;那份深析作为外部标杆参考档单独保留为 2026-06-20-OpenGame对照分析与复刻缺口.md,本路线在需要时引用它的结论,但不重复它的逐行源码考据。读这一份,就读到了"生成主线往哪走、先做什么"的当前真相;要看 OpenGame 内部机理的细节,再去翻那份参考档。

需要先讲清的一个判断,它决定了整张图的取舍边界:OpenGame 是命令式自主循环(while(true) 里模型自由决定下一步调什么工具,控制流由模型驱动),我们是声明式有向图编排(节点、边、条件预先固定,控制流由图驱动)。这是两种正交范式。所以本路线不把 OpenGame 的主循环嫁接进来——硬塞就成了项目明令反对的"缝合设计",而且对卡 80% 成功率门这件事而言,图的确定性本就比"DO NOT STOP"那种口头督促更稳。我们要抄的,是 OpenGame 的工具层、韧性兜底、防脏脚手架与经验复利机制,把它们当成零件库,原样落进 SAA 节点内部的工具执行环节;我们不抄它"模型自由驱动主循环"那套范式。本路线因此天然分成两条并行的线:一条向内加固现有架构,一条向外补齐 OpenGame 证明值钱的能力层。

★ 产物终态定调(创始人 2026-06-20 拍板):终态 = src/ 工程,gameDefinition 只是脚手架

往下读之前,必须先钉死一个比下面任何技术债都更根本的定调,因为它决定了这条生成主线"什么才算做对了"。生成游戏的终态产物,是一个 src/ 多文件代码工程——结构化、模块化、可导航、agent 能快速定位与探索的真实源码项目。这条不可妥协:无论游戏简单还是复杂,最终落地的都必须是 src/ 工程。 这正是《生命周期项目管理》设计 §3.1 白纸黑字的要求("模块化 src 按 input/spawn/score/physics 拆,硬编码 blob 不可维护即不合格产出"),也正是创始人反复表达的那句话——要代码的目录、架构、结构化,方便修改时 agent 好定位好探索。

由此必须诚实纠正本文档与《固定游戏架构》设计此前留下的一处认知偏差:当前的 gameDefinition JSON 不是"真结构化源",它只是极简游戏的、便宜模型友好的中间表示(脚手架)。 它把整段玩法逻辑塞进 behavior.code 这个 JSON 字符串字段、运行时用 new Function 直接解释执行——这恰恰是 §3.1 所说的"硬编码 blob":不可维护、改一行要在字符串里找、agent 无法结构化定位。所谓"双证地基成立",证明的是一件真实但有限的事——便宜模型能可靠产出连贯的 gameDefinition 中间表示;它没有、也不能证明"gameDefinition 就是合格的终态产物"。

所以两者的关系在此一次性钉死,并用它覆盖《生命周期 v2》与《固定游戏架构》之间此前悬而未决、却同被标为 ACTIVE 的那个冲突(一个要 src/、一个要 JSON,让无状态 agent 无所适从):终态产物 = src/ 工程(§3.1 是正解,不可妥协);gameDefinition = 通往 src/ 的中间妥协态——妥协只允许在"输入端"(让便宜模型先产一个极简的声明式描述),绝不允许妥协在"产物端",它必须经过一道真实的"gameDefinition 编译/展开成 src/ 工程"的构建,而不是停在 JSON 里被 new Function 跑掉;当前实现(JSON 内嵌 JS 串 + new Function 解释执行)= 已知偏离终态的债,缺的正是"gameDefinition → src/"这一段产物侧的展开,记入待纠正项(具体怎么补属后续 plan,这里只钉定调与方向,不展开实现)。

这条定调过去"写了却传不到实现",所以它必须配一道机制门(doc↔code 兑现门):生成产物要能被自动断言为"存在 src/ 多文件结构、玩法逻辑落在真实源码文件里、不存在'逻辑只以 JSON 字符串形态存在 / 运行时 new Function 跑内嵌串'"。这道门的设计与挂载并入文档治理那一组的强制门清单;在它落地之前,"产物必须是 src/"这条只是又一条等人自觉的软约束。

二、现状诊断:我们的债在哪里

把这台机器拆开看,真正的病根不是"没建成",而是机制已通、生成质量未达门,且策略下沉进机制层造成了多源漂移。债集中在三类。

第一类是策略下沉进机制层。 本该作为可替换数据的策略,被焊死进了不该重编译重部署的代码里,造成三处倒置。其一是模型路由:11 个便宜模型的名字和 per-role 的采样面,全是 Java 常量,换一个模型要改代码、重新构建。其二是 prompt 正文:gamedef 的生成约定(系统提示、运行时面的写法约定、命名对齐)是 Java 字面量,而 Python worker 那一侧又镜像了一份——同一份约定存在两个源,这是一个潜在的 split-brain,虽然当前 worker 走的还是纯 iife 路、这条裂缝尚未被真正激活,但只要 cutover 依赖 worker 线的数据,它就会立刻变成承重的坑。其三是品类骨架:由 design-agent 自己产出,没有外部锚。这三处倒置的共同后果是,凡涉及跨 Python 与 SAA 双轨的策略,一旦"策略化"做得不干净,就会从"一处硬编码"恶化成"多处不同步",拆东补西。

第二类是验收 oracle 的 Goodhart 风险——九门是机制地板,不是质量 oracle。 九门 harness 判的是机制:能不能装载、跑不跑帧、响不响应输入、到不到终态,全是确定性的,这一层我们确定性地领先,是这套架构最大的工程价值,零理由动它。但它有两个真实口子。一是 latch 终态语义不分胜负:当前 latch 由系统强加(expectLatch 恒为 true),弃守排空也能逼出一个 gameover——这意味着一个空壳游戏可以蹭过 latch 门,而 latch 正是机制进展那一门的承重件。它对"这到底是不是题面要的那个游戏"几乎零鉴别力,这个问题比给门加一个 selfAssessed 字段要紧得多。二是出题与被考同源:classify 自产 archetype、design 自产 gatespec,而 W-G1 的核心未知恰恰是便宜模型连 ball.x、driver:none 这种最基本的东西都会反复写错——让同一只待验模型既出题又答题,验收闭环就有一格没真正断开。

第三类是 factory 与 gamedef 双轨未 cutover。 我们有两条生成产线并存:老的 factory 路(填参装配,默认产线,但实测成功率约 60%,低于 80% 门),和新的 gamedef 路(便宜模型友好的结构化中间表示,双证其"能被可靠产出"已成立,但产物侧"展开成 src/ 工程"这一段尚缺,且尚未切为默认——见上方 ★ 终态定调)。双轨并存本身是健康的演进态——新路没稳前不该贸然切换——但如果不立一道硬退役门,演进态就会沉淀成永久债。与之伴生的还有一个成本侧盲区:generate 节点内部有一条回退链会静默切模型,但它不计 failCount、不进 escalationEvents,与图层的 escalate 升档是两套互不相通的机制;这导致"一次失败到底走了几层模型"算不清,而 cutover 的成本归因恰恰依赖这个数,盲区不补,60% 这个门的成本侧就不可信。

还要顺带说清一个已经被实证反掉的误判,免得为已有资产重复建设:源项目持久层不是悬空的。game_source_project 的建表迁移真实存在(V18/V20 双副本),landSourceQuietly 与 markSourceBuiltQuietly 在回调实现里被真正调用(事务外层、source_hash 幂等)。所以它已经是一等公民,真实缺口只是血缘丰富度和 gamedef 路的端到端验证,这是 P2,不是要去补一条根本不存在的落库链。

三、对标 OpenGame:我们缺哪几层

把 OpenGame 看透之后,落到我们的现状上,真正的差距集中在三层。它们与第二节的内部债不重叠——内部债是"已有的东西没做对",这三层是"值钱的东西我们还没有"。要看每一层在 OpenGame 源码里的具体长相,去翻 2026-06-20-OpenGame对照分析与复刻缺口.md;这里只讲清楚缺的是什么、为什么缺它要紧。

第一层缺的是生成约束的厚度。 OpenGame 端到端能跑通的根本前提,是它有一套预建模板,外加每个 archetype 一份 template_api.md 的 hook 清单当"填空靶子"。它的生成质量不来自强模型自由发挥,而来自把开放问题收敛成填空题:一份 GDD(游戏设计文档)把"做个游戏"这件开放的事,结构化成一张每一节都硬绑下游工具入参或代码文件的待办清单——资产表喂给资产工具、ASCII 布局喂给贴图工具、数值合并进配置、行为去改关卡管理器。约束便宜模型不跑飞的,是三条铁律:数值只能进配置、只用模板已有行为、绝不许编造清单里没有的 hook。而 Hook Integrity 这条铁律之所以能约束便宜模型,正是因为有一份明确的 API 清单让它无从编造。我们这一侧,classify 和 design 节点是存在的,但 archetype 体系、物理优先的分类 prompt、GDD 的契约化程度、以及最关键的那份"LittleJS 增强发行版加插件库公开 API 清单"当我们的 template_api——都还没补齐。没有这份清单,便宜模型一定会编造 API。这一层 OpenGame 抄不来、必须我们自建,而它恰好和创始人定的"游戏等于长生命周期结构化源项目"基座、以及"玩法模板等于品类框架"的定位,是同一个东西。这是最高价值的缺口。

第二层缺的是经验复利层,我们几乎从零。 OpenGame 真正的护城河是两套同构的离线经验自进化机制,都遵循同一个闭环:完成任务、抽取经验、去具体化、沉淀回本地 JSON 库、下次先查库命中复用、重复达阈值再升格成可执行规则——纯本地、零向量、零 embedding,本质是基于案例的推理而非 RAG。其中 Debug Skill 是一本活协议:数据结构是(签名、原因、修复)三元组,签名匹配是纯算法零 LLM,只在诊断新错和归纳新规则两处兜底调 LLM;最实的一环是同一个反应式修复在重复出现三次后,会自动升格成执行前的预校验规则,经验从"救火"升级成"免疫",而且只有跑通验证的修复才进库。Template Skill 则从一个 game-agnostic 元模板出发,每完成一个项目跑一条五段流水线,把具体代码泛化成带 KEEP/copy/hook 分层的模板,以"物理三元组加 archetype 名"为匹配键复用整个家族。这一层我们规划过 Debug Skill 但 MVP 做了简化,Template Skill 那种"从完成的游戏项目反向生长品类骨架库"的能力则完全没有。它对便宜模型尤其划算——每一次签名命中都省一次 LLM 调用,把高频错变成确定性查表。

第三层缺的是资产线,以及偏弱的语义验收。 资产这一块,OpenGame 走的是一整套"生成、抠图、视频抽帧、多级回退、清单装配"的重流水线,依赖视频模型加 ffmpeg 加抠图后端——便宜的文生图模型替不了动画质量,这是真壁垒。我们不照抄这套依赖,而是让 asset 节点接王蓝莓投资人版已经拍板的 mmx-cli,大幅降级的部分(静态帧加程序音)照它的多级回退思路兜底即可。语义验收这一块需要说准:OpenGame 论文最响的"三轴 VLM 验收"在开源代码里其实并不存在——README 描述得很全(headless 浏览器跑生成的游戏,VLM 沿 Build Health、Visual Usability、Intent Alignment 三轴打分),但全仓 grep 不到任何渲染真实像素、真实浏览器或 VLM judging 的代码,只留一句"will be released soon",它放出来的真实验收只到 build 加 test。所以单比已经开源的东西,我们的真机九门已经更硬。但这里要分清两层、别就此自满:九门判的是机制(Build Health 那一轴),我们确定性领先没有疑问;可 VLM 另外两轴——好不好看、是不是用户要的那个游戏——九门根本判不了,这两件事在我们这边对应的不是九门,而是 player 软门(M3 视觉模型看截图),而 player 软门是软的、跑便宜模型、不成体系,这恰恰是我们的弱项。所以正确的动作不是"把九门结果套个三轴外壳就交差",而是把 player 软门那条做厚——OpenGame 论文那套三轴设计,正是这一层值得我们抄的蓝本,哪怕它代码并没放出来。

四、统一演进路线

把内部债和外部缺口合起来,演进沿两条并行的线推进。线 A 向内加固现有架构,把硬编码的策略抽成数据契约、把跨进程对齐点锁成单一事实源、把验收信号补上独立的 ground-truth;线 B 向外补齐 OpenGame 证明值钱的能力层。两条线有两处天然交汇,必须合并、不能各列一遍,下面先讲两条线各自要做什么,再讲交汇点怎么合,最后给一张统一的迁移序列。

贯穿两条线的总原则有三条。其一,不重写任何主干——接法 A 裸图是接法 B(ReAct)的躯干、九门是最大工程价值、源项目持久化已是一等公民,这些全留,改的只是策略层外置与 oracle 加固,而且全部 additive 加 fallback 回落。其二,所有新增的质量门默认只观测不收紧——当前是刻意宽门放量在攒数据(开闸两门焊死放行、三门只观测),任何新门若一上来就生效,会立刻掐断这条灰度闭环,所以新门一律默认 flag-off 只落 trace,达标率稳定后再一行 flip,对齐后端 Tier0 的范式。其三,凡涉及跨 Python 与 SAA 双轨的策略外置,数据契约必须是语言无关的 JSON/YAML、两轨都读它、CI 卡 parity——否则"策略化"就沦为"跨语言漂移",把一处硬编码换成多处不同步。

线 A:加固现有架构

线 A 有五件事。

trace 抽取与文件拆分,是为后续一切改造铺路的纯重构。把内联在近九百行 dispatcher 里的 trace 抽取逻辑(约 280 行)抽成一个独立的纯函数 SaaTraceExtractor,补 snake 到 camel 的单测;同时把过载的 SaaStudioNodes 单文件(一千六百多行,节点工厂、路由谓词、RFC6901 工具、giveup dump IO 混居)按职责拆包。这两步都是包内方法移动、单测护航、零行为变更,把 dispatcher 从近九百行瘦到约六百行。要诚实标注这步的收益边界:它的价值仅仅是"纯函数可脱图单测",并不是"闭合双 Java 实现漂移"(HTTP 路的 trace 抽取在 Python worker 一侧,Java 侧本就不抽),把范围讲准才不会拿错误的理由去论证它。

prompt 同源,解 split-brain,是线 A 的关键路径起点。把 gamedef 的生成约定(系统提示正文、运行时面的写法约定、命名对齐)从 Java 字面量提为 contracts/prompts 下的版本化资产,让 Java 的 GAMEDEF_SYSTEM 与 worker 的 prompt.py 都从这一份资产读、CI 卡到字节一致。Prompt Registry(contracts/prompts/registry.yaml)作为第 8 类契约已经存在,这一步不是从零起,而是把已有的 registry 真正接线进生成链路。它一举两得:既根除了那处 P0 级的 split-brain,又坐实了三段式缓存的前缀——前缀字节一致才能命中,spike 已证命中率有 76% 到 93%。这里有一条硬纪律:split-brain 未解之前,不得拿 worker 线的数据去做 cutover 决策。

模型外置,把 11 个模型名加 per-role 采样面外置为 models.yaml,让加载逻辑从配置读、常量作 fallback。硬约束是必须指定单一权威——要么 Java 与 Python 读同一份 models.yaml,要么 CI 校验两侧 parity——否则换来的是跨语言的模型路由漂移。

latch 终态语义,是线 A 里唯一的 P0、也是最要紧的一件,但它同时是与线 B 的一个交汇点,留到下面"交汇点"统一讲。

cutover,是线 A 的收口里程碑:立一道硬退役门,gamedef 路成功率达到 80% 门后,切为默认产线、二分收敛退役 factory、fail-closed 门 flip、modify 的"从源真构建"闭合。它依赖 prompt 同源(才敢用数据做决策)、依赖质量信号可信(下面交汇点)、依赖 80% 达标率三个前置。与 cutover 同期还要补上前面说的成本侧盲区:给那条静默回退链 append 一个轻量的 fallbackEvents 进 trace,让成本归因可信。此外把 failureReason 全归桶 llm_error 的诊断盲区一并修了——扩出 failureDetail 子码(修复次数耗尽、升档耗尽、缺全局名、模型超时等),契约先行,注意 DB 列宽 32 字符的约束,additive 到消费侧不读即退现行。修复后数据回路才能按真因聚合,这是数据驱动闭环的承重件。

线 B:补齐能力层

线 B 有四件事,全部源自 OpenGame,且全部落在 SAA 图内,不引入外部主循环。

GDD 契约加 template_api,是最高价值项。 把物理优先分类的 system prompt(含易错例)和五 archetype 体系做成 classify 节点加 JSON 容错解析;把 GDD 的"六节每节硬映射下游"契约、三铁律、按 archetype 动态拼三层规则做成 design 节点,内置规则可整段移植。但有一个范式级前提必须先立:先得有那份"LittleJS 增强发行版加插件库公开 API 清单"当我们的 template_api,否则 Hook Integrity 无从约束,便宜模型必然编造 API。这份清单和"结构化源项目"基座、"玩法模板等于品类框架"是同一个东西,是这一层乃至整条路线约束力的靶子。

Debug Skill 落地为 diagnose/repair 节点加 checkpoint。 把验证驱动的 REPEAT 循环、(签名、原因、修复)三元组 JSON 账本、分组阈值升格这套机制,对应到 SAA 裸图里一个 diagnose 节点加 repair 节点加 checkpoint 持久化。签名匹配是纯算法零 LLM,便宜模型只在诊断新错和归纳新规则两处兜底调用,每次命中省一次 LLM 调用。种子协议里的错误码要从 Phaser 换成我们自己的 LittleJS 运行时和九门错误码,但结构原样可用。

Template Skill 按 gameDefinition 重写,且入库前过九门质量门。 抄它的范式(结构化源项目模板的 KEEP/copy/hook 分层、经验计数、离线蒸馏),但实现要整体重写两处:它的物理信号正则和 hook 命名约定死绑了 Phaser 和它自家模板的类名,我们要换成"对 gameDefinition 结构做 archetype 分类、对源项目模块做抽取"。更关键的是,原版入库前没有任何回验门,带病的骨架会直接沉进库;我们必须给它加一道"入库前过九门或可构建校验"的质量门——这恰恰是我们相对它的强项,把我们最硬的东西用在它最弱的地方。另外要预警原版一个硬缺口:这套进化只有单调累积、计数强化、阈值升格,没有遗忘、淘汰、冲突消解,也没有向量检索,家族一多线性扫加物理三元组离散匹配会退化;等品类规模上来,我们可能需要补一层真正的检索。

资产线接 mmx。 asset 节点接 mmx-cli 替代 OpenGame 那套依赖视频模型加 ffmpeg 的重流水线,大幅降级的部分照它的多级回退思路兜底。这是中优先级、范式上"换替代方案"即可的一项。顺带可把它的确定性 bitmask 贴图(纯算法、与模型无关,用确定性算法绕开模型的空间推理)直接搬进来,只对 platformer/top_down 用瓦片地图、逻辑类品类走代码定义网格——这是 OpenGame 一个聪明的工程判断,几乎零成本可得。

两处交汇点:必须合并,不能各列一遍

交汇点一:品类的独立交叉校验。 线 A 第四阶段要做的"category 独立交叉校验",和线 B 要做的"物理优先分类",指向的是同一件事,合成一项。这一项的内核是:保留 classify/design 自产骨架的生成路径,但验收 oracle 绝不能押在同一只待验模型的分类输出上。具体做法是引入一个独立于 design-agent 的交叉校验——从 brief 关键词、从 player-panel 的视觉反推品类,与 design 自报的品类比对,不一致即降权乃至拒发。这比"把出题点从写 gatespec 前移到选 category"更治本,否则只是把自评闭环挪了一格而非真正断开。线 B 带来的物理优先分类(看重力方向、视角、移动方式而非品类名,含 Terraria 是 platformer 不是 top_down 这类易错例),正好为这个独立校验提供了高质量的判定依据。一件事,一处实现。

交汇点二:把 player 软门做厚,oracle 去自评。 线 A 要的"九门去自评闭环",和线 B 要的"补强 VLM 语义层",是同一件事,合成一项。九门那一层(机制/Build Health)我们已经领先,不动它;要补厚的是判"好不好看、是不是要的那个游戏"的那一层,它对应的是 player 软门而非九门。动作是让这条软门更系统、可复现:做成独立于生成方的交叉校验,甚至一个离线 bench,蓝本就是 OpenGame 论文那套三轴(哪怕它没开源代码)。配套要把"模型靠 clickable 等运行时内置基元蹭过门,还是真写了交互逻辑"的占比、player/nreview 自评与九门 verdict 的交叉一致性,都进 trace(additive 扩展位已有),长期背离即告警——用数据积累"门的有效性"证据,而不是去堆一支评审舰队。

统一迁移序列(对齐现有 plan,不另起编号)

已有三份 plan 承接本序列:2026-06-17-001(后端 Tier0 生成主线)、2026-06-18-001(生命周期加 Tier-1 广度)、2026-06-18-002(Tier-1 广度后端)。下面的阶段挂入这些 plan 的验收,不新建 plan 编号;凡标"[新增·需进 plan]"的,是 OpenGame 对照带来的、现有 plan 里还没有的新工作项,需要补进对应 plan。关键路径标 ★。

• 阶段 0(零风险·立桩):收敛 job 核心字段名、state 键集、trace camelCase 键集的常量来源。这里要切分清楚——Java 内部键名可以收敛到常量类,而 Java 与 Python 之间的 trace 键只能靠契约和测试夹具对齐,不能并入 Java 常量类(这是一处假锚)。纯重命名,无行为变化。
• 阶段 1(线 A·重构):抽 SaaTraceExtractor、拆 SaaStudioNodes 分包、补单测,dispatcher 从近九百行瘦到约六百行,零行为变更。
• 阶段 2 ★(线 A·解 P0):gamedef prompt 约定提为 contracts/prompts 版本化资产,Java 与 worker 两轨读它、CI 卡字节。关键路径:split-brain 未解前不得拿 worker 线数据做 cutover 决策。
• 阶段 3(线 A·契约先行):models 外置加 CI parity;failureReason 扩 failureDetail 子码(注意列宽 32);GenerationJob record 化为 dispatcher 边界 DTO(图内 Map 不动,http 与 saa 同步切,灰度开关保非破坏)。全 additive 加 fallback。
• 阶段 4 ★(质量加固·全 flag-off 落 trace):① latch 终态语义区分胜利与弃守/超时(P0);② 交汇点一——品类独立交叉校验(物理优先分类同址实现);③ 交汇点二——player 软门做厚加 Goodhart 可观测化;④ fallbackEvents 入 trace。全部默认 off、只观测、不改放行行为。
• 阶段 B1 ★[新增·需进 plan]:GDD 契约加 template_api(LittleJS 插件库公开 API 清单),classify 与 design 节点契约化。这是约束力的靶子和最高价值杠杆,建议优先排进 2026-06-18-001(它和"结构化源项目"基座同源)。其中"物理优先分类"的落地与阶段 4 的交汇点一是同一处实现,不重复建。
• 阶段 B2 [新增·需进 plan]:Debug Skill 落 diagnose/repair 节点加 checkpoint;Template Skill 按 gameDefinition 重写并强制入库前过九门质量门;asset 节点接 mmx 并搬入确定性 bitmask 贴图。这一组是经验复利层与资产线,可在 B1 之后并行推进。
• 阶段 5 ★(里程碑门·cutover):gamedef 成功率达 80% 门后,切默认产线、二分退役 factory、fail-closed 门 flip、modify"从源真构建"闭合。依赖阶段 2(prompt 同源)、阶段 4(质量信号可信)与 80% 达标率三个前置。

关键路径是一条线:阶段 2(prompt 同源解 split-brain)→ 阶段 4(质量信号可信)→ 阶段 5(cutover)。阶段 0/1/3 可与之并行(独立资源)。线 B 的 B1/B2 与线 A 在资源上基本独立,可并行推进,但 B1 的产物(GDD 契约、template_api 清单)会让阶段 4 的品类校验和阶段 5 的质量更扎实,排程上 B1 越早越好。按价值排,最该立刻动手的三件依次是:先补 template_api 与 GDD 契约(B1,一切约束的靶子)、再把 Debug Skill 落成 diagnose/repair 加 checkpoint(B2 前半)、然后把 Template Skill 按 gameDefinition 重写并加九门质量门(B2 后半)。

五、我们刻意不做的

有三件 OpenGame 看起来在做、但我们刻意不做的事,要讲清楚为什么,免得被论文的卖点带偏。

不专训 GameCoder-27B。 OpenGame 论文把一个为游戏定制的 27B 代码模型当作支柱,但它的权重、训练码、数据都不在仓里,实测代码默认接的反而是 openrouter 上的通用强模型,设一个环境变量就能换。这恰恰证明它的框架被刻意设计成 model-agnostic——专用模型不是跑通的必要条件。我们的路线明确是便宜通用模型加 harness 兜底,质量缺口靠模板约束加 Debug Skill 补,而不是靠把模型这一层做重。OpenGame 自己的设计反过来印证了这条路走得通。

不把 VLM 当硬门。 player 软门要做厚,但它的判定是 LLM 视觉判断,本质是概率性的,不能用来定一次生成"算不算完成"。把一个软判定提成硬门,会直接撞上我们的铁律——"完成"必须由确定性的门来定。所以 VLM 这条线只做软门、做离线 bench、做交叉校验与告警,产出的是"门的有效性"证据和质量趋势,而绝不进放行的确定性判定。九门是机制地板,VLM 是质量观测,两者职责不混。

不上重型 PTY 沙箱。 OpenGame 的 shell 执行是重型的——PTY 优先、ANSI 解析、独占进程组、SIGTERM 再 SIGKILL、docker/podman/seatbelt 沙箱,深度绑定 Node 生态。这是它"模型自由写代码再跑构建看报错"那套自主循环的物理基座。我们走图编排,build 节点的职责窄得多,MVP 阶段不需要这么重的沙箱;将来若真需要,Java 侧用 ProcessBuilder 或 pty4j 自建等价物即可,但绝不移植那套 JS 适配。同理,MCP 走 SAA v1.1.2.2 自带的支持,不试图搬 OpenGame 那套从上游继承的 JS MCP 适配层——何况 OpenGame 的游戏生成能力本就不来自 MCP,而来自内置确定性工具加工程模板,以为复刻它要复刻一堆 MCP server 是彻底读反了。

六、风险与回滚

风险	缓解	回滚
模型/prompt/category 外置成新双源漂移	单一权威加 CI parity/字节卡门	配置缺失回落常量;worker 不引用即回 iife-only
新门收紧放行掐断灰度闭环	全部默认 flag-off 只落 trace,达标后 flip	trace 字段 additive,缺键省略字节兼容
latch 修复误伤现有过门样本	flag-off 观测期对比新旧 latch 判定差异	不 flip 即维持现行 latch
category 独立校验误拒正常样本	先降权观测、不直接拒发,统计误拒率	关 flag 退回 design 自报
Template Skill Abstractor 把坏骨架沉进库	入库前强制过九门/可构建质量门	关进化、保留现有库快照
failureReason 契约改动破审核台	契约先行加 DB 列宽校验加 additive	消费侧不读子码即退现行
gamedef cutover 后 factory 退役回归	80% 门加端到端验证为前置硬门	保留 sourceMode 开关一个 release,可切回 factory
串行门吞吐天花板为 1(已知债)	本轮不改(过早优化),显式记 follow-up	不适用

验证状态:本路线为架构裁定文档,未改代码。承重锚点已抽查属实——V18/V20 建表 SQL 加 land/markBuilt 真调用链(反掉持久层悬空误判)、failureReason 归桶 llm_error、contracts/prompts/registry.yaml 已存在(prompt 外置非 greenfield)、SAA 四文件路径、OpenGame 结论锚在其真源码(github.com/leigest519/OpenGame)。未验证待落地时确认的是:worker 的 prompt.py 与 models.yaml 在 wg1 外部 worker 树(本仓不可见),其"纯 iife、零 gamedef 路"的论断采信对照分析的实证,阶段 2 落地前需在构建机侧复核。