qiaoxinjiu/Fulfilled-Knowledge
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add under-anything knowledge dashboard

Browse Source
This commit is contained in:
qiaoxinjiu
2026-05-27 15:40:32 +08:00
commit e31a75d2bb
565 changed files with 143063 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

544
wishfulfilled-wiki/05_需求文档/00-系统总览.md Normal file
View File

@@ -0,0 +1,544 @@
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|