games-development-ai/docs/architecture/架构/生成引擎

topic, canonical, date

topic	canonical	date
生成引擎子树总览	true	2026-06-22

生成引擎 · 设计主文档

🚧 架构演进中 —— 廉价线 gameDefinition 已废(错误路线),现行 = A-model 写真 src/;tier2 富游戏自治轨建设中(0 号 spike accept)。文中结论可能随推进变化,以子树 README(本档)/ 运行时 SoT agentic运行时架构图说 与最新裁定为准。

这是什么:绘境AI 生成引擎子树的设计主文档,回答"一句话怎么变成一款可上线的游戏"这条技术主线——它的现行架构、要往哪走的演进路线,以及贯穿全程的一条范式原则。 给谁看:负责生成主线的工程师、新加入这条线的同事、架构评审、做尽调时想看清护城河关键路径的人。 怎么读:先读 §1 建立"这台机器是什么"的整体认知,再看 §2 那张端到端流程图;想了解当前债与未来路线读 §4–§6;想要更深的子系统细节,从文末的源档导航进去。

生成引擎是绘境AI 护城河的关键路径。竞品大多止步于"能生成";真正难的是让一个普通模型稳定地、可维护地、可长期演进地把一句话变成一款真游戏。这份文档讲的就是这条路怎么走通。

---

1. 一句话与一张图:生成引擎是什么

绘境AI 的游戏生成主线,本质上是一台被刻意设计成可靠的、固定相位的生成机器。它不是一个让强模型自由发挥的开放式编码助手,而是一条流水线:用便宜的通用模型驱动、用确定性的图编排约束控制流、用一套自动验收门兜底。

这台机器有三个互相支撑的设计支点,理解了它们就理解了整条线为什么这么搭:

• 便宜模型 + 门兜底,而不是训一个专用大模型。 模型这一层硬编码了 11 个角色 → 模型的赋值(以便宜的 deepseek-v4-flash 打底,救场位升 deepseek-v4-pro 强档,视觉 / 分类 / 回退位用 MiniMax-M3),没有任何一个是为游戏代码专门训练过的通用模型。质量缺口不靠把模型做重来补,而靠模板约束和验收门来补。这是成本策略,也是差异化判断——大模型迟早会追上,真正的护城河不在生成引擎本身。
• 图编排约束控制流,而不是让模型自由决定下一步。 控制流由预先固定的有向图驱动:每个节点是一段实打实的代码,节点间的流转在图里写死,而不是由模型在运行时临场决定"下一步调什么工具"。这条原则与具体框架无关——2026-06-25 框架 reframe 后,生成框架统一收敛到 AgentScope(SAA 降为最低优先级、留作远期适配验证),现行编排底座以运行时 SoT agentic运行时架构图说 为准。廉价线当前在 game-cloud 内落地的实现仍是 SAA 裸 StateGraph(SAA = Spring AI Alibaba,阿里的 Spring 生态 AI 编排框架)那 16 个节点——下文 §2 的流程图与 §4–§6 的债诊断讲的正是这套现存实现,不是收敛后的目标框架。
• 一套硬验收门当地板。 这就是俗称的"九门 harness"(harness 指把生成产物放进一个真实运行环境去自动检验的测试夹具;"九门"是其中九道确定性检查):能不能装载、跑不跑帧、响不响应输入、到不到游戏终态……全部是确定性的判定。这一层是这套架构最大的工程价值,也是绝不动它的底座。

把这三点合起来,可以用一句话概括整台机器的定位:LLM 在这里扮演的是"游戏工作室"的角色——它替代的是一个真实游戏工作室原本要做的策划、写码、配资产的活,而不是充当一个一次性出活的黑盒。这个"LLM as 工作室"的定位是整条线的灵魂,§3 会专门展开。

把第三个支点再往前推一步,可以立一条贯穿全线的工程纲领:harness 是这个项目的工程护城河,不是一次性的测试脚本(创始人 2026-06-22 历史回收判定捡回)。 这条判断的分量在于它决定了工程投入往哪里沉淀。一次具体的生成——某个创作者那句话变成的那款游戏——是消耗品:它产出后,真正留下来、能复利的不是那一款游戏本身,而是把它造出来、验出来的那套生成运行环境。所以 harness 应当被当作一份可版本化、可观测、可回放、可扩展的核心资产来建设:可版本化,意味着它的判定口径、阈值、负例语料都进 Git、能 diff、能回滚;可观测,意味着每一次生成的全过程(走了哪些门、花了多少、为什么挂)都落进轨迹账本;可回放,意味着拿同一份输入能重跑出同一个结果、复现一次失败;可扩展,意味着加一道新门、接一个新品类的真玩 driver 不必重写底座。它决定的是整条线的成功率、成本和交付稳定性这三件最要紧的事——把工程力气压在 harness 上,而不是去优化某一次单独的生成,正是这条线"越做越快"的复利来源。这也解释了为什么"九门 harness 禁止重写、是子进程复用的既有资产"这条铁律不只是怕改坏,更是因为它是要被长期养厚的资产,不是用完即弃的脚手架。

这台机器当前的真实状态需要诚实说清:结构正确、控制流确定、底层验收很硬的流水线已经建成并合入主干;但生成质量尚未稳定达到 80% 这道门,而且一部分本该可替换的"策略"被焊死进了不该重编译的"机制"代码里。 换句话说,骨架立住了,接下来要解决的是"质量"和"策略外置"两件事——这正是 §4–§6 演进路线要回答的。

还要钉死一条比技术债更根本的范式定性(出处:同目录设计合理性裁决(已并入运行时 SoT §4.1),2026-06-20 对抗审查,status 待创始人拍板):这套"便宜模型 + 受限 schema + 九门验收"是一条为轻量档游戏(Tier0:打砖块 / 合成 / 挂机 / 答题 / 网格点选)量身打造的可靠产线,而不是一个通用生成范式。它最大的风险不在工程层,而在被当成通用范式去对标 demo 里的 Marvel 平台动作 / KOF 格斗那一档富交互游戏——那一档这套范式结构性地够不着(运行时没有承载那层复杂度的形状),不是补个分支能解决的,必须显式把愿景分层、复杂品类另开一轨。下文 §3/§5 把这台机器框成"护城河的关键路径""值钱的东西我们还没有",成立的前提正是把它锚在 Tier0 这档;读时务必带着这条天花板,别把它读成"再补几层就能通吃所有品类"。

---

2. 一张端到端流程图:一句话怎么变成一款游戏

⚠️ 这张 16 节点流程图是旧 SAA 路线的历史表示。 2026-06-25 框架 reframe 后,生成框架统一收敛到 AgentScope,SAA 降为最低优先级(留作远期适配验证可插拔的目标),不再是现行生成主线的编排底座。下图保留下来是为了讲清"一句话→游戏"这条流水线的相位结构(分类→设计→生成→构建→验收→发布的固定相位至今有效),但具体的编排框架与节点拓扑以运行时 SoT agentic运行时架构图说(§5.2 控制面)为现行真相。

下面这张图是旧 SAA 路线生成主线的相位全貌。16 个节点不是抽象概念,而是当时图里真实存在的执行单元。读图时抓住三段就好:先理解题面(render→classify→design)→ 再造出东西(generate→scaffold→asset→build)→ 最后反复验收直到合格或放弃(play/player/nreview→modify/repair/escalate→emit/giveup)。

flowchart TB
  Brief["一句话 / 选模板 + 素材"] --> Render["render<br/>渲染请求与上下文"]
  Render --> Classify["classify<br/>判定游戏品类"]
  Classify --> Design["design<br/>产出设计文档 GDD"]
  Design --> Generate["generate<br/>便宜模型生成玩法逻辑"]
  Generate --> Scaffold["scaffold<br/>脚手架出源项目结构"]
  Scaffold --> Asset["asset<br/>生成 / 装配资产"]
  Asset --> Build["build<br/>确定性构建出可玩产物"]
  Build --> Play["play + player<br/>真机运行 + 视觉软门看截图"]
  Play --> NReview["nreview<br/>九门 harness 机制验收"]

  NReview -->|过门| Emit["emit<br/>发布产物 + 落库"]
  NReview -->|可修| Modify["modify / repair<br/>定位并修复"]
  NReview -->|升档| Escalate["escalate<br/>换更强模型重试"]
  NReview -->|彻底失败| Giveup["giveup<br/>显式放弃 + 留证据"]

  Modify --> Generate
  Repair["repair"] --> Generate
  Escalate --> Generate

  Validate["validate<br/>校验中间产物"] -.横切.- Generate

  style NReview fill:#f9e79f
  style Emit fill:#a9dfbf
  style Giveup fill:#f5b7b1

这张图里有几个名词第一次出现,先解释清楚:

• GDD(Game Design Document,游戏设计文档):design 节点的产物。它把"做个游戏"这件开放的事,结构化成一张每一节都硬绑下游工具入参或代码文件的待办清单——资产表喂给资产工具、布局喂给贴图工具、数值合并进配置。它是约束便宜模型不跑飞的核心抓手。
• 品类(archetype):游戏的玩法类型(如平台跳跃、俯视射击、逻辑解谜)。classify 节点先把题面归到某个品类,后续的设计与生成都围绕这个品类的框架展开。
• escalate(升档):当前模型反复失败时,图层会切换到一个更强的模型重试。这是图层显式的"加钱保质量"机制。
• emit / giveup(发布 / 放弃):两个终态。emit 是成功出口——产物落库并进入发布链;giveup 是失败出口——显式放弃并留下证据,绝不交付一款坏游戏。"宁可显式失败,也不交付坏游戏"是这条线的铁律。

整条流程最关键的特征是它是一个带回环的有向图,不是一条直线:验收不过时,nreview 会把控制权交回 modify(确定性修复)、repair(基于经验的修复)或 escalate(升档重试),修完再重新走 generate→build→验收。这个回环是质量的来源,但也正是后面要小心治理的地方——出题的和被考的不能是同一只模型(§4 会讲)。

---

3. 范式原则:游戏是长生命周期的源项目,LLM 是它的工作室

在讲债和路线之前,必须先钉死一条比任何技术债都更根本的范式原则,因为它决定了这条生成主线"什么才算做对了"。这条原则由创始人在 2026-06-17 裁定、2026-06-20 进一步拍板,是整个生成引擎子树的定调。

3.1 范式转变:从"一次性产物"到"长生命周期项目"

过去的做法(称为"旧范式")是:生成 = 产出一坨能玩的打包文件存下来;想修改时就去 diff 这个打包产物——而这条路根本走不通。新范式把这个死结从根上解开了:

旧范式(一次性反模式)	新范式(长生命周期项目)
生成 = 产出一坨可玩的打包文件,存下来	生成 = LLM(工作室)创建并长期维护一个游戏源项目
修改 = 想办法 diff 打包产物(不可行)	修改 = 工作室在源项目上做一次开发迭代,再构建
产物 = 一次性、不可维护的硬编码代码块	规范物 = 结构化、可维护、数据驱动的源项目(像工作室的代码仓)
打包 / 发布是终点	打包 = 一个构建步、发布 = 一次版本发布;项目持续演进

一句话:把游戏建模成长生命周期的软件项目,LLM 是它的工作室;create / modify / extend / build / release / maintain 都是项目生命周期操作。 这从根上化解了"怎么改打包产物"的死结——不碰产物,在源项目上演进,再重新构建。这里的"打包产物"和"源项目"是两个必须分清的东西:打包产物是给玩家跑的最终包,源项目是工作室回头要改的那份真实代码。

为什么源项目必须结构化、模块化、数据驱动?因为工作室(LLM)将来要回来改它。 一份长这样的源项目结构,正是为"可被 agent 快速定位、局部修改、增量扩展"而设计的:

game-project/
├── game.json        # 项目元数据(引擎版本 / 入口 / 品类 / 标题 / 版本)
├── design.md        # GDD:玩法意图 / 机制 / 胜负条件(工作室的"需求与设计")
├── config/
│   ├── params.json  # 平衡参数(数值 / 难度 / 速度)——改这里 = 调平衡,免 LLM
│   └── levels/      # 关卡数据——加一个文件 = 加一关
├── src/             # 模块化游戏逻辑(按系统拆:input / spawn / score / physics…)
├── assets/          # 六类资产:sprite / character / effect / scene / ui / music(引用,非内联)
└── build.json       # 构建配置

这样一来,生命周期里的每种操作都各得其所:create 是脚手架出这个项目;modify 时,换美术 / 调参 / 改关卡是确定性地编辑源文件(免 LLM、秒级),只有改玩法逻辑才让 LLM 重新生成那一个模块;extend 是加文件(additive,即只增不改);build 是确定性地把源项目构建成可玩产物;release 是把构建产物发布为一个版本、过审进入游戏信息流;maintain 是据玩家遥测和反馈,工作室回到项目继续演进——这一步把数据闭环接回了护城河。

3.2 终态硬约束:产物必须是 src/ 工程;gameDefinition 是已废的错误路线

创始人在 2026-06-20 拍下一条不可妥协的终态定调,它直接决定了生成产物"合不合格":

生成游戏的终态产物,必须是一个 src/ 多文件代码工程——结构化、模块化、可导航、agent 能快速定位与探索的真实源码项目。无论游戏简单还是复杂,最终落地的都必须是 src/ 工程。

廉价线最初并不是这么做的。它走的是一条叫 gameDefinition 的路:便宜模型吐一份声明式结构化 JSON,运行时用 new Function(JavaScript 里把字符串当代码执行的机制)直接解释执行,承载整段玩法逻辑的 behavior.code 就塞在这份 JSON 的一个字符串字段里。这条路顶着"声明式结构化源"的名号,内核却是一个声明式数据壳加一坨自由 JS 核——那段 behavior.code 靠 schema 的 additionalProperties 偷渡进 gameDefinition,根本没进任何契约,所以名号只覆盖了外壳的数据字段,逻辑核仍是未受约束的自由 JS;改一行要在字符串里找、agent 无法结构化定位,这恰恰是设计明令反对的"硬编码代码块"。更致命的是它的表达力被运行时焊死在四类几何色块玩具上,好玩好看没有下限托底。2026-06-20 的对抗式裁决揭穿了这层名实不符,2026-06-21 判它为错误路线、删除废弃。

取代它的现行廉价线 = A-model:LLM 在 LittleJS 增强发行版上直接写真 src/ 多文件游戏代码,调 L2 插件库(juice / gamefeel / palettePost 等手感件)给卖相,再用九门 harness 把"是不是真能玩"判定下来。它一步到位兑现了上面那条终态硬约束——产物就是真 src/ 工程,不再有"先吐 JSON 再展开"的中间妥协态,也没有任何"迁移中"或"cutover"。它和 tier2 富游戏线是同一范式(LLM 写真 src/),只是引擎(LittleJS vs Phaser)与表现层复杂度档不同。

这条终态硬约束配一道机制门(doc↔code 兑现门):生成产物要能被自动断言为"存在 src/ 多文件结构、玩法逻辑落在真实源码文件里、不存在'逻辑只以 JSON 字符串形态存在 / 运行时 new Function 跑内嵌串'"。设计声称要 src/,代码就必须可验证地兑现 src/——这道门正是 gameDefinition 那条路过不去、而 A-model 天然满足的那条线。

3.3 六维质量 → 生成产出的硬契约

这条范式原则不是口号,它落到生成产出上是六条可检验的硬约束(对应下表六行,其中"长期 / 可维护"是同一维的两面)。它们共同回答了一个被早期方案忽略的根本问题:生成质量的真标尺不是"这次能不能玩",而是"工作室将来能不能维护它"。

质量	落到生成产出的硬约束
长期 / 可维护	模块化代码 + GDD;工作室能回来定位并改
可扩展	additive 内容模型(加关卡 / 资产 / 模块不重写)
灵活	数据驱动(行为走 config / data,不硬编码)
稳定	确定性构建 + 版本化发布 + 回滚 + 构建门(九门 / 质量门)
简单	轻游戏轻结构,不过度工程(够维护即可)
高效	增量改 + 增量构建;确定性操作免 LLM;复用模块 / 资产

---

4. 现状诊断:我们的债在哪里

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

第一类是策略下沉进机制层。 本该作为可替换数据的策略,被焊死进了不该重编译重部署的代码里,造成三处倒置:

• 模型路由:11 个角色的模型名(便宜打底 + 强档 + 视觉 / 回退位)和每个角色的采样配置,全是 Java 常量,换一个模型要改代码、重新构建。
• prompt 正文:A-model 的生成约定(系统提示、写真 src/ 的写法约定、插件库 API 命名对齐)是 Java 字面量,而另一侧的 Python worker(worker 指实际跑生成的独立工作进程)又镜像了一份。同一份约定存在两个源,这是一个潜在的 split-brain(直译"裂脑",指同一份事实存在两个独立副本、迟早会不一致的隐患)。这条裂缝只要两轨依赖的数据开始分叉,就会立刻变成承重的坑,所以 prompt 要提为单一版本化资产、两轨同读。
• 品类骨架:由 design 节点自己产出,没有外部锚点。

这三处倒置的共同后果是:凡涉及跨 Python 与 SAA 双轨的策略,一旦"策略化"做得不干净,就会从"一处硬编码"恶化成"多处不同步",拆东补西。

第二类是验收 oracle 的 Goodhart 风险——九门是机制地板,不是质量裁判。(oracle 在测试语境里指"判定对错的权威";Goodhart 风险指"一旦一个指标变成目标,它就不再是好指标"——刷指标而非真达标。)九门 harness 判的是机制:能不能装载、跑不跑帧、响不响应输入、到不到终态,全是确定性的,这一层我们确定性地领先,零理由动它。但它有两个真实口子:

• latch 终态语义不分胜负:latch 指"游戏到达了某个终态"的锁存信号。当前它由系统强加(永远期望为真),哪怕游戏弃守排空也能逼出一个游戏结束信号——这意味着一个空壳游戏可以蹭过这道门,而 latch 正是"机制有进展"那一门的承重件。它对"这到底是不是题面要的那个游戏"几乎零鉴别力。
• 出题与被考同源:classify 自产品类、design 自产验收规格,而便宜模型的核心毛病恰恰是连 ball.x、driver:none 这种最基本的东西都会反复写错。让同一只待验模型既出题又答题,验收闭环就有一格没真正断开。

第三类原本是 factory 与 gamedef 双轨并存的债,现已随 gameDefinition 废弃而消解。 曾经有两条生成产线:老的 factory 路(填参装配)和新的 gamedef 路(便宜模型吐结构化中间表示)。这两条都已不是现行——gameDefinition 于 2026-06-21 判为错误路线删除(见 §3.2),廉价线收敛成单一的 A-model 路(LLM 直接写真 src/),不再有"双轨待切换"这件事,也就没有"何时 cutover"这道悬而未决的债。与之伴生的成本侧盲区仍在、且与产线选型无关:generate 节点内部有一条回退链会静默切模型,但它不计入失败计数、也不进升档事件,与图层的 escalate 升档是两套互不相通的机制;这导致"一次失败到底走了几层模型"算不清,而成本归因恰恰依赖这个数——给静默回退链补上 fallbackEvents 进轨迹这件事,A-model 线照样要做。

一处已被实证反掉的误判,记在这里免得重复建设:源项目持久层不是悬空的。game_source_project 的持久层真实存在(V18 建表 + V20 加并发幂等唯一键 uk_game_source_hash,这两个是两道不同的迁移而非同一迁移的两份拷贝),落库与标记构建完成的调用在回调实现里被真正调用(事务外层、按内容哈希幂等)。所以它已经是一等公民,真实缺口只是血缘丰富度和 A-model 路的端到端验证——这是 P2,不是要去补一条根本不存在的落库链。

---

5. 对标 OpenGame:我们缺哪几层

把当前最强的外部开源系统 OpenGame(一个把一句话变成游戏的开源生成系统,源码在 github.com/leigest519/OpenGame)看透之后,落到我们的现状上,真正的差距集中在三层。它们与 §4 的内部债不重叠——内部债是"已有的东西没做对",这三层是"值钱的东西我们还没有"。

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

flowchart LR
  subgraph 我方["绘境AI 生成引擎"]
    G["声明式有向图编排<br/>16 节点 SAA StateGraph"]
    N["九门 harness<br/>机制验收(领先)"]
  end
  subgraph 缺口["OpenGame 证明值钱、我们要补的三层"]
    L1["① GDD 契约 + template_api<br/>把开放题收敛成填空题"]
    L2["② 经验复利层<br/>Debug Skill + Template Skill"]
    L3["③ 资产线 + 语义验收<br/>asset 接 mmx + player 软门做厚"]
  end
  G -. 当零件库落进节点内部 .-> 缺口

第一层缺的是生成约束的厚度——最高价值缺口。 OpenGame 端到端能跑通的根本前提,是它有一套预建模板,外加每个品类一份 hook 清单当"填空靶子"(hook 指模板预留给生成代码挂接的接口点)。它的生成质量不来自强模型自由发挥,而来自把开放问题收敛成填空题:一份 GDD 把"做个游戏"结构化成每一节都硬绑下游工具或代码文件的待办清单。约束便宜模型不跑飞的是三条铁律:数值只能进配置、只用模板已有行为、绝不许编造清单里没有的 hook。而第三条铁律之所以能约束住便宜模型,正是因为有一份明确的 API 清单让它无从编造。

我们这一侧,classify 和 design 节点存在,但品类体系、物理优先的分类提示、GDD 的契约化程度,以及最关键的那份"LittleJS 增强发行版 + 插件库公开 API 清单"当我们的填空靶子——都还没补齐。(LittleJS 是我们选定的轻量 H5 游戏引擎,"增强发行版"指我们在它之上加了一层能力插件库。)没有这份清单,便宜模型一定会编造 API。这一层 OpenGame 抄不来、必须我们自建,而它恰好和"游戏 = 长生命周期结构化源项目"基座、"玩法模板 = 品类框架"的定位是同一个东西。

第二层缺的是经验复利层,我们几乎从零。 OpenGame 真正的护城河是两套同构的离线经验自进化机制,都遵循同一个闭环:完成任务 → 抽取经验 → 去具体化 → 沉淀回本地 JSON 库 → 下次先查库命中复用 → 重复达阈值再升格成可执行规则——纯本地、零向量、零 embedding,本质是基于案例的推理而非检索增强:

• Debug Skill(调试技能) 是一本活协议:数据结构是(错误签名、原因、修复)三元组,签名匹配是纯算法零 LLM,只在"诊断新错"和"归纳新规则"两处兜底调 LLM。最实的一环是——同一个修复在重复出现三次后,会自动升格成"执行前的预校验规则",经验从"救火"升级成"免疫";而且只有跑通验证的修复才进库。
• Template Skill(模板技能) 从一个与具体游戏无关的元模板出发,每完成一个项目跑一条流水线,把具体代码泛化成带 KEEP / copy / hook 分层的模板,以"物理三元组 + 品类名"为匹配键复用整个家族。

我们规划过 Debug Skill 但 MVP 做了简化,Template Skill 那种"从完成的游戏项目反向生长品类骨架库"的能力则完全没有。它对便宜模型尤其划算——每一次签名命中都省一次 LLM 调用,把高频错变成确定性查表。

第三层缺的是资产线,以及偏弱的语义验收。 资产这块,OpenGame 走的是一整套"生成、抠图、视频抽帧、多级回退、清单装配"的重流水线,依赖视频模型 + ffmpeg + 抠图后端——便宜的文生图模型替不了动画质量,这是真壁垒。我们不照抄这套依赖,而是让 asset 节点接已拍板的 mmx-cli(王蓝莓投资人版定的媒体生成工具),大幅降级的部分(静态帧 + 程序音)照它的多级回退思路兜底即可。

语义验收这块要说准一个事实:OpenGame 论文最响的"三轴 VLM 验收"在开源代码里其实并不存在。(VLM = Vision-Language Model 视觉语言模型,指能看图打分的模型。)它的 README 描述得很全(用无头浏览器跑生成的游戏,VLM 沿 Build Health 构建健康、Visual Usability 视觉可用、Intent Alignment 意图对齐三轴打分),但全仓搜不到任何渲染真实像素、真实浏览器或 VLM 打分的代码,只留一句"will be released soon",真实验收只到构建 + 测试。所以单比已开源的东西,我们的真机九门已经更硬。

但这里要分清两层、别就此自满:九门判的是机制(对应 Build Health 那一轴),我们确定性领先;可另外两轴——好不好看、是不是用户要的那个游戏——九门根本判不了,它们在我们这边对应的是 player 软门(用视觉模型看截图打分的软性检查),而 player 软门是软的、跑便宜模型、不成体系,这恰恰是我们的弱项。所以正确动作不是"把九门结果套个三轴外壳就交差",而是把 player 软门那条做厚——OpenGame 论文那套三轴设计,正是这一层值得我们抄的蓝本,哪怕它代码并没放出来。

---

6. 统一演进路线

口径:本节这套演进路线是为 §1 说的那套现存 SAA 实现写的。2026-06-25 框架收敛到 AgentScope 之后,与框架无关的目标(策略外置、验收去自评、经验绑契约不绑引擎、A-model 路达 80% 门)照样成立、随框架继承;其中 SAA 特有的迁移动作(Java 侧 split-brain、SAA 图内加节点、models.yaml 外置的具体落点)属现存实现的收口,不再是收敛后的目标框架计划,读时按此区分。

把内部债和外部缺口合起来,演进沿两条并行的线推进:线 A 向内加固现有架构(把硬编码的策略抽成数据契约、把跨进程对齐点锁成单一事实源、把验收信号补上独立的判定依据);线 B 向外补齐 OpenGame 证明值钱的能力层。

贯穿两条线的总原则有三条,它们是后面所有具体动作的护栏:

1. 不重写任何主干。 裸图躯干、九门、源项目持久化都留着,改的只是策略层外置与验收门加固,而且全部是 additive(只增不改)加 fallback(失败回落)。
2. 所有新增的质量门默认只观测不收紧。 当前是刻意宽门放量在攒数据(开闸两门焊死放行、三门只观测),任何新门若一上来就生效,会立刻掐断这条灰度闭环。所以新门一律默认关闭、只记录轨迹,达标率稳定后再一行翻开。
3. 凡涉及跨 Python 与 SAA 双轨的策略外置,数据契约必须是语言无关的 JSON / YAML、两轨都读它、CI 卡一致性(parity)——否则"策略化"就沦为"跨语言漂移",把一处硬编码换成多处不同步。

两条线不是各跑各的:它们在两个点上解的是同一个问题,必须合并成一处实现,不能各列一遍。下面这张图先把这层关系摆清楚,再分小节展开。(原图里有一道"cutover 里程碑门"——它属于 gamedef 与 factory 双轨切换的旧口径;gameDefinition 已废、廉价线现行单线 A-model,这道 cutover 随之作废,只留作演进史记录。)

flowchart TB
  subgraph LA["线 A · 向内加固(把策略从机制里抽出来)"]
    A1["trace 抽取 + 文件拆分<br/>(纯重构)"]
    A2["★ prompt 同源<br/>解 split-brain"]
    A3["模型外置 models.yaml"]
    A4["latch 终态语义<br/>分胜利 / 弃守"]
  end
  subgraph LB["线 B · 向外补能力(抄 OpenGame 的零件)"]
    B1["★ GDD 契约 + template_api<br/>(最高价值)"]
    B2["Debug Skill<br/>diagnose / repair + checkpoint"]
    B3["Template Skill<br/>按 A-model src/ 重写 + 九门门"]
    B4["资产线接 mmx"]
  end
  subgraph X["两处交汇点(一件事,一处实现)"]
    X1["交汇点一:品类独立交叉校验<br/>= 物理优先分类"]
    X2["交汇点二:player 软门做厚<br/>= 验收去自评"]
  end
  CUT["✗ cutover 里程碑门(已废)<br/>原为 gamedef 双轨切换收口<br/>gamedef 已废 → A-model 单线,无此门"]

  A4 --> X1
  B1 --> X1
  A4 --> X2
  B1 --> X2
  A2 --> CUT
  X1 --> CUT
  X2 --> CUT
  style A2 fill:#fde68a
  style B1 fill:#fde68a
  style CUT fill:#fca5a5

关键路径(图中黄色 ★)是一条线:prompt 同源(解 split-brain)→ 质量信号可信(两交汇点)→ A-model 路成功率达 80% 门。原先这条线的终点是一道 cutover 里程碑门(为 gamedef 双轨切换收口),gameDefinition 废弃后不再需要切换动作,达标门本身仍在——A-model 单线把成功率做到 80% 才算这条质量线收口。下面三小节依次展开线 A、线 B、两处交汇点。

6.1 线 A:加固现有架构

事项	做什么	性质
trace 抽取与文件拆分	把内联在近九百行调度器里的轨迹抽取逻辑(约 280 行)抽成独立纯函数 SaaTraceExtractor 补单测;把过载的 SaaStudioNodes 单文件(一千六百多行)按职责拆包。调度器从近九百行瘦到约六百行	纯重构、零行为变更
prompt 同源,解 split-brain	把 A-model 的生成约定(写真 src/ 的系统提示与插件库 API 约定)从 Java 字面量提为 contracts/prompts 下的版本化资产,让 Java 与 worker 都从这一份资产读、CI 卡到字节一致	线 A 关键路径起点
模型外置	把 11 个模型名 + 每角色采样配置外置为 models.yaml,加载逻辑从配置读、常量作 fallback	契约先行
latch 终态语义	区分胜利与弃守 / 超时——见交汇点(§6.3)	线 A 唯一 P0
cutover(切换) 已废	原计划:gamedef 路成功率达 80% 后切为默认产线、二分退役 factory。gameDefinition 已判错误路线删除,廉价线现行单线 A-model,无双轨可切——此里程碑作废。 它原本捎带的两件事仍要做、且与产线选型无关:补成本侧盲区(给静默回退链加 fallbackEvents 进轨迹)、修诊断盲区(把全归一类的失败原因扩出子码,注意 DB 列宽 32 字符约束)	线 A 收口里程碑

prompt 同源这一步一举两得:既根除了那处 P0 级 split-brain,又坐实了三段式缓存的前缀——前缀字节一致才能命中,实测命中率有 76% 到 93%。这里有一条硬纪律:split-brain 未解之前,不得拿 worker 线的数据去做产线质量决策。

6.2 线 B:补齐能力层

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

• GDD 契约 + template_api(最高价值项)。 把物理优先分类的系统提示(含易错例)和品类体系做成 classify 节点;把 GDD"六节每节硬映射下游"的契约、三铁律做成 design 节点。但有一个范式级前提必须先立:先得有那份"LittleJS 增强发行版 + 插件库公开 API 清单"当填空靶子,否则 hook 完整性无从约束,便宜模型必然编造 API。
• Debug Skill 落地为 diagnose / repair 节点 + checkpoint(检查点持久化)。 把(签名、原因、修复)三元组账本、分组阈值升格这套机制对应到 SAA 图里。签名匹配纯算法零 LLM,便宜模型只在两处兜底,每次命中省一次 LLM 调用。种子协议里的错误码要从 OpenGame 用的 Phaser 引擎换成我们的 LittleJS 运行时和九门错误码,但结构原样可用。
• Template Skill 按 A-model src/ 重写,且入库前过九门质量门。 抄它的范式,但实现整体重写(它的物理信号正则和 hook 命名死绑了 Phaser;我们抽取的是 A-model 写出的真 src/ 模块骨架,不是 JSON 结构)。更关键的是:原版入库前没有任何回验门,带病的骨架会直接沉进库;我们必须给它加一道"入库前过九门或可构建校验"的质量门——这恰恰是我们相对它的强项,把我们最硬的东西用在它最弱的地方。另要预警原版一个硬缺口:这套进化只有单调累积、没有遗忘 / 淘汰 / 冲突消解,也没有向量检索,家族一多会退化;等品类规模上来,我们可能需要补一层真正的检索。
• 资产线接 mmx。 asset 节点接 mmx-cli 替代那套重流水线,降级部分照多级回退思路兜底。顺带把它的确定性 bitmask 贴图(纯算法、与模型无关,用确定性算法绕开模型的空间推理)直接搬进来——这是 OpenGame 一个聪明的工程判断,几乎零成本可得。

建 Debug Skill 与 Template Skill 这两套经验库时,有一条容易被忽略、但想得很深的设计约束要先立住:经验要绑契约、不绑引擎,否则一次换引擎就会把攒了很久的经验库抹平(创始人 2026-06-22 历史回收判定捡回)。 我们的引擎本就是"模板携带的可换实现选项"(Tier1 现在是 LittleJS,将来可能换),如果每条经验都和某个引擎的具体写法死绑,那换引擎那天经验库就归零、白攒。正确的做法是把每条 Debug / Template 经验强制拆成两层:一层是 invariant(不变量)层——失败类别(failureClass)、品类原型(archetype)、物理画像、契约级的事前预校验(proactive check),这些与具体引擎无关,换引擎 100% 继承;另一层是 engineBinding(引擎绑定)层——具体的修复 patch、骨架代码、引擎特定的检查,这些换引擎时需要 re-derive(重新推导)。这样切引擎的迁移路径就清楚了:invariant 层 100% 继承、绑定层按新引擎 re-seed(重新播种),再过一道契约无关的黄金集 parity 门——拿一组与引擎无关的黄金用例在新旧引擎上各跑一遍、比对通过率,达标才切默认。这条约束此前在 OpenGame 对照里讲 Debug/Template Skill 时完全没带,但它和"引擎是可换实现选项"这条原则同根,落地经验库时必须先按这个两层结构设计,事后再拆代价极大。

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

线 A 和线 B 有两处在解同一个问题,必须合成一项实现:

• 交汇点一:品类的独立交叉校验。 线 A 的"品类独立交叉校验"和线 B 的"物理优先分类"指向同一件事。内核是:保留 classify / design 自产骨架的生成路径,但验收的判定依据绝不能押在同一只待验模型的分类输出上。做法是引入一个独立于 design 的交叉校验——从题面关键词、从 player 软门的视觉反推品类,与 design 自报的品类比对,不一致即降权乃至拒发。线 B 的物理优先分类(看重力方向、视角、移动方式而非品类名,比如"Terraria 是平台跳跃不是俯视类"这类易错例)正好为这个独立校验提供高质量判定依据。一件事,一处实现。
• 交汇点二:把 player 软门做厚,验收去自评。 线 A 的"九门去自评闭环"和线 B 的"补强 VLM 语义层"是同一件事。九门那一层(机制)已领先,不动它;要补厚的是判"好不好看、是不是要的那个游戏"的 player 软门。动作是让这条软门更系统、可复现:做成独立于生成方的交叉校验,甚至一个离线评测基准,蓝本就是 OpenGame 论文那套三轴。配套把"模型靠运行时内置基元蹭过门、还是真写了交互逻辑"的占比,以及 player 自评与九门判定的交叉一致性都进轨迹,长期背离即告警——用数据积累"门的有效性"证据。

6.4 统一迁移序列

下面的迁移序列在本节内自洽:阶段划分见下图与逐条说明,标 ★ 的是关键路径,标 [新增] 的是 OpenGame 对照带来的新工作项。早期承接它的三份后端执行计划已并入 git 历史,不再单列编号。

flowchart LR
  P0["阶段0<br/>零风险立桩<br/>收敛常量来源"] --> P1["阶段1<br/>线A·重构<br/>抽 TraceExtractor"]
  P1 --> P2["阶段2 ★<br/>线A·解 P0<br/>prompt 同源"]
  P2 --> P3["阶段3<br/>线A·契约先行<br/>模型外置 + 失败子码"]
  P3 --> P4["阶段4 ★<br/>质量加固·全 flag-off<br/>latch + 两交汇点"]
  P4 --> P5["阶段5 ★<br/>A-model 路达 80% 门<br/>(原 cutover 切换动作已废)"]
  B1["阶段B1 ★ [新增]<br/>GDD 契约 + template_api"] -.越早越好.-> P4
  B1 --> B2["阶段B2 [新增]<br/>Debug/Template Skill + 资产线"]
  B2 -.支撑.-> P5

• 阶段 0(零风险·立桩):收敛 job 核心字段名、状态键集、轨迹键集的常量来源。这里要切分清楚——Java 内部键名可以收敛到常量类,而 Java 与 Python 之间的轨迹键只能靠契约和测试夹具对齐,不能并入 Java 常量类(这是一处假锚)。纯重命名,无行为变化。
• 阶段 1(线 A·重构):抽 SaaTraceExtractor、拆 SaaStudioNodes 分包,调度器瘦身,零行为变更。
• 阶段 2 ★(线 A·解 P0):A-model 的生成 prompt 约定提为版本化资产,两轨读它、CI 卡字节。关键路径:split-brain 未解前不得拿 worker 线数据做产线质量决策。
• 阶段 3(线 A·契约先行):模型外置 + CI 一致性校验;失败原因扩子码(注意列宽 32);把作业对象在调度器边界 record 化。全 additive 加 fallback。
• 阶段 4 ★(质量加固·全 flag-off 落轨迹):① latch 终态语义区分胜利与弃守 / 超时(P0);② 交汇点一(品类独立交叉校验);③ 交汇点二(player 软门做厚 + 可观测化);④ fallbackEvents 入轨迹。全部默认关闭、只观测、不改放行行为。
• 阶段 B1 ★[新增]:GDD 契约 + template_api(LittleJS 插件库公开 API 清单),classify 与 design 节点契约化。这是约束力的靶子和最高价值杠杆,建议优先排。其中"物理优先分类"与阶段 4 交汇点一是同一处实现,不重复建。
• 阶段 B2 [新增]:Debug Skill 落 diagnose / repair 节点 + checkpoint;Template Skill 按 A-model src/ 重写并强制入库前过九门;asset 节点接 mmx 并搬入确定性 bitmask 贴图。可在 B1 之后并行。
• 阶段 5 ★(A-model 路达 80% 门):A-model 成功率做到 80% 门后,把"失败即拦截"的门翻开、闭合 modify"从源真构建"。原计划里这一步还含"切默认产线、二分退役 factory"的 cutover 切换动作——gameDefinition 与 factory 双轨都已废、廉价线现行单线 A-model,切换动作作废,只留达标门本身。依赖阶段 2(prompt 同源)、阶段 4(质量信号可信)与 80% 达标率三个前置。

关键路径是一条线:阶段 2(prompt 同源解 split-brain)→ 阶段 4(质量信号可信)→ 阶段 5(A-model 路达 80% 门)。 阶段 0 / 1 / 3 可并行。按价值排,最该立刻动手的三件依次是:先补 template_api 与 GDD 契约(B1,一切约束的靶子)、再把 Debug Skill 落成 diagnose / repair + checkpoint、然后把 Template Skill 按 A-model src/ 重写并加九门质量门。

6.5 两条远期方案的补记(创始人 2026-06-22 历史回收判定捡回)

有两条早期讨论过、被列为"次要"后没进现行档的方案,这里各记一笔,免得它们被彻底丢掉、将来又从头讨论一遍。两条都是远期项,现在不排期。

best-of-N 多候选并行(抬成功率的一条直接杠杆,但有硬前置和两条警示)。 思路是同一 brief 同时跑 K 个候选、取过门质量最高的那一个交付——在 60% 实测基线下,这是抬成功率最朴素有效的办法之一。但它落不了,卡点不在算法而在架构:它的硬前置是先解掉"整图串行"约束(SaaGraphDispatcher 单线程 + Semaphore(1) 包住整条 graph.invoke()、build/play 子进程用固定端口,详见 SAA编排 §整图串行约束)——整图串行下 K 个候选只能排队跑,墙钟退化成 K 倍,并行优势荡然无存。即便将来解了串行、真要上 best-of-N,还有两条评审给过的警示要先认:一是 K 个候选高度相关(同一便宜模型、同一 brief),挑最优带来的成功率上界压在约 94% 以下,不是"K 越大越接近 100%";二是成本必须对账——K 路并行是 K 倍的 LLM 开销,墙钟约 K×3.5–16min,这笔账要落进成本台账算清,别糊里糊涂烧钱。所以 best-of-N 是"先解 037 串行、再谈、且上之前先认清上界与成本"的远期项。

实例级引擎复用(信息流场景的冷启动优化)。 当前每跑一款游戏都要重新初始化引擎、重建 WebGL 上下文;在信息流这种"一款接一款连续玩"的场景里,如果能让一个常驻 runner 跨游戏复用同一个引擎实例,省掉反复的 init 和上下文重建,对冷启动体感收益很大。它没现在做,有两个原因:一是它被明确标为"等 S2 主考实测把它逼出来再上(2.x)"的有意延后项;二是它受候选引擎的 destroy 卫生制约——引擎能不能干净地销毁、不漏内存,直接决定实例能不能安全复用,而这恰恰是 LittleJS 选型时的一个考量因素(Phaser 的 destroy 泄漏 issue #2138/#5456 当年正是它落选因素之一)。记这一笔,是因为它是一条想清楚了、但有意压后的性能路径,别在做冷启动优化时把"复用实例"这个选项忘掉、也别忘了它对 destroy 卫生的依赖。

---

7. 我们刻意不做的

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

• 不专训专用大模型(GameCoder-27B)。 OpenGame 论文把一个为游戏定制的 27B 代码模型当支柱,但它的权重、训练码、数据都不在仓里,实测代码默认接的反而是通用强模型,设一个环境变量就能换。这恰恰证明它的框架被刻意设计成与模型无关——专用模型不是跑通的必要条件。我们的路线明确是便宜通用模型 + 门兜底,质量缺口靠模板约束加 Debug Skill 补。
• 不把 VLM 当硬门。 player 软门要做厚,但它的判定是视觉模型的概率性判断,不能用来定一次生成"算不算完成"。把软判定提成硬门,会直接撞上铁律——"完成"必须由确定性的门来定。所以 VLM 这条线只做软门、做离线基准、做交叉校验与告警,产出的是"门的有效性"证据和质量趋势,绝不进放行的确定性判定。九门是机制地板,VLM 是质量观测,两者职责不混。
• 不上重型沙箱。 OpenGame 的命令执行是重型的(独占进程组、信号管控、容器沙箱,深度绑定 Node 生态),这是它"模型自由写代码再跑构建看报错"那套自主循环的物理基座。我们走图编排,build 节点职责窄得多,MVP 阶段不需要这么重的沙箱;将来真需要,Java 侧自建等价物即可,绝不移植那套 JS 适配。同理 MCP(模型上下文协议)走 SAA 自带支持,不搬 OpenGame 那套 JS 适配层——何况 OpenGame 的游戏生成能力本就不来自 MCP,而来自内置确定性工具加工程模板。

---

8. 三级生成与契约体系(蓝图锚点)

上面讲的是 MVP 阶段的生成主线现状与近期演进。从更长的产品视角看,生成能力被规划为三级(L1/L2/L3),对应创作者梯度和三条收入线。这部分是蓝图级锚点,这里只给骨架,细节在源档:

维度	L1 模板成游戏	L2 模板扩玩法	L3 全栈造游戏
agent 职责面	填参 + 文案 + 资产变体选择	受控补丁面改码 + 关卡 + 生成资产	全内容域,多 agent 分工
时延 SLO	P75 ≤ 30s	P75 ≤ 10min	小时级,阶段进度可见
对应人群	小白(一句话)	进阶创作者(资产 + 对话)	专业 / B 端

预算红线以运行时 SoT 为唯一源,别用本表的旧数值。 上表原列过一栏按级的工程预算门(L1 ≤¥0.15 / L2 ≤¥5 / L3 ¥50~500),已撤下。每次生成的成本硬闸现在统一收口在运行时 SoT agentic运行时架构图说 §5.2 / §5.7:便宜档 per-gen <¥10、复杂档 per-gen <¥50(图 / 音另算)——这是唯一的红线数值源,本表不再自带预算数字,凡谈 per-gen 成本闸都 repoint 到那里。

L1/L2/L3 与 Tier0/1/2 是两条不同的轴,别混用。 本表的 L1/L2/L3 是创作者能力 / 产品复杂度档——它回答"谁来造、agent 替创作者干多少活、卖给哪类人、接哪条收入线",梯度从小白填参一路到 B 端全栈。它和 2026-06-25 reframe 的 Tier0/1/2 不是同一个分级:后者按 AI 参与深度切分生成档,且引擎(LittleJS / Phaser)只是按复杂度选的实现变体、不是分档轴。两套分级各自成立、视角不同,引用时务必标清是哪条轴,不要把"L2"当成"Tier2"、也不要把这里的产品档当成 reframe 的 AI 深度档。(2026-06-25 创始人拍板:两套各自保留、不合并;对应关系见下表。)

L1/L2/L3(产品 / 创作者轴)↔ Tier0/1/2(技术 AI 深度轴)对应关系(2026-06-25 拍板:两套保留、不合并):

这套	分级依据	回答什么	三级	大致对应另一轴(非 1:1)
L1/L2/L3	创作者能力 + 产品复杂度 + 收入线	谁来造、agent 替创作者干多少、卖给谁	L1 填参成游戏(小白)/ L2 受控补丁扩玩法(进阶 · 订阅付费墙)/ L3 全栈造游戏(专业 · B 端)	L1→偏 Tier0/1;L2→Tier1/2 间;L3→Tier2
Tier0/1/2	AI 参与深度(引擎按复杂度选、非分档轴)	AI 写进游戏的内容 / 代码多深	Tier0/1 轻-中档(LittleJS)/ Tier2 富游戏档(Phaser)	Tier0/1→L1/L2;Tier2→L2/L3

两轴非 1:1:同一创作者档可触发不同 AI 深度的生成,反之亦然;引用时各按各轴标清,别把「L2」当「Tier2」。

一条重要的模板哲学拍板(2026-06-12):模板 = 引擎能力插件(碰撞 / 粒子 / 物理 / 手感等,LittleJS 二次开发件),不含玩法 / 美术 / 关卡 / UI——这四者是 agent 生成域。玩法模板层被废除(它是同质化的根源)。所以"玩法模板"在本项目语义里 = 品类引导框架,影响生成 prompt 与脚手架,不是一个可执行的游戏壳。

上面那张表的"预算档"一栏是工程门(成本和时延的硬上限),但同一个预算还有一层产品面,要补上、别只当工程数字看(创始人 2026-06-22 历史回收判定捡回):预算即产品——绘豆与会员档决定创作者能用到哪一级生成、有多少额度,而且这个预算要对用户透明。 创作者看到的不是"L1/L2/L3"这种内部分级,而是"我这个档位能造什么样的游戏、还剩多少次"。这一层把生成级别直接接到了两条收入线上:更高的生成级别(L2 扩玩法、L3 全栈)是订阅会员的付费墙,绘豆额度是用量计费的入口——创作者梯度在这里就是一条订阅转化漏斗(与同域那条"用生成级别做付费墙"是一脉)。配套还要把第一笔收益的激活路径讲给创作者:从"生成一款游戏 → 发布进信息流 → 拿到第一笔广告分成"这条链路要有明确引导,因为创作者留存的第一道坎就是"我造的东西到底能不能赚到钱"。这条产品面此前在生成引擎档没落点,而它恰恰是订阅与广告两条收入线的创作侧入口,值得记一笔。预算的具体数值(绘豆定价、各档额度、付费墙怎么卡)以变现战略档为准,本节只钉死"预算是产品、级别即付费墙、要引导第一笔收益"这条口径。

支撑这套体系的是第 9 契约组(生成工厂契约包,9a~9g):9a 模板协议(能力插件清单)、9b 作业与状态、9c 评估与就绪评分、9d 全链 trace、9e 代码补丁、9f 资产血缘、9g 收益归因。配套还有一个生成控制平面(配额 / 计费 / 背压 / 取消 / 幂等 / 补偿 / 防刷 / 降级——没有控制面的 agentic 系统会同时烧钱、压垮环境、放大滥用),以及一套双轨灰度矩阵(工厂路径按品类 × 人群灰度,黄金评估集通过率 ≥ 80% 且灰度 7 天错误率达标才切默认,跌幅 > 5pp 或破红线自动切回)。L2 起代码不可信,有一套七层信任边界(补丁面白名单、依赖锁定、静态安全门、构建隔离、运行取证、发布隔离、代码补丁契约)——细节都在源档,不在此展开。这里的"生成控制平面 / 双轨灰度矩阵"是蓝图级骨架;它的现行四组件设计(配置注册表、观测 / 审计仓、D12 运行治理门、管理面 UI,三档生成共用)在同目录运行时 SoT 运行时架构 SoT(§5.2 / §一),以该档为现行口径。

---

9. 源档导航

本文档是生成引擎子树的策展层主档,把源档合成了一张可读的全景。要看更深的设计推演、逐条裁决与证据,从下面进去:

源档	回答什么
生成运行时架构图说	三档统一的运行时架构 SoT:adapter 协议层(A1–A13 固定 + B 类可插拔)、三档两引擎实例(AgentScope 一套框架;轻-中档 LittleJS、最高档 Phaser;SAA 降最低优先级、留作远期适配验证)、8 facet、采标准(A2A/MCP/OTel/microVM/Langfuse)。原 16 份图说/详设 + 设计合理性裁决(Tier0 部分合理裁决与 A-model 转向)已并入此 SoT
prompt 治理 / 验收门 / 数据飞轮	另三份设计 SoT:prompt/配置治理(采 Langfuse 热取)、对外开闸放行 6 门、数据护城河
本文 §4–§7(现状诊断 + OpenGame 对标)	旧 SAA 16 节点双轨演进路线的有效结论已并入 §4–§7 并按 A-model 重写,§4–§7 即现行权威;演进史在 git
本文 §3(长生命周期范式)	"游戏 = 长生命周期源项目、LLM as 工作室"范式的完整裁定与契约 delta 已自洽落在 §3,§3 即现行权威源;裁定史在 git
本文 §8 + 需求清单附录	三级生成、第 9 契约组、控制平面、灰度矩阵已在 §8;29 条意图基线全量冻结进需求清单附录;裁定史在 git

两条线统一的运行时架构 = 单一 SoT(2026-06-24 收敛):tier2 富游戏自治轨(AgentScope·Phaser)与廉价线(SAA·LittleJS)的运行时架构——adapter 协议层(A1–A13 固定 + B 类可插拔)、两实例、8 facet、采标准(A2A/MCP/OTel/microVM/Langfuse)——已收敛进 生成运行时架构图说。原先散在本子树的 tier2 四份(自治富游戏引擎 / agentic 集成架构 / tier2 实现详设 / tier2 四层工程架构)、SAA 编排、SAA 能力 API、开闸接线、引擎与运行时、固定游戏架构、设计合理性裁决等共 16 份已并入该 SoT,原路径留 tombstone 指针重定向。

看图入口(原「生成引擎图说」总入口已并入本 README):P0 四张电梯图——全局两线与 tier 体系 assets/07-全局两线与tier体系.svg、游戏=长生命周期源项目 assets/08-长生命周期源项目.svg、廉价线端到端 assets/09-廉价线端到端.svg、数据飞轮全景 assets/10-数据飞轮全景.svg;tier2 运行时 36 张细图在 生成运行时架构图说;子系统图在 验收门 / prompt治理 / 数据飞轮 / OpenGame对照 各档内。

纪律:本档是生成引擎的策展层 SoT——读它 = 当前真相。带日期的源档是留痕层,记录设计如何演进至此;两者职责不同,不互相重复。当现行真相与某份带日期的源档冲突时,以本档与它引用的最新裁定为准。

---

验证状态:本文档为架构策展文档,由四份已评审源档(含 2026-06-20 设计合理性裁决)合成,未改任何代码。承重硬事实(V18 建表 + V20 加并发幂等唯一键、prompt registry 已存在、SAA 16 节点、九门、80% 门、per-gen 预算闸〔便宜档 <¥10 / 复杂档 <¥50,以运行时 SoT §5.2 为唯一源〕、P75≤30s 时延门、76%–93% 缓存命中、OpenGame 结论锚在其真源码、Tier0 范式定性锚在裁决档)均沿用源档已抽查属实的结论;品牌已统一为"绘境AI"。

---

10. 待补设计:数据飞轮的生成侧落点(创始人 2026-06-21 判定补充)

正式设计稿已出:数据飞轮.md(含完整 contract-first 新建项清单、三条飞轮的分期落地与硬依赖、6 个待创始人拍板的开放问题)。本节保留立位与范围摘要,细节以正式稿为准。

护城河逻辑里"资产沉淀 + 网络效应 + 数据"三层,在生成侧本来有一组具体工程动作。创始人在意图基线(HJ-GEN-001)里亲拍过"全采纳",收窄到 Tier0 当下产线时丢掉了,现行档没有落点。这一节先把要补的设计立位,等范围定了再展开成正式设计。

要补的是三条互相咬合的飞轮:

• 创作者资产库 → 资产市场:创作者生成游戏时沉淀下来的素材、配置、玩法骨架,能复用、能流通,长成搬不走的资产层。
• 玩家 → 创作者的 remix(带溯源链):玩家在信息流里看到一款游戏,直接发起"做一个同款",生成时带上溯源,把消费侧流量导回创作侧——这是网络效应飞轮的核心动作(对应需求清单 P-FED-12 同款创作)。
• 生成全量 + 收益数据回流训练语料:生成全过程数据,加上线上真实的收益与留存数据,回流成训练语料,反过来抬升生成质量与商业化判断。现行的进化语料只覆盖了生成侧自增强,漏了收益回流这一半。

范围(创始人 2026-06-21 定:三条全做):三条飞轮都要,但落地仍有先后依赖——

1. 溯源链 + 同款创作:feed 卡片加"做同款"入口,生成时记血缘(原作 / 原作者),试玩页展示溯源。最轻、不依赖新支付,先落。跨 feed + studio + 生成侧。
2. 创作者资产库 → 资产市场:把生成沉淀的素材 / 配置 / 玩法骨架做成可检索、可复用、可流通的资产层。依赖素材契约(P-MAT)与授权 / 分成支付,排在素材中心之后。跨 素材 + trade + studio。
3. 收益回流训练语料:生成全过程数据 + 线上收益 / 留存数据,回流成训练语料,反哺生成质量与商业化评分。依赖数据管线,作为数据线(②自有端内测)成型后的增量。跨 telemetry + trade + 生成侧。

下一步:由我出正式设计稿(接进本生成引擎子树),前端同款创作入口与 admin 落点随稿一并定;代码执行归 Mac。