42 KiB
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-用户身份与上下文 | 107|| S2 | 需求与计划管理 |planning| 需求触发（人工/自动）、计划生成（推新/回评/免评）、审批工作流 | 02-需求与计划管理 | 108|| S3 | 额度与频控 |quota| 月度测评/免评额度台账、累计评价额度、频控、预占 | 03-额度与频控 | 109|| S4 | 多渠道触达引擎 |outreach| IM/EDM/APP Push/TEL 渠道调度、路由、去重、发送 | 04-多渠道触达引擎 | 110|| S5 | 客服工单与管理 |support| 工单生命周期、自动分配、排班出勤、绩效统计 | 05-客服工单与管理 | 111|| S6 | 风险与反欺诈 |risk| 强弱关联判断、黑名单、双重退款检测、风险事件 | 06-风险与反欺诈 | 112|| S7 | 评价结果追踪 |review| 评价提交记录、Amazon 展示核验、ASIN 健康回流 | 07-评价结果追踪 | 113|| S8 | KOC/KOL 协作 |creator| KOC/KOL 匹配、内容跟踪、Code 管理、JOYCOLLAB 同步 | 08-KOC-KOL协作 | 114|| S9 | 审计与通知中心 |audit| 状态变更审计、敏感访问日志、多类型通知/告警 | 09-审计与通知中心 | 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-子系统-用户身份与上下文 | 真实人归并、用户上下文卡、设备识别 | 536|| 02-子系统-需求与计划管理 | 需求触发、计划生命周期、审批工作流 | 537|| 03-子系统-额度与频控 | 额度台账、频控引擎、预占释放 | 538|| 04-子系统-多渠道触达引擎 | IM/EDM/APP/TEL 调度与执行 | 539|| 05-子系统-客服工单与管理 | 工单管理、客服管理支撑 | 540|| 06-子系统-风险与反欺诈 | 风险判断、黑名单、双重退款 | 541|| 07-子系统-评价结果追踪 | 评价提交、展示核验、结果回流 | 542|| 08-子系统-KOC-KOL协作 | KOC/KOL 匹配、内容跟踪、JOYCOLLAB 同步 | 543|| 09-子系统-审计与通知中心 | 审计日志、多类型通知告警 | 544|