544 lines
42 KiB
Markdown
544 lines
42 KiB
Markdown
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| |