docs(生成引擎): gamedef=废弃错误路线 reframe — 8 banner + README §3-6(opus 代理)
创始人:gamedef 已删除/失效/错误路线。opus 代理 reframe(我核验 banner+README §3-6):
- 8 个 🚧 banner:「gameDefinition→src 终态迁移(plan 2026-06-18-001)」→「gameDefinition
已废(错误路线),现行=A-model 写真 src/;tier2 建设中」
- README(生成引擎):§3.2 终态硬约束改「gameDefinition 是已废错误路线」+ A-model 取代;
§4 第三类「factory/gamedef 双轨债」标随 gamedef 废弃消解;§6 cutover 里程碑门标作废
(✗ cutover 已废 → A-model 单线无双轨可切);线A/线B 能力工作对 A-model 路保留
- OpenGame/WG1/验收门/架构README banner 同改
门:全仓死链 0。(broader/沙箱档残留下一 pass)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
452d13d247
commit
95d34c03f5
@ -46,7 +46,7 @@ flowchart LR
|
||||
|
||||
### 架构域 · 生成引擎旗舰子树
|
||||
|
||||
生成引擎是绘境AI 护城河的关键路径,内容最厚,单独成一棵子树。**🚧 注意:这块架构正处于演进中**(gameDefinition→`src/` 终态迁移 + 产线化 plan `2026-06-18-001` U1–U4),子树内标注的现行结论可能随推进变化,以最新裁定 / plan 为准:
|
||||
生成引擎是绘境AI 护城河的关键路径,内容最厚,单独成一棵子树。**🚧 注意:这块架构正处于演进中** —— 廉价线 **gameDefinition 已废(错误路线),现行 = A-model 写真 `src/`**(LLM 在 LittleJS 增强发行版上直接写真多文件源工程 + 调插件库 + 九门 harness 兜底);tier2 富游戏自治轨建设中(0 号 spike accept)。子树内结论可能随推进变化,以运行时 SoT [`agentic运行时架构图说`](架构/生成引擎/agentic运行时架构图说.md) 与最新裁定为准:
|
||||
|
||||
| 子文档 | 讲什么 |
|
||||
|---|---|
|
||||
|
||||
@ -405,7 +405,7 @@ erDiagram
|
||||
|
||||
| 文档 | 回答什么 |
|
||||
|---|---|
|
||||
| [生成引擎](生成引擎/) 🚧 | **架构演进中**(gameDefinition→`src/` 终态迁移、产线化 plan 2026-06-18-001 U1–U4)。生成主线的深层架构:SAA 16 节点拓扑、加节点方法、new-api 接入、checkpoint 框架坑、dispatcher 契约、九门 harness。此外还有待 0号 spike 验证的 tier2 富游戏自治轨三档——引擎与范式见 [`生成引擎/自治富游戏引擎.md`](生成引擎/自治富游戏引擎.md)、两条生成线共用的控制 / 管理面见 [`生成引擎/agentic集成架构.md`](生成引擎/agentic集成架构.md)、spike 怎么跑见 [`生成引擎/tier2实现详设.md`](生成引擎/tier2实现详设.md) |
|
||||
| [生成引擎](生成引擎/) 🚧 | **架构演进中** —— 廉价线 **gameDefinition 已废(错误路线),现行 = A-model 写真 `src/`**;tier2 富游戏自治轨建设中(0 号 spike accept)。生成主线的深层架构:SAA 16 节点拓扑、加节点方法、new-api 接入、checkpoint 框架坑、dispatcher 契约、九门 harness。两条线统一的运行时架构 SoT 见 [`生成引擎/agentic运行时架构图说.md`](生成引擎/agentic运行时架构图说.md) |
|
||||
| [产物执行沙箱](产物执行沙箱.md) | 生成出来的游戏(不可信代码)怎么在浏览器里被隔离着安全跑:取包 / sha256 校验 / iframe+CSP 隔离 / postMessage 双校验 / SDK 受控面;沙箱与"插件↔引擎"受控面是两条正交边界 |
|
||||
| [契约总览](契约总览.md) | 全部契约族的导航与口径收口:有哪几类、各落哪、各算第几、怎么镜像同步到代码、防漂移门有没有 |
|
||||
| [前端域](../前端/) | game-studio / game-admin 的前端设计体系、组件分层、SDK 源码组织、运行时容器 |
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# OpenGame 对照 · 外部标杆深读
|
||||
|
||||
> 🚧 **架构演进中** —— 生成引擎子树正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中,文中标注的现行结论可能随推进变化;以子树 [README](README.md) 与最新裁定 / plan 为准。
|
||||
> 🚧 **架构演进中** —— 廉价线 **gameDefinition 已废(错误路线),现行 = A-model 写真 `src/`**;tier2 富游戏自治轨建设中(0 号 spike accept)。文中结论可能随推进变化,以子树 [README](README.md) / 运行时 SoT [`agentic运行时架构图说`](agentic运行时架构图说.md) 与最新裁定为准。
|
||||
|
||||
> **这是什么**:绘境AI 生成引擎对外部最强开源标杆 **OpenGame** 的源码级深读,以及由此照出的复刻缺口。它回答两个问题——"**OpenGame 到底是怎么把一句话变成游戏的**",以及"**它身上哪三层东西值钱、我们还没有**"。
|
||||
> **给谁看**:负责生成主线的工程师、做技术选型与对标的架构评审、想看清护城河关键路径上"我们与最强开源系统差在哪"的人。
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# 生成引擎 · 设计主文档
|
||||
|
||||
> 🚧 **架构演进中** —— 本子树描述的生成架构正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中;文中标注的现行结论可能随 plan 推进变化。
|
||||
> 🚧 **架构演进中** —— 廉价线 **gameDefinition 已废(错误路线),现行 = A-model 写真 `src/`**;tier2 富游戏自治轨建设中(0 号 spike accept)。文中结论可能随推进变化,以子树 [README](README.md)(本档)/ 运行时 SoT [`agentic运行时架构图说`](agentic运行时架构图说.md) 与最新裁定为准。
|
||||
|
||||
> **这是什么**:绘境AI 生成引擎子树的设计主文档,回答"**一句话怎么变成一款可上线的游戏**"这条技术主线——它的现行架构、要往哪走的演进路线,以及贯穿全程的一条范式原则。
|
||||
> **给谁看**:负责生成主线的工程师、新加入这条线的同事、架构评审、做尽调时想看清护城河关键路径的人。
|
||||
@ -106,21 +106,17 @@ game-project/
|
||||
|
||||
这样一来,生命周期里的每种操作都各得其所:**create** 是脚手架出这个项目;**modify** 时,换美术 / 调参 / 改关卡是确定性地编辑源文件(免 LLM、秒级),只有改玩法逻辑才让 LLM 重新生成那一个模块;**extend** 是加文件(additive,即只增不改);**build** 是确定性地把源项目构建成可玩产物;**release** 是把构建产物发布为一个版本、过审进入游戏信息流;**maintain** 是据玩家遥测和反馈,工作室回到项目继续演进——这一步把数据闭环接回了护城河。
|
||||
|
||||
### 3.2 终态硬约束:产物必须是 src/ 工程,gameDefinition 只是脚手架
|
||||
### 3.2 终态硬约束:产物必须是 src/ 工程;gameDefinition 是已废的错误路线
|
||||
|
||||
创始人在 2026-06-20 拍下一条**不可妥协的终态定调**,它直接决定了生成产物"合不合格":
|
||||
|
||||
> **生成游戏的终态产物,必须是一个 `src/` 多文件代码工程——结构化、模块化、可导航、agent 能快速定位与探索的真实源码项目。无论游戏简单还是复杂,最终落地的都必须是 src/ 工程。**
|
||||
|
||||
由此必须诚实纠正一处此前的认知偏差。当前实现里有一个叫 **gameDefinition** 的 JSON 中间表示——它把整段玩法逻辑塞进 `behavior.code` 这个 JSON 字符串字段,运行时用 `new Function`(JavaScript 里把字符串当代码执行的机制)直接解释执行。这恰恰是设计明令反对的"硬编码代码块":改一行要在字符串里找、agent 无法结构化定位。所以两者的关系在此一次性钉死:
|
||||
廉价线最初并不是这么做的。它走的是一条叫 **gameDefinition** 的路:便宜模型吐一份声明式结构化 JSON,运行时用 `new Function`(JavaScript 里把字符串当代码执行的机制)直接解释执行,承载整段玩法逻辑的 `behavior.code` 就塞在这份 JSON 的一个字符串字段里。这条路顶着"声明式结构化源"的名号,内核却是一个声明式数据壳加一坨自由 JS 核——那段 `behavior.code` 靠 schema 的 `additionalProperties` 偷渡进 gameDefinition,根本没进任何契约,所以名号只覆盖了外壳的数据字段,逻辑核仍是未受约束的自由 JS;改一行要在字符串里找、agent 无法结构化定位,这恰恰是设计明令反对的"硬编码代码块"。更致命的是它的表达力被运行时焊死在四类几何色块玩具上,好玩好看没有下限托底。2026-06-20 的对抗式裁决揭穿了这层名实不符,**2026-06-21 判它为错误路线、删除废弃**。
|
||||
|
||||
- **终态产物 = src/ 工程**(不可妥协);
|
||||
- **gameDefinition = 通往 src/ 的中间妥协态**——妥协只允许在"输入端"(让便宜模型先产一个极简的声明式描述,因为便宜模型确实更擅长产这种结构),**绝不允许妥协在"产物端"**;它必须经过一道真实的"gameDefinition 编译 / 展开成 src/ 工程"的构建,而不是停在 JSON 里被 `new Function` 跑掉;
|
||||
- **当前实现(JSON 内嵌 JS 串 + `new Function` 解释执行)= 已知偏离终态的债**,缺的正是"gameDefinition → src/"产物侧这一段展开。更尖锐的一处名实不符:**承载 100% 玩法逻辑的 `behavior.code` 这个自由 JS 串,根本没进任何契约**——它是靠 schema 的 `additionalProperties` 偷渡进 gameDefinition 的,所以"声明式结构化源"这个名号只覆盖了外壳的数据字段,逻辑核仍是一坨未受契约约束的自由 JS(这正是上面那条机制门要堵的口子)。
|
||||
取代它的现行廉价线 = **A-model**:LLM 在 LittleJS 增强发行版上**直接写真 `src/` 多文件游戏代码**,调 L2 插件库(juice / gamefeel / palettePost 等手感件)给卖相,再用九门 harness 把"是不是真能玩"判定下来。它一步到位兑现了上面那条终态硬约束——产物就是真 src/ 工程,不再有"先吐 JSON 再展开"的中间妥协态,也没有任何"迁移中"或"cutover"。它和 tier2 富游戏线是同一范式(LLM 写真 src/),只是引擎(LittleJS vs Phaser)与表现层复杂度档不同。
|
||||
|
||||
需要把"双证地基成立"这件事说准:它证明的是一件真实但有限的事——**便宜模型能可靠地产出连贯的 gameDefinition 中间表示**;它没有、也不能证明"gameDefinition 就是合格的终态产物"。
|
||||
|
||||
这条定调过去"写了却传不到实现",所以它必须配一道**机制门(doc↔code 兑现门)**:生成产物要能被自动断言为"存在 src/ 多文件结构、玩法逻辑落在真实源码文件里、不存在'逻辑只以 JSON 字符串形态存在 / 运行时 new Function 跑内嵌串'"。设计声称要 src/,代码就必须可验证地兑现 src/——否则"产物必须是 src/"这条就只是又一条等人自觉的软约束。
|
||||
这条终态硬约束配一道**机制门(doc↔code 兑现门)**:生成产物要能被自动断言为"存在 src/ 多文件结构、玩法逻辑落在真实源码文件里、不存在'逻辑只以 JSON 字符串形态存在 / 运行时 new Function 跑内嵌串'"。设计声称要 src/,代码就必须可验证地兑现 src/——这道门正是 gameDefinition 那条路过不去、而 A-model 天然满足的那条线。
|
||||
|
||||
### 3.3 六维质量 → 生成产出的硬契约
|
||||
|
||||
@ -144,7 +140,7 @@ game-project/
|
||||
**第一类是策略下沉进机制层。** 本该作为可替换数据的策略,被焊死进了不该重编译重部署的代码里,造成三处倒置:
|
||||
|
||||
- **模型路由**:11 个角色的模型名(便宜打底 + 强档 + 视觉 / 回退位)和每个角色的采样配置,全是 Java 常量,换一个模型要改代码、重新构建。
|
||||
- **prompt 正文**:gameDefinition 的生成约定(系统提示、运行时写法约定、命名对齐)是 Java 字面量,而另一侧的 Python worker(worker 指实际跑生成的独立工作进程)又镜像了一份。同一份约定存在两个源,这是一个潜在的 **split-brain**(直译"裂脑",指同一份事实存在两个独立副本、迟早会不一致的隐患)。当前 worker 走的还是纯 iife 路(iife 即立即执行函数,指把游戏打成一个单文件代码块的老路),这条裂缝尚未真正激活;但只要后续切换依赖 worker 线的数据,它就会立刻变成承重的坑。
|
||||
- **prompt 正文**:A-model 的生成约定(系统提示、写真 src/ 的写法约定、插件库 API 命名对齐)是 Java 字面量,而另一侧的 Python worker(worker 指实际跑生成的独立工作进程)又镜像了一份。同一份约定存在两个源,这是一个潜在的 **split-brain**(直译"裂脑",指同一份事实存在两个独立副本、迟早会不一致的隐患)。这条裂缝只要两轨依赖的数据开始分叉,就会立刻变成承重的坑,所以 prompt 要提为单一版本化资产、两轨同读。
|
||||
- **品类骨架**:由 design 节点自己产出,没有外部锚点。
|
||||
|
||||
这三处倒置的共同后果是:凡涉及跨 Python 与 SAA 双轨的策略,一旦"策略化"做得不干净,就会从"一处硬编码"恶化成"多处不同步",拆东补西。
|
||||
@ -154,14 +150,9 @@ game-project/
|
||||
- **latch 终态语义不分胜负**:latch 指"游戏到达了某个终态"的锁存信号。当前它由系统强加(永远期望为真),哪怕游戏弃守排空也能逼出一个游戏结束信号——这意味着一个空壳游戏可以蹭过这道门,而 latch 正是"机制有进展"那一门的承重件。它对"这到底是不是题面要的那个游戏"几乎零鉴别力。
|
||||
- **出题与被考同源**:classify 自产品类、design 自产验收规格,而便宜模型的核心毛病恰恰是连 `ball.x`、`driver:none` 这种最基本的东西都会反复写错。让同一只待验模型既出题又答题,验收闭环就有一格没真正断开。
|
||||
|
||||
**第三类是 factory 与 gamedef 双轨未切换。** 我们有两条生成产线并存:
|
||||
**第三类原本是 factory 与 gamedef 双轨并存的债,现已随 gameDefinition 废弃而消解。** 曾经有两条生成产线:老的 factory 路(填参装配)和新的 gamedef 路(便宜模型吐结构化中间表示)。这两条都已不是现行——gameDefinition 于 2026-06-21 判为错误路线删除(见 §3.2),廉价线收敛成单一的 **A-model 路**(LLM 直接写真 src/),不再有"双轨待切换"这件事,也就没有"何时 cutover"这道悬而未决的债。与之伴生的成本侧盲区仍在、且与产线选型无关:generate 节点内部有一条回退链会静默切模型,但它不计入失败计数、也不进升档事件,与图层的 escalate 升档是两套互不相通的机制;这导致"一次失败到底走了几层模型"算不清,而成本归因恰恰依赖这个数——给静默回退链补上 `fallbackEvents` 进轨迹这件事,A-model 线照样要做。
|
||||
|
||||
- 老的 **factory 路**(填参装配,当前默认产线,但实测成功率约 **60%**,低于 80% 门);
|
||||
- 新的 **gamedef 路**(便宜模型友好的结构化中间表示,已双证"能被可靠产出",但产物侧"展开成 src/ 工程"那段尚缺,且尚未切为默认——见 §3.2)。
|
||||
|
||||
双轨并存本身是健康的演进态——新路没稳前不该贸然切换——但如果不立一道硬退役门,演进态就会沉淀成永久债。与之伴生还有一个成本侧盲区:generate 节点内部有一条回退链会静默切模型,但它不计入失败计数、也不进升档事件,与图层的 escalate 升档是两套互不相通的机制;这导致"一次失败到底走了几层模型"算不清,而切换的成本归因恰恰依赖这个数。
|
||||
|
||||
> **一处已被实证反掉的误判,记在这里免得重复建设**:源项目持久层不是悬空的。`game_source_project` 的持久层真实存在(V18 建表 + V20 加并发幂等唯一键 `uk_game_source_hash`,这两个是两道不同的迁移而非同一迁移的两份拷贝),落库与标记构建完成的调用在回调实现里被真正调用(事务外层、按内容哈希幂等)。所以它已经是一等公民,真实缺口只是血缘丰富度和 gamedef 路的端到端验证——这是 P2,不是要去补一条根本不存在的落库链。
|
||||
> **一处已被实证反掉的误判,记在这里免得重复建设**:源项目持久层不是悬空的。`game_source_project` 的持久层真实存在(V18 建表 + V20 加并发幂等唯一键 `uk_game_source_hash`,这两个是两道不同的迁移而非同一迁移的两份拷贝),落库与标记构建完成的调用在回调实现里被真正调用(事务外层、按内容哈希幂等)。所以它已经是一等公民,真实缺口只是血缘丰富度和 A-model 路的端到端验证——这是 P2,不是要去补一条根本不存在的落库链。
|
||||
|
||||
---
|
||||
|
||||
@ -214,7 +205,7 @@ flowchart LR
|
||||
2. **所有新增的质量门默认只观测不收紧。** 当前是刻意宽门放量在攒数据(开闸两门焊死放行、三门只观测),任何新门若一上来就生效,会立刻掐断这条灰度闭环。所以新门一律默认关闭、只记录轨迹,达标率稳定后再一行翻开。
|
||||
3. **凡涉及跨 Python 与 SAA 双轨的策略外置,数据契约必须是语言无关的 JSON / YAML、两轨都读它、CI 卡一致性(parity)**——否则"策略化"就沦为"跨语言漂移",把一处硬编码换成多处不同步。
|
||||
|
||||
两条线不是各跑各的:它们在两个点上解的是同一个问题,**必须合并成一处实现,不能各列一遍**;最后由一道里程碑门(cutover)收口。下面这张图先把这层关系摆清楚,再分小节展开:
|
||||
两条线不是各跑各的:它们在两个点上解的是同一个问题,**必须合并成一处实现,不能各列一遍**。下面这张图先把这层关系摆清楚,再分小节展开。(原图里有一道"cutover 里程碑门"——它属于 gamedef 与 factory 双轨切换的旧口径;gameDefinition 已废、廉价线现行单线 A-model,这道 cutover 随之作废,只留作演进史记录。)
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
@ -227,14 +218,14 @@ flowchart TB
|
||||
subgraph LB["线 B · 向外补能力(抄 OpenGame 的零件)"]
|
||||
B1["★ GDD 契约 + template_api<br/>(最高价值)"]
|
||||
B2["Debug Skill<br/>diagnose / repair + checkpoint"]
|
||||
B3["Template Skill<br/>按 gameDefinition 重写 + 九门门"]
|
||||
B3["Template Skill<br/>按 A-model src/ 重写 + 九门门"]
|
||||
B4["资产线接 mmx"]
|
||||
end
|
||||
subgraph X["两处交汇点(一件事,一处实现)"]
|
||||
X1["交汇点一:品类独立交叉校验<br/>= 物理优先分类"]
|
||||
X2["交汇点二:player 软门做厚<br/>= 验收去自评"]
|
||||
end
|
||||
CUT["★ cutover 里程碑门<br/>gamedef 成功率达 80% → 切默认产线<br/>二分退役 factory · 拦截门翻开"]
|
||||
CUT["✗ cutover 里程碑门(已废)<br/>原为 gamedef 双轨切换收口<br/>gamedef 已废 → A-model 单线,无此门"]
|
||||
|
||||
A4 --> X1
|
||||
B1 --> X1
|
||||
@ -248,19 +239,19 @@ flowchart TB
|
||||
style CUT fill:#fca5a5
|
||||
```
|
||||
|
||||
关键路径(图中黄色 ★)是一条线:**prompt 同源(解 split-brain)→ 质量信号可信(两交汇点)→ cutover**;红色的 cutover 是最终里程碑门,只有 gamedef 路成功率真达 80% 才放行切换。下面三小节依次展开线 A、线 B、两处交汇点。
|
||||
关键路径(图中黄色 ★)是一条线:**prompt 同源(解 split-brain)→ 质量信号可信(两交汇点)→ A-model 路成功率达 80% 门**。原先这条线的终点是一道 cutover 里程碑门(为 gamedef 双轨切换收口),gameDefinition 废弃后不再需要切换动作,达标门本身仍在——A-model 单线把成功率做到 80% 才算这条质量线收口。下面三小节依次展开线 A、线 B、两处交汇点。
|
||||
|
||||
### 6.1 线 A:加固现有架构
|
||||
|
||||
| 事项 | 做什么 | 性质 |
|
||||
|---|---|---|
|
||||
| trace 抽取与文件拆分 | 把内联在近九百行调度器里的轨迹抽取逻辑(约 280 行)抽成独立纯函数 `SaaTraceExtractor` 补单测;把过载的 `SaaStudioNodes` 单文件(一千六百多行)按职责拆包。调度器从近九百行瘦到约六百行 | 纯重构、零行为变更 |
|
||||
| **prompt 同源,解 split-brain** | 把 gameDefinition 的生成约定从 Java 字面量提为 `contracts/prompts` 下的版本化资产,让 Java 与 worker 都从这一份资产读、CI 卡到字节一致 | **线 A 关键路径起点** |
|
||||
| **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、把"失败即拦截"的门翻开、闭合 modify 的"从源真构建"。同期补成本侧盲区(给静默回退链加 `fallbackEvents` 进轨迹)、修诊断盲区(把全归一类的失败原因扩出子码,注意 DB 列宽 32 字符约束) | 线 A 收口里程碑 |
|
||||
| ~~cutover(切换)~~ **已废** | 原计划:gamedef 路成功率达 80% 后切为默认产线、二分退役 factory。**gameDefinition 已判错误路线删除,廉价线现行单线 A-model,无双轨可切——此里程碑作废。** 它原本捎带的两件事仍要做、且与产线选型无关:补成本侧盲区(给静默回退链加 `fallbackEvents` 进轨迹)、修诊断盲区(把全归一类的失败原因扩出子码,注意 DB 列宽 32 字符约束) | ~~线 A 收口里程碑~~ |
|
||||
|
||||
prompt 同源这一步一举两得:既根除了那处 P0 级 split-brain,又坐实了三段式缓存的前缀——前缀字节一致才能命中,实测命中率有 **76% 到 93%**。这里有一条硬纪律:**split-brain 未解之前,不得拿 worker 线的数据去做 cutover 决策。**
|
||||
prompt 同源这一步一举两得:既根除了那处 P0 级 split-brain,又坐实了三段式缓存的前缀——前缀字节一致才能命中,实测命中率有 **76% 到 93%**。这里有一条硬纪律:**split-brain 未解之前,不得拿 worker 线的数据去做产线质量决策。**
|
||||
|
||||
### 6.2 线 B:补齐能力层
|
||||
|
||||
@ -268,7 +259,7 @@ prompt 同源这一步一举两得:既根除了那处 P0 级 split-brain,又坐
|
||||
|
||||
- **GDD 契约 + template_api(最高价值项)。** 把物理优先分类的系统提示(含易错例)和品类体系做成 classify 节点;把 GDD"六节每节硬映射下游"的契约、三铁律做成 design 节点。但有一个范式级前提必须先立:**先得有那份"LittleJS 增强发行版 + 插件库公开 API 清单"当填空靶子**,否则 hook 完整性无从约束,便宜模型必然编造 API。
|
||||
- **Debug Skill 落地为 diagnose / repair 节点 + checkpoint(检查点持久化)。** 把(签名、原因、修复)三元组账本、分组阈值升格这套机制对应到 SAA 图里。签名匹配纯算法零 LLM,便宜模型只在两处兜底,每次命中省一次 LLM 调用。种子协议里的错误码要从 OpenGame 用的 Phaser 引擎换成我们的 LittleJS 运行时和九门错误码,但结构原样可用。
|
||||
- **Template Skill 按 gameDefinition 重写,且入库前过九门质量门。** 抄它的范式,但实现整体重写(它的物理信号正则和 hook 命名死绑了 Phaser)。**更关键的是:原版入库前没有任何回验门,带病的骨架会直接沉进库;我们必须给它加一道"入库前过九门或可构建校验"的质量门**——这恰恰是我们相对它的强项,把我们最硬的东西用在它最弱的地方。另要预警原版一个硬缺口:这套进化只有单调累积、没有遗忘 / 淘汰 / 冲突消解,也没有向量检索,家族一多会退化;等品类规模上来,我们可能需要补一层真正的检索。
|
||||
- **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 时完全没带,但它和"引擎是可换实现选项"这条原则同根,落地经验库时必须先按这个两层结构设计,事后再拆代价极大。
|
||||
@ -290,7 +281,7 @@ flowchart LR
|
||||
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/>里程碑门·cutover<br/>达 80% 切默认产线"]
|
||||
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
|
||||
@ -298,14 +289,14 @@ flowchart LR
|
||||
|
||||
- **阶段 0(零风险·立桩)**:收敛 job 核心字段名、状态键集、轨迹键集的常量来源。这里要切分清楚——Java 内部键名可以收敛到常量类,而 Java 与 Python 之间的轨迹键只能靠契约和测试夹具对齐,不能并入 Java 常量类(这是一处假锚)。纯重命名,无行为变化。
|
||||
- **阶段 1(线 A·重构)**:抽 `SaaTraceExtractor`、拆 `SaaStudioNodes` 分包,调度器瘦身,零行为变更。
|
||||
- **阶段 2 ★(线 A·解 P0)**:gameDefinition prompt 约定提为版本化资产,两轨读它、CI 卡字节。关键路径:split-brain 未解前不得拿 worker 线数据做 cutover 决策。
|
||||
- **阶段 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 节点契约化。这是约束力的靶子和最高价值杠杆,建议优先排进 `2026-06-18-001`。其中"物理优先分类"与阶段 4 交汇点一是同一处实现,不重复建。
|
||||
- **阶段 B2 [新增]**:Debug Skill 落 diagnose / repair 节点 + checkpoint;Template Skill 按 gameDefinition 重写并强制入库前过九门;asset 节点接 mmx 并搬入确定性 bitmask 贴图。可在 B1 之后并行。
|
||||
- **阶段 5 ★(里程碑门·cutover)**:gamedef 成功率达 80% 门后,切默认产线、二分退役 factory、把拦截门翻开、闭合 modify"从源真构建"。依赖阶段 2(prompt 同源)、阶段 4(质量信号可信)与 80% 达标率三个前置。
|
||||
- **阶段 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(cutover)。** 阶段 0 / 1 / 3 可并行。按价值排,最该立刻动手的三件依次是:**先补 template_api 与 GDD 契约(B1,一切约束的靶子)、再把 Debug Skill 落成 diagnose / repair + checkpoint、然后把 Template Skill 按 gameDefinition 重写并加九门质量门。**
|
||||
**关键路径是一条线:阶段 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 历史回收判定捡回)
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# W-G1 基准 · 20 款经典轻游戏靶集与 4 类能力缺口
|
||||
|
||||
> 🚧 **架构演进中** —— 生成引擎子树正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中,文中标注的现行结论可能随推进变化;以子树 [README](README.md) 与最新裁定 / plan 为准。
|
||||
> 🚧 **架构演进中** —— 廉价线 **gameDefinition 已废(错误路线),现行 = A-model 写真 `src/`**;tier2 富游戏自治轨建设中(0 号 spike accept)。文中结论可能随推进变化,以子树 [README](README.md) / 运行时 SoT [`agentic运行时架构图说`](agentic运行时架构图说.md) 与最新裁定为准。
|
||||
|
||||
> **这是什么**:绘境AI 生成引擎用来回答一个很实在的问题的设计文档——**"便宜的通用模型 + 我们当前这套引擎和插件库,到底能造出什么样的游戏、又造不出什么"**。它把 20 款人人都玩过的经典轻游戏铺成一张靶集,既验证生成管线确实能端到端跑通,又拿这些游戏去压测能力上限、把引擎和插件库的短板逼出来。
|
||||
> **给谁看**:负责生成主线的工程师、想知道"哪些品类现在就能放量做、哪些还得先补能力"的产品与创始人,以及做技术尽调时想看清"生成能力真实边界在哪"的架构评审。
|
||||
|
||||
@ -6,7 +6,7 @@ date: 2026-06-24
|
||||
|
||||
# Prompt 治理 · 生成引擎设计文档
|
||||
|
||||
> 🚧 **架构演进中** —— 生成引擎子树正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中,文中标注的现行结论可能随推进变化;以子树 [README](README.md) 与最新裁定 / plan 为准。
|
||||
> 🚧 **架构演进中** —— 廉价线 **gameDefinition 已废(错误路线),现行 = A-model 写真 `src/`**;tier2 富游戏自治轨建设中(0 号 spike accept)。文中结论可能随推进变化,以子树 [README](README.md) / 运行时 SoT [`agentic运行时架构图说`](agentic运行时架构图说.md) 与最新裁定为准。
|
||||
|
||||
> **这是什么**:绘境AI 生成引擎里「Prompt 治理」这一子系统的设计文档,回答"**为什么把 prompt 当成一份正式契约来管、它长什么样、改一条 prompt 要过哪些关、人在什么环节介入**"。
|
||||
> **给谁看**:负责生成主线的后端工程师、写 prompt 的工位负责人、做架构评审的人,以及想搞清楚"生成质量为什么可控、可回归"的新同事。
|
||||
|
||||
@ -6,7 +6,7 @@ date: 2026-06-24
|
||||
|
||||
# 开闸验收门 W-G1 · 生成对外放行的 6 道门
|
||||
|
||||
> 🚧 **架构演进中** —— 生成引擎子树正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中,文中标注的现行结论可能随推进变化;以子树 [README](README.md) 与最新裁定 / plan 为准。
|
||||
> 🚧 **架构演进中** —— 廉价线 **gameDefinition 已废(错误路线),现行 = A-model 写真 `src/`**;tier2 富游戏自治轨建设中(0 号 spike accept)。文中结论可能随推进变化,以子树 [README](README.md) / 运行时 SoT [`agentic运行时架构图说`](agentic运行时架构图说.md) 与最新裁定为准。
|
||||
|
||||
> **这是什么**:绘境AI 生成引擎"对外开闸"那一刻必须先架好的 6 道验收门的设计文档。它回答的是一个很具体的问题——**当"一句话生成游戏"第一次向真实创作者放开时,我们到底要先焊死哪些门、可以并行补哪些门、又有哪两道前置必须先验过才许放行?**
|
||||
> **给谁看**:负责生成主线开闸的工程师、质量与审核台一侧的同事、做发布放行决策的产品与创始人,以及想看清"放量前的安全/可控边界"的架构评审。
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user