234 lines
30 KiB
Markdown
234 lines
30 KiB
Markdown
---
|
||
|
||
> 🚧 **架构演进中** —— 生成引擎子树正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中,文中标注的现行结论可能随推进变化;以子树 [README](README.md) 与最新裁定 / plan 为准。
|
||
|
||
date: 2026-06-20
|
||
topic: 生成设计合理性 · 对抗审查裁决
|
||
status: 裁决 · 待创始人拍板(愿景分层)
|
||
---
|
||
|
||
# 生成引擎 · 设计合理性裁决
|
||
|
||
> **这是什么**:对绘境AI 核心生成设计"**到底合不合理**"的一次对抗式深度审查裁决。它不讲这台机器怎么搭(那在[生成引擎主文档](README.md)),只回答一个判断题——我们押注的这套生成范式,是该坚持、该修补,还是该推倒。
|
||
> **给谁看**:创始人、生成主线的架构负责人、做尽调时想看清"护城河到底硬在哪、天花板在哪"的人。
|
||
> **怎么读**:先读 §1 看总裁决,§2 看该护住的真功夫,§3 看天花板与裂缝,§4 看具体怎么改,§5 看收口结论。
|
||
> **品牌**:本文统一用「绘境AI」。
|
||
|
||
被审查的对象,是绘境AI 当前的核心生成设计:**声明式结构化源 + curated 运行时薄适配器 + 插件后置 + 九门验收**。用更白的话说,就是让便宜模型先吐一份结构化的游戏定义,平台用一套确定性的运行时去解释它,再用九道自动门把"是不是真能玩"判定下来。这套设计是绘境AI 护城河的关键路径,所以"它合不合理"这个问题,值得被四个互相挑刺的视角各读一遍真代码、再由总架构师拍板。
|
||
|
||
为避免这份裁决被当成某个审查者的个人偏见,它的产生方式本身是对抗式的:**四个临界视角各自独立审查——范式视角、能力面视角、产出质量视角、第一性原理视角**,每个视角都直接读运行时和构建链的真实代码去找天花板与裂缝,再由总架构师综合;每一条 fundamental(范式级)或 serious(严重)指控,都已逐条按 `文件:行号` 核实(依据见文末附录)。整个审查由 5 个 agent 经 6c6g 文档/设计线编排并打磨产出。这里先把两个会反复出现的分级词说清楚:**fundamental** 指"范式级病灶"——病在设计的根上,补丁补不掉;**serious** 指"严重但可补的工程缺口"——方向对、只是某处没做到位。这个区分是整份裁决的骨架,因为它直接决定了创始人**该不该动刀、动哪把刀**。
|
||
|
||
---
|
||
|
||
## 1. 一句话总裁决:部分合理
|
||
|
||
**部分合理。** 而且四个视角的分歧可以收敛成一句话:
|
||
|
||
> 这是一个为"便宜模型 + 自动验收"量身打造的、聪明的 **Tier0 超休闲生成范式**,工程取舍大半是对的;但它顶着"声明式结构化源"的名号,内核却是"声明式数据壳 + 一坨未受契约约束的自由 JS",而且表达力被运行时硬编码焊死在四类几何色块玩具上。它不是某个自由工程范式的"更聪明上位替代",而是一个"低复杂度特例"。**坚持它做 Tier0 是对的;拿它去够 demo 里 Marvel/KOF 那一档愿景,是范式选错。**
|
||
|
||
这里先解释三个本文的核心代号,后文不再重复:
|
||
|
||
- **Tier0**:绘境AI 内部对游戏复杂度的分层口径。**Tier0 = 超休闲轻游戏**——单局、机制简单、可被机器自动判定"能玩"的那一档(打砖块、点击合成、躲避、跑酷)。它是这套设计真正擅长的领域。
|
||
- **声明式结构化源**:设计对外宣称的范式名号——意思是"一款游戏 = 一份结构化、可声明、可 diff 的源描述",而非一坨硬编码代码。这个名号是否名副其实,正是裁决的争点之一。
|
||
- **九门 harness**:把生成出来的游戏丢进真实浏览器里**自动真玩一局并判定"是否合法可玩"**的测试夹具(harness 即"测试夹具"),其中有九道确定性检查门——能不能装载、跑不跑帧、响不响应输入、到不到游戏终态等等。它是这套设计最硬的工程价值,详见[主文档](README.md) §2。
|
||
|
||
值得注意的是:**四个对抗视角各自独立得出了"部分合理",措辞不同,但裂缝都指向同一处。** 这本身就是个强信号——这不是某个审查者的口味问题,而是设计里**真有一道贯穿性的张力**。下面把这道张力讲透。
|
||
|
||
---
|
||
|
||
## 2. 真正合理、必须坚持的部分
|
||
|
||
先说该护住的。这套设计有几处取舍是经过深思的真功夫,不是凑数。**创始人不要因为后面的批评,就把这些一并推翻。**
|
||
|
||
### 2.1 把"确定性受控面"当地基,是全盘最聪明的一步
|
||
|
||
便宜模型产线的生死命门,其实只有一个问题:**能不能在没有人、也没有 VLM 的情况下,自动判定一局游戏"真的可玩"。**(VLM = Vision-Language Model,看图打分的多模态模型——同行常用它来"看截图判断游戏好不好",但它会被对抗、会漂移。)绝大多数同行栽在这里:他们能让模型吐出能跑的代码,却**无法机器化地证明它可玩**,于是只能靠截图、靠跑几帧、靠 VLM 打分,而这些都不可靠。
|
||
|
||
这套设计对这个命门的回答,是把三件事做进了运行时:
|
||
|
||
- **把随机、时间、输入全部收进受控种子**——运行时里 `rt.random`、`rt.time.now` 一律走一个统一的上下文 `ctx`,而不是各自调用系统真随机或真时钟。这样同一颗种子就能复现同一局。
|
||
- **把胜负置成不可逆的 latch 终态**——一个叫 `latch()` 的机制一旦置定就停摆,游戏不会偷偷重开。(latch 是电路里的"锁存"概念:置位后保持,不会自己翻回去。)
|
||
- **把整个游戏世界投影成测试侧能用命名路径读取的取证形状**——实体按 id 投影成 `ball.x`/`paddle.x`,带 tag 的实体汇成 `targets[]` 这样的数组,供自动测试程序按名字读取。
|
||
|
||
这三件事合起来,九门 harness 才能用确定性的对照去"真玩一局并判定"。审查者亲手核对了代码:**这些不是设计文档里的许诺,是运行时里真实存在的机制。** 这是该范式最硬的正当性——它不是给玩具加约束,而是为"自动验收"这个产品命门做的地基。换个反例就看清它的价值:自由工程里游戏状态散落在各个 Manager 的私有字段里,想做同等取证得逐个工程定制探针,**根本无法规模化**。这一步,创始人当初拍得对。
|
||
|
||
### 2.2 "behaviors 只写逻辑不写画" + 声明式渲染器,把约束花在了刀刃上
|
||
|
||
实测数据反复证明:便宜模型在三个高频面上漂移率极高——**canvas 绘制、`requestAnimationFrame` 驱帧、事件订阅**。(`requestAnimationFrame` 是浏览器逐帧驱动动画的标准接口。)这套设计干脆把"出图"整个从模型手里拿走:**渲染器根据 render 组件自动画,模型写的 behavior(行为逻辑)只能经运行时接口 `rt` 去操作游戏世界,碰不到画面。** 三个最大的 bug 源被结构性地消除了。
|
||
|
||
更精彩的是一个叫 `clickable` 的内置基元。实测发现,连强模型都常把"点击命中"这件事误门控在一个分离的状态或计时器上,导致自动测试程序永远点不中,连环挂掉好几道门。这套设计把"点中目标 → 翻状态 → 生成标记 → 计分 → 播特效"整条链内置成了运行时基元,**离散点击类游戏只要声明一个 `clickable` 组件就行**。这是"缩小生成域、扩大平台域"这条哲学的最佳实证——用平台的确定性代码,换整整一类游戏的可靠性。这个判断,是真正吃透了便宜模型脾性之后才做得出来的。
|
||
|
||
### 2.3 验收禁止 LLM 自评 + "框架可换、成本单点"的接缝,是对的工程纪律
|
||
|
||
这里有两条工程纪律值得点名表扬:
|
||
|
||
第一,**"完成"(done)钉死在真浏览器真玩的九门上,而不是模型自夸**。这比"用 VLM 给截图打分"更抗 Goodhart(Goodhart 定律:一旦把某个度量当成目标,它就会被钻空子而失真)——VLM 本身会被对抗、会漂移,而确定性门不会。
|
||
|
||
第二,**把生成逻辑藏在一个 dispatcher 契约之后、模型只走单一的 new-api 成本层**。(dispatcher 即"调度契约",是生成逻辑对外的统一接口;new-api 是模型调用的统一网关层,所有模型调用都从这一个口子出去。)这意味着"便宜模型 vs 专训模型""SAA 编排 vs ReAct vs 换一套框架",全都变成了**接缝后面的可替换选择,而不是架构重写**。对照那种"把能力焊死在某个专训运行时加专训权重上"的做法——它们换底座要重训,而绘境AI 的赌注是**可回退的**。在"便宜模型可能撞天花板"这个核心不确定性面前,这条留足了退路,是成熟架构师的做法。
|
||
|
||
### 2.4 "改源不改包"的产品基座判断对,但要打个折
|
||
|
||
还有一处方向性正确、但必须诚实打折的地方:**"游戏即长生命周期源项目、改源不改包"的产品基座判断是对的。** 平台化(而非工具化)确实需要可 diff、可改、可重建的源——这条范式原则的完整论述见[主文档](README.md) §3。
|
||
|
||
但要诚实:**这个优势目前只覆盖了"声明式数据"那一半**(实体/场景/数值——config 走数据驱动,改参数可以免 LLM),而**逻辑那一半仍是自由 JS**,可维护性红利在最关键的"有趣逻辑"处打了折。这把我们引向裂缝。
|
||
|
||
---
|
||
|
||
## 3. 真正的天花板与裂缝
|
||
|
||
下面按 fundamental → serious 排列每条裂缝,并明确标注它是"范式级病灶"还是"可补的工程缺口"。
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
Root["范式张力<br/>用压低输出空间换不专训"]
|
||
Root --> F1["裂缝一(fundamental)<br/>名实不符<br/>behavior.code 没进契约"]
|
||
Root --> F2["裂缝二(fundamental)<br/>表达力天花板<br/>焊死在四类玩具"]
|
||
Root --> F3["裂缝三(fundamental)<br/>好玩好看无托底<br/>九门只判机制地板"]
|
||
Root -. 同源衍生 .-> S["四条 serious 工程缺口"]
|
||
S --> S4["裂缝四:new Function 安全押正则"]
|
||
S --> S5["裂缝五:rt 面四处人手双写"]
|
||
S --> S6["裂缝六:九插件对主线不可达"]
|
||
S --> S7["裂缝七:gatespec 自产自验同源"]
|
||
style Root fill:#f9e79f
|
||
style F1 fill:#f5b7b1
|
||
style F2 fill:#f5b7b1
|
||
style F3 fill:#f5b7b1
|
||
```
|
||
|
||
这张图先把结论摆出来:**三条 fundamental 不是三个独立 bug,而是同一道范式张力的三张脸**(§3.4 会收束这一点);四条 serious 则是从同一根上衍生出的工程缺口。
|
||
|
||
### 3.1 裂缝一(fundamental · 名实不符):承载 100% 游戏逻辑的 `behavior.code`,根本没进契约
|
||
|
||
这是四视角里最尖锐、也是审查者亲手验证最确凿的一条。
|
||
|
||
游戏定义的 schema(数据契约)里,behavior 的定义**只声明了 `id` 和 `trigger` 两个字段**,`required` 也只有这俩;而真正装着**全部玩法逻辑**的 `code` 字段,是靠 schema 上的 `additionalProperties: true`(允许任意额外字段)偷渡进来的——运行时甚至还接受一个**未文档化的 `js` 别名**。这意味着什么?
|
||
|
||
> **我们对外宣称这是"声明式结构化源",但它真实的结构是"声明式数据壳 + 未受契约约束的自由代码核"。**
|
||
|
||
entities / components / scenes / rules 那层声明式外壳是真的,可游戏的灵魂——逻辑——**依旧是一坨任意 JS 字符串**。后果是连锁的:契约对最关键的产物零约束,于是**校验落空、版本化落空、可寻址性落空**——`sourceHash`(源指纹哈希)哈希的是一个内含任意代码串的 JSON,改一个字符哈希就变,根本无法对逻辑做点对点的 diff 和结构化迭代。我们号称的"长生命周期项目"优势,在逻辑这一半上是悬空的。
|
||
|
||
这是范式级问题,因为它戳破了设计的自我叙事。但请注意:**它不是"这设计废了",而是"这设计名不副实"。** 补法是把名号和现实对齐,而不是推倒——§4 的改动一、改动二给具体改法。
|
||
|
||
### 3.2 裂缝二(fundamental · 表达力天花板):能产的复杂度被焊死在四类玩具上,且墙撞得很近
|
||
|
||
这不是理论推测,是代码现状:
|
||
|
||
- **scenes 只取 `scenes[0]`** —— 多关卡无从谈起;
|
||
- **advance(推进)是注释写明的 v0 占位空操作**(`gd-runtime.js:265`,evalRules 内 advance 分支)—— 关卡推进根本没实现;
|
||
- **渲染只有 rect / circle / fill / sprite 四种形状**(sprite 系 U1 新增,见 §3.3)—— 而 sprite 之外仍只有三类几何色块;
|
||
- **物理只有 `vx/vy + gravity` 一条单一积分路径**;
|
||
- **进度只有一个全局 score 加 win/lose 二元**。
|
||
|
||
它能撑的,就是 **pong / clicker / dodge / runner 这四类**——休闲单局小游戏。任何需要多关卡推进、库存/对话树、敌人 AI 状态机、tilemap/寻路、相机、可变 HUD 流程的品类,这套运行时**既没有对应的声明面,也没有调度器去承载**。schema 注释自己都坦白了:"非 AAA ECS:无 system 调度器、无 archetype、无 query DSL"。(ECS = Entity-Component-System,游戏业界的实体-组件-系统架构;这句话等于承认它只是个极简的数据容器,不是真正的游戏引擎内核。)
|
||
|
||
对照一个成熟的自由工程范式,才看得清这道墙的高度:它的 platformer(平台跳跃)模块有 **8435 行**(里面是 PlayerFSM 玩家状态机、ChaseAI 追击 AI、PatrolAI 巡逻 AI、SkillBehavior 技能、BehaviorManager 行为管理器),tower_defense(塔防)模块 **3877 行**(WaveManager 波次管理、EconomyManager 经济管理)。那一层结构化复杂度,**不是绘境AI 的模型不够强,而是运行时根本没有承载它的形状**——给再强的模型,它也只能把复杂逻辑硬塞进一个 `update` 串里,然后撞上"自由 JS 核"那道裂缝一。
|
||
|
||
这一条之所以是 fundamental 而非工程缺口,是因为它**和对标的产品愿景正面冲突**:demo 里放的是 **Marvel 平台动作、KOF 格斗**这种富交互游戏,而这套范式**结构性地产不出那一档**。这是产品愿景级的天花板,不是补个分支能解决的。
|
||
|
||
### 3.3 裂缝三(fundamental · 好玩好看无下限托底):九门只判机制地板,质量上限由便宜模型单点决定
|
||
|
||
把前两条往产品端推一步,就是这条。
|
||
|
||
九门作为"机制 CI"(持续集成式的机制校验)设计得很精良、很抗假绿:**C 门**拦单步假推进、**E 门**用哈希拦冻屏(画面卡死)、**G 门**用同种子同帧号的 A/B 对照,隔离"靠自走动画蒙混过活性检查"的把戏、**H 门**验 gameover 之后不会自动重开;驱动测试的 driver 家族还做了速度前瞻、抛物线反解这种"测试侧自己也得会玩"的真功夫。这一层审查者给高分。
|
||
|
||
**但九门保证的是"机制合法",中间整段"好玩"没有任何硬门或软门兜底。** 同一套九门下,一个精心设计的打砖块,和一个"摆 3 个砖块、点一下就 win"的退化品,**都能全绿**。
|
||
|
||
"好看"那一侧也撞墙,但要先把现状说准——这条在审查者初稿之后已被 **U1 资产渲染工作**(commits 73d33916+db14845d+81c1b2cf,2026-06-19)推进过一截:**资产消费端的地基已打通**——runtime 多了第四种形状 `sprite`(`gd-runtime.js:368` 走 `drawSprite`→真 `drawImage`,见 `:387`),构建链也从源项目顶层 `sp.assets` 把那六类资产规格(`assetSpec`)抽进运行时 `GameDefinition.assets` 供 `drawSprite` 消费(`build-from-source.mjs:160`),`d.ts` 与单测均已对齐。所以"渲染器只画色块 / assets 零消费者 / 白名单根本不含 assets"这三句**在现行代码里已不成立**。
|
||
|
||
**但"好看"的方向性结论仍未翻盘**,缺口只是从"链路根本不存在"下移成了"链路打通、宿主预载未端到端 wire":真实 sprite 显示依赖宿主 `boot.assets` 预先载入图源,而这一步当前尚未端到端接上,所以 `drawSprite` 在没有图源时会**降级成类目色占位 rect**——**当前实测产出仍以几何色块为主**。这意味着模型即便用 mmx(绘境AI 的素材生成工具)产出了精美 sprite,在宿主预载 wire 落地前,渲出来基本还是占位色块。而对大众用户来说,"好看"是游戏信息流第一屏的入场券——**占位色块画面会被直接划走**。
|
||
|
||
叠加上记忆里 `SaaFullGraphE2eTest`(端到端测试)实测**便宜模型成功率只有 60%**、连"机制稳定产出"都未达 **80% 这道门**——把"大众想玩"这个愿景级目标,押在一个"机制都还没稳、好玩好看零下限保护"的单点上,是当前架构**最大的产品风险**。
|
||
|
||
### 3.4 三条 fundamental 是同一道张力的三张脸
|
||
|
||
审查者必须诚实指出:**这三条 fundamental 不是三个独立 bug,而是同一个范式张力的三张脸——"用压低输出空间换不专训"。**
|
||
|
||
压低输出空间(声明式壳 + 窄 rt 面 + 硬编码渲染物理)确实把简单品类的可靠性和可验收性拉了上去,这是**真价值**;但同一个动作,也把可产游戏的复杂度上限、视觉质量上限、"有趣"的表达空间一起压低了。
|
||
|
||
> **这不是设计做错了,而是这套设计天然只能站在"可靠"这一端,够不到"复杂/精美"那一端。危险的不是它有天花板,而是把它当"通用生成范式"去卖。**
|
||
|
||
### 3.5 四条 serious:方向对、可补的工程缺口
|
||
|
||
**裂缝四(serious · 安全押在脆弱正则上):`new Function` 编译不可信模型代码,安全完全靠正则黑名单兜。** behavior 和 rule.condition 都走裸 `new Function`(把字符串当 JS 代码执行),无沙箱,安全靠构建期的 `LOGIC_BANS` / `CONDITION_BANS` 正则黑名单(禁 `process`/`eval`/`.constructor`/`while(true)` 等)。正则黑名单对 JS 是出了名的可绕——模板字符串拼接、Unicode 转义、`[].filter.constructor` 这类变体都能逃逸。作者自己在注释里也承认这是"`new Function` 不沙箱的现实缓解"。这条是 serious 而非 fundamental,因为**方向其实是对的,只是定位错了**:既然只在浏览器 CDP harness 里跑(CDP = Chrome DevTools Protocol,通过它远程驱动真实浏览器),**浏览器进程本身就是安全边界**,那个安全扫描该被诚实地定位成"质量门/确定性门"而非"安全门"。真要防逃逸,该靠 iframe sandbox + CSP + 进程隔离,而非正则。顺带一个真实的可调试性债:behavior 抛错只回灌一行 message,无行号、无 source map,模型和人都难定位——给注入代码包一层 `//# sourceURL=behavior/<id>`(让 JS 错误栈带上可读名字)就能解决,这是低成本高回报的补丁。
|
||
|
||
**裂缝五(serious · rt 面四处人手双写、无一致性门):** 加一个 rt 能力,要**同时手改四处**——Java 里的 prompt 字符串、`gd-runtime.js` 实现、`runtime-api-2d.md` 文档、构建禁则。当前 rt 面被刻意冻在约 **20 个函数**(YAGNI 原则:You Aren't Gonna Need It,不为没到来的需求提前造),这个成本现在可控,而且 prompt 与运行时目前**没有 split-brain**(审查者核对过——"split-brain"指"两个本该一致的副本各说各话";这里指 prompt 承诺的接口面运行时真的都有)。但这是**静默高危的演进期债**:漂移一旦发生(prompt 说有 `rt.X` 但运行时没有 → 模型据此生成 → 运行时报 undefined → 九门挂),排查成本极高。**不必上重型注册表(那是过度工程),对症解是加一道一致性测试**:从 `gd-runtime.js` 反射出真实合法的 rt 面集合,断言它与 prompt 里的 `rt.*` token 集、文档表三者相等,一旦 diff 就红线。把"四处人手同步"降级成"改任一处、测试逼你改齐"。
|
||
|
||
**裂缝六(serious · 九插件对主线全不可达):** 团队花整整一波(一个开发批次)建的**九个能力插件**——collision(碰撞)的 SAT/MTV 算法、physics-lite 刚体、gamefeel 的缓动/屏震/hitStop(手感插件:tween 缓动、screenshake 屏幕震动、hitStop 命中顿帧)——在结构化生成主线里**一个都用不上**。`gd-runtime.js` 零 import 那个插件注册表(PluginRegistry),只经 `getEngine()` 拿引擎三面(粒子/音频/数学)。这意味着 gameDefinition 能表达的物理只有最朴素的 `vx/vy` 积分加 AABB 重叠检测,想要"带法线的弹性反弹""缓动入场""屏震 juice"都做不到——**手感被实打实压低一档**。这是 serious 而非 fundamental,因为它有清晰的升级路径:**当某个插件能力被验证"可靠产出且九门可测"时,经 `rt.fx` 家族扩一个声明式入口**(如 `rt.fx.shake` / `rt.tween`)把它纳入 gameDefinition 面。但必须立刻把这道落差写进路线图,否则九插件会变成"为旧的 iife 老路建的、在新路里逐渐腐烂的死资产"。
|
||
|
||
**裂缝七(serious · gatespec 自产自验、同源风险):** H 门的"机制进展"断言由 play-spec 的 `assertAfterPlay` 逐游戏自声明,而 spec / driver / gatespec(测试规格 / 驱动脚本 / 门规格)**都是 design-agent 自产**。同一来源既定义"怎么算过"又生成"被测物",存在系统性地"把门调到刚好能过"的风险——断言写成 `score increased`、driver 又专门去触发那个 score,门必绿,但游戏未必好玩。G 门能挡"完全不响应",挡不住"只为过门而响应"。补法是对 gatespec 引入"断言最小强度"校验,或让独立评审 agent 抽样复核,**切断自产自验链**。
|
||
|
||
剩下两条 minor 点到为止:
|
||
|
||
- **D 门"真渲染"判据(有色像素 maxCh > 80)在色块时代几乎恒真**——接了 sprite 也不会自动变严,视觉维度形同虚设;接美术时必须同步升级判据。
|
||
- **rule.condition 的"无副作用"约束只在构建期静态扫,运行时的 `new Function('return (cond)')` 并不强制**——双边界对纯净性的保证强度不一致;让两边共用同一份禁则定义即可。
|
||
|
||
---
|
||
|
||
## 4. 要让它更合理,具体改什么
|
||
|
||
审查者不主张推倒。这套设计的地基(确定性受控面 + 自动验收)是对的,该做的是**"对齐名实、明确分层、补上几道门"**。按优先级排,核心是四改(改动一至四),外加两条配套(改动五、改动六):
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
P0["改动一(最高优先)<br/>给范式正名<br/>+ 愿景显式分层"] --> P1a["改动二(高优先)<br/>逻辑层往结构化拽回<br/>code 串退场到长尾"]
|
||
P0 --> P1b["改动三(高优先)<br/>assetSpec 接上消费端<br/>打通'好看'"]
|
||
P1a --> P2a["改动四(中优先)<br/>给'好玩'立独立质量轴"]
|
||
P1b --> P2a
|
||
P2a --> P2b["改动五(中优先)<br/>三道一致性/调试补丁"]
|
||
P2b --> P3["改动六(战略级)<br/>给生成产线<br/>自己的进化飞轮"]
|
||
```
|
||
|
||
**改动一(最高优先 · 定性纠偏):诚实地给范式正名,并把愿景显式分层。** 别再对内对外叫它"纯声明式结构化源",它是"**结构化外壳 + 受限逻辑**"的混合范式。同时,把"便宜模型 + 约束 schema"明确锁定为 **Tier0:可发行轻游戏(超休闲/合成/挂机/答题/网格点选)的可靠产线**,并把这档的复杂度边界、视觉边界白纸黑字写进 profile 的承诺里。
|
||
|
||
> **最大的风险不是设计有天花板,而是产品团队拿它当"通用生成范式"去对标 demo 里的 Marvel/KOF。**
|
||
|
||
富交互品类要么显式推迟,要么走"受控自由工程 + 更强模型"的独立轨——**别让一套 schema 同时背"可靠"和"复杂"两个互斥目标**。这一条不花一行代码,却是整份裁决里最重要的动作。
|
||
|
||
**改动二(高优先 · 把逻辑层往结构化拽回来):把高频 idiom 沉淀成声明式 behavior kind,让 code 字符串退场到长尾兜底。** 当前四个原型其实都能用五六个内置 behavior kind(移动 / 积分 / 碰撞 lose / 计时 spawn / clickable 那样)表达。把这些做成可组合的声明式原语库——类似成熟范式里那种"可选可配"的 PlatformerMovement / ChaseAI 件——让便宜模型从"写任意 JS"降级成"选 + 配组合",才真正吃到约束式的可靠性红利;任意 JS 逃逸口只留给少数高阶场景。这一步同时缓解**裂缝一**(逻辑可契约化了)、**裂缝四**(逃逸面缩小)和"模型成功率 60%"(选配比手写错误率低得多)。
|
||
|
||
**改动三(高优先 · 让 assetSpec 从孤儿契约转成有消费端):** 这是打通"好看"的**关键路径**,且它是一整条链、不是一个分支。其中 ①②的地基已由 **U1**(commits 73d33916+db14845d+81c1b2cf,2026-06-19)落地——① 渲染器已加 `sprite` 分支(render 组件 `shape:'sprite'` 引 `asset` → 引擎 `drawImage`);② 构建链已从源项目顶层抽 `assets` 并入运行时 `GameDefinition.assets`、`d.ts` 与单测对齐。**剩余两块尚未兑现**:一是 **宿主 `boot.assets` 预载尚未端到端 wire**(未 wire 时 `drawSprite` 降级类目色占位,故当前实测仍多为色块);二是 ③ **D 门视觉判据仍停在"非白屏"、未升级成"非纯色块/有结构"**(颜色直方图复杂度 / 边缘密度),否则接了真图,门也测不出视觉退化,等于白接。在这两块补齐前,**路线图必须明确标注"当前产出 = 色块原型,非可发行视觉品质"**,杜绝把"机制门全绿"误读成"产品就绪"。
|
||
|
||
**改动四(中优先 · 给"好玩"立独立质量轴):** 别让九门兼任"好玩"判官。补一道便宜的启发式门——动作类看 driver 真玩时分数增长曲线是否非平非爆、失败是否可达且非秒败——给 **0–100 分而非 pass/fail**,作为信息流排序与 repair 修复的信号。把"好玩"明确从九门责任里剥离:
|
||
|
||
> **九门 = 机制 CI,好玩 = 另一条评审/数据回灌轨。**
|
||
|
||
否则,机制全绿会持续制造"质量已达标"的错觉。
|
||
|
||
**改动五(中优先 · 三道一致性/调试补丁):** rt 面加一致性测试(对应裂缝五);注入代码包 `//# sourceURL` 让错误栈带名(对应裂缝四);把 condition 的双边界共用同一份禁则定义(对应裂缝中的 minor)。这三条都是低成本、止住静默漂移的对症解。
|
||
|
||
**改动六(战略级 · 给生成产线自己的复利飞轮):** 当前 schema / rt / 模板都是 Opus(绘境AI 用来做最高复杂度设计的最强模型)人工设计的**静态资产**,量上来后会成为瓶颈——而护城河四层里就有"资产沉淀"和"网络效应"两层。成熟范式有一套"模板技能"五段管线,能从每个完成的项目里**自动萃取新模板家族**,绘境AI 没有。建议:**把过门的 gameDefinition 做成生成侧的进化语料**,从高频 entity/behavior 组合聚类,半自动沉淀为品类 prompt 模板 / 行为原语,给生成产线一个**自我增强的飞轮**,而非永远靠 Opus 手动加模板。这一条不紧急,但决定了平台能否真正"越跑越强"。
|
||
|
||
---
|
||
|
||
## 5. 收口:这设计能到产品愿景吗
|
||
|
||
**能到一半,且那一半是真护城河;另一半它够不着,必须靠分层和另一条轨。**
|
||
|
||
这套设计能**可靠地、低成本地、机器可验收地批量产出超休闲轻游戏**——这正是"零门槛用户一句话造可玩游戏"这个差异化闭环里**最难、也最值钱**的一环。竞品大多停在"生成工具",死在"无法证明可玩";而绘境AI 这套确定性受控面 + 九门 harness,真的把"能生成 ≠ 能玩"这条假绿线焊死了,这是别人短期补不上的工程纵深。**作为 Tier0 产线,它合理、聪明、该坚持。**
|
||
|
||
但产品愿景里 demo 对标的 **Marvel 平台动作、KOF 格斗**那一档富交互游戏,这套范式**结构性地够不着**——不是模型不够强,是运行时没有承载那层复杂度的形状,逻辑核又还是没被结构化的自由 JS。**愿景必须诚实分层:Tier0 用这套吃"可靠 + 可验收 + 规模",复杂品类另开一轨。** 把这两件事混为一谈、用一套 schema 同时承诺"可靠"和"复杂",是当前**唯一的范式级误判风险**。这条"复杂品类另开一轨"现在已落档:它就是 tier2 富游戏自治轨,设计见同目录 [自治富游戏引擎](自治富游戏引擎.md)、[agentic 集成架构](agentic集成架构.md)、[tier2 实现详设](tier2实现详设.md)。
|
||
|
||
一句话给创始人:
|
||
|
||
> **这设计哪里都没"错",它只是被起错了名、被寄予了它够不到的期望。把名字改对(混合范式)、把愿景分层(Tier0 不碰 Marvel)、把逻辑往声明式拽回来、把 assets 链打通——做完这四件,它就是一个诚实、强壮、有护城河的 Tier0 生成范式;不做,它迟早会因为"被当通用范式卖"而在第一款复杂游戏的 demo 上当众撞墙。**
|
||
|
||
---
|
||
|
||
## 附录 · 裁决依据(已逐条代码核实)
|
||
|
||
本裁决的每一条 fundamental / serious 指控,均已按 `文件:行号` 核对真实代码,而非凭设计文档推断:
|
||
|
||
| 指控 | 代码证据 |
|
||
|---|---|
|
||
| 逻辑核未进契约 | `source-project.schema.json`:behavior 仅声明 `id`/`trigger` + `additionalProperties: true`;运行时另接受未文档化 `js` 别名 |
|
||
| 渲染/物理/场景焊死 | `gd-runtime.js`:渲染器仅 rect/circle/fill + sprite(U1 新增,sprite 之外仍三类几何);advance 为 v0 空操作(`:265`,evalRules 内 advance 分支);单场景 `scenes[0]`;单一物理积分;裸 `new Function` |
|
||
| 安全靠正则 | `build-from-source.mjs`:安全靠 `LOGIC_BANS`/`CONDITION_BANS` 正则黑名单(注:assets 已不再被丢弃——U1 后从顶层 `sp.assets` 单独抽入 `cleaned.assets`,误入 `GAMEDEF_KEYS` 才会丢) |
|
||
| 视觉链(U1 后)| host 目录对 `sprite`/`assets` **非零消费者**(`gd-runtime.js` `drawSprite`、`runtime-api-2d.d.ts`、两份单测均消费;`drawTile` 路已改 `drawImage`);剩余缺口=宿主 `boot.assets` 预载未端到端 wire,故实测仍多为占位色块 |
|
||
| 机制成功率未达门 | `SaaFullGraphE2eTest` 实测便宜模型成功率约 60%,未达 80% 门 |
|
||
|
||
> 总架构师对四视角分歧的拍板:**这些不是四个孤立缺陷,而是"压低输出空间换不专训"这一个范式张力的多张脸——该坚持地基、对齐名实、显式分层,而非推倒重来。**
|
||
|
||
---
|
||
|
||
> **延伸阅读**:这台生成机器的完整架构与端到端流程见[生成引擎主文档](README.md);"游戏即长生命周期源项目、LLM 是工作室"的范式原论述见同文 §3;固定架构 + 填槽的展开见[固定游戏架构](固定游戏架构.md);运行时与九门细节见[引擎与运行时](引擎与运行时.md);SAA 编排拓扑见[SAA编排](SAA编排.md);复杂品类"另一轨"的落地设计见[自治富游戏引擎](自治富游戏引擎.md)、[agentic 集成架构](agentic集成架构.md)、[tier2 实现详设](tier2实现详设.md)。
|