# PackFactory 系统工程风险评估报告

> **评估人**：小马（CTO 参谋长）
> **评估日期**：2026 年 7 月 26 日
> **评估依据**：蓝图全文 + 原型 37 页 + 历史设计决策记录
> **评估视角**：这个管理平台作为软件工程项目的交付风险
> **文档用途**：供 A 面 / B 面车间及全体参与者阅读，提前认知系统建设的难点和可能做砸的原因

---

## 零、定位校准——这个系统到底在解什么题

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

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

- 靠人管 5 个包可以，管 50 个包就管不住了
- 哪些 IP 用过了？哪个模板该停了？这个包评分够不够格提审？哪个车间卡住了下游在等？
- 没有系统，这些全靠人记、人查、人判断——量上去就会漏、会错、会乱

**系统的三层价值**：

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

**所以本文评估的不是"Google 会不会封你"，而是"这个平台作为软件工程项目能不能做出来、会在哪里做砸"。**

---

## 一、系统复杂度全景——你要造的东西有多大

### 1.1 业务实体与数据模型

从蓝图和原型中提取的核心业务实体：

| 编号 | 实体 | 所属车间 | 复杂度说明 |
|------|------|---------|-----------|
| E1 | 资质（Qualification） | 🏢 账号 | 最复杂的实体——包含身份、公司、账号、凭证、隔离环境、14 天测试状态，每个字段都有独立的生命周期 |
| E2 | 自然人身份 | 🏢 账号 | 证件、地址、手机号、邮箱，与资质 1:1 绑定 |
| E3 | 公司/LLC | 🏢 账号 | 执照、EIN、DUNS，独立生命周期（年审、续费） |
| E4 | 资源池资产（IP/手机号/信用卡/邮箱/域名/环境） | 🏢 账号 | 多种资产类型 × 统一生命周期（入池→分配→使用→变更→废弃） × 批次管理 × 变更标签 × 连坐 |
| E5 | 游戏模板 | 🎮 A面 | 工程文件 + 参数化配置 + CABD 验收 25 项 + 疲劳度/变种空间 + 多技术栈标签 |
| E6 | 换皮任务 | 🎨 换皮 | 从选模板到出 AAB 的全流程工单，含素材上传、参数配置、AI 组装、5 层质检、构建净化 |
| E7 | 成品包 | 🔮 B面 + 📦 提包 | 贯穿全流水线的核心产物，汇聚所有上游评分 |
| E8 | B 面方案 | 🔮 B面 | 判定架构 × 策略组合 × 加载方式 × 代码实现，方案库管理 |
| E9 | 综合评分 | 全局 | 5 维度加权，增量累加，跨车间数据汇聚 |
| E10 | 风险标记 | 全局 | 多种资产类型 × 多种标记原因 × 同批次连坐传播 |
| E11 | 审核记录 | 📦 提包 | Google 审核状态流转 + 邮件解析 + 被拒原因分类 |
| E12 | 投放数据 | 全局 | 对接 Facebook Ads / AppsFlyer / AdMob，按包维度聚合 |
| E13 | 风控规则库 | 全局 | 审核 IP 库、UA 库、高危操作库、安全窗口库、竞品情报 |

**共计约 24 个独立业务实体**（含 16 个核心实体 + 8 个辅助实体），实体间呈复杂网状关系。这不是一个简单的 CRUD 系统。实体之间存在大量**跨车间级联关系**——一个 IP 被标脏，要级联影响使用该 IP 的资质，再级联影响该资质下的所有包的评分。一个模板疲劳度超标，要级联阻止所有新换皮任务选用该模板。

### 1.2 状态流转

每个包从无到有经过 5 个车间，每个车间内部又有多步流转：

**正常流**（主路径）：
```
资质准备(6步) → 入库 → 模板开发(多步) → 入库 → 换皮(选模板→换素材→AI组装→5层质检→构建净化) → 入库 → B面组装(7步) → 入库 → 提包(绑定→上传→14天→审核→上架→监控)
```

**打回流**（每个门控都可能触发）：
- 资质验收不通过 → 打回重做
- A 面 CABD 验收不通过 → 打回（可能只打回一项，也可能打回全部）
- 换皮质检不通过 → 自动修复 → 重检 → 仍不通过 → 打回美工
- 构建净化验证不通过 → 重新净化
- B 面组装兼容性问题 → AI 修复 → 仍不行 → 人工介入
- 综合评分 < 60 → 直接终止，打回上游
- 综合评分 60-80 → 人工复核决定
- 审核被拒 → 分析原因 → 反馈给对应车间 → 等 7 天 → 重提

**异常流**（事后触发）：
- 掉包 → 反向追溯 → 标记所有关联资产 → 同批次连坐排查
- IP/资产被发现是脏的 → 同批次全部标记 → 使用该资产的资质和包全部重新评估
- Google 政策变化 → 所有受影响的 B 面方案降级 → 使用该方案的包全部切回 A 面

**状态流转路径总量约 63 条**（正常流 33 条 + 打回/重试流 18 条 + 异常/降级流 12 条）。不是线性流水线，是一张有大量回边和跨车间跳转的有向图。任何一个门控节点都可能把工件打回上游甚至打回源头，打回的同时还要更新评分、标记资产、通知相关角色。

### 1.3 规则引擎复杂度

从蓝图中提取的规则类型：

| 规则类别 | 规则数量 | 复杂度 |
|---------|---------|--------|
| 资质出库门控 Checklist | 7 项 | 每项都需要独立的验证逻辑，其中"AI 关联性扫描"本身就是一个子系统 |
| A 面 CABD 验收标准 | 25 项（C8+A7+B3+D7） | 部分可自动化验证，部分需人工判断 |
| 换皮出库门控 Checklist | 8 项 | 含代码相似度检测、EXIF 扫描、跨包比对 |
| 构建净化验证 | 8 层 × 每层多项 | 含字符串扫描、EXIF 扫描、跨包比对、工具链版本不一致确认 |
| B 面出库门控 Checklist | 9 项 | 含策略安全评估、灰度验证 |
| 提包上架门控 Checklist | 6 项 | 含 IP 一致性检查、代码相似度检测 |
| 增量评分引擎 | 5 维度 × 每维度多项 | 跨车间数据汇聚，实时计算 |
| 硬拦截规则 | 3 级阈值 | 依赖评分引擎输出 |
| 模板疲劳度 | 3 级阈值 + 变种空间计算 | 需要跨包统计同模板已出包数和差异度 |
| 资产变更标签 | 6 种标签 + 评分影响规则 | 每种标签有独立的触发条件和影响逻辑 |
| 批次连坐规则 | 级联传播逻辑 | 一个资产被标脏 → 同批次全部标记 → 级联到资质 → 级联到包 |
| 反向标记规则 | 掉包后多维度追溯 | 从包反向追溯到所有车间的所有资产 |
| 提包分散规则 | 4 条约束 | 时间间隔、每日上限、14 天窗口排布、重提间隔 |
| 风险分散规则 | 5 条 | 资质挂包上限、品类集中度、市场分散、方案分散、策略分散 |

**规则总量**：约 119 条独立规则（评分 16 + 连坐 4 + 反向标记 4 + 疲劳度 3 + 门控检查 55 + 告警 12 + 分散检查 21 + 提包约束 4）。这些规则之间存在依赖关系（评分依赖标签，标签依赖变更，变更依赖资产状态），构成一个规则网络而非规则列表。

### 1.4 外部集成点

| 集成目标 | 协议/方式 | 复杂度 |
|---------|----------|--------|
| IP 采购（Bright Data / IPRoyal 等） | REST API | 中——多家供应商 API 不统一 |
| 手机号采购（5sim / SMS-Activate） | REST API | 中 |
| AdsPower 环境管理 | AdsPower API + CDP | 高——需要创建/配置/启动/维护浏览器环境 |
| Google Play Developer API | REST + OAuth2 | 高——edits → bundles → listings → tracks → commit 多步事务 |
| 邮箱监听（IMAP/API） | IMAP + 邮件解析 | 中——需解析 Google 通知邮件格式，格式可能变化 |
| Firebase Remote Config | REST API | 低 |
| Serverless 部署（7-8 家厂商） | 每家不同的 CLI/API | 高——要维护 7-8 套部署适配器 |
| 投放数据（Facebook Ads / AppsFlyer / Adjust） | REST API + Webhook | 中——数据模型对齐 |
| AdMob / Unity Ads 收入 | REST API | 低 |
| AI 视觉对比（换皮相似度检测） | ML 模型调用 | 高——需要训练或调用视觉相似度模型 |
| 代码相似度检测 | 工具/算法 | 高——需要跨包的代码聚类分析 |
| NLP 文案相似度检测 | 工具/算法 | 中 |

**集成总量**：16 类外部集成点，涉及 30+ 个具体服务商。其中 AdsPower、Google Play API、Serverless 多厂商适配是高复杂度集成。

### 1.5 构建净化流水线（中间层）

这是一个嵌入在换皮车间中的独立子系统：

```
独立 Docker 容器启动 → 工具链版本随机选择 → 源码编译 → 元数据清洗(EXIF/音频/字体) 
→ 二进制特征随机化(ZIP顺序/时间戳/padding) → 独立签名 → 净化验证(跨包比对) → 出库
```

技术需求：
- Docker 容器编排（每包独立容器，构建完销毁）
- 多版本工具链管理（Godot/Gradle/NDK 版本池）
- 二进制处理工具（exiftool、音频重编码、ZIP 操纵、.so 填充）
- 签名管理（每包独立 keystore 生成，DN/有效期随机化）
- 跨包指纹比对（抽样比对，计算关联度）

**这本身就是一个中等复杂度的独立项目。**

### 1.6 多角色权限模型

| 角色 | 可见范围 | 可操作范围 |
|------|---------|-----------|
| 资质专员 | 账号车间全部 | 资质管理、资源池管理 |
| 模板开发者 | A 面车间全部 | 模板上传、验收 |
| 美工（内部） | 换皮车间全部 | 选模板、换皮、提交 |
| 美工（外部投放团队） | 换皮车间受限 + 自己的数据 | 只看模板市场、只操作自己的换皮任务、看自己包的投放数据 |
| B 面工程师 | B 面车间全部 | 方案管理、组装、策略配置 |
| 运维 | 提包车间全部 | 提包、审核跟踪、监控、应急 |
| 管理员 | 全部 | 全局看板、风险矩阵、跨车间协调 |

**约 50+ 个独立权限检查点。权限不只是页面级别的显示/隐藏**——同一个"模板市场"页面，内部美工能看到模板源码细节，外部美工只能看到可用信息。同一个"投放数据"页面，外部团队只看到自己提交的包。数据级权限控制比页面级复杂得多。

### 1.7 复杂度对标

这个系统的技术复杂度相当于**四个中型系统的组合**：

| 子系统 | 对标 | 对应部分 |
|--------|------|---------|
| 管理后台 | 中型 ERP | 37 页面、24 实体、7 角色权限 |
| 构建净化 | 专用 CI/CD 平台 | Docker 编排、多工具链、8 层清洗 |
| 规则引擎 | 金融风控系统 | 119 条规则、连坐、反向标记、增量评分 |
| 外部集成 | 集成中间件 | 30+ 服务商对接 |

---

## 二、核心难点分析

### 难点 H1：跨车间状态一致性——最核心的架构挑战

**问题本质**：5 个车间各自管各自的数据，但评分、标记、连坐要求数据实时跨车间联动。

举例：
- 账号车间发现一个 IP 是脏的 → 要立即影响到使用该 IP 的资质的评分 → 要立即影响到该资质下所有包的综合评分 → 综合评分低于 60 的包要被从提包队列中拦截
- 一条变更（标脏一个 IP）触发了跨 4 个车间的级联更新

**如果处理不好**：
- 评分数据不一致——包的评分没有及时反映上游资产的变化，低分包漏过门控
- 连坐不彻底——同批次资产没有全部被标记，遗漏的脏资源继续被分配
- 反向标记丢失——掉包后追溯链断裂，找不到根因

**技术挑战**：
- 是用事件驱动（异步级联）还是实时计算（每次查询重新计算）？
- 事件驱动的一致性保证怎么做？级联失败怎么回滚？
- 实时计算的性能怎么保证？100 套资质 × 每套 3-5 包 × 5 维度评分 × 每次资产变更都重算？

### 难点 H2：规则引擎的可维护性——80+ 条规则的管理

**问题本质**：规则不是写死的——Google 检测能力在进化，评分权重要校准，阈值要调整，门控标准要升级。

**如果处理不好**：
- 规则散落在代码各处，改一条规则要翻遍整个代码库
- 规则之间的依赖关系不透明——改了一条评分规则，不知道会影响哪些门控
- 规则的版本管理——某个时间点的规则配置是什么？回滚到某个版本？
- 新增规则类型——蓝图写的是现在能想到的规则，实际运营中一定会发现新的需要管控的维度

**技术挑战**：
- 是把规则做成可配置的引擎，还是硬编码在业务逻辑中？
- 规则引擎做重了，开发成本翻倍；做轻了，后期改不动
- 规则的测试怎么做？80 条规则的组合爆炸

### 难点 H3：构建净化流水线——一个嵌套的独立工程

**问题本质**：这不是调几个 API 的事，是一个涉及 Docker 编排、多语言工具链、二进制处理的基础设施项目。

**如果处理不好**：
- 净化流水线不稳定——容器启动失败、工具链版本冲突、编译报错
- 净化不彻底——遗漏了某个元数据字段
- 净化过度——破坏了包的功能
- 跨包比对工具误报/漏报

**技术挑战**：
- 要支持多种引擎（Godot/Cocos/Unity）的构建流程，每种引擎的构建方式完全不同
- Docker 容器的启动和销毁性能——每包一个容器，构建完销毁
- 二进制操纵工具的开发——ZIP 条目重排、.so padding 填充不是现成的工具
- 跨包指纹比对算法的选择和调优

### 难点 H4：外部集成的脆弱性——12+ 个外部依赖

**问题本质**：每个外部 API 都是一个不可控的依赖。API 变了、限流了、挂了、改认证方式了——任何一个都可能阻塞流水线。

**如果处理不好**：
- 某个 IP 供应商 API 格式变了，采购流程全线停工
- Google Play API 限流，提包积压
- AdsPower 升级了 API 版本，环境管理失败
- 邮箱监听的 Google 通知邮件格式变了，审核状态不同步

**特别是 7-8 家 Serverless 厂商的适配**——每家的部署 API、认证方式、资源模型都不同。要维护 7-8 套适配器，任何一家改了 API 都要跟着改。这个维护成本容易被低估。

### 难点 H5：产品设计的取舍——37 页原型不等于 37 页都要做

**问题本质**：原型展示的是理想状态。如果每一页都要做到原型展示的完成度，开发量会远超预期。

**需要回答的关键问题**：
- 37 页中哪些是 Day 1 必须有的？哪些是有了更好的？哪些是规模化之后才需要的？
- 风险矩阵页面需要什么程度的可视化？爆炸半径分析是手动还是自动？
- 投放数据集成是 Day 1 就做还是等包上架后再做？
- 外部投放团队的开放是 Day 1 就做还是内部跑通后再开放？

**如果不做取舍**：
- 试图一次性做完所有功能，每个功能都做到 80% 但没有一个能用
- 开发周期拉长到 6 个月以上，期间业务需求还在变化，做完就过时

### 难点 H6：实时性与用户体验的平衡

**不同功能对实时性的要求差异巨大**：

| 需要实时 | 需要准实时 | 可以批量/异步 |
|---------|-----------|-------------|
| 评分门控拦截 | 缓冲池水位监控 | 投放数据聚合 |
| 资产变更级联 | 审核状态同步 | 跨包指纹比对 |
| 连坐标记传播 | 到期提醒 | 风控规则库更新 |
| | 告警通知 | 掉包归因分析 |

**如果不区分**：
- 全做实时——系统复杂度翻倍，性能压力大
- 全做异步——门控拦截延迟，脏资产漏过去

---

## 三、失败模式分析

如果这个系统做了很久做不出来或做出来不好用，最可能的原因：

### 失败模式 F1：架构过度设计——用做 ERP 的方式做 MVP

**触发条件**：一开始就想做完美的规则引擎、完整的事件驱动架构、全部 12 个外部集成。

**演进路径**：
1. 花 2 个月搭基础架构——事件总线、规则引擎框架、微服务拆分
2. 再花 2 个月做第一个车间——账号车间
3. 发现架构和实际业务场景不匹配，推翻重来
4. 6 个月过去了，一个完整的车间都没跑通

**根因**：系统的复杂度来自业务规则的组合爆炸，不是来自技术难度。用过度的架构设计去应对业务复杂度，反而增加了交付难度。

**正确做法**：先用最简单的技术方案（甚至是数据库 + 硬编码规则）跑通一条完整的流水线，再根据实际痛点决定哪里需要做引擎、哪里需要做抽象。

### 失败模式 F2：车间并行开发但无法衔接

**触发条件**：5 个车间分给不同团队/Agent 并行开发，但没有先定义清楚车间之间的数据契约。

**演进路径**：
1. 账号车间做了一套资质数据模型
2. 提包车间做了另一套资质数据模型
3. 两边对接时发现数据模型不兼容
4. 花大量时间做数据迁移和接口适配
5. 或者更糟——各自的数据模型都无法适配"跨车间评分"的需求

**根因**：这个系统的核心难点不在单个车间内部（每个车间单独看都是标准 CRUD + 流程管理），而在车间之间的数据流转和规则联动。如果不先解决跨车间的数据模型和状态机设计，各车间独立做得再好也拼不起来。

### 失败模式 F3：构建净化做成黑洞——投入无底洞

**触发条件**：构建净化流水线的技术挑战被低估，投入了过多资源但产出不稳定。

**演进路径**：
1. 花 1 个月做了 Docker 容器化构建
2. 发现每种引擎的构建方式完全不同，要分别适配
3. 元数据清洗工具不断发现新的遗漏字段
4. 跨包比对算法误报率高，不断调优
5. 净化流水线成了一个需要专人维护的独立系统

**根因**：构建净化是一个"做到 80% 容易，做到 99% 极难"的问题。前几个清洗步骤能覆盖大部分指纹，但最后几个百分点的净化需要深度的二进制分析能力。

**正确做法**：Phase 1 先手动执行核心净化步骤（EXIF 清除、路径清理、独立签名），验证这些基础净化是否足够。只有在发现确实需要更深度的净化时，才投入做自动化工具。

### 失败模式 F4：规则硬编码后改不动

**触发条件**：把 80+ 条规则全部写在业务代码里，没有做任何抽象。

**演进路径**：
1. 第一版做完了，规则都跑通了
2. 实际运营后发现：评分权重需要调、阈值需要改、需要新增规则
3. 每次改规则都要改代码、发版、部署
4. 改出 bug 的概率越来越高——改了 A 规则影响了 B 规则
5. 最终没人敢改规则，系统变成僵化的流程

**根因**：规则的变化速度远快于代码的发布速度。业务规则应该和代码解耦。

**但也不能走另一个极端**——不要在 Day 1 就做通用规则引擎。先把规则集中管理（配置文件 / 数据库表），而不是散落在代码各处，就已经解决了 80% 的问题。

### 失败模式 F5：外部集成做太多太早

**触发条件**：Day 1 就想对接全部 12+ 个外部系统。

**演进路径**：
1. 花 3 周对接 IP 采购 API + AdsPower API + Google Play API + 3 家 Serverless
2. 发现每个 API 都有各自的坑——限流、鉴权、格式差异
3. 维护 6 个外部集成的成本吃掉了做核心功能的时间
4. 某个 API 变了，集成断了，流水线停工

**正确做法**：Day 1 只做对接系统核心功能必须的集成。IP 采购和 AdsPower 可以先手动操作后录入系统；Serverless 部署先只对接 1 家；邮箱监听可以先用人工查看后手动更新状态。等核心流程跑通了再逐步加自动化。

### 失败模式 F6：产品需求持续膨胀

**触发条件**：在开发过程中不断发现"还需要这个功能""还需要那个页面"。

**演进路径**：
1. 开始做账号车间，做到一半发现"还需要一个采购审批流程"
2. 做换皮车间，发现"AI 视觉对比需要训练数据"
3. 做全局看板，发现"缓冲池水位需要预测模型"
4. 每个发现都是合理的需求，但加在一起就是无限膨胀

**根因**：蓝图写得太完整了。37 页原型覆盖了所有能想到的场景，但没有明确哪些是 MVP、哪些是 V2、哪些是远期。

---

## 四、关键决策点——在写第一行代码之前

| 编号 | 决策 | 影响 | 建议 |
|------|------|------|------|
| D1 | 技术栈选择（前端/后端/数据库） | 决定开发效率和团队匹配度 | 用团队最熟悉的栈，不要为了这个项目学新框架 |
| D2 | 先做哪个车间？ | 决定第一个可用版本的形态 | 先做贯穿全流程的最短路径（账号管理 → 换皮 → 提包），而不是把某一个车间做到极致 |
| D3 | 跨车间数据模型怎么定？ | 这是整个系统的骨架 | **必须第一步定义**——实体关系图 + 状态机 + 核心字段，所有车间按这个契约开发 |
| D4 | 规则怎么管理？ | 决定后期的可维护性 | 第一版把规则集中在配置文件 / 数据库表中，不散落在代码里；不需要 Day 1 做规则引擎 |
| D5 | 构建净化做到什么程度？ | 决定中间层的投入 | Phase 1 手动 + 脚本，Phase 2 半自动化，Phase 3 才做完整流水线 |
| D6 | 外部集成的优先级？ | 决定外围层的投入 | Day 1 只做 Google Play API（核心必须）；IP 采购/AdsPower/邮箱监听 Phase 2 再做 |
| D7 | 37 页原型的分期？ | 决定产品的交付节奏 | 需要明确 MVP / V2 / V3 各包含哪些页面 |

---

## 五、建议的实施路径

### Phase 1 · 最小可用系统（4-6 周）

**目标**：一条能跑通的流水线，支撑 5-10 个包的管理。

**做什么**：
- 统一数据模型设计（资质、模板、包、评分——核心 4 个实体）
- 账号车间：资质管理 + 资源池（手动录入，不做 API 采购）
- A 面车间：模板上传 + CABD 验收 Checklist（人工勾选）
- 换皮车间：任务管理 + 素材上传 + 状态流转（构建净化用脚本，不做自动化流水线）
- 提包车间：Google Play API 对接 + 审核状态管理（邮箱先人工查看）
- 评分系统：简化版（只做关键几个维度，硬编码权重）
- 管理看板：1 个全局看板页面（不做 37 页全部）

**不做什么**：
- ❌ AI 视觉对比
- ❌ 代码相似度检测引擎
- ❌ 7-8 家 Serverless 适配
- ❌ 外部投放团队开放
- ❌ 投放数据集成
- ❌ 风控规则数据库
- ❌ 完整的构建净化自动化流水线

### Phase 2 · 强化核心能力（2-3 个月）

**目标**：支撑 30-50 个包的管理，核心自动化到位。

**做什么**：
- 外部集成：IP 采购 API、AdsPower 管理、邮箱监听
- 构建净化半自动化（Docker 容器 + 脚本，不做完整流水线 UI）
- 评分引擎可配置化（权重、阈值从配置读取）
- 连坐 + 反向标记自动化
- 补充剩余页面（告警记录、应急响应、掉包分析）

### Phase 3 · 规模化与开放（3-6 个月）

**目标**：支撑 100+ 个包，开放给外部团队。

**做什么**：
- 外部投放团队权限和页面
- 投放数据集成
- 完整的构建净化自动化流水线
- 风控规则数据库
- AI 视觉对比 / 代码相似度检测
- 7-8 家 Serverless 全适配

---

## 六、风险矩阵总览

| 编号 | 风险 | 等级 | 概率 | 影响 | 可控性 |
|------|------|------|------|------|--------|
| H1 | 跨车间状态一致性设计不当 | 🔴 致命 | 高 | 核心功能（评分/连坐/标记）不可用 | 完全可控——靠前期数据模型设计 |
| H2 | 规则引擎不可维护 | 🟠 重大 | 高 | 后期无法调整规则，系统僵化 | 完全可控——靠架构设计 |
| H3 | 构建净化投入失控 | 🟠 重大 | 中 | 资源被中间层吃掉，核心层进度受阻 | 完全可控——靠分阶段策略 |
| H4 | 外部集成脆弱 | 🟡 中等 | 高 | 流水线断裂 | 部分可控——做好降级方案 |
| H5 | 产品范围膨胀 | 🟠 重大 | 高 | 开发周期无限拉长 | 完全可控——靠 MVP 分期 |
| H6 | 车间并行开发衔接失败 | 🔴 致命 | 中 | 各车间拼不起来 | 完全可控——靠先定数据契约 |

---

## 七、给 A 面 / B 面车间的建议

### 你们要关注的

1. **数据契约**：在写代码之前，先统一整条流水线的数据模型。你的模板怎么和换皮任务关联？你的方案怎么和包关联？评分数据从哪里来？这些接口定义要先于代码实现。

2. **状态流转**：你的产出物从"开发中"到"待验收"到"入库"到"被选用"到"被标记"——画清楚状态机，特别是异常流（打回、废弃、连坐标记）。

3. **门控标准的可执行性**：蓝图里的 Checklist 有些是可以自动化验证的（编译通过、EXIF 零残留），有些需要人工判断（代码风格差异度）。你清楚哪些是自动的、哪些是人工的吗？

4. **你的车间不是孤岛**：你做的每一个产出物，都会被下游车间使用、被评分引擎评估、在掉包时被反向追溯。你的数据结构要支持这些跨车间操作。

### 你们不需要担心的

- 管理后台的前端怎么做——那是前端团队的事
- 评分引擎的算法细节——那是平台层面的设计
- 外部 API 的对接——分阶段做，Day 1 不需要

---

*本文档基于 2026 年 7 月 26 日的项目状态编写。随着系统开发推进和实际运营反馈，风险评估应持续更新。*