整条流水线由 5 个独立车间串联。车间之间通过标准交付物 + 质检门控对接,任何车间可独立扩容或外包。
▼ 就绪的资质包 ▼
▼ 入库的模板 ▼
▼ 净化后的干净 AAB ▼
▼ 完整的 A+B 成品包 ▼
角色 × 车间矩阵
| 角色 | 所在车间 | 核心职责 |
| 资质专员 | 🏢 账号车间 | 身份资料、公司注册、开发者账号、隔离环境、资源池、14天养号 |
| 模板开发者 | 🎮 A面车间 | 竞品分析、Godot 开发、参数化改造、代码差异化 |
| 美工 | 🎨 换皮车间 | 素材替换、配色、游戏参数调整 |
| B面工程师 | 🔮 B面车间 | 判定架构、策略选型、B面代码变异、加载方式 |
| 运维 | 📦 提包车间 | 绑定资质、API 提交、审核跟踪、上架后监控 |
| 管理员 | 全部 | 全局看板、风险矩阵、跨车间协调 |
五个车间速度完全不同——两头慢、中间快。不做协调就会积压或饥荒。核心策略:慢车间提前备货维持库存,快车间按下游消化能力限产。
各车间速度特征
| 车间 | 单件耗时 | 并行度 | 产出特征 | 节拍策略 |
| 🏢 账号 | 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 天 | 📦 |
| 更新频率 | 所有包同时更新 | 更新时间随机打散 | 📦 |
铁律:在设计和实现任何环节时,先问一句「这个东西是不是所有包共用的?」——如果是,就必须分散。没有例外。
每个车间定义:谁干活、原料是什么、产出是什么、质检门控(不通过不允许进入下一车间)。
🏢 账号车间
生产「上架资格」。每套资质 = 一个完全独立的身份 + 开发者账号 + 隔离环境。这是全流程中人工密度最高、周期最长的车间。
📥 原料
管理员下达的备货需求(数量 + 目标国家)
📤 产出
就绪可用的资质包(全部凭证归档 + 隔离检查通过 + 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面车间
生产「游戏模板」。从竞品市场找到参考游戏,逆向分析核心玩法,用 Godot 重新实现为可参数化的模板工程。
这是差异化的源头。模板之间如果代码风格一致、架构一致,后续所有车间的差异化都是白费。
📤 产出
干净的 Godot 项目工程 + 参数配置表 + 可变维度说明
L1 · 基础组件库(做包越多,池子越大)
| 组件类别 | 包含什么 | 增长方式 |
| 引擎层 | 场景管理、输入处理、物理碰撞、音频管理、帧率控制 | 首批模板时沉淀 |
| 高级组件层 | 在引擎 API 之上封装游戏概念级操作:「添加玩家」「添加巡逻敌人」「设置胜利条件」——AI 不操作底层节点,调用语义工具 | 每个新品类追加 |
| UI 组件 | 通用按钮、弹窗、排行榜、设置页、分享组件、加载动画 | 每做一个品类追加 |
| 变现层 | 广告 SDK 封装(AdMob / Unity Ads / ironSource)、IAP、激励视频 | 一次接好,长期复用 |
| 合规层 | 隐私弹窗、GDPR/CCPA 同意流、权限请求、年龄门控、ATT 弹窗 | 政策变更时更新 |
| 运营层 | 数据埋点、远程配置、A/B 测试、推送通知、崩溃上报 | 一次集成,按需启用 |
| 素材库 | 通用音效、粒子特效、背景图、UI 皮肤集 | 每做一个包追加 |
L2 · 品类模板矩阵(一次建好,无限派生)
| 品类 | 核心玩法骨架 | 可变量(可定制参数) | 单模板可派生 |
| 跑酷/飞行 | 自动前进 + 躲避障碍 + 收集物 | 主角皮肤、障碍物类型、背景主题、速度曲线、音效包 | 20-50 |
| 转盘/抽奖 | 转盘旋转 + 结果展示 + 分享 | 奖品内容、视觉主题、音效、动画风格、分享文案 | 30+ |
| 点击/Tap | 点击累计 + 升级 + 排行 | 点击对象、特效、成长曲线、主题皮肤 | 30+ |
| 合成/Merge | 拖拽合成 + 升级 + 解锁 | 合成物品主题、合成规则、美术风格、音效 | 15-30 |
| 答题/测试 | 题目 + 选项 + 结果页 | 题库内容、结果描述、视觉主题、分享卡片 | 50+ |
| 消除/Match | 三消/连线 + 关卡 + 道具 | 消除物、关卡设计、特效、主题 | 15-30 |
| 骰子/棋盘 | 骰子 + 棋盘移动 + 事件触发 | 棋盘主题、事件内容、角色、奖励机制 | 20-40 |
技术栈选型
首选 Godot 4.x——开源(零 license)、Headless 容器化、GDScript 适合 AI 生成和参数化、原生 Android/H5 导出。
备选 Cocos Creator——包体最小,适合新兴市场。
不建议 Unity——包体大(15MB+)、需 license、C# 编译链重。
外包接口:逆向复刻可外包(交付物 = 可编译工程 + 变量配置表),验收 = 工程可运行 + 核心交互还原 ≥90%。参数化改造和可定制参数设计必须自研。
模板疲劳度——同一模板出包越多,关联风险越高
一个模板不管怎么变异,底层骨架是一样的。Google 做代码聚类分析时,同模板出的包天然有更高的结构相似度。出包越多,疲劳度越高。
| 变种空间 | 状态 | 策略 |
| > 60% | 充足 | 正常出包 |
| 30%-60% | 收紧 | 新包必须加强差异化检查(与同模板已出包逐一比对) |
| < 30% | 饱和预警 | 暂停该模板出新包,要么开发新模板,要么对现有模板做架构级大改 |
美工选模板时就能看到变种空间——不是等管理员事后发现。换皮工作台的模板市场中,每个模板卡片上直接显示剩余变种空间和进度条。饱和预警的模板标红,提示需要额外差异化或暂不可用。
入库门控(Checklist)——全部通过才能入库给换皮车间使用:
- 完整可玩——试玩 5 分钟无崩溃、有完整玩法循环(开始→游戏→胜利/失败→重试)
- 参数化——所有可换皮维度已抽成 JSON/YAML 配置项,≥5 个独立维度
- 代码架构差异化——与已有任意模板代码结构相似度 < 30%(工具扫描)
- 代码风格差异化——命名/注释/缩进习惯与已有模板不同(AI 风格检测)
- 项目目录差异化——文件夹名/场景名/脚本名与已有模板不一致
- 引擎版本——不与最近入库的模板使用完全相同的 Godot 版本
- 无个人痕迹——git 历史清空、无 IDE 配置、无绝对路径、无署名
- SDK 接入独立——广告/分析 SDK 封装层与已有模板不同
🎨 换皮车间
把模板变成一个个独立的成品包。美工换素材 → 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 无规律 |
净化验证不通过 = 不允许出库。任何一项验证失败,打回重新净化。硬门控,没有例外。
| 步骤 | 谁做 | 差异化职责 | 分散检查 |
| 美工换皮 | 美工 | 替换素材、选配色、调参数、起名、做图标截图 | 素材不与同模板已出包重复 |
| AI 组装 | 系统 | 变量名变异、资源 ID 扰动、商店文案差异化、翻译差异化、隐私政策生成 | 代码相似度<30%、NLP相似度<40% |
| 自动质检 | 系统 | — | 5层验证:静态/构建/运行/截图/逻辑 |
| 构建净化 | 系统 | 构建环境隔离、工具链版本随机、元数据清洗、二进制改写、独立签名 | 跨包关联度≤1% |
出库门控(Checklist)——全部通过才能进入 B面车间:
- 真机安装运行无崩溃
- 无原模板残留(包名/图标/文案/图片)
- 代码变异后与同模板已出包相似度 < 30%
- 图片 EXIF 零残留 + 音频编码器标识已清除
- ZIP 条目时间戳已打散 + 条目顺序已随机化
- 签名证书 DN/有效期/序列号与已有包无关联
- 跨包指纹比对关联度 ≤ 1%
- 商店文案 NLP 相似度 < 40% + 隐私政策独立域名
🔮 B面车间
给干净的 A面包注入 B面能力。包含三层决策:判定层(展示 A 还是 B)、策略层(怎么切换)、加载层(B面内容怎么送达)。
详细策略清单见参考文档,蓝图只定义架构层级。
📥 原料
换皮车间产出的净化 AAB + 风险偏好 + 策略方案
📤 产出
完整的 A+B 成品包(判定层已部署 + B面可用 + 灰度验证通过)
三层架构详解
判定层 · 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 输出审核概率评分 | 非硬编码,平台改策略时 AI 自适应 |
策略层 · 7 种组合方案
策略分 9 层(正道→灰色→暗道→邪修→结构规避→物理信号→协议暗通道→AI对抗→生态寄生),详细清单见参考文档。以下为推荐组合。
| 风险偏好 | 策略思路 | 包体干净度 | 适用 |
| 保守 | 远程配置全局开关 + 后端灰度 | ★★★★★ | 长期运营 |
| 标准 | 多层渐进式(本地快判+云函数+灰度窗口) | ★★★★ | 行业常见 |
| 激进 | 云函数 AI + SSR 动态渲染 | ★★★★★ | 短期冲量 |
| 跳板 | A面包 + PWA/TWA 承载 B面 | ★★★★★ | 风险最低 |
| 生态联动 | TG Mini App 等第三方平台承载 | ★★★★★ | 脱离 Play 审核 |
| 物理信号 | 传感器快判 + 后台延迟确认 | ★★★★★ | 时间差消除误判 |
| AI 对抗 | 联邦学习模型 + 生成式动态 A面 | ★★★★★ | 对抗 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 → 80,000+ 账号批量封禁 + GenAI 辅助审核
趋势:从「审核时扫一次」→「上架后持续监控」。
出库门控(Checklist)——全部通过才能进入提包车间:
- B面代码变异后任意两包相似度 < 30%
- 判定逻辑不在包体内(零痕迹)
- 策略组合与同资质下其他包不同
- A面功能回归测试通过(无崩溃、无 UI 异常)
- B面核心功能端到端验证通过
- 灰度 5-10% 稳定运行 24h 无异常信号
- 紧急回退机制验证通过(一键切回纯 A面)
- 策略安全评估——当前策略未被 Google 最新检测能力覆盖
- Firebase/AdMob/GCF 项目独立(不与其他包共用)
📦 提包车间
把完整的 A+B 成品包送上 Google Play 并持续运营。绑定资质 → API 提交 → 14天测试 → 审核 → 上架 → 在线监控。
📥 原料
B面车间产出的成品包 + 账号车间的就绪资质
📤 产出
已上架且 B面正常的线上 App + 持续运营状态
提包流程
绑定资质账号▶
API 上传 AAB▶
填 Listing▶
14天封闭测试▶
提交审核▶
上架▶
在线监控
| 步骤 | 分散要求 |
| 绑定资质 | 通过对应资质的AdsPower环境操作——API 调用来源 IP 必须与资质绑定的住宅 IP 一致 |
| API 提交 | 用对应资质的 Service Account 调用 API,不能所有包用同一个 SA |
| 上传时间 | 随机延迟 1-7 天,不能批量集中上传 |
| 更新发版 | 不同包的更新时间随机打散 |
上架门控(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面用途/变异策略 |
绝对不能外包:接口契约设计、代码变异引擎、伪装加固、关联性检测、上架策略、判定架构——核心机密。
不是逐包看风险,而是整个包矩阵的风险敞口——一个关联暴露可能连锁击倒多少包。
| 风险 | 触发条件 | 爆炸半径 | 防御 |
| 构建指纹关联 | 二进制分析发现多包出自同一构建环境 | 全部包 | 换皮车间构建净化 |
| 账号关联暴露 | IP/设备/支付/手机号交叉 | 同资质 3-5 包 | 账号车间隔离检查 |
| 判定策略暴露 | Google 新增检测覆盖在用策略 | 同策略所有包 | B面车间策略多样化 |
| 品类集中度 | 单品类 > 总包量 30% | 该品类所有包 | A面车间品类分散 |
| 加载方式被检测 | Google 检测到 B面加载机制 | 同加载方式所有包 | B面车间加载方式多样化 |
| 政策收紧 | 平台更新政策 | 依赖该特性的包 | B面车间 Google 检测追踪 |
风险分散原则
- 资质分散——每套资质最多承载 3-5 个包
- 品类分散——单一品类不超过总包量的 30%
- 市场分散——覆盖 3+ 国家/地区
- B面方案分散——至少 3+ 不同平台实现方案
- 策略分散——同资质下不同包用不同策略组合
可交互原型,按车间分组,侧栏导航切换。每个车间对应角色只能看到自己车间的页面。
差异化覆盖全景——谁在哪一步管什么
| 差异化层面 | 🎮 A面车间 模板开发者 | 🎨 换皮车间 美工 | 🎨 换皮车间 AI 系统 | 🎨 换皮车间 构建净化 | 🔮 B面车间 |
| 代码架构 | ● | — | — | — | — |
| 引擎版本 | ● | — | — | ● | — |
| 目录/文件命名 | ● | — | ● | — | — |
| 代码风格 | ● | — | ● | — | — |
| 视觉素材 | — | ● | — | — | — |
| 配色/主题/游戏名 | — | ● | — | — | — |
| 游戏参数 | — | ● | — | — | — |
| 变量名/类名变异 | — | — | ● | — | — |
| 资源 ID | — | — | ● | — | — |
| 商店文案/翻译 | — | — | ● | — | — |
| 构建环境 | — | — | — | ● | — |
| 元数据/二进制特征 | — | — | — | ● | — |
| 签名证书 | — | — | — | ● | — |
| B面代码 | — | — | — | — | ● |
| 判定策略 | — | — | — | — | ● |
| 上传时间 | — | — | — | — | ● |
关键原则:差异化从源头(A面车间)开始。模板开发者交付的模板如果代码风格一致,后面的 AI 变异和构建净化能做的只是掩盖,不是根治。Google 做代码聚类分析时,底层架构相似度远比变量名更有权重。