包工厂 · 业务全景与设计意图

小马整理

一、为什么要做这件事

以前一个团队 3-5 人，一周最多提 2-3 个包。瓶颈在三个地方：开发者账号准备太慢、A面精修太耗人、B面组装太依赖全栈工程师。

AI 时代的变化：

A面不用自己从零设计——互联网上有几十万款休闲游戏，爬下来改皮就能用。以前一个游戏要写一周，现在 AI 几小时就能把别人的游戏跑成高保真的本地工程。
技术栈差异化不用招人——一个「小鸡过马路」的游戏，用 20 种技术栈各写一遍，每个都是全新代码。以前需要 20 个不同方向的工程师，现在 AI 都能做。
系统能替代人的组织能力——账号管理、资源排重、差异化检查、提包调度——以前全靠人记、人查、人判断，现在做成系统，一个运营就能管 100 套资质。

所以核心目标是：把月产能从 2-3 个包提升到 30-50 个包，同时保证每个包的质量（代码无关联、账号干净、过审率高）超过行业平均水平，在这个基础之上最大程度追求包数量的规模化，也就是各个车间衔接后的生产效率的最大化及效率同频，避免出现阻塞和等待。

二、规模化的商业逻辑

一个包很难稳定在线两年——同行投诉、用户投诉、Google 风控收紧，随时可能掉包。所以不能押在少数几个包上。

规模化的好处：

均摊风险——100 个包在线，掉 30 个还有 70 个。不会因为一个包掉了就断收入。
新包红利——每个新包在 Facebook 投放时有新手期流量红利，CPI 便宜。包越多，吃到的红利越多。
抢占用户屏幕——用户手机上装了 10 个同类 App，如果 7 个是我们的，他大概率在我们的 App 里消费。无形中挤掉了竞品的屏幕时间。
投放团队自驱——开放换皮车间给合作的投放团队，他们的美工自己做 A面——他们比我们更懂什么品类在什么市场有流量，什么视觉风格吸引目标用户。

三、五车间流水线

一个包从无到有经过五个车间，每个车间有独立的工人、原料、产出和验收标准。

🏢 账号车间

干什么：生产「上架资格」——一套完全独立的身份 + 开发者账号 + 隔离环境。

谁干：资质专员（专人，人工为主）。

关键点：

个人账号和企业账号都要做，企业账号需要 LLC + EIN + DUNS。
每套资质的手机号、信用卡、IP、邮箱、设备指纹必须完全独立——不是逻辑上独立，是物理上独立。
IP、手机号、信用卡这些可以通过三方平台 API 批量采购入池（Bright Data、5sim、SMS-Activate 等），这个环节可以靠系统，但入池后必须自动排重——不能复用以前用过的、被标记为脏的资源。
Ads Power 这类指纹浏览器的新增和配置及环境组装环节可以靠系统，同时可以长期维护管理，可以方便的废弃及了解哪些需要续费，但配置后的打开及访问使用，需要靠个人操作。
账号做完后要在 Google Cloud 把 API 权限配好（Service Account + API Key），后面提包车间通过 API 提交，不用人登录 AdsPower 去手动操作。
14 天封闭测试是硬约束——新账号首个 App 必须 20 人测试 14 天才能正式发布。
账号制作过程中会出错（IP 坏了换新的、信用卡被拒换一张、证件照模糊重拍），这些失误会降低账号的可信度——所以交付时要有验收标准和评分。制作过程的失误会留痕——换过几次 IP？信用卡被拒过几次？证件传错过吗？这些都是减分项。更严重的是：如果事后发现某批 IP 是脏的/被关联过的，那整批用了这些 IP 注册的号都不能再用——必须批量标记为高风险或直接废弃。
系统要能帮资质专员管好这些资产：哪些需要续费、哪些可以清退、哪些以前用过不能再用。

🎮 A面车间

干什么：生产「游戏模板」——从互联网爬取休闲游戏，跑成本地可运行的工程，参数化后入库。

谁干：模板开发者（可以是一个人+AI）。

关键点：

不需要自己想游戏创意——互联网上有几十万款 Cocos/Pixi/Canvas/Three.js 的休闲游戏，爬下来就是。
爬下来后要做的事：跑成本地工程 → 可 AI 转换技术栈 → 参数化（可换皮的部分抽成配置项）→ 去除所有个人痕迹 → 入库。
一个游戏可以用 20 种技术栈各写一遍——JS/Cocos/Pixi/Three.js/Unity/Godot/Flutter/RN... 每种技术栈出来的代码完全不同，Google 做代码聚类分析时认为是不同的游戏。
模板入库有标准：完整可玩、参数化完整、代码风格与已有模板不同、无个人痕迹、无崩溃、无异常日志、无本机电脑个人文件特征、无外部 CDN 引用、体积合理、可替换素材的位置和名称要有说明文档、原有的归因 SDK 和广告 SDK 必须剔除干净、不能残留原游戏网站的任何域名或接口引用。不达标的工程不允许进入模板市场被美工选中。
模板有疲劳度——同一个模板用了 5～10 次后，不管怎么变异，底层骨架还是一样的。系统要追踪每个模板的剩余变种空间，饱和了就要开发新模板，以及基于分散风险也不建议用在太多个包，防止连坐。
模板还要包含一套可替换的 Icon、五图、截图模板——这些是后面美工换皮时要提供的。

🎨 换皮车间

干什么：把模板变成一个个独立的成品包。

谁干：美工（可以是合作的投放团队的美工）+ AI 系统。

关键点：

美工进系统后，在 A面模板市场里挑模板 → 换素材（图片/配色/音效/文案）→ 做 Icon 和五图 → 调游戏参数 → 提交。
美工提交后，系统自动：代码变量名变异 → 资源 ID 扰动 → 商店文案差异化生成 → 多语言翻译 → 构建编译 → 5 层自动质检 → 构建净化（消除构建环境指纹）→ 产出干净的 AAB。
换皮不是只换图片——如果美工只换了个颜色就提交，系统要能检测出来并打回。系统要做 AI 视觉对比，比对换皮前后的 UI 截图，颜色/布局/交互太相似就直接拒掉打回重做。即便下载到本地改个文件名再传回来也不行。
换皮车间是速度最快的车间（AI 驱动，几小时出一个包），但不能无限出——要看提包车间能消化多少，否则积压。
投放团队的美工可以直接用这个系统——他们比我们更懂什么品类有流量、什么视觉风格吸引用户。他们做出来的 A面包，后面由我们的 B面车间和提包车间处理。

🔮 B面车间

干什么：给干净的 A面包注入 B面能力。

谁干：B面工程师。

关键点：

B面工程师提前准备多种「组装方案」——不同的判定策略 × 不同的加载方式 × 不同的 B面代码实现。美工换皮出来的 A面包，套到某个方案上就变成了最终的 A+B 成品。
A面和 B面之间要有规范——否则每个模板都不一样，B面方案对接不起来。
组装后要做：混淆 → 垃圾代码注入 → 构建编译 → 归因 SDK 集成 → 广告 SDK 集成 → AB 通信协议对接。
理想情况下组装是全自动的。但实际上有些包可能兼容性有问题需要人介入修复——能用 AI 修就用 AI，AI 修不了才人工。
B面的接口部署也要分散——不能所有包都调同一台服务器。要用 CF Worker / Google Cloud Functions / AWS Lambda 等多家分散部署。
组装完成后的包要有一套增量累加制的综合评分——不是在 B面这一步单独打分，而是从账号车间开始，每个环节各自有分（IP 是否被关联过、A面模板已被用过几次、信用卡卡段是否与其他包重复、代码相似度...），前面所有环节的分一路带下来到 B面组装完成时汇总。评分太低的包不应该提交，因为它不仅自己过不了审，还会因为关联性污染已经在线的包。

📦 提包车间

干什么：把成品包送上 Google Play。

谁干：运维。

关键点：

提包通过 Google Play Developer API 完成——不需要人登录 Play Console 手动操作。账号车间已经把 Service Account 和 API Key 准备好了。
但是 API 调用的来源 IP 也是关联维度——不能用同一台服务器调 100 个账号的 API。每个账号的 API 调用要通过对应资质的隔离环境（CF Worker / 各家 Serverless）转发，确保来源 IP 与资质绑定的 IP 一致。
需要对接 7-8 家不同的 Serverless/服务器厂商做 API 转发——阿里云 FC、Google Cloud Functions、AWS Lambda、CF Worker、还有一些小厂商。分散。
提包时间要打散——不能 10 个包同一天提交。每天上限不超过可用资质数的 10%。
提上去有三种策略：① 先提白包（纯 A面），过审后更新加 B面 ② 直接提 A+B，靠判定策略控制 B面展示 ③ A面包里不含 B面代码，通过动态加载/热更注入。
提包后的跟踪：通过 API 查审核状态，或者通过邮箱监听审核邮件通知（邮箱也要做分散转发，不能所有账号的通知都转到同一个邮箱）。
审核被拒后的处理：分析被拒原因 → 反馈给对应车间（是 A面问题就反馈给换皮车间，是关联性问题就反馈给账号车间）→ 等 7 天后重提。
提包前要有最终复审——由人或 AI 做最后一轮检查：提包过程有没有失误？综合评分是否达标？过审希望大不大？如果希望不大，可能要决定放弃这个包加快做新的，而不是硬提上去浪费资质。
过审后还有事：配置 Facebook 广告归因、开 B面开关、通知投放团队可以投放了、提供 APK 给投放团队录制素材视频（注意这个 APK 不能有特征，要跟线上包隔离。包 ID 用一个在架包的 ID——防止 Google 远程铲除用户手机上的本地 APK）。

四、分散——贯穿全部车间的设计铁律

Google 能关联两个包的维度有几十种。任何「多个包共用同一个 X」的地方都是关联风险。

分散不是某几个点的隔离措施，是渗透到每个环节的设计哲学：

账号车间：身份/公司/手机号/信用卡/IP/邮箱/域名/设备指纹/域名注册商——全部分散
A面车间：代码架构/引擎版本/目录结构/代码风格/第三方 SDK 接入方式——全部分散
换皮车间：素材来源（多个 AI 模型轮换）/商店文案风格/截图模板/构建环境/签名证书——全部分散
B面车间：判定策略/加载方式/B面代码实现/GCP 项目/CF 账号/B面域名——全部分散
提包车间：API 调用来源 IP/上传时间/更新频率/Serverless 厂商——全部分散

按批次做分散是现实的妥协——不可能每个包都 100% 独立（成本太高）。但每批 3-5 个包之间特征相近，批与批之间差异要大。所有批次加在一起，有共同特征的包数量交叉要尽量少。

五、检查与评分——流水线上的硬门控

每个车间的出口都有验收标准，不通过就不允许进入下一车间。

验收不只是「通过/不通过」——到了 B面组装完成时，应该有一个增量累加制的综合评分，把前面所有环节的风险因素加权汇总。评分太低的包不应该提交——因为它不仅自己过不了审，还会因为关联性污染已经在线的包。这是比单个包被拒更严重的后果。

事后反向标记：包掉了、被投诉了、被关联了——不管怎么发现的，都要能反向追溯到所有车间的资产打标记。关键原则是同批次连坐——一个 IP 出问题，同批次采购的 IP 全部标记待排查；一个模板出问题，用这个模板做的所有包都要重新评估。这些标记实时反映到系统中，下次有人选用这些资产时自动拦截或警告。

六、面向投放团队的开放

这个系统不只是内部用——要开放给合作的投放团队的美工。

他们登录后只看到换皮车间的页面：

从模板市场选 A面模板
换皮（图片/配色/参数/文案/Icon/五图）
提交后跟踪进度（制作中 → 检查 → 通过 → 提审 → 上架）
看到自己做的包有没有过审、有没有掉包、评分多少

他们不需要看到账号车间、B面车间、提包车间——这些是我们内部的事。

他们还需要看到跟投放节奏相关的数据：广告数据（来自 AppsFlyer/Adjust/自归因）跟包关联后的粗指标（CPI、D1 留存、收入），帮他们决定啥时候开、啥时候关、啥时候扩量。竞品数据也要在系统中体现。

他们为什么要用这个系统而不是自己做？因为：

他们没有账号资源（我们有）
他们没有 B面技术能力（我们有）
他们没有规模化提包的基础设施（我们有）
他们有的是流量感知力和美工能力——正好是换皮车间需要的

七、过审之后的事

包过审上架不是终点，还有一系列对接工作：

投放对接：把商店链接给投放团队 → 开 Facebook 广告户 → 配置归因（AppsFlyer/Adjust/自归因）→ 替换应用内的 Facebook pixel ID 和开发者 ID
B面开关：根据当前风控环境决定何时开 B面——高风险期关闭，低风险期开启。需要在服务端做开关控制。
投放素材：给投放团队提供录屏用的 APK（不能有特征，不能被 Google 关联到线上包）。
掉包监控：通过服务端日志分析 Google 审核爬虫的 IP/UA，区分正常审核、竞品恶意举报、掉包前的二次审核。IP 情报依赖自营数据库（日志沉淀，成本低）和外部 IP 服务 API（实时性好）两条线，查询结果统一沉淀。
落地页：如果 Facebook 封了包链接但 Google Play 还在架，就需要落地页做中转——落地页引导下载 → 包里读取剪贴板的归因参数 → 完成自归因。

八、系统设计的核心原则

能程序化的全部程序化，能自动化的全部自动化。不能自动化的看成本和稳定性——成本低且稳定就用 AI Agent 处理，都不行才人工。
资产全生命周期管理——每个账号、每个模板、每个 IP、每个手机号，从入池到使用到废弃，全程记录。被标记为脏的资源永远不能再被分配。
分散是第一优先级——任何新功能上线前先问：这个东西是不是所有包共用的？如果是，怎么分散？
评分制而非通过制——一个包的风险不是某个环节决定的，是所有环节加权的结果。评分体系要贯穿整条流水线。
掉包后能反向追溯——包掉了之后，要能查出是哪个环节出了问题（是账号脏了？还是 A面被关联了？还是 B面策略暴露了？），然后把问题标记到对应的资产上，同批次连坐，防止后面的包再踩同样的坑。