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

date, topic, status

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

00 · 系统总览图说

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

---

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

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

---

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

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

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

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

现行 vs 远期 / 已废,严格标注。 全文凡涉及未来式或被推翻的方案,一律用虚线框 + 文字小标画出,与「现行已建」的实心块一眼区分。几类边界必须看清:tier2 富游戏自治轨(= AgentScope + Phaser——核心已落、0 号 spike 已过 accept,n=1 机制验证、n≥30 统计待跑,图上仍按 spike 前视角画成虚线,现状以生成引擎子树的运行时架构 SoT 为准)、future-state(Nacos / RocketMQ 框架自带但 MVP 未部署、k3s 缓做、观测体系待接线、两条生成线远期可能收敛为一条)、已废(Dify / OpenGame 从未部署降远期、玩法填参式模板与 15KB 红线已废除)、终态迁移中(廉价线产物的终态定为 src/ 源项目,现行的声明式 gameDefinition JSON 只是通往它的中间脚手架、正迁移成直接生成 src/)。把这些诚实画出,正是为了让据图 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 生成层(SAA 编排 → new-api → 便宜 LLM → 九门,配 LittleJS 引擎)→ 最底的中间件层(MySQL / Redis / MinIO);整套之外,一条旁路可观测层横向监控。

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

图 3 · 现行 SAA 廉价线 ‖ 远期 tier2 自治轨 边界〔SVG·架·现 + F〕

这张图是看清「生成引擎现行 vs 远期」的总闸,也是本主档最该守状态纪律的一张。绘境AI 有两条生成轨:左轨是现行的 SAA 廉价线——已实测合入主干,承载超休闲档(打砖块 / 合成 / 挂机 / 答题 / 网格点选),一条流水线从「创作者一句话」经 SAA 裸图编排(Java·16 节点)、new-api 网关、便宜 LLM、harness 九门兜底,到 emit 出包,用 LittleJS 当引擎、产物是一份可维护的 src/ 源项目;右轨是 tier2 富游戏自治轨——核心已落、0 号 spike 已过 accept(n=1 机制验证,n≥30 统计待跑),承载 premium 富游戏(经营 / 合成 / 多系统富交互),走的是与左轨正交的另一套范式:AgentScope(Python)的自治 ReAct agent、作为一个独立 service 跑、用 Phaser / Pixi 全无头引擎、靠三层校验当确定性地板加人工终审兜底,产物是 Phaser 的 src/ 源工程。两轨只经公共件交汇:计费平面、送审 + feed、验收基线 + 执行沙箱、控制 / 管理面治理层。两轨远期有可能收敛为一条——把左轨的 SAA + LittleJS 也并入 AgentScope 自治范式(登记为未来方向,当前不做)。

读这张图,最要紧的是把左轨的实心和右轨的紫色虚线分清:左轨是「现行已建」;右轨那道紫色虚线是 spike 前视角的画法,而 tier2 的现状是核心已落、0 号 spike 已过 accept(n=1 机制验证,n≥30 统计待跑),状态以 SoT① 生成引擎/agentic运行时架构图说.md 为准。还有三层意思必须读到。其一,左轨的现行真实状态要诚实说清:骨架立住、控制流确定、九门很硬已合入主干,但生成质量尚未稳定到 80% 门(便宜模型天花板,实测约 60%)、一部分策略被焊进机制代码;范式侧的终态产物定为可维护的 src/ 源项目(改源不改包),这一点由廉价线现行路径直接兑现:gameDefinition 已废(判错误路线),廉价线现行 = A-model 写真 src/(LittleJS,经 esbuild 构建成 engineBundle);默认产线已是 A-model 单线,既无「迁移中」也无「cutover 切换」,质量做到 80% 仍交 W-G1。其二,为什么两轨不合并:左轨声明式有向图与右轨命令式循环是两种正交范式,硬塞就成项目明令反对的「缝合设计」,而且对卡 80% 门,图的确定性本就比口头督促更稳。其三,它们的唯一交汇面是公共件——tier2 换的是「游戏内容怎么造出来」,换不掉「造出来之后怎么被关进笼子跑、怎么计费、怎么送审发行」。生成引擎的深度(SAA 16 节点拓扑、加节点法、救场阶梯、引擎运行时、tier2 详设)在生成引擎子树,本图只画两轨硬边界。

图 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 对账分账(Ⓒ),最终结进创作者钱包(Ⓓ)。

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

图 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 图都是跨域才画得出、无单域拥有的图。远期/已废标注:tier2 轨(图 3 / 图 8,= AgentScope+Phaser)= 核心已落 + 0 号 spike accept(n=1;n≥30 统计待跑),图为 spike 前视角的虚线、现状以 SoT① 为准、远期可能与左轨收敛为一条;Nacos/RocketMQ(图 2)= future-state 未部署;观测(图 2)= 接;收益回流语料(图 4)= 远期·待建;打款 mock(图 5 / 图 8 / 图 9)= 现状桩(缺渠道须 fail-fast);网关双校验(图 6)= 未来态;feed 游标分页 / 真广告 SDK(图 8)= 现状桩;广告联盟 / 微信抖音渠道 / 支付商户 / 短信(图 9 外部依赖)= 待接或远期(被 ICP / 资质 / 备案锁 / 短信报备等日历闸门阻塞)、阿里云 OSS 生产 = 远期(MinIO 内网已接);Dify/OpenGame/玩法填参模板/15KB = 已废;gameDefinition JSON 数据壳 = 中间脚手架·正迁移成直接生成 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 已给出「两条生成轨现行 vs 远期」的总闸轮廓,这棵子树是它的深度展开。

读这棵子树最该带着一条范式定性:这套「便宜模型 + 受限 schema + 九门验收」是一条为超休闲轻游戏(Tier0)量身打造的可靠产线,而不是一个通用生成范式;它最大的风险不在工程层,而在被当成通用范式去对标 demo 里那一档富交互游戏(那一档结构性地够不着,必须显式分层、复杂品类另开一轨)。廉价线现行已是 A-model 写真 src/ 源项目(gameDefinition 已废、判错误路线),子树内细节以最新裁定为准。

跨 session 协调红线 + 链接(只链不并):生成引擎子树正被另一条 session 在飞建设,本主档对它只链接、不并入其内部图与散文——它的两簇(现行 SAA 廉价线 / 远期 tier2 自治轨)的逐张图、SAA 16 节点拓扑、九门逐门、tier2 详设都在子树内,本文不重复承载。

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

---

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