📦 PackFactory | 📋 设计意图 📄 蓝图 🖥 原型 ⚠ 风险评估

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

小马整理

一、为什么要做这件事

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

AI 时代的变化：

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

二、规模化的商业逻辑

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

规模化的好处：

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

三、五车间流水线

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

🏢 账号车间

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

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

关键点：

🎮 A面车间

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

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

关键点：

🎨 换皮车间

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

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

关键点：

🔮 B面车间

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

谁干：B面工程师。

关键点：

📦 提包车间

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

谁干：运维。

关键点：

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

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

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

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

五、A面骨架验收标准——站在B面车间视角

A面不是独立产品，是让B面合理存在的载体。验收标准追求最小集合——限制越少，A面差异化空间越大。

底座是B面车间提供给A面使用的原生能力套餐。A面车间不需要知道底座为什么存在，按接口文档对接即可。

CABD 四类验收项（25项，硬性18项）：

交付物：工程源码 + config.template.yaml + MANIFEST.md + README.md。交付的是源码不是 APK，打包是B面车间的事。

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

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

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

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

七、面向投放团队的开放

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

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

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

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

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

八、过审之后的事

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

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

九、系统设计的核心原则

  1. 能程序化的全部程序化，能自动化的全部自动化。不能自动化的看成本和稳定性——成本低且稳定就用 AI Agent 处理，都不行才人工。
  2. 资产全生命周期管理——每个账号、每个模板、每个 IP、每个手机号，从入池到使用到废弃，全程记录。被标记为脏的资源永远不能再被分配。
  3. 分散是第一优先级——任何新功能上线前先问：这个东西是不是所有包共用的？如果是，怎么分散？
  4. 评分制而非通过制——一个包的风险不是某个环节决定的，是所有环节加权的结果。评分体系要贯穿整条流水线。
  5. 掉包后能反向追溯——包掉了之后，要能查出是哪个环节出了问题（是账号脏了？还是 A面被关联了？还是 B面策略暴露了？），然后把问题标记到对应的资产上，同批次连坐，防止后面的包再踩同样的坑。
  6. 验证驱动，不是设计驱动——任何设计假设在未经真实上架验证之前，都只是假设。不要把设计文档的完善等同于进度推进。越早用最小代价验证核心假设，越早知道哪些设计是对的、哪些需要修改。

十、这个系统到底在解什么题

A 面和 B 面不是这个系统要解的题。没有这个系统，A 面游戏照样做、B 面策略照样跑、包照样能提上去——手动就能干，而且已经在干。

这个系统要解的题是规模化：

系统提供三层价值：

  1. 核心层 · 规模化组织协同——多角色通过系统衔接，数据留存、规则校验、流程门控、交付标准全部系统化。这是系统的根本目标，让 1 个人管 100 套资质成为可能。
  2. 中间层 · 工程能力集成——构建编译隔离、资源净化处理、元数据清洗等技术环节系统化。本质是提效——手动也能做，系统做更快更一致。
  3. 外围层 · 外部服务集成——IP 采购 API、AdsPower 管理、Google Play API、邮箱监听等自动化。同样是提效——没有自动化可以人工操作，有了才能支撑规模。

十一、分阶段验证策略——不要一步到位

基于上述对抗性系统的本质，PackFactory 必须采用分阶段验证的推进方式，而不是做完所有功能再上线。

Phase 1 · 最小验证（1-2 周）

Phase 2 · 小规模验证（1-3 个月）

Phase 3 · 规模化（3-6 个月，取决于 Phase 2 结果）

关键认知：Phase 1 验证失败 = 整个模式的基本假设不成立。越早知道越好，只损失 1-2 周。最怕的是跳过验证直接做 6 个月的系统开发，然后发现假设不成立。

十二、系统工程风险全景

这个管理平台作为软件工程项目，面临 6 类核心风险：

  1. 🔴 跨车间状态一致性——评分、连坐、反向标记需要数据实时跨车间联动。一条资产变更要级联影响 4 个车间的数据。如果数据模型设计不当，核心功能不可用。
  2. 🔴 车间衔接失败——5 个车间并行开发但数据契约没定清楚，各自做完拼不起来。
  3. 🟠 规则引擎不可维护——80+ 条业务规则如果散落在代码各处，后期改不动、不敢改。
  4. 🟠 产品范围膨胀——37 页原型如果不分期，试图一次做完会导致开发周期无限拉长。
  5. 🟠 构建净化投入失控——中间层的技术挑战被低估，资源被吃掉，核心层进度受阻。
  6. 🟡 外部集成脆弱——12+ 个外部 API 依赖，任何一个变化都可能阻塞流水线。

完整的风险分析和分阶段实施建议见 docs/risk-assessment.md。