From c197abc4209de10d78811f49d8c85bde8787af18 Mon Sep 17 00:00:00 2001 From: lili Date: Wed, 1 Jul 2026 09:03:12 -0700 Subject: [PATCH] =?UTF-8?q?docs(architecture):=20=E6=96=B0=E5=A2=9E?= =?UTF-8?q?=E6=80=BB=E6=9E=B6=E6=9E=84=E5=9B=BE=E8=AF=B4=C2=B7=E5=88=9B?= =?UTF-8?q?=E5=A7=8B=E4=BA=BA=E5=AF=B9=E5=A4=96=E6=BC=94=E7=A4=BA=E7=89=88?= =?UTF-8?q?(13=20=E5=BC=A0=E5=86=85=E7=BD=AE=20SVG)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 面向技术尽调/技术顾问的单文档对外演示:开篇全闭环价值锚点,三大部分(整体技术架构 / 功能模块 / 游戏生成),收尾护城河四层。诚实技术口径、自研 vs 不自研边界、采主流标准(A2A/MCP/OTel),非程序员散文 + 13 张内置 SVG(商业信息图风格,已逐张渲染验证)。README §3 加对外版指针。 Co-Authored-By: Claude Opus 4.8 (1M context) --- docs/architecture/README.md | 1 + .../绘境AI-总架构图说-对外演示版.md | 1010 +++++++++++++++++ 2 files changed, 1011 insertions(+) create mode 100644 docs/architecture/绘境AI-总架构图说-对外演示版.md diff --git a/docs/architecture/README.md b/docs/architecture/README.md index 83273198..3d027080 100644 --- a/docs/architecture/README.md +++ b/docs/architecture/README.md @@ -61,6 +61,7 @@ flowchart LR ## 3. 怎么按角色读 +- **对外演示 / 技术尽调(创始人对外版)**:[绘境AI-总架构图说-对外演示版](绘境AI-总架构图说-对外演示版.md)——三大块(整体技术架构 / 功能模块 / 游戏生成)+ 内置 SVG、非程序员散文,单文档对外讲解用;它是**对外叙事视图**(内容事实源仍以本策展层为准,非 canonical)。 - **产品 / 运营 / 投资人**:[产品域](产品/README.md) → [运营域](运营/README.md)。 - **工程师(新加入)**:[架构域](架构/README.md) → 你负责的模块([13 模块](架构/13模块.md))→ 相关子树。 - **做生成主线的**:直接进[生成引擎子树](架构/生成引擎/README.md)。 diff --git a/docs/architecture/绘境AI-总架构图说-对外演示版.md b/docs/architecture/绘境AI-总架构图说-对外演示版.md new file mode 100644 index 00000000..c905339c --- /dev/null +++ b/docs/architecture/绘境AI-总架构图说-对外演示版.md @@ -0,0 +1,1010 @@ +--- +date: 2026-07-01 +topic: 总架构图说 · 创始人对外演示版 +status: 对外演示视图(技术尽调向)· 内容事实源以 docs/architecture/ 策展层为准 · 非 canonical +audience: 技术顾问 / 技术尽调 / 懂技术的外部决策者 +--- + +# 绘境AI · 总架构图说(对外演示版) + +> 绘境AI 是一个 AI 驱动的游戏创作与变现平台:让零基础的人用一句话做出一款能上线、能赚钱的轻量小游戏,让玩家像刷短视频一样发现并即点即玩,让平台从广告、订阅、B 端定制三条线拿到收入。 +> +> 这份文档面向懂技术的外部人,用三条线讲清楚这套系统:**整体技术架构**(它怎么搭起来)、**功能模块**(它由哪些部分组成、怎么协作)、**游戏生成**(一句话到底怎么变成一款游戏)。全程只讲设计与能力,不堆代码。 + +--- + +## 一件事没人做完:把"做得出"接到"赚到钱" + +这两年"AI 做游戏"的工具冒出来很多,但绝大多数停在同一个地方——**能生成,却止步于生成**。一个创作者用它做出一款游戏,然后呢?没有人来玩,也没有地方赚钱,这款游戏就死在硬盘里。 + +绘境AI 的判断是:**"做得出"只是入场券,真正难、也真正值钱的,是把"做得出 → 有人玩 → 赚到钱"接成一条完整的闭环。** 生成、分发、变现这三件事,单独拿出来每一件都有人在做;把它们接成一条自我加强的回路,是这个平台真正要解决的问题。 + + + + + + + + + + + + + + + + + + + + 玩家行为 + 收益数据回流 · 越用越聪明 + + + + + 做得出 + 一句话 → 一款可上线的游戏 + AI 游戏生成 + + + + 有人玩 + 短视频式游戏流,即点即玩 + 流量分发 + + + + 赚到钱 + 广告 / 订阅 / B 端定制 + 变现闭环 + + + + + + + + + + 竞品大多止步于第一格;绘境AI 把三格接成一条自我加强的回路—— + 这条回路本身,才是壁垒的地基。 + + +这条回路一旦转起来,好游戏会因为真实玩家的反馈自动浮上来、差游戏沉下去,平台越用越懂什么好玩、什么能赚钱。它带来一个诚实的结论,也是理解后面所有技术选择的前提:**生成能力本身不是护城河——通用大模型迟早会把它追平。真正的护城河是这条回路里沉淀下来的东西:真实流量喂出来的数据、搬不走的创作者生态、时间堆出来的资产与合规资质。** 技术架构的每一处取舍,都是围绕"用最小的代价把这条回路跑通,再把资源集中投到回路里那几样别人抢不走的东西上"来做的。 + +## 一条贯穿全局的技术总原则:能买的绝不自造 + +在看具体架构之前,先记住一条原则,它能解释后面几乎每一个技术选择:**凡是成熟开源或商用组合能解决的,一律不自研;自研只投在两个地方——平台必须自己攥住的控制点,和数据流进来的入口。** + +这不是能力不足的将就,而是窗口期内的资本效率选择。自研一个大模型、一套后台、一个游戏引擎,每一样都是六到十二个月、数百万起步的投入,而且做出来还会被开源生态追平。把这些耗时但不构成差异化的能力用现成件顶上,团队就能把有限的钱和人,全部压在竞品做不了、也搬不走的那几件事上。这条原则落到工程上是一条清晰的边界,后面第一部分会把这条边界画出来。 + +**这份演示接下来分三部分展开:** + +1. **整体技术架构** —— 系统分几层、由哪三个代码库构成、哪些自研哪些外包、安全边界划在哪。 +2. **功能模块** —— 十三个业务模块各管什么、怎么串成一条从创作到收益的完整链路。 +3. **游戏生成** —— 护城河的关键路径:一句话怎么被一台"生成机器"稳定地变成一款真游戏。 + +最后用一小节收回到商业:这套技术到底为哪几层护城河服务。 + +--- + +# 第一部分 · 整体技术架构 + +## 系统分六层:一个请求怎么穿过整套系统 + +一个用户从浏览器点开绘境AI,他的请求自上而下穿过六层。最上面是接入层,CDN 分发游戏包和静态资源、Nginx 做 SSL 终结和前端托管,都是标准件。往下是两个前端应用,创作者和玩家用的 game-studio、运营和管理员用的 game-admin。再往下,请求经过网关进入业务服务层——十三个游戏业务模块聚合成一个单体启动,但它们的边界是按微服务切好的,哪个模块将来需要独立扩容,改一处配置就能拆出去。托住这一切的,是最底下两块能力底座和一层中间件。 + + + + + + 自研掌控 + + 复用现成 + 用户从浏览器进入,请求自上而下穿过六层 + + + + 接入层 + + CDN + 游戏包 / 静态资源分发 + Nginx + SSL 终结 / 前端托管 + + + + 前端应用 + Vue3 + + game-studio + 创作者 + 玩家 · 移动优先 + game-admin + 运营 + 管理员 · 后台 + + + + 网关层 + + Spring Cloud Gateway + 路由 / 鉴权 / 限流 / 灰度 / 跨域 + + + + 业务服务层 + Java + + 13 个游戏业务模块 + 单体启动,边界按微服务切好——改一处配置即可独立拆分扩容 + + + + 能力底座 + + + Huijing 原生底座 · 复用开箱即用 + 用户 / 权限 / OAuth2 登录 + 文件 / 定时任务 / 日志 + 工作流审批 BPM + 通知 / 字典 / 操作审计 + 覆盖 60%+ 通用后台工作量 + + + AI 生成层 · 自研护城河 + AgentScope 自治编排 + new-api 多模型网关 + 便宜大模型直连 + 九门确定性验收 + LittleJS / Phaser 引擎 + 第三部分展开这一层 + + + + 中间件层 + + MySQL 8 · 业务主库　|　Redis 7 · 缓存 / 限流 / 排行　|　MinIO · 阿里云 OSS · 对象存储 + + + + 全链路可观测旁路 · Metrics / Traces / Logs / Errors 横向贯穿各层 + + +这张分层图最该看清的,是那条贯穿始终的取向:**能复用就不自研**。左边这块 Huijing 原生底座,是一个成熟且社区活跃的开源后台框架,用户体系、权限、OAuth2 登录、文件存储、定时任务、工作流审批这些通用能力开箱即用,覆盖了平台六成以上的后台工作量;绘境AI 不重写它,只在它之上扩展游戏领域独有的东西。右边这块 AI 生成层才是自研的重心,它是护城河的关键路径,第三部分会专门拆开讲。这种"底座买现成、力气花在刀刃上"的切法,是这套系统能用很小的团队、很低的成本跑起来的根本原因。 + +分层之外还有一处让技术评审安心的设计:业务服务层的十三个模块虽然现在打包成一个单体一起启动,但它们的边界是按微服务的标准切干净的。起步用单体是为了省下分布式的运维复杂度,而一旦某个模块的压力上来,把它单独拆出去扩容不需要重构,改配置即可。**先用单体简单地跑起来,再按需长成微服务**——这条演进路径从第一天就铺好了。 + +## 三个代码库:一套系统,各管一摊 + +整套系统的代码分在三个库里,各自面向不同的人、用最适合的技术栈: + +| 代码库 | 它是什么 | 面向谁 | 技术栈 | +|---|---|---|---| +| **game-cloud** | 统一后端,所有前端的请求最终都落到它 | 全部前端 | Java 17 + Spring Cloud 生态 + MySQL | +| **game-studio** | 产品前端,创作与消费都在这里 | 创作者 + 玩家 | Vue3 + Vant(移动优先,适配手机屏) | +| **game-admin** | 管理后台,审核推荐与数据看板 | 运营 + 管理员 | Vue3 + Element Plus | + +后端选择 fork 一个成熟框架来做二次开发,并守住一条纪律:**不改框架本身,只通过它预留的扩展点接入**。这样将来框架升级,平台能跟着一起升,不会因为当初改花了底座而永远卡死在某个老版本上——这是"复用现成件"这条路能长期走下去的前提,也是技术尽调时最该确认的一点。 + +## 自研还是外包:一条画得很清楚的边界 + +"能复用就不自研"这条原则,落到具体的技术边界上,是一条清清楚楚的线。哪些东西绘境AI 必须自己写、绝不外包,哪些直接用现成的、连自研的念头都不起——这张图把这条线画了出来。 + + + + + + + + + + + + 自研 · 护城河 + 平台必须攥住的控制点 + 数据入口 + + + + + + 运行时宿主层 + Runner + iframe 沙箱 + SDK 注入 + + + + + 信息流推荐引擎 + 决定流量给谁 + + + + + 遥测数据底座 + 行为数据流进来的入口 + + + + + 变现链路 + 钱包 · 分账 · 广告位 + + + + + 确定性验收门 · 九门 + 机器判定"真的能玩" + + + + + 生成断点续跑 + 自治生成的核心语义 + + + + + 系 + 统 + 边 + 界 + + + + 不自研 · 用现成 + 耗时但不构成差异化 · 可替换无锁定 + + + + + + 大模型 + 通用 LLM · DeepSeek / MiniMax + + + + + 多模型网关 + new-api · 一处切换背后的模型 + + + + + 后台框架 + Huijing · 复用 60%+ 通用后台 + + + + + 素材生成 + mmx-cli · 图片 / 音乐 + + + + + 内容安全 + 阿里云审核 API + + + + + 游戏引擎 + LittleJS / Phaser / Cocos + + + + + agent 框架与标准 + AgentScope + A2A · MCP · OTel + + + + + 总原则:能买的绝不自造 —— 自研只砸在控制点与数据入口,其余全部外包、每一样都可替换、无单点锁定 + + +自研的这一侧,全是两类东西:**平台必须攥在自己手里的控制点,和数据流进来的入口**。变现链路、信息流推荐、遥测底座,决定了钱怎么分、流量给谁、数据往哪流,这些一旦交出去就等于把命脉让人;运行时宿主层和确定性验收门,决定了平台怎么控制游戏运行、怎么验收生成质量;生成断点续跑,是一次自治生成能不能被平台接管的核心语义。这几样别人短期补不上,也正是护城河真正的所在。 + +不自研的这一侧,是另一类东西:**耗时、但不构成差异化的通用能力**。大模型、多模型网关、后台框架、素材生成、内容安全、游戏引擎——每一样都有成熟的开源或商用方案,自己造一遍要烧掉六到十二个月和数百万,做出来还未必比现成的好。对技术尽调更要紧的一点是:这一侧的每一样都可替换,没有单点供应商锁定。大模型可以换一家,网关背后接的模型能随时切,引擎在契约约束下可换实现——绘境AI 没有把身家押在任何一个外部供应商身上。 + +最右下那一项 agent 编排框架值得单独说一句,它是这套系统里最"新"的部分。绘境AI 没有自己发明一套 agent 框架,而是采用 2025 年业界已经收敛的一批开放标准来搭它:任务与状态用 A2A、工具调用用 MCP、全链路追踪用 OpenTelemetry。这意味着连底层的 agent 框架本身都是可替换的——今天主力用 AgentScope,明天想接别的框架,只要它会说这几种标准协议就能插进来。**采标准而不是闭门造车,既省了自研的力气,也避免把自己锁死在一套私有框架里。** 对于一个刻意"不自研"的团队,这恰恰是最经得起技术尽调追问的地方:它证明这里的每一处"不自研",都想清楚了退路。 + +## 系统边界的第二重身份:它也是一道安全边界 + +绘境AI 把边界切在哪里,不只决定了自研什么,也决定了防线设在哪里。一款 AI 生成出来的游戏,本质上是一段不完全可信的代码——它可能带 bug,也可能被人塞进恶意内容。所以平台从不假设游戏是安全的,而是用一层层隔离把它关起来。 + + + + + + + 身份可信化 + + 消息双校验 + + + + + + 平台可信区 + 后端 + 受控网关 + 唯一出网口 · 外呼全走网关 + 上游模型 key 只在此 + 不下发前端 + 权限只在后端强制 + 前端拦截一律不作数 + + + + 宿主 · game-studio + 半可信 · 沙箱之外 + 代理后端 API · 游戏不直连 + 广告 / 支付在沙箱外渲染 + 据 manifest 注入 SDK 能力 + + + + 游戏沙箱 · iframe + 不可信代码 · 严格隔离 + iframe sandbox 隔离 + CSP 禁网 · 游戏零网络 + 仅经 postMessage 通信 + 体积门 10MB / 首屏 2MB + + + + 降级铁律:游戏主循环永不被打断 —— 广告 / 支付失败即跳过并兜底,绝不阻塞游戏运行 + + +从右往左读这张图,是一条从"完全不可信"到"完全可信"的梯度。最右边,每一款游戏都跑在一个隔离的 iframe 沙箱里,平台用一条 CSP 规则直接掐断它的网络——游戏碰不到任何外部地址,一个字节都发不出去。玩家要看的广告、要走的支付,全部在沙箱外面由宿主渲染,**游戏本身既碰不到网络、也碰不到钱**。游戏与平台之间只有一条受控的消息通道,来源和格式都要双重校验才放行。 + +再往左,所有对外的模型调用都收在一个受控网关后面,上游模型密钥只存在于这道网关里,永远不下发到前端。而权限——谁能创作、谁能发布、谁能提现——只在后端这道可信边界上强制;前端的任何拦截都只是体验优化,从不作数。**"前端藏了按钮就安全"这种想法,在这套架构里从设计上就被否掉了。** + +这道防线的最外圈,是一条降级铁律:游戏的主循环永远不能被打断。广告加载失败就跳过并给玩家兜底,支付出问题就静默降级,这些非核心能力无论怎么坏,都不许把游戏卡死。把变现和合规的控制点牢牢焊在沙箱外的平台侧,既保证了平台能掌控每一笔收入,也保证了一款出问题的游戏波及不到别人——这正是"系统边界即安全边界"的实际含义。 + +--- + +# 第二部分 · 功能模块 + +第一部分讲的是骨架,这一部分讲器官。绘境AI 的后端由十三个业务模块组成,每一个只负责一件事,合起来撑起从创作到收益的完整链路。它们按四个功能域聚在一起,主次分明。 + + + + + + + + + + + + project · 项目核心 + 全生命周期状态机 · 被最多模块依赖 + ↑ 几乎所有模块都围着它转 ↑ + + + + ① 创作 · 生成 + + + studio + 创作编排 · 编辑器 + + + + aigc + 生成原子 · 校验 + + + + runtime + 编译打包 · 沙箱 + + 一句话 → 生成逻辑与资产 → 打包成可玩产物、多渠道导出 + + + + ② 分发 · 互动 + + + feed + 游戏流 · 推荐 + + + + telemetry + 遥测 · 质量评分 + + + + community + 社区 · 成就 + + feed ⇄ telemetry 互为反哺 —— 好游戏自动浮上来,"越用越聪明"的引擎 + + + + ④ 合规 · B 端 + + + compliance + 内容安全 · 审核 · 风控 + + + + biz + B / G 端定制 · 教育文旅 + + compliance 横切:aigc · ip · biz · project 的内容,露出前都要过它这道关 + biz 服务 B / G 端定制,是最早回款的现金线 + + + + ③ 变现 + + + ad + 广告位 · 植入 · eCPM + + + + pay + 充值 · 会员 · 内购 + + + + ip + 素材市场 · 版权授权 + + + + trade + 结算汇聚 · 钱包 + + trade 是变现汇聚点:ad · pay · ip 三路收入都汇到它,再结进创作者钱包 + + + 十三个模块高内聚、低耦合,彼此只经明确的契约调用 —— 这是它们能被并行开发、互不踩脚的前提 + + +这十三个模块不是平铺的十三块,它们有清晰的主次。**project 是绝对的核心**——一款游戏从创建、生成、出多个版本、提交发布到过审上线,整条生命周期都由它的状态机管着,几乎所有其他模块都要依赖它。 + +另外三条协作关系,基本决定了整个系统的性格。**feed 和 telemetry 互为反哺**:feed 把游戏推给玩家,telemetry 收集玩家的真实行为、算出每款游戏的质量分,质量分又回喂给 feed 决定下一次推什么——这一对咬合就是"越用越聪明"的引擎,第三部分会把它单独放大。**trade 是变现的汇聚点**:广告、支付、IP 素材交易三路收入最终都汇到它,再结算进创作者的钱包。**compliance 横切在所有内容模块之上**:生成、IP、发布、B 端交付,任何内容要露出给用户之前,都得先过它这道合规关。 + +这种划分让每个模块高内聚、模块之间低耦合,而且它们只通过明确的契约互相调用。这不只是整洁,更是工程上的一个务实选择:边界切干净了,十三个模块就能被不同的人并行开发,不会互相踩脚——这也是"契约先行"这套做法在这个团队里真正落了地的证据。 + +## 一条完整的链路:从一句话到收益回流 + +把十三个模块串成一条线,就是绘境AI 完整跑一圈的样子。 + + + + + + + + + + + + + + + ① + 创作者 + 一句话:"我想做个…" + + + ② + aigc 生成 + AgentScope + 九门验收 + + + ③ + 合规门 + pass 才入流(硬红线) + + + ④ + feed 游戏流 + 竖屏刷 · 即点即玩 + + + ⑤ + 玩家 + 试玩 + 互动 + + + 数据回流 · 越用越聪明 + + + + + + ⑥ + telemetry 聚合 + 玩家行为埋点入库 + + + + + ⑦ + 质量分 0–100 + 好游戏浮上 · 差游戏沉底 + + + + ⑧ feed 重排 · 把更好玩的推回玩家 + + + 并联钱流 · 玩家每次试玩即触发　⑤ → + + + + + + + + Ⓐ 广告曝光 + ad 模块 + + + Ⓑ 计费落账 + 按次记账 + + + Ⓒ trade 分账 + 按来源对账 + + + Ⓓ 创作者钱包 + 当天可见收益 + + + 主链 + 数据回流(飞轮) + 并联钱流 + + +主链是这样跑的:创作者敲下一句话(①),经 studio 提交给 aigc 生成(②),产物过完九门验收、打包成可玩的游戏,先落成 project 里的一份草稿;创作者点发布,触发 compliance 的合规裁决(③)——这里有一条硬红线,**只有裁决 pass 的游戏才允许进入游戏流**,造得再好、过不了这道门也上不了线。过审的游戏进入 feed(④),玩家在竖屏游戏流里刷到、即点即玩、点赞分享(⑤)。 + +到这里,线性的价值链拐了个弯,变成一个环。玩家的每一个行为都被埋点上报进 telemetry 聚合(⑥),算出一个 0 到 100 的质量分(⑦),这个分再回喂给 feed 重新排序(⑧),把更好玩的游戏推回到玩家眼前。这条绿色的回流,就是把一条直线弯成飞轮的地方,也是数据护城河的产品载体——第三部分会把它单独放大。 + +和主链并联的,还有一条钱流:玩家每次试玩都可能触发一次游戏内广告曝光(Ⓐ),经 ad 模块计费落账(Ⓑ),由 trade 按来源对账分账(Ⓒ),最后结进创作者的钱包(Ⓓ)。创作者当天做的游戏,当天有人玩,当天就能看到收益。 + +判断这样一套系统"有没有缝",就是看相邻两步的交接对不对得上:出包能不能落成草稿、草稿能不能提审、裁决能不能挡住入流、互动能不能回流成排序。这些交接点全在一条线上,顺着编号走一遍就能核对——这也是这张图对做技术评审的人最大的用处。 + +## 六种角色,两个入口 + +这套系统服务的"用户"最终收敛成六种角色,分布在两个前端上。最容易混的是"经营"和"运营":**经营是创作者看自己作品的数据**(留存、完玩、广告转化),**运营是平台管理员**(审核、精选、封禁),两者分属不同的端。 + +| 端 | 角色 | 做什么 | +|---|---|---| +| **C 端 · game-studio** | 创作者 | 一句话生成、预览迭代、发布、看自己的收益(经营) | +| | 玩家 | 刷游戏流即点即玩、点赞分享、发起"做同款" | +| | B 端客户(询单侧) | 提需求、看 demo、验收 | +| **B 端 · game-admin** | 运营(平台管理员) | 内容审核、精选推荐、封禁处置、经营看板 | +| | 管理员 | 用户与权限管理、合规处置、数据看板 | +| | 商务 / BD | B 端定制单据流转、报价、进度、交付 | + +这里藏着两条把平台"转起来"的转化回路:一条是玩家在游戏流里看到一款游戏,直接点"做同款"跳进工作坊,**从玩游戏的人变成做游戏的人**——这是网络效应护城河的产品载体;另一条是 B 端客户的询单,经商务流转成一张定制单据,接上最早回款的那条现金线。 + +--- + +# 第三部分 · 游戏生成 + +这是护城河的关键路径,也是整套系统里技术含量最高的一块。竞品大多能"生成",真正难的,是让一个普通模型**稳定地、可维护地、可长期演进地**把一句话变成一款真游戏。绘境AI 解决这个问题的方式可以一句话概括:**它不是一个让强模型自由发挥的编码助手,而是一台被刻意设计成可靠的生成机器。** + +这台机器立在三个支点上: + +- **用便宜的通用模型驱动,而不是训一个昂贵的专用大模型。** 质量缺口不靠把模型做重来补,而靠模板约束和验收门来补。这是成本策略,也是"生成迟早会被追平、护城河不在生成本身"这个判断落到工程上的样子。 +- **用固定的流程图约束控制流,而不是让模型自己决定下一步干什么。** 每一步走到哪、下一步做什么,是预先定好的,不是模型临场发挥的。 +- **用一套硬验收门当地板。** 一款游戏能不能装载、跑不跑帧、响不响应操作、到不到游戏终态,全部由机器确定性地判定。这一层是整套架构最大的工程价值,也是绝不妥协的底座。 + +## 一句话怎么变成一款游戏 + +一句话变成游戏,走的是一条固定相位的流水线:先读懂题面,再造出东西,最后反复验收直到合格或放弃。 + + + + + + + + + + + + + + ✓ 过门 + + + + + 题面 + 一句话 + 选项 + + + + 设计 GDD + 结构化成待办清单 + + + + 生成 + 便宜模型写真 src/ + + + + 构建 + 确定性打包成产物 + + + + 验收 · 九门 + 机器真玩,判能不能玩 + + + + 发布 + 落库 · 进上线链 + + + + + + ✗ 不过门 → 修复(确定性)/ 升档(换更强模型)→ 重跑一轮 + + + + 铁律:修不好也升不动,就显式放弃并留下证据 —— 宁可失败,绝不交付一款坏游戏 + + +读这条流水线,抓住两个特征就够了。 + +**它是一条带回环的线,不是一条直线。** 验收这一关最关键:游戏造出来先被机器真玩一遍,过不了就打回去——能确定性修的就修,修不动就换一个更强的模型再试(这是显式的"加钱保质量"),然后重新走生成、构建、验收。这个回环是质量的来源。这里也藏着一条容易被忽略却很要紧的纪律:出题的和被考的绝不能是同一只模型,后面讲验收时会回到这一点。 + +**它有一条绝不含糊的铁律:宁可显式失败,也绝不交付一款坏游戏。** 一款游戏如果反复修、升档都过不了门,系统会显式地放弃它、留下证据,而不是硬着头皮交付一个玩不了的东西糊弄用户。对一个要靠"即点即玩"留住玩家的平台,这条底线比多产几款游戏重要得多。 + +## 一套框架,三档深度:从"照模板填"到"自治创作" + +同样是"一句话生成",不同的人想要的东西天差地别:有人要一个五秒钟上手的打砖块,有人要一个能经营、能挂机、有养成系统的复杂游戏。绘境AI 用一套框架覆盖这整个跨度,靠的是按 **AI 参与深度**分三档。 + + + + + + + + + + + + + + + AgentScope · 一套自治 agent 框架统一编排三档 + + + + AI 参与浅 + AI 参与深度 —— 唯一分档轴 + AI 参与深 + + + + Tier 0 + 照模板填 · AI 参与最浅 + AI:填参 · 配文案 · 选资产 + 品类:打砖块 · 合成 · 答题 + 引擎:LittleJS + + 预算硬闸 < ¥10 / 次 + + + + Tier 1 + 受控改码 · AI 参与中 + AI:受控改码 · 加关卡 · 生成资产 + 品类:轻中度成长游戏 + 引擎:LittleJS + + 预算硬闸 < ¥10 / 次 + + + + Tier 2 + 自治创作 · AI 参与最深 + AI:自治造多系统富交互 + 品类:合成 · 经营 · 挂机 + 引擎:Phaser(全无头) + + 预算硬闸 < ¥50 / 次 + + + + 分档的轴只有 AI 参与深度这一条 —— 引擎(LittleJS / Phaser)是按表现复杂度选的实现变体,不是分档轴。 + 无论哪一档,产物都是同一种 src/ 多文件源工程,都过同一套九门验收。 + + +这张图有两个容易被误解的地方,值得说清。 + +**分档的唯一标准是 AI 参与深度,不是引擎。** 三档全都高度模板化——平台预先备好玩法模板和工程骨架,AI 不从零写,只是在模板上按档位深浅填数值、改逻辑、写表现层。Tier0 让 AI 干得最少(照模板填),Tier2 让 AI 自治地造多系统富游戏。引擎只是按表现复杂度选的实现:轻中档用 LittleJS,最富档用 Phaser。换引擎不改变"这是第几档",产物也始终是同一种 src/ 源工程、过同一套验收。 + +**每一档都带一条硬性的成本闸。** 便宜档每次生成不超过 ¥10,复杂档不超过 ¥50(图片和音乐另算)。这不是预估,是焊死的上限,超了就停。一个要规模化生成的平台,如果不把单次成本钉死,很容易在"让 AI 多试几次"里悄悄烧掉利润。这条闸和"便宜模型 + 门兜底"的路线一脉相承:用最省的方式把游戏造出来,把省下的算力留给验收和迭代。 + +## 一款游戏不是一坨文件,是一个能长期养的项目 + +这台生成机器背后,还有一条比任何技术细节都更根本的判断,它决定了"生成质量"到底该怎么定义。 + +绝大多数生成工具把"生成"理解成:产出一坨能玩的打包文件,存下来。这条路有个致命的死结——用户想改,怎么办?去 diff 那坨打包好的文件,几乎不可行。绘境AI 从根上换了个模型:**一款游戏不是一次性的产物,而是一个长生命周期的软件项目;LLM 扮演的是这个项目的"工作室"。** + + + + + + + LLM = 工作室 + 创建并长期维护 + 一个游戏源项目 + 像真实工作室 + 经营自己的代码仓 + + + + + + 一款游戏 = 一个源项目 + + + game.json项目元数据 + design.md设计文档 GDD + config/参数 · 关卡 ← 改这里=调平衡,免 LLM + src/模块化逻辑 ← 改玩法=重生成一个模块 + assets/六类资产(引用,非内联) + build.json构建配置 + + 结构化 · 模块化 · 数据驱动 —— 为"工作室将来回来改它"而设计 + + + + + + 生命周期操作 + create 脚手架出项目 + modify 换皮 / 调参 + (秒级 · 免 LLM) + extend 加文件 · 只增不改 + build 确定性构建成产物 + maintain 据数据回来演进 + + + + 不碰打包产物,在源项目上演进、再重新构建 —— 这解开了"AI 生成的游戏改不动"的死结 + + +这个转变带来的好处,恰恰是最能打动人的地方。因为游戏是一个结构化、模块化、数据驱动的源项目,创作者想改的时候,大多数修改根本不需要惊动 AI:换个皮肤、调个难度、加一关,都是确定性地编辑某个文件,秒级完成、零成本;只有要改玩法逻辑,才让工作室回来重新生成那一个模块。而"据玩家反馈回来持续演进"这一步,又把数据闭环接回了护城河——一款游戏可以像一个真实的软件项目那样被长期养着,而不是生成完就扔。 + +所以在绘境AI 这里,生成质量的真标尺不是"这次能不能玩",而是"工作室将来能不能维护它"。这条判断直接决定了产物必须是一个真实的、可导航的源码工程,而不是一段没法维护的硬编码——它也是创作者能用一句"把难度调低一点、把主角换成猫"就改动一款游戏的技术根基。 + +## 质量从哪来(上):一个可插拔的平台 + +这套生成能力还有一个对技术尽调很关键的设计:它是一个可插拔的平台,而不是绑死在某一个 agent 框架上。 + +绘境AI 的做法,是划一条清楚的线,把"谁来生成"(agent 框架)和"生成什么、怎么验收、怎么落库"(平台契约)彻底分开。平台只认一层 adapter,这层 adapter 由三个采自业界主流标准的端点、加两块必须自研的东西组成。 + + + + + + + 周边服务 · 13 后端模块 / runtime / feed / pay / 素材 / 审核 + + + + + 平台 adapter · 系统拥有的契约(换框架也不许动) + + 采 2025 主流标准 ↓ + + + A2A + 任务 / 状态 / 流式 / 发现 + + + + MCP + 工具调用 + + + + OpenTelemetry + 全链路追踪 trace + + + 自研 · 护城河 ↓ + + + 确定性验收门(九门) + 业界无对等物 · 必须自建 + + + + 生成断点续跑 + 生成专属 · 无跨框架标准 + + + + + 只要会说 A2A + MCP + OTel 就能插入 + + + + agent 框架:AgentScope(主) · SAA / dify / coze(远期适配验证 · 可插拔) + + +任务和状态用 A2A、工具调用用 MCP、全链路追踪用 OpenTelemetry,这三样直接采标准;而确定性验收门和生成断点续跑这两块,业界没有现成对等物,是平台自建的护城河。这条线的意义是:**任何 agent 框架,只要会说这三种标准协议,就能插进这个平台。** 今天主力用 AgentScope,将来要换或要并存别的框架,只是给它接一个新 adapter,不用动上层十三个模块的调用、也不用重写验收和落库。既避免把自己锁死在一套私有框架里,又把真正值钱的两块——怎么判游戏真能玩、怎么让一次生成断了能续上——牢牢攥在自己手里。 + +## 质量从哪来(下):三层兜底,谁也替不了谁 + +回到最核心的问题:一款 AI 生成的游戏,凭什么敢说它质量过关?答案是三层兜底,各司其职。 + + + + + + + ③ 人锚抽检 + 视觉模型的死角(如交互手感)由人做最终纠偏 + 现阶段不可替代 + + + + ② 便宜 player · 视觉模型看截图 + 判机器判不了的主观:好不好看 · 节奏对不对 · 是不是想要的那个游戏 + 软 · 只参考,不做最终放行 + + + + ① 确定性门 · 九门(硬地板) + 机器把游戏放进真实浏览器真玩一遍,纯代码判定 —— + 能启动 · 不报错 · 跑帧 · 真渲染 · 响应操作 · 机制有进展 · 到得了终态 + 不用模型 · 挡住坏游戏 + + + + 不让步的纪律:出题的和被考的绝不能是同一只模型 —— 质量是设计进流程里的,不是 LLM 自评 + + +最底下是确定性门,也就是九门。它把一款游戏放进真实的浏览器环境里真玩一遍,用九道纯代码的检查判定:能不能启动、有没有报错、跑不跑帧、画面有没有真渲染、响不响应操作、机制有没有进展、到不到终态。这一层全是机器的确定性判断,不掺任何模型的主观意见,是挡住坏游戏的硬地板。 + +往上一层,是便宜的视觉模型看截图,判那些机器判不了的主观问题:好不好看、节奏对不对、是不是用户想要的那个游戏。这一层是软的、会有误差,所以它只做参考,不做放行的最终裁决。 + +最上面一层是人的抽检。视觉模型有它判不准的死角——比如碰撞手感这类交互问题——现阶段还需要人来做最终纠偏。这一层暂时去不掉,平台也没有假装它已经全自动。 + +这三层背后,有一条不让步的纪律:**出题的和被考的绝不能是同一只模型。** 让生成游戏的那只模型自己给自己打分,验收就等于没验。所以判"能不能玩"的九门是纯代码、不用模型,判"好不好玩"的视觉模型也独立于生成方。质量是被设计进这套流程里的,不是靠 LLM 自我表扬得来的——这是整条生成线最该记住的一句话,也是"这台机器为什么可靠"的真正答案。 + +## 越用越聪明:数据飞轮 + +前两部分都提到过一条回路,这里把它单独放大,因为它是理解绘境AI 为什么"越用越聪明"的关键,也是护城河真正开始成形的地方。 + + + + + + + + + + + + + + + + + + + + + + + 数据飞轮 + 越用越聪明 + + + + + ① 玩 + 互动 + 玩家在游戏流 + + + + ② 埋点上报 + 游戏内 SDK + + + + ③ 聚合 + telemetry 幂等入库 + + + + ④ 质量分 + 0 – 100 + + + + ⑤ 进推荐 + Redis 候选集 + + + + ⑥ 重排下发 + feed 更新排序 + + + + + 唯一的"硬"降权是 error_rate:能不能玩,永远排在好不好玩前面 —— 即点即玩的可玩性底线 + + 这条回路 = 护城河第一层:真实流量喂出来的数据,买不到、追不上 + + +这条回路转一圈是这样的:玩家在游戏流里玩、互动,游戏内的埋点把这些行为上报,telemetry 逐条幂等地聚合入库,算出每款游戏 0 到 100 的质量分,这个分进入推荐、把游戏流重新排序,更好玩的浮上来、玩不动的沉下去,再推回到玩家眼前。转一圈,平台就更懂一点什么好玩。 + +这里有一个刻意的设计:唯一的"硬"降权是 error_rate,也就是技术上跑不动的游戏直接沉底。在"好不好玩"之前,先卡住"能不能玩"——这是即点即玩的可玩性底线,也和前面那套九门验收一脉相承:能玩,永远是第一位的。 + +而这条回路,正是护城河的第一层。它靠的是真实流量一点点喂出来的数据,这种数据买不到、也没法凭空造;飞轮一旦转起来,好游戏自动浮现、创作者和玩家互相吸引,追赶者面对的就是一个指数级增长的差距。 + +--- + +# 收尾 · 这套技术,到底为哪几层护城河服务 + +讲完三大技术部分,把话收回到最开始那句判断:**生成能力本身不是护城河,它是入场券。** 绘境AI 把技术刻意做成"够用、可替换、低成本",正是为了把省下来的资源,全部投到几样真正搬不走的东西上。 + + + + + + + 生成能力 = 入场券,迟早会被通用大模型追平 —— 不是护城河 + + + + ① 数据壁垒 + 玩家行为 + 质量评分 + 推荐信号 + 真实流量喂出,买不到 + 长在数据飞轮上 + + + + ② 网络效应 + 创作者 ⇄ 玩家:越多越丰富、越丰富越吸引 + 飞轮转起,追赶成本指数级 + 靠"做同款" + 创作者资产沉淀点燃 + + + + ③ 资产壁垒 + 模板库 + 素材市场 + IP 合约 + 时间沉淀型,搬不走 + 随生成越用越厚 + + + + ④ 合规壁垒 + ICP + 文网文 + 广告资质 + 渠道关系 + 牌照 + 关系,6–12 月门槛 + 日历驱动,压不快 + + + + 诚实说:这四层墙大多还没砌完 —— 要在窗口期用融资点燃、用时间长成,不是已经握在手里的 + 现在真有的,是别人还没接通的那条"做得出 → 有人玩 → 赚到钱"闭环 —— 一个不公平的起跑 + + +这四层护城河,对应着技术架构里的不同部分。数据壁垒长在那条数据飞轮上;网络效应靠玩家"做同款"、创作者资产沉淀这些产品设计来点燃;资产壁垒是模板库、素材市场、IP 合约随时间的积累;合规壁垒则是一张张要花 6 到 12 个月才能办齐的牌照和渠道关系。 + +必须诚实地说:这四层墙,现在大多还没砌完。它们是要在窗口期里用融资点燃、用时间长成的东西,不是已经握在手里的。绘境AI 现在真正有的,是一样别人还没有的东西——那条"做得出 → 有人玩 → 赚到钱"的全栈闭环,已经在这套架构上设计成型、跑得通。它给的是一个别人没有的起跑,而不是一道已经砌好的墙。 + +所以,如果要用一句话收束这套技术的定位:**这不是一套堆满护城河的架构,而是一个懂工程的团队,用最少的钱、最快的速度,把一条别人没接通的闭环扎扎实实跑通了的架构。** 对看技术的人来说,这恰恰是最该考察的东西——不是它宣称了多少壁垒,而是它用什么样的判断力和克制,把每一分资源都花在了刀刃上。