30 KiB
src/ 终态迁移 + 产线化(plan 2026-06-18-001 U1–U4)中,文中标注的现行结论可能随推进变化;以子树 README 与最新裁定 / plan 为准。
date: 2026-06-20
topic: 生成设计合理性 · 对抗审查裁决
status: 裁决 · 待创始人拍板(愿景分层)
生成引擎 · 设计合理性裁决
这是什么:对绘境AI 核心生成设计"到底合不合理"的一次对抗式深度审查裁决。它不讲这台机器怎么搭(那在生成引擎主文档),只回答一个判断题——我们押注的这套生成范式,是该坚持、该修补,还是该推倒。 给谁看:创始人、生成主线的架构负责人、做尽调时想看清"护城河到底硬在哪、天花板在哪"的人。 怎么读:先读 §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 即"测试夹具"),其中有九道确定性检查门——能不能装载、跑不跑帧、响不响应输入、到不到游戏终态等等。它是这套设计最硬的工程价值,详见主文档 §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、可改、可重建的源——这条范式原则的完整论述见主文档 §3。
但要诚实:这个优势目前只覆盖了"声明式数据"那一半(实体/场景/数值——config 走数据驱动,改参数可以免 LLM),而逻辑那一半仍是自由 JS,可维护性红利在最关键的"有趣逻辑"处打了折。这把我们引向裂缝。
3. 真正的天花板与裂缝
下面按 fundamental → serious 排列每条裂缝,并明确标注它是"范式级病灶"还是"可补的工程缺口"。
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. 要让它更合理,具体改什么
审查者不主张推倒。这套设计的地基(确定性受控面 + 自动验收)是对的,该做的是**"对齐名实、明确分层、补上几道门"**。按优先级排,核心是四改(改动一至四),外加两条配套(改动五、改动六):
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 富游戏自治轨,设计见同目录 自治富游戏引擎、agentic 集成架构、tier2 实现详设。
一句话给创始人:
这设计哪里都没"错",它只是被起错了名、被寄予了它够不到的期望。把名字改对(混合范式)、把愿景分层(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% 门 |
总架构师对四视角分歧的拍板:这些不是四个孤立缺陷,而是"压低输出空间换不专训"这一个范式张力的多张脸——该坚持地基、对齐名实、显式分层,而非推倒重来。
延伸阅读:这台生成机器的完整架构与端到端流程见生成引擎主文档;"游戏即长生命周期源项目、LLM 是工作室"的范式原论述见同文 §3;固定架构 + 填槽的展开见固定游戏架构;运行时与九门细节见引擎与运行时;SAA 编排拓扑见SAA编排;复杂品类"另一轨"的落地设计见自治富游戏引擎、agentic 集成架构、tier2 实现详设。