整条流水线由 5 个独立车间串联。车间之间通过标准交付物 + 质检门控对接，任何车间可独立扩容或外包。
▼ 就绪的资质包 ▼
▼ 入库的模板 ▼
▼ 净化后的干净 AAB ▼
▼ 完整的 A+B 成品包 ▼
角色 × 车间矩阵
| 角色 | 所在车间 | 核心职责 |
|---|
| 资质专员 | 🏢 账号车间 | 身份资料、公司注册、开发者账号、隔离环境、资源池、14天养号 |
| 模板开发者 | 🎮 A面车间 | 竞品分析、Godot 开发、参数化改造、代码差异化 |
| 美工 | 🎨 换皮车间 | 素材替换、配色、游戏参数调整 |
| B面工程师 | 🔮 B面车间 | 判定架构、策略选型、B面代码变异、加载方式 |
| 运维 | 📦 提包车间 | 绑定资质、API 提交、审核跟踪、上架后监控 |
| 外部投放团队美工 | 🎨 换皮车间（受限） | 根据流量热度选模板、换皮制作 A 面，只能看到自己提交的包的提审/过审/掉包/投放数据 |
| 管理员 | 全部 | 全局看板、风险矩阵、跨车间协调、投放数据看板、风控数据库 |
五个车间速度完全不同——两头慢、中间快。不做协调就会积压或饥荒。核心策略：慢车间提前备货维持库存，快车间按下游消化能力限产。
各车间速度特征
| 车间 | 单件耗时 | 并行度 | 产出特征 | 节拍策略 |
|---|
| 🏢 账号 | 30-45天/套 | 可并行（不同国家同时办） | 可复用——每套资质挂 3-5 包 | 提前备货型：维持就绪库存 ≥ 下月需求 |
| 🎮 A面 | 5-10天/模板 | 可并行 | 可复用——每模板派生 20-50 包 | 提前备货型：模板库存 ≥ 品类需求 |
| 🎨 换皮 | 预估几小时/包（需验证） | 高度并行（AI 驱动） | 一次性——每次产出 1 个包 | 按需限产型：按提包车间消化能力安排 |
| 🔮 B面 | 1-2天/包 | 可并行 | 一次性 | 跟随换皮车间节拍 |
| 📦 提包 | 14-21天/包 | 受限于资质数量 | — | 流水排布型：错开提交，14天窗口交错 |
车间之间的缓冲库存
每两个车间之间有一个缓冲池。池子水位太低 = 下游要饿了，自动触发上游补货。池子太高 = 上游产出过快或下游消化不了，需要限产。
| 缓冲池 | 位于 | 库存内容 | 安全水位 | 低于水位时 |
|---|
| 就绪资质池 | 账号车间 → 提包车间 | 已完成 14 天养号、全部验收通过的资质套数 | ≥ 未来 4 周的预计消耗量 | 立即启动账号车间补货 |
| 模板库 | A面车间 → 换皮车间 | 已入库的可用模板数 × 剩余变种空间 | 每个品类至少 1 个模板，变种空间 > 30% | 安排 A面车间开发新模板或改进旧模板 |
| 待注入队列 | 换皮车间 → B面车间 | 已净化但还没注入 B 面的干净 AAB 数量 | 不超过 B面车间 1 周产能 | 换皮车间限产——不要生产超过 B面能消化的量 |
| 提包队列 | B面车间 → 提包车间 | 已完成 B 面注入、等待提交上架的成品包 | 不超过可用资质槽位数 | B面车间限产或账号车间补货 |
提包车间的流水排布
14 天封闭测试是硬约束。如果 10 个包同一天提交，14 天后 10 个包同一天进入审核——违反分散原则。必须错开。
| 约束 | 规则 |
|---|
| 提交间隔 | 同一资质下的包间隔 ≥ 3 天提交 |
| 每日上限 | 全平台每日提交总量不超过可用资质数的 10% |
| 14天窗口 | 滚动排布——确保每周都有包完成测试进入审核，而不是集中在某一天 |
| 审核失败重提 | 被拒的包重提间隔 ≥ 7 天，不能立即重提 |
管理员需要监控的指标：
① 就绪资质池水位 vs 消耗速度 → 预测何时耗尽
② 各品类模板的变种空间剩余 → 是否需要新模板
③ 待注入队列长度 → 换皮车间是否过快
④ 提包队列长度 vs 可用资质槽位 → 是否需要账号补货
⑤ 每周提包量 vs 计划量 → 是否在分散原则范围内
Google 能关联两个包的维度远不止 IP 和手机号。任何「多个包共用同一个 X」的地方都是关联风险。以下列出全部需要分散的维度，标注在哪个车间执行。
分散维度全景
| 维度 | 关联风险 | 分散要求 | 车间 |
|---|
| 自然人身份 | Google 比对注册信息 | 每套资质独立身份，不复用 | 🏢 |
| 公司 / LLC | 同公司下多个账号 | 每套资质独立公司 | 🏢 |
| 手机号 | 同号段批量注册 | 不同运营商、不同号段 | 🏢 |
| 邮箱 | 域名模式关联 | 独立域名邮箱，命名无规律 | 🏢 |
| 信用卡 / 支付 | 同 BIN 号段 / 同持卡人 | 独立卡号，不同发卡行 | 🏢 |
| 住宅 IP | 同 IP / 同子网 | 独立 IP，不同供应商/地区 | 🏢 |
| AdsPower / 浏览器环境 | 设备指纹关联 | 独立环境，互不共享 | 🏢 |
| 域名注册商账号 | 同一 Namecheap 账号下 87 个域名 | 多个注册商账号轮换 | 🏢 |
| 代码架构 / 风格 | 代码聚类分析 | 不同模板看起来像不同人写的 | 🎮 |
| Godot 引擎版本 | 导出模板哈希一致 | 模板库覆盖 2+ 引擎版本 | 🎮 🎨 |
| 视觉素材来源 | AI 生成图像的统计学指纹 | 多 AI 模型 + 多 prompt 风格 | 🎨 |
| 商店文案 / 截图 | NLP 风格聚类 | 多 prompt 模板 + 多 AI 模型 | 🎨 |
| 构建环境 | 编译路径 / 时间戳 / 工具链版本 | 独立容器 + 版本池随机选 | 🎨 |
| 签名证书 | DN 模式 / 有效期 / 序列号 | 每包独立 keystore | 🎨 |
| GCP / Firebase 项目 | 多包共用同一个项目 | 每包独立 Firebase 项目 + AdMob 账号 | 🔮 |
| 云函数 / 判定层 | 所有判定跑在同一个 GCF 项目 | 分散到多个 GCP 项目 / CF 账号 | 🔮 |
| B面加载域名 | 多包的 WebView 指向同一个域名 | 每包独立域名 → CDN → 统一后端 | 🔮 |
| 判定策略组合 | 同策略 = 行为模式一致 | 同资质下不同包用不同策略组合 | 🔮 |
| API 调用来源 IP | 所有 API 提包来自同一台服务器 | 通过不同资质的AdsPower环境分别调用 | 📦 |
| 上传时间 | 批量上传时间模式 | 随机延迟 1-7 天 | 📦 |
| 更新频率 | 所有包同时更新 | 更新时间随机打散 | 📦 |
铁律：在设计和实现任何环节时，先问一句「这个东西是不是所有包共用的？」——如果是，就必须分散。没有例外。
📦
四、资产全生命周期管理——贯穿所有车间的基础能力
每个车间都管理各自的资产（账号车间管 IP/手机号/信用卡，A面车间管模板，B面车间管策略方案...）。所有资产遵循统一的生命周期范式。
资产生命周期
入池▶
分配▶
使用中▶
变更▶
废弃 / 标脏
| 阶段 | 说明 | 系统能力 |
|---|
| 入池 | 资产进入系统。两种方式：① API 自动采购入池 ② 外部购买后手动录入 | API 对接 + 手动录入表单 + 入池自动排重（不与已有/已废弃/已标脏资源重复）+ 自动分配批次号 |
| 分配 | 资产绑定到具体的资质/包/方案 | 分配记录 + 分配时间 + 分配人 |
| 使用中 | 资产正在被某个资质/包使用 | 到期提醒 + 续费管理 + 状态监控 |
| 变更 | 资产信息发生变化（IP 死了换新的、信用卡过期换一张、模板代码改了一版） | 编辑入口 + 编辑日志（记录谁改了什么、什么时候改的、改之前是什么）+ 变更标签（如「更换过 IP」「更新过证件」） |
| 废弃 | 资产不再使用（IP 脏了、账号被封了、模板关联了） | 标记废弃/标脏 + 废弃原因 + 同批次连坐排查 + 永久不可再分配 |
各车间的资产类型
| 车间 | 管理的资产 | 入池方式 | 常见变更 |
|---|
| 🏢 账号 | 手机号、IP、信用卡、邮箱、域名、AdsPower 环境、身份资料、公司信息 | API 采购 + 手动录入 | IP 更换、信用卡过期换卡、证件更新、环境重配 |
| 🎮 A面 | 游戏模板工程 | 模板开发者上传 | 模板代码修改、参数化调整、标记疲劳/禁用 |
| 🎨 换皮 | 换皮素材、商店截图模板、AI prompt 模板 | 美工上传 / AI 生成 | 素材替换、截图模板更新 |
| 🔮 B面 | 组装方案、判定策略、加载配置、GCF 项目 | B面工程师配置 | 策略失效标记、方案版本升级 |
| 📦 提包 | AAB 文件、商店 Listing 信息、审核记录 | 系统自动生成 | 重提更新、审核状态变更 |
批次管理
同一批采购/创建的资源共享一个批次号。批次的意义：① 同批次资源的关联风险更高（同一供应商、同一时间段）② 一个资源出问题时，同批次需要连坐排查。
| 规则 | 说明 |
|---|
| 自动生成批次号 | 每次 API 采购或批量手动录入，系统自动分配批次号（如 B-2026-07-001） |
| 批次内关联 | 同批次的资源在隔离检查时要额外关注——来自同一供应商的同一批 IP/手机号天然有更高的关联风险 |
| 批次连坐 | 某批次中一个资源被标脏 → 同批次所有资源标记「待排查」→ 人工确认后决定保留或废弃 |
变更标签体系
资产每次发生变更都会自动打标签。标签直接影响增量评分。
| 标签 | 触发条件 | 对评分的影响 |
|---|
| 更换过 IP | IP 死掉后换了新 IP | IP 清洁度 -1 分 |
| 更换过信用卡 | 信用卡被拒/过期后换卡 | 卡段独立性需重新评估 |
| 更新过证件 | 证件传错后重新上传 | 账号制作稳定性 -1 分 |
| 更换过环境 | AdsPower 环境重配 | 设备指纹需重新验证 |
| 同批次有脏记录 | 同批次另一个资源被标脏 | 该资源自动标记「待排查」 |
| 曾被关联 | 掉包后反向追溯标记 | 直接废弃或降为最低分 |
变更日志是审计的基础——每次编辑都记录：谁改的、什么时候改的、改了什么字段、从什么值改成什么值。掉包后做反向追溯时，变更日志是判断「这个资产什么时候开始出问题」的关键证据。
每个车间定义：谁干活、原料是什么、产出是什么、质检门控（不通过不允许进入下一车间）。
🏢 账号车间
生产「上架资格」。每套资质 = 一个完全独立的身份 + 开发者账号 + 隔离环境。这是全流程中人工密度最高、周期最长的车间。
📥 原料
管理员下达的备货需求（数量 + 目标国家）
📤 产出
就绪可用的资质包（全部凭证归档 + 隔离检查通过 + 14天测试完成）
资质专员 · 人+AI 分工
| 职责 | 具体内容 | 人/AI |
|---|
| 身份资料准备 | 自然人信息、证件照、地址证明、手机号、邮箱、信用卡 | 🧑 人工为主 · 🤖 AI 检查跨资质关联性 |
| 公司注册 | LLC（美/英/菲/越等）+ EIN + 邓白氏号 | 🧑 人工或委托注册代理 |
| 开发者账号注册 | Google ($25) / Apple ($99)，全程使用对应 IP 和设备 | 🧑 纯人工（身份验证/人脸/视频通话） |
| 隔离环境搭建 | 住宅 IP（AdsPower/自备）+ 独立设备指纹 + 独立浏览器环境 | 🧑 人工配置 · 🤖 AI 检查 IP 冲突 |
| 收款账户 | PayPal Business / Payoneer · KYC 验证 | 🧑 纯人工 |
| 14天封闭测试 | 新账号首个 App 必须 14 天 + ≥20 测试者 | 🧑 组织测试者 · 🤖 AI 监控进度 |
| 凭证档案管理 | 密码/密钥/证书/SA/API Key 统一归档加密 | 🤖 自动归档 + 加密存储 |
| 日常维护 | IP 续费、年费续期、证书续签、异常响应 | 🧑 人工操作 · 🤖 到期提醒/异常告警 |
生产流程 · 6 阶段 · 约 30-45 天
基础资源采购▶
身份 + 公司注册▶
域名 + 在线身份▶
开发者账号注册▶
收款开通▶
14天养号 + 验收
一套资质包含的完整资源
| 类别 | 资源 | 分散要求 |
|---|
| 身份 | 自然人信息、证件照（正/反/手持）、地址证明 | 每套独立自然人 |
| 通讯 | 手机号 + 邮箱 | 不同运营商/号段，域名命名无规律 |
| 支付 | 信用卡/借记卡 + 收款账户（PayPal/Payoneer） | 不同发卡行、不同 BIN 号段 |
| 公司 | LLC 执照 + EIN + 邓白氏号 | 公司名/地址/EIN 全部独立 |
| 域名 | 独立域名（隐私政策 + 开发者网站 + 邮箱后缀） | 不同注册商账号，命名无规律 |
| 网络 | 住宅 IP（通过 Bright Data / IPRoyal 等供应商 API 采购）+ AdsPower 环境 | 不同 IP 供应商/地区，IP 非数据中心；API 采购入池后自动排重 |
| 账号 | Google Play + Apple Developer + Service Account + API Key | 每套独立 |
出库门控（Checklist）——全部通过才能标记「就绪可用」：
- 州注册处可查到公司 + dnb.com 可查到 DUNS
- Google/Apple 开发者账号状态 Active 且未被标记
- 14天封闭测试完成（≥20 测试者全部 opt-in）
- Service Account + API Key 有效
- 收款账户已验证（测试收款成功）
- AI 关联性扫描通过——与所有已有资质零关联（姓名/地址/手机号段/IP子网/BIN号段/域名模式）
- 凭证档案完整且加密存储
🎮 A面车间
生产「游戏模板」。从互联网爬取休闲游戏（Cocos/Pixi/Canvas/Three.js 等各类技术栈），用 AI 跑成本地可运行的高保真工程，转换技术栈后参数化入库。
这是差异化的源头。模板之间如果代码风格一致、架构一致，后续所有车间的差异化都是白费。
📤 产出
干净的游戏工程（Godot / Cocos / Unity 等，按技术栈分散策略选择）+ 参数配置表 + 可变维度说明
L1 · 基础组件库（做包越多，池子越大）
| 组件类别 | 包含什么 | 增长方式 |
|---|
| 引擎层 | 场景管理、输入处理、物理碰撞、音频管理、帧率控制 | 首批模板时沉淀 |
| 高级组件层 | 在引擎 API 之上封装游戏概念级操作：「添加玩家」「添加巡逻敌人」「设置胜利条件」——AI 不操作底层节点，调用语义工具 | 每个新品类追加 |
| UI 组件 | 通用按钮、弹窗、排行榜、设置页、分享组件、加载动画 | 每做一个品类追加 |
| 变现层 | 广告 SDK 封装（AdMob / Unity Ads / ironSource）、IAP、激励视频 | 一次接好，长期复用 |
| 合规层 | 隐私弹窗、GDPR/CCPA 同意流、权限请求、年龄门控、ATT 弹窗 | 政策变更时更新 |
| 运营层 | 数据埋点、远程配置、A/B 测试、推送通知、崩溃上报 | 一次集成，按需启用 |
| 素材库 | 通用音效、粒子特效、背景图、UI 皮肤集 | 每做一个包追加 |
L2 · 品类模板矩阵（一次建好，无限派生）
| 品类 | 核心玩法骨架 | 技术栈 | 可变量（可定制参数） | 单模板可派生（预估，需验证） |
|---|
| 跑酷/飞行 | 自动前进 + 躲避障碍 + 收集物 | Godot / Unity | 主角皮肤、障碍物类型、背景主题、速度曲线、音效包 | 20-50 |
| 转盘/抽奖 | 转盘旋转 + 结果展示 + 分享 | Godot / Cocos | 奖品内容、视觉主题、音效、动画风格、分享文案 | 30+ |
| 点击/Tap | 点击累计 + 升级 + 排行 | Godot / 原生 | 点击对象、特效、成长曲线、主题皮肤 | 30+ |
| 合成/Merge | 拖拽合成 + 升级 + 解锁 | Cocos / Godot | 合成物品主题、合成规则、美术风格、音效 | 15-30 |
| 答题/测试 | 题目 + 选项 + 结果页 | H5 / Cocos | 题库内容、结果描述、视觉主题、分享卡片 | 50+ |
| 消除/Match | 三消/连线 + 关卡 + 道具 | Cocos / Unity | 消除物、关卡设计、特效、主题 | 15-30 |
| 骰子/棋盘 | 骰子 + 棋盘移动 + 事件触发 | Godot / H5 | 棋盘主题、事件内容、角色、奖励机制 | 20-40 |
技术栈选型——多技术栈是分散手段
技术栈多样性本身是抗关联特征。同一引擎构建的包在二进制层面天然有相似度，多技术栈轮换是分散铁律之一。
| 技术栈 | 优势 | 适用品类 | 定位 |
|---|
| Godot 4.x | 开源零 license、Headless 容器化、GDScript 适合 AI 生成 | 跑酷/点击/转盘/合成 | 主力引擎之一 |
| Cocos Creator | 包体最小、H5/原生双出、TypeScript | 消除/答题/棋盘 | 主力引擎之一 |
| Unity | 3D 能力强、生态成熟、C# | 3D 跑酷/塔防/音游 | 3D 品类专用 |
| 原生 (Kotlin/Swift) | 最接近平台原生、无引擎指纹 | 工具类/简单交互 | 特殊需求 |
| H5 前端框架 (Phaser/PixiJS) | Web 技术栈、WebView 天然适配 | 答题/测试/轻交互 | TWA/WebView 场景首选 |
分散要求：同一资质下的多个包必须使用 ≥2 种不同技术栈。同技术栈连续出包不超过 3 个。模板库按技术栈分类管理，确保各技术栈均有模板覆盖。
外包接口：逆向复刻可外包（交付物 = 可编译工程 + 变量配置表），验收 = 工程可运行 + 核心交互还原 ≥90%。参数化改造和可定制参数设计必须自研。
模板疲劳度——同一模板出包越多，关联风险越高
一个模板不管怎么变异，底层骨架是一样的。Google 做代码聚类分析时，同模板出的包天然有更高的结构相似度。出包越多，疲劳度越高。
| 变种空间 | 状态 | 策略 |
|---|
| > 60% | 充足 | 正常出包 |
| 30%-60% | 收紧 | 新包必须加强差异化检查（与同模板已出包逐一比对） |
| < 30% | 饱和预警 | 暂停该模板出新包，要么开发新模板，要么对现有模板做架构级大改 |
美工选模板时就能看到变种空间——不是等管理员事后发现。换皮工作台的模板市场中，每个模板卡片上直接显示剩余变种空间和进度条。饱和预警的模板标红，提示需要额外差异化或暂不可用。
A面骨架验收标准——B面车间视角的最小验收集合
站在B面车间角度，只关心交付物满不满足要求，不关心A面车间怎么做。底座由B面车间提供，A面车间按底座接口文档对接。
C · 绝对不能有——出现任何一项直接打回
| 编号 | 检查项 | 验证方法 |
|---|
| C-01 | 与本包身份无关的第三方品牌、域名、Logo、版权声明、备案号 | 全局搜索 → 除本包自身信息外零匹配 |
| C-02 | 赌博关键词——代码和 UI 都不能有 | 全局搜索 bet/balance/cashout/withdraw/deposit/wager/payout/odds → 零匹配 |
| C-03 | 向非本包归属的外部服务上报数据 | 抓包/代码审查：所有网络请求只指向本包自己的服务端或底座指定的服务 |
| C-04 | 硬编码的包名 / App ID | 包名和 App ID 必须从配置文件读取 |
| C-05 | 本机个人痕迹 | 构建产物中不含本机用户名、设备序列号、个人文件路径 |
| C-06 | 中文硬编码（出海包适用） | 代码和 UI 中无中文字符（i18n 资源文件除外） |
| C-07 | 任何对B面的引用或感知 | 代码/文档/注释中不能出现 B面、判定、切换等内容 |
| C-08 | 预填的广告 SDK 配置（AdMob ID / 广告位 ID / Unity Ads ID） | 配置扫描：无预填广告位 ID，广告按资质在提包环节注入 |
A · 必须有，怎么做不要求——只看结果不管过程
| 编号 | 检查项 | 验收标准 |
|---|
| A-01 | 完整可玩 + 零崩溃 | 默认配置能编译/安装/玩完一局；模拟器运行 10 分钟、完整循环 3 次，零崩溃零 ANR、logcat 无红色错误、无内存泄露 |
| A-02 | 整体可运行 | 端到端可用——服务端功能正常、前端交互正常、作为完整产品能跑通 |
| A-03 | 骨架化 / 参数化 | 所有可替换元素（主题/音频/文案/游戏参数/App 身份）走配置文件，换皮不改代码 |
| A-04 | 多语言支持 | 用户可见文案抽到 i18n 配置，不硬编码在代码里 |
| A-05 | 工程描述文件（MANIFEST） | 包含：资源清单、文件名与作用对照、可替换资源的位置和格式说明 |
| A-06 | 隐私政策入口 | App 内有隐私政策入口，URL 走配置文件，换皮时可替换为每包独立域名 |
| A-07 | 权限声明合理 | AndroidManifest 声明的权限与 A面功能对应；D 类能力的权限由底座在组装时注入 |
B · 必须有，且必须按底座要求对接——底座提供能力，A面提供使用场景
底座由B面车间提供和维护。不同技术栈对应不同底座，每次以B面给的接口文档为准。
| 编号 | 检查项 | A面要做什么 | 为什么必须走底座 |
|---|
| B-01 | Google 登录场景 | 游戏中有使用 Google 登录的合理功能（登录送积分/排行榜），通过底座桥接调用 | Web OAuth 在 WebView 中被 Google 封杀（2021.9 起），必须走原生 |
| B-02 | 推送通知场景 | 游戏中有接收推送的 UI 和合理理由（消息中心/活动通知），通过底座桥接接入 | WebView 不支持 Web Push API；B面用推送做用户召回 |
| B-03 | 剪贴板 / 深度链接 / 自归因 | 游戏中有使用剪贴板或深度链接的合理功能（邀请码/分享码），通过底座桥接调用 | Clipboard API 在 WebView 中不可用；自归因链路需要读剪贴板或处理深度链接 |
通用逻辑：底座提供能力 → A面提供使用场景 → 用户和 Google 审核看到的是 A面 的场景。
D · 可有可无，但如果有就必须按底座要求做
不强制包含。但如果A面做了这些功能，就必须走底座接口，不能自己直接调原生。底座已提供的能力必须走底座，底座没有的可以自行实现。
| 编号 | 功能 | 如果A面做了 | 必须怎么做 |
|---|
| D-01 | 分享功能 | 分享给好友 | 通过底座分享接口 |
| D-02 | 应用内评分 | 弹评分引导 | 通过底座 In-App Review 接口 |
| D-03 | 本地数据持久化 | 存游戏进度/设置 | Web 存储优先；如需持久可靠存储，走底座 KV 接口 |
| D-04 | 后台保活 | 后台播放游戏音乐 | 通过底座后台保活接口 |
| D-05 | WebView 缓存 | 缓存游戏资源/攻略页 | 通过底座 WebView 缓存策略接口 |
| D-06 | 远程配置 | 远程调整游戏难度/活动 | 通过底座远程配置接口（Firebase RC 或等价） |
| D-07 | Install Referrer | 追踪安装来源 | 通过底座 Install Referrer 接口 |
通用规则：底座已提供的原生能力必须走底座接口调用，不能绕过。底座没有的能力，A面可以自行实现。如需底座没有的原生能力，向B面车间提需求，由B面车间在底座中新增。
交付物
交付的是工程源码，不是 APK。打包成 APK / AAB 是B面车间的事。
| 文件 | 说明 |
|---|
| 工程源码/ | 可编译的完整工程 |
| config.template.yaml | 配置文件模板（所有可替换字段 + 注释） |
| MANIFEST.md | 工程描述文件（资源清单 + 作用说明） |
| README.md | 换皮操作说明 |
汇总：C 类 8 项 + A 类 7 项 + B 类 3 项 + D 类 7 项 = 25 项。硬性要求 C+A+B = 18 项。
底座接口规范——B面车间提供给A面车间使用的原生能力套餐
底座由B面车间开发和维护，A面车间只是使用方。不同技术栈对应不同底座，每次以B面给的接口文档为准。A面车间不需要知道底座为什么存在。
| 底座能力 | 底座提供 | A面使用场景 | 对接方式 |
|---|
| 统一 HTTP 客户端 | lib/net/ | 封装所有网络请求，URL/Header 可配置 | B面通过配置切换请求目标 |
| WebView 模块 | lib/webview/ | 独立 WebView 容器，支持 JS Bridge | B面注入运营站 URL + JS 通信 |
| 远程配置 | lib/config/ | Firebase RC 或等价框架，key 按规范命名 | B面通过配置 key 控制 AB 开关 |
| 事件总线 | lib/events/ | 统一事件发布/订阅，事件名按约定格式 | B面订阅游戏事件触发 AB 切换 |
| 深度链接处理 | lib/deeplink/ | App Links 配置，路由表可扩展 | 落地页跳转回 App 到指定页面 |
| 权限管理 | lib/permission/ | 统一权限请求封装，第四层权限按需启用 | B面方案声明需要哪些权限 |
核心原则：A面工程不用知道B面要做什么，只要按规范提供这些标准模块。B面车间不用关心A面是什么游戏，只要这些接口存在且符合规范就能接入。两边通过规范解耦。
🎨 换皮车间
把模板变成一个个独立的成品包。美工换素材 → AI 组装 → 自动质检（5层）→ 构建净化 → 产出干净 AAB。
📤 产出
净化后的干净 AAB（构建指纹已消除、元数据已清洗、签名已独立）
换皮车间内部流水线
🧑 美工换皮▶
🤖 AI 组装▶
🤖 自动质检(5层)▶
🤖 构建净化▶
✅ 出库
AI 组装工作流（人工选题 → AI 执行）
| 步骤 | 人 or AI | 做什么 |
|---|
| 选题输入 | 🧑 人工 | 基于 ASO 趋势词、热点事件确定本批方向 |
| 模板匹配 | 🤖 AI | 从模板库匹配最佳品类模板 |
| 变种方案 | 🤖 AI | 在可定制参数内生成具体的参数组合（主题/配色/音效/难度） |
| 美术资产 | 🤖 AI | 应用内皮肤素材（角色/背景/UI 元素） |
| 商店素材 | 🤖 AI + 🧑 人工审核 | 图标（512×512）+ Feature Graphic（1024×500）+ 商店截图（≥4张，多机型）+ 描述文案 + 简短描述 |
| 多语言 | 🤖 AI | 按目标市场翻译商店标题/描述、应用内文案 |
| 自动组装 | 🤖 自动化 | 参数注入模板 → 替换资产 → 编译构建 → 生成 AAB |
| 人工质检 | 🧑 人工 | 快速过一遍：能运行 + 不崩溃 + 视觉不离谱 + 无残留 |
商店素材制作规范（Google Play 上架必备）
每个包必须有一套完整的商店素材，且与同模板已出包在视觉上无相似性。
| 素材 | 规格 | 数量 | 制作方式 | 差异化要求 |
|---|
| 应用图标 | 512×512 PNG，圆角自适应 | 1 | AI 生成 + 人工调整 | 与同模板已出包图标视觉相似度检测 < 30% |
| Feature Graphic | 1024×500 PNG/JPG | 1 | AI 生成 | 不同构图/配色/布局 |
| 商店截图 | ≥4 张，16:9 或 9:16
推荐 1920×1080 或 1080×1920 | 4-8 | 真机/模拟器截图 + 包装模板 | 多套截图包装模板轮换；截图内容必须与实际游戏画面一致 |
| 简短描述 | ≤80 字符 | 1 | AI 生成 | 用不同措辞风格 |
| 完整描述 | ≤4000 字符 | 1 | AI 生成（多 prompt 模板） | NLP 相似度 < 40% |
| 隐私政策页 | 独立域名可访问的网页 | 1 | 模板生成 + 域名独立部署 | 内容差异化，域名无规律 |
分散检查（商店素材层面）：
① 图标不能用同一个 AI prompt 的微调——换 prompt 模板、换 AI 模型（DALL-E / Midjourney / Stable Diffusion 轮换）
② 截图包装模板至少准备 3 套以上，每个包随机选一套
③ 描述文案用不同 prompt 风格生成——口语化/正式/幽默/简洁轮换
④ 所有素材的 EXIF 信息在构建净化阶段会被清除，但生成阶段就要做源头差异化，不能指望后端清洗来解决统计学指纹
自动质检 · 5 层验证
| 层 | 检查什么 | 自动化 |
|---|
| 静态检查 | 场景结构完整性、资源路径有效、脚本引用正确、配置项无遗漏 | 全自动 |
| 构建检查 | 编译通过、打包成功、签名正确 | 全自动 |
| 运行检查 | 启动不崩溃、收集运行日志、无致命错误 | 全自动（模拟器/容器） |
| 截图检查 | 画面不是空白/黑屏/明显异常、UI 元素可见 | AI 视觉检查 |
| 逻辑检查 | 基础玩法成立（点击有反馈、碰撞有效果、胜利/失败可触发） | 半自动（模拟输入+断言） |
修复+回滚机制：验证失败 → 自动修复 → 重新验证 → 仍失败则回滚到快照 → 换参数重试。收敛循环，不是一次赌成功率。
构建净化 · 8 层指纹泄露维度
假设 Google 能检测一切。凡是有可能泄露关联的维度，全部消除。
| 层 | 泄露源 | 消除手段 |
|---|
| ① 构建机器 | hostname/username/系统时钟/locale/UUID | 独立 Docker 容器 + 随机化 |
| ② 工具链 | Godot 版本/导出模板哈希/Gradle/NDK/R8 | 版本池随机选 2-3 个版本 |
| ③ 代码/源文件 | 编译路径/Git 元数据/代码结构/资源 ID | 强制 release + 路径随机化 + 资源扰动 |
| ④ 素材/资源 | 图片 EXIF/音频编码器/字体元数据/文件命名规律 | exiftool 清除 + 重编码 + 文件名随机化 |
| ⑤ 包结构 | ZIP 条目顺序/压缩参数/时间戳/META-INF | 条目重排 + 时间戳打散 + 清理多余文件 |
| ⑥ 签名证书 | DN 模式/有效期/序列号 | 每包独立 keystore，DN/有效期随机化 |
| ⑦ 应用配置 | Firebase/AdMob/Backend/隐私政策 URL/崩溃上报 | 每包独立项目+独立域名 |
| ⑧ Play Listing | 文案风格/截图模式/联系邮箱/上传时间 | 多 prompt+多 AI+域名无规律+时间打散 |
构建净化流水线 · 6 阶段
🐳 独立容器▶
🧹 元数据清洗▶
🔀 特征随机化▶
🔐 独立签名▶
✅ 净化验证▶
→ 出库
| 阶段 | 做什么 | 怎么做 |
|---|
| 构建前 · 隔离 | 每包独立容器构建 | 全新 Docker 容器（随机 hostname/username/locale/时区），构建完销毁 |
| 构建前 · 重置 | 容器恢复干净快照 | 从基础镜像启动，版本池随机选工具链 |
| 构建后 · 清空 | 剥离所有元数据 | exiftool + 音频重编码 + 字体清理 + 路径扫描 + .git 删除 + META-INF 清理 |
| 构建后 · 改写 | 随机化可识别特征 | ZIP 时间戳/顺序随机 + .so padding 填充 + 素材名随机化 + 资源 ID 扰动 |
| 签名 | 独立签名 | 独立容器生成 keystore，随机种子/DN/有效期 |
| 净化验证 | 自动扫描验证 | 字符串扫描 + EXIF 扫描 + 跨包比对(抽 5 包) + 工具链版本不一致确认 + 证书 DN 无规律 |
净化验证不通过 = 不允许出库。任何一项验证失败，打回重新净化。硬门控，没有例外。
⚠ 净化方案有效性的验证方式：净化方案本身是基于推理设计的——Google 实际检测什么维度并不公开。唯一的验证方式是真实上架后观察存活情况。因此 Phase 1（最小验证）阶段必须特别关注净化方案的有效性，记录哪些维度的净化实际产生了效果。不要在 Phase 1 结果出来之前就投入大量资源完善全部 8 层净化工具。
| 步骤 | 谁做 | 差异化职责 | 分散检查 |
|---|
| 美工换皮 | 美工 | 替换素材、选配色、调参数、起名、做图标截图 | 素材不与同模板已出包重复 |
| AI 组装 | 系统 | 变量名变异、资源 ID 扰动、商店文案差异化、翻译差异化、隐私政策生成 | 代码相似度<30%、NLP相似度<40%（阈值为初始设定，需根据实际过审/掉包数据持续校准） |
| 自动质检 | 系统 | — | 5层验证：静态/构建/运行/截图/逻辑 |
| 构建净化 | 系统 | 构建环境隔离、工具链版本随机、元数据清洗、二进制改写、独立签名 | 跨包关联度≤1%（初始阈值，需验证） |
出库门控（Checklist）——全部通过才能进入 B面车间：
- 真机安装运行无崩溃
- 无原模板残留（包名/图标/文案/图片）
- 代码变异后与同模板已出包相似度 < 30%
- 图片 EXIF 零残留 + 音频编码器标识已清除
- ZIP 条目时间戳已打散 + 条目顺序已随机化
- 签名证书 DN/有效期/序列号与已有包无关联
- 跨包指纹比对关联度 ≤ 1%
- 商店文案 NLP 相似度 < 40% + 隐私政策独立域名
🔮 B面车间
给干净的 A面包注入 B面能力。核心原则：方案预沉淀、组装标准化。
B面工程师提前将多套标准化 AB 面对接方案沉淀在方案库中，组装时直接匹配复用，无需定制开发。
同时完成代码混淆、垃圾代码植入、广告与归因 SDK 集成，输出最终可提审的 AAB 格式包体。
📥 原料
换皮车间产出的净化 AAB + 风险偏好 + 策略方案
📤 产出
完整的 A+B 成品包（判定层已部署 + B面可用 + 灰度验证通过）
上游依赖声明——每种方案必须声明需要A面具备什么
B面方案不能默认A面"什么都有"。每种方案必须显式声明依赖A面的哪些能力，选方案时系统自动检查A面模板是否满足。
| B面方案类型 | 依赖的第三层（必须） | 依赖的第四层（按需） | A面不满足时 |
|---|
| WebView URL 切换 | 网络通信层 + WebView 容器 + 远程配置 | — | 方案不可用 |
| SSR 动态渲染 | 网络通信层 + WebView 容器 | — | 方案不可用 |
| 多层渐进式（本地快判+云函数） | 网络通信层 + 远程配置 + 事件总线 | Install Referrer + 设备传感器 | 降级为纯远程判定 |
| PWA/TWA 跳板 | 深度链接 | 剪切板读写 | 方案不可用 |
| 物理信号快判 | 事件总线 | GPS + 传感器 + 蓝牙 | 缺少传感器 → 方案不可用 |
| 远程模块加载（过审后下发） | 应用更新机制 + 网络通信层 | 推送通知 | 缺更新机制 → 方案不可用 |
选方案的流程：B面工程师选方案 → 系统自动比对该方案的依赖 vs A面模板已实现的能力 → 缺项标红 → 要么换方案，要么打回A面车间补能力后重新入库。不允许"先组装再补"。
组装流水线 · 7 步
选方案▶
A+B 拼装▶
代码混淆▶
垃圾代码植入▶
SDK 集成▶
编译构建 AAB▶
AI 自动修复 / 人工兜底
| 步骤 | 人 or AI | 做什么 |
|---|
| 选方案 | 🤖 系统推荐 + 🧑 确认 | 从预沉淀方案库中匹配最佳 AB 面对接方案（按技术栈 + 风险偏好 + 资质下已用方案去重） |
| A+B 拼装 | 🤖 自动化 | 将 A 面工程与选定方案按标准接口拼装为完整工程 |
| 代码混淆 | 🤖 自动化 | ProGuard/R8 + 自定义变异规则，变量名/类名/控制流变异 |
| 垃圾代码植入 | 🤖 自动化 | 按确定性种子生成无功能代码块，增加逆向分析成本 |
| SDK 集成 | 🤖 自动化 | 接入广告 SDK（AdMob/Unity Ads）+ 归因 SDK（AF/Adjust）+ Firebase |
| 编译构建 | 🤖 自动化 | 在独立容器中编译构建，输出 AAB 格式包体 |
| 兼容修复 | 🤖 AI 优先 + 🧑 兜底 | 构建失败或运行异常时，AI 自动修复常见兼容问题；无法修复才转人工 |
方案库管理：B面工程师的核心工作不是每个包现场设计策略，而是：① 持续扩充方案库（新增对接方案）② 维护已有方案的兼容性 ③ 跟踪 Google 检测演进并更新方案。组装过程本身是标准化的、可自动化的。
三层架构详解（方案库中的方案类型）
判定层 · 6 种架构
| 架构 | 判定位置 | 包体痕迹 | 适用场景 |
|---|
| 客户端本地判定 | App 内代码 | 高（可被逆向） | 仅做模拟器快判兜底 |
| 自有云函数 | GCF / Lambda / FC | 零 | 主判定首选 |
| 平台自有服务 | Firebase RC + 云函数 | 零 | 利用 Google 基础设施 |
| CDN 边缘判定 | CF Worker / Fastly | 零 | WebView 场景首选 |
| 第三方风控 | Fingerprint Pro / HUMAN | SDK 通用 | 专业级设备指纹检测 |
| 纯后端灰度 | 业务服务器用户标签 | 零 | 已登录用户分群 |
判定信号 · 5 类输入
| 信号类别 | 包含什么 | 检测能力 |
|---|
| 来源特征 | 审核方 IP 段、Install Referrer、User-Agent、设备型号 | 识别 Google 审核环境 |
| 环境特征 | 设备指纹、传感器数据模式、root/模拟器、触摸事件 | 区分真机 vs 自动化 |
| 时空特征 | GPS 坐标、时区+locale、提审后时间窗口 | 定位审核员物理位置 |
| 行为特征 | 安装到首次操作间隔、会话深度/频次、注册行为 | 区分真实用户 vs 短时审核 |
| AI 增强 [概念·待验证] | 所有信号打包 → LLM 输出审核概率评分（概念方案，需验证 LLM 判定的准确率和延迟是否满足实时判定需求） | 非硬编码，平台改策略时 AI 自适应 |
策略层 · 7 种组合方案
策略分 9 层（正道→灰色→暗道→邪修→结构规避→物理信号→协议暗通道→AI对抗→生态寄生），详细清单见参考文档。以下为推荐组合。
| 风险偏好 | 策略思路 | 包体干净度 | 适用 |
|---|
| 保守 | 远程配置全局开关 + 后端灰度 | ★★★★★ | 长期运营 |
| 标准 | 多层渐进式（本地快判+云函数+灰度窗口） | ★★★★ | 行业常见 |
| 激进 | 云函数 AI + SSR 动态渲染 | ★★★★★ | 短期冲量 |
| 跳板 | A面包 + PWA/TWA 承载 B面 | ★★★★★ | 风险最低 |
| 生态联动 | TG Mini App 等第三方平台承载 | ★★★★★ | 脱离 Play 审核 |
| 物理信号 | 传感器快判 + 后台延迟确认 | ★★★★★ | 时间差消除误判 |
| AI 对抗 [远期·概念] | 联邦学习模型 + 生成式动态 A面（需要专业 ML 能力，当前团队暂不具备，标记为远期探索方向） | ★★★★★ | 远期·对抗 Google AI |
加载层 · 6 种 B面送达方式
| 方式 | 原理 | 包体痕迹 |
|---|
| WebView 不同 URL | A→合规站，B→运营站 | 只有 WebView 壳 |
| SSR 动态渲染 | 同 URL，服务端按判定返回不同 HTML | 零痕迹 |
| 动态 JSON 布局 | 服务端返回 UI 描述，客户端引擎渲染 | 引擎通用 |
| 远程模块加载 | 过审后下载 B面模块（so/dex/RN bundle） | 有加载器代码 |
| TWA 域名切换 | TWA 指向的域名内容由服务端控制 | 零（只有 assetlinks） |
| 第三方平台 | B面在 TG Mini App / PWA 中运行 | 与 Play 包无关 |
代码实现层 · 接口契约 + 变异 + 伪装
| 环节 | 做什么 |
|---|
| 接口契约 | Protobuf / JSON Schema 定义 B面所有方法签名、参数、返回值、调用时序、错误码——唯一不变的「真相源」 |
| 行为测试 | 平台无关的行为测试用例（正常/边界/异常），验证任何实现是否符合契约 |
| 多平台实现 | Kotlin/.so/WASM/Lua 等，按目标平台实现 |
| 代码变异 | 基于唯一种子做确定性变异：重命名→结构重组→控制流变异→常量变异 |
| 伪装加固 | 分散嵌入 A面、消除统一入口、分散调用路径、删除特征关键词 |
外包边界：判定架构、策略选型、变异引擎、伪装加固、Google 检测对抗——全部自研。平台实现（把契约翻译成代码）可外包。
上架全链路 · 6 步
A面过审▶
部署判定层▶
激活 B面▶
灰度验证▶
全量放开▶
持续监控
| 步骤 | 做什么 | 关键约束 |
|---|
| A面过审 | 纯净 A面包提交审核 | A面必须是真实完整的游戏，不是空壳 |
| 部署判定层 | 按策略组合部署云函数/边缘/灰度 | 判定逻辑独立于包体，可随时更新不发版 |
| 激活 B面 | 根据策略组合激活 B面加载 | 不同策略有不同激活路径 |
| 灰度验证 | 5-10% 用户先开放（注意：新包初期日活可能只有个位数用户，灰度比例的统计意义有限。初期更依赖日志分析和手动验证） | 无异常信号才可扩大 |
| 全量放开 | 逐步扩大 | 保留一键切回 A面的紧急回退能力 |
| 持续监控 | 跟踪 Google 检测演进 | 策略失效前主动迭代 |
Google 检测能力演进（持续关注）：
2023 → 静态扫描升级（检测动态加载）
2024 → Accessibility 严查 + Play Integrity 强推
2025 → AI 行为分析（安装后 vs 审核时对比）+ Remote Config 突变检测
2026 → 大规模账号批量封禁事件（据行业报道）+ GenAI 辅助审核趋势
趋势：从「审核时扫一次」→「上架后持续监控」。
出库门控（Checklist）——全部通过才能进入提包车间：
- B面代码变异后任意两包相似度 < 30%
- 判定逻辑不在包体内（零痕迹）
- 策略组合与同资质下其他包不同
- A面功能回归测试通过（无崩溃、无 UI 异常）
- B面核心功能端到端验证通过
- 灰度 5-10% 稳定运行 24h 无异常信号
- 紧急回退机制验证通过（一键切回纯 A面）
- 策略安全评估——当前策略未被 Google 最新检测能力覆盖
- Firebase/AdMob/GCF 项目独立（不与其他包共用）
📦 提包车间
把完整的 A+B 成品包送上 Google Play 并持续运营。全流程自动化，无需人工登录 Play Console。
绑定资质 → 多厂商 Serverless 分散 IP → API 提交 → 邮箱监听自动同步审核结果 → 14天测试 → 上架 → B面开关动态管控 → 在线监控。
📥 原料
B面车间产出的成品包 + 账号车间的就绪资质
📤 产出
已上架且 B面正常的线上 App + 持续运营状态
提包流程
绑定资质账号▶
API 上传 AAB▶
填 Listing▶
14天封闭测试▶
提交审核▶
上架▶
在线监控
| 步骤 | 分散要求 |
|---|
| 绑定资质 | 通过对应资质的AdsPower环境操作——API 调用来源 IP 必须与资质绑定的住宅 IP 一致 |
| API 提交 | 用对应资质的 Service Account 调用 API，不能所有包用同一个 SA |
| 上传时间 | 随机延迟 1-7 天，不能批量集中上传 |
| 更新发版 | 不同包的更新时间随机打散 |
自动化提包架构
| 环节 | 实现方式 | 自动化程度 |
|---|
| IP 分散 | 对接 7-8 家 Serverless 厂商（AWS Lambda / GCF / Aliyun FC / Vercel / Netlify / Cloudflare Workers / Azure Functions / Deno Deploy），通过转发方式分散提包来源 IP | 全自动 |
| API 提审 | 调用 Google Play Developer API 完成全流程：edits.insert → bundles.upload → listings.update → tracks.update → edits.commit | 全自动 |
| 审核结果同步 | 监听各资质绑定邮箱的 Google 通知邮件（IMAP/API），自动解析过审、驳回、补充材料等状态并同步到系统 | 全自动 |
| B面开关管控 | 根据 Google 风控周期松紧度动态调整 B 面展示时机：高风险期（批量封号事件后）自动延迟开启 B 面，保障包体在线稳定性 | 半自动（AI 判定 + 人工确认） |
| 被拒自动处理 | 根据被拒原因自动匹配修复方案：Repetitive content → 增强差异化重新构建；Minimum functionality → 标记该模板需升级 | 半自动 |
审核结果监听——不登录 Play Console
所有账号在准备阶段就配好邮箱转发，审核结果通过邮件监听获取——不需要登录 Play Console 查看。
| 监听方式 | 获取什么 | 自动化动作 |
|---|
| 邮箱 IMAP/API 监听 | 过审通知 / 被拒原因 / 补材料要求 / 政策违规警告 | 解析邮件内容 → 更新系统状态 → 触发对应流程 |
| Google Play API 轮询 | 包状态变更（审核中→已发布 / 已暂停 / 已移除） | 状态变更 → 通知运维 + 投放团队 |
邮箱转发不能转到同一个邮箱——不同资质的通知邮箱分散，防止 Google 通过邮箱收件人关联多个账号。账号车间在准备阶段就要配好转发规则。
API 调用来源分散——对接 7-8 家 Serverless 厂商
如果 100 个包的 API 调用都来自同一台服务器，Google 一看 IP 就知道是同一个人——必须分散。
| 厂商类型 | 示例 | 分散策略 |
|---|
| 云函数 | Google Cloud Functions / AWS Lambda / 阿里云 FC / Vercel | 每个资质绑定不同厂商的函数实例 |
| 边缘计算 | Cloudflare Workers / Fastly Compute | 不同资质用不同 CF 账号 |
| 轻量 VPS | DigitalOcean / Vultr / Linode | 按需创建、用完销毁 |
提包 API 调用的来源 IP 必须与该资质绑定的住宅 IP 环境一致——不是说用 CF Worker 就行，是 CF Worker 的出口 IP 要和该资质的 AdsPower 环境所用的 IP 段保持一致，或通过代理转发。
上架门控（Checklist）——全部通过才能提交审核：
- A面真机运行无崩溃 + B面端到端验证通过
- 隐私政策页面可访问且内容匹配
- 商店截图与实际界面一致
- API 调用来源 IP 与资质绑定 IP 一致
- 该资质下挂包数未超过上限（建议 3-5 包）
- 代码相似度检测：与同资质已上架包相似度 < 30%
Google Play 审核约束（2024-2026）
| 触发行为 | 检测方式 | 后果 |
|---|
| 代码高度相似 | 自动扫描 APK，标记同代码库/微小模板修改 | 拒绝→下架→封号 |
| 素材/商店信息重复 | 图标/截图/描述相似 → repetitive content | 拒绝或下架 |
| 功能过于简单 | 缺乏核心交互、静态应用 | 拒绝 |
| 短时间批量上架 | 上传速度异常 → 自动化检测 | 高风险审查 |
| 关联身份暴露 | 硬件指纹/IP/电话/支付关联 | 连带封号 |
14天封闭测试新规（2024 生效）：新个人开发者首个 App 必须完成 14 天封闭测试（≥20 测试者），才能申请生产发布。每个新账号至少额外 2 周准备期。
外包接口规格
| 可外包 | 输入 | 交付物 | 验收标准 | 不能给的 |
|---|
| 公司注册 | 自然人信息+目标国家 | 执照+EIN+DUNS | dnb.com 可查 | 资质用途/包矩阵 |
| App 逆向复刻 | 参考 App 链接+品类 | 可编译工程+分析报告 | 可运行+交互还原≥90% | B面/上架策略 |
| 品牌资源设计 | 品类+风格+尺寸规格 | 图标+截图+启动图+文案 | 符合平台规格 | 同上 |
| 多语言翻译 | 源语言文案+目标语言 | 翻译后文案 | 母语人士审核通过 | 无 |
| B面平台实现 | 接口契约+目标平台 | 符合契约的代码+测试报告 | 行为测试 100% 通过 | B面用途/变异策略 |
绝对不能外包：接口契约设计、代码变异引擎、伪装加固、关联性检测、上架策略、判定架构——核心机密。