From 9ee58e19a0bdf94cdfd8c3fcdf8b799f52cd695b Mon Sep 17 00:00:00 2001 From: zizi Date: Sun, 21 Jun 2026 16:42:16 +0000 Subject: [PATCH] =?UTF-8?q?docs(tier2=E5=AE=9E=E7=8E=B0=E8=AF=A6=E8=AE=BE)?= =?UTF-8?q?:=20=E8=A1=A5=E7=8E=B0=E8=A1=8C=E8=A3=85=E8=BD=BD=E5=9F=BA?= =?UTF-8?q?=E7=BA=BF(engineBundle/GamePackage=20=E4=BB=8E=E5=BA=93?= =?UTF-8?q?=E5=8F=96)+=20spike=20=E8=B7=91=E5=BA=8F(M3=20=E5=85=88?= =?UTF-8?q?=E8=AF=81=E8=B7=AF+=E4=BA=BA=E9=AA=8C=E2=86=92flash/v4pro=20?= =?UTF-8?q?=E6=AF=94=E6=88=90=E6=9C=AC)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 --- docs/architecture/架构/生成引擎/tier2实现详设.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/architecture/架构/生成引擎/tier2实现详设.md b/docs/architecture/架构/生成引擎/tier2实现详设.md index 11809bab..9f48e049 100644 --- a/docs/architecture/架构/生成引擎/tier2实现详设.md +++ b/docs/architecture/架构/生成引擎/tier2实现详设.md @@ -7,7 +7,9 @@ ## 第一批工程定义:源项目契约 -tier2 的产物是一个真引擎工程 —— 多个源文件、一份构建脚本、一套依赖,build 出来才是能玩的游戏。它不复用 Tier0/1 那条 ECS-lite 装载路:现有廉价线把一份声明式数据壳塞进固定运行时就能玩,tier2 没有这层壳,它要把一整个 Phaser 工程编译、落库、寻址、再装进 feed。这两条装载路不通用,所以 tier2 立项要补的第一件工程,就是给真引擎工程新写一套源项目契约。 +先看现在的游戏怎么进浏览器,因为 tier2 要在这条路上接第二种产物。现在一款生成好的游戏不是仓库里的代码,而是一份存进库的数据:游戏代码被打成 `engineBundle`,内嵌在它那份 GamePackage 的 manifest JSON 里(整包带一个 sha256 校验)。玩家在 feed 点开,后端把这份 manifest 下发,浏览器取出 `engineBundle`、挂到 `window.__GameBundle`,`bootGameHost` 在沙箱 canvas 上把它跑起来,之后每帧回调游戏的 update / render。每款游戏就是库里一条 GamePackage,不是仓库里一份源码。 + +tier2 的产物也走"存进库、按需取来跑"这条路,但形态不同。它不是 Tier0/1 那种声明式数据壳 + 固定运行时,而是一个真 Phaser 引擎工程 —— 多个源文件、一份构建脚本、一套依赖,要先 esbuild 构建出 bundle 才能玩。这两条装载路不通用、解耦并存,所以 tier2 立项要补的第一件工程,就是给真引擎工程新写一套源项目契约。 这套契约要钉住七样东西,分四组。先是身份:一个**源项目类型标记**,让装载侧一眼分得清这是 ECS-lite 数据壳还是 tier2 引擎工程、走对应的装载分支。再是工程骨架:**文件树 manifest** 记下有哪些文件、各自什么角色(入口、场景、资产、配置),**入口文件**标出 build 从哪个文件起手,装载和寻址都按它们走。然后是构建可复现:**构建 profile** 固定这一款用什么命令、什么 esbuild 配置打包,**依赖锁**钉死引擎和插件的版本,免得上游一升级历史游戏就构建不出来。最后是落库取回:**内容哈希**给整个工程算一个指纹,做缓存命中和完整性校验;**落库与寻址 API** 定义工程怎么存进 MySQL 加对象存储、怎么按 id 取回来重建。 @@ -100,11 +102,13 @@ flowchart LR |---|---|---| | 主力便宜档 | deepseek-v4-flash | 现行 Tier0/1 打底模型,tier2 自治的主力候选 | | 强便宜档 | deepseek-v4-pro | 现行救场档,测"贵一档便宜模型"是否显著抬过门率 | -| 中等 agentic 档 | MiniMax-M3 | 用对它 = Anthropic /v1/messages 原生加 agentic 工具循环;tier2 ReAct 的天然候选 | +| 中等 agentic 档 | MiniMax-M3 | 用对它 = Anthropic /v1/messages 原生加 agentic 工具循环;这批最能打,**先用它证路**(见下"跑序") | | 强模型基线 | Opus / Fable | 只跑 1~2 款作"路通不通"的上限基线,不进成本评估 | 样本量上每个便宜/中等档跑 n ≥ 30 真跑(承袭"先跑 n≥30 真基线、别拿单次当基线"的硬教训),强模型基线 n = 2~3。题面用 5 个一句话变体(美食、水果、咖啡、面包、糖水店),每变体每档跑 6 次凑够 n≥30。跑在 mini-desktop —— 权威构建加 e2e 门、x86 同构;禁本机 6c6g 跑 chrome。 +**跑序:先用 M3 证路,再用便宜档比成本(2026-06-21 创始人定)。** 不一上来就把整张矩阵 × n≥30 全铺开。先用 MiniMax-M3 把路跑通 —— 它是这批便宜/中等档里最能打的一个(能力比 Sonnet 略强、且接得通),用它在全流程上自治产出一款 mini-肥鹅,创始人亲玩、判它确实是个有肥鹅味的可玩雏形。这一步证的是"便宜模型自治这条路到底走不走得通";走不通,就别在更便宜的模型上空耗。证通之后,再用 deepseek-v4-flash 和 deepseek-v4-pro 各跑一轮(n≥30)做对比,看把模型降到主力便宜档、过门率和单款成本各掉多少 —— 这一步证的是"便宜到什么程度还守得住"。Opus/Fable 那档仍只作路通不通的上限基线,不进成本评估。 + ### 过门判据与精确阈值 没有数字阈值,go/no-go 必然滑成"再调一轮",退路树也悬空。标 ★ 的是建议值、需创始人和实测校准,其余是承袭现行线的硬约束: