     1|# 如愿 · 系统总览 v1.0
     2|
     3|## 文件信息
     4|
     5|- 文件名称：`00-系统总览.md`
     6|- 项目代号：**如愿**
     7|- 工作目录：`/root/user-business/`
     8|- 当前版本：`v1.0`
     9|- 创建日期：`2026-05-22`
    10|- 上游基线：
    11|  - `docs-from-business/20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md`
    12|  - `docs-from-business/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`
    13|
    14|## 目录
    15|
    16|1. [项目目标与原则](#1-项目目标与原则)
    17|2. [系统总边界](#2-系统总边界)
    18|3. [子系统划分](#3-子系统划分)
    19|4. [子系统间依赖关系](#4-子系统间依赖关系)
    20|5. [角色 → 独立前端映射](#5-角色--独立前端映射)
    21|6. [子系统内外边界明细](#6-子系统内外边界明细)
    22|7. [总系统级业务澄清问题清单](#7-总系统级业务澄清问题清单)
    23|8. [待确认的内外边界](#8-待确认的内外边界)
    24|9. [附录：子系统文档索引](#9-附录子系统文档索引)
    25|
    26|---
    27|
    28|## 1. 项目目标与原则
    29|
### 1.1 项目代号："如愿"

> 取名"如愿"——系统做好能做的所有事（身份识别、需求评估、计划调度、渠道协同、风险拦截、结果追踪），让每一次运营投入都如愿转化为真实的评价提升和 ASIN 健康增长。Amazon 是否展示评价有平台的不确定性，但系统必须把可控环节做到极致。
    33|
    34|### 1.2 核心架构目标
    35|
    36|| # | 目标 | 说明 |
    37|| --- | --- | --- |
    38|| G1 | 前端分离 | 不同角色拥有独立前端应用，按需集成子系统能力 |
    39|| G2 | 清晰系统边界 | 明确系统内外边界，区分内部可控与外部依赖 |
    40|| G3 | 子系统解耦 | 子系统通过 API 契约通信，支持独立开发、独立部署 |
    41|| G4 | 并行开发 | 子系统之间尽量减少串行依赖，允许多团队并行推进 |
    42|| G5 | 独立角色前端 | Amazon 运营、用户运营、客服、风险管理、KOC/KOL 运营各自拥有独立前端 |
    43|
    44|### 1.3 架构原则
    45|
    46|| 原则 | 说明 |
    47|| --- | --- |
    48|| **单一数据源** | 每个业务事实只有一个子系统负责写入（Owner），其他子系统只读或通过 API 调用 |
    49|| **API 契约优先** | 子系统间通过明确 API 契约通信，先定义契约再实现 |
    50|| **真实人为核心** | 所有额度、风险、历史判断围绕「真实人」而非单一账号 |
    51|| **每次互动重判** | 身份、额度、风险不是一次性的，每次有效互动需重做判断 |
    52|| **审计不可少** | 所有状态变更、敏感访问、人工干预必须留痕 |
    53|
    54|---
    55|
    56|## 2. 系统总边界
    57|
    58|### 2.1 边界总图
    59|
    60|```
    61|┌─────────────────────────────────────────────────────────────────────┐
    62|│                        如愿 系统边界                                 │
    63|│                                                                     │
    64|│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐            │
    65|│  │  Amazon   │  │  用户运营  │  │ Amazon   │  │ 风险/黑名 │            │
    66|│  │  运营前端 │  │   前端    │  │ 运营总监  │  │  单前端   │            │
    67|│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘            │
    68|│       │              │              │              │                  │
    69|│  ┌────┴─────┐  ┌────┴─────┐  ┌────┴─────┐  ┌────┴─────┐            │
    70|│  │  客服前端  │  │  客服管理 │  │ KOC/KOL  │  │ 管理驾驶 │            │
    71|│  │          │  │   前端    │  │  运营前端 │  │   舱     │            │
    72|│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘            │
    73|│       │              │              │              │                  │
    74|│  ═════╪══════════════╪══════════════╪══════════════╪══════  API网关  │
    75|│       │              │              │              │                  │
    76|│  ┌────┴──────────────┴──────────────┴──────────────┴─────┐          │
    77|│  │                    内部子系统                            │          │
    78|│  │  ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐         │          │
    79|│  │  │ 用户身 │ │需求与计│ │额度与频│ │多渠道触│         │          │
    80|│  │  │份上下文│ │划管理  │ │  控    │ │达引擎  │         │          │
    81|│  │  └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘         │          │
    82|│  │  ┌───┴────┐ ┌───┴────┐ ┌───┴────┐ ┌───┴────┐         │          │
    83|│  │  │客服工单│ │风险与反│ │评价结果│ │KOC/KOL │         │          │
    84|│  │  │与管理  │ │  欺诈  │ │  追踪  │ │  协作  │         │          │
    85|│  │  └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘         │          │
    86|│  │  ┌───┴────┐                                                │          │
    87|│  │  │审计与通│                                                │          │
    88|│  │  │知中心  │                                                │          │
    89|│  │  └────────┘                                                │          │
    90|│  └───────────────────────────────────────────────────────────┘          │
    91|│                                                                     │
    92|└─────────────────────────────────────────────────────────────────────┘
    93|
    94|                        ║  外部系统  ║
    95|
    96|┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
    97|│  Amazon  │  │ JOYHUB   │  │JOYCOLLAB │  │ 邮件服务 │  │ 财务系统 │
    98|│ Marketplace│ │ 用户平台  │  │ KOC平台  │  │  (ESP)   │  │(返款/退款)│
    99|└──────────┘  └──────────┘  └──────────┘  └──────────┘  └──────────┘
   100|```
   101|
   102|### 2.2 系统内部（如愿系统）
   103|
   104|| # | 子系统 | 代号 | 核心职责 | 详情文档 |
   105|| --- | --- | --- | --- | --- |
   106|| S1 | 用户身份与上下文 | `identity` | 真实人识别、身份线索归并、用户上下文卡 | [01-用户身份与上下文](01-子系统-用户身份与上下文.md) |
   107|| S2 | 需求与计划管理 | `planning` | 需求触发（人工/自动）、计划生成（推新/回评/免评）、审批工作流 | [02-需求与计划管理](02-子系统-需求与计划管理.md) |
   108|| S3 | 额度与频控 | `quota` | 月度测评/免评额度台账、累计评价额度、频控、预占 | [03-额度与频控](03-子系统-额度与频控.md) |
   109|| S4 | 多渠道触达引擎 | `outreach` | IM/EDM/APP Push/TEL 渠道调度、路由、去重、发送 | [04-多渠道触达引擎](04-子系统-多渠道触达引擎.md) |
   110|| S5 | 客服工单与管理 | `support` | 工单生命周期、自动分配、排班出勤、绩效统计 | [05-客服工单与管理](05-子系统-客服工单与管理.md) |
   111|| S6 | 风险与反欺诈 | `risk` | 强弱关联判断、黑名单、双重退款检测、风险事件 | [06-风险与反欺诈](06-子系统-风险与反欺诈.md) |
   112|| S7 | 评价结果追踪 | `review` | 评价提交记录、Amazon 展示核验、ASIN 健康回流 | [07-评价结果追踪](07-子系统-评价结果追踪.md) |
   113|| S8 | KOC/KOL 协作 | `creator` | KOC/KOL 匹配、内容跟踪、Code 管理、JOYCOLLAB 同步 | [08-KOC-KOL协作](08-子系统-KOC-KOL协作.md) |
   114|| S9 | 审计与通知中心 | `audit` | 状态变更审计、敏感访问日志、多类型通知/告警 | [09-审计与通知中心](09-子系统-审计与通知中心.md) |
   115|
   116|### 2.3 系统外部（外部依赖）
   117|
   118|| # | 外部系统 | 说明 | 交互方式 | 确认状态 |
   119|| --- | --- | --- | --- | --- |
   120|| E1 | **Amazon Marketplace** | 订单数据、评价数据、ASIN/Listing 健康数据、退款数据 | API 拉取 / 爬取 | ⚠️ 待确认 |
   121|| E2 | **JOYHUB 用户平台** | JOYHUB ID、设备信息、APP 行为数据、绑定玩具数据 | API 同步 | ⚠️ 待确认 |
   122|| E3 | **JOYCOLLAB** | KOC/KOL 内容数据、Code 使用数据、带货订单数据 | API 同步 | ⚠️ 待确认 |
   123|| E4 | **邮件服务 (ESP)** | EDM 发送、送达/打开/点击追踪、退订/硬退信 | SMTP + Webhook | ⚠️ 待确认 |
   124|| E5 | **财务系统** | 返款执行、返款状态、退款记录（OA 侧） | API 调用 | ⚠️ 待确认 |
   125|| E6 | **APP Push 服务** | APP 推送通道（FCM/APNs） | SDK / API | ⚠️ 待确认 |
   126|| E7 | **电话系统** | 外呼能力、来电识别、通话记录 | API / SIP | ⚠️ 待确认 |
   127|| E8 | **IM 平台 (WhatsApp?)** | IM 消息收发 | API | ⚠️ 待确认 |
   128|
   129|---
   130|
   131|## 3. 子系统划分
   132|
   133|### 3.1 划分依据
   134|
   135|子系统按照**业务域内聚**原则划分，每个子系统：
   136|
   137|1. 拥有明确的数据所有权（该子系统是某些核心数据对象的唯一写入方）
   138|2. 对外暴露清晰的 API 契约
   139|3. 可以独立开发、测试、部署
   140|4. 尽量减少对其他子系统的强依赖（启动依赖）
   141|
   142|### 3.2 各子系统数据所有权
   143|
   144|| 子系统 | 拥有（写入）的核心数据对象 |
   145|| --- | --- |
   146|| identity | `person_profiles`、`person_identity_links`、`contact_context_snapshots`、`device_records` |
   147|| planning | `demands`、`plans`、`plan_items`、`approval_records`、`asin_catalog` |
   148|| quota | `person_quota_ledgers`、`quota_reservations`、`frequency_control_records` |
   149|| outreach | `channel_route_decisions`、`channel_dedup_records`、`im_interaction_records`、`edm_message_events`、`app_touch_events`、`tel_call_records` |
   150|| support | `support_tickets`、`support_followups`、`support_assignment_logs`、`attendance_records`、`shift_schedules`、`support_performance_snapshots` |
   151|| risk | `risk_signals`、`risk_cases`、`blacklist_entities`、`refund_match_results` |
   152|| review | `review_submission_records`、`review_display_checks`、`review_results` |
   153|| creator | `exemption_plan_tasks`、`creator_content_records`、`creator_profiles`、`code_records` |
   154|| audit | `interaction_audit_logs`、`notification_records`、`manual_review_tasks` |
   155|
   156|---
   157|
   158|## 4. 子系统间依赖关系
   159|
   160|### 4.1 依赖图
   161|
   162|```
   163|         ┌─────────────────────────────────────────────┐
   164|         │               audit (审计与通知)              │
   165|         │         ← 所有子系统向 audit 发送事件          │
   166|         └─────────────────────────────────────────────┘
   167|                              ↑
   168|    ┌─────────┬─────────┬─────┼─────┬─────────┬─────────┐
   169|    │         │         │     │     │         │         │
   170|┌───┴───┐ ┌───┴───┐ ┌───┴───┐ │ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐
   171|│ review│ │creator│ │support│ │ │  risk │ │ quota │ │outreach│
   172|│(评价) │ │(KOC)  │ │(客服) │ │ │(风险) │ │(额度) │ │(触达) │
   173|└───┬───┘ └───┬───┘ └───┬───┘ │ └───┬───┘ └───┬───┘ └───┬───┘
   174|    │         │         │     │     │         │         │
   175|    └─────────┼─────────┼─────┼─────┼─────────┼─────────┘
   176|              │         │     │     │         │
   177|         ┌────┴─────────┴─────┼─────┼─────────┴────────┐
   178|         │                    │     │                    │
   179|         ▼                    ▼     ▼                    ▼
   180|    ┌─────────┐          ┌──────────────┐          ┌─────────┐
   181|    │planning │←─────────│   identity   │─────────→│  quota  │
   182|    │(计划)   │          │  (用户身份)   │          │ (额度)  │
   183|    └─────────┘          └──────────────┘          └─────────┘
   184|```
   185|
   186|### 4.2 依赖矩阵
   187|
   188|| ↓ 消费者 \ 提供者 → | identity | planning | quota | outreach | support | risk | review | creator | audit |
   189|| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
   190|| **identity** | - | - | - | - | - | R | - | - | E |
   191|| **planning** | **R** | - | R | - | - | R | R | - | E |
   192|| **quota** | **R** | - | - | - | - | - | R | - | E |
   193|| **outreach** | R | R | R | - | - | R | - | - | E |
   194|| **support** | R | - | - | - | - | R | - | - | E |
   195|| **risk** | R | - | - | - | - | - | - | - | E |
   196|| **review** | R | R | - | - | - | - | - | R | E |
   197|| **creator** | - | R | R | - | - | - | - | - | E |
   198|| **audit** | - | - | - | - | - | - | - | - | - |
   199|
   200|**图例：** `R` = 只读依赖（通过 API 查询），`E` = 事件发送（fire-and-forget），`-` = 无依赖
   201|
   202|### 4.3 启动依赖（必须就绪才能工作）
   203|
   204|| 子系统 | 启动依赖 | 说明 |
   205|| --- | --- | --- |
   206|| identity | 无硬依赖 | 可独立启动（需要 JOYHUB 数据同步） |
   207|| planning | identity（软依赖） | 无 identity 时可先操作，但无法做人群匹配 |
   208|| quota | identity（软依赖） | 额度按真实人计算，未归并时按单一账号 |
   209|| outreach | identity, planning, quota（软依赖） | 无依赖时可先建渠道基础设施 |
   210|| support | identity（软依赖） | 无用户上下文卡时可先跑工单 |
   211|| risk | identity（软依赖） | 强/弱关联依赖身份数据 |
   212|| review | identity, planning（软依赖） | 评价需关联计划和用户 |
   213|| creator | planning（软依赖） | 免评计划入口 |
   214|| audit | 无硬依赖 | 完全独立 |
   215|
   216|> **软依赖** = 可降级运行，核心功能不受阻。例如 outreach 在 identity 不可用时仍可发送消息，但缺少用户上下文。
   217|
   218|---
   219|
   220|## 5. 角色 → 独立前端映射
   221|
   222|### 5.1 前端应用矩阵
   223|
   224|| 前端应用 | 目标角色 | 集成的子系统 | 部署形态 |
   225|| --- | --- | --- | --- |
   226|| **运营工作台** | Amazon 运营、Amazon 运营总监 | planning + review + quota (查询) | Web SPA |
   227|| **用户运营中心** | 用户运营、用户运营负责人/组长 | planning + outreach + quota + review | Web SPA |
   228|| **客服工作台** | 菲律宾客服组员 | support + identity (上下文卡) + outreach (TEL) | Web SPA / 桌面端 |
   229|| **客服管理台** | 菲律宾客服负责人、客服组长 | support (管理模块) + audit | Web SPA |
   230|| **风险控制台** | 风险/黑名单相关人员 | risk + identity (上下文卡) + audit | Web SPA |
   231|| **达人协作台** | KOC/KOL 运营 | creator + outreach (协同) + review (免评结果) | Web SPA |
   232|| **管理驾驶舱** | 运营总监、用户运营负责人 | 跨子系统聚合看板 (planning + outreach + support + review) | Web SPA |
   233|
   234|### 5.2 角色-功能矩阵
   235|
   236|| 功能 \ 角色 | Amazon运营 | 运营总监 | 用户运营 | 用户负责人 | 客服组员 | 客服组长 | 客服负责人 | 风险人员 | KOC运营 |
   237|| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
   238|| 提需求（推新/回评/免评） | ✓ | ✓ | - | - | - | - | - | - | - |
   239|| 审批计划 | - | ✓ | - | ✓ | - | - | - | - | - |
   240|| 评估需求 | - | - | ✓ | ✓ | - | - | - | - | - |
   241|| 生成计划/调资源 | - | - | ✓ | ✓ | - | - | - | - | - |
   242|| 查看 ASIN 健康 | ✓ | ✓ | ✓ | - | - | - | - | - | - |
   243|| 处理工单 | - | - | - | - | ✓ | ✓ | - | - | - |
   244|| 分配工单 | - | - | - | - | - | ✓ | ✓ | - | - |
   245|| 电话外呼/接听 | - | - | - | - | ✓ | - | - | - | - |
   246|| 查看排班出勤 | - | - | - | - | - | ✓ | ✓ | - | - |
   247|| 绩效统计 | - | - | - | - | - | ✓ | ✓ | - | - |
   248|| 风险审核 | - | - | - | - | - | - | - | ✓ | - |
   249|| 黑名单管理 | - | - | - | - | - | - | - | ✓ | - |
   250|| KOC/KOL 匹配 | - | - | - | - | - | - | - | - | ✓ |
   251|| 内容跟踪 | - | - | ✓ | - | - | - | - | - | ✓ |
   252|
   253|---
   254|
   255|## 6. 子系统内外边界明细
   256|
   257|### 6.1 identity — 用户身份与上下文
   258|
   259|| 维度 | 说明 |
   260|| --- | --- |
   261|| **对内** | 管理真实人归并逻辑、身份线索关联（JOYHUB ID↔邮箱↔电话↔设备↔订单→真实人ID）、用户上下文卡聚合与快照、设备变化识别 |
   262|| **对外（提供给其他子系统）** | `GET /api/identity/person/{context}` — 按线索查真实人；`GET /api/identity/context/{person_id}` — 用户上下文卡；`POST /api/identity/merge` — 归并请求 |
   263|| **依赖外部系统** | JOYHUB（用户基础数据）、APP（设备数据） |
   264|| **待确认边界** | 真实人归并是自动还是人工确认？归并拆分（合并错了如何回退）？非 APP 用户的身份线索从哪里同步（ESM 的邮箱清洗？） |
   265|
   266|### 6.2 planning — 需求与计划管理
   267|
   268|| 维度 | 说明 |
   269|| --- | --- |
   270|| **对内** | 需求触发（人工提交 + 自动触发规则）、需求评估、计划创建（推新/回评/免评）、审批工作流、ASIN 基础信息管理 |
   271|| **对外（提供给其他子系统）** | `GET /api/plans/{id}` — 计划详情；`GET /api/plans?status=approved` — 待执行计划；`POST /api/demands` — 创建需求 |
   272|| **依赖外部系统** | Amazon（ASIN 数据、销售数据、评价缺口） |
   273|
   274|### 6.3 quota — 额度与频控
   275|
   276|| 维度 | 说明 |
   277|| --- | --- |
   278|| **对内** | 额度台账（测评4/免评4/累计12）、额度预占与释放、频控规则引擎、发送前终校 |
   279|| **对外（提供给其他子系统）** | `GET /api/quota/check/{person_id}?type=测评` — 额度查询+预占；`POST /api/quota/reserve` — 预占；`POST /api/quota/commit` — 确认占用 |
   280|| **依赖外部系统** | 无直接外部系统依赖 |
   281|| **待确认边界** | 额度预占有效期多长？跨月额度如何处理（月末最后一天预占，下月一号释放还是保留？） |
   282|
   283|### 6.4 outreach — 多渠道触达引擎
   284|
   285|| 维度 | 说明 |
   286|| --- | --- |
   287|| **对内** | 渠道路由决策、渠道去重、IM 推送（分层 A/B/C）、EDM 发送与行为追踪、APP Push、TEL 任务生成 |
   288|| **对外（提供给其他子系统）** | `POST /api/outreach/send` — 发送触达；`GET /api/outreach/history/{person_id}` — 触达历史 |
   289|| **依赖外部系统** | JOYHUB（IM 通道）、ESP（EDM）、FCM/APNs（APP Push）、电话系统（TEL） |
   290|| **待确认边界** | IM 具体是什么平台（WhatsApp/自研 IM）？EDM 模板管理在 outreach 内还是独立内容管理？APP Push 是否复用 JOYHUB 现有 Push 通道？ |
   291|
   292|### 6.5 support — 客服工单与管理
   293|
   294|| 维度 | 说明 |
   295|| --- | --- |
   296|| **对内** | 工单生命周期、自动分配（按排班/在线/负载）、答应配合状态机、出勤/排班/绩效 |
   297|| **对外（提供给其他子系统）** | `POST /api/tickets` — 创建工单；`GET /api/tickets/{id}` — 工单详情；`GET /api/support/stats` — 绩效数据 |
   298|| **依赖外部系统** | 无直接外部系统依赖（电话记录来自 outreach TEL 模块） |
   299|| **待确认边界** | 客服是否使用独立 IM 工具还是复用 outreach 的 IM 通道？排班数据是否与现有 HR 系统对接？ |
   300|
   301|### 6.6 risk — 风险与反欺诈
   302|
   303|| 维度 | 说明 |
   304|| --- | --- |
   305|| **对内** | 强弱关联判断、黑名单实体管理、风险事件管理、双重退款检测（Amazon退款 vs OA返款） |
   306|| **对外（提供给其他子系统）** | `GET /api/risk/check/{person_id}` — 风险查询；`POST /api/risk/report` — 上报风险信号 |
   307|| **依赖外部系统** | Amazon（退款数据）、财务系统（OA 返款数据） |
   308|
   309|### 6.7 review — 评价结果追踪
   310|
   311|| 维度 | 说明 |
   312|| --- | --- |
   313|| **对内** | 用户真实提交评价记录、Amazon 展示核验、ASIN 健康更新回流、计划完成度计算 |
   314|| **对外（提供给其他子系统）** | `POST /api/reviews/submission` — 记录提交；`GET /api/reviews/status/{plan_id}` — 计划评价进度 |
   315|| **依赖外部系统** | Amazon（评价展示状态、ASIN 评分数据） |
   316|
   317|### 6.8 creator — KOC/KOL 协作
   318|
   319|| 维度 | 说明 |
   320|| --- | --- |
   321|| **对内** | KOC/KOL 匹配筛选、内容 Brief/Code 分配、内容发布跟踪、带货结果跟踪 |
   322|| **对外（提供给其他子系统）** | `GET /api/creators/match?plan_id=` — 匹配推荐；`POST /api/creators/tasks` — 创建协作任务 |
   323|| **依赖外部系统** | JOYCOLLAB（KOC/KOL 数据、内容数据、Code 使用、带货订单） |
   324|
   325|### 6.9 audit — 审计与通知中心
   326|
   327|| 维度 | 说明 |
   328|| --- | --- |
   329|| **对内** | 所有子系统的状态变更审计、敏感字段访问日志、多类型通知（额度预警/超时提醒/紧急 Listing 告警/审批通知） |
   330|| **对外（提供给其他子系统）** | `POST /api/audit/event` — 上报审计事件；`POST /api/notifications/send` — 发送通知 |
   331|| **依赖外部系统** | 通知可能通过 IM/EDM/APP Push 等通道（可复用 outreach 通道或独立） |
   332|| **待确认边界** | 审计日志保留策略？通知模板管理在 audit 内还是需要独立内容管理？ |
   333|
   334|---
   335|
   336|## 7. 总系统级业务澄清问题清单
   337|
   338|> 以下问题需要与业务方确认，涉及跨子系统边界、关键业务规则和外部系统对接。
   339|
   340|### 7.1 外部系统对接（8 项）
   341|
   342|| # | 问题 | 涉及外部系统 | 优先级 |
   343|| --- | --- | --- | --- |
   344|| Q-E1 | Amazon 数据以什么方式接入？（MWS/SP-API 授权拉取、爬虫、CSV 导入、已有中间表？） | Amazon | **P0** |
   345|| Q-E2 | JOYHUB 现有数据有哪些可用？是否有现成 API？JOYHUB ID ↔ 邮箱 ↔ 设备 ↔ 订单 的关联数据是否已存储？ | JOYHUB | **P0** |
   346|| Q-E3 | JOYCOLLAB 数据同步方向是单向（COLLAB→USER）还是双向？同步频率？Code 生成是在 COLLAB 还是 USER？ | JOYCOLLAB | **P0** |
   347|| Q-E4 | 当前 EDM 使用什么邮件服务？（SendGrid / Mailchimp / SES / 自建？）是否有现成的送达/打开/点击追踪？ | ESP | **P0** |
   348|| Q-E5 | OA 返款系统是哪个？是否有 API 可以查询返款状态和返款记录？（用于双重退款比对） | 财务系统 | **P0** |
   349|| Q-E6 | APP Push 是否复用 JOYHUB 现有 Push 通道还是需要独立接入 FCM/APNs？ | APP Push | P1 |
   350|| Q-E7 | 电话系统用什么方案？（自建 SIP / 第三方云呼叫中心？）是否已有通话记录存储？ | 电话系统 | P1 |
   351|| Q-E8 | IM 平台具体是什么？（WhatsApp Business API / 自研 IM / Facebook Messenger？） | IM 平台 | P1 |
   352|
   353|### 7.2 用户身份体系（5 项）
   354|
   355|| # | 问题 | 优先级 |
   356|| --- | --- | --- |
   357|| Q-I1 | 「真实人」归并是完全自动还是需要人工确认？自动归并错误时如何拆分？（拆分会影响到已关联的历史评价和额度） | **P0** |
   358|| Q-I2 | 非 APP 用户（只知道邮箱）如何建立真实人？没有设备号仅凭邮箱+收件地址归并，置信度阈值如何定？ | **P0** |
   359|| Q-I3 | JOYHUB ID 与真实人是 1:1 还是 N:1？（一个真实人可能拥有多个 JOYHUB ID） | P1 |
   360|| Q-I4 | 设备变化的「换机」判定标准是什么？（同一 JOYHUB ID 下设备号变化？多久内变化算换机？） | P1 |
   361|| Q-I5 | 用户上下文卡的「快照」是否需要保留历史版本？（每次互动生成新快照 vs 覆盖上次） | P2 |
   362|
   363|### 7.3 额度与频控规则（6 项）
   364|
   365|| # | 问题 | 优先级 |
   366|| --- | --- | --- |
   367|| Q-Q1 | 月度额度按自然月还是按 30 天滚动？如果是自然月，预占在月末最后一天是否需要特殊处理？ | **P0** |
   368|| Q-Q2 | 「测评 4 次」的「次」定义：是指参与 4 个不同的测评计划，还是提交 4 次评价？（如果一次计划要求用户提交多条评价怎么算） | **P0** |
   369|| Q-Q3 | 「累计 12 个评价」是永久上限还是可以重置？（例如用户长期优质，是否可以放宽？） | P1 |
   370|| Q-Q4 | 额度预占的有效期多长？如果预占后用户始终未响应，多久释放额度？ | P1 |
   371|| Q-Q5 | 频控规则中的「渠道频控」具体阈值是多少？（IM 每日最多推几次？EDM 每周最多几封？） | P1 |
   372|| Q-Q6 | 「接近上限时提前预警」——预警阈值是还剩 1 次还是还剩 N%？ | P2 |
   373|
   374|### 7.4 计划与审批流程（5 项）
   375|
   376|| # | 问题 | 优先级 |
   377|| --- | --- | --- |
   378|| Q-P1 | 自动触发需求的条件是什么？（ASIN 评分低于多少？评价缺口多少条？Listing 健康到什么程度？） | **P0** |
   379|| Q-P2 | 审批链中的「指定负责人」如何确定？（系统自动按规则还是人工指定？规则是什么？） | **P0** |
   380|| Q-P3 | 计划审批后是否可以修改？修改是否需要重新审批？ | P1 |
   381|| Q-P4 | 计划之间是否有互斥关系？（同一个 ASIN 同时跑推新和回评计划是否可以？） | P1 |
   382|| Q-P5 | 「紧急计划」的判定标准和特殊审批流程？（谁可以标记为紧急？是否跳过某些审批节点？） | P1 |
   383|
   384|### 7.5 渠道协同与去重（5 项）
   385|
   386|| # | 问题 | 优先级 |
   387|| --- | --- | --- |
   388|| Q-C1 | 渠道优先级路由规则是否需要可配置？（例如针对某类用户调整 IM > EDM 的优先级） | **P0** |
   389|| Q-C2 | 用户已在客服工单中时「暂停自动触达」——是所有渠道暂停还是仅暂停与当前工单相关的渠道？ | P1 |
   390|| Q-C3 | EDM 引导注册 APP 后，如何识别「该 EDM 邮箱对应该 APP 用户」？靠什么字段关联？ | P1 |
   391|| Q-C4 | 渠道去重中「同一计划同一用户不重复通过多渠道路由」——如果高优先级渠道发送失败（退信/未送达），是否自动降级到下一渠道？ | P1 |
   392|| Q-C5 | IM 推送中的「催评卡片」和 APP Push 中的「催评推送」如何协调？（两者会不会同时推送给同一用户？） | P1 |
   393|
   394|### 7.6 客服与工单（5 项）
   395|
   396|| # | 问题 | 优先级 |
   397|| --- | --- | --- |
   398|| Q-S1 | 工单自动分配算法——「当前负载」如何计算？（按未关闭工单数？按最近 N 小时处理量？） | **P0** |
   399|| Q-S2 | 客服的「在线状态」如何获取？（手动切换在线/离线，还是自动检测活跃度？） | P1 |
   400|| Q-S3 | 「答应配合」的超时判定——答应后多少天未提交算超时？超时后提醒频率？ | P1 |
   401|| Q-S4 | 出勤排班是否与本系统内的排班模块管理还是对接外部 HR 系统？ | P1 |
   402|| Q-S5 | 客服转化统计中的 RSO（回评）和 RDO（测评）如何区分？（按工单来源？按最终结果？） | P2 |
   403|
   404|### 7.7 风险与反欺诈（4 项）
   405|
   406|| # | 问题 | 优先级 |
   407|| --- | --- | --- |
   408|| Q-R1 | 「强关联」中哪些维度的命中可以直接自动化拦截，哪些需要人工复核？（文档说一旦命中直接进入高风险，但实际执行中是否所有强关联都自动拦截？） | **P0** |
   409|| Q-R2 | 双重退款检测——Amazon 退款数据如何及时获取？（T+1 同步？实时 Webhook？手动导入？） | **P0** |
   410|| Q-R3 | 黑名单是否有过期/申诉/解除机制？什么条件下可以从黑名单中移除？ | P1 |
   411|| Q-R4 | 风险信号的「弱关联」观察期多长？观察期过后是自动解除还是人工确认？ | P1 |
   412|
   413|### 7.8 评价结果与回流（4 项）
   414|
   415|| # | 问题 | 优先级 |
   416|| --- | --- | --- |
   417|| Q-V1 | Amazon 评价展示的核验方式是什么？（定时爬取 Amazon 页面？手动录入？用户上传截图？API？） | **P0** |
   418|| Q-V2 | 「Amazon 未展示 / 暂不可核验」的评价进入异常观察队列后，观察多久？复查频率？ | P1 |
   419|| Q-V3 | ASIN 健康「回流」的具体含义是什么？（更新 ASIN 评分/评价数到 planning 子系统，触发新一轮需求？） | P1 |
   420|| Q-V4 | 一个用户可能为多个 ASIN 提交评价——这些评价是否都计入同一个计划的完成度？ | P1 |
   421|
   422|### 7.9 KOC/KOL 协作（4 项）
   423|
   424|| # | 问题 | 优先级 |
   425|| --- | --- | --- |
   426|| Q-K1 | JOYCOLLAB 中 KOC/KOL 数据字段有哪些？（粉丝量、平台、国家、历史效果——文档提到但需确认完整字段） | **P0** |
   427|| Q-K2 | 「匹配 KOC/KOL」是运营人工选择还是系统自动推荐？推荐算法依赖什么数据？ | P1 |
   428|| Q-K3 | Code 是 JOYCOLLAB 生成还是 USER 系统生成？是一对一（每个 KOC 独立 Code）还是一对多？ | P1 |
   429|| Q-K4 | KOC/KOL 的财务结算（提成/返点）是完全在财务系统还是在 USER 系统内触发？ | P1 |
   430|
   431|### 7.10 数据迁移与历史兼容（3 项）
   432|
   433|| # | 问题 | 优先级 |
   434|| --- | --- | --- |
   435|| Q-D1 | 现有 USER 后台 ERP 系统（`C:\XCODE\USER`）是否完全废弃还是部分模块保留？新旧系统切换策略？ | **P0** |
   436|| Q-D2 | 历史数据（已有评价记录、用户数据、工单记录）是否需要迁移到新系统？迁移范围和清洗策略？ | **P0** |
   437|| Q-D3 | 旧系统中存在的用户额度数据如何初始化？（历史测评次数、免评次数、累计评价数如何确定？） | **P0** |
   438|
   439|### 7.11 项目分期与 MVP 范围（5 项）
   440|
   441|| # | 问题 | 优先级 |
   442|| --- | --- | --- |
   443|| Q-M1 | 项目一期（MVP）的最小范围是什么？9 个子系统中哪些是必须的、哪些可以二期再做？ | **P0** |
   444|| Q-M2 | MVP 先支持哪个 Amazon 站点？（.com？还是多站点？）先支持哪种计划类型？（推新/回评/免评全部 or 先做回评？） | **P0** |
   445|| Q-M3 | 前端应用的优先级——7 个前端中哪些是 MVP 必须有？（客服工作台+运营工作台？还是全部都要？） | **P0** |
   446|| Q-M4 | 项目整体时间线和里程碑约束？（6 个月？1 年？是否有硬性 deadline？） | P1 |
   447|| Q-M5 | 开发团队规模和结构？（几个后端开发？几个前端？是否有专职 QA？）是否支持 9 个子系统并行开发？ | P1 |
   448|
   449|### 7.12 基础设施与部署（6 项）
   450|
   451|| # | 问题 | 优先级 |
   452|| --- | --- | --- |
   453|| Q-IN1 | 部署环境？（云厂商 AWS/阿里云？自建机房？）是否已有 Kubernetes 集群或考虑容器化部署？ | **P0** |
   454|| Q-IN2 | 数据库选型？（PostgreSQL / MySQL？）每子系统独立数据库还是共享数据库？是否已有数据库团队和规范？ | **P0** |
   455|| Q-IN3 | 子系统间异步通信方案？（消息队列：Kafka/RabbitMQ/Redis？还是全部同步 HTTP？） | **P0** |
   456|| Q-IN4 | API 网关选型？（Kong/Nginx/自研？）认证鉴权方案？（JWT/OAuth2/SSO？） | P1 |
   457|| Q-IN5 | 日志、监控、链路追踪方案？（ELK/Prometheus+Grafana/Jaeger？）是否已有公司级基础设施可复用？ | P1 |
   458|| Q-IN6 | 灾备和容灾要求？（RPO/RTO 目标？是否需要多可用区/异地容灾？数据备份频率？） | P2 |
   459|
   460|### 7.13 安全与合规（5 项）
   461|
   462|| # | 问题 | 优先级 |
   463|| --- | --- | --- |
   464|| Q-SC1 | 是否有需要通过的安全合规认证？（SOC2 / ISO 27001 / 等保？）对系统架构有何约束？ | P1 |
   465|| Q-SC2 | 用户个人数据（邮箱、电话、地址、设备号）的保留和删除策略？（GDPR 的「被遗忘权」如何处理？） | P1 |
   466|| Q-SC3 | Amazon 的 API 使用条款（SP-API Acceptable Use Policy）对数据存储和使用的限制？（评价数据是否可以长期存储？） | P1 |
   467|| Q-SC4 | 系统权限模型？（RBAC？角色和权限的粒度？是否需要支持数据行级权限——例如不同站点的运营只看自己的 ASIN？） | P1 |
   468|| Q-SC5 | 敏感数据（收款信息、设备号）的加密存储方案？传输加密（TLS）要求？ | P2 |
   469|
   470|### 7.14 技术栈与规范（4 项）
   471|
   472|| # | 问题 | 优先级 |
   473|| --- | --- | --- |
   474|| Q-TS1 | 后端技术栈偏好？（Python/FastAPI？Go？Node.js？Java？）是否有公司技术栈约束？ | P1 |
   475|| Q-TS2 | 前端技术栈偏好？（React/Vue/Angular？）是否有公司前端组件库或设计系统可复用？ | P1 |
   476|| Q-TS3 | API 规范标准？（OpenAPI 3.0？gRPC？）是否需要 BFF（Backend for Frontend）层？ | P2 |
   477|| Q-TS4 | 代码仓库策略？（Monorepo or Polyrepo？9 个子系统分仓库还是一仓库？CI/CD 工具？） | P2 |
   478|
   479|### 7.15 多站点与多市场（4 项）
   480|
   481|| # | 问题 | 优先级 |
   482|| --- | --- | --- |
   483|| Q-MS1 | 系统需要支持多少个 Amazon 站点？（.com / .co.uk / .de / .fr / .it / .es / .jp / .ca？）不同站点的业务流程是否一致？ | **P0** |
   484|| Q-MS2 | 多站点下「真实人」归并是否跨站点？（同一个真实人在 .com 和 .co.uk 用不同邮箱/账号——是否归并为同一人？） | P1 |
   485|| Q-MS3 | 额度规则是否跨站点？（测评 4 次是每个站点独立还是全局？累计 12 个评价呢？） | P1 |
   486|| Q-MS4 | 未来是否扩展到 Amazon 以外的平台（eBay/Walmart/独立站）？架构上需要预留扩展点吗？ | P2 |
   487|
   488|### 7.16 内容与素材管理（3 项）
   489|
   490|| # | 问题 | 优先级 |
   491|| --- | --- | --- |
   492|| Q-CM1 | EDM 模板、IM 推送话术、APP Push 文案的创建和维护由谁负责？（内容运营？用户运营？）是否需要独立的内容管理子系统？ | P1 |
   493|| Q-CM2 | 多语言内容策略？（面向美国用户的英文消息、面向德国用户的德语消息——模板由谁翻译和维护？系统是否需要自动翻译？） | P1 |
   494|| Q-CM3 | 图片/视频素材（产品图片、测评指引图）的存储和管理？是否需要 CDN？ | P2 |
   495|
   496|### 7.17 业务量级预估（4 项）
   497|
   498|| # | 问题 | 优先级 |
   499|| --- | --- | --- |
   500|| Q-BV1 | 系统需要管理的 ASIN 数量级？（几十个？几百个？几千个？） | P1 |
   501|| Q-BV2 | 日活跃用户数（APP 端）？日触达消息量（IM+EDM+APP Push+TEL）？ | P1 |
   502|| Q-BV3 | 客服团队规模？（几个组？每组多少人？峰值工单量？） | P1 |
   503|| Q-BV4 | 峰值场景预估？（Prime Day / Black Friday 期间流量和触达量是平时的几倍？） | P2 |
   504|
   505|### 7.18 外部系统对接细节（4 项）
   506|
   507|| # | 问题 | 优先级 |
   508|| --- | --- | --- |
   509|| Q-EX1 | 各外部系统的 SLA 和可用性？（Amazon SP-API 的 rate limit？JOYHUB 的响应时间？）当外部系统不可用时的降级策略？ | P1 |
   510|| Q-EX2 | 外部系统的认证方式？（Amazon SP-API 的 OAuth 授权流程？JOYHUB 的 API Key？）谁负责管理这些凭证？ | P1 |
   511|| Q-EX3 | 数据同步的增量 or 全量策略？（Amazon 订单是增量拉取最近 N 天还是全量同步？JOYHUB 用户数据呢？） | P1 |
   512|| Q-EX4 | 外部系统数据格式和字段映射是否已有文档？（Amazon 订单字段→系统内部字段的映射关系？） | P2 |
   513|
   514|---
   515|
   516|## 8. 待确认的内外边界
   517|
   518|> 以下边界由于文档信息不足，标记为「待确认」，需要在后续与业务方或技术团队确认。
   519|
   520|| # | 边界问题 | 影响范围 | 建议确认方式 |
   521|| --- | --- | --- | --- |
   522|| B1 | **内容/素材管理归属**：EDM 模板、IM 推送话术、APP Push 文案由哪个子系统管理？是 outreach 内的内容模块，还是独立的内容管理子系统？ | outreach | 与内容运营角色确认工作流 |
   523|| B2 | **品牌/内容运营角色**：文档提到品牌运营和内容运营但目前不展开。他们是否需要独立前端？需求何时明确？ | planning / creator | 与业务方确认是否一期纳入 |
   524|| B3 | **数据仓库/BI 边界**：文档明确「完整 BI/财务/ROI 系统」不在本版主流程，但管理驾驶舱涉及聚合看板。看板数据是子系统直接提供聚合 API 还是走独立数据仓库？ | 全部 | 与数据团队确认数据架构 |
   525|| B4 | **外部系统降级策略**：Amazon API 不可用时，哪些功能可以降级运行？JOYHUB 不可用时用户身份如何兜底？ | identity / planning / review | 制定 SLA 和降级方案 |
   526|| B5 | **多语言支持**：系统前端是否只面向菲律宾客服（英文？）还是国内团队也使用（中文？） | 所有前端 | 确认各前端的语言需求 |
   527|| B6 | **定时任务归属**：自动需求触发、EDM 批处理、超时检测、评价核验等定时任务在各子系统内实现还是有统一调度器？ | 多个子系统 | 确认是否引入统一任务调度 |
   528|
   529|---
   530|
   531|## 9. 附录：子系统文档索引
   532|
   533|| 文档 | 描述 |
   534|| --- | --- |
   535|| [01-子系统-用户身份与上下文](01-子系统-用户身份与上下文.md) | 真实人归并、用户上下文卡、设备识别 |
   536|| [02-子系统-需求与计划管理](02-子系统-需求与计划管理.md) | 需求触发、计划生命周期、审批工作流 |
   537|| [03-子系统-额度与频控](03-子系统-额度与频控.md) | 额度台账、频控引擎、预占释放 |
   538|| [04-子系统-多渠道触达引擎](04-子系统-多渠道触达引擎.md) | IM/EDM/APP/TEL 调度与执行 |
   539|| [05-子系统-客服工单与管理](05-子系统-客服工单与管理.md) | 工单管理、客服管理支撑 |
   540|| [06-子系统-风险与反欺诈](06-子系统-风险与反欺诈.md) | 风险判断、黑名单、双重退款 |
   541|| [07-子系统-评价结果追踪](07-子系统-评价结果追踪.md) | 评价提交、展示核验、结果回流 |
   542|| [08-子系统-KOC-KOL协作](08-子系统-KOC-KOL协作.md) | KOC/KOL 匹配、内容跟踪、JOYCOLLAB 同步 |
   543|| [09-子系统-审计与通知中心](09-子系统-审计与通知中心.md) | 审计日志、多类型通知告警 |
   544|