games-development-ai/docs/agent-specs/_archive/2026-06-20-生成设计合理性-对抗审查裁决.md

date, topic, status

date	topic	status
2026-06-20	生成设计合理性 · 对抗审查裁决	裁决 · 待创始人拍板(愿景分层)

这是对"我们核心生成设计(声明式结构化源 + curated rt 薄适配器 + 插件后置 + 九门)合理吗"的对抗深析裁决。 4 个临界视角(范式 / 能力面 / 产出质量 / 第一性原理)各读真代码找天花板与裂缝,总架构师综合;每条 fundamental/serious 指控已逐条 file:line 核实(见文末附录)。5 agent · 6c6g 编排+打磨。 一句话:部分合理——地基(确定性受控面 + 九门自动验收)是真护城河、该坚持;但它顶着"声明式结构化源"的名、内核却是"数据壳 + 未受契约约束的自由 JS",表达力被硬编码焊在 4 类几何色块玩具上。它是 Tier0 可靠产线、不是通用范式;最大风险 = 拿它去对标 demo 里的 Marvel/KOF。

核心生成设计裁决——给创始人

一、一句话总裁决

部分合理,且分歧可以收敛成一句话:这是一个为"便宜模型 + 自动验收"量身打造的、聪明的 Tier0 超休闲生成范式,工程取舍大半是对的;但它顶着"声明式结构化源"的名号,内核却是"声明式数据壳 + 一坨未受契约约束的自由 JS",而且表达力被运行时硬编码焊死在四类几何色块玩具上。它不是 OpenGame 自由工程的"更聪明上位替代",而是"低复杂度特例"。坚持它做 Tier0 是对的;拿它去够 demo 里 Marvel/KOF 那档愿景,是范式选错。

四个对抗视角各自独立得出"部分合理",措辞不同但裂缝指向同一处,这本身就是个强信号——不是某个审查者的偏见,而是设计里真有一道贯穿性的张力。我把它讲透。

二、真正合理、必须坚持的部分

先说该护住的。这套设计有三处取舍是经过深思的真功夫,不是凑数,创始人不要因为后面的批评就把这些一起推翻。

第一,把"确定性受控面"当作整个范式的地基,这是全盘最聪明的一步。 便宜模型产线的生死命门只有一个问题:能不能在没有人、没有 VLM 的情况下,自动判定一局游戏"真的可玩"。绝大多数同行栽在这里——他们能让模型吐出能跑的代码,却无法机器化地证明它可玩,于是只能靠截图、靠跑几帧、靠 VLM 打分,而这些都会被对抗、会漂移。这套设计的回答是:把随机、时间、输入全部收进受控种子(gd-runtime.js 里 rt.random/rt.time.now 一律走 ctx),把胜负置成不可逆的 latch 终态(latch() 一旦置定就停摆),再在 state() 里把整个游戏世界投影成 driver 能用命名路径读取的取证形状(实体按 id 投影成 ball.x/paddle.x,带 tag 的汇成 targets[])。这三件事合起来,才让九门 harness 能用确定性对照去"真玩一局并判定"。我亲手核对了代码,这些不是设计文档里的许诺,是运行时里真实存在的机制。这是该范式最硬的正当性——它不是给玩具加约束,而是为"自动验收"这个产品命门做的地基。 自由 Phaser 工程里状态散在各 Manager 的私有字段里,要做同等取证得逐个工程定制探针,根本无法规模化。这一步,创始人当初拍得对。

第二,"behaviors 只写逻辑不写画" + 声明式渲染器,是把约束花在了刀刃上。 实测数据反复证明,便宜模型在 canvas 绘制、requestAnimationFrame 驱帧、事件订阅这三个高频面上漂移率极高。这套设计干脆把出图整个从模型手里拿走——渲染器据 render 组件自动画,模型的 behavior 只能经 rt 操作世界。三个最大的 bug 源被结构性地消除了。更精彩的是 clickable 这个内置基元:实测发现连强模型都常把"点击命中"误门控在一个分离的 state 或计时器上,导致 driver 永远点不中、E_live/G_input/F/H 四门连环挂。这套设计把"点中目标→翻状态→spawn 标记→计分→fx"整条内置成运行时基元,离散点击类只要声明一个 clickable 组件就行。这是"缩小生成域、扩大平台域"哲学的最佳实证——用平台的确定性代码,换整整一类游戏的可靠性。 这个判断,是真正理解了便宜模型脾性之后才做得出来的。

第三,验收边界禁止 LLM 自评,以及"框架可换、成本单点"的接缝,这两条工程纪律是对的。 done 钉死在真浏览器真玩的九门上,而非模型自夸,这比 OpenGame 用 VLM-judge 打分更抗 Goodhart——VLM 本身会被对抗、会漂移,而确定性门不会。同时,把生成逻辑藏在 dispatcher 契约之后、模型只走单一 new-api 成本层,意味着"便宜模型 vs 专训模型""SAA vs ReAct vs 换框架"全都变成接缝后的可替换选择,而不是架构重写。对照 OpenGame 把能力焊死在 qwen-code 运行时加 GameCoder-27B 专训权重上——它们换底座要重训,我们的赌注是可回退的。这一条在"便宜模型可能撞天花板"这个核心不确定性面前,留足了退路,是成熟架构师的做法。

还有一处方向性正确但要打个折:"游戏即长生命周期源项目、改源不改包"的产品基座判断是对的,平台化(而非工具化)确实需要可 diff、可改、可重建的源。但要诚实——这个优势目前只覆盖了声明式数据那一半(实体/场景/数值,config 走数据驱动可免 LLM 改参),逻辑那一半仍是自由 JS,可维护性红利在最关键的"有趣逻辑"处打了折。这把我引到裂缝。

三、真正的天花板与裂缝

按 fundamental → serious 排。我会明确每一条是"范式级病灶"还是"可补的工程缺口"——这个区分决定了创始人该不该动刀、动哪把刀。

裂缝一(fundamental,范式级·名实不符):承载 100% 游戏逻辑的 behavior.code,根本没有进契约。 这是四视角里最尖锐、也是我亲手验证最确凿的一条。schema 里 behavior 的定义只声明了 id 和 trigger 两个字段,required 也只有这俩,而真正装着全部玩法逻辑的 code 字段,是靠 additionalProperties:true 偷渡进来的,运行时甚至还接受一个未文档化的 js 别名。这意味着什么?我们对外宣称这是"声明式结构化源",但它真实的结构是"声明式数据壳 + 未受契约约束的自由代码核"。 entities/components/scenes/rules 那层声明式外壳是真的,可游戏的灵魂——逻辑——依旧是一坨任意 JS 字符串。后果是连锁的:契约对最关键的产物零约束,于是校验落空、版本化落空、可寻址性落空——sourceHash 哈希的是一个内含任意代码串的 JSON,改一个字符哈希就变,根本无法对逻辑做点对点的 diff 和结构化迭代。我们号称的"长生命周期项目"优势,在逻辑这一半上是悬空的。

这是范式级问题,因为它戳破了设计的自我叙事。但请注意,它不是"这设计废了",而是"这设计名不副实"——补法是把名号和现实对齐,而不是推倒。后面第四节我给具体改法。

裂缝二(fundamental,范式级·表达力天花板):能产的游戏复杂度被运行时硬编码焊死在四类玩具上,且这道墙撞得很近。 这不是理论推测,是代码现状:scenes 只取 scenes[0](多关卡无从谈起),advance 推进是注释写明的 v0 占位空操作(gd-runtime.js:256),渲染只有 rect/circle/fill 三种形状,物理只有 vx/vy + gravity 一条单一积分路径,进度只有一个全局 score 加 win/lose 二元。它能撑的,就是 pong/clicker/dodge/runner 这四类——休闲单局小游戏。任何需要多关卡推进、库存/对话树、敌人 AI 状态机、tilemap/寻路、相机、可变 HUD 流程的品类,这套 runtime 没有对应的声明面,也没有调度器去承载。schema 注释自己都坦白了"非 AAA ECS:无 system 调度器、无 archetype、无 query DSL"。

对照 OpenGame 才看得清这道墙的高度:它的 platformer 模块 8435 行(PlayerFSM/ChaseAI/PatrolAI/SkillBehavior/BehaviorManager),tower_defense 3877 行(WaveManager/EconomyManager)。那一层结构化复杂度,不是我们的模型不够强,而是 runtime 根本没有承载它的形状——给再强的模型,它也只能把复杂逻辑硬塞进一个 update 串里,然后撞上"自由 JS 核"那道裂缝。这一条之所以是 fundamental 而非工程缺口,是因为它和我们对标的产品愿景正面冲突:demo 里放的是 Marvel 平台动作、KOF 格斗这种富交互游戏,而这套范式结构性地产不出那一档。 这是产品愿景级的天花板,不是补个分支能解决的。

裂缝三(fundamental,范式级·"好玩好看"无下限托底):九门只判机制地板,产出质量上限实质由便宜模型单点决定。 把前面两条往产品端推一步,就是这条。九门作为"机制 CI"设计得很精良、很抗假绿——C 门拦单步假推进、E 门用哈希拦冻屏、G 门用同种子同帧号 A/B 对照隔离"靠自走动画蒙混过活性"、H 门验 gameover 不自动重开,driver 家族还做了速度前瞻、抛物线反解这种"测试侧也得会玩"的真功夫。这一层我给高分。但九门保证的是"机制合法",中间整段"好玩"没有任何硬门或软门兜底。 同一套九门下,一个精心设计的打砖块和一个"摆 3 个砖块点一下就 win"的退化品,都能全绿。

"好看"那一侧更直接撞墙:渲染器只画色块,而 SourceProject.assets 那六类资产规格在整条 build 链上零消费者——我 grep 过整个 host 目录,白名单根本不含 assets,模型即便用 mmx 产出了精美 sprite,当前链路也会原样丢弃,渲出来永远是几何色块。而大众"想玩的游戏","好看"是 feed 第一屏的入场券,色块画面会被直接划走。叠加上记忆里 SaaFullGraphE2eTest 便宜模型成功率只有 60%、连"机制稳定产出"都未达 80% 门——把"大众想玩"这个愿景级目标,押在一个"机制都还没稳、好玩好看零下限保护"的单点上,是当前架构最大的产品风险。

我必须诚实指出:这三条 fundamental 不是三个独立 bug,而是同一个范式张力的三张脸——"用压低输出空间换不专训"。压低输出空间(声明式壳 + 窄 rt 面 + 硬编码渲染物理)确实把简单品类的可靠性和可验收性拉上去了,这是真价值;但同一个动作,也把可产游戏的复杂度上限、视觉质量上限、"有趣"的表达空间一起压低了。这不是设计做错了,而是这套设计天然只能站在"可靠"这一端,够不到"复杂/精美"那一端。 危险的不是它有天花板,而是把它当"通用生成范式"去卖。

裂缝四(serious,工程缺口·安全押在脆弱正则上):new Function 编译不可信模型代码,安全完全靠正则黑名单兜。 behavior 和 rule.condition 都走裸 new Function,无沙箱,安全靠 build 期的 LOGIC_BANS/CONDITION_BANS 正则(禁 process/eval/.constructor/while(true) 等)。正则黑名单对 JS 是出了名的可绕——模板字符串拼接、Unicode 转义、[].filter.constructor 变体都能逃。作者自己在注释里也承认这是"new Function 不沙箱的现实缓解"。这条是 serious 而非 fundamental,因为方向其实是对的,只是定位错了:既然只在浏览器 CDP harness 里跑,浏览器进程本身就是安全边界,scanLogic 该被诚实定位成"质量门/确定性门"而非"安全门"。真要防逃逸,靠 iframe sandbox + CSP + 进程隔离,而非正则。顺带一个真实的可调试性债:behavior 抛错只回灌一行 message,无行号无 source map,模型和人都难定位——给注入代码包一层 //# sourceURL=behavior/<id> 就能让错误栈带名,这是低成本高回报的补丁。

裂缝五(serious,工程缺口·rt 面四处人手双写无一致性门): 加一个 rt 能力,要同时手改 Java prompt 字符串、gd-runtime.js 实现、runtime-api-2d.md 文档、build 禁则四处。当前 rt 面被刻意冻在约 20 个函数(YAGNI),这个成本现在可控,且 prompt 与运行时目前没有 split-brain(我核对过,prompt 承诺的面运行时真有)。但这是静默高危的演进期债:漂移一旦发生(prompt 说有 rt.X 但运行时没有 → 模型生成 → undefined → 九门挂),排查成本极高。不必上重型注册表(那是过度工程),对症解是加一道一致性测试:从 gd-runtime.js 反射出真实合法 rt 面集,断言它与 prompt 里的 rt.* token 集、文档表三者相等,diff 即红。把"四处人手同步"降级成"改任一处测试逼你改齐"。

裂缝六(serious,工程缺口·九插件对主线全不可达): 团队花整整一波建的九个能力插件(collision 的 SAT/MTV、physics-lite 刚体、gamefeel 的缓动/屏震/hitStop),在结构化生成主线里一个都用不上——gd-runtime.js 零 import PluginRegistry,只经 getEngine() 拿引擎三面(粒子/音频/数学)。这意味着 gamedef 能表达的物理只有最朴素的 vx/vy 积分加 AABB 重叠,想要"带法线的弹性反弹""缓动入场""屏震 juice"都做不到——手感被实打实压低一档。这是 serious 而非 fundamental,因为它有清晰的升级路径:当某个插件能力被验证"可靠产出且九门可测"时,经 rt.fx 家族扩一个声明式入口(如 rt.fx.shake/rt.tween)纳入 gamedef 面。 但必须立刻把这道落差写进路线图,否则九插件会变成"为 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 的"无副作用"约束只在 build 期静态扫,运行时 new Function('return (cond)') 并不强制,双边界对纯净性的保证强度不一致,让两边共用同一份禁则定义即可。

四、要让它更合理,具体改什么

我不主张推倒。这套设计的地基(确定性受控面 + 自动验收)是对的,该做的是"对齐名实、明确分层、补上几道门"。按优先级:

改动一(最高优先·定性纠偏):诚实地给范式正名,并把愿景显式分层。 别再对内对外叫"纯声明式结构化源",它是"结构化外壳 + 受限逻辑"的混合范式。同时,把"便宜模型 + 约束 schema"明确锁定为 Tier0:可发行轻游戏(超休闲/合成/挂机/答题/网格点选)的可靠产线,并把这档的复杂度边界、视觉边界白纸黑字写进 profile 的承诺里。最大的风险不是设计有天花板,而是产品团队拿它当"通用生成范式"去对标 demo 里的 Marvel/KOF。 富交互品类要么显式推迟,要么走 OpenGame 式受控自由工程 + 更强模型的独立轨——别让一套 schema 同时背"可靠"和"复杂"两个互斥目标。这一条不花一行代码,却是整个裁决里最重要的动作。

改动二(高优先·把逻辑层往结构化拽回来):把高频 idiom 沉淀成声明式 behavior kind,让 code 字符串退场到长尾兜底。 当前四个原型其实都能用五六个内置 behavior kind(移动/积分/碰撞 lose/计时 spawn/clickable 那样)表达。把这些做成可组合的声明式原语库——类似 OpenGame 的 PlatformerMovement/ChaseAI 那种"可选可配"的件——让便宜模型从"写任意 JS"降级成"选 + 配组合",才真正吃到约束式的可靠性红利。任意 JS 逃逸口只留给少数高阶场景。这一步同时缓解裂缝一(逻辑可契约化了)、裂缝四(逃逸面缩小)和"模型成功率 60%"(选配比手写错误率低得多)。

改动三(高优先·让 assetSpec 从孤儿契约转成有消费端): 这是打通"好看"的唯一路径,且它是一整条链不是一个分支——① 渲染器加 sprite 分支(render 组件增 spriteRef → 引擎 drawTile);② build 白名单纳入 assets 并在 rt 暴露资产解析;③ 同步把 D 门从"非白屏"升级成"非纯色块/有结构"的视觉判据(颜色直方图复杂度/边缘密度),否则接了 sprite 门也测不出视觉退化,等于白接。在这条链打通前,路线图必须明确标注"当前产出 = 色块原型,非可发行视觉品质",杜绝把"机制门全绿"误读成"产品就绪"。

改动四(中优先·给"好玩"立独立质量轴): 别让九门兼任"好玩"判官。补一道便宜的启发式门——动作类看 driver 真玩时分数增长曲线是否非平非爆、失败是否可达且非秒败——给 0-100 分而非 pass/fail,作 feed 排序与 repair 信号。把"好玩"明确从九门责任里剥离:九门 = 机制 CI,好玩 = 另一条评审/数据回灌轨。 否则机制全绿会持续制造"质量已达标"的错觉。

改动五(中优先·三道一致性/调试补丁): rt 面加一致性测试(裂缝五);注入代码包 //# sourceURL 让错误栈带名(裂缝四);把 condition 双边界共用同一份禁则定义(裂缝二)。这三条都是低成本、止住静默漂移的对症解。

改动六(战略级·给生成产线自己的 compounding 飞轮): 当前 schema/rt/模板都是 Opus 人工设计的静态资产,量上来后会成为瓶颈——而护城河四层里就有"资产沉淀"和"网络效应"。OpenGame 有 Template Skill 五段管线从每个完成项目里自动萃取新模板家族,我们没有。建议:把过门的 gameDefinition 做成生成侧的进化语料,从高频 entity/behavior 组合聚类,半自动沉淀为品类 prompt 模板/行为原语,给生成产线一个自我增强的飞轮,而非永远靠 Opus 手动加模板。这一条不紧急,但决定了平台能否真正"越跑越强"。

五、收口:这设计能到产品愿景吗

能到一半,且那一半是真护城河;另一半它够不着,必须靠分层和另一条轨。

这套设计能可靠地、低成本地、机器可验收地批量产出超休闲轻游戏——这正是"零门槛用户一句话造可玩游戏"这个差异化闭环最难、也最值钱的一环。竞品大多停在"生成工具",死在"无法证明可玩";我们这套确定性受控面 + 九门 harness 真的把"能生成 ≠ 能玩"这条假绿线焊死了,这是别人短期补不上的工程纵深。作为 Tier0 产线,它合理、聪明、该坚持。

但产品愿景里 demo 对标的 Marvel 平台动作、KOF 格斗那一档富交互游戏,这套范式结构性地够不着——不是模型不够强,是 runtime 没有承载那层复杂度的形状,逻辑核又还是没被结构化的自由 JS。愿景必须诚实分层:Tier0 用这套吃"可靠 + 可验收 + 规模",复杂品类另开一轨。 把这两件事混为一谈、用一套 schema 同时承诺"可靠"和"复杂",是当前唯一的范式级误判风险。

一句话给创始人:这设计哪里都没"错",它只是被起错了名、被寄予了它够不到的期望。把名字改对(混合范式)、把愿景分层(Tier0 不碰 Marvel)、把逻辑往声明式拽回来、把 assets 链打通——做完这四件,它就是一个诚实、强壮、有护城河的 Tier0 生成范式;不做,它迟早会因为"被当通用范式卖"而在第一款复杂游戏的 demo 上当众撞墙。

---

裁决依据已逐条代码核实(source-project.schema.json behavior 仅声明 id/trigger + additionalProperties:true;gd-runtime.js 渲染器仅 circle/rect/fill、advance v0 空操作、单场景 scenes[0]、单一物理积分、裸 new Function + js 别名;build-from-source.mjs GAMEDEF_KEYS 五项白名单丢弃 assets、安全靠正则黑名单;host 全目录对 sprite/assets/drawTile 零消费者)。四视角的全部 fundamental/serious 指控均属实,我对分歧的拍板是:它们不是四个孤立缺陷,而是"压低输出空间换不专训"这一个范式张力的四张脸——该坚持地基、对齐名实、显式分层,而非推倒重来。