games-development-ai/docs/architecture/00-系统总览图说.md

date, topic, status

date	topic	status
2026-06-22	系统总览图说——绘境AI 架构图集的总图 + 目录(系统级 9 图 + 下钻各域)	现行为主(系统级 9 图)· 架构图集入口 · 通用图例与按角色路径在此

00 · 系统总览图说

图集定位:六域设计树(架构域 README 与本目录产品 / 架构 / 后端 / 前端 / 运营 / 运维 6 域)是设计的单一事实源(SoT)——读它 = 当前真相;本图集是它的派生视图。图与域树冲突时,一律以域树为准。

这是什么:绘境AI 架构图集的总图 + 目录——整套图集按领域拆成 8 篇(本篇 00 系统总览 + 01–07 各域,每篇一个文档、各含该域全部图与讲解)。本篇是入口:先读下面九张系统级跨域图建立全局轮廓,再按目录下钻到某个领域那一篇。 怎么读:先看「系统级 9 图」(系统怎么分层、三档生成怎么按 AI 参与深度统一在 AgentScope 框架下、引擎随复杂度选 LittleJS 还是 Phaser、数据怎么回流、钱怎么转、失败怎么兜、鉴权边界在哪、端到端全链怎么串、系统边界与外部依赖在哪),再按你的角色或任务选某领域下钻(见文末「按角色读」)。所有 SVG 仍在各子目录 assets/ 下,各篇经相对路径引用、inline 渲染。

---

各领域图说(目录 · 下钻入口)

• 01 · 产品图说 — 产品定义 ≠ 建设进度;护城河「不假装有墙」
• 02 · 架构图说 — 图 11 契约 5 处现实缝;决策史别当现行
• 03 · 产物执行沙箱图说 — 别把机制已建当已安全;两条正交边界别混
• 04 · 后端图说 — DB 镜像漂移;桩与真分清;全图无物理外键
• 05 · 前端图说 — 试玩宿主机制建成 ≠ 合规收口;同源过渡态三债
• 06 · 运营图说 — 元素级被阻塞部分别画成已建;8 项法定 P0 待律所
• 07 · 运维图说 — 观测 = 待接、k3s = 缓做,别画成现行
• 生成引擎子树(护城河关键路径,内容最厚、正被另一条 session 在飞建设)→ 生成引擎 README(本图集只链接、不并入;系统级图 3「三档生成与引擎选型」已给其总闸轮廓)

---

0. 怎么读 + 全图通用图例

这份主档的形态,是「先定向、再下钻」。 它分功能段:第一篇是系统定向图集,用九张系统级大图把整个系统的轮廓自顶向下讲清楚;第二到第八篇是七个领域的全部图说,把各域的每一张图与每一段讲解都搬进来 inline。建议的读法是:先把第一篇九张图连讲解读完(建立全局轮廓),再按你的角色或当前任务,选某一两个领域的篇章下钻(文末给了按角色推荐的路径)。读完第一篇,你应该能回答「这是个什么系统、分几层、三档生成怎么按 AI 参与深度统一在一套框架下、引擎按复杂度怎么选、数据怎么回流、钱怎么转」;读完某领域那一篇,你应该知道「这块的图在哪、它的命门是哪条缝」。

单源纪律(本图集的硬约束)。 这份图集要消灭的就是「同一张图存两处、改一处漏一处」的漂移面。在原来的多文件形态下,本图集靠「系统级图内联、领域图只链接」来守这条纪律。本主档是单一全量主档,定位就是把所有图说 inline 在一篇——所以原各域图说里那种「单源引用、不复制 README 的图,只给链接」的声明,在本文里改成直接内联该 README 对应节的 Mermaid 块(让它真渲染),并在图下注明图源;原「单源不复制」的声明段相应删去。系统级图与领域图仍是互补、不重复:领域图回答「这一块内部长什么样」,系统级图回答「这些块如何跨域串成一个整体」;本文不会把同一张图在不同篇章各画一份。

同步纪律 + 防漂移门。 设计档一变动,本主档与对应 SVG 必须同步更新。本文 frontmatter 记了全部 8 份图说源档 + 6 份 README(引图 Mermaid 来源)的当前 commit hash 作为防漂移门:任一源档变更、hash 对不上,本文与对应 SVG 即标「待复核」,由收口脚本比对。每张 SVG 的映射源档与状态在其所属篇章的散文与状态表里注明。

现行 / 待建 / 已废,严格标注。 全文凡涉及尚未建成或被推翻的方案,一律用虚线框 + 文字小标画出,与「现行已建」的实心块一眼区分。几类边界必须看清:三档统一框架——绘境AI 收敛到 AgentScope 一套框架,按 AI 参与深度分 Tier0/1/2 三档(三档全高度模板化:玩法模板 + 工程骨架,不是从零生成),引擎按复杂度选(轻-中档 LittleJS、最高档 Phaser),SAA / Dify / Coze 降到最低优先级、留作「远期适配验证可插拔」目标;tier2 富游戏档(= AgentScope + Phaser)的 0 号 spike 已过 accept、核心代码已落,验证走 n=5 收敛环(并发跑 5、有错追加 5、收敛即 go),产品化排期待定;future-state(k3s 缓做、观测体系待接线);Nacos / RocketMQ / Sentinel 已于 2026-07-01 反转为 MVP 生产 runtime(自托管 mini-infra:Nacos 配置中心+服务发现、RocketMQ 异步 gen 队列、Sentinel 准入侧流控;接入实现进行中);已废(Dify / OpenGame 从未部署降远期、gameDefinition 与玩法填参式模板及 15KB 红线均已废除);A-model 写真 src/(生成产物的终态 = src/ 多文件源项目,gameDefinition 已废、现行直接由 A-model 写真 src/,既无 factory/gamedef 双轨、也无 cutover 切换)。把这些诚实画出,正是为了让据图 review 的人不会把待建或已废的方案误当现行。

产物形式。 系统级 SVG 入仓(GitHub 与编辑器直接渲染矢量),PNG 在 mini-desktop 批量转(6c6g 禁 chrome、无转换器);Mermaid 图 GitHub 直接渲染、无需转换。本文不转 PNG、不动任何 SVG 文件、不碰生成引擎子树。

全图通用图例

整套图集(含本主档)共用一套视觉约定,读任何一张图都按这套理解。

生产维度徽章(用小色块 chip + 白字标在每张图相关的维度上)。七个维度对应七种「这套设计在为什么负责」:

• 安全(#dc2626):iframe 沙箱 + CSP 红线、权限只在后端可信边界强制、打款 fail-fast 绝不发假钱、上游 API key 不裸暴露。
• 可观测(#0ea5e9):四路信号(Metrics / Traces / Logs / Errors)+ SAA 节点 observation——但落地态是「接」(待接线),详见运维域。
• 可靠(#16a34a):幂等矩阵、最终一致 + 补偿、SLO + Error Budget、多通道兜底——涉及外部模型 / 异步 / 支付,可靠性必须前置。
• 成本(#16a34a):复用 Huijing 买现成后台、便宜模型直出、单 key 入计费台账、内网物理机不上云——都是「5 人小团队 + ¥4,300/月」跑起来的取舍。
• 数据(#475569):契约即跨端数据边界、推荐用信号驱动排序、行为数据回流「越用越聪明」——数据口径对不对,是系统能不能闭环的根。
• 伸缩(#7c3aed):单体平滑长成微服务、Redis 候选集适配无限流、声明式编排平滑长多节点。
• 质量(#15803d):harness 九门兜底、三层约束框架、error_rate 硬降权保可玩底线——质量是设计进去的,不是 LLM 自评。

复用 / 边界三线语义:

• 实线(#334155):现成直接用、同步动作、单向依赖或数据流的正向推进。
• 虚线(#64748b,stroke-dasharray="6 4"):自建 / 解耦 / 远期 / 待接线 / 决策史的目标态或对照态;远期·待建项用紫色 #7c3aed,失败 / 资金红线分支用红色 #dc2626。
• 双线 / 加粗框:跨域共享的公共件,或需要强调的硬边界(如三档生成共用的公共件、资金硬边界)。

状态码(贯穿全图集):现 = 现行已建 / 已实测 · 接 = 现行待接线(设计已出、代码未接) · 建 = 待建 · 缓 = 缓做(排在 W-G1 之后) · F / future = future-state(框架自带未部署 / 远期轨) · 废 = 决策史对照(被推翻的旧方案)。全文凡远期 / 待接 / 缓做 / 已废的元素一律虚线框 + 小标,绝不画成现行。

各域特有的状态分布(各篇沿用本图例,这里把各域整体状态分布先汇总一句,各篇开头再展开):第一篇系统级=现 ×5、现 + F ×3、现 + 接 ×1(共 9 图);产品=九图整体「现」(定义层,两处元素级 future-state);架构=现 ×10 + 现+史 ×1 + 现+废 ×1;产物执行沙箱=现 ×7(机制全建成,四处现状债元素级标注);后端=现 ×8(若干设计缝与桩元素级标注);前端=现 ×8 + 建 ×1(tier2 承载);运营=11 图整体「现」(元素级 mock / 待建 / 待律所诚实区分);运维=现 ×6 + 接 ×2(观测) + 缓 ×1(k3s)。

---

---

第一篇 · 系统总览(9 张系统级图)

下面九张图是这份主档的核心。它们都是跨域才画得出、没有任何单个领域拥有的系统级图。按「先看全局形状、再看三档生成与引擎选型、再看数据与钱与可靠性与边界、最后把全链串起来并钉清系统边界」的顺序读下来,就能自顶向下建立对整个系统的认知。

本篇内联的图 1–6 与图 8–9 是顶层 docs/architecture/assets/ 下的系统级 SVG(路径保持 assets/xxx.svg);图 7 是 Mermaid,直接内联。

图 1 · 六域生命周期全景〔SVG·架·现〕

这张图回答最顶层的问题:绘境AI 是个什么系统,它的六个领域如何串成一条主线。设计文档按产品生命周期的六个领域组织——产品(用户要给谁、给什么)、架构(用什么技术、怎么搭)、后端与前端(并列的实现层,同受架构约束)、运营(合规上线、变现、发行)、运维(部署、健康、可用性)。这六域不是六个互不相干的孤岛,而是一条接力链:产品定义出「做什么」,架构据此定「怎么搭」,前后端把它实现出来,运营让它合规变现,运维让它持续跑得住。

读这张图要抓住三件事。其一,它是一条闭环、不是六个孤岛——判断「系统有没有缝」,就是看相邻两域的交接处对不对得上;一个具体的例子是后端定义的五条业务链(创作 / 发布 / 试玩 / 广告收益 / 数据回路)恰好就是运维冒烟门按链分组点检的那五条,两域在这个接口上必须严丝合缝。其二,它不是瀑布,是带回流的循环——图上方那条贯穿全宽的大虚线,是玩家行为加收益数据回流、反哺产品优先级与生成质量的飞轮;正是这条回流把一条线性的价值链弯成了一个循环,也正是数据与网络效应护城河的来源(它的机制细节在图 4 展开)。其三,单源纪律——本图只画「六域如何串成一条生命周期」,六域各自内部的图都在各自的篇章里,本系统图绝不重画任何一张领域已有的图。看完这张图,你就知道了整个系统的骨架和「每一块在哪」;接下来六张图把这条骨架的关键段一段段放大。

图 2 · 六层技术分层总图〔SVG·架·现 + F〕

这张图回答「这套系统在技术上怎么搭起来、分几层」——是系统级的权威分层视图。一个用户从浏览器进来,自上而下穿过六层:接入层(CDN / Nginx)→ 前端应用(studio + admin)→ 网关层(Spring Cloud Gateway,MVP 下软转发)→ 业务服务层(13 个游戏业务模块,jar 聚合进 Huijing 单体)→ 基础设施层(Huijing 原生的 system / infra / bpm,开箱即用)与并列的 AI 生成层(agent 编排统一收敛 AgentScope、SAA 降最低优先级 → new-api → 便宜 LLM → 九门,配 LittleJS / Phaser 引擎)→ 最底的中间件层(MySQL / Redis / MinIO);整套之外,一条旁路可观测层横向监控。

这张图最该让人抓住的,是它那条贯穿始终的设计取向:先简后扩、能复用就不自研。后端复用 Huijing 现成的 60% 后台能力、生成不自研大模型而接通用模型、引擎不自研而用成熟的 LittleJS——正是这条取向让系统能用很小的团队和很低的成本跑起来。同时有两处状态边界必须按标注读:其一,中间件层的 Nacos / RocketMQ / Sentinel 已于 2026-07-01 反转为 MVP 生产基建(自托管 mini-infra,接入实现进行中;SVG 若仍画虚线「future」,以本文与域树为准),所以「异步 MQ」「服务注册发现」「准入流控」按已采纳的 Nacos / RocketMQ / Sentinel 理解,不再按 MVP 阶段「进程内调用 / 本地配置」折算;其二,整条旁路可观测层整体是「接」(待接线)——唯一已就位的实心块是 SAA 节点 observation,其余 OTel 采集、Prometheus、Grafana、夜莺、admin 观测入口全部待接,落地全貌见运维图 6。这张图给的是空间感:看「某块技术落在哪一层、它现行还是 future」用它;看某一层内部的细节(13 模块怎么聚类、生成层怎么编排)去对应领域篇章。

图 3 · 三档生成(按 AI 深度统一框架)与引擎选型〔SVG·架·现 + 建〕

这张图是看清「生成引擎怎么组织」的总闸。绘境AI 把生成收敛到 AgentScope 一套框架,按 AI 参与深度分 Tier0/1/2 三档——不是「SAA 现行 ‖ tier2 远期」那种按基建分裂的两轨。三档全高度模板化(玩法模板 + 工程骨架,不是从零生成),区别在 AI 介入多深:浅介入档照模板填,深介入档让 agent 自治造多系统富交互。引擎是按复杂度选的实现变体、不是分档轴:轻-中复杂度用 LittleJS,最高复杂度用 Phaser(纯代码全无头可构建,适配 agent 自治 loop)。生成产物的终态统一是 src/ 多文件源项目——gameDefinition 已废(判错误路线),现行直接由 A-model 写真 src/,既无 factory/gamedef 双轨、也无 cutover 切换。SAA / Dify / Coze 在这套框架里降到最低优先级,留作「远期适配验证可插拔」的目标,不是现行主轴。各档只经公共件交汇:计费平面、送审 + feed、验收基线 + 执行沙箱、控制 / 管理面治理层。

读这张图有三层意思必须读到。其一,tier2 富游戏档的状态要说准:它走 AgentScope(Python)的自治 ReAct agent、用 Phaser 全无头引擎、靠三层校验当确定性地板加人工终审兜底,产物是 Phaser 的 src/ 源工程;0 号 spike 已过 accept、核心代码已落,验证走 n=5 收敛环(并发跑 5、有错追加 5、收敛即 go),产品化排期待定——它不是「远期待 spike、尚未落代码」。其二,三档共用一套框架而非两套正交范式:统一在 AgentScope 下按 AI 深度调档,避免「声明式有向图 ‖ 命令式循环」硬塞成项目明令反对的「缝合设计」。其三,per-gen 预算硬闸:便宜档每次生成 < ¥10、复杂档 < ¥50(图、音另算),这条成本闸是三档共守的硬边界。生成引擎的深度(运行时架构、加节点法、救场阶梯、引擎运行时、tier2 详设)在生成引擎子树,运行时单一真相 SoT 见 生成引擎/agentic运行时架构图说.md,本图只画三档与引擎选型的硬边界。

图 4 · 跨域数据流(越用越聪明)〔SVG·流·现〕

这张图把图 1 那条「回流大虚线」放大,回答「平台靠什么越用越聪明」。它是一条数据飞轮回路:玩家在 feed 玩、互动(①)→ 游戏内 SDK 埋点上报(②)→ telemetry 入库聚合(③,逐事件 uk_event_id 幂等防重)→ 算出 0–100 的质量分(④)→ 进推荐打分公式与 Redis 候选集(⑤)→ feed 重排下发(⑥)→ 回到①,玩家刷到更好的游戏。这条回路转一圈,好游戏自然浮上来、差游戏沉下去,数据回流持续校准推荐。

这张图最该让人看清的有三点。其一,error_rate 是唯一的「硬」降权——技术上跑不动的游戏直接沉底,这条把「好不好玩」之前先卡住「能不能玩」,是可玩性底线。其二,这条回路就是护城河第一层——它是数据壁垒加网络效应的产品载体:真实流量积累出来的质量信号无法购买,飞轮转起后追赶成本指数级增长;竞品做生成工具止步于出包,没有这条回流就不「越用越聪明」。其三,有两处现状要诚实标:候选集当前可直查 MySQL、Redis 是增长期形态,游标分页目前是桩(永远返回第一页)——公式和飞轮是设计真相,落地仍是增长期的事;而飞轮的第二半(收益 / 留存数据回流成训练语料、反哺生成质量)是远期·待建,现行只覆盖了生成侧自增强这一半,图上用虚线把它和现行回路分开。这张图与图 1 是一对:图 1 点出「有这么一条回流」,图 4 把回流的每一站和它的现状画清。

图 5 · 失败 / 降级 / 补偿路径全景〔SVG·流·现〕

这张图是据图做评审最容易发现「缝」的一张。它横切三类不可控调用——外部模型(链路 A)、异步任务 / 跨表(链路 B)、支付 / 打款(链路 C)——把「超时 → 失败 → 重试 → 幂等 → 补偿 → 兜底」这条可靠性主线集中画出来。链路 A 给生成调便宜 LLM 的全路径:超时 120s、状态机显式建 FAILED / TIMED_OUT 边、重试加 repair→escalate 救场阶梯、idempotency_key 去重、giveup 留证据,并标出 2026-06 已真实发生的「二厂系通道全废 → new-api 多通道兜底」。链路 B 给异步与跨表:最终一致 + 补偿(非分布式事务)、唯一一处真原子发布(project 把合规裁决 + 出包 + 入流串成事务)、补偿 job 兜底、幂等四范式。链路 C 给钱的事:账户恒等式永远成立、「发起 ≠ 终态」、双路驱动 + CAS、对账锚点链。

这张图最该让人记住的,是底部那条关键反差:打款的降级口径与生成 / 广告正好相反——广告渠道缺失降级 mock 可接受(少算收入),但打款渠道缺失若降级 mock 就是吞真钱,必须 fail-fast、绝不发假钱;审核降级则一律朝保守(阿里云超时降到 review、绝不降到 pass)。图底那张「据图 review 的六条检查清单」是这张系统级图存在的意义:每个外部 / 异步 / 资金动作是否都有幂等键、失败是否在状态机里显式建边、补偿 job 是否扫得到、降级方向对不对、抽象是否做对(mock ↔ 真实现可零改业务码切换)、对账锚点链是否端到端串得起来——凡有一格答不上,就是一处可靠性裂缝,据图就能定位,不必逐文件翻。图上也诚实标了打款 mock 桩、订阅自助购买被支付闸门阻塞这些现状缺口。

图 6 · 端到端鉴权信任边界总图〔SVG·架·现〕

这张图回答「权限在系统的哪一层、挡什么」,是系统级的信任边界视图。一个请求从前端经网关到业务,三层各管一段:① 前端的路由守卫只改善体验(anon_id 让 Feed / Play / Share 匿名可达、即刷即玩不挡门),但它挡不住直连 API——前端守卫形同虚设,任何「前端藏了按钮就安全」的想法都击穿信任;② 网关在 MVP 单体下只做软转发(剥除外部伪造的 login-user 头、有 token 才注入可信头、无 token 也放行),它本身没有路径级 RBAC,所谓「网关双重校验」是微服务拆分后的未来态;③ 业务服务 huijing-server 是权限的唯一真强制点——TokenAuthenticationFilter 校验 token 的 userType 与 URL 前缀一致,然后 B 端走声明式 RBAC(@PreAuthorize + 角色菜单交集)、C 端走 Service 归属隔离(eq 谓词把当前用户钉进 WHERE),再叠一层创作白名单(A2 内测准入)和匿名读三纪律。

这张图与后端图 7 是互补、不重复的:后端图 7 是模块类图(讲两套权限模型在代码里的类与方法),本图是系统边界(讲前端→网关→业务三层各挡什么、职责怎么切分)。它最该让人看清的,是那条贯穿全图的铁律——权限只在后端可信边界强制,前端拦截一律不算数;以及职责切分的本质:网关做「身份可信化」(把不可信外部头换成可信内部头),但绝不替代服务侧的权限判定,两者是接力、不是冗余。anon_id 让玩家免登消费,但创作 / 写域必须越过后端这道墙。图上还诚实标了一处现状:控制器注释里「网关 + 服务端双重校验」是未来态,当前单体下网关甚至不在请求路径上,权限强制 100% 在服务侧单点;mock 后门是 staging 现状、生产必须关死的红线。

图 7 · 角色 × 端全景〔Mermaid·讲·现〕

这张图回答「谁在哪个端做什么」。绘境AI 把「用户」收敛成六种角色,分布在两个前端(C 端 studio / B 端 admin)上;最容易混的一对是「经营」和「运营」——经营 = 创作者看自己作品的数据(留存 / 完玩 / 广告转化),运营 = 平台管理员(审核 / 精选 / 封禁 / 经营看板),两者在需求清单里分属不同的域(OPS vs OPN),混了就会把功能归错端。

flowchart TB
  subgraph C端["C 端 · game-studio(Vue3 + Vant)"]
    direction LR
    CR["创作者<br/>一句话生成 / 预览迭代<br/>发布 / 看收益(经营)"]:::role
    PL["玩家<br/>刷 feed 即点即玩<br/>点赞分享 / 发起同款"]:::role
    CB["B 端客户(询单侧)<br/>提需求 / 看 demo / 验收"]:::roleb
  end
  subgraph B端["B 端 · game-admin(Vue3 + Element Plus)"]
    direction LR
    OPN["运营(平台管理员)<br/>内容审核 / 精选推荐<br/>封禁处置 / 经营看板"]:::roled
    ADM["管理员<br/>用户管理 / 权限角色<br/>合规处置 / 数据看板"]:::roled
    BD["商务 / BD<br/>B 端定制单据流转<br/>报价 / 进度 / 交付"]:::roled
  end
  COM["通用(任意端可触)<br/>账号 / 登录 / 消息通知 / 政策页 / 申诉"]:::common

  CR -->|产出可玩游戏| PL
  PL -.->|发起同款 → 变创作者(P-FED-12)| CR
  CB -.->|线索 → 单据| BD
  OPN -.->|审核 / 降权联动| PL
  ADM -.->|白名单置位 set-creator| CR
  C端 --- COM
  B端 --- COM

  classDef role fill:#eff6ff,stroke:#2563eb,stroke-width:2px;
  classDef roleb fill:#f5f3ff,stroke:#7c3aed,stroke-width:1.6px;
  classDef roled fill:#fefce8,stroke:#ca8a04,stroke-width:2px;
  classDef common fill:#f1f5f9,stroke:#475569,stroke-width:1.6px;

这张图最该让人看出的,是两条跨角色的转化回路:一条是玩家「发起同款」跳转工作坊变成创作者(P-FED-12)——它把「玩游戏的人」转化成「做游戏的人」,是网络效应护城河的产品载体;另一条是 B 端客户的询单经商务 / BD 流转成定制单据。还有一处系统级衔接:运营对内容的审核 / 降权处置会联动 feed 曝光(影响玩家看到什么),管理员对创作者的白名单置位(set-creator)决定一个 C 端用户能不能创作——这两条「B 端动作影响 C 端体验」的链路,正是图 6 那条「权限在后端强制」与图 4 那条「feed 重排」的人侧投影。这张图没有现行 / 远期的灰度,它是当前的角色与端的真相;每个角色的完整旅程(创作者旅程、玩家旅程)在产品篇,每个端的视图地图在前端篇。

图 8 · 端到端跨域全链泳道〔SVG·流·现 + F〕

这张图是整本图集里最该第一个读的一张:它把前面那些分门别类的领域图,拼成了一条从「创作者敲下一句话」一直跑到「数据回流让 feed 重排」的完整系统链。它用八条横向泳道——创作者、game-studio、aigc + SAA、compliance、project + feed、玩家、telemetry、ad + trade——各占一条道,让你能顺着一个编号(①到⑮,外加钱流的 Ⓐ 到 Ⓓ)从头走到尾,看清每一步落在哪个域、交给谁、产出什么。主链是这样跑的:创作者一句话(①)经 studio 提交(②),aigc 建任务(③)进入 SAA 十六节点编排(④),九门验收通过后 emit 出包(⑤)回写成 project 草稿(⑥);创作者提交发布(⑦)触发 compliance 锁风门裁决(⑧),只有 pass 才让游戏 PUBLISHED 入 feed(⑨);玩家在竖屏游戏流里刷到(⑩)、即点即玩并互动(⑪);这些行为经埋点上报进 telemetry 聚合(⑬)、算出 0–100 的质量分(⑭),再把 feed 重新排序(⑮),把更好的游戏推回到玩家眼前——这条绿色的回流箭头,正是把一条线性的价值链弯成飞轮的地方。下半部还叠了一条与主链并联的钱流:玩家试玩时触发游戏内广告曝光(Ⓐ),经 ad 模块计费落账(Ⓑ),由 trade 按 source_ref 对账分账(Ⓒ),最终结进创作者钱包(Ⓓ)。（2026-07-09 勘误：主链里「九门验收通过后 emit 出包」这一环，九门自此降为「未见明显死」的机械预筛地板，出包放行还须叠加独立模型对真玩证据的玩法判定，详见质量 SoT《游戏质量与爆火能力》裁定三。）

新人能从这张图看出几件单看任何一张领域图都看不全的事。其一,判断「系统有没有缝」,就是看相邻泳道的交接处对不对得上——出包能不能落成草稿、草稿能不能提审、裁决能不能控制入流、互动能不能回流成排序,任何一处接不上,闭环就断了;这张图把所有交接点都画在了一条线上,据图就能逐个核对。其二,合规门是整条链的上线总闸:图上那条红线写着「pass 才入流」,游戏造得再好,过不了锁风门也进不了 feed,这是平台不碰红线的硬约束。其三,现状必须诚实地读,不能因为画出来了就当全是实的:图里用橙色虚线小标点出了两处现状桩——feed 的游标分页现在恒返第一页、Redis 候选集还是增长期形态,广告侧的 provider 还是 mock、真广告 SDK 要等渠道落地才接;提现打款那一格更标了红线,缺渠道时必须 fail-fast、绝不发假钱。其四,右上角那个虚线框是 tier2 富游戏档——它走的是 AgentScope 自治加 Phaser 无头的更深 AI 介入档,0 号 spike 已过 accept、核心代码已落(验证走 n=5 收敛环),产品化排期待定;它不在这条现行链上跑同一条装载路,换的只是「游戏内容怎么造出来」,造出来之后仍旧汇进同一条上线与发行的公共件。把这些边界一眼标清,正是为了让据图做评审的人,既能顺着主链确认闭环跑得通,又不会把桩误当成已经建好的现行。

图 9 · 系统上下文与外部依赖边界〔SVG·架·现 + 接〕

这张图回答一个新人最先想问、却常常没有一张图能直接回答的问题:绘境AI 这个系统,边界到底画到哪里、它对外又依赖谁。它用 C4 模型最外层的「系统上下文」视角来画——正中间一个大框是绘境AI 平台本身(内网单体:game-studio 产品前端、game-admin 管理后台、game-cloud 后端十三模块,以及它自建的 MySQL / Redis),左边是站在系统边界之外、会来使用它的四类外部用户(创作者、玩家、运营 / 管理员、B 端 / IP 客户),右边则是平台要去调用、同样在边界之外的外部依赖系统。这张图刻意不画系统内部的模块怎么拆、调用怎么串(那些在架构图和泳道图里),它只回答「边界」这一件事,所以一眼就能让人建立「哪些东西是我们自己的、哪些是外面的」这个最基础的方位感。

这张图真正的价值,在于它给每一个外部依赖都标了接入度三态,而不是把它们一律画成「已经连上了」。现行真正已经联通在调用的(绿色实线框、标「已接」)只有两类:一是生成与素材这条供给线——new-api 网关后面的便宜大模型(DeepSeek / MiniMax)和 mmx-cli 的素材生成,它们是护城河运转的燃料,已经在 mini-infra 上接通;二是代码与存储的底座——Aliyun Gitea 代码仓和 MinIO 对象存储。而变现侧的几条线——广告联盟(穿山甲 CSJ / 优量汇 GDT)、微信 / 抖音小游戏渠道、支付商户、短信服务——全部是「待接」或「远期」,用橙色或紫色虚线框画出,绝不能误读成已经接好。新人看到这里应该立刻反应过来:这恰恰是运营域那条「合规闸门是总闸」的判断,投影到依赖边界上的样子——所有能把钱赚回来的外部线,都卡在 ICP 备案、广告资质、渠道备案锁、短信签名报备这些日历驱动的闸门后面,一秒也压不动,所以它们现在只能是桩或 mock。最后一层意思藏在边界的切法里:平台把那些「耗时但不构成差异化」的能力——后台框架、大模型、引擎、素材生成——统统用外部现成件顶上,系统边界内只留真正的护城河(生成编排、流量分发、收益闭环、数据飞轮);而且出网一律只走受控网关、上游 key 不裸暴露、游戏侧 CSP 直接禁网,这等于把「系统边界」同时当成一道「安全边界」来守。看懂这张图,你就同时知道了这个系统「大在哪、靠谁、又把哪几道门关在了外面」。

第一篇状态分布:现 ×5、现 + F ×3、现 + 接 ×1(图 2 含 future-state 中间件与「接」可观测、图 3 含 tier2 档与引擎选型、图 8 含桩与 tier2 档、图 9 外部依赖三态)。系统级图与领域图互补不重复:本 9 图都是跨域才画得出、无单域拥有的图。三档统一框架 / 待建 / 已废标注:生成收敛 AgentScope 一套框架,按 AI 参与深度分 Tier0/1/2 三档(全高度模板化)、引擎按复杂度选 LittleJS/Phaser(图 3),SAA/Dify/Coze 降最低优先级、留作远期适配验证可插拔目标;tier2 富游戏档(图 3 / 图 8,= AgentScope+Phaser)= 0 号 spike 已 accept、核心已落、验证走 n=5 收敛环、产品化排期待定;per-gen 预算硬闸 = 便宜档 <¥10 / 复杂档 <¥50(图音另算);Nacos/RocketMQ/Sentinel(图 2)= 已于 2026-07-01 反转为 MVP 生产 runtime(SVG 待刷新);观测(图 2)= 接;收益回流语料(图 4)= 远期·待建;打款 mock(图 5 / 图 8 / 图 9)= 现状桩(缺渠道须 fail-fast);网关双校验(图 6)= 未来态;feed 游标分页 / 真广告 SDK(图 8)= 现状桩;广告联盟 / 微信抖音渠道 / 支付商户 / 短信(图 9 外部依赖)= 待接或远期(被 ICP / 资质 / 备案锁 / 短信报备等日历闸门阻塞)、阿里云 OSS 生产 = 远期(MinIO 内网已接);Dify/OpenGame/gameDefinition/玩法填参模板/15KB = 已废;生成产物终态 = src/ 多文件源项目(A-model 写真 src/);均不画成现行终态。

---

---

末尾 · 按角色读:推荐下钻路径

读完第一篇系统定向图、再按你的角色选某一两个领域篇章下钻,是最省时的读法。下面给四类角色各推荐一条 2–3 个篇章的路径(因各域图说已并入本文,下面的链接都是本文内部锚点)。

• 产品 / 运营 / 投资人:先读第一篇 图 1(六域生命周期)+ 图 4(数据飞轮)+ 图 7(角色×端),建立「这是个什么系统、靠什么越用越聪明」的轮廓;再下钻 第二篇产品域(产品定义与护城河)→ 第七篇运营域(合规上线 / 变现 / 发行,尤其图 9 备案锁、图 10 钱流、图 11 审核台)。命门:护城河「不假装有墙」、变现被日历闸门阻塞的部分别当已建。

• 工程师(新加入):先读第一篇 图 2(六层分层)+ 图 3(三档生成与引擎选型)+ 图 6(鉴权边界);再下钻 第三篇架构域(尤其图 11 契约现状)→ 你负责的模块在 第五篇后端域(图 5 ER + 图 6 五条业务链)→ 若做生成主线直接进 生成引擎子树。命门:契约 DB 镜像漂移、网关双校验是未来态、桩与真要分清。

• 前端工程师:先读第一篇 图 6(鉴权信任边界,前端那一层挡不住直连)+ 图 7(角色×端);再下钻 第六篇前端域(图 2 token 两层 + 组件库四层、图 8 真实试玩宿主)→ 跨到 第四篇产物执行沙箱(图 8 宿主侧的安全隔离纵深)。命门:试玩宿主「机制建成 ≠ 合规收口」、同源过渡态三债一起收。

• 安全 / 可靠性评审:先读第一篇 图 5(失败 / 降级 / 补偿全景,据图 review 六条检查清单)+ 图 6(鉴权信任边界);再下钻 第四篇产物执行沙箱(三层封堵 + 两条正交边界)→ 第五篇后端域图 7(鉴权双模型)→ 第七篇运营域图 10(打款 fail-fast)。命门:降级方向(可降 mock vs 必须 fail-fast)、权限只在后端可信边界强制、同源红线过渡态。

第九篇 · 生成引擎子树(另一 session 在飞、只链不并)

生成引擎是绘境AI 护城河的关键路径,内容最厚、单独成一棵子树。它回答「一句话怎么变成一款可上线的游戏」这条技术主线:被刻意设计成可靠的生成机器(模板化引导 + 确定性控制流约束 + 九门 harness 兜底),以及贯穿全程的范式原则(游戏是长生命周期源项目、LLM 是它的工作室)。本主档第一篇图 3 已给出「三档生成与引擎选型」的总闸轮廓,这棵子树是它的深度展开。

读这棵子树最该带着一条定性:生成收敛到 AgentScope 一套框架,按 AI 参与深度分 Tier0/1/2 三档,三档全高度模板化(玩法模板 + 工程骨架);引擎按复杂度选(轻-中档 LittleJS、最高档 Phaser),不是分档轴。生成产物的终态统一是 src/ 多文件源项目——A-model 写真 src/(gameDefinition 已废、判错误路线),子树内细节以运行时 SoT 生成引擎/agentic运行时架构图说.md 为准。

跨 session 协调红线 + 链接(只链不并):生成引擎子树正被另一条 session 在飞建设,本主档对它只链接、不并入其内部图与散文——三档的逐张图、运行时架构、九门逐门、tier2 详设都在子树内,本文不重复承载。

入口链接 → 架构/生成引擎/README.md

---

全文防漂移门汇总:本文 frontmatter 记了各域设计档(6 域 README + 架构 13模块/契约总览/产物执行沙箱、后端 数据模型/鉴权与权限、运维 观测体系/k8s迁移、生成引擎 README 等)的 commit hash;每图的具体映射源档另见正文该图脚注 / 内联小注。任一源档变更、hash 对不上,本文与对应图即标「待复核」,由收口脚本比对。SVG 不动:本文不动任何 SVG 文件,只经顶层相对路径引用它们;PNG 后续在 mini-desktop 批量转(6c6g 禁 chrome),Mermaid 图 GitHub 直接渲染、无需转换。