zizi-al/games-development-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
games-development-ai/docs/plans/2026-06-20-关闭九门判定-全面参考OpenGame-决策与Phase0-4.md
lili f4c6789312 docs(saa): 蒸馏 M3 thinking 治理/协议/流式 + rc 门修(91.7% 跃迁) → .agents 技能 + 决策档 
§7 知识沉淀（仓库权威版，配套代码提交 4e5a7bbf）：

- .agents/skills/saa-graph-orchestration.md：新增 §3.5「M3 thinking 治理 + 协议/流式」——M3 thinking 二元(无深度/budget、提示词压不住)；openai adaptive 内联污染→只能关；anthropic 原生分离要质量走这条但必配【流式 StreamingCallChatModel + NO_PROXY webClientBuilder】否则阻塞整取大面积 SocketTimeout；#4407 对 1.1.2 过时；rc 门耦合 bug(playNode pass 别前置 rc==0)。e2e 段补 2026-06-20 跃迁(67%→91.7%、证伪模型天花板)。
- docs/plans/2026-06-20-…md：状态 banner→主线达成 + 追加 §7 结果与修正(rc 真根因 / thinking+协议杠杆 / 实测对照 / n=12 达标口径放宽 / 未尽项)。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 11:38:59 -07:00

6.5 KiB
Raw Blame History

关闭九门 driver 判定 · 全面参考 OpenGame · Phase 0–4 决策记录

状态：✅ 主线达成(2026-06-20：rc 门修使 Phase 1 真生效 + 改 anthropic 流式 thinking → gamedef e2e 91.7%、按 n=12 达标；详见末节「§7 结果与修正」)。execution-spec/Codex×Opus 双评审仍为 follow-up。 决策人 / 日期：创始人 / 2026-06-20。 一句话:把"逐品类手写 driver 自动试玩"从生成硬门降级,生成环改只认客观健康门(build-health, A–F),验证全面对标 OpenGame(方法蓝图,非 Phaser 运行时)。

1. 决策内容

  1. 关闭九门 driver 判定对生成的绑架:生成环(SAA 管线)硬门 = 客观健康门 A–F;driver 依赖门 G_input / H_progress / I_control 不再否决生成、不进救场回喂。九门 harness 仍照常跑并写 verdict.json(不动门判定本身),仅改"生成环如何消费 verdict",双轨可回退(-Dsaa.gen.gateMode=all9 退回旧聚合 pass)。
  2. 全面参考 OpenGame:采纳其方法蓝图——agentic 编码循环 / Template-First+hook 覆写 / 活调试协议 / build-health+VLM 验证 / 薄 prompt+按需 archetype doc;落在我们 LittleJS + gamedef + 便宜模型 栈;不照搬 Phaser/TS/GameCoder-27B 运行时(评审 2026-06-14-OpenGame蓝图补缺-review D1 已划线)。
  3. 反转前约束:本会话早前的"never edit nine-gate judgment logic"安全约束由创始人 2026-06-20 显式解除。

2. 为什么(证据)

  • n=1 铁证:M3 openai 流式 n=1 实测,游戏过尽全部客观门(A_boot/B_uncaught/C_frame/D_render/E_live/F_wiring),只挂 I_control+H_progress(driver 门)→ 几乎肯定是可玩游戏,纯被 driver 玩不动误杀。
  • Phase 0 去混杂基线:跨日志门失败分布 H_progress 24 / G_input 7 / F_wiring 5 / E_live 4 / I_control 1,~78% 失败是 driver 依赖门;A_boot/B/C_frame/D_render 零失败。all-9 历史率 ≈ 50%,推断客观-only 率 ~80–90%(精确值待 Phase 1 新口径重测)。
  • OpenGame 源码+论文(leigest519/OpenGame,arXiv 2604.18394):验证 = build-health + VLM(无 driver);消融最大杠杆 = hook/模板 +10.1 BH、活调试协议 +6.9、模板族 +5.8;prompt = 薄基座 + 按 archetype 动态装配 doc + 匹配式调试库。
  • SOTA 校准:OpenGame + Claude Sonnet 4.6 也只 BH 72.4 / VU 67.2 / IA 65.1(复合分,口径异)→ "一句话自由生成可玩游戏"前沿在七成上下,我们 ≥80% 自由生成目标偏激进,主失败源是 driver 测量偏差而非模型天花板。

3. Phase 0–4

Phase 内容 状态
0 去混杂基线(挖现有 verdict 样本:A–F vs all-9) ✅ 完成(§2)
1 关闭九门对生成的绑架 + prompt/driver 解耦 进行中:1a 代码门解耦 ✅ 编译验证;1b prompt 解耦起草中
2 Template-First 骨架(+10.1):每 archetype 已验证 gamedef 骨架 + hook 覆写 待办
3 活调试协议/离线 linter(+6.9):坑入版本化匹配库,真玩前静态门回灌 待办
4 build-health + VLM 验证替换 driver 判定;自修复封 T=3;达标 flip 待办(注:SaaStudioNodes.judgeVision 已有 VLM 雏形)

4. 客观门 vs driver 门(Phase 1 口径)

  • 客观健康门(build-health·play-independent,生成硬门):A_boot / B_uncaught / C_frame / D_render / E_live。
  • driver 依赖门(降级为参考,不否决生成):G_input / H_progress / I_control。
  • F_wiring 已移出客观硬门(2026-06-20 实测 n=2 发现):它靠游戏事件触发 rt.fx,无 driver 真玩→事件不触发→必挂=play-dependent(实测两局均挂 [F_wiring,H_progress],但 A–E 全过=游戏本身可跑可动)。"真用引擎/有特效"语义改由 player 节点 VLM 看截图判(OpenGame VU 口径);彻底解法见 Phase 4(VLM 升打分门 / harness 通用 input-poker 触发事件)。
  • 实现:SaaGenNodes.objectiveGatesPass() + OBJECTIVE_GATES 常量 + GATE_ALL9 开关;summarizeFailedGuards 客观门模式下不回喂 driver 门失败。

5. Blast radius / 回退

  • 改动面:SaaGenNodes.java(生成环 verdict 消费口径);后续 SaaPrompts.java(prompt 解耦)。
  • 不改:play.cdp.cjs 九门判定逻辑、gd-runtime.js、verdict.json 产物结构。
  • 回退:-Dsaa.gen.gateMode=all9 即恢复旧"九门聚合 pass"硬门。

6. Follow-up(不阻塞执行)

  • 出 Phase 0–4 execution-spec 并过 §6.8 Codex×Opus 双评审(task #18)。
  • Phase 4 VLM 验证口径(对标 OpenGame BH/VU/IA)单独定义 + 契约无关基线 parity 门(≥ 现客观基线才 flip 默认)。

7. 2026-06-20 结果与修正（已提交 4e5a7bbf → feat/mac-gamedef-qc-concurrent）

执行中发现 + 修正，最终把 gamedef 生成质量做到 91.7%（超 80 门）：

  1. rc 门耦合 bug（Phase 1 真根因）：§4 的客观门解耦写对了，但 SaaGenNodes.playNode 的 pass 前置了 rc==0，而 play.cdp.cjs 退出码=九门聚合（任一门含 driver 门挂即 exit 1）→ driver 门失败 rc=1 反向否决客观 pass，使 Phase 1 形同虚设、空跑 8 轮救场烧 302K token。修：客观门模式 pass=(rc==0||rc==1)&&objectiveGatesPass。修后 Phase 1 真生效。
  2. 生成质量杠杆 = thinking + 协议（先于 Phase 2 模板即见效）：便宜模型"哑火静态游戏"（E_live 不动=没接对运动逻辑）是最大失败簇；开 M3 thinking 修了它。M3 thinking 仅二元（无深度/budget、提示词压不住）；openai 路 adaptive 内联污染 JSON+截断→只能关；改走 anthropic 原生分离 + 流式（StreamingCallChatModel + NO_PROXY webClient，治阻塞 SocketTimeout；#4407 对 1.1.2 过时）+ max_tokens 256k。详见 .agents/skills/saa-graph-orchestration.md §3.5。
  3. 实测对照（conc=12 gamedef）：thinking-off 8/12(67%、哑火×4) → thinking-on 11/12(91.7%、哑火修 3/4)；残留 #7 打地鼠（天生无运动点击类，E_live 苛、思考也救不活→留 Phase 2 模板 / E_live 口径调整）。代价 ~10x 慢 + 1.6x token。
  4. 达标口径放宽（创始人拍板）：以 n=12/91.7% 宣告达标（非原 plan003 n≥30——n≥30 只多给方差信息，不改"thinking-on 更好且过门"的结论）。
  5. 证伪"模型天花板"：§2 曾忧"≥80% 偏激进 / 前沿七成"——便宜模型经"对的协议 + 开思考"实达九成，主瓶颈是工程配置非模型天花板。
  6. 未尽：#7 无运动点击类；速度代价（adaptive 无界、单局 20–73min，上线要治）；Phase 2/3/4（模板 / 活调试 / VLM 门）仍可叠加作进一步增益。