{ "version": "1.0.0", "kind": "knowledge", "project": { "name": "知识地图", "languages": [ "markdown" ], "frameworks": [ "karpathy-wiki" ], "description": "Knowledge graph for 知识地图", "analyzedAt": "2026-05-27T02:58:24.412854+00:00", "gitCommitHash": "" }, "nodes": [ { "id": "article:00_首页/Agent问答入口", "type": "article", "name": "Agent 问答入口", "filePath": "00_首页\\Agent问答入口.md", "summary": "当用户询问业务或项目流程时，Agent 应先检索本知识库 Markdown 文件，再组织回答。", "tags": [ "00_首页", "[Agent", "检索]", "问答" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: agent_entry\ntags: [Agent, 问答, 检索]\naliases: [问答入口, Agent入口]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# Agent 问答入口\n\n当用户询问业务或项目流程时，Agent 应先检索本知识库 Markdown 文件，再组织回答。\n\n## 推荐检索顺序\n\n1. `05_需求文档/`：持续新增的业务需求、业务规则、需求变更。\n2. `06_里程碑/`：项目节点、阶段计划、阶段评审、上线节奏。\n3. `07_技术文档/`：架构、接口、数据模型、实现方案、技术决策。\n4. `08_测试相关/`：测试计划、测试用例、缺陷、验收、上线检查。\n5. `02_项目管理流程/`：阶段、角色、交付物、门禁、检查清单。\n6. `01_业务流程/`：具体业务流程、业务对象、业务规则。\n7. `04_Agent检索/`：关键词、同义词、回答规则、来源索引。\n8. `03_规范与模板/`：需要产出文档或表单时检索。\n\n## 回答格式\n\n- 先给结论。\n- 再按阶段、负责人、输入、关键动作、输出、检查点说明。\n- 最后注明来源文件。\n- 若知识库没有明确记录，回答“知识库未明确记录”，并说明建议补充到哪个文件。\n\n## 示例问题\n\n- 一个内部系统需求从提出到上线要走哪些阶段？\n- 阶段2.5测试提前补漏要产出什么？\n- 业务主管在项目入口分级中负责什么？\n- 什么时候需要前端提前参与需求收敛？\n- 新增一条业务规则后，怎么验证 Agent 能搜到？\n- 某个业务规则应该补充到哪个模板里？\n- 某个需求对应哪些测试用例？\n- 某个模块有哪些接口说明？\n- 这个项目当前处在哪个里程碑？\n\n## 业务补充验证入口\n\n- 需求文档目录：`05_需求文档/`\n- 里程碑目录：`06_里程碑/`\n- 技术文档目录：`07_技术文档/`\n- 测试相关目录：`08_测试相关/`\n- 需求文档索引：`05_需求文档/需求文档索引.md`\n- 测试用例索引：`08_测试相关/测试用例索引.md`\n- 模板：`03_规范与模板/业务规则与需求补充模板.md`\n- 流程：`04_Agent检索/知识库持续更新与验证流程.md`\n- 记录：`01_业务流程/业务补充验证记录.md`\n", "backlinks": [ "article:00_首页/知识库首页", "article:欢迎", "article:知识库使用说明", "article:知识库使用说明" ] } }, { "id": "article:00_首页/知识地图", "type": "article", "name": "知识地图", "filePath": "00_首页\\知识地图.md", "summary": "- [[../知识库使用说明|知识库使用说明]] - [[../Git使用说明|Git 使用说明]]", "tags": [ "00_首页", "[知识地图", "导航]" ], "complexity": "complex", "knowledgeMeta": { "wikilinks": [ "../知识库使用说明", "../Git使用说明", "../05_需求文档/README", "../05_需求文档/需求文档索引", "../03_规范与模板/需求说明模板", "../03_规范与模板/业务规则与需求补充模板", "../01_业务流程/业务规则索引", "../01_业务流程/业务对象字典", "../06_里程碑/README", "../06_里程碑/里程碑索引", "../06_里程碑/阶段计划模板", "../06_里程碑/里程碑评审记录", "../02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "../02_项目管理流程/阶段交付物清单", "../02_项目管理流程/项目检查清单", "../07_技术文档/README", "../07_技术文档/技术文档索引", "../07_技术文档/系统架构说明模板", "../07_技术文档/接口说明模板", "../07_技术文档/技术决策记录", "../08_测试相关/README", "../08_测试相关/测试用例索引", "../08_测试相关/测试用例模板", "../08_测试相关/测试计划模板", "../08_测试相关/缺陷记录模板", "../08_测试相关/验收记录模板", "../08_测试相关/上线检查模板", "../02_项目管理流程/阶段2.5_测试提前补漏", "../02_项目管理流程/阶段4_测试培训上线回流", "../04_Agent检索/检索说明", "../04_Agent检索/问答提示词", "../04_Agent检索/关键词索引", "../04_Agent检索/同义词表", "../04_Agent检索/来源文件索引", "../04_Agent检索/知识库持续更新与验证流程" ], "content": "---\ntype: map\ntags: [知识地图, 导航]\naliases: [知识库地图]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 知识地图\n\n## 使用说明\n\n- [[../知识库使用说明|知识库使用说明]]\n- [[../Git使用说明|Git 使用说明]]\n\n## 需求文档\n\n- [[../05_需求文档/README|需求文档入口]]\n- [[../05_需求文档/需求文档索引|需求文档索引]]\n- [[../03_规范与模板/需求说明模板|需求说明模板]]\n- [[../03_规范与模板/业务规则与需求补充模板|业务规则与需求补充模板]]\n- [[../01_业务流程/业务规则索引|业务规则索引]]\n- [[../01_业务流程/业务对象字典|业务对象字典]]\n\n## 里程碑\n\n- [[../06_里程碑/README|里程碑入口]]\n- [[../06_里程碑/里程碑索引|里程碑索引]]\n- [[../06_里程碑/阶段计划模板|阶段计划模板]]\n- [[../06_里程碑/里程碑评审记录|里程碑评审记录]]\n- [[../02_项目管理流程/AI驱动内部系统开发流程_V3_总览|项目管理流程总览]]\n- [[../02_项目管理流程/阶段交付物清单|阶段交付物清单]]\n- [[../02_项目管理流程/项目检查清单|项目检查清单]]\n\n## 技术文档\n\n- [[../07_技术文档/README|技术文档入口]]\n- [[../07_技术文档/技术文档索引|技术文档索引]]\n- [[../07_技术文档/系统架构说明模板|系统架构说明模板]]\n- [[../07_技术文档/接口说明模板|接口说明模板]]\n- [[../07_技术文档/技术决策记录|技术决策记录]]\n\n## 测试相关\n\n- [[../08_测试相关/README|测试相关入口]]\n- [[../08_测试相关/测试用例索引|测试用例索引]]\n- [[../08_测试相关/测试用例模板|测试用例模板]]\n- [[../08_测试相关/测试计划模板|测试计划模板]]\n- [[../08_测试相关/缺陷记录模板|缺陷记录模板]]\n- [[../08_测试相关/验收记录模板|验收记录模板]]\n- [[../08_测试相关/上线检查模板|上线检查模板]]\n- [[../02_项目管理流程/阶段2.5_测试提前补漏|阶段2.5 测试提前补漏]]\n- [[../02_项目管理流程/阶段4_测试培训上线回流|阶段4 测试培训上线回流]]\n\n## Agent 检索\n\n- [[../04_Agent检索/检索说明|检索说明]]\n- [[../04_Agent检索/问答提示词|问答提示词]]\n- [[../04_Agent检索/关键词索引|关键词索引]]\n- [[../04_Agent检索/同义词表|同义词表]]\n- [[../04_Agent检索/来源文件索引|来源文件索引]]\n- [[../04_Agent检索/知识库持续更新与验证流程|持续更新与验证流程]]\n", "backlinks": [ "article:00_首页/知识库首页", "article:欢迎", "article:知识库使用说明", "article:知识库使用说明" ] } }, { "id": "article:00_首页/知识库首页", "type": "article", "name": "如愿知识库首页", "filePath": "00_首页\\知识库首页.md", "summary": "本知识库用于沉淀如愿内部系统建设中的业务流程、项目管理流程、角色职责、交付物、检查清单与 Agent 检索问答规范。", "tags": [ "00_首页", "[知识库", "如愿]", "首页" ], "complexity": "moderate", "knowledgeMeta": { "wikilinks": [ "../知识库使用说明", "知识地图", "Agent问答入口", "../05_需求文档/README", "../06_里程碑/README", "../07_技术文档/README", "../08_测试相关/README", "../04_Agent检索/检索说明" ], "content": "---\ntype: index\ntags: [知识库, 首页, 如愿]\naliases: [如愿知识库首页, 知识库入口]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 如愿知识库首页\n\n本知识库用于沉淀如愿内部系统建设中的业务流程、项目管理流程、角色职责、交付物、检查清单与 Agent 检索问答规范。\n\n## 快速入口\n\n- [[../知识库使用说明|知识库使用说明]]\n- [[知识地图]]\n- [[Agent问答入口]]\n- [[../05_需求文档/README|需求文档]]\n- [[../06_里程碑/README|里程碑]]\n- [[../07_技术文档/README|技术文档]]\n- [[../08_测试相关/README|测试相关]]\n- [[../04_Agent检索/检索说明|Agent 检索说明]]\n\n## 当前权威来源\n\n- 项目管理流程：`AI_驱动_内部系统开发流程_V3.docx`\n- 适用范围：ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。\n\n## 使用原则\n\n1. 需求类问题先查需求文档。\n2. 进度、节点、准入问题先查里程碑。\n3. 技术实现、接口、架构问题先查技术文档。\n4. 测试范围、用例、验收、缺陷问题先查测试相关。\n5. Agent 回答必须说明来源文件。\n6. 知识库没有明确记录时，不要猜测，应提示补充位置。\n", "backlinks": [ "article:欢迎", "article:知识库使用说明" ] } }, { "id": "article:01_业务流程/README", "type": "article", "name": "业务流程", "filePath": "01_业务流程\\README.md", "summary": "本目录用于沉淀真实业务流程。第一阶段先建立模板、业务对象字典和业务规则索引，后续按流程逐条补充。", "tags": [ "01_业务流程", "[业务流程", "入口]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [ "业务流程模板", "业务对象字典", "业务规则索引", "../02_项目管理流程/阶段1_业务需求完整形成", "../02_项目管理流程/阶段2_高保真模型与业务对象确认" ], "content": "---\ntype: index\ntags: [业务流程, 入口]\naliases: [业务流程入口]\nsource: manual\nstatus: active\nowner: 业务主管\nupdated: 2026-05\n---\n\n# 业务流程\n\n本目录用于沉淀真实业务流程。第一阶段先建立模板、业务对象字典和业务规则索引，后续按流程逐条补充。\n\n## 当前文件\n\n- [[业务流程模板]]\n- [[业务对象字典]]\n- [[业务规则索引]]\n\n## 录入要求\n\n每条业务流程至少补充：流程名称、适用角色、触发条件、主流程、分支流程、异常处理、输入数据、输出结果、相关系统、业务规则、常见问题、关联项目管理阶段。\n\n## 与项目管理流程的关系\n\n业务流程内容主要用于支撑 [[../02_项目管理流程/阶段1_业务需求完整形成|阶段1 业务需求完整形成]] 和 [[../02_项目管理流程/阶段2_高保真模型与业务对象确认|阶段2 高保真模型与业务对象确认]]。\n", "backlinks": [] } }, { "id": "article:01_业务流程/业务对象字典", "type": "article", "name": "业务对象字典", "filePath": "01_业务流程\\业务对象字典.md", "summary": "用于沉淀业务对象、字段、状态和生命周期，是页面、接口、数据库、测试、AI 提示词的共同基础。", "tags": [ "01_业务流程", "[业务对象", "字典]", "数据对象" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [ "../02_项目管理流程/阶段2_高保真模型与业务对象确认", "../02_项目管理流程/阶段交付物清单" ], "content": "---\ntype: dictionary\ntags: [业务对象, 数据对象, 字典]\naliases: [业务对象模型, 对象字典]\nsource: manual\nstatus: draft\nowner: 业务主管\nupdated: 2026-05\n---\n\n# 业务对象字典\n\n用于沉淀业务对象、字段、状态和生命周期，是页面、接口、数据库、测试、AI 提示词的共同基础。\n\n## 对象清单\n\n| 业务对象 | 定义 | 关键字段 | 状态 | 关联流程 | 备注 |\n|---|---|---|---|---|---|\n| | | | | | |\n\n## 维护规则\n\n- 阶段2必须确认统一业务对象模型。\n- 新增页面、接口、数据库表或测试用例时，应回查本字典。\n- 字段含义、状态枚举和对象关系不明确时，不应进入正式开发。\n\n## 关联条目\n\n- [[../02_项目管理流程/阶段2_高保真模型与业务对象确认]]\n- [[../02_项目管理流程/阶段交付物清单]]\n", "backlinks": [ "article:01_业务流程/README", "article:知识库使用说明" ] } }, { "id": "article:01_业务流程/业务流程模板", "type": "article", "name": "业务流程模板", "filePath": "01_业务流程\\业务流程模板.md", "summary": "- 流程名称： - 适用部门： - 适用角色： - 相关系统： - 流程负责人： - 当前状态：draft / active / deprecated", "tags": [ "01_业务流程", "[业务流程", "模板]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [ "../02_项目管理流程/阶段1_业务需求完整形成", "../02_项目管理流程/阶段2_高保真模型与业务对象确认" ], "content": "---\ntype: template\ntags: [业务流程, 模板]\naliases: [业务流程梳理模板]\nsource: manual\nstatus: active\nowner: 业务主管\nupdated: 2026-05\n---\n\n# 业务流程模板\n\n## 基本信息\n\n- 流程名称：\n- 适用部门：\n- 适用角色：\n- 相关系统：\n- 流程负责人：\n- 当前状态：draft / active / deprecated\n\n## 触发条件\n\n说明什么情况下进入该流程。\n\n## 前置条件\n\n说明流程开始前必须满足的条件、权限、数据或审批。\n\n## 主流程\n\n1. \n2. \n3. \n\n## 分支流程\n\n| 分支场景 | 判断条件 | 处理方式 | 负责人 | 输出 |\n|---|---|---|---|---|\n| | | | | |\n\n## 异常处理\n\n| 异常场景 | 发现方式 | 处理方式 | 升级路径 |\n|---|---|---|---|\n| | | | |\n\n## 输入数据\n\n| 数据项 | 来源 | 必填 | 说明 |\n|---|---|---|---|\n| | | | |\n\n## 输出结果\n\n| 输出物 | 接收方 | 用途 |\n|---|---|---|\n| | | |\n\n## 业务规则\n\n- \n\n## 常见问题\n\n- 问：\n 答：\n\n## 关联项目管理阶段\n\n- [[../02_项目管理流程/阶段1_业务需求完整形成]]\n- [[../02_项目管理流程/阶段2_高保真模型与业务对象确认]]\n", "backlinks": [ "article:01_业务流程/README" ] } }, { "id": "article:01_业务流程/业务补充验证记录", "type": "article", "name": "业务补充验证记录", "filePath": "01_业务流程\\业务补充验证记录.md", "summary": "每次新增或修订 `01_业务流程/` 下的业务规则、需求或流程文档后，在此记录 Agent 检索验证结果。", "tags": [ "01_业务流程", "Agent检索]", "[业务流程", "业务规则", "验证记录" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: validation_log\ntags: [业务流程, 业务规则, 验证记录, Agent检索]\naliases: [业务补充验证, Agent问答验证记录]\nsource: manual\nstatus: active\nowner: 产品经理 / 内部技术团队\nupdated: 2026-05\n---\n\n# 业务补充验证记录\n\n## 使用说明\n\n每次新增或修订 `01_业务流程/` 下的业务规则、需求或流程文档后，在此记录 Agent 检索验证结果。\n\n## 验证记录\n\n| 日期 | 业务域 | 新增/修订文件 | 验证问题 | 是否命中 | 来源文件 | 结果 | 待补充 |\n|---|---|---|---|---|---|---|---|\n| | | | | 是/否 | | 通过/失败 | |\n\n## 验证结论模板\n\n```markdown\n### YYYY-MM-DD 业务域_规则或需求名称\n\n- 新增/修订文件：\n- 已更新索引：业务规则索引 / 业务对象字典 / 关键词索引 / 同义词表 / 来源文件索引\n- 验证问题：\n 1. \n 2. \n 3. \n- 结论：通过 / 失败\n- 待补充：\n```\n", "backlinks": [] } }, { "id": "article:01_业务流程/业务规则索引", "type": "article", "name": "业务规则索引", "filePath": "01_业务流程\\业务规则索引.md", "summary": "用于集中记录跨流程复用的业务规则，避免规则散落在需求、页面和测试用例中。", "tags": [ "01_业务流程", "[业务规则", "索引]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: index\ntags: [业务规则, 索引]\naliases: [规则索引]\nsource: manual\nstatus: draft\nowner: 业务主管\nupdated: 2026-05\n---\n\n# 业务规则索引\n\n用于集中记录跨流程复用的业务规则，避免规则散落在需求、页面和测试用例中。\n\n| 规则编号 | 规则名称 | 适用流程 | 规则说明 | 来源 | 状态 |\n|---|---|---|---|---|---|\n| BR-001 | | | | | draft |\n\n## 维护要求\n\n- 规则必须能追溯到业务流程或项目文档。\n- 涉及权限、状态流转、金额、时间、审批、异常处理的规则应优先沉淀。\n- 规则变更后，应同步检查测试用例和上线培训材料。\n- 新增规则建议使用 `03_规范与模板/业务规则与需求补充模板.md`。\n- 新增或修订后，按 `04_Agent检索/知识库持续更新与验证流程.md` 执行 Agent 检索验证。\n", "backlinks": [ "article:01_业务流程/README", "article:知识库使用说明" ] } }, { "id": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "type": "article", "name": "AI 驱动内部系统开发流程 V3 总览", "filePath": "02_项目管理流程\\AI驱动内部系统开发流程_V3_总览.md", "summary": "本流程适用于公司当前阶段的 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。", "tags": [ "02_项目管理流程", "AI驱动开发", "ERP", "[项目管理流程", "内部系统]" ], "complexity": "moderate", "knowledgeMeta": { "wikilinks": [ "阶段0_项目入口分级", "阶段1_业务需求完整形成", "阶段2_高保真模型与业务对象确认", "阶段2.5_测试提前补漏", "阶段3_研发协作与正式开发", "阶段4_测试培训上线回流", "角色职责矩阵", "阶段交付物清单", "项目检查清单" ], "content": "---\ntype: process_overview\ntags: [项目管理流程, AI驱动开发, ERP, 内部系统]\naliases: [AI驱动内部系统开发流程, 内部系统开发流程V3, ERP开发流程]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# AI 驱动内部系统开发流程 V3 总览\n\n## 版本定位\n\n本流程适用于公司当前阶段的 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。\n\n核心目标不是让流程变复杂，而是解决以下问题：\n\n- 业务需求说不清。\n- AI 生成内容不完整。\n- 前端模型介入太晚。\n- 后端数据库设计被页面倒逼。\n- 测试太晚才发现需求漏项。\n- 项目完成后留下大量重复代码和技术债。\n\n## 总体阶段\n\n| 阶段 | 阶段名称 | 核心目标 | 核心负责人 |\n|---|---|---|---|\n| 阶段0 | 项目入口分级 | 判断项目是否值得做、走轻流程还是完整流程 | 业务主管 / 技术负责人 |\n| 阶段1 | 业务需求完整形成 | 业务侧通过 Vibe Coding 跑完整需求 | 业务主管 / 业务人员 |\n| 阶段2 | 高保真模型与业务对象确认 | 把完整但粗糙的需求收敛成可开发模型 | 前端 / 产品经理 |\n| 阶段2.5 | 测试提前补漏 | 在开发前用测试视角发现需求漏洞 | 测试 |\n| 阶段3 | 研发协作与正式开发 | 基于高保真模型进行模块化、安全、可维护开发 | 前端 / 后端 / 算法 |\n| 阶段4 | 测试、培训、上线、回流 | 完成测试、培训、上线验收和问题回流 | 测试 / 业务主管 |\n| 阶段5 | 技术债治理与能力沉淀 | 清理 AI 冗余代码并沉淀复用能力 | 技术负责人 |\n\n## 阶段门禁\n\n| 门禁 | 通过标准 |\n|---|---|\n| Gate 0 | 项目入口通过：确认值得做，确认项目类型。 |\n| Gate 1 | 需求完整通过：主流程、分支、页面、按钮、字段、状态大致完整。 |\n| Gate 2 | 高保真模型通过：页面收敛、按钮行为、业务对象、状态、V1/V2 明确。 |\n| Gate 2.5 | 测试补漏：测试用例初稿发现的阻塞问题已处理。 |\n| Gate 3 | 开发联调通过：前后端、数据库、权限、安全、主要流程联调完成。 |\n| Gate 4 | 上线验收通过：测试通过、业务确认、培训完成。 |\n| Gate 5 | 技术债治理完成：重复代码、组件、接口、数据结构完成治理或进入债务池。 |\n\n## 完整版文件结构\n\n- `00_项目入口分级.md`\n- `01_主流程说明.md`\n- `02_日常操作页面结构.md`\n- `03_功能页面按钮盘点表.md`\n- `04_分支流程_XXX.md`\n- `05_异常流程_XXX.md`\n- `06_VibeCoding页面验证记录.md`\n- `07_高保真模型.html`\n- `07_高保真模型说明.md`\n- `08_项目周期与版本确认.md`\n- `09_前端技术评审.md`\n- `10_技术预检记录.md`\n- `10A_统一业务对象模型.md`\n- `10B_按钮行为矩阵.md`\n- `11_测试用例初稿与需求补漏.md`\n- `12_研发任务拆分与协作计划.md`\n- `13_技术实现对接.md`\n- `14_代码治理与安全规范.md`\n- `15_开发问题与联调记录.md`\n- `16_正式测试报告.md`\n- `17_内部培训手册.md`\n- `18_上线验收记录.md`\n- `19_上线问题与回流需求.md`\n- `20_技术债清单.md`\n- `21_业务原子能力沉淀清单.md`\n- `22_组件库与服务复用清单.md`\n- `23_AI开发上下文模板更新记录.md`\n\n## 轻量版文件结构\n\n小项目可以使用轻量版：\n\n- `00_项目入口分级.md`\n- `01_业务需求包.md`\n- `02_高保真模型包.md`\n- `03_项目版本与技术预检.md`\n- `04_测试用例初稿与需求补漏.md`\n- `05_研发协作与技术实现包.md`\n- `06_代码治理与安全规范.md`\n- `07_测试培训上线包.md`\n- `08_技术债与能力沉淀包.md`\n\n## 最终核心原则\n\n- 先分级，再开发。\n- 阶段1追求需求完整，不追求产品完善。\n- Vibe Coding 页面只是需求原型，不直接进入生产。\n- 阶段2追求模型高效，前端必须深度参与。\n- 高保真模型确认后，才允许正式开发。\n- 统一业务对象模型是页面、接口、数据库、测试、AI 提示词的共同基础。\n- 性能、安全、权限、并发、日志、可回滚必须提前预检。\n- 测试提前补漏，不只是上线前找 Bug。\n- 研发阶段以代码质量、模块化、安全性、可维护性为中心。\n- AI 代码必须治理，不能直接堆进生产。\n- 每个项目都要沉淀业务原子能力。\n- 每完成 3-4 个项目，必须进行技术债治理。\n\n## 一句话总结\n\n这套流程不是为了让 AI 替代开发，而是让 AI 帮业务更快形成完整需求，让前端和产品把需求收敛成高保真模型，让研发团队基于模型高质量开发，让测试和技术债治理保障系统长期可用。\n\n## 关联条目\n\n- [[阶段0_项目入口分级]]\n- [[阶段1_业务需求完整形成]]\n- [[阶段2_高保真模型与业务对象确认]]\n- [[阶段2.5_测试提前补漏]]\n- [[阶段3_研发协作与正式开发]]\n- [[阶段4_测试培训上线回流]]\n- [[角色职责矩阵]]\n- [[阶段交付物清单]]\n- [[项目检查清单]]\n", "backlinks": [ "article:02_项目管理流程/README", "article:02_项目管理流程/常见问题FAQ", "article:02_项目管理流程/常见问题FAQ", "article:02_项目管理流程/角色职责矩阵", "article:02_项目管理流程/阶段0_项目入口分级", "article:02_项目管理流程/阶段交付物清单", "article:02_项目管理流程/项目检查清单", "article:知识库使用说明" ] } }, { "id": "article:02_项目管理流程/README", "type": "article", "name": "项目管理流程", "filePath": "02_项目管理流程\\README.md", "summary": "本目录基于 `AI_驱动_内部系统开发流程_V3.docx` 拆解，用于指导 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。", "tags": [ "02_项目管理流程", "AI驱动开发]", "[项目管理流程" ], "complexity": "moderate", "knowledgeMeta": { "wikilinks": [ "AI驱动内部系统开发流程_V3_总览", "阶段0_项目入口分级", "阶段1_业务需求完整形成", "阶段2_高保真模型与业务对象确认", "阶段2.5_测试提前补漏", "阶段3_研发协作与正式开发", "阶段4_测试培训上线回流", "角色职责矩阵", "阶段交付物清单", "项目检查清单", "常见问题FAQ" ], "content": "---\ntype: index\ntags: [项目管理流程, AI驱动开发]\naliases: [项目管理流程入口, 开发流程入口]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 项目管理流程\n\n本目录基于 `AI_驱动_内部系统开发流程_V3.docx` 拆解，用于指导 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。\n\n## 阶段文件\n\n- [[AI驱动内部系统开发流程_V3_总览]]\n- [[阶段0_项目入口分级]]\n- [[阶段1_业务需求完整形成]]\n- [[阶段2_高保真模型与业务对象确认]]\n- [[阶段2.5_测试提前补漏]]\n- [[阶段3_研发协作与正式开发]]\n- [[阶段4_测试培训上线回流]]\n\n## 重组索引\n\n- [[角色职责矩阵]]\n- [[阶段交付物清单]]\n- [[项目检查清单]]\n- [[常见问题FAQ]]\n\n## 核心原则\n\n先分级，再开发。阶段1追求需求完整，不追求产品完善。高保真模型确认后，才允许正式开发。测试要提前补漏。AI 代码必须治理，不能直接堆进生产。\n", "backlinks": [] } }, { "id": "article:02_项目管理流程/常见问题FAQ", "type": "article", "name": "常见问题 FAQ", "filePath": "02_项目管理流程\\常见问题FAQ.md", "summary": "通常经过阶段0项目入口分级、阶段1业务需求完整形成、阶段2高保真模型与业务对象确认、阶段2.5测试提前补漏、阶段3研发协作与正式开发、阶段4测试培训上线回流。文档还定义了阶段5技术债治理与能力沉淀。", "tags": [ "02_项目管理流程", "FAQ", "[项目管理流程", "问答]" ], "complexity": "moderate", "knowledgeMeta": { "wikilinks": [ "AI驱动内部系统开发流程_V3_总览", "阶段0_项目入口分级", "角色职责矩阵", "阶段1_业务需求完整形成", "阶段2.5_测试提前补漏", "阶段2.5_测试提前补漏", "阶段交付物清单", "阶段2_高保真模型与业务对象确认", "阶段3_研发协作与正式开发", "阶段4_测试培训上线回流", "项目检查清单", "阶段1_业务需求完整形成", "AI驱动内部系统开发流程_V3_总览" ], "content": "---\ntype: faq\ntags: [项目管理流程, FAQ, 问答]\naliases: [流程常见问题, 项目管理问答]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 常见问题 FAQ\n\n## 一个内部系统需求从提出到上线要走哪些阶段？\n\n通常经过阶段0项目入口分级、阶段1业务需求完整形成、阶段2高保真模型与业务对象确认、阶段2.5测试提前补漏、阶段3研发协作与正式开发、阶段4测试培训上线回流。文档还定义了阶段5技术债治理与能力沉淀。\n\n来源：[[AI驱动内部系统开发流程_V3_总览]]\n\n## 阶段0项目入口分级由谁负责？\n\n由业务主管和技术负责人共同负责。业务主管判断业务价值和范围，技术负责人判断技术复杂度和风险。\n\n来源：[[阶段0_项目入口分级]]、[[角色职责矩阵]]\n\n## 业务需求完整形成阶段的目标是什么？\n\n业务侧通过 Vibe Coding 跑完整需求。阶段1追求需求完整，不追求产品完善。\n\n来源：[[阶段1_业务需求完整形成]]\n\n## 阶段2.5测试提前补漏应该在什么时候发生？\n\n发生在高保真模型确认后、正式开发前。\n\n来源：[[阶段2.5_测试提前补漏]]\n\n## 阶段2.5测试提前补漏要产出什么？\n\n主要产出 `11_测试用例初稿与需求补漏.md`，并形成需求补漏记录、阻塞问题清单和已关闭问题清单。\n\n来源：[[阶段2.5_测试提前补漏]]、[[阶段交付物清单]]\n\n## 什么时候需要前端提前参与需求收敛？\n\n阶段2必须由前端深度参与。若需求涉及多页面、复杂交互、权限、状态流转、数据结构或组件复用，前端应在需求收敛时提前参与。\n\n来源：[[阶段2_高保真模型与业务对象确认]]\n\n## 研发协作与正式开发阶段如何保证模块化、安全和可维护？\n\n依赖统一业务对象模型、研发任务拆分、技术实现对接、代码治理与安全规范、开发问题与联调记录。AI 代码必须经过治理，不能直接堆进生产。\n\n来源：[[阶段3_研发协作与正式开发]]\n\n## 上线前需要检查哪些事项？\n\n至少检查正式测试、主流程、分支流程、权限、异常、数据边界、内部培训手册、业务确认、上线问题回流机制。\n\n来源：[[阶段4_测试培训上线回流]]、[[项目检查清单]]\n\n## Vibe Coding 页面能不能直接进入生产？\n\n不能。Vibe Coding 页面只是需求原型，不直接进入生产。\n\n来源：[[阶段1_业务需求完整形成]]、[[AI驱动内部系统开发流程_V3_总览]]\n", "backlinks": [ "article:02_项目管理流程/README" ] } }, { "id": "article:02_项目管理流程/角色职责矩阵", "type": "article", "name": "角色职责矩阵", "filePath": "02_项目管理流程\\角色职责矩阵.md", "summary": "| 角色 | 主要负责阶段 | 核心职责 | 典型产出 | |---|---|---|---| | 业务主管 | 阶段0、阶段1、阶段4 | 判断项目价值、明确主流程、确认业务完整性、上线验收 | 项目入口分级、主流程说明、业务验收口径、上线验收记录 | | 业务人员 | 阶段1 | 补充分支流程、提供样本数据、验证真实操作路径 | 分支流程、异常流程、Vibe Coding 页面验证记录 ...", "tags": [ "02_项目管理流程", "RACI]", "[项目管理流程", "角色职责" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [ "AI驱动内部系统开发流程_V3_总览", "阶段0_项目入口分级", "阶段1_业务需求完整形成", "阶段2.5_测试提前补漏", "阶段4_测试培训上线回流" ], "content": "---\ntype: responsibility_matrix\ntags: [项目管理流程, 角色职责, RACI]\naliases: [角色职责, 职责矩阵, RACI]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 角色职责矩阵\n\n## 总览\n\n| 角色 | 主要负责阶段 | 核心职责 | 典型产出 |\n|---|---|---|---|\n| 业务主管 | 阶段0、阶段1、阶段4 | 判断项目价值、明确主流程、确认业务完整性、上线验收 | 项目入口分级、主流程说明、业务验收口径、上线验收记录 |\n| 业务人员 | 阶段1 | 补充分支流程、提供样本数据、验证真实操作路径 | 分支流程、异常流程、Vibe Coding 页面验证记录 |\n| 产品经理 | 阶段2 | 收敛需求、组织高保真模型、明确版本范围 | 高保真模型说明、项目周期与版本确认 |\n| 前端 | 阶段2、阶段3 | 深度参与模型收敛、页面结构、按钮行为、组件复用、前端开发 | 高保真模型、前端技术评审、按钮行为矩阵、前端实现 |\n| 后端 | 阶段3 | 设计接口、数据库、权限、安全、日志、回滚和服务能力 | 技术实现对接、后端服务、接口和数据库方案 |\n| 算法 | 阶段3 | 判断是否需要 AI，设计输入输出、置信度、人工审核和风险控制 | 算法适用性判断、算法输入输出说明、置信度规则 |\n| 测试 | 阶段2.5、阶段4 | 提前写测试用例、发现需求漏洞、正式测试、培训材料、上线反馈 | 测试用例初稿、正式测试报告、内部培训手册、上线问题回流 |\n| 技术负责人 | 阶段0、阶段5 | 技术分级、风险判断、技术债治理和能力沉淀 | 技术债清单、业务原子能力沉淀清单、组件库与服务复用清单 |\n\n## 业务主管\n\n业务主管保证方向正确、主流程清楚、需求不漏大块。\n\n职责：\n\n- 判断项目是否值得做。\n- 定义主流程。\n- 定义日常操作入口。\n- 明确业务人员每天先看什么页面。\n- 拆分分支流程，指定业务人员补充。\n- 确认异常流程。\n- 确认业务完整性。\n- 参与业务验收。\n\n## 业务人员\n\n业务人员负责具体分支流程和真实操作细节。\n\n职责：\n\n- 补充分支流程。\n- 提供样本数据，例如 ASIN、订单、评论、用户、表格等真实样本。\n- 使用 Vibe Coding 跑页面，验证是否符合真实操作。\n- 补充异常场景。\n\n## 算法\n\n算法保证 AI 能力可控、可解释、可人工审核。\n\n职责：\n\n- 判断是否需要 AI，避免为了 AI 而 AI。\n- 设计算法输入，明确模型需要哪些数据。\n- 设计算法输出，明确 AI 返回什么结果。\n- 制定置信度规则。\n- 制定人工审核机制。\n- 设计风险控制，确保 AI 判断错误时可以回退和纠正。\n\n## 测试\n\n测试不只是最后找 Bug，还要提前补漏，并负责内部培训材料。\n\n职责：\n\n- 高保真模型出来后先写测试用例。\n- 用测试视角发现流程、按钮、权限遗漏。\n- 正式测试主流程、分支流程、权限、异常和数据。\n- 输出验收报告。\n- 将测试用例转成业务操作手册。\n- 记录上线问题并回流需求池。\n\n## 关联条目\n\n- [[AI驱动内部系统开发流程_V3_总览]]\n- [[阶段0_项目入口分级]]\n- [[阶段1_业务需求完整形成]]\n- [[阶段2.5_测试提前补漏]]\n- [[阶段4_测试培训上线回流]]\n", "backlinks": [ "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "article:02_项目管理流程/README", "article:02_项目管理流程/常见问题FAQ", "article:02_项目管理流程/阶段0_项目入口分级", "article:02_项目管理流程/阶段1_业务需求完整形成" ] } }, { "id": "article:02_项目管理流程/阶段0_项目入口分级", "type": "article", "name": "阶段0 项目入口分级", "filePath": "02_项目管理流程\\阶段0_项目入口分级.md", "summary": "不是所有需求都应该进入完整开发流程。阶段0用于判断项目是否值得做，以及走轻流程还是完整流程。", "tags": [ "02_项目管理流程", "[项目管理流程", "分级", "立项]", "阶段0", "项目入口" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [ "AI驱动内部系统开发流程_V3_总览", "角色职责矩阵", "阶段交付物清单" ], "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段0, 项目入口, 分级, 立项]\naliases: [项目入口分级, 入口分级, Gate 0, 立项分级]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 业务主管 / 技术负责人\nupdated: 2026-05\n---\n\n# 阶段0 项目入口分级\n\n## 核心目标\n\n不是所有需求都应该进入完整开发流程。阶段0用于判断项目是否值得做，以及走轻流程还是完整流程。\n\n## 负责人\n\n- 业务主管\n- 技术负责人\n\n## 输入\n\n- 业务提出的问题或机会。\n- 现有系统痛点。\n- 业务收益、风险、范围的初步判断。\n\n## 项目分类\n\n| 类型 | 适用场景 | 流程要求 |\n|---|---|---|\n| S 类 | 小需求，单页面、小改动、无复杂数据 | 可简化阶段1和阶段2。 |\n| M 类 | 中等需求，涉及多个页面、多个角色或状态流转 | 建议走完整阶段0-4。 |\n| L 类 | 大型需求，涉及核心流程、多个部门、复杂权限、数据模型或算法 | 必须走完整流程，并强化技术预检和阶段门禁。 |\n\n## 关键动作\n\n- 判断需求是否值得做。\n- 判断项目影响范围。\n- 判断是否需要完整流程。\n- 判断是否涉及复杂数据、权限、算法、外部系统或高风险流程。\n- 初步指定业务负责人和技术负责人。\n\n## 输出/交付物\n\n- `00_项目入口分级.md`\n- 项目类型：S / M / L。\n- 是否进入完整流程的结论。\n- 初步负责人。\n- 初步范围和风险。\n\n## 检查清单\n\n- [ ] 是否确认需求要解决的真实业务问题？\n- [ ] 是否确认该需求值得做？\n- [ ] 是否确认项目类型？\n- [ ] 是否确认走轻流程还是完整流程？\n- [ ] 是否识别复杂权限、数据、算法、并发、安全或外部系统风险？\n- [ ] 是否明确业务主管和技术负责人？\n\n## 风险点\n\n- 小需求被过度流程化，降低效率。\n- 大需求被当成小需求处理，后续返工。\n- 没有识别权限、数据、安全、算法风险。\n- 没有业务负责人，需求持续漂移。\n\n## Gate 0 通过标准\n\n项目入口通过：确认值得做，确认项目类型。\n\n## 常见问题\n\n### 阶段0由谁负责？\n\n由业务主管和技术负责人共同负责。业务主管判断业务价值和业务范围，技术负责人判断技术复杂度和风险。\n\n### 小需求是否必须走完整流程？\n\n不一定。S 类小需求可以简化阶段1和阶段2，但仍应保留基本入口判断、测试和上线验收。\n\n## 关联条目\n\n- [[AI驱动内部系统开发流程_V3_总览]]\n- [[角色职责矩阵]]\n- [[阶段交付物清单]]\n", "backlinks": [ "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "article:02_项目管理流程/README", "article:02_项目管理流程/常见问题FAQ", "article:02_项目管理流程/角色职责矩阵", "article:02_项目管理流程/阶段1_业务需求完整形成" ] } }, { "id": "article:02_项目管理流程/阶段1_业务需求完整形成", "type": "article", "name": "阶段1 业务需求完整形成", "filePath": "02_项目管理流程\\阶段1_业务需求完整形成.md", "summary": "业务侧通过 Vibe Coding 跑完整需求。阶段1追求需求完整，不追求产品完善。", "tags": [ "02_项目管理流程", "VibeCoding", "[项目管理流程", "业务需求", "阶段1", "需求完整]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [ "阶段0_项目入口分级", "阶段2_高保真模型与业务对象确认", "角色职责矩阵", "阶段交付物清单" ], "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段1, 业务需求, VibeCoding, 需求完整]\naliases: [业务需求完整形成, 提需求, 需求梳理, Gate 1]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 业务主管 / 业务人员\nupdated: 2026-05\n---\n\n# 阶段1 业务需求完整形成\n\n## 核心目标\n\n业务侧通过 Vibe Coding 跑完整需求。阶段1追求需求完整，不追求产品完善。\n\n## 负责人\n\n- 业务主管\n- 业务人员\n\n## 输入\n\n- 阶段0入口分级结论。\n- 业务痛点、业务目标、现有流程。\n- 业务人员真实操作经验。\n\n## 关键动作\n\n- 梳理主流程。\n- 明确日常操作页面结构。\n- 盘点功能页面和按钮。\n- 补充分支流程。\n- 补充异常流程。\n- 使用 Vibe Coding 生成或验证需求原型。\n- 记录页面验证结果。\n\n## 输出/交付物\n\n- `01_主流程说明.md`\n- `02_日常操作页面结构.md`\n- `03_功能页面按钮盘点表.md`\n- `04_分支流程_XXX.md`\n- `05_异常流程_XXX.md`\n- `06_VibeCoding页面验证记录.md`\n\n## 检查清单\n\n- [ ] 主流程是否能从开始走到结束？\n- [ ] 日常操作入口是否清楚？\n- [ ] 页面、按钮、字段是否大致完整？\n- [ ] 分支流程是否由真实业务人员补充？\n- [ ] 异常流程是否覆盖无负责人、超时、数据缺失等情况？\n- [ ] Vibe Coding 原型是否经过业务侧走查？\n- [ ] 是否明确哪些内容只是原型，不可直接进入生产？\n\n## 风险点\n\n- 只描述主流程，漏掉分支和异常。\n- 把 Vibe Coding 页面当成可生产代码。\n- 业务主管只给方向，没有安排业务人员补充真实操作细节。\n- 页面、按钮、字段未盘点，导致阶段2和开发阶段返工。\n\n## Gate 1 通过标准\n\n需求完整通过：主流程、分支、页面、按钮、字段、状态大致完整。\n\n## 常见问题\n\n### 阶段1追求什么？\n\n追求需求完整，不追求产品完善。页面可以粗糙，但业务流程、分支、异常、按钮、字段不能漏大块。\n\n### Vibe Coding 页面能不能直接上线？\n\n不能。Vibe Coding 页面只是需求原型，不直接进入生产。\n\n## 关联条目\n\n- [[阶段0_项目入口分级]]\n- [[阶段2_高保真模型与业务对象确认]]\n- [[角色职责矩阵]]\n- [[阶段交付物清单]]\n", "backlinks": [ "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "article:02_项目管理流程/README", "article:02_项目管理流程/常见问题FAQ", "article:02_项目管理流程/常见问题FAQ", "article:02_项目管理流程/角色职责矩阵", "article:02_项目管理流程/阶段2_高保真模型与业务对象确认" ] } }, { "id": "article:02_项目管理流程/阶段2.5_测试提前补漏", "type": "article", "name": "阶段2.5 测试提前补漏", "filePath": "02_项目管理流程\\阶段2.5_测试提前补漏.md", "summary": "在开发前用测试视角发现需求漏洞。测试提前补漏，不只是上线前找 Bug。", "tags": [ "02_项目管理流程", "[项目管理流程", "测试", "测试用例]", "阶段2.5", "需求补漏" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [ "阶段2_高保真模型与业务对象确认", "阶段3_研发协作与正式开发", "项目检查清单" ], "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段2.5, 测试, 需求补漏, 测试用例]\naliases: [测试提前补漏, 开发前测试, Gate 2.5, 测试用例初稿]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 测试\nupdated: 2026-05\n---\n\n# 阶段2.5 测试提前补漏\n\n## 核心目标\n\n在开发前用测试视角发现需求漏洞。测试提前补漏，不只是上线前找 Bug。\n\n## 负责人\n\n- 测试\n\n## 输入\n\n- 高保真模型。\n- 高保真模型说明。\n- 统一业务对象模型。\n- 按钮行为矩阵。\n- 项目周期与版本确认。\n\n## 关键动作\n\n- 基于高保真模型先写测试用例初稿。\n- 从主流程、分支流程、权限、异常、数据、按钮行为视角检查遗漏。\n- 标记阻塞开发的问题。\n- 将需求漏洞回流给业务、产品、前端补齐。\n- 确认阻塞问题处理后再进入正式开发。\n\n## 输出/交付物\n\n- `11_测试用例初稿与需求补漏.md`\n- 需求补漏记录。\n- 阻塞问题清单。\n- 已关闭问题清单。\n\n## 检查清单\n\n- [ ] 是否已基于高保真模型编写测试用例初稿？\n- [ ] 是否覆盖主流程？\n- [ ] 是否覆盖分支流程？\n- [ ] 是否覆盖权限？\n- [ ] 是否覆盖异常场景？\n- [ ] 是否覆盖关键数据和状态？\n- [ ] 是否覆盖按钮行为？\n- [ ] 测试发现的阻塞问题是否已关闭？\n\n## 风险点\n\n- 测试只在上线前介入，导致需求漏洞在开发后才暴露。\n- 测试用例只覆盖主流程，漏掉权限、异常、分支和数据边界。\n- 阻塞问题没有关闭就进入开发。\n\n## Gate 2.5 通过标准\n\n测试补漏：测试用例初稿发现的阻塞问题已处理。\n\n## 常见问题\n\n### 阶段2.5应该在什么时候发生？\n\n发生在高保真模型确认后、正式开发前。\n\n### 阶段2.5要产出什么？\n\n主要产出 `11_测试用例初稿与需求补漏.md`，并形成需求补漏记录、阻塞问题清单和已关闭问题清单。\n\n## 关联条目\n\n- [[阶段2_高保真模型与业务对象确认]]\n- [[阶段3_研发协作与正式开发]]\n- [[项目检查清单]]\n", "backlinks": [ "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "article:02_项目管理流程/README", "article:02_项目管理流程/常见问题FAQ", "article:02_项目管理流程/常见问题FAQ", "article:02_项目管理流程/角色职责矩阵", "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", "article:02_项目管理流程/阶段3_研发协作与正式开发" ] } }, { "id": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", "type": "article", "name": "阶段2 高保真模型与业务对象确认", "filePath": "02_项目管理流程\\阶段2_高保真模型与业务对象确认.md", "summary": "把完整但粗糙的需求收敛成可开发模型。阶段2追求模型高效，前端必须深度参与。", "tags": [ "02_项目管理流程", "[项目管理流程", "业务对象", "产品]", "前端", "阶段2", "高保真模型" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [ "阶段1_业务需求完整形成", "阶段2.5_测试提前补漏", "../01_业务流程/业务对象字典", "阶段交付物清单" ], "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段2, 高保真模型, 业务对象, 前端, 产品]\naliases: [高保真模型确认, 业务对象确认, Gate 2, 统一业务对象模型]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 前端 / 产品经理\nupdated: 2026-05\n---\n\n# 阶段2 高保真模型与业务对象确认\n\n## 核心目标\n\n把完整但粗糙的需求收敛成可开发模型。阶段2追求模型高效，前端必须深度参与。\n\n## 负责人\n\n- 前端\n- 产品经理\n\n## 输入\n\n- 阶段1形成的主流程、页面结构、按钮盘点、分支流程、异常流程和 Vibe Coding 验证记录。\n\n## 关键动作\n\n- 将业务原型收敛为高保真模型。\n- 明确页面结构、交互、按钮行为和状态变化。\n- 确认业务对象、字段、状态和对象关系。\n- 明确 V1/V2 范围和项目周期。\n- 进行前端技术评审和技术预检。\n- 识别性能、安全、权限、并发、日志、可回滚等风险。\n\n## 输出/交付物\n\n- `07_高保真模型.html`\n- `07_高保真模型说明.md`\n- `08_项目周期与版本确认.md`\n- `09_前端技术评审.md`\n- `10_技术预检记录.md`\n- `10A_统一业务对象模型.md`\n- `10B_按钮行为矩阵.md`\n\n## 检查清单\n\n- [ ] 页面是否已经从粗糙原型收敛成可开发模型？\n- [ ] 按钮行为是否明确？\n- [ ] 业务对象、字段、状态、对象关系是否明确？\n- [ ] V1/V2 范围是否明确？\n- [ ] 是否完成前端技术评审？\n- [ ] 是否完成性能、安全、权限、并发、日志、可回滚预检？\n- [ ] 是否明确高保真模型确认后才允许正式开发？\n\n## 风险点\n\n- 前端介入太晚，导致页面、接口、数据库互相倒逼。\n- 高保真模型只画页面，没有确认业务对象和状态。\n- 没有按钮行为矩阵，开发和测试无法对齐。\n- 未提前识别性能、安全、权限、并发、日志、回滚风险。\n\n## Gate 2 通过标准\n\n高保真模型通过：页面收敛、按钮行为、业务对象、状态、V1/V2 明确。\n\n## 常见问题\n\n### 什么时候需要前端提前参与？\n\n阶段2必须由前端深度参与。若需求涉及多页面、复杂交互、权限、状态流转、数据结构或组件复用，前端应在需求收敛时提前参与。\n\n### 统一业务对象模型为什么重要？\n\n统一业务对象模型是页面、接口、数据库、测试、AI 提示词的共同基础。\n\n## 关联条目\n\n- [[阶段1_业务需求完整形成]]\n- [[阶段2.5_测试提前补漏]]\n- [[../01_业务流程/业务对象字典]]\n- [[阶段交付物清单]]\n", "backlinks": [ "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "article:02_项目管理流程/README", "article:02_项目管理流程/常见问题FAQ", "article:02_项目管理流程/阶段1_业务需求完整形成", "article:02_项目管理流程/阶段2.5_测试提前补漏" ] } }, { "id": "article:02_项目管理流程/阶段3_研发协作与正式开发", "type": "article", "name": "阶段3 研发协作与正式开发", "filePath": "02_项目管理流程\\阶段3_研发协作与正式开发.md", "summary": "基于高保真模型进行模块化、安全、可维护开发。研发阶段以代码质量、模块化、安全性、可维护性为中心。", "tags": [ "02_项目管理流程", "[项目管理流程", "代码治理", "安全]", "正式开发", "研发协作", "阶段3" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [ "阶段2.5_测试提前补漏", "阶段4_测试培训上线回流", "阶段交付物清单" ], "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段3, 研发协作, 正式开发, 代码治理, 安全]\naliases: [研发协作, 正式开发, Gate 3, 开发联调]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 前端 / 后端 / 算法\nupdated: 2026-05\n---\n\n# 阶段3 研发协作与正式开发\n\n## 核心目标\n\n基于高保真模型进行模块化、安全、可维护开发。研发阶段以代码质量、模块化、安全性、可维护性为中心。\n\n## 负责人\n\n- 前端\n- 后端\n- 算法\n\n## 输入\n\n- 高保真模型。\n- 统一业务对象模型。\n- 按钮行为矩阵。\n- 测试用例初稿与需求补漏结果。\n- 技术预检记录。\n\n## 关键动作\n\n- 拆分研发任务与协作计划。\n- 进行前端、后端、算法技术实现对接。\n- 明确接口、数据库、权限、安全、日志和回滚方案。\n- 按代码治理与安全规范开发。\n- 记录开发问题与联调结果。\n- 治理 AI 生成代码，不能直接堆进生产。\n\n## 输出/交付物\n\n- `12_研发任务拆分与协作计划.md`\n- `13_技术实现对接.md`\n- `14_代码治理与安全规范.md`\n- `15_开发问题与联调记录.md`\n\n## 检查清单\n\n- [ ] 研发任务是否已拆分？\n- [ ] 前后端、数据库、权限、安全、主要流程是否联调完成？\n- [ ] 是否按统一业务对象模型设计接口和数据库？\n- [ ] 是否处理权限、安全、日志、可回滚？\n- [ ] AI 生成代码是否经过人工审查和治理？\n- [ ] 是否避免重复代码和不可维护堆叠？\n\n## 风险点\n\n- 开发直接从 Vibe Coding 原型开始，跳过高保真模型。\n- AI 生成代码未经治理直接进入生产。\n- 缺少模块边界、权限、安全、日志和回滚方案。\n- 前后端、数据库、测试使用的业务对象不一致。\n\n## Gate 3 通过标准\n\n开发联调通过：前后端、数据库、权限、安全、主要流程联调完成。\n\n## 常见问题\n\n### 阶段3如何保证模块化、安全和可维护？\n\n依赖统一业务对象模型、研发任务拆分、技术实现对接、代码治理与安全规范、开发问题与联调记录。AI 代码必须经过治理，不能直接堆进生产。\n\n## 关联条目\n\n- [[阶段2.5_测试提前补漏]]\n- [[阶段4_测试培训上线回流]]\n- [[阶段交付物清单]]\n", "backlinks": [ "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "article:02_项目管理流程/README", "article:02_项目管理流程/常见问题FAQ", "article:02_项目管理流程/阶段2.5_测试提前补漏", "article:02_项目管理流程/阶段4_测试培训上线回流" ] } }, { "id": "article:02_项目管理流程/阶段4_测试培训上线回流", "type": "article", "name": "阶段4 测试培训上线回流", "filePath": "02_项目管理流程\\阶段4_测试培训上线回流.md", "summary": "完成测试、培训、上线验收和问题回流。测试保证系统真实可用，并帮助业务人员正确使用。", "tags": [ "02_项目管理流程", "[项目管理流程", "上线", "回流]", "培训", "测试", "阶段4" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [ "阶段3_研发协作与正式开发", "项目检查清单", "阶段交付物清单" ], "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段4, 测试, 培训, 上线, 回流]\naliases: [测试培训上线回流, 上线验收, Gate 4]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 测试 / 业务主管\nupdated: 2026-05\n---\n\n# 阶段4 测试培训上线回流\n\n## 核心目标\n\n完成测试、培训、上线验收和问题回流。测试保证系统真实可用，并帮助业务人员正确使用。\n\n## 负责人\n\n- 测试\n- 业务主管\n\n## 输入\n\n- 开发联调完成的系统。\n- 测试用例。\n- 高保真模型和业务对象模型。\n- 开发问题与联调记录。\n\n## 关键动作\n\n- 进行正式测试。\n- 验证主流程、分支流程、权限、异常和数据。\n- 输出正式测试报告。\n- 将测试用例转成业务操作手册或内部培训材料。\n- 组织业务确认和上线验收。\n- 记录上线问题并回流需求池。\n\n## 输出/交付物\n\n- `16_正式测试报告.md`\n- `17_内部培训手册.md`\n- `18_上线验收记录.md`\n- `19_上线问题与回流需求.md`\n\n## 检查清单\n\n- [ ] 正式测试是否通过？\n- [ ] 主流程是否验证通过？\n- [ ] 分支流程是否验证通过？\n- [ ] 权限是否验证通过？\n- [ ] 异常和数据边界是否验证通过？\n- [ ] 内部培训手册是否完成？\n- [ ] 业务主管是否完成上线确认？\n- [ ] 上线问题是否记录并回流？\n\n## 风险点\n\n- 只测功能，不测权限、异常、数据和实际操作路径。\n- 没有培训材料，业务人员不会用。\n- 上线问题没有进入回流需求池。\n- 业务主管未验收就上线。\n\n## Gate 4 通过标准\n\n上线验收通过：测试通过、业务确认、培训完成。\n\n## 常见问题\n\n### 上线前需要检查哪些事项？\n\n至少检查正式测试、主流程、分支流程、权限、异常、数据边界、内部培训手册、业务确认、上线问题回流机制。\n\n## 关联条目\n\n- [[阶段3_研发协作与正式开发]]\n- [[项目检查清单]]\n- [[阶段交付物清单]]\n", "backlinks": [ "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "article:02_项目管理流程/README", "article:02_项目管理流程/常见问题FAQ", "article:02_项目管理流程/角色职责矩阵", "article:02_项目管理流程/阶段3_研发协作与正式开发" ] } }, { "id": "article:02_项目管理流程/阶段交付物清单", "type": "article", "name": "阶段交付物清单", "filePath": "02_项目管理流程\\阶段交付物清单.md", "summary": "| 阶段 | 交付物 | |---|---| | 阶段0 | `00_项目入口分级.md` | | 阶段1 | `01_主流程说明.md`、`02_日常操作页面结构.md`、`03_功能页面按钮盘点表.md`、`04_分支流程_XXX.md`、`05_异常流程_XXX.md`、`06_VibeCoding页面验证记录.md` | | 阶段2 | `07_高保真模型.html`、`07_高保真...", "tags": [ "02_项目管理流程", "[项目管理流程", "交付物", "文件清单]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [ "AI驱动内部系统开发流程_V3_总览", "项目检查清单" ], "content": "---\ntype: deliverable_index\ntags: [项目管理流程, 交付物, 文件清单]\naliases: [交付物清单, 文件结构, 产出物]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 阶段交付物清单\n\n## 完整版交付物\n\n| 阶段 | 交付物 |\n|---|---|\n| 阶段0 | `00_项目入口分级.md` |\n| 阶段1 | `01_主流程说明.md`、`02_日常操作页面结构.md`、`03_功能页面按钮盘点表.md`、`04_分支流程_XXX.md`、`05_异常流程_XXX.md`、`06_VibeCoding页面验证记录.md` |\n| 阶段2 | `07_高保真模型.html`、`07_高保真模型说明.md`、`08_项目周期与版本确认.md`、`09_前端技术评审.md`、`10_技术预检记录.md`、`10A_统一业务对象模型.md`、`10B_按钮行为矩阵.md` |\n| 阶段2.5 | `11_测试用例初稿与需求补漏.md` |\n| 阶段3 | `12_研发任务拆分与协作计划.md`、`13_技术实现对接.md`、`14_代码治理与安全规范.md`、`15_开发问题与联调记录.md` |\n| 阶段4 | `16_正式测试报告.md`、`17_内部培训手册.md`、`18_上线验收记录.md`、`19_上线问题与回流需求.md` |\n| 阶段5 | `20_技术债清单.md`、`21_业务原子能力沉淀清单.md`、`22_组件库与服务复用清单.md`、`23_AI开发上下文模板更新记录.md` |\n\n## 轻量版交付物\n\n| 阶段包 | 交付物 |\n|---|---|\n| 入口 | `00_项目入口分级.md` |\n| 需求 | `01_业务需求包.md` |\n| 模型 | `02_高保真模型包.md` |\n| 预检 | `03_项目版本与技术预检.md` |\n| 测试补漏 | `04_测试用例初稿与需求补漏.md` |\n| 研发 | `05_研发协作与技术实现包.md` |\n| 治理 | `06_代码治理与安全规范.md` |\n| 上线 | `07_测试培训上线包.md` |\n| 沉淀 | `08_技术债与能力沉淀包.md` |\n\n## 关联条目\n\n- [[AI驱动内部系统开发流程_V3_总览]]\n- [[项目检查清单]]\n", "backlinks": [ "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "article:02_项目管理流程/README", "article:02_项目管理流程/常见问题FAQ", "article:02_项目管理流程/阶段0_项目入口分级", "article:02_项目管理流程/阶段1_业务需求完整形成", "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", "article:02_项目管理流程/阶段3_研发协作与正式开发", "article:02_项目管理流程/阶段4_测试培训上线回流", "article:02_项目管理流程/项目检查清单" ] } }, { "id": "article:02_项目管理流程/项目检查清单", "type": "article", "name": "项目检查清单", "filePath": "02_项目管理流程\\项目检查清单.md", "summary": "- [ ] 确认项目值得做。 - [ ] 确认项目类型：S / M / L。 - [ ] 确认走轻流程还是完整流程。 - [ ] 确认业务主管和技术负责人。", "tags": [ "02_项目管理流程", "[项目管理流程", "检查清单", "门禁]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [ "AI驱动内部系统开发流程_V3_总览", "阶段交付物清单" ], "content": "---\ntype: checklist\ntags: [项目管理流程, 检查清单, 门禁]\naliases: [项目门禁检查, 上线检查, 流程检查]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 项目检查清单\n\n## Gate 0 项目入口\n\n- [ ] 确认项目值得做。\n- [ ] 确认项目类型：S / M / L。\n- [ ] 确认走轻流程还是完整流程。\n- [ ] 确认业务主管和技术负责人。\n\n## Gate 1 需求完整\n\n- [ ] 主流程完整。\n- [ ] 分支流程完整。\n- [ ] 页面、按钮、字段大致完整。\n- [ ] 状态大致完整。\n- [ ] Vibe Coding 页面已验证。\n\n## Gate 2 高保真模型\n\n- [ ] 页面已经收敛。\n- [ ] 按钮行为明确。\n- [ ] 业务对象明确。\n- [ ] 状态明确。\n- [ ] V1/V2 明确。\n- [ ] 性能、安全、权限、并发、日志、可回滚已预检。\n\n## Gate 2.5 测试补漏\n\n- [ ] 测试用例初稿已完成。\n- [ ] 主流程、分支、权限、异常、数据、按钮行为已检查。\n- [ ] 阻塞开发的问题已处理。\n\n## Gate 3 开发联调\n\n- [ ] 前后端联调完成。\n- [ ] 数据库联调完成。\n- [ ] 权限和安全联调完成。\n- [ ] 主要流程联调完成。\n- [ ] AI 代码已治理。\n\n## Gate 4 上线验收\n\n- [ ] 正式测试通过。\n- [ ] 业务确认完成。\n- [ ] 培训完成。\n- [ ] 上线问题回流机制明确。\n\n## Gate 5 技术债治理\n\n- [ ] 技术债已分类。\n- [ ] 必须立即处理的已处理。\n- [ ] 可延后的进入技术债池。\n- [ ] 可复用组件已沉淀。\n- [ ] 可复用后端服务已沉淀。\n- [ ] AI 开发上下文模板已更新。\n\n## 关联条目\n\n- [[AI驱动内部系统开发流程_V3_总览]]\n- [[阶段交付物清单]]\n", "backlinks": [ "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "article:02_项目管理流程/README", "article:02_项目管理流程/常见问题FAQ", "article:02_项目管理流程/阶段2.5_测试提前补漏", "article:02_项目管理流程/阶段4_测试培训上线回流", "article:02_项目管理流程/阶段交付物清单" ] } }, { "id": "article:03_规范与模板/上线检查模板", "type": "article", "name": "上线检查模板", "filePath": "03_规范与模板\\上线检查模板.md", "summary": "- 项目名称： - 上线版本： - 上线时间： - 负责人：", "tags": [ "03_规范与模板", "[模板", "上线检查]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: template\ntags: [模板, 上线检查]\naliases: [上线模板, 验收模板]\nsource: manual\nstatus: active\nowner: 测试 / 业务主管\nupdated: 2026-05\n---\n\n# 上线检查模板\n\n## 基本信息\n\n- 项目名称：\n- 上线版本：\n- 上线时间：\n- 负责人：\n\n## 上线前检查\n\n- [ ] 正式测试通过。\n- [ ] 主流程通过。\n- [ ] 分支流程通过。\n- [ ] 权限通过。\n- [ ] 异常和数据边界通过。\n- [ ] 培训材料完成。\n- [ ] 业务主管确认。\n- [ ] 回滚方案明确。\n\n## 上线验收\n\n| 验收项 | 验收人 | 结果 | 备注 |\n|---|---|---|---|\n| | | | |\n\n## 上线问题回流\n\n| 问题 | 影响 | 处理优先级 | 负责人 | 状态 |\n|---|---|---|---|---|\n| | | | | |\n", "backlinks": [ "article:08_测试相关/README" ] } }, { "id": "article:03_规范与模板/业务流程梳理模板", "type": "article", "name": "业务流程梳理模板", "filePath": "03_规范与模板\\业务流程梳理模板.md", "summary": "见 [[../01_业务流程/业务流程模板]]。", "tags": [ "03_规范与模板", "[模板", "业务流程]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [ "../01_业务流程/业务流程模板" ], "content": "---\ntype: template\ntags: [模板, 业务流程]\naliases: [流程梳理模板]\nsource: manual\nstatus: active\nowner: 业务主管\nupdated: 2026-05\n---\n\n# 业务流程梳理模板\n\n见 [[../01_业务流程/业务流程模板]]。\n\n使用时复制该模板，并按真实业务流程命名保存到 `01_业务流程/` 下。\n", "backlinks": [] } }, { "id": "article:03_规范与模板/业务规则与需求补充模板", "type": "article", "name": "业务规则与需求补充模板", "filePath": "03_规范与模板\\业务规则与需求补充模板.md", "summary": "| 字段 | 内容 | |---|---| | 业务域 | | | 规则/需求名称 | | | 提出人 | | | 负责部门 | | | 适用角色 | | | 关联系统 | | | 版本 | v1.0 | | 生效状态 | draft / active / deprecated | | 生效时间 | | | 最近更新时间 | |", "tags": [ "03_规范与模板", "Agent检索]", "[模板", "业务规则", "需求补充" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: template\ntags: [模板, 业务规则, 需求补充, Agent检索]\naliases: [业务补充模板, 规则补充模板, 需求增量模板]\nsource: manual\nstatus: active\nowner: 业务主管 / 产品经理\nupdated: 2026-05\n---\n\n# 业务规则与需求补充模板\n\n> 使用方式：每次新增或修订业务规则时，复制本模板到 `01_业务流程/` 下，并按 `业务域_规则或需求名称_YYYYMMDD.md` 命名。\n\n## 1. 基本信息\n\n| 字段 | 内容 |\n|---|---|\n| 业务域 | |\n| 规则/需求名称 | |\n| 提出人 | |\n| 负责部门 | |\n| 适用角色 | |\n| 关联系统 | |\n| 版本 | v1.0 |\n| 生效状态 | draft / active / deprecated |\n| 生效时间 | |\n| 最近更新时间 | |\n\n## 2. 背景与目标\n\n- 当前问题：\n- 业务目标：\n- 不解决的问题：\n\n## 3. 适用范围\n\n- 适用场景：\n- 不适用场景：\n- 前置条件：\n\n## 4. 业务规则\n\n| 编号 | 规则描述 | 触发条件 | 处理结果 | 优先级 | 例外情况 |\n|---|---|---|---|---|---|\n| BR-001 | | | | 高/中/低 | |\n\n## 5. 业务流程\n\n### 5.1 主流程\n\n1. \n2. \n3. \n\n### 5.2 分支流程\n\n| 分支场景 | 判断条件 | 处理方式 | 输出结果 |\n|---|---|---|---|\n| | | | |\n\n### 5.3 异常处理\n\n| 异常场景 | 识别方式 | 处理方式 | 负责人 |\n|---|---|---|---|\n| | | | |\n\n## 6. 数据与业务对象\n\n| 业务对象 | 字段 | 字段含义 | 必填 | 来源 | 去向 |\n|---|---|---|---|---|---|\n| | | | 是/否 | | |\n\n## 7. 权限与操作\n\n| 角色 | 可见范围 | 可执行操作 | 禁止操作 |\n|---|---|---|---|\n| | | | |\n\n## 8. 验收口径\n\n| 验收点 | 通过标准 | 测试问题 |\n|---|---|---|\n| | | |\n\n## 9. Agent 检索字段\n\n### 9.1 推荐关键词\n\n- \n\n### 9.2 同义词/口语问法\n\n| 用户可能问法 | 标准术语 | 推荐命中文件 |\n|---|---|---|\n| | | |\n\n### 9.3 标准问答\n\n| 问题 | 期望答案要点 | 来源章节 |\n|---|---|---|\n| | | |\n\n## 10. 关联条目\n\n- 关联业务流程：\n- 关联项目管理阶段：\n- 关联需求说明：\n- 关联测试用例：\n\n## 11. 变更记录\n\n| 日期 | 版本 | 变更内容 | 变更人 |\n|---|---|---|---|\n| | v1.0 | 新增 | |\n", "backlinks": [] } }, { "id": "article:03_规范与模板/会议纪要模板", "type": "article", "name": "会议纪要模板", "filePath": "03_规范与模板\\会议纪要模板.md", "summary": "- 会议主题： - 时间： - 参会人： - 记录人：", "tags": [ "03_规范与模板", "[模板", "会议纪要]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: template\ntags: [模板, 会议纪要]\naliases: [会议记录模板]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 会议纪要模板\n\n## 基本信息\n\n- 会议主题：\n- 时间：\n- 参会人：\n- 记录人：\n\n## 结论\n\n| 编号 | 结论 | 负责人 | 截止时间 |\n|---|---|---|---|\n| | | | |\n\n## 待办\n\n| 事项 | 负责人 | 截止时间 | 状态 |\n|---|---|---|---|\n| | | | |\n\n## 风险与问题\n\n| 问题 | 影响 | 处理方式 |\n|---|---|---|\n| | | |\n", "backlinks": [] } }, { "id": "article:03_规范与模板/需求说明模板", "type": "article", "name": "需求说明模板", "filePath": "03_规范与模板\\需求说明模板.md", "summary": "- 背景： - 要解决的问题： - 目标用户： - 预期收益：", "tags": [ "03_规范与模板", "[模板", "需求说明]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: template\ntags: [模板, 需求说明]\naliases: [需求模板, 业务需求包]\nsource: manual\nstatus: active\nowner: 产品经理 / 业务主管\nupdated: 2026-05\n---\n\n# 需求说明模板\n\n## 背景与目标\n\n- 背景：\n- 要解决的问题：\n- 目标用户：\n- 预期收益：\n\n## 范围\n\n- V1 范围：\n- V2 范围：\n- 不包含范围：\n\n## 主流程\n\n1. \n2. \n3. \n\n## 页面与按钮\n\n| 页面 | 按钮/操作 | 行为说明 | 权限 | 备注 |\n|---|---|---|---|---|\n| | | | | |\n\n## 业务对象\n\n| 对象 | 字段 | 状态 | 说明 |\n|---|---|---|---|\n| | | | |\n\n## 分支与异常\n\n| 场景 | 处理方式 | 负责人 |\n|---|---|---|\n| | | |\n\n## 验收口径\n\n- \n", "backlinks": [] } }, { "id": "article:04_Agent检索/关键词索引", "type": "article", "name": "关键词索引", "filePath": "04_Agent检索\\关键词索引.md", "summary": "| 关键词 | 推荐检索文件 | |---|---| | 内部系统开发流程 | `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` | | ERP 开发流程 | `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` | | 项目入口 | `02_项目管理流程/阶段0_项目入口分级.md` | | 项目分级 | `02_项目管理流程/阶段0_项目入口分级.md` ...", "tags": [ "04_Agent检索", "[Agent", "关键词", "索引]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: keyword_index\ntags: [Agent, 关键词, 索引]\naliases: [关键词映射]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 关键词索引\n\n| 关键词 | 推荐检索文件 |\n|---|---|\n| 内部系统开发流程 | `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` |\n| ERP 开发流程 | `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` |\n| 项目入口 | `02_项目管理流程/阶段0_项目入口分级.md` |\n| 项目分级 | `02_项目管理流程/阶段0_项目入口分级.md` |\n| S 类 / M 类 / L 类 | `02_项目管理流程/阶段0_项目入口分级.md` |\n| 业务需求 | `02_项目管理流程/阶段1_业务需求完整形成.md` |\n| Vibe Coding | `02_项目管理流程/阶段1_业务需求完整形成.md` |\n| 高保真模型 | `02_项目管理流程/阶段2_高保真模型与业务对象确认.md` |\n| 业务对象 | `02_项目管理流程/阶段2_高保真模型与业务对象确认.md`、`01_业务流程/业务对象字典.md` |\n| 按钮行为 | `02_项目管理流程/阶段2_高保真模型与业务对象确认.md` |\n| 测试提前补漏 | `02_项目管理流程/阶段2.5_测试提前补漏.md` |\n| 测试用例初稿 | `02_项目管理流程/阶段2.5_测试提前补漏.md` |\n| 正式开发 | `02_项目管理流程/阶段3_研发协作与正式开发.md` |\n| 研发协作 | `02_项目管理流程/阶段3_研发协作与正式开发.md` |\n| 代码治理 | `02_项目管理流程/阶段3_研发协作与正式开发.md`、`02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` |\n| 上线验收 | `02_项目管理流程/阶段4_测试培训上线回流.md` |\n| 内部培训 | `02_项目管理流程/阶段4_测试培训上线回流.md` |\n| 问题回流 | `02_项目管理流程/阶段4_测试培训上线回流.md` |\n| 技术债 | `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md`、`02_项目管理流程/项目检查清单.md` |\n| 门禁 | `02_项目管理流程/项目检查清单.md` |\n| 交付物 | `02_项目管理流程/阶段交付物清单.md` |\n| 谁负责 | `02_项目管理流程/角色职责矩阵.md` |\n| 业务规则补充 | `03_规范与模板/业务规则与需求补充模板.md`、`04_Agent检索/知识库持续更新与验证流程.md` |\n| 需求补充 | `03_规范与模板/业务规则与需求补充模板.md`、`03_规范与模板/需求说明模板.md` |\n| 新增业务流程 | `03_规范与模板/业务规则与需求补充模板.md`、`03_规范与模板/业务流程梳理模板.md` |\n| 检索验证 | `04_Agent检索/知识库持续更新与验证流程.md`、`01_业务流程/业务补充验证记录.md` |\n| Agent 问答验证 | `04_Agent检索/知识库持续更新与验证流程.md`、`01_业务流程/业务补充验证记录.md` |\n", "backlinks": [ "article:知识库使用说明", "article:知识库使用说明", "article:知识库使用说明" ] } }, { "id": "article:04_Agent检索/同义词表", "type": "article", "name": "同义词表", "filePath": "04_Agent检索\\同义词表.md", "summary": "| 用户说法 | 标准术语 | 推荐检索文件 | |---|---|---| | 提需求 | 业务需求完整形成 / 项目入口分级 | `阶段1_业务需求完整形成.md`、`阶段0_项目入口分级.md` | | 立项 | 项目入口分级 | `阶段0_项目入口分级.md` | | 原型 | Vibe Coding 页面 / 高保真模型 | `阶段1_业务需求完整形成.md`、`阶段2_高保真模型...", "tags": [ "04_Agent检索", "[Agent", "同义词", "检索]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: synonym_table\ntags: [Agent, 同义词, 检索]\naliases: [口语映射, 术语映射]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 同义词表\n\n| 用户说法 | 标准术语 | 推荐检索文件 |\n|---|---|---|\n| 提需求 | 业务需求完整形成 / 项目入口分级 | `阶段1_业务需求完整形成.md`、`阶段0_项目入口分级.md` |\n| 立项 | 项目入口分级 | `阶段0_项目入口分级.md` |\n| 原型 | Vibe Coding 页面 / 高保真模型 | `阶段1_业务需求完整形成.md`、`阶段2_高保真模型与业务对象确认.md` |\n| 页面模型 | 高保真模型 | `阶段2_高保真模型与业务对象确认.md` |\n| 字段字典 | 业务对象模型 | `阶段2_高保真模型与业务对象确认.md`、`业务对象字典.md` |\n| 开发前测试 | 测试提前补漏 | `阶段2.5_测试提前补漏.md` |\n| 测试先看 | 测试提前补漏 | `阶段2.5_测试提前补漏.md` |\n| 开发怎么开始 | 研发协作与正式开发 | `阶段3_研发协作与正式开发.md` |\n| 上线前要做什么 | 测试培训上线回流 / Gate 4 | `阶段4_测试培训上线回流.md`、`项目检查清单.md` |\n| 谁来做 | 角色职责 | `角色职责矩阵.md` |\n| 要交什么 | 阶段交付物 | `阶段交付物清单.md` |\n| 检查点 | 阶段门禁 / 项目检查清单 | `项目检查清单.md` |\n| AI 写的代码 | AI 代码治理 | `阶段3_研发协作与正式开发.md` |\n| 加一条业务规则 | 业务规则补充 | `业务规则与需求补充模板.md`、`知识库持续更新与验证流程.md` |\n| 补需求 | 需求补充 | `业务规则与需求补充模板.md`、`需求说明模板.md` |\n| 新规则怎么写 | 业务规则与需求补充 | `业务规则与需求补充模板.md` |\n| 怎么验证能不能搜到 | Agent 检索验证 | `知识库持续更新与验证流程.md`、`业务补充验证记录.md` |\n", "backlinks": [ "article:知识库使用说明" ] } }, { "id": "article:04_Agent检索/来源文件索引", "type": "article", "name": "来源文件索引", "filePath": "04_Agent检索\\来源文件索引.md", "summary": "| 来源文件 | 路径 | 用途 | 状态 | |---|---|---|---| | AI_驱动_内部系统开发流程_V3.docx | `D:\\\\AIcoding\\\\WishFulfilled\\\\知识库\\\\AI_驱动_内部系统开发流程_V3.docx` | 项目管理流程权威来源 | active |", "tags": [ "04_Agent检索", "Agent]", "[来源", "索引" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: source_index\ntags: [来源, 索引, Agent]\naliases: [来源索引, 原始文件]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 来源文件索引\n\n## 原始来源\n\n| 来源文件 | 路径 | 用途 | 状态 |\n|---|---|---|---|\n| AI_驱动_内部系统开发流程_V3.docx | `D:\\\\AIcoding\\\\WishFulfilled\\\\知识库\\\\AI_驱动_内部系统开发流程_V3.docx` | 项目管理流程权威来源 | active |\n\n## 拆解后的知识条目\n\n| 条目 | 来源 |\n|---|---|\n| `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段0_项目入口分级.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段1_业务需求完整形成.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段2_高保真模型与业务对象确认.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段2.5_测试提前补漏.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段3_研发协作与正式开发.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段4_测试培训上线回流.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/角色职责矩阵.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段交付物清单.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/项目检查清单.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/常见问题FAQ.md` | AI_驱动_内部系统开发流程_V3.docx |\n\n## 业务补充来源\n\n| 来源文件 | 路径 | 用途 | 状态 |\n|---|---|---|---|\n| 需求文档目录 | `05_需求文档/` | 持续存放新增业务需求、业务规则和需求变更文档 | active |\n| 需求文档索引.md | `05_需求文档/需求文档索引.md` | 登记新增需求文档及 Agent 检索验证状态 | active |\n| 业务规则与需求补充模板.md | `03_规范与模板/业务规则与需求补充模板.md` | 新增业务规则、需求、流程的标准模板 | active |\n| 知识库持续更新与验证流程.md | `04_Agent检索/知识库持续更新与验证流程.md` | 规范新增文档后的索引同步和 Agent 检索验证 | active |\n| 业务补充验证记录.md | `01_业务流程/业务补充验证记录.md` | 记录新增业务文档是否能被 Agent 检索并回答 | active |\n| 里程碑目录 | `06_里程碑/` | 存放里程碑计划、阶段评审和项目节点材料 | active |\n| 技术文档目录 | `07_技术文档/` | 存放架构、接口、数据模型、实现方案和技术决策 | active |\n| 测试相关目录 | `08_测试相关/` | 存放测试计划、测试用例、缺陷、验收和上线检查材料 | active |\n\n## 维护要求\n\n- 从原始 docx 更新流程时，需要同步更新阶段文件、角色职责矩阵、交付物清单、检查清单、FAQ、关键词索引和同义词表。\n- 新增业务规则、需求或流程文档时，原始需求文档统一放入 `05_需求文档/`，并同步更新需求文档索引、业务规则索引、业务对象字典、关键词索引、同义词表和本来源文件索引。\n- 新增里程碑材料统一放入 `06_里程碑/`，并同步更新里程碑索引。\n- 新增技术材料统一放入 `07_技术文档/`，并同步更新技术文档索引。\n- 新增测试材料统一放入 `08_测试相关/`，并同步更新测试用例索引或对应测试记录。\n- Agent 回答项目管理流程问题时，应优先引用拆解后的 Markdown 文件。\n- Agent 回答具体业务规则和需求问题时，应优先引用 `05_需求文档/` 下的正式需求文档；稳定流程可再引用 `01_业务流程/` 下的业务流程条目。\n", "backlinks": [ "article:知识库使用说明", "article:知识库使用说明", "article:知识库使用说明", "article:知识库使用说明" ] } }, { "id": "article:04_Agent检索/检索说明", "type": "article", "name": "Agent 检索说明", "filePath": "04_Agent检索\\检索说明.md", "summary": "让 Agent 在回答业务流程和项目管理流程问题时，优先基于本地 Markdown 知识库检索，而不是凭空回答。", "tags": [ "04_Agent检索", "[Agent", "检索", "规则]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [ "知识库持续更新与验证流程" ], "content": "---\ntype: agent_retrieval_guide\ntags: [Agent, 检索, 规则]\naliases: [Agent检索说明, 检索规则]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# Agent 检索说明\n\n## 目标\n\n让 Agent 在回答业务流程和项目管理流程问题时，优先基于本地 Markdown 知识库检索，而不是凭空回答。\n\n## 检索优先级\n\n1. `05_需求文档/`：持续新增的业务需求、业务规则、需求变更和补充说明。\n2. `06_里程碑/`：项目节点、阶段计划、阶段评审和上线节奏。\n3. `07_技术文档/`：系统架构、数据模型、接口说明、实现方案和技术决策。\n4. `08_测试相关/`：测试计划、测试用例、缺陷记录、验收记录和上线检查。\n5. `02_项目管理流程/`：内部系统开发流程、阶段、角色、门禁、交付物、检查清单。\n6. `01_业务流程/`：真实业务流程、业务对象、业务规则。\n7. `04_Agent检索/`：关键词、同义词、来源索引、回答规则。\n8. `03_规范与模板/`：需要产出模板或文档时使用。\n\n## 问题类型与命中文件\n\n| 问题类型 | 优先文件 |\n|---|---|\n| 流程阶段 | `AI驱动内部系统开发流程_V3_总览.md`、各阶段文件 |\n| 角色职责 | `角色职责矩阵.md` |\n| 交付物 | `阶段交付物清单.md` |\n| 门禁/检查 | `项目检查清单.md` |\n| 常见问答 | `常见问题FAQ.md` |\n| 业务对象 | `01_业务流程/业务对象字典.md`、`阶段2_高保真模型与业务对象确认.md` |\n| 业务规则 | `05_需求文档/`、`05_需求文档/需求文档索引.md`、`01_业务流程/业务规则索引.md` |\n| 业务需求 | `05_需求文档/`、`05_需求文档/需求文档索引.md` |\n| 项目里程碑 | `06_里程碑/`、`06_里程碑/里程碑索引.md` |\n| 技术实现 | `07_技术文档/`、`07_技术文档/技术文档索引.md` |\n| 接口/数据模型 | `07_技术文档/接口说明模板.md`、具体接口文档、具体数据模型文档 |\n| 测试用例 | `08_测试相关/`、`08_测试相关/测试用例索引.md` |\n| 缺陷/验收/上线检查 | `08_测试相关/缺陷记录模板.md`、`08_测试相关/验收记录模板.md`、`08_测试相关/上线检查模板.md` |\n\n## 回答规则\n\n- 先回答结论，再展开依据。\n- 流程问题按“阶段、负责人、输入、动作、输出、检查点”组织。\n- 角色问题按“负责阶段、核心职责、典型产出”组织。\n- 交付物问题列出文件名。\n- 业务规则和需求问题优先检索 `05_需求文档/` 下的正式需求文档，再检索 `05_需求文档/需求文档索引.md`、`01_业务流程/业务规则索引.md`、`关键词索引.md` 和 `同义词表.md`。\n- 里程碑问题优先检索 `06_里程碑/` 和 `06_里程碑/里程碑索引.md`。\n- 技术问题优先检索 `07_技术文档/` 和 `07_技术文档/技术文档索引.md`。\n- 测试问题优先检索 `08_测试相关/` 和 `08_测试相关/测试用例索引.md`。\n- 必须注明来源文件名。\n- 如果知识库未明确记录，不要推测，应回答“知识库未明确记录”，并建议补充到具体文件。\n\n## 持续更新验证\n\n新增业务规则、需求或流程文档后，按 [[知识库持续更新与验证流程]] 执行验证。\n新增文档应使用 `03_规范与模板/业务规则与需求补充模板.md`，正式需求文档保存到 `05_需求文档/`，验证结果记录到 `05_需求文档/需求文档索引.md` 和 `01_业务流程/业务补充验证记录.md`。\n\n## 引用格式\n\n建议在回答末尾使用：\n\n> 来源：`02_项目管理流程/阶段2.5_测试提前补漏.md`\n", "backlinks": [ "article:欢迎", "article:知识库使用说明", "article:知识库使用说明" ] } }, { "id": "article:04_Agent检索/知识库持续更新与验证流程", "type": "article", "name": "知识库持续更新与验证流程", "filePath": "04_Agent检索\\知识库持续更新与验证流程.md", "summary": "确保业务规则、业务需求和流程补充后，Agent 能通过文件检索命中新内容，并基于知识库给出可追溯回答。", "tags": [ "04_Agent检索", "[Agent", "检索", "知识库更新", "验证流程]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: validation_process\ntags: [Agent, 检索, 知识库更新, 验证流程]\naliases: [知识库更新验证, Agent检索验证, 补充文档验证流程]\nsource: manual\nstatus: active\nowner: 内部技术团队 / 产品经理\nupdated: 2026-05\n---\n\n# 知识库持续更新与验证流程\n\n## 1. 目标\n\n确保业务规则、业务需求和流程补充后，Agent 能通过文件检索命中新内容，并基于知识库给出可追溯回答。\n\n## 2. 更新入口\n\n业务新增或修订时，优先使用：\n\n- `03_规范与模板/业务规则与需求补充模板.md`\n- `03_规范与模板/需求说明模板.md`\n- `03_规范与模板/业务流程梳理模板.md`\n\n补充后的正式需求文档统一保存到：\n\n- `05_需求文档/`\n\n如果文档已经沉淀为稳定业务流程，再同步拆解或引用到：\n\n- `01_业务流程/`\n\n推荐命名：\n\n```text\n业务域_规则或需求名称_YYYYMMDD.md\n```\n\n示例：\n\n```text\n采购_供应商准入规则_20260526.md\n库存_出入库审批规则_20260526.md\n销售_客户授信额度规则_20260526.md\n```\n\n## 3. 标准更新流程\n\n### 步骤 1：新增补充文档\n\n1. 复制 `业务规则与需求补充模板.md`。\n2. 保存到 `05_需求文档/`。\n3. 补全 Frontmatter：`type`、`tags`、`aliases`、`source`、`status`、`owner`、`updated`。\n4. 补全正文中的业务规则、流程、异常、权限、验收口径和 Agent 检索字段。\n\n### 步骤 2：更新索引\n\n新增业务文档后，同步更新：\n\n| 文件 | 更新内容 |\n|---|---|\n| `05_需求文档/需求文档索引.md` | 增加需求/规则名称、业务域、来源文件、状态和验证状态 |\n| `01_业务流程/业务规则索引.md` | 增加规则名称、业务域、适用场景、来源文件 |\n| `01_业务流程/业务对象字典.md` | 增加新增或变更的业务对象、字段、状态 |\n| `04_Agent检索/关键词索引.md` | 增加关键词到新文件的映射 |\n| `04_Agent检索/同义词表.md` | 增加口语问法与标准术语映射 |\n| `04_Agent检索/来源文件索引.md` | 登记新增知识条目来源 |\n\n### 步骤 3：执行文件级检查\n\n检查项：\n\n- 文件是否位于 `05_需求文档/`。\n- 文件名是否包含业务域、规则/需求名称、日期。\n- Frontmatter 是否完整。\n- 是否包含 `业务规则`、`业务流程`、`验收口径`、`Agent 检索字段`。\n- 索引文件是否已同步更新。\n\n### 步骤 4：执行关键词检索验证\n\n用新增文档中的关键词、别名、口语问法进行检索。\n\n验证标准：\n\n- 至少 1 个正式关键词能命中新文档。\n- 至少 1 个口语问法能通过 `同义词表.md` 或 `关键词索引.md` 定位到新文档。\n- 检索结果能定位到具体文件，而不是只命中模板。\n\n### 步骤 5：执行 Agent 问答验证\n\n每次新增文档至少准备 3 类问题：\n\n| 类型 | 示例 | 通过标准 |\n|---|---|---|\n| 规则类 | `供应商准入有什么条件？` | 能回答规则条件、触发条件、处理结果 |\n| 流程类 | `供应商准入流程怎么走？` | 能按步骤回答主流程和分支流程 |\n| 异常类 | `供应商资料不完整怎么办？` | 能回答异常处理方式和负责人 |\n\nAgent 回答必须满足：\n\n1. 结论来自新增文档或已索引文件。\n2. 回答末尾注明来源文件名。\n3. 如果文档未记录，明确回答“知识库未明确记录”。\n4. 不得凭经验补充没有来源的业务规则。\n\n### 步骤 6：记录验证结果\n\n在新增业务文档末尾的 `变更记录` 或单独验证记录中记录：\n\n| 日期 | 验证问题 | 是否命中 | 来源文件 | 结果 | 待补充 |\n|---|---|---|---|---|---|\n| | | 是/否 | | 通过/失败 | |\n\n## 4. 验证用例模板\n\n复制以下内容到新增业务文档的 `Agent 检索字段` 或验证记录中：\n\n```markdown\n## Agent 检索验证\n\n| 编号 | 用户问题 | 期望命中文件 | 期望答案要点 | 实际结果 | 状态 |\n|---|---|---|---|---|---|\n| Q1 | | | | | 未验证 |\n| Q2 | | | | | 未验证 |\n| Q3 | | | | | 未验证 |\n```\n\n## 5. 通过/失败判定\n\n### 通过\n\n- 新文档能被关键词检索到。\n- Agent 能引用新文档回答至少 3 个验证问题。\n- 回答没有明显幻觉。\n- 来源文件引用正确。\n\n### 失败\n\n出现任一情况视为失败：\n\n- 新文档只保存了，但没有更新关键词索引或同义词表。\n- Agent 命中了旧文件，未命中新文档。\n- Agent 回答没有引用来源。\n- Agent 编造了文档中不存在的业务规则。\n- 问题能检索到模板，但不能检索到正式业务文档。\n\n失败后处理：\n\n1. 补充 `aliases`、`tags`、推荐关键词和同义词。\n2. 更新 `关键词索引.md` 和 `同义词表.md`。\n3. 将标准问答补充到新增文档的 `Agent 检索字段`。\n4. 重新执行验证。\n\n## 6. Agent 验证提示词\n\n```text\n请只基于 D:\\AIcoding\\WishFulfilled\\知识库\\如愿知识库 下的 Markdown 文件回答。\n优先检索 05_需求文档、01_业务流程、02_项目管理流程、04_Agent检索。\n如果知识库没有明确记录，请回答“知识库未明确记录”，并说明建议补充到哪个文件。\n回答末尾必须列出来源文件。\n现在验证问题是：{用户问题}\n```\n", "backlinks": [ "article:04_Agent检索/检索说明", "article:知识库使用说明" ] } }, { "id": "article:04_Agent检索/问答提示词", "type": "article", "name": "问答提示词", "filePath": "04_Agent检索\\问答提示词.md", "summary": "你是如愿内部知识库问答 Agent。你必须优先检索本地 Markdown 知识库，再回答业务流程、项目管理流程、角色职责、交付物、检查清单和模板相关问题。", "tags": [ "04_Agent检索", "[Agent", "提示词", "问答]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: agent_prompt\ntags: [Agent, 提示词, 问答]\naliases: [Agent提示词, 知识库问答Prompt]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 问答提示词\n\n## 系统提示词\n\n你是如愿内部知识库问答 Agent。你必须优先检索本地 Markdown 知识库，再回答业务流程、项目管理流程、角色职责、交付物、检查清单和模板相关问题。\n\n回答要求：\n\n1. 不要凭空编造知识库未记录的信息。\n2. 优先检索 `02_项目管理流程` 和 `01_业务流程`。\n3. 流程类问题按阶段、负责人、输入、关键动作、输出、检查点回答。\n4. 角色类问题优先检索 `角色职责矩阵.md`。\n5. 交付物类问题优先检索 `阶段交付物清单.md`。\n6. 门禁和检查类问题优先检索 `项目检查清单.md`。\n7. 每次回答末尾必须注明来源文件。\n8. 如果没有明确答案，回答“知识库未明确记录”，并说明建议补充到哪个文件。\n\n## 用户问题改写规则\n\n- “提需求”可映射为“项目入口分级”或“业务需求完整形成”。\n- “开发前测试”可映射为“阶段2.5 测试提前补漏”。\n- “原型”可映射为“Vibe Coding 页面”或“高保真模型”，需结合上下文区分。\n- “上线前检查”可映射为“Gate 4 上线验收”和“项目检查清单”。\n- “谁负责”优先查角色职责矩阵。\n\n## 标准回答模板\n\n结论：\n\n要点：\n\n1. 阶段/角色：\n2. 输入：\n3. 关键动作：\n4. 输出：\n5. 检查点：\n\n来源：\n", "backlinks": [] } }, { "id": "article:05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3", "type": "article", "name": "USER 评价业务闭环 — 第三步：数据流与中间对象设计 v3", "filePath": "05_需求文档\\20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md", "summary": "- 文件名称：`20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md` - 项目路径：`C:\\XCODE\\USER` - 当前版本：`v3` - 最近更新：`2026-05-17` - 上游文档： - [工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md) — 业务规则与额度口径 - [共用能力图与渠道专属流程 v2....", "tags": [ "05_需求文档" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "# USER 评价业务闭环 — 第三步：数据流与中间对象设计 v3\n\n## 文件信息\n\n- 文件名称：`20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md`\n- 项目路径：`C:\\XCODE\\USER`\n- 当前版本：`v3`\n- 最近更新：`2026-05-17`\n- 上游文档：\n - [工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md) — 业务规则与额度口径\n - [共用能力图与渠道专属流程 v2.2](20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md) — 每个节点的 查/写/状态/提醒/拦截\n- 前置版本：\n - `数据流与中间对象需求_v1`（Codex，六层架构骨架）\n - `数据流与中间对象设计_v1.1`（Codex，字段字典最全版）\n - `第三步_数据流与中间表设计_v1`（字段级展开 + 流转时序）\n - `第三步_数据流与中间表设计_v2`（吸收 Codex 优点的合并版）\n- 合并策略：以 Codex v1.1 为主骨架（保留其完整字段字典和免评对象），补入 v2 的流转时序表、写入顺序图和快照策略。\n- 文件目的：作为第三步最终主稿，后续数据库物理设计、接口设计和页面点击读写设计均以此为准。\n\n---\n\n## 1. 第三步的目标\n\n第三步不再回答\"流程怎么走\"，而是回答：\n\n1. 现有系统里已经有哪些数据可以复用。\n2. 为什么仅靠现有 `users / amazon_orders / review_plans / push_tasks / support_tickets / fraud_events` 不够。\n3. 必须新增哪些中间对象。\n4. 哪些是正式事务表，哪些只是快照，哪些可以先做成视图。\n5. 从需求形成到结果回流，数据怎样一层一层往下走。\n\n---\n\n## 2. 本步先给出的结论\n\n### 2.1 不能再只围绕单一账号建模\n\n后续所有关键判断都应围绕 **真实人**，而不是只看 JOYHUB ID / 邮箱 / 电话 / Amazon 账号 / 单次订单。JOYHUB 用户只是身份线索之一，真实人才是额度、历史、风险、跨渠道去重和客服上下文的主对象。\n\n### 2.2 现有表能承载业务记录，但承载不了跨流程判断\n\n既有表更接近\"某一模块自己的账\"，但前两步已确认的新需求需要额外的中间层：真实人跨账号归并、每次互动重判、人群入选/排除解释、额度预占与跨渠道去重、客服上下文、评价提交与展示拆分、退款比对。\n\n### 2.3 第三步最重要的是把对象分层\n\n本文件把数据对象分为六层：\n\n```\n源数据层 → 主实体层 → 桥接层 → 事件层 → 快照与决策层 → 结果回流层\n```\n\n---\n\n## 3. 数据设计原则\n\n| 原则 | 说明 |\n| --- | --- |\n| 先识别真实人，再做额度与风险 | 否则 4/4/12 规则都会被多账号绕开 |\n| 事件与快照分离 | 事件是原始事实，快照是某个时点的判断结果 |\n| 当前态与历史态分离 | 当前视图可重算，历史决策必须留痕 |\n| 计划、渠道、客服、风险状态分离 | 不能压成一个字段 |\n| 用户提交与平台展示分离 | 真实提交计额度，Amazon 展示计计划完成 |\n| 能解释\"为什么\" | 入选、排除、拦截、转人工都要能追溯 |\n| 先复用现有对象，再补最小中间层 | 不为了建模漂亮重造全部旧表 |\n| 对敏感数据分层处理 | 原值、标准化值、哈希/指纹、脱敏展示值应区分 |\n\n---\n\n# 第一部分：现有数据源分析\n\n## 4. 现有数据源盘点\n\n| 数据源 | 当前可用内容 | 主要缺口 |\n| --- | --- | --- |\n| 现有 ERP 用户管理 | 用户 ID、用户名、注册时间、最近活跃、国家、性别、邮箱、绑定产品数、标签 | 仍是账号视角，不是真实人视角 |\n| APP / 用户数据库 | JOYHUB ID、邮箱、设备号、设备型号/类型、系统版本、APP版本、绑定玩具、活跃与点击行为 | 需要设备变更轨迹和与订单/客服联动 |\n| Amazon 订单 | 订单号、ASIN、站点、购买时间、订单状态、Profile ID、收件人姓名、收件地址等 | 需要标准化姓名/地址和收件人指纹 |\n| Amazon 评价/Listing | ASIN、评分、评价数、差评数、评价缺口、展示结果 | 用户真实提交与平台展示要拆成两条事实 |\n| 推送系统 | Push 计划、素材、任务、打开、点击、回复、投诉、退订 | IM/EDM/APP 语义不同，不能只用一套粗糙 push 结果 |\n| 客服/TEL | 工单、通话、售后、答应配合、问题处理 | 需要和上下文卡、风险复检、跟进状态联动 |\n| 黑名单/诈骗资料 | 黑名单、诈骗事件、双重退款、强弱关联 | 需要把风险信号与确认案件拆开 |\n| OA 返款/Amazon 退款 | 内部返款与 Amazon 退款 | 缺统一比对对象 |\n| JOYCOLLAB | KOC/KOL、内容、Code、点击、订单、转化、佣金 | 需要和 USER 计划/ASIN 结果打通 |\n\n### 4.1 Amazon 订单字段明细（结合表头.xlsx）\n\n| 字段 | 主要用途 | 涉密 |\n| --- | --- | --- |\n| 订单号 | 订单核验、真实人关联、退款比对 | 是 |\n| 订单状态 | 判断是否撤销、退款、退货、换货 | - |\n| 买家姓名 / 买家邮箱 | 身份关联 | 是 |\n| 收件人 / 电话 | 真实人归并、风险判断 | 是 |\n| 地址 / 城市 / 州 / 邮编 | 收件人归并、同址异名识别 | 是 |\n| ASIN / MSKU / SKU / 品名 / 标题 | 产品匹配、计划归属 | - |\n| 订购日期 / 发货时间 / 结算时间 | 时序判断 | - |\n| 数量 / 单价 / 订单总金额 / 销售额 | 交易画像 | 是 |\n| 是否退款 / 退款总金额 | 双重退款检测 | 是 |\n| 请求评论状态 | 评价缺口判断 | - |\n| 店铺 / 国家 / 销售渠道 | 站点匹配 | - |\n| Order Item ID | 订单行级关联 | - |\n\n### 4.2 订单侧必须补的派生字段\n\n| 字段 | 说明 |\n| --- | --- |\n| `recipient_name_normalized` | 标准化后的收件人姓名 |\n| `recipient_address_normalized` | 标准化后的地址 |\n| `recipient_fingerprint` | 由标准化姓名+地址生成的稳定指纹 |\n| `address_fingerprint` | 仅地址指纹，用于识别同址异名 |\n\n---\n\n## 5. 全局数据流\n\n```mermaid\nflowchart LR\n subgraph S[\"源数据层\"]\n S1[\"现有ERP用户/标签/身份\"", "backlinks": [] } }, { "id": "article:05_需求文档/README", "type": "article", "name": "需求文档", "filePath": "05_需求文档\\README.md", "summary": "本目录用于集中存放后续持续补充的业务需求文档、业务规则文档、流程补充文档和需求变更文档。", "tags": [ "05_需求文档", "Agent]", "[需求文档", "知识库更新", "需求收集" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: requirement_inbox\ntags: [需求文档, 需求收集, 知识库更新, Agent]\naliases: [需求文档目录, 需求收集目录, 需求入口]\nsource: manual\nstatus: active\nowner: 产品经理 / 业务主管\nupdated: 2026-05\n---\n\n# 需求文档\n\n本目录用于集中存放后续持续补充的业务需求文档、业务规则文档、流程补充文档和需求变更文档。\n\n## 使用方式\n\n1. 所有新增需求文档优先放入本目录。\n2. 建议使用 `03_规范与模板/需求说明模板.md` 或 `03_规范与模板/业务规则与需求补充模板.md` 创建文档。\n3. 文档确认有效后，同步更新业务流程索引和 Agent 检索索引。\n4. Agent 回答具体业务需求时，应优先检索本目录。\n\n## 推荐命名\n\n```text\n业务域_需求或规则名称_YYYYMMDD.md\n```\n\n示例：\n\n```text\n采购_供应商准入规则_20260526.md\n库存_出入库审批规则_20260526.md\n销售_客户授信额度需求_20260526.md\n```\n\n## 文档状态\n\n每个需求文档建议在 Frontmatter 中维护 `status`：\n\n| 状态 | 含义 |\n|---|---|\n| draft | 草稿，尚未确认 |\n| reviewing | 评审中 |\n| active | 已确认，可作为 Agent 回答依据 |\n| deprecated | 已废弃，仅归档参考 |\n\n## 必填内容\n\n每个需求文档至少包含：\n\n- 需求背景\n- 适用范围\n- 涉及角色\n- 业务规则\n- 业务流程\n- 异常处理\n- 权限要求\n- 验收口径\n- Agent 检索字段\n- 变更记录\n\n## 索引维护\n\n新增或修改需求文档后，需要同步更新：\n\n- `05_需求文档/需求文档索引.md`\n- `01_业务流程/业务规则索引.md`\n- `01_业务流程/业务对象字典.md`\n- `04_Agent检索/关键词索引.md`\n- `04_Agent检索/同义词表.md`\n- `04_Agent检索/来源文件索引.md`\n\n## 验证流程\n\n新增需求文档后，按 `04_Agent检索/知识库持续更新与验证流程.md` 执行验证，并将验证结果记录到：\n\n- `05_需求文档/需求文档索引.md`\n- `01_业务流程/业务补充验证记录.md`\n", "backlinks": [ "article:欢迎", "article:知识库使用说明" ] } }, { "id": "article:05_需求文档/需求文档索引", "type": "article", "name": "需求文档索引", "filePath": "05_需求文档\\需求文档索引.md", "summary": "本文件记录 `05_需求文档/` 下所有正式需求文档，供人工维护和 Agent 检索定位。", "tags": [ "05_需求文档", "Agent检索]", "[需求文档", "索引" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: requirement_index\ntags: [需求文档, 索引, Agent检索]\naliases: [需求索引, 需求文档清单, 需求清单]\nsource: manual\nstatus: active\nowner: 产品经理 / 业务主管\nupdated: 2026-05\n---\n\n# 需求文档索引\n\n本文件记录 `05_需求文档/` 下所有正式需求文档，供人工维护和 Agent 检索定位。\n\n## 需求文档清单\n\n| 编号 | 业务域 | 需求/规则名称 | 文件 | 状态 | 负责人 | 更新时间 | 验证状态 |\n|---|---|---|---|---|---|---|---|\n| | | | | | | | 未验证 |\n\n## Agent 检索关键词\n\n| 关键词/问法 | 标准术语 | 命中文件 | 答案要点 |\n|---|---|---|---|\n| | | | |\n\n## 维护规则\n\n1. 新增需求文档后，必须在“需求文档清单”新增一行。\n2. 每个需求文档至少维护 3 个可检索问法。\n3. `状态=active` 的文档可作为 Agent 回答依据。\n4. `status=draft/reviewing` 的文档只能作为草稿参考，Agent 回答时需说明尚未确认。\n5. `status=deprecated` 的文档不得作为当前规则依据，只能说明历史背景。\n\n## 验证记录摘要\n\n| 日期 | 文件 | 验证问题数 | 通过数 | 失败数 | 结论 |\n|---|---|---:|---:|---:|---|\n| | | | | | |\n", "backlinks": [ "article:知识库使用说明", "article:知识库使用说明" ] } }, { "id": "article:06_里程碑/README", "type": "article", "name": "里程碑", "filePath": "06_里程碑\\README.md", "summary": "本目录用于存放项目阶段计划、里程碑节点、阶段评审记录和上线节奏说明。", "tags": [ "06_里程碑", "[里程碑", "知识库]", "项目管理" ], "complexity": "moderate", "knowledgeMeta": { "wikilinks": [ "里程碑索引", "阶段计划模板", "里程碑评审记录", "../05_需求文档/README", "../02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "../08_测试相关/README" ], "content": "---\ntype: milestone_home\ntags: [里程碑, 项目管理, 知识库]\naliases: [里程碑入口, 项目里程碑]\nsource: manual\nstatus: active\nowner: 项目经理\nupdated: 2026-05\n---\n\n# 里程碑\n\n本目录用于存放项目阶段计划、里程碑节点、阶段评审记录和上线节奏说明。\n\n## 二级入口\n\n- [[里程碑索引]]\n- [[阶段计划模板]]\n- [[里程碑评审记录]]\n\n## 存放内容\n\n- 项目启动节点\n- 需求评审节点\n- 原型/高保真确认节点\n- 开发启动节点\n- 测试准入节点\n- 上线检查节点\n- 复盘回流节点\n\n## 命名建议\n\n```text\n项目名_里程碑计划_YYYYMMDD.md\n项目名_阶段评审记录_YYYYMMDD.md\n```\n\n## 关联目录\n\n- 需求依据：[[../05_需求文档/README|需求文档]]\n- 流程依据：[[../02_项目管理流程/AI驱动内部系统开发流程_V3_总览|项目管理流程]]\n- 测试准入：[[../08_测试相关/README|测试相关]]\n", "backlinks": [ "article:欢迎", "article:知识库使用说明" ] } }, { "id": "article:06_里程碑/里程碑索引", "type": "article", "name": "里程碑索引", "filePath": "06_里程碑\\里程碑索引.md", "summary": "| 项目 | 里程碑名称 | 文件 | 阶段 | 负责人 | 计划时间 | 当前状态 | |---|---|---|---|---|---|---| | | | | | | | |", "tags": [ "06_里程碑", "Agent检索]", "[里程碑", "索引" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: milestone_index\ntags: [里程碑, 索引, Agent检索]\naliases: [里程碑清单, 项目节点索引]\nsource: manual\nstatus: active\nowner: 项目经理\nupdated: 2026-05\n---\n\n# 里程碑索引\n\n## 里程碑文档清单\n\n| 项目 | 里程碑名称 | 文件 | 阶段 | 负责人 | 计划时间 | 当前状态 |\n|---|---|---|---|---|---|---|\n| | | | | | | |\n\n## Agent 检索关键词\n\n| 问法 | 标准术语 | 命中文件 | 答案要点 |\n|---|---|---|---|\n| | | | |\n\n## 维护规则\n\n- 新增里程碑计划后，在本索引登记。\n- 每个里程碑应关联至少一个需求文档或项目管理阶段。\n- Agent 回答项目进度、节点、准入问题时，应引用本索引或具体里程碑文件。\n", "backlinks": [ "article:06_里程碑/README", "article:知识库使用说明" ] } }, { "id": "article:06_里程碑/里程碑评审记录", "type": "article", "name": "里程碑评审记录", "filePath": "06_里程碑\\里程碑评审记录.md", "summary": "| 日期 | 项目 | 阶段 | 评审结论 | 遗留问题 | 负责人 | 后续动作 | |---|---|---|---|---|---|---| | | | | | | | |", "tags": [ "06_里程碑", "[里程碑", "记录]", "评审" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: milestone_review_log\ntags: [里程碑, 评审, 记录]\naliases: [阶段评审记录, 里程碑评审]\nsource: manual\nstatus: active\nowner: 项目经理\nupdated: 2026-05\n---\n\n# 里程碑评审记录\n\n| 日期 | 项目 | 阶段 | 评审结论 | 遗留问题 | 负责人 | 后续动作 |\n|---|---|---|---|---|---|---|\n| | | | | | | |\n", "backlinks": [ "article:06_里程碑/README" ] } }, { "id": "article:06_里程碑/阶段计划模板", "type": "article", "name": "阶段计划模板", "filePath": "06_里程碑\\阶段计划模板.md", "summary": "| 项目 | 内容 | |---|---| | 项目名称 | | | 关联需求 | | | 当前阶段 | | | 负责人 | | | 计划开始 | | | 计划结束 | |", "tags": [ "06_里程碑", "[里程碑", "模板]", "阶段计划" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: milestone_template\ntags: [里程碑, 阶段计划, 模板]\naliases: [阶段计划, 里程碑模板]\nsource: manual\nstatus: active\nowner: 项目经理\nupdated: 2026-05\n---\n\n# 阶段计划模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 项目名称 | |\n| 关联需求 | |\n| 当前阶段 | |\n| 负责人 | |\n| 计划开始 | |\n| 计划结束 | |\n\n## 阶段目标\n\n\n## 输入材料\n\n- 需求文档：\n- 业务流程：\n- 技术文档：\n- 测试材料：\n\n## 关键任务\n\n| 任务 | 负责人 | 截止时间 | 输出物 | 状态 |\n|---|---|---|---|---|\n| | | | | |\n\n## 阶段交付物\n\n\n## 准入/准出条件\n\n\n## 风险与阻塞\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", "backlinks": [ "article:06_里程碑/README" ] } }, { "id": "article:07_技术文档/README", "type": "article", "name": "技术文档", "filePath": "07_技术文档\\README.md", "summary": "本目录用于存放系统架构、数据模型、接口说明、实现方案、部署说明和技术决策记录。", "tags": [ "07_技术文档", "[技术文档", "开发", "架构", "知识库]" ], "complexity": "moderate", "knowledgeMeta": { "wikilinks": [ "技术文档索引", "系统架构说明模板", "接口说明模板", "技术决策记录", "../05_需求文档/README", "../08_测试相关/README", "../06_里程碑/README" ], "content": "---\ntype: technical_docs_home\ntags: [技术文档, 架构, 开发, 知识库]\naliases: [技术文档入口, 技术资料]\nsource: manual\nstatus: active\nowner: 技术负责人\nupdated: 2026-05\n---\n\n# 技术文档\n\n本目录用于存放系统架构、数据模型、接口说明、实现方案、部署说明和技术决策记录。\n\n## 二级入口\n\n- [[技术文档索引]]\n- [[系统架构说明模板]]\n- [[接口说明模板]]\n- [[技术决策记录]]\n\n## 存放内容\n\n- 系统架构说明\n- 模块设计说明\n- 数据表/业务对象设计\n- API 接口说明\n- 权限与安全设计\n- 部署与配置说明\n- 技术决策记录\n\n## 命名建议\n\n```text\n系统或模块_技术方案_YYYYMMDD.md\n系统或模块_接口说明_YYYYMMDD.md\n系统或模块_数据模型_YYYYMMDD.md\n```\n\n## 关联目录\n\n- 需求依据：[[../05_需求文档/README|需求文档]]\n- 测试依据：[[../08_测试相关/README|测试相关]]\n- 里程碑：[[../06_里程碑/README|里程碑]]\n", "backlinks": [ "article:欢迎", "article:知识库使用说明" ] } }, { "id": "article:07_技术文档/技术决策记录", "type": "article", "name": "技术决策记录", "filePath": "07_技术文档\\技术决策记录.md", "summary": "| 日期 | 决策主题 | 背景 | 决策结论 | 影响范围 | 关联需求/技术文档 | |---|---|---|---|---|---| | | | | | | |", "tags": [ "07_技术文档", "ADR]", "[技术文档", "技术决策" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: adr_log\ntags: [技术文档, 技术决策, ADR]\naliases: [技术决策, ADR]\nsource: manual\nstatus: active\nowner: 技术负责人\nupdated: 2026-05\n---\n\n# 技术决策记录\n\n| 日期 | 决策主题 | 背景 | 决策结论 | 影响范围 | 关联需求/技术文档 |\n|---|---|---|---|---|---|\n| | | | | | |\n", "backlinks": [ "article:07_技术文档/README" ] } }, { "id": "article:07_技术文档/技术文档索引", "type": "article", "name": "技术文档索引", "filePath": "07_技术文档\\技术文档索引.md", "summary": "| 模块/系统 | 文档类型 | 文件 | 关联需求 | 负责人 | 更新时间 | 状态 | |---|---|---|---|---|---|---| | | | | | | | |", "tags": [ "07_技术文档", "Agent检索]", "[技术文档", "索引" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: technical_docs_index\ntags: [技术文档, 索引, Agent检索]\naliases: [技术索引, 技术资料清单]\nsource: manual\nstatus: active\nowner: 技术负责人\nupdated: 2026-05\n---\n\n# 技术文档索引\n\n## 技术文档清单\n\n| 模块/系统 | 文档类型 | 文件 | 关联需求 | 负责人 | 更新时间 | 状态 |\n|---|---|---|---|---|---|---|\n| | | | | | | |\n\n## Agent 检索关键词\n\n| 问法 | 标准术语 | 命中文件 | 答案要点 |\n|---|---|---|---|\n| | | | |\n\n## 维护规则\n\n- 新增技术方案、接口说明、数据模型后，在本索引登记。\n- 技术文档必须关联需求文档或业务流程。\n- Agent 回答技术实现、接口、数据结构问题时，应优先检索本目录。\n", "backlinks": [ "article:07_技术文档/README", "article:知识库使用说明", "article:知识库使用说明" ] } }, { "id": "article:07_技术文档/接口说明模板", "type": "article", "name": "接口说明模板", "filePath": "07_技术文档\\接口说明模板.md", "summary": "| 项目 | 内容 | |---|---| | 接口名称 | | | 所属模块 | | | 关联需求 | | | 负责人 | | | 状态 | draft |", "tags": [ "07_技术文档", "[技术文档", "接口", "模板]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: api_template\ntags: [技术文档, 接口, 模板]\naliases: [接口模板, API说明模板]\nsource: manual\nstatus: active\nowner: 技术负责人\nupdated: 2026-05\n---\n\n# 接口说明模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 接口名称 | |\n| 所属模块 | |\n| 关联需求 | |\n| 负责人 | |\n| 状态 | draft |\n\n## 接口用途\n\n\n## 请求说明\n\n| 字段 | 类型 | 必填 | 说明 | 示例 |\n|---|---|---|---|---|\n| | | | | |\n\n## 响应说明\n\n| 字段 | 类型 | 说明 | 示例 |\n|---|---|---|---|\n| | | | |\n\n## 业务规则\n\n\n## 异常码\n\n| 异常码 | 含义 | 处理方式 |\n|---|---|---|\n| | | |\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", "backlinks": [ "article:07_技术文档/README" ] } }, { "id": "article:07_技术文档/系统架构说明模板", "type": "article", "name": "系统架构说明模板", "filePath": "07_技术文档\\系统架构说明模板.md", "summary": "| 项目 | 内容 | |---|---| | 系统/模块 | | | 关联需求 | | | 负责人 | | | 状态 | draft |", "tags": [ "07_技术文档", "[技术文档", "架构", "模板]" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: architecture_template\ntags: [技术文档, 架构, 模板]\naliases: [架构说明模板]\nsource: manual\nstatus: active\nowner: 技术负责人\nupdated: 2026-05\n---\n\n# 系统架构说明模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 系统/模块 | |\n| 关联需求 | |\n| 负责人 | |\n| 状态 | draft |\n\n## 背景与目标\n\n\n## 架构说明\n\n\n## 模块划分\n\n| 模块 | 职责 | 输入 | 输出 | 依赖 |\n|---|---|---|---|---|\n| | | | | |\n\n## 数据模型\n\n\n## 接口关系\n\n\n## 权限与安全\n\n\n## 异常与边界\n\n\n## 部署与配置\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", "backlinks": [ "article:07_技术文档/README" ] } }, { "id": "article:08_测试相关/README", "type": "article", "name": "测试相关", "filePath": "08_测试相关\\README.md", "summary": "本目录用于存放测试计划、测试用例、测试报告、缺陷记录、验收记录和上线检查材料。", "tags": [ "08_测试相关", "[测试", "测试用例", "知识库]", "验收" ], "complexity": "moderate", "knowledgeMeta": { "wikilinks": [ "测试用例索引", "测试用例模板", "测试计划模板", "缺陷记录模板", "验收记录模板", "上线检查模板", "../05_需求文档/README", "../07_技术文档/README", "../06_里程碑/README", "../02_项目管理流程/阶段2.5_测试提前补漏", "../02_项目管理流程/阶段4_测试培训上线回流" ], "content": "---\ntype: testing_home\ntags: [测试, 测试用例, 验收, 知识库]\naliases: [测试相关入口, 测试文档]\nsource: manual\nstatus: active\nowner: 测试负责人\nupdated: 2026-05\n---\n\n# 测试相关\n\n本目录用于存放测试计划、测试用例、测试报告、缺陷记录、验收记录和上线检查材料。\n\n## 二级入口\n\n- [[测试用例索引]]\n- [[测试用例模板]]\n- [[测试计划模板]]\n- [[缺陷记录模板]]\n- [[验收记录模板]]\n- [[上线检查模板]]\n\n## 存放内容\n\n- 测试计划\n- 测试用例\n- 测试执行记录\n- 缺陷记录\n- 验收记录\n- 上线检查记录\n- 回归测试说明\n\n## 命名建议\n\n```text\n项目或模块_测试用例_YYYYMMDD.md\n项目或模块_测试计划_YYYYMMDD.md\n项目或模块_缺陷记录_YYYYMMDD.md\n项目或模块_验收记录_YYYYMMDD.md\n```\n\n## 关联目录\n\n- 需求依据：[[../05_需求文档/README|需求文档]]\n- 技术依据：[[../07_技术文档/README|技术文档]]\n- 里程碑依据：[[../06_里程碑/README|里程碑]]\n- 流程依据：[[../02_项目管理流程/阶段2.5_测试提前补漏|阶段2.5 测试提前补漏]]、[[../02_项目管理流程/阶段4_测试培训上线回流|阶段4 测试培训上线回流]]\n", "backlinks": [ "article:欢迎", "article:知识库使用说明" ] } }, { "id": "article:08_测试相关/上线检查模板", "type": "article", "name": "上线检查模板", "filePath": "08_测试相关\\上线检查模板.md", "summary": "| 项目 | 内容 | |---|---| | 项目/模块 | | | 关联需求 | | | 关联里程碑 | | | 负责人 | | | 检查日期 | |", "tags": [ "08_测试相关", "[上线检查", "模板]", "测试" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: go_live_checklist_template\ntags: [上线检查, 测试, 模板]\naliases: [上线检查, 发布检查]\nsource: manual\nstatus: active\nowner: 测试负责人 / 项目经理\nupdated: 2026-05\n---\n\n# 上线检查模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 项目/模块 | |\n| 关联需求 | |\n| 关联里程碑 | |\n| 负责人 | |\n| 检查日期 | |\n\n## 上线前检查项\n\n| 检查项 | 负责人 | 结果 | 备注 |\n|---|---|---|---|\n| 需求已确认 | | | |\n| 测试用例已执行 | | | |\n| P0/P1 缺陷已关闭 | | | |\n| 用户培训已完成 | | | |\n| 回滚方案已确认 | | | |\n| 数据备份已确认 | | | |\n\n## 上线结论\n\n\n## 回滚条件\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", "backlinks": [] } }, { "id": "article:08_测试相关/测试用例模板", "type": "article", "name": "测试用例模板", "filePath": "08_测试相关\\测试用例模板.md", "summary": "| 项目 | 内容 | |---|---| | 项目/模块 | | | 关联需求 | | | 关联技术文档 | | | 测试负责人 | | | 状态 | draft |", "tags": [ "08_测试相关", "[测试用例", "模板]", "测试" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: test_case_template\ntags: [测试用例, 测试, 模板]\naliases: [用例模板, 测试用例]\nsource: manual\nstatus: active\nowner: 测试负责人\nupdated: 2026-05\n---\n\n# 测试用例模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 项目/模块 | |\n| 关联需求 | |\n| 关联技术文档 | |\n| 测试负责人 | |\n| 状态 | draft |\n\n## 测试范围\n\n\n## 前置条件\n\n\n## 测试用例\n\n| 用例编号 | 场景 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | 状态 |\n|---|---|---|---|---|---|---|\n| TC-001 | | | | | P1 | 未执行 |\n\n## 边界与异常场景\n\n\n## 验收口径\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", "backlinks": [ "article:08_测试相关/README" ] } }, { "id": "article:08_测试相关/测试用例索引", "type": "article", "name": "测试用例索引", "filePath": "08_测试相关\\测试用例索引.md", "summary": "| 编号 | 项目/模块 | 用例集名称 | 文件 | 关联需求 | 关联技术文档 | 负责人 | 状态 | 更新时间 | |---|---|---|---|---|---|---|---|---| | | | | | | | | 未验证 | |", "tags": [ "08_测试相关", "Agent检索]", "[测试用例", "测试", "索引" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: test_case_index\ntags: [测试用例, 测试, 索引, Agent检索]\naliases: [测试用例清单, 用例索引]\nsource: manual\nstatus: active\nowner: 测试负责人\nupdated: 2026-05\n---\n\n# 测试用例索引\n\n## 测试用例清单\n\n| 编号 | 项目/模块 | 用例集名称 | 文件 | 关联需求 | 关联技术文档 | 负责人 | 状态 | 更新时间 |\n|---|---|---|---|---|---|---|---|---|\n| | | | | | | | 未验证 | |\n\n## Agent 检索关键词\n\n| 问法 | 标准术语 | 命中文件 | 答案要点 |\n|---|---|---|---|\n| | | | |\n\n## 维护规则\n\n- 新增测试用例后，必须在本索引登记。\n- 每个测试用例文件必须关联至少一个需求文档。\n- 若测试用例依赖接口、数据模型或技术方案，应关联技术文档。\n- Agent 回答测试范围、验收口径、缺陷复现问题时，应优先检索本目录。\n", "backlinks": [ "article:08_测试相关/README", "article:知识库使用说明", "article:知识库使用说明" ] } }, { "id": "article:08_测试相关/测试计划模板", "type": "article", "name": "测试计划模板", "filePath": "08_测试相关\\测试计划模板.md", "summary": "| 项目 | 内容 | |---|---| | 项目/模块 | | | 关联需求 | | | 关联里程碑 | | | 测试负责人 | | | 计划周期 | |", "tags": [ "08_测试相关", "[测试计划", "模板]", "测试" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: test_plan_template\ntags: [测试计划, 测试, 模板]\naliases: [测试计划模板]\nsource: manual\nstatus: active\nowner: 测试负责人\nupdated: 2026-05\n---\n\n# 测试计划模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 项目/模块 | |\n| 关联需求 | |\n| 关联里程碑 | |\n| 测试负责人 | |\n| 计划周期 | |\n\n## 测试目标\n\n\n## 测试范围\n\n\n## 不在范围内\n\n\n## 测试资源\n\n\n## 测试安排\n\n| 阶段 | 时间 | 负责人 | 输出物 |\n|---|---|---|---|\n| | | | |\n\n## 准入条件\n\n\n## 准出条件\n\n\n## 风险\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", "backlinks": [ "article:08_测试相关/README" ] } }, { "id": "article:08_测试相关/缺陷记录模板", "type": "article", "name": "缺陷记录模板", "filePath": "08_测试相关\\缺陷记录模板.md", "summary": "| 项目 | 内容 | |---|---| | 缺陷编号 | BUG- | | 项目/模块 | | | 关联需求 | | | 关联用例 | | | 严重级别 | | | 当前状态 | open | | 负责人 | |", "tags": [ "08_测试相关", "[缺陷", "模板]", "测试" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: defect_template\ntags: [缺陷, 测试, 模板]\naliases: [Bug记录模板, 缺陷记录]\nsource: manual\nstatus: active\nowner: 测试负责人\nupdated: 2026-05\n---\n\n# 缺陷记录模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 缺陷编号 | BUG- |\n| 项目/模块 | |\n| 关联需求 | |\n| 关联用例 | |\n| 严重级别 | |\n| 当前状态 | open |\n| 负责人 | |\n\n## 问题描述\n\n\n## 复现步骤\n\n1. \n2. \n3. \n\n## 实际结果\n\n\n## 预期结果\n\n\n## 影响范围\n\n\n## 修复结论\n\n\n## 回归验证\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", "backlinks": [ "article:08_测试相关/README" ] } }, { "id": "article:08_测试相关/验收记录模板", "type": "article", "name": "验收记录模板", "filePath": "08_测试相关\\验收记录模板.md", "summary": "| 项目 | 内容 | |---|---| | 项目/模块 | | | 关联需求 | | | 关联测试用例 | | | 验收负责人 | | | 验收日期 | | | 验收结论 | |", "tags": [ "08_测试相关", "[验收", "模板]", "测试" ], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "---\ntype: acceptance_template\ntags: [验收, 测试, 模板]\naliases: [验收记录, UAT模板]\nsource: manual\nstatus: active\nowner: 测试负责人 / 业务负责人\nupdated: 2026-05\n---\n\n# 验收记录模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 项目/模块 | |\n| 关联需求 | |\n| 关联测试用例 | |\n| 验收负责人 | |\n| 验收日期 | |\n| 验收结论 | |\n\n## 验收范围\n\n\n## 验收结果\n\n| 验收项 | 预期结果 | 实际结果 | 结论 | 备注 |\n|---|---|---|---|---|\n| | | | | |\n\n## 遗留问题\n\n\n## 上线建议\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", "backlinks": [ "article:08_测试相关/README" ] } }, { "id": "article:20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", "type": "article", "name": "20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", "filePath": "20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md", "summary": "Wiki article: 20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", "tags": [], "complexity": "simple", "knowledgeMeta": { "wikilinks": [], "content": "", "backlinks": [] } }, { "id": "article:欢迎", "type": "article", "name": "欢迎使用如愿知识库", "filePath": "欢迎.md", "summary": "请从 [[00_首页/知识库首页]] 开始。", "tags": [ "[知识库", "入口]" ], "complexity": "moderate", "knowledgeMeta": { "wikilinks": [ "00_首页/知识库首页", "知识库使用说明", "00_首页/知识地图", "00_首页/Agent问答入口", "05_需求文档/README", "06_里程碑/README", "07_技术文档/README", "08_测试相关/README", "04_Agent检索/检索说明" ], "content": "---\ntype: index\ntags: [知识库, 入口]\naliases: [欢迎, 首页]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 欢迎使用如愿知识库\n\n请从 [[00_首页/知识库首页]] 开始。\n\n常用入口：\n\n- [[知识库使用说明]]\n- [[00_首页/知识地图]]\n- [[00_首页/Agent问答入口]]\n- [[05_需求文档/README|需求文档]]\n- [[06_里程碑/README|里程碑]]\n- [[07_技术文档/README|技术文档]]\n- [[08_测试相关/README|测试相关]]\n- [[04_Agent检索/检索说明]]", "backlinks": [ "article:知识库使用说明" ] } }, { "id": "article:知识库使用说明", "type": "article", "name": "如愿知识库使用说明", "filePath": "知识库使用说明.md", "summary": "本文档说明如愿知识库的用途、目录结构、文档存放规则、索引维护规则、Obsidian 图谱使用方式，以及 Agent 如何基于知识库回答问题。", "tags": [ "Agent检索]", "Obsidian", "[知识库", "使用说明" ], "complexity": "complex", "knowledgeMeta": { "wikilinks": [ "欢迎", "00_首页/知识库首页", "00_首页/知识地图", "00_首页/Agent问答入口", "04_Agent检索/检索说明", "00_首页/知识地图", "00_首页/Agent问答入口", "05_需求文档/README", "06_里程碑/README", "07_技术文档/README", "08_测试相关/README", "02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "04_Agent检索/检索说明", "04_Agent检索/来源文件索引", "05_需求文档/需求文档索引", "01_业务流程/业务规则索引", "01_业务流程/业务对象字典", "04_Agent检索/关键词索引", "04_Agent检索/来源文件索引", "06_里程碑/里程碑索引", "07_技术文档/技术文档索引", "04_Agent检索/关键词索引", "04_Agent检索/来源文件索引", "08_测试相关/测试用例索引", "05_需求文档/需求文档索引", "07_技术文档/技术文档索引", "08_测试相关/测试用例索引", "05_需求文档/xxx需求文档", "07_技术文档/xxx技术方案", "08_测试相关/xxx测试用例", "04_Agent检索/关键词索引", "04_Agent检索/同义词表", "04_Agent检索/来源文件索引", "04_Agent检索/知识库持续更新与验证流程" ], "content": "---\ntype: knowledge_base_guide\ntags: [知识库, 使用说明, Obsidian, Agent检索]\naliases: [如愿知识库使用说明, 知识库操作说明, 知识库维护说明]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 如愿知识库使用说明\n\n本文档说明如愿知识库的用途、目录结构、文档存放规则、索引维护规则、Obsidian 图谱使用方式，以及 Agent 如何基于知识库回答问题。\n\n## 1. 知识库定位\n\n如愿知识库用于沉淀内部系统建设过程中的：\n\n- 业务需求\n- 业务规则\n- 业务流程\n- 项目里程碑\n- 技术方案\n- 测试用例\n- 缺陷与验收记录\n- Agent 检索规则\n\n知识库不是单纯存文件，而是要形成可检索、可追溯、可被 Agent 引用回答的知识网络。\n\n## 2. 推荐打开方式\n\n推荐使用 Obsidian 打开以下目录作为 Vault：\n\n```text\nD:\\AIcoding\\WishFulfilled\\知识库\\如愿知识库\n```\n\n打开后建议从以下入口开始：\n\n1. [[欢迎]]\n2. [[00_首页/知识库首页]]\n3. [[00_首页/知识地图]]\n4. [[00_首页/Agent问答入口]]\n5. [[04_Agent检索/检索说明]]\n\n## 3. 主目录说明\n\n```text\n如愿知识库/\n├─ 00_首页/ # 首页、知识地图、Agent 问答入口\n├─ 01_业务流程/ # 业务流程、业务对象、业务规则、补充验证记录\n├─ 02_项目管理流程/ # 项目阶段、角色职责、交付物、检查清单、FAQ\n├─ 03_规范与模板/ # 需求、业务规则、会议、上线检查等模板\n├─ 04_Agent检索/ # 检索说明、关键词、同义词、来源文件索引\n├─ 05_需求文档/ # 正式需求文档、需求索引\n├─ 06_里程碑/ # 里程碑计划、阶段计划、评审记录\n├─ 07_技术文档/ # 技术方案、系统架构、接口说明、技术决策\n├─ 08_测试相关/ # 测试用例、测试计划、缺陷、验收、上线检查\n├─ 99_归档/ # 历史文档、废弃文档、仅供参考内容\n├─ 欢迎.md # Obsidian 入口页\n├─ 知识库使用说明.md # 本文档\n└─ Git使用说明.md # Git 仓库协作说明\n```\n\n## 4. 日常使用入口\n\n| 使用场景 | 优先入口 |\n|---|---|\n| 想了解知识库整体结构 | [[00_首页/知识地图]] |\n| 想让 Agent 回答业务问题 | [[00_首页/Agent问答入口]] |\n| 查看或新增需求 | [[05_需求文档/README]] |\n| 查看或新增里程碑 | [[06_里程碑/README]] |\n| 查看或新增技术方案 | [[07_技术文档/README]] |\n| 查看或新增测试用例 | [[08_测试相关/README]] |\n| 查看项目管理阶段 | [[02_项目管理流程/AI驱动内部系统开发流程_V3_总览]] |\n| 查看 Agent 检索规则 | [[04_Agent检索/检索说明]] |\n| 查看来源依据 | [[04_Agent检索/来源文件索引]] |\n\n## 5. 文档应该放在哪里\n\n### 5.1 需求文档\n\n放入：\n\n```text\n05_需求文档/\n```\n\n适合存放：\n\n- 正式需求说明\n- 业务规则说明\n- 需求变更说明\n- 业务补充说明\n- 产品口径说明\n\n推荐命名：\n\n```text\n业务域_需求或规则名称_YYYYMMDD.md\n```\n\n示例：\n\n```text\nUSER评价业务闭环_数据流与中间对象设计_20260517.md\n采购_供应商准入规则_20260526.md\n库存_出入库审批规则_20260526.md\n```\n\n新增后应同步维护：\n\n- [[05_需求文档/需求文档索引]]\n- [[01_业务流程/业务规则索引]]，如涉及业务规则\n- [[01_业务流程/业务对象字典]]，如涉及新增业务对象\n- [[04_Agent检索/关键词索引]]，如需要 Agent 检索命中\n- [[04_Agent检索/来源文件索引]]，如是新的权威来源\n\n### 5.2 里程碑文档\n\n放入：\n\n```text\n06_里程碑/\n```\n\n适合存放：\n\n- 项目里程碑计划\n- 阶段计划\n- 阶段评审记录\n- 上线节奏\n- 准入/准出记录\n\n推荐命名：\n\n```text\n项目名_里程碑计划_YYYYMMDD.md\n项目名_阶段评审记录_YYYYMMDD.md\n```\n\n新增后应同步维护：\n\n- [[06_里程碑/里程碑索引]]\n\n### 5.3 技术文档\n\n放入：\n\n```text\n07_技术文档/\n```\n\n适合存放：\n\n- 系统架构说明\n- 数据模型说明\n- 接口说明\n- 模块设计\n- 技术方案\n- 部署说明\n- 技术决策记录\n\n推荐命名：\n\n```text\n系统或模块_技术方案_YYYYMMDD.md\n系统或模块_接口说明_YYYYMMDD.md\n系统或模块_数据模型_YYYYMMDD.md\n```\n\n新增后应同步维护：\n\n- [[07_技术文档/技术文档索引]]\n- [[04_Agent检索/关键词索引]]，如需要 Agent 检索\n- [[04_Agent检索/来源文件索引]]，如是新的技术依据\n\n### 5.4 测试相关文档\n\n放入：\n\n```text\n08_测试相关/\n```\n\n适合存放：\n\n- 测试计划\n- 测试用例\n- 缺陷记录\n- 验收记录\n- 上线检查\n- 回归测试记录\n\n推荐命名：\n\n```text\n项目名_模块名_测试计划_YYYYMMDD.md\n项目名_模块名_测试用例_YYYYMMDD.md\n项目名_模块名_缺陷记录_YYYYMMDD.md\n项目名_模块名_验收记录_YYYYMMDD.md\n```\n\n新增后应同步维护：\n\n- [[08_测试相关/测试用例索引]]\n- 关联需求文档\n- 关联里程碑或测试阶段\n\n测试用例必须能追溯到需求来源。\n\n### 5.5 业务流程文档\n\n放入：\n\n```text\n01_业务流程/\n```\n\n适合存放：\n\n- 已稳定的业务流程\n- 业务对象定义\n- 业务规则索引\n- 业务补充验证记录\n\n如果是新需求或尚未确认的业务规则，优先放入 `05_需求文档/`，确认稳定后再沉淀到 `01_业务流程/`。\n\n### 5.6 模板文档\n\n放入：\n\n```text\n03_规范与模板/\n```\n\n适合存放：\n\n- 需求说明模板\n- 业务规则补充模板\n- 会议纪要模板\n- 上线检查模板\n- 通用文档模板\n\n模板只用于复用格式，不应存放具体项目内容。\n\n### 5.7 归档文档\n", "backlinks": [ "article:欢迎" ] } }, { "id": "topic:使用说明", "type": "topic", "name": "使用说明", "summary": "Category from index: 使用说明 (2 articles)", "tags": [ "category" ], "complexity": "simple" }, { "id": "topic:需求文档", "type": "topic", "name": "需求文档", "summary": "Category from index: 需求文档 (6 articles)", "tags": [ "category" ], "complexity": "simple" }, { "id": "topic:里程碑", "type": "topic", "name": "里程碑", "summary": "Category from index: 里程碑 (7 articles)", "tags": [ "category" ], "complexity": "simple" }, { "id": "topic:技术文档", "type": "topic", "name": "技术文档", "summary": "Category from index: 技术文档 (5 articles)", "tags": [ "category" ], "complexity": "simple" }, { "id": "topic:测试相关", "type": "topic", "name": "测试相关", "summary": "Category from index: 测试相关 (9 articles)", "tags": [ "category" ], "complexity": "simple" }, { "id": "topic:agent-检索", "type": "topic", "name": "Agent 检索", "summary": "Category from index: Agent 检索 (6 articles)", "tags": [ "category" ], "complexity": "simple" }, { "id": "source:AI_驱动_内部系统开发流程_V3", "type": "source", "name": "AI_驱动_内部系统开发流程_V3.docx", "filePath": "raw\\AI_驱动_内部系统开发流程_V3.docx", "summary": "Raw source (.docx, 36 KB)", "tags": [ "raw", "docx" ], "complexity": "simple" }, { "id": "doc:05_需求文档/00-系统总览", "type": "document", "name": "如愿 · 系统总览 v1.0", "filePath": "05_需求文档/00-系统总览.md", "summary": "如愿 · 系统总览 v1.0 2 文件信息 4 文件名称： 00 系统总览.md 项目代号： 如愿 工作目录： /root/user business/ 当前版本： v1.0 创建日期： 2026 05 22 上游基线： docs from business/20260517 USER评价业务闭环主流程与后续工作基线 v1.2.md docs from bu", "tags": [ "05_需求文档", "需求文档" ], "complexity": "complex", "knowledgeMeta": { "content": "# 如愿 · 系统总览 v1.0\n 2|\n## 文件信息\n 4|\n- 文件名称：`00-系统总览.md`\n- 项目代号：**如愿**\n- 工作目录：`/root/user-business/`\n- 当前版本：`v1.0`\n- 创建日期：`2026-05-22`\n- 上游基线：\n - `docs-from-business/20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md`\n - `docs-from-business/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`\n 13|\n## 目录\n 15|\n1. [项目目标与原则](#1-项目目标与原则)\n2. [系统总边界](#2-系统总边界)\n3. [子系统划分](#3-子系统划分)\n4. [子系统间依赖关系](#4-子系统间依赖关系)\n5. [角色 → 独立前端映射](#5-角色--独立前端映射)\n6. [子系统内外边界明细](#6-子系统内外边界明细)\n7. [总系统级业务澄清问题清单](#7-总系统级业务澄清问题清单)\n8. [待确认的内外边界](#8-待确认的内外边界)\n9. [附录：子系统文档索引](#9-附录子系统文档索引)\n 25|\n---\n 27|\n## 1. 项目目标与原则\n 29|\n### 1.1 项目代号：\"如愿\"\n\n> 取名\"如愿\"——系统做好能做的所有事（身份识别、需求评估、计划调度、渠道协同、风险拦截、结果追踪），让每一次运营投入都如愿转化为真实的评价提升和 ASIN 健康增长。Amazon 是否展示评价有平台的不确定性，但系统必须把可控环节做到极致。\n 33|\n### 1.2 核心架构目标\n 35|\n| # | 目标 | 说明 |\n| --- | --- | --- |\n| G1 | 前端分离 | 不同角色拥有独立前端应用，按需集成子系统能力 |\n| G2 | 清晰系统边界 | 明确系统内外边界，区分内部可控与外部依赖 |\n| G3 | 子系统解耦 | 子系统通过 API 契约通信，支持独立开发、独立部署 |\n| G4 | 并行开发 | 子系统之间尽量减少串行依赖，允许多团队并行推进 |\n| G5 | 独立角色前端 | Amazon 运营、用户运营、客服、风险管理、KOC/KOL 运营各自拥有独立前端 |\n 43|\n### 1.3 架构原则\n 45|\n| 原则 | 说明 |\n| --- | --- |\n| **单一数据源** | 每个业务事实只有一个子系统负责写入（Owner），其他子系统只读或通过 API 调用 |\n| **API 契约优先** | 子系统间通过明确 API 契约通信，先定义契约再实现 |\n| **真实人为核心** | 所有额度、风险、历史判断围绕「真实人」而非单一账号 |\n| **每次互动重判** | 身份、额度、风险不是一次性的，每次有效互动需重做判断 |\n| **审计不可少** | 所有状态变更、敏感访问、人工干预必须留痕 |\n 53|\n---\n 55|\n## 2. 系统总边界\n 57|\n### 2.1 边界总图\n 59|\n```\n┌─────────────────────────────────────────────────────────────────────┐\n│ 如愿 系统边界 │\n│ │\n│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │\n│ │ Amazon │ │ 用户运营 │ │ Amazon │ │ 风险/黑名 │ │\n│ │ 运营前端 │ │ 前端 │ │ 运营总监 │ │ 单前端 │ │\n│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │\n│ │ │ │ │ │\n│ ┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐ │\n│ │ 客服前端 │ │ 客服管理 │ │ KOC/KOL │ │ 管理驾驶 │ │\n│ │ │ │ 前端 │ │ 运营前端 │ │ 舱 │ │\n│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │\n│ │ │ │ │ │\n│ ═════╪══════════════╪══════════════╪══════════════╪══════ API网关 │\n│ │ │ │ │ │\n│ ┌────┴──────────────┴──────────────┴──────────────┴─────┐ │\n│ │ 内部子系统 │ │\n│ │ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ │\n│ │ │ 用户身 │ │需求与计│ │额度与频│ │多渠道触│ │ │\n│ │ │份上下文│ │划管理 │ │ 控 │ │达引擎 │ │ │\n│ │ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │ │\n│ │ ┌───┴────┐ ┌───┴────┐ ┌───┴────┐ ┌───┴────┐ │ │\n│ │ │客服工单│ │风险与反│ │评价结果│ │KOC/KOL │ │ │\n│ │ │与管理 │ │ 欺诈 │ │ 追踪 │ │ 协作 │ │ │\n│ │ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │ │\n│ │ ┌───┴────┐ │ │\n│ │ │审计与通│ │ │\n│ │ │知中心 │ │ │\n│ │ └────────┘ │ │\n│ └───────────────────────────────────────────────────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────────────┘\n 93|\n ║ 外部系统 ║\n 95|\n┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐\n│ Amazon │ │ JOYHUB │ │JOYCOLLAB │ │ 邮件服务 │ │ 财务系统 │\n│ Marketplace│ │ 用户平台 │ │ KOC平台 │ │ (ESP) │ │(返款/退款)│\n└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘\n```\n 101|\n### 2.2 系统内部（如愿系统）\n 103|\n| # | 子系统 | 代号 | 核心职责 | 详情文档 |\n| --- | --- | --- | --- | --- |\n| S1 | 用户身份与上下文 | `identity` | 真实人识别、身份线索归并、用户上下文卡 | [01-用户身份与上下文](01-子系统-用户身份与上下文.md) |\n| S2 | 需求与计划管理 | `planning` | 需求触发（人工/自动）、计划生成（推新/回评/免评）、审批工作流 | [02-需求与计划管理](02-子系统-需求与计划管理.md) |\n| S3 | 额度与频控 | `quota` | 月度测评/免评额度台账、累计评价额度、频控、预占 | [03-额度与频控](03-子系统-额度与频控.md) |\n| S4 | 多渠道触达引擎 | `outreach` | IM/EDM/APP Push/TEL 渠道调度、路由、去重、发送 | [04-多渠道触达引擎](04-子系统-多渠道触达引擎.md) |\n| S5 | 客服工单与管理 | `support` | 工单生命周期、自动分配、排班出勤、绩效统计 | [05-客服工单与管理](05-子系统-客服工单与管理.md) |\n| S6 | 风险与反欺诈 | `risk` | 强弱关联判断、黑名单、双重退款检测、风险事件 | [06-风险与反欺诈](06-子系统-风险与反欺诈.md) |\n| S7 | 评价结果追踪 | `review` | 评价提交记录、Amazon 展示核验、ASIN 健康回流 | [07-评价结果追踪](07-子系统-评价结果追踪.md) |\n| S8 | KOC/KOL 协作 | `creator` | KOC/KOL 匹配、内容跟踪、Code 管理、JOYCOLLAB 同步 | [08-KOC-KOL协作](08-子系统-KOC-KOL协作.md) |\n| S9 | 审计与通知中心 | `audit` | 状态变更审计、敏感访问日志、多类型通知/告警 | [09-审计与通知中心](09-子系统-审计与通知中心.md) |\n 115|\n### 2.3 系统外部（外部依赖）\n 117|\n| # | 外部系统 | 说明 | 交互方式 | 确认状态 |\n| --- | --- | --- | --- | --- |\n| E1 | **Amazon Marketplace** | 订单数据、评价数据、ASIN/Listing 健康数据、退款数据 | API 拉取 / 爬取 | ⚠️ 待确认 |\n| E2 | **JOYHUB 用户平台** | JOYHUB ID、设备信息、APP 行为数据、绑定玩具数据 | API 同步 | ⚠️ 待确认 |\n| E3 | **JOYCOLLAB** | KOC/KOL 内容数据、Code 使用数据、带货订单数据 | API 同步 | ⚠️ 待确认 |\n| E4 | **邮件服务 (ESP)** | EDM 发送、送达/打开/点击追踪、退订/硬退信 | SMTP + Webhook | ⚠️ 待确认 |\n| E5 | **财务系统** | 返款执行、返款状态、退款记录（OA 侧） | API 调用 | ⚠️ 待确认 |\n| E6 | **APP Push 服务** | APP 推送通道（FCM/APNs） | SDK / API | ⚠️ 待确认 |\n| E7 | **电话系统** | 外呼能力、来电识别、通话记录 | API / SIP | ⚠️ 待确认 |\n| E8 | **IM 平台 (WhatsApp?)** | IM 消息收发 | API | ⚠️ 待确认 |\n 128|\n---\n 130|\n## 3. 子系统划分\n 132|\n### 3.1 划分依据\n 134|\n子系统按照**业务域内聚**原则划分，每个子系统：\n 136|\n1. 拥有明确的数据所有权（该子系统是某些核心数据对象的唯一写入方）\n2. 对外暴露清晰的 API 契约\n3. 可以独立开发、测试、部署\n4. 尽量减少对其他子系统的强依赖（启动依赖）\n 141|\n### 3.2 各子系统数据所有权\n 143|\n| 子系统 | 拥有（写入）的核心数据对象 |\n| --- | --- |\n| identity | `person_profiles`、`person_identity_links`、`contact_context_snapshots`、`device_records` |\n| planning | `demands`、`plans`、`plan_items`、`approval_records`、`asin_catalog` |\n| quota | `person_quota_ledgers`、`quota_reservations`、`frequency_control_records` |\n| outreach | `channel_route_decisions`、`channel_dedup_records`、`im_interaction_records`、`edm_message_events`、`app_touch_events`、`tel_call_records` |\n| support | `support_tickets`、`support_followups`、`support_assignment_logs`、`attendance_records`、`shift_schedules`、`support_performance_snapshots` |\n| risk | `risk_signals`、`risk_cases`、`blacklist_entities`、`refund_match_results` |\n| review | `review_submission_records`、`review_display_checks`、`review_results` |\n| creator | `exemption_plan_tasks`、`creator_content_records`、`creator_profiles`、`code_records` |\n| audit | `interaction_audit_logs`、`notification_records`、`manual_review_tasks` |\n 155|\n---\n 157|\n## 4. 子系统间依赖关系\n 159|\n### 4.1 依赖图\n 161|\n```\n ┌─────────────────────────────────────────────┐\n │ audit (审计与通知) │\n │ ← 所有子系统向 audit 发送事件 │\n └─────────────────────────────────────────────┘\n ↑\n ┌─────────┬─────────┬─────┼─────┬─────────┬─────────┐\n │ │ │ │ │ │ │\n┌───┴───┐ ┌───┴───┐ ┌───┴───┐ │ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐\n│ review│ │creator│ │support│ │ │ risk │ │ quota │ │outreach│\n│(评价) │ │(KOC) │ │(客服) │ │ │(风险) │ │(额度) │ │(触达) │\n└───┬───┘ └───┬───┘ └───┬───┘ │ └───┬───┘ └───┬───┘ └───┬───┘\n │ │ │ │ │ │ │\n └─────────┼─────────┼─────┼─────┼─────────┼─────────┘\n │ │ │ │ │\n ┌────┴─────────┴─────┼─────┼─────────┴────────┐\n │ │ │ │\n ▼ ▼ ▼ ▼\n ┌─────────┐ ┌──────────────┐ ┌─────────┐\n │planning │←─────────│ identity │─────────→│ quota │\n │(计划) │ │ (用户身份) │ │ (额度) │\n └─────────┘ └──────────────┘ └─────────┘\n```\n 185|\n### 4.2 依赖矩阵\n 187|\n| ↓ 消费者 \\ 提供者 → | identity | planning | quota | outreach | support | risk | review | creator | audit |\n| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|\n| **identity** | - | - | - | - | - | R | - | - | E |\n| **planning** | **R** | - | R | - | - | R | R | - | E |\n| **quota** | **R** | - | - | - | - | - | R | - | E |\n| **outreach** | R | R | R | - | - | R | - | - | E |\n| **support** | R | - | - | - | - | R | - | - | E |\n| **risk** | R | - | - | - | - | - | - | - | E |\n| **review** | R | R | - | - | - | - | - | R | E |\n| **creator** | - | R | R | - | - | - | - | - | E |\n| **audit** | - | - | - | - | - | - | - | - | - |\n 199|\n**图例：** `R` = 只读依赖（通过 API 查询），`E` = 事件发送（fire-and-forget），`-` = 无依赖\n 201|\n### 4.3 启动依赖（必须就绪才能工作）\n 203|\n| 子系统 | 启动依赖 | 说明 |\n| --- | --- | --- |\n| identity | 无硬依赖 | 可独立启动（需要 JOYHUB 数据同步） |\n| planning | identity（软依赖） | 无 identity 时可先操作，但无法做人群匹配 |\n| quota | identity（软依赖） | 额度按真实人计算，未归并时按单一账号 |\n| outreach | identity, planning, quota（软依赖） | 无依赖时可先建渠道基础设施 |\n| support | identity（软依赖） | 无用户上下文卡时可先跑工单 |\n| risk | identity（软依赖） | 强/弱关联依赖身份数据 |\n| review | identity, planning（软依赖） | 评价需关联计划和用户 |\n| creator | planning（软依赖） | 免评计划入口 |\n| audit | 无硬依赖 | 完全独立 |\n 215|\n> **软依赖** = 可降级运行，核心功能不受阻。例如 outreach 在 identity 不可用时仍可发送消息，但缺少用户上下文。\n 217|\n---\n 219|\n## 5. 角色 → 独立前端映射\n 221|\n### 5.1 前端应用矩阵\n 223|\n| 前端应用 | 目标角色 | 集成的子系统 | 部署形态 |\n| --- | --- | --- | --- |\n| **运营工作台** | Amazon 运营、Amazon 运营总监 | planning + review + quota (查询) | Web SPA |\n| **用户运营中心** | 用户运营、用户运营负责人/组长 | planning + outreach + quota + review | Web SPA |\n| **客服工作台** | 菲律宾客服组员 | support + identity (上下文卡) + outreach (TEL) | Web SPA / 桌面端 |\n| **客服管理台** | 菲律宾客服负责人、客服组长 | support (管理模块) + audit | Web SPA |\n| **风险控制台** | 风险/黑名单相关人员 | risk + identity (上下文卡) + audit | Web SPA |\n| **达人协作台** | KOC/KOL 运营 | creator + outreach (协同) + review (免评结果) | Web SPA |\n| **管理驾驶舱** | 运营总监、用户运营负责人 | 跨子系统聚合看板 (planning + outreach + support + review) | Web SPA |\n 233|\n### 5.2 角色-功能矩阵\n 235|\n| 功能 \\ 角色 | Amazon运营 | 运营总监 | 用户运营 | 用户负责人 | 客服组员 | 客服组长 | 客服负责人 | 风险人员 | KOC运营 |\n| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|\n| 提需求（推新/回评/免评） | ✓ | ✓ | - | - | - | - | - | - | - |\n| 审批计划 | - | ✓ | - | ✓ | - | - | - | - | - |\n| 评估需求 | - | - | ✓ | ✓ | - | - | - | - | - |\n| 生成计划/调资源 | - | - | ✓ | ✓ | - | - | - | - | - |\n| 查看 ASIN 健康 | ✓ | ✓ | ✓ | - | - | - | - | - | - |\n| 处理工单 | - | - | - | - | ✓ | ✓ | - | - | - |\n| 分配工单 | - | - | - | - | - | ✓ | ✓ | - | - |\n| 电话外呼/接听 | - | - | - | - | ✓ | - | - | - | - |\n| 查看排班出勤 | - | - | - | - | - | ✓ | ✓ | - | - |\n| 绩效统计 | - | - | - | - | - | ✓ | ✓ | - | - |\n| 风险审核 | - | - | - | - | - | - | - | ✓ | - |\n| 黑名单管理 | - | - | - | - | - | - | - | ✓ | - |\n| KOC/KOL 匹配 | - | - | - | - | - | - | - | - | ✓ |\n| 内容跟踪 | - | - | ✓ | - | - | - | - | - | ✓ |\n 252|\n---\n 254|\n## 6. 子系统内外边界明细\n 256|\n### 6.1 identity — 用户身份与上下文\n 258|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 管理真实人归并逻辑、身份线索关联（JOYHUB ID↔邮箱↔电话↔设备↔订单→真实人ID）、用户上下文卡聚合与快照、设备变化识别 |\n| **对外（提供给其他子系统）** | `GET /api/identity/person/{context}` — 按线索查真实人；`GET /api/identity/context/{person_id}` — 用户上下文卡；`POST /api/identity/merge` — 归并请求 |\n| **依赖外部系统** | JOYHUB（用户基础数据）、APP（设备数据） |\n| **待确认边界** | 真实人归并是自动还是人工确认？归并拆分（合并错了如何回退）？非 APP 用户的身份线索从哪里同步（ESM 的邮箱清洗？） |\n 265|\n### 6.2 planning — 需求与计划管理\n 267|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 需求触发（人工提交 + 自动触发规则）、需求评估、计划创建（推新/回评/免评）、审批工作流、ASIN 基础信息管理 |\n| **对外（提供给其他子系统）** | `GET /api/plans/{id}` — 计划详情；`GET /api/plans?status=approved` — 待执行计划；`POST /api/demands` — 创建需求 |\n| **依赖外部系统** | Amazon（ASIN 数据、销售数据、评价缺口） |\n 273|\n### 6.3 quota — 额度与频控\n 275|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 额度台账（测评4/免评4/累计12）、额度预占与释放、频控规则引擎、发送前终校 |\n| **对外（提供给其他子系统）** | `GET /api/quota/check/{person_id}?type=测评` — 额度查询+预占；`POST /api/quota/reserve` — 预占；`POST /api/quota/commit` — 确认占用 |\n| **依赖外部系统** | 无直接外部系统依赖 |\n| **待确认边界** | 额度预占有效期多长？跨月额度如何处理（月末最后一天预占，下月一号释放还是保留？） |\n 282|\n### 6.4 outreach — 多渠道触达引擎\n 284|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 渠道路由决策、渠道去重、IM 推送（分层 A/B/C）、EDM 发送与行为追踪、APP Push、TEL 任务生成 |\n| **对外（提供给其他子系统）** | `POST /api/outreach/send` — 发送触达；`GET /api/outreach/history/{person_id}` — 触达历史 |\n| **依赖外部系统** | JOYHUB（IM 通道）、ESP（EDM）、FCM/APNs（APP Push）、电话系统（TEL） |\n| **待确认边界** | IM 具体是什么平台（WhatsApp/自研 IM）？EDM 模板管理在 outreach 内还是独立内容管理？APP Push 是否复用 JOYHUB 现有 Push 通道？ |\n 291|\n### 6.5 support — 客服工单与管理\n 293|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 工单生命周期、自动分配（按排班/在线/负载）、答应配合状态机、出勤/排班/绩效 |\n| **对外（提供给其他子系统）** | `POST /api/tickets` — 创建工单；`GET /api/tickets/{id}` — 工单详情；`GET /api/support/stats` — 绩效数据 |\n| **依赖外部系统** | 无直接外部系统依赖（电话记录来自 outreach TEL 模块） |\n| **待确认边界** | 客服是否使用独立 IM 工具还是复用 outreach 的 IM 通道？排班数据是否与现有 HR 系统对接？ |\n 300|\n### 6.6 risk — 风险与反欺诈\n 302|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 强弱关联判断、黑名单实体管理、风险事件管理、双重退款检测（Amazon退款 vs OA返款） |\n| **对外（提供给其他子系统）** | `GET /api/risk/check/{person_id}` — 风险查询；`POST /api/risk/report` — 上报风险信号 |\n| **依赖外部系统** | Amazon（退款数据）、财务系统（OA 返款数据） |\n 308|\n### 6.7 review — 评价结果追踪\n 310|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 用户真实提交评价记录、Amazon 展示核验、ASIN 健康更新回流、计划完成度计算 |\n| **对外（提供给其他子系统）** | `POST /api/reviews/submission` — 记录提交；`GET /api/reviews/status/{plan_id}` — 计划评价进度 |\n| **依赖外部系统** | Amazon（评价展示状态、ASIN 评分数据） |\n 316|\n### 6.8 creator — KOC/KOL 协作\n 318|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | KOC/KOL 匹配筛选、内容 Brief/Code 分配、内容发布跟踪、带货结果跟踪 |\n| **对外（提供给其他子系统）** | `GET /api/creators/match?plan_id=` — 匹配推荐；`POST /api/creators/tasks` — 创建协作任务 |\n| **依赖外部系统** | JOYCOLLAB（KOC/KOL 数据、内容数据、Code 使用、带货订单） |\n 324|\n### 6.9 audit — 审计与通知中心\n 326|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 所有子系统的状态变更审计、敏感字段访问日志、多类型通知（额度预警/超时提醒/紧急 Listing 告警/审批通知） |\n| **对外（提供给其他子系统）** | `POST /api/audit/event` — 上报审计事件；`POST /api/notifications/send` — 发送通知 |\n| **依赖外部系统** | 通知可能通过 IM/EDM/APP Push 等通道（可复用 outreach 通道或独立） |\n| **待确认边界** | 审计日志保留策略？通知模板管理在 audit 内还是需要独立内容管理？ |\n 333|\n---\n 335|\n## 7. 总系统级业务澄清问题清单\n 337|\n> 以下问题需要与业务方确认，涉及跨子系统边界、关键业务规则和外部系统对接。\n 339|\n### 7.1 外部系统对接（8 项）\n 341|\n| # | 问题 | 涉及外部系统 | 优先级 |\n| --- | --- | --- | --- |\n| Q-E1 | Amazon 数据以什么方式接入？（MWS/SP-API 授权拉取、爬虫、CSV 导入、已有中间表？） | Amazon | **P0** |\n| Q-E2 | JOYHUB 现有数据有哪些可用？是否有现成 API？JOYHUB ID ↔ 邮箱 ↔ 设备 ↔ 订单 的关联数据是否已存储？ | JOYHUB | **P0** |\n| Q-E3 | JOYCOLLAB 数据同步方向是单向（COLLAB→USER）还是双向？同步频率？Code 生成是在 COLLAB 还是 USER？ | JOYCOLLAB | **P0** |\n| Q-E4 | 当前 EDM 使用什么邮件服务？（SendGrid / Mailchimp / SES / 自建？）是否有现成的送达/打开/点击追踪？ | ESP | **P0** |\n| Q-E5 | OA 返款系统是哪个？是否有 API 可以查询返款状态和返款记录？（用于双重退款比对） | 财务系统 | **P0** |\n| Q-E6 | APP Push 是否复用 JOYHUB 现有 Push 通道还是需要独立接入 FCM/APNs？ | APP Push | P1 |\n| Q-E7 | 电话系统用什么方案？（自建 SIP / 第三方云呼叫中心？）是否已有通话记录存储？ | 电话系统 | P1 |\n| Q-E8 | IM 平台具体是什么？（WhatsApp Business API / 自研 IM / Facebook Messenger？） | IM 平台 | P1 |\n 352|\n### 7.2 用户身份体系（5 项）\n 354|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-I1 | 「真实人」归并是完全自动还是需要人工确认？自动归并错误时如何拆分？（拆分会影响到已关联的历史评价和额度） | **P0** |\n| Q-I2 | 非 APP 用户（只知道邮箱）如何建立真实人？没有设备号仅凭邮箱+收件地址归并，置信度阈值如何定？ | **P0** |\n| Q-I3 | JOYHUB ID 与真实人是 1:1 还是 N:1？（一个真实人可能拥有多个 JOYHUB ID） | P1 |\n| Q-I4 | 设备变化的「换机」判定标准是什么？（同一 JOYHUB ID 下设备号变化？多久内变化算换机？） | P1 |\n| Q-I5 | 用户上下文卡的「快照」是否需要保留历史版本？（每次互动生成新快照 vs 覆盖上次） | P2 |\n 362|\n### 7.3 额度与频控规则（6 项）\n 364|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-Q1 | 月度额度按自然月还是按 30 天滚动？如果是自然月，预占在月末最后一天是否需要特殊处理？ | **P0** |\n| Q-Q2 | 「测评 4 次」的「次」定义：是指参与 4 个不同的测评计划，还是提交 4 次评价？（如果一次计划要求用户提交多条评价怎么算） | **P0** |\n| Q-Q3 | 「累计 12 个评价」是永久上限还是可以重置？（例如用户长期优质，是否可以放宽？） | P1 |\n| Q-Q4 | 额度预占的有效期多长？如果预占后用户始终未响应，多久释放额度？ | P1 |\n| Q-Q5 | 频控规则中的「渠道频控」具体阈值是多少？（IM 每日最多推几次？EDM 每周最多几封？） | P1 |\n| Q-Q6 | 「接近上限时提前预警」——预警阈值是还剩 1 次还是还剩 N%？ | P2 |\n 373|\n### 7.4 计划与审批流程（5 项）\n 375|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-P1 | 自动触发需求的条件是什么？（ASIN 评分低于多少？评价缺口多少条？Listing 健康到什么程度？） | **P0** |\n| Q-P2 | 审批链中的「指定负责人」如何确定？（系统自动按规则还是人工指定？规则是什么？） | **P0** |\n| Q-P3 | 计划审批后是否可以修改？修改是否需要重新审批？ | P1 |\n| Q-P4 | 计划之间是否有互斥关系？（同一个 ASIN 同时跑推新和回评计划是否可以？） | P1 |\n| Q-P5 | 「紧急计划」的判定标准和特殊审批流程？（谁可以标记为紧急？是否跳过某些审批节点？） | P1 |\n 383|\n### 7.5 渠道协同与去重（5 项）\n 385|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-C1 | 渠道优先级路由规则是否需要可配置？（例如针对某类用户调整 IM > EDM 的优先级） | **P0** |\n| Q-C2 | 用户已在客服工单中时「暂停自动触达」——是所有渠道暂停还是仅暂停与当前工单相关的渠道？ | P1 |\n| Q-C3 | EDM 引导注册 APP 后，如何识别「该 EDM 邮箱对应该 APP 用户」？靠什么字段关联？ | P1 |\n| Q-C4 | 渠道去重中「同一计划同一用户不重复通过多渠道路由」——如果高优先级渠道发送失败（退信/未送达），是否自动降级到下一渠道？ | P1 |\n| Q-C5 | IM 推送中的「催评卡片」和 APP Push 中的「催评推送」如何协调？（两者会不会同时推送给同一用户？） | P1 |\n 393|\n### 7.6 客服与工单（5 项）\n 395|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-S1 | 工单自动分配算法——「当前负载」如何计算？（按未关闭工单数？按最近 N 小时处理量？） | **P0** |\n| Q-S2 | 客服的「在线状态」如何获取？（手动切换在线/离线，还是自动检测活跃度？） | P1 |\n| Q-S3 | 「答应配合」的超时判定——答应后多少天未提交算超时？超时后提醒频率？ | P1 |\n| Q-S4 | 出勤排班是否与本系统内的排班模块管理还是对接外部 HR 系统？ | P1 |\n| Q-S5 | 客服转化统计中的 RSO（回评）和 RDO（测评）如何区分？（按工单来源？按最终结果？） | P2 |\n 403|\n### 7.7 风险与反欺诈（4 项）\n 405|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-R1 | 「强关联」中哪些维度的命中可以直接自动化拦截，哪些需要人工复核？（文档说一旦命中直接进入高风险，但实际执行中是否所有强关联都自动拦截？） | **P0** |\n| Q-R2 | 双重退款检测——Amazon 退款数据如何及时获取？（T+1 同步？实时 Webhook？手动导入？） | **P0** |\n| Q-R3 | 黑名单是否有过期/申诉/解除机制？什么条件下可以从黑名单中移除？ | P1 |\n| Q-R4 | 风险信号的「弱关联」观察期多长？观察期过后是自动解除还是人工确认？ | P1 |\n 412|\n### 7.8 评价结果与回流（4 项）\n 414|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-V1 | Amazon 评价展示的核验方式是什么？（定时爬取 Amazon 页面？手动录入？用户上传截图？API？） | **P0** |\n| Q-V2 | 「Amazon 未展示 / 暂不可核验」的评价进入异常观察队列后，观察多久？复查频率？ | P1 |\n| Q-V3 | ASIN 健康「回流」的具体含义是什么？（更新 ASIN 评分/评价数到 planning 子系统，触发新一轮需求？） | P1 |\n| Q-V4 | 一个用户可能为多个 ASIN 提交评价——这些评价是否都计入同一个计划的完成度？ | P1 |\n 421|\n### 7.9 KOC/KOL 协作（4 项）\n 423|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-K1 | JOYCOLLAB 中 KOC/KOL 数据字段有哪些？（粉丝量、平台、国家、历史效果——文档提到但需确认完整字段） | **P0** |\n| Q-K2 | 「匹配 KOC/KOL」是运营人工选择还是系统自动推荐？推荐算法依赖什么数据？ | P1 |\n| Q-K3 | Code 是 JOYCOLLAB 生成还是 USER 系统生成？是一对一（每个 KOC 独立 Code）还是一对多？ | P1 |\n| Q-K4 | KOC/KOL 的财务结算（提成/返点）是完全在财务系统还是在 USER 系统内触发？ | P1 |\n 430|\n### 7.10 数据迁移与历史兼容（3 项）\n 432|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-D1 | 现有 USER 后台 ERP 系统（`C:\\XCODE\\USER`）是否完全废弃还是部分模块保留？新旧系统切换策略？ | **P0** |\n| Q-D2 | 历史数据（已有评价记录、用户数据、工单记录）是否需要迁移到新系统？迁移范围和清洗策略？ | **P0** |\n| Q-D3 | 旧系统中存在的用户额度数据如何初始化？（历史测评次数、免评次数、累计评价数如何确定？） | **P0** |\n 438|\n### 7.11 项目分期与 MVP 范围（5 项）\n 440|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-M1 | 项目一期（MVP）的最小范围是什么？9 个子系统中哪些是必须的、哪些可以二期再做？ | **P0** |\n| Q-M2 | MVP 先支持哪个 Amazon 站点？（.com？还是多站点？）先支持哪种计划类型？（推新/回评/免评全部 or 先做回评？） | **P0** |\n| Q-M3 | 前端应用的优先级——7 个前端中哪些是 MVP 必须有？（客服工作台+运营工作台？还是全部都要？） | **P0** |\n| Q-M4 | 项目整体时间线和里程碑约束？（6 个月？1 年？是否有硬性 deadline？） | P1 |\n| Q-M5 | 开发团队规模和结构？（几个后端开发？几个前端？是否有专职 QA？）是否支持 9 个子系统并行开发？ | P1 |\n 448|\n### 7.12 基础设施与部署（6 项）\n 450|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-IN1 | 部署环境？（云厂商 AWS/阿里云？自建机房？）是否已有 Kubernetes 集群或考虑容器化部署？ | **P0** |\n| Q-IN2 | 数据库选型？（PostgreSQL / MySQL？）每子系统独立数据库还是共享数据库？是否已有数据库团队和规范？ | **P0** |\n| Q-IN3 | 子系统间异步通信方案？（消息队列：Kafka/RabbitMQ/Redis？还是全部同步 HTTP？） | **P0** |\n| Q-IN4 | API 网关选型？（Kong/Nginx/自研？）认证鉴权方案？（JWT/OAuth2/SSO？） | P1 |\n| Q-IN5 | 日志、监控、链路追踪方案？（ELK/Prometheus+Grafana/Jaeger？）是否已有公司级基础设施可复用？ | P1 |\n| Q-IN6 | 灾备和容灾要求？（RPO/RTO 目标？是否需要多可用区/异地容灾？数据备份频率？） | P2 |\n 459|\n### 7.13 安全与合规（5 项）\n 461|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-SC1 | 是否有需要通过的安全合规认证？（SOC2 / ISO 27001 / 等保？）对系统架构有何约束？ | P1 |\n| Q-SC2 | 用户个人数据（邮箱、电话、地址、设备号）的保留和删除策略？（GDPR 的「被遗忘权」如何处理？） | P1 |\n| Q-SC3 | Amazon 的 API 使用条款（SP-API Acceptable Use Policy）对数据存储和使用的限制？（评价数据是否可以长期存储？） | P1 |\n| Q-SC4 | 系统权限模型？（RBAC？角色和权限的粒度？是否需要支持数据行级权限——例如不同站点的运营只看自己的 ASIN？） | P1 |\n| Q-SC5 | 敏感数据（收款信息、设备号）的加密存储方案？传输加密（TLS）要求？ | P2 |\n 469|\n### 7.14 技术栈与规范（4 项）\n 471|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-TS1 | 后端技术栈偏好？（Python/FastAPI？Go？Node.js？Java？）是否有公司技术栈约束？ | P1 |\n| Q-TS2 | 前端技术栈偏好？（React/Vue/Angular？）是否有公司前端组件库或设计系统可复用？ | P1 |\n| Q-TS3 | API 规范标准？（OpenAPI 3.0？gRPC？）是否需要 BFF（Backend for Frontend）层？ | P2 |\n| Q-TS4 | 代码仓库策略？（Monorepo or Polyrepo？9 个子系统分仓库还是一仓库？CI/CD 工具？） | P2 |\n 478|\n### 7.15 多站点与多市场（4 项）\n 480|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-MS1 | 系统需要支持多少个 Amazon 站点？（.com / .co.uk / .de / .fr / .it / .es / .jp / .ca？）不同站点的业务流程是否一致？ | **P0** |\n| Q-MS2 | 多站点下「真实人」归并是否跨站点？（同一个真实人在 .com 和 .co.uk 用不同邮箱/账号——是否归并为同一人？） | P1 |\n| Q-MS3 | 额度规则是否跨站点？（测评 4 次是每个站点独立还是全局？累计 12 个评价呢？） | P1 |\n| Q-MS4 | 未来是否扩展到 Amazon 以外的平台（eBay/Walmart/独立站）？架构上需要预留扩展点吗？ | P2 |\n 487|\n### 7.16 内容与素材管理（3 项）\n 489|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-CM1 | EDM 模板、IM 推送话术、APP Push 文案的创建和维护由谁负责？（内容运营？用户运营？）是否需要独立的内容管理子系统？ | P1 |\n| Q-CM2 | 多语言内容策略？（面向美国用户的英文消息、面向德国用户的德语消息——模板由谁翻译和维护？系统是否需要自动翻译？） | P1 |\n| Q-CM3 | 图片/视频素材（产品图片、测评指引图）的存储和管理？是否需要 CDN？ | P2 |\n 495|\n### 7.17 业务量级预估（4 项）\n 497|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-BV1 | 系统需要管理的 ASIN 数量级？（几十个？几百个？几千个？） | P1 |\n| Q-BV2 | 日活跃用户数（APP 端）？日触达消息量（IM+EDM+APP Push+TEL）？ | P1 |\n| Q-BV3 | 客服团队规模？（几个组？每组多少人？峰值工单量？） | P1 |\n| Q-BV4 | 峰值场景预估？（Prime Day / Black Friday 期间流量和触达量是平时的几倍？） | P2 |\n 504|\n### 7.18 外部系统对接细节（4 项）\n 506|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-EX1 | 各外部系统的 SLA 和可用性？（Amazon SP-API 的 rate limit？JOYHUB 的响应时间？）当外部系统不可用时的降级策略？ | P1 |\n| Q-EX2 | 外部系统的认证方式？（Amazon SP-API 的 OAuth 授权流程？JOYHUB 的 API Key？）谁负责管理这些凭证？ | P1 |\n| Q-EX3 | 数据同步的增量 or 全量策略？（Amazon 订单是增量拉取最近 N 天还是全量同步？JOYHUB 用户数据呢？） | P1 |\n| Q-EX4 | 外部系统数据格式和字段映射是否已有文档？（Amazon 订单字段→系统内部字段的映射关系？） | P2 |\n 513|\n---\n 515|\n## 8. 待确认的内外边界\n 517|\n> 以下边界由于文档信息不足，标记为「待确认」，需要在后续与业务方或技术团队确认。\n 519|\n| # | 边界问题 | 影响范围 | 建议确认方式 |\n| --- | --- | --- | --- |\n| B1 | **内容/素材管理归属**：EDM 模板、IM 推送话术、APP Push 文案由哪个子系统管理？是 outreach 内的内容模块，还是独立的内容管理子系统？ | outreach | 与内容运营角色确认工作流 |\n| B2 | **品牌/内容运营角色**：文档提到品牌运营和内容运营但目前不展开。他们是否需要独立前端？需求何时明确？ | planning / creator | 与业务方确认是否一期纳入 |\n| B3 | **数据仓库/BI 边界**：文档明确「完整 BI/财务/ROI 系统」不在本版主流程，但管理驾驶舱涉及聚合看板。看板数据是子系统直接提供聚合 API 还是走独立数据仓库？ | 全部 | 与数据团队确认数据架构 |\n| B4 | **外部系统降级策略**：Amazon API 不可用时，哪些功能可以降级运行？JOYHUB 不可用时用户身份如何兜底？ | identity / planning / review | 制定 SLA 和降级方案 |\n| B5 | **多语言支持**：系统前端是否只面向菲律宾客服（英文？）还是国内团队也使用（中文？） | 所有前端 | 确认各前端的语言需求 |\n| B6 | **定时任务归属**：自动需求触发、EDM 批处理、超时检测、评价核验等定时任务在各子系统内实现还是有统一调度器？ | 多个子系统 | 确认是否引入统一任务调度 |\n 528|\n---\n 530|\n## 9. 附录：子系统文档索引\n 532|\n| 文档 | 描述 |\n| --- | --- |\n| [01-子系统-用户身份与上下文](01-子系统-用户身份与上下文.md) | 真实人归并、用户上下文卡、设备识别 |\n| [02-子系统-需求与计划管理](02-子系统-需求与计划管理.md) | 需求触发、计划生命周期、审批工作流 |\n| [03-子系统-额度与频控](03-子系统-额度与频控.md) | 额度台账、频控引擎、预占释放 |\n| [04-子系统-多渠道触达引擎](04-子系统-多渠道触达引擎.md) | IM/EDM/APP/TEL 调度与执行 |\n| [05-子系统-客服工单与管理](05-子系统-客服工单与管理.md) | 工单管理、客服管理支撑 |\n| [06-子系统-风险与反欺诈](06-子系统-风险与反欺诈.md) | 风险判断、黑名单、双重退款 |\n| [07-子系统-评价结果追踪](07-子系统-评价结果追踪.md) | 评价提交、展示核验、结果回流 |\n| [08-子系统-KOC-KOL协作](08-子系统-KOC-KOL协作.md) | KOC/KOL 匹配、内容跟踪、JOYCOLLAB 同步 |\n| [09-子系统-审计与通知中心](09-子系统-审计与通知中心.md) | 审计日志、多类型通知告警 |\n 544|", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/01-子系统-用户身份与上下文", "type": "document", "name": "子系统 01 — 用户身份与上下文 (`identity`) v1.0", "filePath": "05_需求文档/01-子系统-用户身份与上下文.md", "summary": "子系统 01 — 用户身份与上下文 identity v1.0 子系统概述 维度 说明 代号 identity 核心职责 真实人识别与归并、身份线索关联、用户上下文卡生成 数据所有权 person profiles , person identity links , contact context snapshots , device records 启动依", "tags": [ "05_需求文档", "需求文档" ], "complexity": "moderate", "knowledgeMeta": { "content": "# 子系统 01 — 用户身份与上下文 (`identity`) v1.0\n\n## 子系统概述\n\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `identity` |\n| 核心职责 | 真实人识别与归并、身份线索关联、用户上下文卡生成 |\n| 数据所有权 | `person_profiles`, `person_identity_links`, `contact_context_snapshots`, `device_records` |\n| 启动依赖 | 无硬依赖（需 JOYHUB 数据同步到位） |\n| 外部系统依赖 | JOYHUB（用户数据）、APP（设备数据） |\n\n---\n\n## 1. 模块划分\n\n### 整体模块图\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│ identity 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 身份线索 │ │ M2: 真实人 │ │ M3: 用户上下 │ │\n│ │ 采集与同步 │→│ 归并引擎 │→│ 文卡服务 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 设备变化 │ │ M5: 身份管理 │ │ M6: 对外 API │ │\n│ │ 识别 │ │ Admin │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n\n### 模块明细\n\n| # | 模块 | 代号 | 职责 |\n| --- | --- | --- | --- |\n| M1 | 身份线索采集与同步 | `identity-ingest` | 从 JOYHUB、APP 等外部系统拉取/接收身份线索（JOYHUB ID、邮箱、电话、设备号、订单关联） |\n| M2 | 真实人归并引擎 | `person-merge` | 按标准姓名+地址、多线索交叉权重归并，生成/更新真实人 ID |\n| M3 | 用户上下文卡服务 | `context-card` | 聚合身份+交易+服务+风险+设备+触达全量数据生成上下文快照 |\n| M4 | 设备变化识别 | `device-tracker` | 识别设备号变化、换机、多设备场景，记录设备变化日志 |\n| M5 | 身份管理 Admin | `identity-admin` | 人工归并/拆分操作、归并冲突处理、身份数据校正 |\n| M6 | 对外 API Gateway | `identity-api` | 向其他子系统提供真实人查询、上下文卡查询、归并请求等 API |\n\n---\n\n## 2. 各模块内外说明\n\n### 2.1 M1: 身份线索采集与同步\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 管理外部系统的数据同步任务（定时拉取 JOYHUB 用户数据、设备数据）；解析和标准化各来源的身份线索（邮箱规范化、电话格式化、地址标准化）；写入 `person_identity_links` 表 |\n| **对外接口** | `POST /internal/identity/ingest — 接收上游推送的身份线索`；同步调度器可配置频率 |\n| **数据写入** | `person_identity_links`（线索类型 + 线索值 + 来源系统 + 采集时间） |\n\n### 2.2 M2: 真实人归并引擎\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 执行归并规则：标准姓名+地址一致→同一真实人；多线索交叉（设备+电话+邮箱+收款信息）按权重打分；地址一致姓名不同→标记家庭关联但不合并；生成真实人 ID、归并证据、置信度 |\n| **对外接口** | `POST /api/identity/merge — 触发归并`；返回归并结果（真实人 ID + 置信度） |\n| **数据写入** | `person_profiles`（真实人创建/更新）、`person_identity_links`（关联关系更新） |\n| **关键规则** | 邮箱不同+JOYHUB ID 不同不能单独否定「同一真实人」；订单号命中历史异常需拉出风险记录 |\n\n### 2.3 M3: 用户上下文卡服务\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 聚合 6 组字段（当前身份、真实人归并、历史交易、历史服务、历史风险、当前设备、触达历史）；生成上下文快照（含快照时间）；首次生成 vs 增量更新 |\n| **对外接口** | `GET /api/identity/context/{person_id} — 获取用户上下文卡`；返回聚合后的全量上下文 |\n| **数据写入** | `contact_context_snapshots` |\n| **依赖其他子系统** | 交易数据来自 planning；服务数据来自 support；风险数据来自 risk；触达数据来自 outreach（通过 API 聚合或事件） |\n\n### 2.4 M4: 设备变化识别\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 监控同一 JOYHUB ID 下设备号变化；记录换机/多设备事件；关联设备型号、系统版本、APP 版本变化 |\n| **对外接口** | 内部事件 `device.changed` 供其他模块消费 |\n| **数据写入** | `device_records`（设备变化时间、变化类型） |\n| **待确认** | 多久内的设备变化算「近期换机」？多设备同时活跃如何标记？ |\n\n### 2.5 M5: 身份管理 Admin\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 提供人工归并操作界面（两个真实人合并为一个）；归并拆分（合并错了如何回退）；冲突处理（系统自动归并 vs 人工判定不一致时） |\n| **对外接口** | 管理 API（不对其他子系统暴露） |\n| **数据写入** | 所有身份相关表（权限控制） |\n\n### 2.6 M6: 对外 API Gateway\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 统一对外 API 认证、限流、日志 |\n| **对外接口** | `GET /api/identity/person?线索类型=&线索值=` — 按线索查真实人；`GET /api/identity/context/{person_id}` — 用户上下文卡；`POST /api/identity/batch-check` — 批量身份查询 |\n\n---\n\n## 3. 对外 API 契约（草案）\n\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 按线索查真实人 | `GET /api/identity/person` | `?type=email&value=xxx@yy.com` 或 `?type=joyhub_id&value=123` | `{person_id, confidence, matched_clues[]}` | 所有子系统 |\n| 获取用户上下文卡 | `GET /api/identity/context/{person_id}` | `person_id` | `{identity, transactions, services, risks, devices, outreach_history}` | support, risk, outreach |\n| 批量身份查询 | `POST /api/identity/batch-check` | `[{type, value}, ...]` | `[{person_id, confidence}, ...]` | planning, outreach |\n| 触发归并 | `POST /api/identity/merge` | `{clues: [{type, value}, ...]}` | `{person_id, is_new, confidence}` | outreach（每次互动时调用） |\n\n---\n\n## 4. 数据对象（本子系统写入）\n\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `person_profiles` | person_id, status, created_at, updated_at, merge_evidence | 真实人主表 |\n| `person_identity_links` | person_id, clue_type (JOYHUB_ID/EMAIL/PHONE/DEVICE/ORDER_NAME_ADDRESS), clue_value, source, confidence, linked_at | 身份线索关联表 |\n| `contact_context_snapshots` | person_id, snapshot_time, identity_snapshot, transaction_snapshot, service_snapshot, risk_snapshot, device_snapshot, outreach_snapshot | 上下文快照 |\n| `device_records` | person_id, joyhub_id, device_id, device_model, os_version, app_version, change_type (NEW/SWITCH/MULTI), recorded_at | 设备变化记录 |\n\n---\n\n## 5. 业务澄清问题清单 — identity\n\n### 5.1 真实人归并规则（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-01 | 标准姓名+地址的「标准化」规则是什么？（大小写、空格、缩写如 St./Street、middle name 处理？）标准化在哪个模块做？ | **P0** |\n| I-02 | 归并是多线索交叉权重打分——各维度的权重如何设定？（邮箱=0.3、设备=0.4、电话=0.2、收款=0.5？由谁定义？可否动态调整？） | **P0** |\n| I-03 | 归并是完全自动执行还是部分需要人工审核？触发人工审核的条件是什么？（置信度 < 多少？涉及风险用户？） | **P0** |\n| I-04 | 自动归并错误后如何拆分？拆分时如何处理已关联的历史评价和额度数据？（评价归属、额度扣减是否回滚？） | **P0** |\n\n### 5.2 非 APP 用户处理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-05 | 非 APP 用户的邮箱从哪里来？（Amazon 订单中的买家邮箱？EDM 列表？客服录入？）邮箱质量/有效性如何保证？ | **P0** |\n| I-06 | 只有邮箱没有设备号的非 APP 用户，归并置信度是否单独设置较低阈值？这种情况下如何确定是同一真实人？ | P1 |\n| I-07 | EDM 引导用户注册 APP 后——如何识别「这个新 APP 用户就是之前那个 EDM 邮箱用户」？（注册时要求填同一邮箱？设备号关联？） | P1 |\n\n### 5.3 设备与多账号（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-08 | 「同设备多账号」的风险判断——同一个设备号关联了多个 JOYHUB ID，哪些情况正常（家庭共用）哪些算风险信号？ | P1 |\n| I-09 | 设备号变化的识别窗口——同一个 JOYHUB ID 下，设备号变化间隔多久内算「近期换机」？ | P1 |\n| I-10 | APP 卸载重装导致设备号变化怎么处理？（卸载重装可能生成新设备号） | P2 |\n\n### 5.4 用户上下文卡（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-11 | 上下文卡的「快照」保留几份？每次互动生成新快照（保留历史）还是覆盖（只保留最新一份）？保留历史的话保留多久？ | P1 |\n| I-12 | 上下文卡中的历史交易、历史服务等数据是从其他子系统实时拉取还是从本地冗余存储读取？（涉及跨子系统数据一致性） | P1 |\n| I-13 | 上下文卡是否需要在某个条件触发时预生成（如用户接入前），还是每次实时生成？ | P2 |\n\n### 5.5 数据同步（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-14 | JOYHUB 数据同步频率？（实时/每小时/每天？）同步方式？（API 拉取 / 消息队列 / 数据库直连？） | **P0** |\n| I-15 | JOYHUB 和 APP 端的数据字段完整清单是否已有？（注册邮箱、设备号、设备型号、APP 版本、系统版本、绑定玩具、活跃行为——文档已列出但需确认是否有遗漏） | **P0** |\n\n### 5.6 身份数据生命周期（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-16 | 用户数据保留策略——身份线索和历史快照保留多久？（6个月？1年？永久？）超出保留期后是归档还是删除？ | P1 |\n| I-17 | 用户注销/数据删除请求如何处理？（用户要求删除所有个人数据——如何标记而不是物理删除以保持额度/风险记录的完整性？） | P1 |\n| I-18 | 「被遗忘权」实操——删除真实人记录后，与之关联的额度、风险、评价如何处理？（匿名化保留？还是级联删除？） | P1 |\n| I-19 | 用户主动修改关键身份信息（换邮箱、换电话）——系统如何感知和响应？（自动触发重新归并？还是保持原关联？） | P1 |\n\n### 5.7 多站点与跨平台身份（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-20 | 同一个自然人在 Amazon.com 和 Amazon.co.uk 用不同邮箱和地址——是否跨站点归并为同一个「真实人」？ | P1 |\n| I-21 | 未来扩展到非 Amazon 平台（eBay/Walmart/独立站）——真实人体系是否需要跨平台？架构预留？ | P2 |\n| I-22 | 不同国家站点的地址标准化规则不同（US→州/邮编、UK→郡/邮编、DE→邮编/城市）——标准化引擎如何处理？ | P2 |\n\n### 5.8 归并冲突与人工干预（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-23 | 系统自动归并和人工判定冲突时，以谁为准？（人工优先？系统告警→人工确认？）冲突记录保留多久？ | P1 |\n| I-24 | 人工拆分归并的操作是否需要审批？（谁来审批？审批流程？）拆分的审计记录保留什么字段？ | P1 |\n| I-25 | 是否存在「不确定」状态的真实人？（置信度太低无法归并，标记为「待定」——如何流转到人工审核？） | P1 |\n\n### 5.9 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-26 | 身份归并是实时还是异步？（用户接入时实时归并→阻塞用户体验 vs 异步归并→可能用旧数据？） | P1 |\n| I-27 | 上下文卡聚合的性能要求——单次查询需要在多少 ms 内返回？（涉及跨子系统调用时的超时和降级） | P2 |\n| I-28 | 如果 JOYHUB 数据同步中断，identity 子系统如何降级？（用缓存数据？标记为「数据可能过期」？） | P1 |\n", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/02-子系统-需求与计划管理", "type": "document", "name": "子系统 02 — 需求与计划管理 (`planning`) v1.0", "filePath": "05_需求文档/02-子系统-需求与计划管理.md", "summary": "子系统 02 — 需求与计划管理 planning v1.0 子系统概述 维度 说明 代号 planning 核心职责 需求触发（人工/自动）、需求评估、计划生成（推新/回评/免评）、审批工作流、ASIN 基础信息管理 数据所有权 demands , plans , plan items , approval records , asin catalog 启", "tags": [ "05_需求文档", "需求文档" ], "complexity": "moderate", "knowledgeMeta": { "content": "# 子系统 02 — 需求与计划管理 (`planning`) v1.0\n\n## 子系统概述\n\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `planning` |\n| 核心职责 | 需求触发（人工/自动）、需求评估、计划生成（推新/回评/免评）、审批工作流、ASIN 基础信息管理 |\n| 数据所有权 | `demands`, `plans`, `plan_items`, `approval_records`, `asin_catalog` |\n| 启动依赖 | identity（软依赖，无 identity 可操作但无法做人群匹配） |\n| 外部系统依赖 | Amazon（ASIN 数据、销售数据、评价缺口） |\n\n---\n\n## 1. 模块划分\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│ planning 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 需求管理 │ │ M2: 计划引擎 │ │ M3: 审批工作 │ │\n│ │ (Demand) │→│ (Plan) │→│ 流 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 自动触发 │ │ M5: ASIN管理 │ │ M6: 对外 API │ │\n│ │ 规则引擎 │ │ │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n\n| # | 模块 | 代号 | 职责 |\n| --- | --- | --- | --- |\n| M1 | 需求管理 | `demand-mgr` | 需求创建、评估（成立/待补充/驳回）、优先级管理、需求与 ASIN 关联 |\n| M2 | 计划引擎 | `plan-engine` | 从已确认需求生成计划（推新/回评/免评）、计划生命周期管理、计划项拆解 |\n| M3 | 审批工作流 | `approval-workflow` | 计划审批链（Amazon 运营总监→用户负责人→渠道负责人）、审批记录 |\n| M4 | 自动触发规则引擎 | `auto-trigger` | 按 ASIN 健康度、评价缺口自动触发需求；定时评估触发条件 |\n| M5 | ASIN 管理 | `asin-catalog` | ASIN 基础信息、评分、评价数、Listing 健康状态维护 |\n| M6 | 对外 API Gateway | `planning-api` | 向其他子系统提供计划查询、ASIN 查询、审批状态查询 API |\n\n---\n\n## 2. 各模块内外说明\n\n### 2.1 M1: 需求管理\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | Amazon 运营人工提需求（选择 ASIN、指定类型：推新/回评/免评、目标数量、周期）；用户运营评估需求（查 ASIN 健康、目标数量、历史完成、当前资源）；评估结果：已确认/待补充/驳回 |\n| **对外接口** | `POST /api/demands` — 创建需求；`PUT /api/demands/{id}/evaluate` — 评估需求 |\n| **数据写入** | `demands` |\n| **依赖** | `GET /api/identity/person` — 评估时可能需要运营人员身份 |\n| **待确认** | 需求是否有优先级字段（P0/P1/P2）？驳回后是否允许重新提交？ |\n\n### 2.2 M2: 计划引擎\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 从已确认需求生成计划草案（类型：推新/回评/免评）；计划参数（目标 ASIN、目标数量、周期、预算、备注）；计划状态流转；计划项拆解（将计划拆成可分配给渠道的执行单元） |\n| **对外接口** | `POST /api/plans` — 创建计划；`PUT /api/plans/{id}/status` — 更新状态；`GET /api/plans/{id}/items` — 获取计划项 |\n| **数据写入** | `plans`, `plan_items` |\n| **依赖** | `GET /api/quota/check` — 生成人群前查询额度；`GET /api/risk/check` — 计划复核时查询风险 |\n| **待确认** | 计划是否可以包含多个 ASIN？推新和回评是否可以合并为一个计划？ |\n\n### 2.3 M3: 审批工作流\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 按计划类型路由不同审批链：（测评→Amazon运营总监 / 回评→总监或指定负责人 / 免评→总监+用户负责人 / 紧急→运营负责人+用户负责人+主管）；周/月推送计划审批（用户负责人→渠道负责人）；审批节点（通过/驳回/待补充） |\n| **对外接口** | `POST /api/approvals/{plan_id}/submit` — 提交审批；`PUT /api/approvals/{plan_id}/review` — 审批决策 |\n| **数据写入** | `approval_records` |\n| **依赖** | `GET /api/identity/person` — 获取审批人身份 |\n| **待确认** | 审批链是否可以动态配置（不同站点/国家不同审批人）？驳回后修改再提交是否需要重新走完整审批链？ |\n\n### 2.4 M4: 自动触发规则引擎\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 定时扫描 ASIN 健康状态（评分、评价数、差评比例）；当满足触发条件时自动创建需求（无需人工干预）；触发规则可配置 |\n| **对外接口** | 内部定时任务，不对外暴露 |\n| **数据写入** | `demands`（自动生成的需求） |\n| **依赖** | `GET /api/reviews/asin-health` 或本地 ASIN 数据 |\n| **待确认** | 自动触发后是否需要人工确认还是直接进入评估？自动触发的优先级如何设定？ |\n\n### 2.5 M5: ASIN 管理\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | ASIN 基础信息（ASIN 码、标题、品类、站点）；评分、评价总数、差评数；Listing 健康状态（活跃/风险/下架）；与计划的关联关系 |\n| **对外接口** | `GET /api/asins/{asin}` — ASIN 详情；`GET /api/asins?status=at_risk` — 需关注的 ASIN 列表 |\n| **数据写入** | `asin_catalog` |\n| **依赖** | Amazon 数据同步（外部系统） |\n| **待确认** | ASIN 数据是否已在 JOYHUB 或其他系统中维护？是否需要新建还是复用？ |\n\n### 2.6 M6: 对外 API Gateway\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 统一对外 API 认证、限流、日志 |\n| **对外接口** | `GET /api/plans?status=approved` — 待执行计划（outreach 消费）；`GET /api/plans/{id}` — 计划详情（review 消费）；`GET /api/asins/{asin}` — ASIN 查询 |\n\n---\n\n## 3. 对外 API 契约（草案）\n\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 创建需求 | `POST /api/demands` | `{asin, type, target_count, period, priority}` | `{demand_id, status}` | 运营前端 |\n| 评估需求 | `PUT /api/demands/{id}/evaluate` | `{decision, reason}` | `{status}` | 用户运营前端 |\n| 创建计划 | `POST /api/plans` | `{demand_id, type, params}` | `{plan_id}` | 用户运营前端 |\n| 待执行计划列表 | `GET /api/plans?status=approved` | 无 | `[{plan_id, type, items}]` | outreach |\n| 计划详情 | `GET /api/plans/{id}` | `plan_id` | 完整计划含审批记录 | review / outreach |\n| ASIN 查询 | `GET /api/asins/{asin}` | `asin` | ASIN 详情+健康状态 | 所有子系统 |\n\n---\n\n## 4. 数据对象\n\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `demands` | demand_id, asin, type (NEW/REVIEW/EXEMPTION), target_count, period, status (PENDING/EVALUATING/CONFIRMED/REJECTED/WAITING), priority, created_by, evaluated_by, created_at | 需求主表 |\n| `plans` | plan_id, demand_id, type, status (DRAFT/REVIEW/APPROVED/EXECUTING/COMPLETED/CANCELLED), target_count, period, created_at | 计划主表 |\n| `plan_items` | item_id, plan_id, asin, item_type, target_count, assigned_channel, status | 计划执行项 |\n| `approval_records` | approval_id, plan_id, approver, decision, comment, decided_at, step_order | 审批记录 |\n| `asin_catalog` | asin, title, category, marketplace, rating, review_count, negative_count, health_status, last_synced_at | ASIN 信息 |\n\n---\n\n## 5. 业务澄清问题清单 — planning\n\n### 5.1 需求与计划模型（5 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-01 | 一个需求是否可以生成多个计划？（例如一个回评需求拆分到 IM 计划和 EDM 计划）还是一对一？ | **P0** |\n| P-02 | 计划是否可以跨 ASIN？（一个推新计划覆盖 3 个新 ASIN）还是每个计划只针对一个 ASIN？ | **P0** |\n| P-03 | 计划中的「目标数量」是指目标评价数还是目标触达用户数？（如果转化率 2%，要得到 10 个评价需触达 500 人） | **P0** |\n| P-04 | 计划的「周期」是什么粒度？（周/月/自定义日期范围？）周期结束后未完成的计划如何处理？ | P1 |\n| P-05 | 需求是否有优先级？（P0/P1/P2 或高/中/低？）优先级影响什么？（审批速度？资源分配？） | P1 |\n\n### 5.2 审批流程（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-06 | 文档提到「免评计划 → Amazon 运营总监 + 用户负责人」审批——是两者都必须通过（会签）还是任一通过即可（或签）？ | **P0** |\n| P-07 | 「指定负责人」的指定规则是什么？（按 ASIN 品类？按站点？按当前负载？人工指定？） | P1 |\n| P-08 | 审批超时如何处理？（审批人 N 天未处理，自动通过？自动驳回？升级到上级？） | P1 |\n| P-09 | 审批驳回后修改再提交，审批链是否重置还是从当前节点继续？ | P1 |\n\n### 5.3 自动触发（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-10 | 自动触发的具体阈值是什么？（① ASIN 评分低于多少？② 差评在最近 N 天新增多少？③ 评价总数 < 目标值？） | **P0** |\n| P-11 | 自动触发是每天跑一次还是实时监控？（如果是实时，高频变化的 ASIN 会不会重复触发？） | P1 |\n| P-12 | 自动触发生成的需求是否自动进入评估环节还是需要人工确认后才进入？ | P2 |\n\n### 5.4 ASIN 管理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-13 | ASIN 数据来源和更新频率？（从 Amazon API 拉取？T+1？实时？手动导入？） | **P0** |\n| P-14 | ASIN 的「Listing 健康状态」如何定义？（评分 ≥ 4.2 = 健康？差评率 < X%？）健康度是否有多个等级？ | P1 |\n| P-15 | ASIN 是否有关联关系？（变体 ASIN、父 ASIN-子 ASIN）关联合并还是独立管理？ | P2 |\n\n### 5.5 计划执行衔接（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-16 | 计划审批通过后如何流转到 outreach 子系统？（planning 主动推送？outreach 定时拉取？事件通知？） | P1 |\n| P-17 | 计划执行过程中是否可以调整目标数量或周期？调整是否需要重新审批？ | P2 |\n\n### 5.6 计划模板与复用（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-18 | 是否需要计划模板功能？（对常推的 ASIN 创建可复用的计划模板——模板包含预设的渠道/目标数/周期？） | P1 |\n| P-19 | 周期性计划（如「每月 1 号自动对 ASIN X 发起回评计划」）是否支持？谁有权限创建？ | P2 |\n| P-20 | 计划是否可以暂停/恢复？（执行中因库存或供应链原因需暂停——暂停期间已触达的用户如何处理？） | P1 |\n\n### 5.7 预算与资源管理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-21 | 计划是否有预算字段？（返款金额、Code 成本、KOC 费用——是否需要预算审批？超出预算如何处理？） | P1 |\n| P-22 | 资源容量规划——同时可执行的计划数是否有上限？（受限于客服人力/EDM发送额度/IM频控？） | P1 |\n| P-23 | 是否需要计划执行成本的 ROI 计算？（返款总额 / 获得的评价数 = 单评价成本——系统自动计算还是手动录入？） | P2 |\n\n### 5.8 季节性/大促处理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-24 | Prime Day / Black Friday 等大促期间的计划是否有特殊处理？（提前锁定额度、加大推送量、豁免某些频控规则？） | P1 |\n| P-25 | 大促前的「预热计划」和大促后的「回评计划」是否需要在系统中作为计划间的依赖关系来管理？ | P2 |\n| P-26 | 季节性产品（圣诞装饰、夏季用品）的计划是否有时间敏感度标记？（错过季节窗口的计划自动降级？） | P2 |\n\n### 5.9 多站点/多市场（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-27 | 不同 Amazon 站点的计划是否可以统一管理？（同一个 ASIN 在不同站点是独立计划还是关联计划？） | P1 |\n| P-28 | 多站点的审批人是否不同？（.com 的运营总监和 .co.uk 的运营总监可能是不同人） | P1 |\n| P-29 | 跨站点需求的冲突检测？（.com 和 .de 同时对同一真实的同一用户做了不同计划——算不算冲突？） | P2 |\n\n### 5.10 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-30 | 自动触发生成的需求如果无人处理（评估超时），是否自动驳回还是升级通知？ | P1 |\n| P-31 | 审批工作流引擎——是否有现成的审批引擎可复用？（还是需要从零开发状态机？） | P2 |\n| P-32 | 计划执行过程中用户反馈「不想再收到」——是标记为退订（outreach 处理）还是需要回写到 planning 的计划状态中？ | P1 |\n", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/03-子系统-额度与频控", "type": "document", "name": "子系统 03 — 额度与频控 (`quota`) v1.0", "filePath": "05_需求文档/03-子系统-额度与频控.md", "summary": "子系统 03 — 额度与频控 quota v1.0 2 子系统概述 4 维度 说明 代号 quota 核心职责 额度台账（测评4/免评4/累计12）、额度预占与释放、频控规则引擎、发送前终校 数据所有权 person quota ledgers , quota reservations , frequency control records 启动依赖 ide", "tags": [ "05_需求文档", "需求文档" ], "complexity": "moderate", "knowledgeMeta": { "content": "# 子系统 03 — 额度与频控 (`quota`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `quota` |\n| 核心职责 | 额度台账（测评4/免评4/累计12）、额度预占与释放、频控规则引擎、发送前终校 |\n| 数据所有权 | `person_quota_ledgers`, `quota_reservations`, `frequency_control_records` |\n| 启动依赖 | identity（软依赖，额度按真实人计算，未归并时按单一账号） |\n| 外部系统依赖 | 无直接外部依赖 |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ quota 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 额度台账 │ │ M2: 预占管理 │ │ M3: 频控引擎 │ │\n│ │ (Ledger) │→│ (Reservation)│ │ (FreqCtrl) │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 终校服务 │ │ M5: 额度管理 │ │ M6: 对外 API │ │\n│ │ (FinalCheck)│ │ Admin │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 代号 | 职责 |\n| --- | --- | --- | --- |\n| M1 | 额度台账 | `quota-ledger` | 维护真实人三层额度（测评4/免评4/累计12）、已用/进行中/已预占计数 |\n| M2 | 预占管理 | `reservation-mgr` | 额度预占创建、确认占用、超时释放；跨计划重复入选检测 |\n| M3 | 频控引擎 | `freq-control` | 渠道频控（IM/EDM/APP/TEL 最近触达间隔）、单 ASIN 短期触达次数、退订/投诉屏蔽 |\n| M4 | 终校服务 | `final-check` | 发送前合并校验（最新额度 + 最新风险 + 最新未关闭工单），准入/撤出决策 |\n| M5 | 额度管理 Admin | `quota-admin` | 额度手动调整、额度重置、额度审计 |\n| M6 | 对外 API Gateway | `quota-api` | 供 planning（人群生成）、outreach（发送前校验）、review（提交后确认）调用 |\n 43|\n---\n 45|\n## 2. 各模块内外说明\n 47|\n### 2.1 M1: 额度台账\n 49|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 按真实人维护三种额度：月度测评（已完成+进行中+已预占）、月度免评（同上）、累计真实提交评价（永久累计）；额度计数时点明确（提交评价立即计数12、不会因 Amazon 未展示回退）；接近上限时预警 |\n| **对外接口** | `GET /api/quota/ledger/{person_id}` — 读取当前台账 |\n| **数据写入** | `person_quota_ledgers` |\n| **依赖** | `GET /api/identity/person` — 获取真实人 ID |\n 56|\n### 2.2 M2: 预占管理\n 58|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 人群生成时预占额度（测评/免评）；计算：已用+进行中+已预占+本次拟发送 > 上限 → 拦截；剩余不足但>0 → 预警池 → 发送前人工复核；预占有效期管理，超时自动释放；并发占用控制（同一真实人跨计划重复入选检测） |\n| **对外接口** | `POST /api/quota/reserve` — 创建预占；`POST /api/quota/commit` — 确认占用；`POST /api/quota/release` — 释放预占 |\n| **数据写入** | `quota_reservations` |\n 64|\n### 2.3 M3: 频控引擎\n 66|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 四种频控维度：①渠道频控（IM/EDM/APP/TEL 最近触达间隔）②单 ASIN 短期内触达同一用户次数 ③用户反感度（投诉/退订状态）④用户在客服工单中暂不触达；频控规则可配置 |\n| **对外接口** | `GET /api/quota/freq-check/{person_id}?channel=IM&asin=xxx` — 频控检查 |\n| **数据写入** | `frequency_control_records` |\n| **依赖** | 触达历史来自 outreach（`GET /api/outreach/history/{person_id}`） |\n 73|\n### 2.4 M4: 终校服务\n 75|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 发送前做最终校验：①重新读取最新额度（防止发送和预占之间额度变化）②重新读取最新风险状态 ③重新读取最新未关闭工单；三者全部通过→准入发送；任一新增超限/风险/工单→撤出本批次 |\n| **对外接口** | `POST /api/quota/final-check` — 批量终校（输入 person_ids + plan_id，返回每个的准入/撤出决策） |\n| **数据写入** | 终校结果写入审计日志 |\n| **依赖** | `GET /api/risk/check/{person_id}`；`GET /api/tickets?person_id=&status=open` |\n 82|\n### 2.5 M5: 额度管理 Admin\n 84|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 额度手动调整（运营确认某次测评不计入额度等）；额度重置（新月份额度初始化）；额度审计（谁改了什么额度） |\n| **对外接口** | 管理 API |\n 89|\n### 2.6 M6: 对外 API Gateway\n 91|\n| 维度 | 说明 |\n| --- | --- |\n| **对外接口** | `GET /api/quota/check/{person_id}?type=测评` — 额度查询+可用判断；`POST /api/quota/reserve` — 预占；`POST /api/quota/commit` — 确认；`POST /api/quota/release` — 释放；`POST /api/quota/final-check` — 终校 |\n 95|\n---\n 97|\n## 3. 对外 API 契约（草案）\n 99|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 额度查询 | `GET /api/quota/check/{person_id}?type=REVIEW` | person_id + 额度类型 | `{used, in_progress, reserved, remaining, status(sufficient/warning/exceeded)}` | planning, outreach |\n| 批量预占 | `POST /api/quota/reserve` | `[{person_id, type, plan_id, count}]` | `[{person_id, success, reservation_id}]` | planning（人群生成时） |\n| 确认占用 | `POST /api/quota/commit` | `[{reservation_id}]` | `[{reservation_id, committed}]` | review（用户提交评价后） |\n| 释放预占 | `POST /api/quota/release` | `[{reservation_id}]` | `[{success}]` | planning（计划取消时） |\n| 频控检查 | `GET /api/quota/freq-check/{person_id}?channel=&asin=` | person_id + 渠道 + ASIN | `{allowed, reason, cooldown_until}` | outreach（发送前） |\n| 发送前终校 | `POST /api/quota/final-check` | `[{person_id, plan_id}]` | `[{person_id, decision: APPROVED/WITHDRAWN, reasons}]` | outreach（发送前最后一步） |\n 108|\n---\n 110|\n## 4. 数据对象\n 112|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `person_quota_ledgers` | ledger_id, person_id, quota_type (MONTHLY_REVIEW/MONTHLY_EXEMPTION/LIFETIME_SUBMISSION), period, used, in_progress, reserved, limit_value, status | 三层额度台账 |\n| `quota_reservations` | reservation_id, person_id, ledger_id, plan_id, count, status (RESERVED/COMMITTED/RELEASED/EXPIRED), reserved_at, expires_at | 额度预占记录 |\n| `frequency_control_records` | freq_id, person_id, channel, asin, last_contact_at, contact_count_period, status | 频控记录 |\n 118|\n---\n 120|\n## 5. 业务澄清问题清单 — quota\n 122|\n### 5.1 额度规则细化（5 项）\n 124|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-01 | 月度额度按自然月还是 30 天滚动？如果是自然月：①预占在 1 月 31 日，2 月 1 日释放还是保留？②1 月 31 日晚 23:59 的预占跨月怎么处理？ | **P0** |\n| Q-02 | 「测评 4 次」中的「次」定义：是指参与 4 个不同的测评计划，还是提交 4 条评价？（如果 1 个计划要求用户提交 3 条评价，占 3 次还是 1 次？） | **P0** |\n| Q-03 | 「累计 12 个真实提交评价」是永久上限还是可以动态调整？（例如用户长期优质且评价质量高，是否可以人工放宽？放宽流程？） | P1 |\n| Q-04 | 测评和免评额度是否独立？（测评 4 次 + 免评 4 次 = 同一真实人一月最多参与 8 个计划？）还是测评和免评共享总额度？ | P1 |\n| Q-05 | 额度计算中「进行中」的定义——什么状态才算进行中？（已生成人群？已发送触达？用户已回应？已提交评价待核验？） | P1 |\n 132|\n### 5.2 预占机制（4 项）\n 134|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-06 | 预占有效期多长？（预占后用户始终未响应，多久释放？1 天？7 天？计划周期结束？） | **P0** |\n| Q-07 | 预占释放后是否可以自动重新分配给同一计划的其他用户？是否触发重新生成人群？ | P1 |\n| Q-08 | 跨计划并发占用检测——同一真实人在计划 A 和计划 B 同时被入选，谁先预占谁得？还是按计划优先级？ | P1 |\n| Q-09 | 预占是否可手动取消/释放？（运营发现某用户不应计入某计划时） | P2 |\n 141|\n### 5.3 频控规则（4 项）\n 143|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-10 | 各渠道频控的具体阈值是什么？（IM 每日最多 X 次？EDM 每周最多 Y 封？APP Push 每日最多 Z 条？TEL 每日最多 N 通？） | **P0** |\n| Q-11 | 频控规则是否区分计划类型？（紧急催评是否可以突破频控？） | P1 |\n| Q-12 | 频控是全局统一配置还是按用户层级可调整？（A 类和 C 类用户频控规则是否不同？） | P1 |\n| Q-13 | 「单 ASIN 短期触达次数」——多少天内触达多少次算超标？ | P2 |\n 150|\n### 5.4 预警与异常（3 项）\n 152|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-14 | 预警阈值如何设定？（剩余 1 次时预警？剩余 N% 时预警？不同类型额度预警阈值是否不同？） | P1 |\n| Q-15 | 终校中「新增风险」的判断——距离上次风险检查超过多少时间需重查？还是每次终校都实时查 risk？ | P1 |\n| Q-16 | 额度数据异常时的处理策略？（台账数据与预占记录不一致、预占未释放导致额度泄漏——系统如何自动发现和修复？） | P2 |\n 158|\n### 5.5 额度异常与纠错（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-17 | 用户反馈「我明明只参与了 3 次测评，系统说我已用 4 次」——申诉流程？谁有权限查台账和修正？ | P1 |\n| Q-18 | 额度台账的审计追踪——每次额度变更（预占/确认/释放/手动调整）是否记录完整操作人和原因？保留多久？ | P1 |\n| Q-19 | 数据异常自动检测——台账数据与预占记录之和是否需要对账？系统是否定期自动化对账并报告差异？ | P1 |\n| Q-20 | 如果发现「额度泄漏」（预占未释放导致额度永久被占），系统如何自动发现和修复？（定时扫描过期预占？手动触发对账？） | P2 |\n\n### 5.6 紧急/例外处理（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-21 | 大促期间（Prime Day/Black Friday）是否需要临时额度提升？（测评 4→8？）由谁审批？临时额度有效期？ | P1 |\n| Q-22 | 高价值用户是否可以突破额度限制？（例如 KOC 级别的用户需要超额参与——人工审批流程？） | P1 |\n| Q-23 | 「紧急计划」是否可以跳过频控？（例如 Listing 评分暴跌至 3.8 需要紧急大量催评——是否豁免部分频控规则？） | P1 |\n| Q-24 | 额度手动调整是否需要审批？审批权限？（谁可以手动给某人加/减可用额度？） | P2 |\n\n### 5.7 跨站点/跨平台额度（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-25 | 额度是否跨 Amazon 站点？（.com 参与了 2 次测评 + .co.uk 参与了 3 次 → 全局算 5 次还是各自独立？） | P1 |\n| Q-26 | 累计 12 个评价是否跨站点统计？（在 .com 提交了 8 个 + .co.uk 提交了 5 个 → 是否算 13 个超限？） | P1 |\n| Q-27 | 未来扩展到非 Amazon 平台，额度体系是否独立？（eBay 的测评额度与 Amazon 的额度是否共享？） | P2 |\n\n### 5.8 额度可见性（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-28 | 用户是否能看到自己的额度状态？（APP 端显示「本月还可参与 2 次测评」——是否对用户可见？） | P2 |\n| Q-29 | 运营视角的额度看板——能否看到「全局额度使用率」「各真实人的额度分布」「额度预警用户列表」？ | P1 |\n\n### 5.9 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-30 | 终校服务的性能要求——批量终校（一次可能几百人）需要在多少 ms 内完成？（涉及跨子系统调用 risk + support） | P2 |\n| Q-31 | 频控规则是否需要热更新（不重启服务即可调整阈值）？配置管理方案？ | P1 |\n| Q-32 | 额度台账历史数据的初始化——旧系统的数据如何映射到三层额度模型？（无「真实人」概念的老数据如何归入？） | P1 |", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/04-子系统-多渠道触达引擎", "type": "document", "name": "子系统 04 — 多渠道触达引擎 (`outreach`) v1.0", "filePath": "05_需求文档/04-子系统-多渠道触达引擎.md", "summary": "子系统 04 — 多渠道触达引擎 outreach v1.0 2 子系统概述 4 维度 说明 代号 outreach 核心职责 渠道路由决策、渠道去重、IM/EDM/APP Push/TEL 渠道调度执行、触达历史管理 数据所有权 channel route decisions , channel dedup records , im interaction", "tags": [ "05_需求文档", "需求文档" ], "complexity": "moderate", "knowledgeMeta": { "content": "# 子系统 04 — 多渠道触达引擎 (`outreach`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `outreach` |\n| 核心职责 | 渠道路由决策、渠道去重、IM/EDM/APP Push/TEL 渠道调度执行、触达历史管理 |\n| 数据所有权 | `channel_route_decisions`, `channel_dedup_records`, `im_interaction_records`, `im_flow_tags`, `edm_message_events`, `edm_user_behavior_profiles`, `app_touch_events`, `tel_call_records` |\n| 启动依赖 | identity / planning / quota（均为软依赖） |\n| 外部系统依赖 | JOYHUB（IM 通道）、ESP（EDM）、FCM/APNs（APP Push）、电话系统（TEL） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ outreach 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 渠道路由 │ │ M2: 渠道去重 │ │ M3: IM 执行 │ │\n│ │ + 优先级 │→│ │→│ 引擎 │ │\n│ └──────────────┘ └──────────────┘ └──────┬───────┘ │\n│ │ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────┴───────┐ │\n│ │ M4: EDM 执行 │ │ M5: APP Push │ │ M6: TEL 执行 │ │\n│ │ 引擎 │ │ 引擎 │ │ 引擎 │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ │\n│ │ M7: 触达历史 │ │ M8: 对外 API │ │\n│ │ 服务 │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 38|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | 渠道路由+优先级 | 按用户状态路由到最优渠道（APP活跃→IM优先 / 未注册→EDM优先 / 高价值无响应→TEL / C类→IM免评卡片） |\n| M2 | 渠道去重 | 同一计划同一用户不重复走多渠道路由；工单中暂停自动触达；已提交待核验暂停催评 |\n| M3 | IM 执行引擎 | IM 推送、用户分层（A未参与/B参与过/C长期测评人）、回评/测评/免评卡片推送、催评、提交核验、返款通知 |\n| M4 | EDM 执行引擎 | EDM 发送、送达/打开/点击追踪、行为画像、节奏控制、退订/硬退信处理 |\n| M5 | APP Push 引擎 | APP 推送、触发源管理（绑定玩具/不活跃/计划到期/Listing紧急/活动）、响应追踪 |\n| M6 | TEL 执行引擎 | 电话任务生成、拨打前准备（用户画像+风险检查+历史沟通）、通话记录、重试策略 |\n| M7 | 触达历史服务 | 统一触达历史查询（跨渠道聚合）、供 quota（频控）、identity（上下文卡）调用 |\n| M8 | 对外 API Gateway | 统一对外 API |\n 49|\n---\n 51|\n## 2. 各模块内外说明\n 53|\n### 2.1 M1: 渠道路由+优先级\n 55|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 接收 planning 的已批准计划，按用户状态矩阵决定渠道：APP活跃+已绑定→IM首选；APP低活跃→EDM补充+APP Push召回；未注册→EDM首选→引导注册后转IM；高价值+多次无响应→TEL；C类（累计≥12）→IM免评卡片+KOC/KOL协同 |\n| **对外接口** | `POST /api/outreach/route` — 输入计划+用户，返回路由决策 |\n| **数据写入** | `channel_route_decisions` |\n| **依赖** | `GET /api/identity/context/{person_id}` — 用户状态 |\n 62|\n### 2.2 M2: 渠道去重\n 64|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 执行去重规则（同一计划同一用户首选渠道、工单中暂停、已提交评价暂停、退订某渠道永久排除、强关联风险全暂停、弱关联降频+提示） |\n| **对外接口** | `GET /api/outreach/dedup-check?person_id=&plan_id=` |\n| **数据写入** | `channel_dedup_records` |\n| **依赖** | `GET /api/tickets?person_id=&status=open`（support）；`GET /api/risk/check/{person_id}`（risk） |\n 71|\n### 2.3 M3: IM 执行引擎\n 73|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 用户分层逻辑（A未参与/B参与过但<12/C≥12长期测评人）；分层推送策略（A推回评卡片/B先催评再二次转化/C仅免评）；提交后的核验与流转（订单号核实→登记→补全信息→返款→二次转化）；标签管理（9 种核心标签如「xx产品已回评用户」「xx产品测评待返款用户」等） |\n| **对外接口** | `POST /api/outreach/im/send` — 发送 IM 消息 |\n| **数据写入** | `im_interaction_records`, `im_flow_tags` |\n| **依赖** | JOYHUB（IM 通道）；`GET /api/quota/check/{person_id}` |\n| **待确认** | IM 是 WhatsApp 还是自研 IM？通道对接方式？ |\n 81|\n### 2.4 M4: EDM 执行引擎\n 83|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 推送前检查（身份→风险→退订→资格→国家）；行为筛选（打开/点击/回复/频率）；节奏判断（适合触达/需降频/不适合）；发送后追踪（送达→打开→点击→回复→退订）；转化路径（下载注册APP→转IM / 直接回复邮件→生成客服工单 / 未响应→再触达队列） |\n| **对外接口** | `POST /api/outreach/edm/send` — 发送 EDM |\n| **数据写入** | `edm_message_events`, `edm_user_behavior_profiles` |\n| **依赖** | ESP 邮件服务 |\n| **待确认** | EDM 模板在哪里管理？模板变量（用户名/产品名/链接）如何填充？ |\n 91|\n### 2.5 M5: APP Push 引擎\n 93|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 5 种触发源（绑定新玩具/不活跃/计划到期/Listing紧急/活动）；推送前过滤（身份+风险+频控+标签）；响应追踪（点击打开→落地页 / 忽略→短期不重复推 / 卸载→转EDM候选池）；APP 内动作分流（提交回评/测评→IM核验 / 联系客服→工单 / 浏览→更新活跃标签） |\n| **对外接口** | `POST /api/outreach/app/push` — 发送 APP Push |\n| **数据写入** | `app_touch_events` |\n| **依赖** | FCM/APNs |\n| **待确认** | 是否复用 JOYHUB 现有 Push 通道？ |\n 101|\n### 2.6 M6: TEL 执行引擎\n 103|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 7 种触发场景（答应配合超时/高价值跟进/复杂售后/多次无响应/紧急Listing/Amazon来电/外呼任务）；拨打前准备 5 步（查用户完整画像→查风险→查历史沟通→准备话术→生成电话工单）；通话结果 5 种（售后问题解决→引导回评 / 直接配合→登记答应配合 / 拒绝→记录 / 疑似诈骗→转风险 / 未接通→重试）；重试策略（<3次重拨 / ≥3次降级EDM或关闭） |\n| **对外接口** | `POST /api/outreach/tel/task` — 创建 TEL 任务 |\n| **数据写入** | `tel_call_records` |\n| **依赖** | 电话系统（外呼/来电） |\n 110|\n### 2.7 M7: 触达历史服务\n 112|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 跨渠道聚合触达历史（IM/EDM/APP/TEL）；提供统一查询接口供 quota（频控）和 identity（上下文卡）消费 |\n| **对外接口** | `GET /api/outreach/history/{person_id}` |\n| **数据写入** | 只读聚合 |\n 118|\n---\n 120|\n## 3. 对外 API 契约（草案）\n 122|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 触达历史 | `GET /api/outreach/history/{person_id}` | person_id | `{im[], edm[], app[], tel[]}` | quota（频控）, identity（上下文卡） |\n| 执行触达 | `POST /api/outreach/send` | `{plan_id, person_ids[], channel, content}` | `{task_id, status}` | planning |\n| 渠道路由决策 | `POST /api/outreach/route` | `{person_id, plan_id}` | `{recommended_channel, alternatives[]}` | planning |\n| IM 消息发送 | `POST /api/outreach/im/send` | `{person_id, msg_type, content}` | `{message_id}` | 内部 |\n 129|\n---\n 131|\n## 4. 数据对象\n 133|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `channel_route_decisions` | decision_id, person_id, plan_id, selected_channel, reason, decided_at | 渠道路由决策 |\n| `channel_dedup_records` | dedup_id, person_id, plan_id, channel, status(BLOCKED/ALLOWED), block_reason | 渠道去重记录 |\n| `im_interaction_records` | interaction_id, person_id, msg_type(PUSH_CARD/REVIEW_CARD/EXEMPTION_CARD/REMINDER/REFUND_NOTICE), direction(OUTBOUND/INBOUND), content, status, created_at | IM 交互记录 |\n| `im_flow_tags` | tag_id, person_id, tag_type, tag_value, tagged_at | IM 流程标签（如 xx产品待返款等） |\n| `edm_message_events` | event_id, person_id, email, event_type(SENT/DELIVERED/OPENED/CLICKED/REPLIED/UNSUBSCRIBED/HARD_BOUNCED), occurred_at | EDM 事件 |\n| `edm_user_behavior_profiles` | profile_id, person_id, email, last_opened_at, total_opens, consecutive_no_open, last_replied_at, monthly_received, status | EDM 用户行为画像 |\n| `app_touch_events` | event_id, person_id, trigger_type, push_status, response, occurred_at | APP Push 事件 |\n| `tel_call_records` | call_id, person_id, ticket_id, direction(OUTBOUND/INBOUND), call_status, duration, outcome, retry_count, recorded_at | TEL 通话记录 |\n 144|\n---\n 146|\n## 5. 业务澄清问题清单 — outreach\n 148|\n### 5.1 渠道优先级路由（4 项）\n 150|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-01 | 路由规则是否可配置？（例如针对某个站点用户调整 IM > EDM 的优先级）配置界面在 outreach 内还是在独立配置管理？ | **P0** |\n| O-02 | 「APP 低活跃」的判定标准是什么？（N 天未打开？N 天未点击推送？）阈值是否可配置？ | P1 |\n| O-03 | 高优先级渠道发送失败（退信/未送达）后，是否自动降级到下一渠道？降级是否有冷却时间？ | P1 |\n| O-04 | C 类用户（累计≥12）只推免评——如果免评计划也没有，是完全不推还是推品牌/活动内容？ | P2 |\n 157|\n### 5.2 IM 通道（4 项）\n 159|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-05 | IM 使用的具体平台是什么？（WhatsApp Business API / 自研 JOYHUB IM / Messenger？）不同平台的 API 能力和限制？ | **P0** |\n| O-06 | IM 的「分层」是系统自动判断还是人工可干预？（一个 B 类用户会不会被错误标记为 C 类？如何修正？） | **P0** |\n| O-07 | IM 推送中「测评卡片」的具体形式是什么？（带按钮的消息模板？需要用户填表单？）模板在哪里管理？ | P1 |\n| O-08 | IM 中的「订单号核实」——核实的数据源是什么？（比对内部订单表？Amazon 订单 API？）核实失败的转人工流程？ | P1 |\n 166|\n### 5.3 EDM 通道（4 项）\n 168|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-09 | 当前使用的邮件服务是什么？（SendGrid/Mailchimp/SES/自建？）有没有现成 API 和 Webhook 追踪？ | **P0** |\n| O-10 | EDM 模板（邮件内容、样式、多语言）在哪里管理？属于 outreach 还是独立内容管理子系统？ | P1 |\n| O-11 | 「EDM 行为画像」中的「最近 3/5 次 0 打开」——3 次和 5 次是两个独立指标还是二选一？各自对应什么策略？ | P1 |\n| O-12 | EDM 发送量和频控——单日最大发送量有限制吗？（ESP 的每日限额？） | P1 |\n 175|\n### 5.4 APP Push（3 项）\n 177|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-13 | APP Push 是否复用 JOYHUB 的现有推送通道？还是需要独立接入 FCM（Android）和 APNs（iOS）？ | **P0** |\n| O-14 | APP Push 和 IM 消息的分工——文档第 11.2 节给了对照表，但边界是否绝对？（例如\"计划到期提醒\"是否可能同时走 APP Push 和 IM？） | P1 |\n| O-15 | APP 落地页——推送点击后跳转到哪个页面？（APP 内的测评页？IM 对话页？）落地页由哪个团队/子系统负责？ | P2 |\n 183|\n### 5.5 TEL 通道（3 项）\n 185|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-16 | 电话系统使用什么方案？（自建 SIP PBX / Twilio / 其他云呼叫中心？）是否已有通话记录？ | **P0** |\n| O-17 | 「拨打前准备」第 2 步「查风险：强关联命中→暂停拨打→先复核」——复核由谁来做？（风险人员？客服组长？）复核时长预期？ | P1 |\n| O-18 | 电话中「尽量确认」的字段（购买平台、订单号、产品型号、购买时间、问题类型、凭证）如果用户不愿意/无法提供——哪些是必须确认的？哪些可以跳过？ | P1 |\n 191|\n### 5.6 消息内容与合规（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-19 | 消息内容是否需要审核？（IM 推送文案、EDM 邮件内容、APP Push——上线前是否需要审核？审核流程？） | P1 |\n| O-20 | EDM 合规要求——是否遵守 CAN-SPAM Act（美国）、GDPR（欧洲）、CASL（加拿大）？退订机制是否满足法律要求？ | P1 |\n| O-21 | IM 平台的合规限制——WhatsApp 等平台禁止垃圾消息和特定类型内容（如测评引导）——是否有合规风险？ | P1 |\n| O-22 | 消息发送的时区感知——美国用户、英国用户、德国用户的推送时间是否需要本地化？（用户当地时间的白天而非半夜） | P1 |\n\n### 5.7 消息策略与实验（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-23 | 是否需要 A/B 测试能力？（同一计划的两组用户收到不同文案/不同发送时间——对比转化率？） | P2 |\n| O-24 | 消息打开率/点击率/转化率的追踪和报表？是否需要自动优化发送策略（高打开率的文案模板优先使用）？ | P2 |\n| O-25 | 用户反馈「消息太频繁/内容不相关」——是否有投诉/退订统计和预警？（投诉率超过 X% 暂停该类型推送？） | P1 |\n\n### 5.8 IM 通道补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-26 | IM 消息的「已读」状态是否能获取？（WhatsApp 的蓝色双勾——能否用于判断用户是否看到消息？） | P1 |\n| O-27 | IM 用户提交的「评论截图/链接」——如何自动验证截图的真实性？（防止用户 PS 假截图？是否需要 OCR 识别截图内容？） | P1 |\n| O-28 | IM 中的返款通知——返款是系统自动触发还是人工触发？返款状态如何回写到 outreach？ | P1 |\n\n### 5.9 EDM 通道补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-29 | EDM 的「硬退信」和「投诉」是否自动同步到 identity 的风险标记？（硬退信用户是否需要进入风险观察？） | P1 |\n| O-30 | EDM 引导用户下载 APP——是否在邮件中嵌入归因链接（deferred deep link）以追踪转化来源？ | P2 |\n| O-31 | EDM 的发送域名和 IP 预热策略？（新域名/IP 直接大批量发送会被 ESP 判定为垃圾邮件——需要渐进式预热？） | P2 |\n\n### 5.10 TEL 通道补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-32 | 电话录音是否需要存储？存储多久？谁有权调取录音？（涉及合规和隐私） | P1 |\n| O-33 | 不同国家的电话合规要求——美国需提前告知录音、德国的 GDPR 限制——如何处理？ | P1 |\n| O-34 | TEL 任务的优先级和分配——多个外呼任务同时存在时，客服按什么顺序拨打？（先打高价值用户？先打答应配合超时的？） | P1 |\n\n### 5.11 实施层面（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-35 | 各外部通道的 rate limit 和计费模式？（WhatsApp 按消息数计费？EDM 按发送量计费？）是否需要成本控制？ | P1 |\n| O-36 | 消息发送是同步还是异步？（用户点「发送」后立即返回还是后台队列处理？失败重试策略？） | P1 |\n| O-37 | 多渠道消息的发送顺序保证？（「先发 IM 提醒→24h 后无回复再发 EDM」——这种时序依赖如何实现？定时任务？延迟队列？） | P2 |\n| O-38 | 异常场景——如果某渠道 100% 发送失败（ESP 宕机/WhatsApp API 限流）——是否自动切换备用渠道？ | P2 |", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/05-子系统-客服工单与管理", "type": "document", "name": "子系统 05 — 客服工单与管理 (`support`) v1.0", "filePath": "05_需求文档/05-子系统-客服工单与管理.md", "summary": "子系统 05 — 客服工单与管理 support v1.0 2 子系统概述 4 维度 说明 代号 support 核心职责 工单生命周期管理、自动分配、答应配合状态机、排班出勤管理、绩效统计 数据所有权 support tickets , support followups , support assignment logs , attendance rec", "tags": [ "05_需求文档", "需求文档" ], "complexity": "moderate", "knowledgeMeta": { "content": "# 子系统 05 — 客服工单与管理 (`support`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `support` |\n| 核心职责 | 工单生命周期管理、自动分配、答应配合状态机、排班出勤管理、绩效统计 |\n| 数据所有权 | `support_tickets`, `support_followups`, `support_assignment_logs`, `attendance_records`, `shift_schedules`, `support_performance_snapshots` |\n| 启动依赖 | identity（软依赖，无上下文卡时可先跑工单） |\n| 外部系统依赖 | 无直接外部依赖（电话记录来自 outreach TEL 模块） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ support 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 工单管理 │ │ M2: 自动分配 │ │ M3: 答应配合 │ │\n│ │ (Ticket) │→│ (Assign) │ │ 状态机 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 排班出勤 │ │ M5: 绩效统计 │ │ M6: 对外 API │ │\n│ │ 管理 │ │ │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | 工单管理 | 工单创建、分类、状态流转（待分配→已分配→处理中→等待用户/等待内部→已解决/疑似诈骗→已关闭） |\n| M2 | 自动分配 | 按班次+在线状态+当前负载+最大工单数自动分配到客服组；组长再分派到组员 |\n| M3 | 答应配合状态机 | 独立的答应配合状态流转（已答应→待分配→待提醒→等待提交→已提交/超时→需再次联系→关闭） |\n| M4 | 排班出勤管理 | 排班设置、出勤记录（应出勤/实际出勤/迟到/早退/请假/缺勤）、在线客服池维护 |\n| M5 | 绩效统计 | 回复效率（回复用户数/处理工单数/首次回复时长分布）；转化统计（RSO回评/RDO测评登记订单数/获取评价数/完成率）；目标完成统计 |\n| M6 | 对外 API Gateway | 供其他子系统创建工单、查询工单状态、查询绩效数据 |\n 43|\n---\n 45|\n## 2. 各模块内外说明\n 47|\n### 2.1 M1: 工单管理\n 49|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 5 种入口（用户消息进入/推送转人工/售后触发/风险触发/电话后续）；工单状态流转（待分配→已分配→处理中→等待用户/等待内部→已解决/疑似诈骗→已关闭）；5 种处理结果（等待用户回复/等待内部协同/答应配合/疑似诈骗/已解决） |\n| **对外接口** | `POST /api/tickets` — 创建工单；`PUT /api/tickets/{id}/status` — 更新状态 |\n| **数据写入** | `support_tickets` |\n| **依赖** | `GET /api/identity/context/{person_id}` — 展示用户上下文卡 |\n| **待确认** | 工单类型分类维度？（售后/催评/风险/其他？是否需要自定义分类？） |\n 57|\n### 2.2 M2: 自动分配\n 59|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 分配算法（查班次+在线状态+当前负载+最大工单数→自动分配到客服组）；组长可在组内重新分派到具体组员；分配日志记录 |\n| **对外接口** | 内部服务 |\n| **数据写入** | `support_assignment_logs` |\n| **依赖** | M4 排班出勤数据 |\n| **待确认** | 「当前负载」按什么计算？（未关闭工单数？最近 N 小时处理量？两者加权？） |\n 67|\n### 2.3 M3: 答应配合状态机\n 69|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 独立于工单状态的状态机（已答应配合→待分配负责人→待提醒→等待提交→已提交评价/已提交反馈→超时→需再次联系→已关闭）；防止承诺用户流失；超时提醒机制 |\n| **对外接口** | `POST /api/support/followups` — 创建跟进任务；`PUT /api/support/followups/{id}` — 更新状态 |\n| **数据写入** | `support_followups` |\n| **待确认** | 答应配合后多少天未提交算超时？超时后提醒频率？多次提醒无果后是否降级？ |\n 76|\n### 2.4 M4: 排班出勤管理\n 78|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 排班设置（按日/周的班次安排）；出勤记录（应出勤/实际出勤/出勤率/迟到/早退/请假/缺勤）；在线客服池（排班+在线状态→可用客服列表） |\n| **对外接口** | `GET /api/support/available-agents` — 查询当前可用客服 |\n| **数据写入** | `attendance_records`, `shift_schedules` |\n| **待确认** | 排班是否对接外部 HR 系统还是独立管理？客服手动签入/签出？ |\n 85|\n### 2.5 M5: 绩效统计\n 87|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 回复效率（回复用户数、处理工单数、发送消息数、首次回复时长：平均/中位数/最大/最小）；转化统计（RSO 回评登记订单数、RDO 测评登记订单数、获取评价数、评价完成率）；目标完成（月目标、当前完成、完成率、历史趋势）；主管看板 |\n| **对外接口** | `GET /api/support/stats?agent_id=&period=` — 绩效数据查询 |\n| **数据写入** | `support_performance_snapshots`（定时快照） |\n| **待确认** | 绩效统计周期（日/周/月？）主管看板是否需要实时数据还是 T+1 汇总？ |\n 94|\n---\n 96|\n## 3. 对外 API 契约（草案）\n 98|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 创建工单 | `POST /api/tickets` | `{person_id, source, type, description}` | `{ticket_id}` | outreach（TEL→工单/EDM回复→工单）、risk（诈骗→工单） |\n| 工单详情 | `GET /api/tickets/{id}` | ticket_id | 完整工单+上下文卡 | 客服前端 |\n| 查询用户打开工单 | `GET /api/tickets?person_id=&status=open` | person_id | `[{ticket_id, status}]` | outreach（渠道去重）、quota（终校） |\n| 客服可用性 | `GET /api/support/available-agents` | 无 | `[{agent_id, current_load}]` | outreach（分配参考） |\n| 绩效查询 | `GET /api/support/stats?agent_id=&period=` | agent_id + 周期 | 绩效数据 | 客服管理前端 |\n 106|\n---\n 108|\n## 4. 数据对象\n 110|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `support_tickets` | ticket_id, person_id, source, type, status, assigned_agent, assigned_group, created_at, resolved_at | 工单主表 |\n| `support_followups` | followup_id, ticket_id, person_id, status(PROMISED/ASSIGNED/WAITING/SUBMITTED/TIMEOUT/RECONTACT/CLOSED), promised_at, deadline_at, reminded_at | 答应配合跟进 |\n| `support_assignment_logs` | log_id, ticket_id, from_agent, to_agent, reason, assigned_at | 工单分配日志 |\n| `attendance_records` | record_id, agent_id, date, status(PRESENT/LATE/EARLY/ABSENT/LEAVE), check_in, check_out | 出勤记录 |\n| `shift_schedules` | shift_id, agent_id, date, shift_type, start_time, end_time | 排班表 |\n| `support_performance_snapshots` | snapshot_id, agent_id, period, tickets_handled, messages_sent, avg_first_reply, rso_orders, rdo_orders, reviews_obtained, completion_rate | 绩效快照 |\n 119|\n---\n 121|\n## 5. 业务澄清问题清单 — support\n 123|\n### 5.1 工单管理（5 项）\n 125|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-01 | 工单的来源分类有哪些？（IM 转人工 / 电话后续 / EDM 回复 / 用户主动联系 / 风险触发 / 其他？）每种来源的优先级是否不同？ | **P0** |\n| S-02 | 工单状态「等待用户」和「等待内部」的超时分别是多少？超时后谁来提醒？提醒方式（IM/系统通知）？ | **P0** |\n| S-03 | 三套并行状态（工单状态/答应配合状态/风险状态）的交互规则？例如：风险状态变为「确认诈骗」时工单是否自动关闭？（目前文档说是独立拆开的） | P1 |\n| S-04 | 工单关闭后是否允许重新打开？什么条件可重开？ | P1 |\n| S-05 | 工单是否有 SLA（服务级别协议）？不同来源/类型的工单 SLA 不同？ | P2 |\n 133|\n### 5.2 自动分配（4 项）\n 135|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-06 | 「当前负载」如何精确计算？（未关闭工单数 × 权重？最近 N 小时处理量？工单类型权重不同？） | **P0** |\n| S-07 | 「最大工单数」是什么？（每个客服同时最多持有 X 个工单？）这个值是否统一还是按级别不同？ | **P0** |\n| S-08 | 在线状态如何判定？（手动签入/签出？系统自动检测活跃度？N 分钟无操作自动离线？） | P1 |\n| S-09 | 自动分配如果分配给了离线/满载的客服，兜底机制是什么？（自动转移给组长？放入公共池？） | P1 |\n 142|\n### 5.3 答应配合（3 项）\n 144|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-10 | 答应配合后多少天未提交算超时？超时后的提醒频率？（第 1/3/7 天各提醒一次？）多次提醒无果后关闭还是降级？ | **P0** |\n| S-11 | 用户答应配合但最终提交了错误的 ASIN 评价——算不算配合完成？如何处理？ | P1 |\n| S-12 | 答应配合状态是否只针对客服工单场景？IM 直推中用户答应的算不算？ | P1 |\n 150|\n### 5.4 排班出勤（3 项）\n 152|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-13 | 排班管理是否对接外部 HR 系统？还是独立在 support 子系统内管理？ | P1 |\n| S-14 | 菲律宾客服团队的工作制度？（班次类型：早班/中班/晚班？每班时长？每周几天？） | P1 |\n| S-15 | 出勤异常（迟到/早退/缺勤）是否需要自动通知主管？通知方式？ | P2 |\n 158|\n### 5.5 绩效统计（3 项）\n 160|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-16 | 转化统计中 RSO（回评）和 RDO（测评）如何区分？（按工单来源？按关联计划类型？按客服标记？） | P1 |\n| S-17 | 「首次回复时长」从什么时候开始计时？（工单分配给客服的时间？用户消息到达时间？） | P1 |\n| S-18 | 评价完成率的分母是什么？（答应配合数？登记订单数？触达数？） | P2 |\n 166|\n### 5.6 多语言与国际化（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-19 | 客服工作台需要支持哪些语言？（菲律宾客服用英语+Tagalog？面向用户的消息是否需要自动翻译？） | P1 |\n| S-20 | 用户消息的多语言处理——用户用德语/法语/西语发消息时，客服如何理解？（是否需要集成翻译工具？） | P2 |\n| S-21 | 系统管理界面（排班/绩效/设置）是否需要多语言？面向中国管理团队的是中文界面？ | P2 |\n\n### 5.7 知识库与话术（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-22 | 是否需要集成知识库/FAQ？（客服在处理售后时快速查找产品信息、常见问题解答？） | P2 |\n| S-23 | 是否需要「快捷回复」功能？（预设常用回复模板——「请提供你的订单号」「我们将在 24h 内处理你的退款」等） | P1 |\n| S-24 | 快捷回复模板是否支持按场景/产品分类？（不同产品的售后话术不同——模板管理和权限？） | P2 |\n\n### 5.8 客服质量管控（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-25 | 是否需要客户满意度（CSAT）调查？（工单关闭后推送满意度评分——评分方式？计入绩效？） | P2 |\n| S-26 | 是否需要质检功能？（组长抽查客服的对话记录进行评分——质检抽样比例？质检标准？） | P2 |\n| S-27 | 客服技能分组——不同客服擅长不同类型工单（售后/催评/风控）——是否需要基于技能的自动分配？ | P1 |\n| S-28 | 升级工单的处理流程——什么条件下工单升级到组长/负责人？（超时？用户投诉？疑似诈骗？） | P1 |\n\n### 5.9 排班与出勤补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-29 | 排班是否支持轮班制？（周一到周日每天不同的班次安排）排班变更的通知方式？ | P1 |\n| S-30 | 临时调班/换班请求——客服之间是否可以自助换班？是否需要审批？ | P2 |\n| S-31 | 节假日/特殊日期的排班策略？（当地节假日——菲律宾假日 vs 美国假日 vs 中国假日——按哪国日历？） | P1 |\n\n### 5.10 绩效统计补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-32 | 绩效考核周期？（日/周/月/季度？）绩效数据是否需要导出为报表？ | P1 |\n| S-33 | 绩效目标是否可自定义？（不同组的目标不同？新人目标低于老员工？）目标由谁设置？ | P1 |\n| S-34 | 绩效看板是否需要实时数据还是 T+1 汇总？（主管需要实时看到当前客服处理了多少工单？） | P2 |\n\n### 5.11 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-35 | 客服使用的 IM 工具——是独立于 outreach 的客服专用 IM 还是嵌入在客服工作台内的 Web IM？ | P1 |\n| S-36 | 工单数据是否需要与 outreach 的交互记录打通？（同一个用户在 IM 的聊天记录是否需要关联到工单？） | P1 |\n| S-37 | 客服工作台的实时性要求——新工单到达后多少秒内需要在客服界面显示？（WebSocket 推送 vs 轮询？） | P2 |", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/06-子系统-风险与反欺诈", "type": "document", "name": "子系统 06 — 风险与反欺诈 (`risk`) v1.0", "filePath": "05_需求文档/06-子系统-风险与反欺诈.md", "summary": "子系统 06 — 风险与反欺诈 risk v1.0 2 子系统概述 4 维度 说明 代号 risk 核心职责 强弱关联判断、黑名单实体管理、风险事件管理、双重退款检测 数据所有权 risk signals , risk cases , blacklist entities , refund match results 启动依赖 identity（软依赖） 外", "tags": [ "05_需求文档", "需求文档" ], "complexity": "moderate", "knowledgeMeta": { "content": "# 子系统 06 — 风险与反欺诈 (`risk`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `risk` |\n| 核心职责 | 强弱关联判断、黑名单实体管理、风险事件管理、双重退款检测 |\n| 数据所有权 | `risk_signals`, `risk_cases`, `blacklist_entities`, `refund_match_results` |\n| 启动依赖 | identity（软依赖） |\n| 外部系统依赖 | Amazon（退款数据）、财务系统（OA 返款数据） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ risk 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 关联判断 │ │ M2: 黑名单 │ │ M3: 双重退款 │ │\n│ │ 引擎 │→│ 管理 │ │ 检测 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 风险事件 │ │ M5: 风险审核 │ │ M6: 对外 API │ │\n│ │ 管理 │ │ Admin │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | 关联判断引擎 | 对每次风险信号做强弱关联判断（强：邮箱/设备/电话/地址/订单号/ProfileID/收款信息 命中→高风险；弱：IP单独/姓名单独/同址异名→观察+复核） |\n| M2 | 黑名单管理 | 黑名单实体管理（添加/移除/过期）、黑名单同步、命中查询 |\n| M3 | 双重退款检测 | Amazon 退款记录 vs OA 返款记录的自动比对，检测重复退款 |\n| M4 | 风险事件管理 | 风险事件创建、状态流转、关联工单/推送/计划状态回写 |\n| M5 | 风险审核 Admin | 人工复核弱关联风险、确认/排除诈骗、黑名单操作 |\n| M6 | 对外 API Gateway | 供所有子系统查询风险状态、上报风险信号 |\n 43|\n---\n 45|\n## 2. 各模块内外说明\n 47|\n### 2.1 M1: 关联判断引擎\n 49|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 每次风险信号进入时执行：8 项强关联维度（邮箱/设备号/电话/收件人姓名+地址/订单号/聊天记录/Profile ID/收款信息）→任一命中→高风险；3 项弱关联维度（IP单独/姓名单独/同址异名）→高风险观察+人工复核；判断结果：强关联/弱关联/无关联 |\n| **对外接口** | `GET /api/risk/check/{person_id}` — 风险查询（含关联判断结果） |\n| **数据写入** | `risk_signals` |\n| **依赖** | `GET /api/identity/context/{person_id}` — 获取身份线索用于关联判断 |\n| **关键规则** | 风险判断不是一次性，每次有效互动都要重做；非 APP 用户缺设备/注册邮箱等维度→风险识别能力下降 |\n 57|\n### 2.2 M2: 黑名单管理\n 59|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 黑名单实体 CRUD（邮箱/设备/电话/地址/收款信息）；黑名单命中查询（任何子系统查询用户是否在黑名单）；黑名单同步（确认诈骗后同步到黑名单）；黑名单过期/申诉机制 |\n| **对外接口** | `GET /api/risk/blacklist/check?type=EMAIL&value=xxx` — 黑名单命中检查 |\n| **数据写入** | `blacklist_entities` |\n| **待确认** | 黑名单是否有过期时间？申诉/移除流程？ |\n 66|\n### 2.3 M3: 双重退款检测\n 68|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 采集 Amazon 退款记录（外部系统同步）+ OA 返款记录（财务系统同步）；按订单号/用户/金额/时间自动比对；匹配结果：无重复/疑似重复/确认重复；确认重复时强告警+阻止后续返款 |\n| **对外接口** | `GET /api/risk/double-refund-check/{person_id}` — 双重退款检测 |\n| **数据写入** | `refund_match_results` |\n| **依赖** | Amazon 退款数据（外部）、OA 返款数据（外部财务系统） |\n| **待确认** | Amazon 退款数据如何及时获取？OA 返款记录是否已有 API？ |\n 76|\n### 2.4 M4: 风险事件管理\n 78|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 风险事件创建（客服上报疑似诈骗 / 双重退款检测 / 关联判断命中）；事件状态流转（待复核→复核中→确认风险/排除风险）；高风险链路动作（拦截继续推送/拦截自动退款/拦截自动放行）；回写关联工单/推送/计划状态 |\n| **对外接口** | `POST /api/risk/report` — 上报风险信号（客服、系统自动均可调用） |\n| **数据写入** | `risk_cases` |\n 84|\n### 2.5 M5: 风险审核 Admin\n 86|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 人工复核弱关联风险；确认/排除诈骗判定；黑名单手动操作；风险口径维护 |\n| **对外接口** | 管理 API |\n| **待确认** | 复核时效要求？（N 分钟内必须复核？） |\n 92|\n---\n 94|\n## 3. 对外 API 契约（草案）\n 96|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 风险查询 | `GET /api/risk/check/{person_id}` | person_id | `{risk_level(NONE/WEAK/STRONG), signals[], cases[]}` | 所有子系统（每次互动时调用） |\n| 上报风险信号 | `POST /api/risk/report` | `{person_id, signal_type, evidence, reported_by}` | `{signal_id}` | support（客服上报诈骗）、outreach（异常互动） |\n| 黑名单命中 | `GET /api/risk/blacklist/check?type=&value=` | 维度类型+值 | `{hit, entity}` | outreach（发送前）、identity（身份归并时） |\n| 双重退款检测 | `GET /api/risk/double-refund-check/{person_id}` | person_id | `{status, matched_refunds[]}` | outreach（返款前）、support（退款处理前） |\n 103|\n---\n 105|\n## 4. 数据对象\n 107|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `risk_signals` | signal_id, person_id, signal_type, hit_dimensions[], risk_level(STRONG/WEAK), detected_at | 风险信号（每次互动生成的判断） |\n| `risk_cases` | case_id, person_id, source, status(PENDING_REVIEW/REVIEWING/CONFIRMED_RISK/RULED_OUT), reviewer, created_at, resolved_at | 风险事件 |\n| `blacklist_entities` | entity_id, entity_type(EMAIL/DEVICE/PHONE/ADDRESS/PAYMENT), entity_value, status(ACTIVE/EXPIRED/APPEALED), added_at, added_by | 黑名单实体 |\n| `refund_match_results` | match_id, person_id, amazon_refund_id, oa_refund_id, match_status(NO_DUPLICATE/SUSPECTED/CONFIRMED), matched_at | 双重退款比对结果 |\n 114|\n---\n 116|\n## 5. 业务澄清问题清单 — risk\n 118|\n### 5.1 强弱关联规则（4 项）\n 120|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-01 | 8 项强关联维度中，每个维度的命中是独立判断还是组合判断？（例如仅「设备号命中」是否就足够判定强关联？还是需要「设备号 + 电话」同时命中？） | **P0** |\n| R-02 | 「强关联→直接进入高风险或黑名单链路」——这里的「直接」是指全自动化拦截无需人工确认？还是系统先拦截再人工审核？（涉及自动化力度） | **P0** |\n| R-03 | 弱关联的「观察期」多长？观察期过后是自动解除还是必须人工确认？观察期内用户继续参与互动如何处理？ | P1 |\n| R-04 | 风险判断中「IP 单独命中」列为弱关联——IP 从哪里获取？（JOYHUB APP？EDM 邮件头？客服系统？）不同来源的 IP 可靠性不同 | P1 |\n 127|\n### 5.2 双重退款（4 项）\n 129|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-05 | Amazon 退款数据如何获取？（SP-API 实时拉取？T+1 同步？手动导入 CSV？）同步频率决定检测时效 | **P0** |\n| R-06 | OA 返款系统是哪个？是否有 API？如果没有 API，返款记录怎么录入？（财务手动录入？CSV 导入？） | **P0** |\n| R-07 | 「双重退款」比对的关键字段是什么？（订单号？金额？用户？时间窗口？）匹配精度？（金额完全相等还是 ±X%？时间窗口多宽？） | P1 |\n| R-08 | 确认重复退款后，阻止后续返款——「阻止」是指系统自动拦截返款指令，还是只发告警让人工决定？ | P1 |\n 136|\n### 5.3 黑名单管理（3 项）\n 138|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-09 | 黑名单是否有过期/申诉/解除机制？（例如用户被误标后如何申诉？谁有权解除？） | P1 |\n| R-10 | 黑名单是否需要与外部系统同步？（例如 JOYHUB 的黑名单？Amazon 的欺诈标记？）同步方向？ | P1 |\n| R-11 | 黑名单的粒度——是标记「真实人」还是「某个维度的值」？（标记的是真实人 ID 还是具体的邮箱/设备？） | P1 |\n 144|\n### 5.4 风险可见性（3 项）\n 146|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-12 | 文档要求「客服、审核、退款等环节必须都能看到风险提醒」——风险提醒的展现形式是什么？（红色标签？弹窗？工单页顶部横幅？） | P1 |\n| R-13 | 风险状态的「提醒」通过什么通道发送？（audit 通知中心？IM 消息？系统内消息？） | P1 |\n| R-14 | 风险人员角色是否需要独立的风险控制台前端？该前端需要哪些功能？（事件列表/审核工作台/黑名单管理/统计报表？） | P2 |\n 152|\n### 5.5 高级风险检测能力（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-15 | 是否需要行为速度检测？（同一真实人短时间内大量注册/大量申请退款/大量提交评价→触发异常行为告警？） | P1 |\n| R-16 | 是否需要设备指纹/浏览器指纹？（识别同一设备换账号、模拟器、虚拟机等欺诈行为？） | P2 |\n| R-17 | 是否需要地理位置异常检测？（同一账号短期内从不同国家/城市登录→触发告警？） | P2 |\n| R-18 | 风险评分模型——是否需要一个综合风险分数（0-100）而非二元判断（强/弱/无）？评分模型的因子和权重？ | P1 |\n\n### 5.6 风险事件处理流程（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-19 | 风险事件的优先级（P0/P1/P2）如何定义？（双重退款确认→P0？单次弱关联→P2？）不同优先级的响应 SLA？ | P1 |\n| R-20 | 风险人员的工作台——是否需要「待审核队列」「审核中」「已处理」等看板视图？是否需要分配给具体审核人？ | P1 |\n| R-21 | 同一个人短时间内触发多次风险信号——是每次生成新事件还是合并到已有事件？合并规则？ | P1 |\n\n### 5.7 黑名单管理补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-22 | 黑名单的生效范围——加入黑名单后是「全系统拦截」还是「只拦截某些操作」？（是否还允许正常购买？只拦截测评参与？） | P1 |\n| R-23 | 黑名单是否需要分级？（一级黑名单→全拦截 / 二级黑名单→降频+人工审核 / 三级黑名单→仅标记提醒） | P1 |\n| R-24 | 黑名单是否需要与外部欺诈数据库同步？（如行业共享的欺诈黑名单？Amazon 的 abuse 标记？） | P2 |\n\n### 5.8 非 APP 用户风险盲区（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-25 | 文档已明确「非 APP 用户识别能力下降」——是否需要额外的风控措施？（例如非 APP 用户的返款额度降低？首次返款必须人工审核？） | P1 |\n| R-26 | 是否计划引导非 APP 用户注册 APP 以补全风险画像？（EDM/客服主动引导注册——注册转化跟踪？） | P2 |\n\n### 5.9 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-27 | 风险判断的实时性要求——每次互动时实时调用 risk API？（性能 overhead？需要缓存策略？） | P1 |\n| R-28 | 双重退款检测的时效——Amazon 退款数据（外部）同步延迟 vs OA 返款实时——T+N 的延迟是否可接受？ | P1 |\n| R-29 | 风险事件的数据保留策略？（已解决的诈骗案件数据保留多久？用于后续模型训练还是定期清理？） | P2 |", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/07-子系统-评价结果追踪", "type": "document", "name": "子系统 07 — 评价结果追踪 (`review`) v1.0", "filePath": "05_需求文档/07-子系统-评价结果追踪.md", "summary": "子系统 07 — 评价结果追踪 review v1.0 2 子系统概述 4 维度 说明 代号 review 核心职责 用户真实提交评价记录、Amazon 展示核验、ASIN 健康/计划完成度更新回流 数据所有权 review submission records , review display checks , review results 启动依赖 id", "tags": [ "05_需求文档", "需求文档" ], "complexity": "moderate", "knowledgeMeta": { "content": "# 子系统 07 — 评价结果追踪 (`review`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `review` |\n| 核心职责 | 用户真实提交评价记录、Amazon 展示核验、ASIN 健康/计划完成度更新回流 |\n| 数据所有权 | `review_submission_records`, `review_display_checks`, `review_results` |\n| 启动依赖 | identity / planning（软依赖） |\n| 外部系统依赖 | Amazon（评价展示状态、ASIN 评分数据） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ review 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 评价提交 │ │ M2: 展示核验 │ │ M3: 结果回流 │ │\n│ │ 记录 │→│ │→│ 引擎 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 异常观察 │ │ M5: 对外 API │ │\n│ │ 队列 │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | 评价提交记录 | 记录用户真实提交评价的事实（提交时点、提交证据、关联计划、关联 ASIN） |\n| M2 | 展示核验 | 核查 Amazon 是否展示该评价 / 是否可核验 |\n| M3 | 结果回流引擎 | 将评价结果反馈给 planning（计划完成度）、identity（用户标签）、audit |\n| M4 | 异常观察队列 | 用户已提交但 Amazon 未展示 / 暂不可核验的评价，进入定期复查队列 |\n| M5 | 对外 API Gateway | 供 outreach、planning 查询评价进度、提交评价 |\n 42|\n---\n 44|\n## 2. 各模块内外说明\n 46|\n### 2.1 M1: 评价提交记录\n 48|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 记录两个核心事实：①用户真实提交评价（时间、ASIN、评论内容/截图/链接、关联计划）；②提交后立即更新真实人累计评价额度（调用 quota 子系统 `commit`） |\n| **对外接口** | `POST /api/reviews/submission` — 记录评价提交 |\n| **数据写入** | `review_submission_records` |\n| **依赖** | `POST /api/quota/commit` — 确认额度占用（提交后立即计数12） |\n| **关键规则** | 「用户真实提交评价」和「Amazon 展示确认」是两个独立事实；额度计数按前者，计划完成按后者 |\n 56|\n### 2.2 M2: 展示核验\n 58|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 核查 Amazon 是否展示该评价 / 是否可核验；核验方式（待确认：爬取 / 手动 / API / 截图？）；核验结果：①展示或可核验→计入计划完成 ②未展示/暂不可核验→保留已提交事实→进入异常观察 |\n| **对外接口** | `POST /api/reviews/verify` — 触发核验（或定时核验） |\n| **数据写入** | `review_display_checks` |\n| **依赖** | Amazon（评价展示数据） |\n| **待确认** | 核验是自动还是人工？核验频率？ |\n 66|\n### 2.3 M3: 结果回流引擎\n 68|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 评价确认展示后：①通知 planning 更新计划完成度 ②通知 identity 更新用户标签（例如标记为「已回评用户」）③写入审计日志；免评结果回流：①更新 ASIN 健康与权重变化 ②更新计划完成度 ③通知 planning |\n| **对外接口** | 内部事件发布 |\n| **数据写入** | `review_results` |\n| **依赖** | `PUT /api/plans/{id}/status`（更新计划状态） |\n 75|\n### 2.4 M4: 异常观察队列\n 77|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 用户已提交但 Amazon 未展示/暂不可核验的评价，进入异常观察队列；定期复查（例如每天查一次 Amazon 是否已展示）；超过观察期仍未展示→标记异常→通知运营 |\n| **数据写入** | `review_display_checks`（更新状态） |\n| **待确认** | 观察周期多长？复查频率？观察期满后如何处理？ |\n 83|\n---\n 85|\n## 3. 对外 API 契约（草案）\n 87|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 记录评价提交 | `POST /api/reviews/submission` | `{person_id, asin, plan_id, evidence, submitted_at}` | `{submission_id, quota_updated}` | outreach（IM 核验后/客服确认后） |\n| 查询计划评价进度 | `GET /api/reviews/status/{plan_id}` | plan_id | `{total_submissions, verified, pending, completion_rate}` | planning |\n| 查询用户评价历史 | `GET /api/reviews/history/{person_id}` | person_id | `[{submission_id, asin, status, submitted_at}]` | identity（上下文卡） |\n| ASIN 评价统计 | `GET /api/reviews/asin-stats/{asin}` | asin | `{submission_count, verified_count, pending_count}` | planning |\n 94|\n---\n 96|\n## 4. 数据对象\n 98|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `review_submission_records` | submission_id, person_id, asin, plan_id, evidence_type, evidence, submitted_at, quota_updated | 评价提交记录（核心事实一） |\n| `review_display_checks` | check_id, submission_id, asin, check_method, check_result(DISPLAYED/NOT_DISPLAYED/UNVERIFIABLE), checked_at, retry_count, status(OBSERVING/CONFIRMED/ABNORMAL) | 展示核验记录（核心事实二） |\n| `review_results` | result_id, plan_id, asin, submission_count, verified_count, completion_rate, asin_health_change, updated_at | 评价结果汇总 |\n 104|\n---\n 106|\n## 5. 业务澄清问题清单 — review\n 108|\n### 5.1 评价提交记录（3 项）\n 110|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-01 | 「用户真实提交评价」的证据形式是什么？（用户上传的截图？Amazon 评论链接？系统自动检测？）不同形式如何验证真伪？ | **P0** |\n| V-02 | 一个用户为同一个 ASIN 提交多条评价（如果 Amazon 允许）——每一条都独立计入累计12额度吗？ | **P0** |\n| V-03 | 评价提交记录是 outreach（IM/客服）写入还是用户直接提交？（系统内提交 vs 系统外提交的区别）系统外提交如何登记？ | P1 |\n 116|\n### 5.2 展示核验（4 项）\n 118|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-04 | Amazon 评价展示的核验方式是？（定时爬取 Amazon 产品页？SP-API 拉取评价列表？用户上传截图人工审核？混合方式？） | **P0** |\n| V-05 | 如果通过爬取核验——爬取频率？（小时级？天级？）如何识别「哪条评价是本次计划用户提交的」？（靠评论者名字匹配？靠时间窗口？） | **P0** |\n| V-06 | 「暂不可核验」的常见原因有哪些？（Amazon 审核中/延迟展示/被 Amazon 删除？）每种原因的处理策略是否不同？ | P1 |\n| V-07 | 核验失败的兜底机制——如果 Amazon API 不可用或爬取失败，是否允许人工确认？ | P1 |\n 125|\n### 5.3 异常观察队列（2 项）\n 127|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-08 | 异常观察队列的观察期多长？（1 天？7 天？30 天？）复查频率？（每天？每周？）观察期满后未展示→如何处理？ | P1 |\n| V-09 | 多少条评价进入异常观察算异常阈值？（单计划 10% 未展示→通知？单用户多次未展示→标记？） | P2 |\n 132|\n### 5.4 结果回流（3 项）\n 134|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-10 | ASIN 健康「回流」的具体动作是什么？（更新 ASIN 评分/评价数到 planning？触发新一轮需求评估？更新 outreach 的触达策略？） | P1 |\n| V-11 | 计划完成度的计算方式——「评价确认展示」即算完成？还是需要确认展示 + 关联到本计划用户？（如何确保那条展示的评价确实是本计划用户的？） | P1 |\n| V-12 | 免评结果的「权重变化」如何量化？（Amazon 不直接提供权重数据——如何通过间接指标判断？） | P2 |\n 140|\n### 5.5 评价质量管理（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-13 | 是否需要评价内容分析？（好评/中评/差评？评价字数？是否含图片/视频？——这些影响评价质量评分？） | P2 |\n| V-14 | 差评检测和响应——用户提交了差评（1-2 星）是否需要自动触发售后工单？（「差评补救」流程？） | P1 |\n| V-15 | 虚假评价检测——用户提交的评价是否可能被 Amazon 判定为虚假评价并删除？（系统是否需要内部质量评分来预测被删风险？） | P2 |\n| V-16 | 评价的 ASIN 匹配校验——用户声称对 ASIN A 提交了评价但实际是对 ASIN B 提交的——如何检测和处理？ | P1 |\n\n### 5.6 异常观察队列补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-17 | 评价提交后 Amazon 展示的预期时间窗口？（通常 24-48h？最长多久？）超出预期窗口后的自动通知？ | P1 |\n| V-18 | Amazon 删除评价（违反社区准则）vs 用户删除评价 vs 评价被折叠——是否能区分？分别如何处理？ | P2 |\n| V-19 | 大量评价同时进入异常观察（例如 Amazon 评价系统故障导致全站延迟）——系统如何处理？（自动暂停观察队列？人工干预？） | P2 |\n\n### 5.7 ASIN 健康回流补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-20 | ASIN 健康更新的频率？（每次评价确认展示就更新？每天汇总更新一次？） | P2 |\n| V-21 | 如果多人同时对同一 ASIN 提交了评价，是否对 ASIN 健康有复合影响？（例如 5 条 5 星好评 vs 1 条 1 星差评——权重不同） | P2 |\n| V-22 | ASIN 健康数据的来源——是 Amazon 直接提供的数据还是系统内部计算？（Amazon 评分 vs 系统追踪到的评价评分可能有差异） | P1 |\n\n### 5.8 实施层面（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-23 | 评价展示核验如果是爬取 Amazon 页面——爬取频率和多 ASIN 并行爬取能力？（需要爬取几百个 ASIN 时的时间和资源开销） | P1 |\n| V-24 | 评价数据是否需要在系统间同步？（outreach 需要知道「用户已提交」→暂停触达；planning 需要知道「评价已确认」→更新计划完成度）数据一致性的保证？ | P1 |", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/08-子系统-KOC-KOL协作", "type": "document", "name": "子系统 08 — KOC/KOL 协作 (`creator`) v1.0", "filePath": "05_需求文档/08-子系统-KOC-KOL协作.md", "summary": "子系统 08 — KOC/KOL 协作 creator v1.0 2 子系统概述 4 维度 说明 代号 creator 核心职责 KOC/KOL 匹配筛选、内容 Brief/Code 分配、内容发布跟踪、带货结果跟踪、JOYCOLLAB 数据同步 数据所有权 exemption plan tasks , creator content records , c", "tags": [ "05_需求文档", "需求文档" ], "complexity": "moderate", "knowledgeMeta": { "content": "# 子系统 08 — KOC/KOL 协作 (`creator`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `creator` |\n| 核心职责 | KOC/KOL 匹配筛选、内容 Brief/Code 分配、内容发布跟踪、带货结果跟踪、JOYCOLLAB 数据同步 |\n| 数据所有权 | `exemption_plan_tasks`, `creator_content_records`, `creator_profiles`, `code_records` |\n| 启动依赖 | planning（软依赖，免评计划入口） |\n| 外部系统依赖 | JOYCOLLAB（KOC/KOL 数据、内容数据、Code 使用、带货订单） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ creator 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: KOC/KOL │ │ M2: 内容/Code│ │ M3: 结果跟踪 │ │\n│ │ 匹配筛选 │→│ 管理 │→│ │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: JOYCOLLAB│ │ M5: IM/EDM/ │ │ M6: 对外 API │ │\n│ │ 数据同步 │ │ APP 协同 │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | KOC/KOL 匹配筛选 | 按国家/平台/粉丝量/产品类目/历史效果筛选匹配合作对象；检查合作对象风险（历史纠纷/违约） |\n| M2 | 内容/Code 管理 | 分配内容 Brief、分配 Code、管理 Code 使用量、素材管理 |\n| M3 | 结果跟踪 | 跟踪内容发布状态、点击/跳转数据、Code 使用量、带货订单、转化销量、权重变化 |\n| M4 | JOYCOLLAB 数据同步 | 从 JOYCOLLAB 拉取 KOC/KOL 数据、内容数据、Code 使用、带货订单；同步失败告警 |\n| M5 | IM/EDM/APP 协同 | KOC 内容二次分发、免评 Code 触达站内用户、活动引流、结果通知 |\n| M6 | 对外 API Gateway | 供 planning、outreach、review 查询 |\n 43|\n---\n 45|\n## 2. 各模块内外说明\n 47|\n### 2.1 M1: KOC/KOL 匹配筛选\n 49|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 免评计划进入后：①按国家/平台/粉丝量/历史效果筛选 KOC/KOL ②按产品类目匹配专长 ③检查合作对象风险（历史纠纷/违约）→有风险记录时提示 |\n| **对外接口** | `GET /api/creators/match?plan_id=` — 获取匹配推荐列表 |\n| **数据写入** | `creator_profiles`（从 JOYCOLLAB 同步的 KOC/KOL 画像缓存） |\n| **待确认** | 匹配是完全自动推荐还是运营人工选择？推荐算法依赖哪些权重？ |\n 56|\n### 2.2 M2: 内容/Code 管理\n 58|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 分配内容 Brief（产品信息/要求/素材/发布时间）；Code 分配（每个 KOC 独立 Code 还是一对多？）；Code 使用量监控 |\n| **对外接口** | `POST /api/creators/tasks` — 创建协作任务（含 Brief + Code） |\n| **数据写入** | `exemption_plan_tasks`, `code_records` |\n| **待确认** | Code 是 JOYCOLLAB 生成还是 USER 系统生成？Code 是优惠码还是追踪码？ |\n 65|\n### 2.3 M3: 结果跟踪\n 67|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 跟踪 6 组结果：①内容发布状态/链接/互动数据 ②点击/跳转量 ③Code 使用量 ④带货订单数 ⑤转化销量 ⑥Listing 权重变化；执行评估：达标→结果回流 / 未达标→调整策略（更换KOC/调整素材/追加Code） |\n| **对外接口** | `GET /api/creators/results/{plan_id}` — 免评计划执行结果 |\n| **数据写入** | `creator_content_records` |\n| **依赖** | JOYCOLLAB 数据同步 |\n 74|\n### 2.4 M4: JOYCOLLAB 数据同步\n 76|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 从 JOYCOLLAB 同步：KOC/KOL 画像数据、内容发布数据、Code 使用数据、带货订单数据；同步记录（时间/成功/失败）；同步失败告警 |\n| **对外接口** | 内部定时任务 |\n| **数据写入** | 本地缓存表（`creator_profiles`, `creator_content_records`） |\n| **待确认** | 同步方向是单向（COLLAB→USER）还是双向？同步频率？ |\n 83|\n### 2.5 M5: IM/EDM/APP 协同\n 85|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 4 种协同动作：①KOC 内容二次分发（IM/APP 推送优质内容）②免评 Code 触达（IM/EDM 分发 Code 给站内用户）③活动引流（APP Push 引导用户进入 KOC 内容页）④结果通知（IM/APP 通知用户 Code 到账/订单确认） |\n| **对外接口** | 调用 outreach API：`POST /api/outreach/im/send` 等 |\n| **数据写入** | 协同记录 |\n 91|\n---\n 93|\n## 3. 对外 API 契约（草案）\n 95|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| KOC/KOL 匹配推荐 | `GET /api/creators/match?plan_id=` | plan_id | `[{creator_id, score, match_reason}]` | planner 前端 |\n| 创建协作任务 | `POST /api/creators/tasks` | `{creator_id, plan_id, brief, code, deadline}` | `{task_id}` | planner 前端 |\n| 免评执行结果 | `GET /api/creators/results/{plan_id}` | plan_id | `{content, clicks, codes, orders, sales, weight_change}` | review（结果回流）, planning |\n| KOC/KOL 画像查询 | `GET /api/creators/{creator_id}` | creator_id | KOC/KOL 完整画像 | planner 前端 |\n 102|\n---\n 104|\n## 4. 数据对象\n 106|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `exemption_plan_tasks` | task_id, plan_id, creator_id, brief, code, status, assigned_at, deadline | 免评计划协作任务 |\n| `creator_content_records` | record_id, task_id, creator_id, content_url, publish_time, engagement_data, synced_at | KOC 内容发布记录 |\n| `creator_profiles` | creator_id, name, platform, country, follower_count, category, historical_performance, risk_notes, synced_at | KOC/KOL 画像（从 JOYCOLLAB 同步的本地缓存） |\n| `code_records` | code_id, task_id, code_value, code_type, usage_count, usage_limit, status | Code 记录 |\n 113|\n---\n 115|\n## 5. 业务澄清问题清单 — creator\n 117|\n### 5.1 JOYCOLLAB 对接（4 项）\n 119|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-01 | JOYCOLLAB 中 KOC/KOL 的完整数据字段有哪些？（平台/粉丝量/国家/类目/历史合作效果/历史纠纷/违约——文档部分列出，需确认完整字段清单和 API 可用性） | **P0** |\n| K-02 | 数据同步方向是单向（COLLAB→USER）还是双向？（USER 分配的 Brief/Code 是否需要回写到 COLLAB？） | **P0** |\n| K-03 | 同步频率？（实时 Webhook？每小时？每天？）同步失败时谁来处理？重试策略？ | P1 |\n| K-04 | JOYCOLLAB 是否有现成 API？是 REST API 还是需要开发新的同步接口？ | P1 |\n 126|\n### 5.2 KOC/KOL 匹配（3 项）\n 128|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-05 | 匹配是运营人工选择还是系统自动推荐？推荐算法的权重？（粉丝量 vs 历史效果 vs 类目匹配 vs 报价？） | P1 |\n| K-06 | KOC/KOL 是否有评级/分层体系？（头部/腰部/尾部？）不同层级对应的计划类型是否不同？ | P1 |\n| K-07 | 「合作对象风险（历史纠纷/违约）」——风险数据从哪里来？（JOYCOLLAB？人工标记？）什么程度的风险需要拦截？ | P1 |\n 134|\n### 5.3 Code 与内容（3 项）\n 136|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-08 | Code 是 JOYCOLLAB 生成还是 USER 系统生成？Code 类型？（优惠码/追踪码/专属链接？）一对一还是可以多人共用？ | P1 |\n| K-09 | KOC 发布的内容是否需要审核？（Brief 交付后→KOC 创作→审核→发布？）审核流程在哪个系统？ | P2 |\n| K-10 | KOC 内容二次分发到 IM/APP——分发策略是什么？（所有优质内容都分发？按产品/地区筛选？） | P2 |\n 142|\n### 5.4 财务结算（2 项）\n 144|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-11 | KOC/KOL 的提成/返点结算在哪个系统执行？（JOYCOLLAB？财务系统？还是 USER 内触发结算指令？）USER 的责任边界？ | P1 |\n| K-12 | 结算数据（提成计算/返点核算/提款记录）是否需要同步到 USER？权限控制（财务数据独立权限）？ | P2 |\n 149|\n### 5.5 KOC/KOL 分层与定价（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-13 | KOC/KOL 是否有分层体系？（头部/腰部/尾部——按粉丝量划分？按历史带货效果划分？）不同分层的合作价格和权益？ | P1 |\n| K-14 | KOC/KOL 的报价/定价数据是否在系统中维护？（用于预算计算和 ROI 分析？） | P2 |\n| K-15 | KOC/KOL 是否有签约/合同管理？排他性协议？（签约期内只能推广本品牌产品？）排他性信息是否需要系统记录？ | P2 |\n\n### 5.6 内容与权益管理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-16 | KOC/KOL 发布内容的使用权和授权期限？（品牌是否可以二次使用、广告投放、修改？授权条款在系统中管理还是走线下合同？） | P2 |\n| K-17 | 内容审核流程——KOC/KOL 创作的内容是否需要品牌方审核后才能发布？（审核不通过→修改→重新审核的流程？） | P1 |\n| K-18 | 内容效果评估——除了点击/Code/订单数据外，是否需要评估内容质量？（互动率、完播率、正向评论比例？） | P2 |\n\n### 5.7 多平台 KOC/KOL 管理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-19 | KOC/KOL 涉及哪些平台？（YouTube / TikTok / Instagram / Facebook / 博客 / Amazon 站内 Influencer Program？）每个平台的数据来源？ | P1 |\n| K-20 | 同一 KOC/KOL 在多个平台有账号——是否在系统中关联为同一个人？（类似 identity 的归并逻辑？） | P2 |\n| K-21 | 不同平台的内容格式和指标不同（YouTube 视频 vs Instagram 帖子 vs TikTok 短视频）——结果跟踪如何统一？ | P2 |\n\n### 5.8 Code 管理补充（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-22 | Code 的类型？（一次性折扣码 / 多次使用码 / 追踪链接 / 专属落地页？）不同类型的生成和追踪逻辑？ | P1 |\n| K-23 | Code 的有效期管理？（计划结束后 Code 自动失效？还是保留一段时间？）Code 是否可重复使用？ | P1 |\n\n### 5.9 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-24 | JOYCOLLAB 数据同步失败时的降级策略？（用本地缓存数据？标记为「数据可能过期」？暂停新的协作任务？） | P1 |\n| K-25 | KOC/KOL 匹配算法的性能——如果 JOYCOLLAB 有几千个 KOC，匹配需要多少时间？是否有预筛选+精排的两阶段设计？ | P2 |\n| K-26 | KOC/KOL 的任务状态如何与 planning 的计划状态联动？（协作任务完成→计划完成度增加→计划状态更新？） | P1 |", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/09-子系统-审计与通知中心", "type": "document", "name": "子系统 09 — 审计与通知中心 (`audit`) v1.0", "filePath": "05_需求文档/09-子系统-审计与通知中心.md", "summary": "子系统 09 — 审计与通知中心 audit v1.0 2 子系统概述 4 维度 说明 代号 audit 核心职责 状态变更审计、敏感字段访问日志、多类型通知/告警 数据所有权 interaction audit logs , notification records , manual review tasks 启动依赖 无硬依赖，完全独立 外部系统依赖 通", "tags": [ "05_需求文档", "需求文档" ], "complexity": "moderate", "knowledgeMeta": { "content": "# 子系统 09 — 审计与通知中心 (`audit`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `audit` |\n| 核心职责 | 状态变更审计、敏感字段访问日志、多类型通知/告警 |\n| 数据所有权 | `interaction_audit_logs`, `notification_records`, `manual_review_tasks` |\n| 启动依赖 | 无硬依赖，完全独立 |\n| 外部系统依赖 | 通知可能通过 IM/EDM/APP Push 等通道（可复用 outreach 通道或独立） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ audit 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 状态变更 │ │ M2: 敏感操作 │ │ M3: 通知分发 │ │\n│ │ 审计 │ │ 审计 │ │ 引擎 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 通知模板 │ │ M5: 人工复核 │ │ M6: 对外 API │ │\n│ │ 管理 │ │ 任务 │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | 状态变更审计 | 记录所有业务对象的状态流转（对象ID/旧状态/新状态/操作人/时间/原因） |\n| M2 | 敏感操作审计 | 敏感字段访问记录、数据导出记录、人工复核操作留痕 |\n| M3 | 通知分发引擎 | 按通知类型路由到不同通道（系统内通知/IM/EDM/APP Push）；通知优先级管理 |\n| M4 | 通知模板管理 | 各类通知的模板（额度预警/Listing 预警/超时提醒/审批通知/风险告警） |\n| M5 | 人工复核任务 | 管理需要人工复核的任务（弱关联风险/额度预警池/异常评价），供风险/运营人员消费 |\n| M6 | 对外 API Gateway | 接收所有子系统上报的审计事件和通知请求 |\n 43|\n---\n 45|\n## 2. 各模块内外说明\n 47|\n### 2.1 M1: 状态变更审计\n 49|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 接收所有子系统的状态变更事件（fire-and-forget）；记录：对象类型（plan/ticket/risk_case/review…）、对象ID、旧状态、新状态、操作人、操作时间、操作原因；审计日志不可篡改（append-only）；支持按对象ID/操作人/时间范围检索 |\n| **对外接口** | `POST /api/audit/event` — 上报审计事件 |\n| **数据写入** | `interaction_audit_logs` |\n| **典型事件** | 计划状态变更（草稿→审批→执行→完成）、工单分配/关闭、风险事件确认/排除、额度手动调整、审批决策 |\n 56|\n### 2.2 M2: 敏感操作审计\n 58|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 三类敏感操作：①敏感字段访问（用户上下文卡中的涉密字段→记录访问人/时间/字段/上下文）②数据导出操作（导出人/时间/范围/原因/是否含敏感字段）③人工复核操作（决策人/决策内容/决策依据/时间） |\n| **对外接口** | `POST /api/audit/sensitive-access` — 上报敏感访问 |\n| **数据写入** | `interaction_audit_logs`（带 sensitivity 标记） |\n 64|\n### 2.3 M3: 通知分发引擎\n 66|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 接收通知请求→按通知类型路由：①系统内通知（Web 前端轮询/WebSocket）②IM 通知（通过 outreach）③EDM 通知 ④APP Push；优先级管理（紧急 Listing 预警 > 超时提醒 > 额度预警）；通知去重（同一用户同一类型短时间内不重复发） |\n| **对外接口** | `POST /api/notifications/send` — 发送通知 |\n| **依赖** | outreach（IM/EDM/APP Push 通道） |\n 72|\n### 2.4 M4: 通知模板管理\n 74|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 通知类型与模板：①额度预警（「真实人 X 的测评额度仅剩 1 次」）②紧急 Listing 预警（「ASIN X 评分接近 4.2，建议紧急催评」）③客服超时提醒（「工单 #123 已超时 N 小时未回复」）④审批通知（「计划 X 等待您的审批」）⑤规则风控提醒（「ASIN X 频控过高」）⑥风险告警（「用户 X 命中强关联风险」） |\n| **对外接口** | 管理 API |\n| **数据写入** | `notification_records` |\n| **待确认** | 模板是否需要多语言（中文/英文/菲律宾语）？模板管理界面在 audit 内部还是独立？ |\n 81|\n### 2.5 M5: 人工复核任务\n 83|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 统一管理需人工复核的任务：弱关联风险复核、额度预警池复核、异常评价复核、诈骗疑似复核；任务分配/认领/完成/超时 |\n| **对外接口** | `POST /api/audit/review-task` — 创建复核任务；`GET /api/audit/review-tasks?assignee=` — 查询待复核任务 |\n| **数据写入** | `manual_review_tasks` |\n 89|\n---\n 91|\n## 3. 对外 API 契约（草案）\n 93|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 上报审计事件 | `POST /api/audit/event` | `{object_type, object_id, old_status, new_status, operator, reason}` | `{event_id}` | 所有子系统（状态变更时调用） |\n| 上报敏感访问 | `POST /api/audit/sensitive-access` | `{operator, field, context, accessed_at}` | `{event_id}` | identity（上下文卡访问） |\n| 发送通知 | `POST /api/notifications/send` | `{recipient, type, template_id, params}` | `{notification_id}` | 所有子系统 |\n| 创建复核任务 | `POST /api/audit/review-task` | `{task_type, target_id, priority, description}` | `{task_id}` | risk, quota |\n 100|\n---\n 102|\n## 4. 数据对象\n 104|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `interaction_audit_logs` | log_id, object_type, object_id, old_status, new_status, operator, operation, reason, sensitivity_level, logged_at | 审计日志（append-only） |\n| `notification_records` | notification_id, recipient, type, template_id, channel, sent_at, status(SENT/DELIVERED/READ/FAILED) | 通知记录 |\n| `manual_review_tasks` | task_id, task_type, target_id, status(PENDING/ASSIGNED/IN_REVIEW/RESOLVED/TIMEOUT), assignee, priority, created_at, resolved_at | 人工复核任务 |\n 110|\n---\n 112|\n## 5. 业务澄清问题清单 — audit\n 114|\n### 5.1 审计范围与保留（4 项）\n 116|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-01 | 审计日志的保留策略？（保留多久？1 年？永久？到期后归档还是删除？） | **P0** |\n| A-02 | 审计日志的存储量预估？（日产生多少条？是否需要分库分表/冷热分离？） | P1 |\n| A-03 | 审计日志是否需要支持导出/报表？（合规审计时需要导出给外部审计？） | P1 |\n| A-04 | 「敏感字段」的定义范围？（订单号、收款信息、设备号——还有哪些？谁来确定完整清单？） | **P0** |\n 123|\n### 5.2 通知策略（4 项）\n 125|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-05 | 通知发送通道的优先级？（紧急告警用什么通道？IM？系统内通知？邮件？） | P1 |\n| A-06 | 通知去重规则？（同一用户同一类型通知 N 分钟内不重复发？） | P1 |\n| A-07 | 通知是否需要用户偏好设置？（用户可以选择不接收某类通知？公告类通知是否强制发送？） | P2 |\n| A-08 | 通知模板是否需要多语言支持？（中文/英文/菲律宾语？）模板由谁来维护？ | P2 |\n 132|\n### 5.3 人工复核任务（2 项）\n 134|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-09 | 人工复核任务的时效要求？（不同任务类型 SLA？弱关联风险 N 小时内复核？额度预警池 N 分钟内复核？） | P1 |\n| A-10 | 复核任务超时后的升级机制？（自动分配给上级？通知主管？） | P2 |\n 139|\n### 5.4 与其他子系统的协作（2 项）\n 141|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-11 | 通知通道是否完全复用 outreach？（IM/EDM/APP Push）还是 audit 独立对接通知通道？（如果 outreach 不可用，audit 仍需要能发告警） | P1 |\n| A-12 | 审计事件是同步上报还是异步？（同步→影响业务链路性能 / 异步→可能丢失事件） | P1 |\n 146|\n### 5.5 合规与认证（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-13 | 系统是否需要通过合规认证？（SOC2 Type II / ISO 27001？）认证对审计日志的完整性、不可篡改性、保留期限有何具体要求？ | P1 |\n| A-14 | 数据导出请求（DSR）——用户或监管机构要求导出所有个人数据时，系统如何响应？（需要哪些子系统的数据？导出格式？响应时限？） | P1 |\n| A-15 | 审计日志是否需要对第三方审计开放？（外部审计师需要查看审计日志时——权限控制和数据脱敏？） | P2 |\n\n### 5.6 日志保留与归档（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-16 | 审计日志的分级保留策略？（状态变更日志保留 X 年 / 敏感访问日志保留 Y 年 / 通知记录保留 Z 月？） | P1 |\n| A-17 | 日志归档方案？（超过保留期的日志是删除还是归档到冷存储？归档后是否仍可检索？） | P2 |\n| A-18 | 日志存储量预估？（日产生日志条数 × 保留天数 = 需要的存储空间——是否需要分库分表/分区？） | P2 |\n\n### 5.7 敏感数据脱敏（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-19 | 审计日志中是否允许记录敏感字段的明文？（例如「谁在何时查看了用户 X 的收款信息」——收款信息是否脱敏存储？） | P1 |\n| A-20 | 日志查询权限——谁可以查审计日志？（管理员？审计员？）是否需要限制只能查自己相关的日志？ | P1 |\n| A-21 | 生产环境的日志是否可以包含 PII（个人可识别信息）？（邮箱/电话/地址——是否在写入日志时自动脱敏？） | P1 |\n\n### 5.8 通知可靠性（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-22 | 通知的可靠性保证——紧急告警（如 Listing 评分暴跌）是否需要确保送达？（有送达确认机制吗？发送失败后重试？） | P1 |\n| A-23 | 通知通道的优先级切换——IM 通知失败后是否自动切换到 EDM 或系统通知？ | P2 |\n| A-24 | 通知的聚合/摘要——同一个用户短时间收到多条同类通知是否合并？（「您有 3 个待审批计划」而不是 3 条独立通知） | P2 |\n\n### 5.9 实施层面（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-25 | 审计事件是同步写入还是异步写入？（同步→影响业务链路 RT / 异步→可能丢失事件——如何取舍？） | P1 |\n| A-26 | 审计日志的查询性能——是否需要支持全文搜索？（按操作人/对象ID/时间范围检索是否需要在秒级返回？） | P2 |\n| A-27 | 通知通道的可靠性——如果 audit 子系统本身宕机，其他子系统的通知请求是否丢失？（是否需要消息队列做缓冲？） | P1 |\n| A-28 | audit 子系统是否需要独立的数据库？（与其他子系统共享数据库会在高峰期互相影响——是否独立部署数据库？） | P2 |", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7", "type": "document", "name": "USER 后台 ERP MVP · 管理员总览原型 v7", "filePath": "05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7.html", "summary": "USER 后台 ERP MVP · 管理员总览原型 v7 U USER 后台 ERP MVP 一期 v7 · 模拟数据 待办提醒 21 重要事项 3 审核类 4 紧急 Listing 7 问题总结 9 经营总览 系统管理员 · 最高权限 · 全部部门 搜索 至 日 周 月 全部部门 Amazon 运营 用户运营 客服 系统管理员（最高权限） Amazon 运", "tags": [ "05_需求文档", "需求文档" ], "complexity": "complex", "knowledgeMeta": { "content": "\n\n\n \n \n USER 后台 ERP MVP · 管理员总览原型 v7\n \n\n\n
\n \n\n
\n
\n
\n
\n 经营总览\n 系统管理员 · 最高权限 · 全部部门\n
\n
\n 搜索\n \n
\n
\n
\n
\n \n 至\n \n
\n
\n \n \n \n
\n \n \n \n
\n
\n\n
\n
\n
\n\n
\n \n\n
\n
\n
\n

操作确认

\n \n
\n
\n
\n
\n\n
\n\n \n\n\n", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", "type": "document", "name": "USER 评价业务闭环 — 共用能力图与渠道专属流程 v2.2", "filePath": "05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md", "summary": "USER 评价业务闭环 — 共用能力图与渠道专属流程 v2.2 文件信息 文件名称： 20260517 USER评价业务闭环 共用能力图与渠道专属流程 v2.2.md 项目路径： C:\\XCODE\\USER 当前版本： v2.2 最近更新： 2026 05 17 上游基线： 工作基线 v1.2 20260517 USER评价业务闭环主流程与后续工作基线 v1", "tags": [ "05_需求文档", "需求文档" ], "complexity": "complex", "knowledgeMeta": { "content": "# USER 评价业务闭环 — 共用能力图与渠道专属流程 v2.2\n\n## 文件信息\n\n- 文件名称：`20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`\n- 项目路径：`C:\\XCODE\\USER`\n- 当前版本：`v2.2`\n- 最近更新：`2026-05-17`\n- 上游基线：[工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md)\n- 前一版本：\n - `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v1.1.md`\n - `20260517_USER评价业务闭环点击操作模拟_v2.1.md`\n- 文件目的：在基线 v1.2 确认的额度规则和真实人体系上，拆出系统级共用能力图与 IM / EDM / APP / TEL / 客服 / KOC-KOL 六条渠道的专属执行流程，每个节点标注 查 / 写 / 状态 / 提醒 / 拦截。\n- 资料依据：IM 推送业务流脑图、电话业务流程知识库、客服相关模块、后台回评工作流对接事项、状态机 v4、页面设计 v4、原型 HTML。\n- 使用方式：先读基线 v1.2，再读本文件；第三步数据流设计直接引用本文件的节点规则表和数据对象建议。本文件取代 `v1.1` 与 `v2.1` 作为当前第二步主稿。\n\n---\n\n### 1. 总览\n\n```mermaid\nflowchart LR\n A[\"销售 / ASIN数据形成\"] --> B[\"需求触发\"]\n B --> C[\"用户运营评估\"]\n C --> D{\"计划类型\"}\n D --> E[\"评价型计划
推新 / 回评\"]\n D --> F[\"免评计划\"]\n E --> G[\"执行拆解\"]\n F --> G\n G --> SHARED[\"共用能力层\"]\n SHARED --> I1[\"IM\"]\n SHARED --> I2[\"EDM\"]\n SHARED --> I3[\"APP\"]\n SHARED --> I4[\"TEL\"]\n SHARED --> I5[\"客服\"]\n SHARED --> I6[\"KOC / KOL\"]\n I1 & I2 & I3 & I4 & I5 --> J[\"用户互动 / 服务 / 跟进\"]\n J --> K[\"用户真实提交评价\"]\n K --> L[\"计入累计评价额度（12）\"]\n L --> M[\"Amazon展示确认\"]\n M --> N[\"ASIN / 计划 / 用户 / 风险结果回流\"]\n I6 --> O[\"免评结果跟踪\"]\n O --> N\n N --> C\n\n style SHARED fill:#f5f5f5,stroke:#333,stroke-width:3px\n```\n\n#### 节点审查标准\n\n每个关键节点按以下 8 问审：\n\n| ## | 问题 | 标注 |\n| --- | --- | --- |\n| 1 | 入口是什么 | 触发条件 |\n| 2 | 先查什么 | **查** |\n| 3 | 判断什么 | 分岔条件 |\n| 4 | 写什么 | **写** |\n| 5 | 状态怎么变 | **状态** |\n| 6 | 何时提醒 | **提醒** |\n| 7 | 何时拦截 | **拦截** |\n| 8 | 何时转人工 | **转人工** |\n\n---\n\n## 第一部分：共用能力图\n\n### 2. 共用能力一：真实人识别与用户上下文卡\n\n#### 2.1 流程图\n\n```mermaid\nflowchart TB\n A[\"新互动 / 新订单 / 新任务\"] --> B[\"读取身份线索\"]\n B --> B1[\"JOYHUB ID\"]\n B --> B2[\"邮箱\"]\n B --> B3[\"电话\"]\n B --> B4[\"设备号\"]\n B --> B5[\"订单号\"]\n B --> B6[\"姓名 + 地址\"]\n\n B1 & B2 & B3 & B4 & B5 & B6 --> C[\"归并真实人\"]\n C --> D{\"匹配结果\"}\n D -->|\"标准化姓名+地址一致\"| E[\"强关联 → 同一真实人\"]\n D -->|\"地址一致姓名不同\"| F[\"家庭/关联风险 → 不直接合并\"]\n D -->|\"多线索交叉\"| G[\"按设备/电话/邮箱/收款信息权重合并\"]\n\n E & F & G --> H[\"生成 / 更新真实人 ID\"]\n H --> I[\"拉取用户上下文卡\"]\n\n I --> J[\"历史交易
订单/购买/退款/返款/ASIN\"]\n I --> K[\"历史服务
工单/聊天/电话/承诺/提醒\"]\n I --> L[\"历史风险
黑名单/诈骗/关联/异常\"]\n I --> M[\"当前设备
型号/版本/换机记录\"]\n I --> N[\"触达历史
IM/EDM/APP/TEL 近期记录\"]\n\n J & K & L & M & N --> O[\"上下文卡快照 → 供客服/运营/风险使用\"]\n```\n\n#### 2.2 用户上下文卡字段组\n\n| 字段组 | 具体内容 |\n| --- | --- |\n| 当前身份 | JOYHUB ID、邮箱、电话、当前订单、真实人 ID |\n| 真实人归并 | 姓名+地址（标准化）、设备号、电话、邮箱、Profile ID、收款信息、关联账号列表 |\n| 历史交易 | 历史订单、购买频次、最近购买、历史退款、历史返款、目标 ASIN 购买记录 |\n| 历史服务 | 历史工单、聊天记录、通话记录、已承诺事项、已发送提醒、工单关闭原因 |\n| 历史风险 | 黑名单标记、强关联记录、弱关联记录、疑似诈骗、双重退款、异常订单 |\n| 当前设备 | 设备号摘要、设备型号/类型、系统版本、APP 版本、最近设备变化（换机/多设备） |\n| 触达历史 | IM 最近触达/回复/退订、EDM 最近打开/点击/退订、APP 最近 Push、TEL 最近拨打 |\n\n#### 2.3 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 归并真实人 | JOYHUB、邮箱、电话、设备、订单、地址 | 真实人匹配结果、匹配证据、置信度 | 新真实人 / 已存在 | 标准化姓名+地址一致时强提示 | - |\n| 拉取上下文卡 | 交易、工单、风险、设备、触达全量记录 | 上下文快照（含快照时间） | 首次生成 / 增量更新 | 命中黑名单/异常时高亮 | 严重风险标记时阻止自动通过 |\n| 设备变化识别 | 设备号、型号、系统版本、APP版本 | 设备变化记录、变化时间 | 设备正常 / 近期换机 / 多设备 | 近期换机或同设备多账号提示 | - |\n\n---\n\n### 3. 共用能力二：人群生成与画像拆解\n\n#### 3.1 流程图\n\n```mermaid\nflowchart TB\n A[\"计划进入人群生成\"] --> B[\"基础过滤\"]\n B --> B1[\"硬排除：国家/站点/可达性/退订/黑名单/未关闭工单\"]\n\n B1 --> C[\"画像匹配\"]\n C --> C1[\"基础画像：国家/语言/性别/年龄段/注册时间\"]\n C --> C2[\"产品关系：绑定玩具/绑定数量/绑定品类/目标产品\"]\n C --> C3[\"交易画像：历史订单/购买频次/是否买过目标ASIN\"]\n C --> C4[\"行为画像：活跃度/打开率/点击率/历史回评率/配合率\"]\n C --> C5[\"触达画像：各渠道可达性/最近触达/退订\"]\n C --> C6[\"风险画像：黑名单/设备关联/地址关联/退款异常\"]\n C --> C7[\"计划画像：是否参加过推新/回评/免评/最近结果\"]\n\n C1 & C2 & C3 & C4 & C5 & C6 & C7 --> D[\"历史行为评分\"]\n\n D --> E[\"额度与频控校验
（进入 §4 共用能力三）\"]\n E --> F[\"风险复检
（进入 §6 共用能力五）\"]\n F --> G[\"生成候选人群快照 + 排除快照\"]\n```\n\n#### 3.2 画像字段的三类用途\n\n| 类型 | 作用 | 示例字段 |\n| --- | --- | --- |\n| **硬过滤** | 决定能不能进池 | 国家、可达性、黑名单、退订、未关闭工单、额度超限 |\n| **匹配条件** | 决定是否适合当前计划 | 绑定玩具、目标品类、年龄、性别、是否买过目标 ASIN |\n| **排序权重** | 决定触达优先级 | 活跃度、历史回评率、历史配合率、最近互动时间 |\n\n#### 3.3 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 基础过滤 | 国家、站点、可达性、退订、黑名单、未关闭工单 | 排除原因记录 | 入池 / 排除 | - | 黑名单/退订/强关联直接排除 |\n| 画像匹配 | 7 组画像字段 | 匹配分组与得分 | 匹配 / 不匹配 / 待补全 | 画像缺失可补全 | - |\n| 历史行为评分 | 活跃、点击、回复、回评率、配合率、投诉 | 评分结果、排序权重 | 高分 / 中分 / 低分 | 低活跃用户降级提醒 | - |\n| 生成快照 | 过滤、匹配、评分、额度、风险全量结果 | 人群快照、排除快照、快照时间 | 已生成 | 排除比例异常时提醒 | 快照为空时拦截 |\n\n---\n\n### 4. 共用能力三：额度台账与频控控制\n\n#### 4.1 已确认额度规则\n\n| 规则 | 统计对象 | 计数口径 | 计数时点 |\n| --- | --- | --- | --- |\n| 每月测评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 | - |\n| 每月免评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 | - |\n| 累计真实提交评价最多 12 个 | 真实人 | 用户真实提交评价后立即计数 | 用户真实提交评价时 |\n\n#### 4.2 流程图\n\n```mermaid\nflowchart TB\n A[\"识别真实人\"] --> B[\"读取额度台账\"]\n B --> B1[\"本月测评：已完成 / 进行中 / 已预占\"]\n B --> B2[\"本月免评：已完成 / 进行中 / 已预占\"]\n B --> B3[\"累计真实提交：当前 / 上限 12\"]\n B --> B4[\"并发占用：跨计划重复入选检测\"]\n\n B1 & B2 & B3 & B4 --> C{\"额度判断\"}\n C -->|\"剩余 ≥ 本次拟发送\"| D[\"进入普通候选池
→ 预占额度\"]\n C -->|\"剩余不足但 > 0\"| E[\"进入预警池
→ 预占额度 → 发送前人工复核\"]\n C -->|\"已用 + 预占 + 本次 ≥ 上限\"| F[\"排除自动推送\"]\n\n D --> G[\"写入预占记录\"]\n E --> G\n\n G --> H[\"频控复核\"]\n H --> H1[\"渠道频控：IM/EDM/APP/TEL 最近触达间隔\"]\n H --> H2[\"单 ASIN 短期触达次数\"]\n H --> H3[\"用户反感度/投诉/退订状态\"]\n\n H1 & H2 & H3 --> I{\"频控判断\"}\n I -->|通过| J[\"进入发送队列\"]\n I -->|不通过| K[\"延后 / 降频 / 排除\"]\n\n J --> L[\"发送前再次读取最新额度 + 风险\"]\n L --> M{\"最终校验\"}\n M -->|通过| N[\"发送\"]\n M -->|新增超限/风险| O[\"撤出本批次\"]\n```\n\n#### 4.3 额度 vs 频控的区别\n\n| 类别 | 统计维度 | 周期 | 拦截时机 |\n| --- | --- | --- | --- |\n| **渠道频控** | 单渠道触达次数/间隔 | 按日/周/月 | 发送前 |\n| **月度业务额度** | 真实人测评 4 / 免评 4 | 自然月 | 人群生成 + 发送前 |\n| **累计评价额度** | 真实人累计 12 | 永久累计 | 用户提交评价时更新、下次人群生成时判断 |\n| **并发占用控制** | 进行中 + 已预占 + 跨计划重复 | 实时 | 人群生成 + 预占时 |\n\n#### 4.4 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 读取额度台账 | 本月测评/免评、累计提交、进行中、已预占 | 当前额度快照 | - | 剩余 ≤ 1 或本批次将打满时预警 | - |\n| 预占额度 | 候选计划、预计发送量、当前剩余 | 额度预占记录 | 已预占 | - | 预计超限阻止进入自动发送 |\n| 频控复核 | IM/EDM/APP/TEL 最近触达、ASIN频次、退订/投诉 | 频控校验结果 | 通过 / 降频 / 排除 | 接近频控上限时提醒 | 超频直接排除 |\n| 发送前终校 | 最新额度、最新风险、最新未关闭工单 | 发送前校验结果 | 准入 / 撤出 | 任何新增异常立即提示 | 新增超限/风险撤出本批次 |\n\n---\n\n### 5. 共用能力四：每次有效互动复检\n\n#### 5.1 流程图\n\n```mermaid\nflowchart TB\n A[\"触发复检的事件\"] --> A1[\"主动推送后回复\"]\n A --> A2[\"再次联系\"]\n A --> A3[\"补充订单号\"]\n A --> A4[\"客服回访\"]\n A --> A5[\"电话来电\"]\n A --> A6[\"退款/返款/继续推送前\"]\n\n A1 & A2 & A3 & A4 & A5 & A6 --> X[\"重新读取四组数据\"]\n\n X --> X1[\"身份：真实人/JOYHUB/邮箱/电话/设备/订单/地址\"]\n X --> X2[\"历史：订单/工单/触达/退款/返款\"]\n X --> X3[\"额度：本月测评/免评/累计提交/进行中/预占\"]\n X --> X4[\"风险：黑名单/强弱关联/双重退款/异常订单\"]\n\n X1 & X2 & X3 & X4 --> Y{\"判断结果\"}\n Y -->|正常 + 额度充足| Z[\"继续业务\"]\n Y -->|弱风险 / 接近额度上限| W[\"继续但显著提示 → 人工关注\"]\n Y -->|强风险 / 额度超限| V[\"暂停当前动作 → 转风险中心或人工复核\"]\n```\n\n#### 5.2 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 身份复检 | JOYHUB、邮箱、电话、设备、订单、地址是否变化 | 身份变化记录 | 未变 / 新增关联 / 冲突 | 设备变化/地址变化提示 | - |\n| 历史复检 | 是否有新订单、新工单、新触达、新退款 | 历史变化记录 | 无变化 / 有更新 | 新退款/新工单提示 | - |\n| 额度复检 | 最新测评/免评/累计额度 | 最新额度快照 | 充足 / 预警 / 超限 | 接近上限预警 | 超限拦截 |\n| 风险复检 | 黑名单、强弱关联、双重退款、异常 | 最新风险结果 | 正常 / 弱风险 / 强风险 | 任何命中高亮提醒 | 强关联暂停自动操作 |\n\n---\n\n### 6. 共用能力五：风险判断与黑名单\n\n#### 6.1 风险分层\n\n| 风险类型 | 关联项 | 处理原则 |\n| --- | --- | --- |\n| **强关联** | 邮箱、设备号、电话、收件人姓名+地址、订单号、聊天记录、Profile ID、收款信息 | 一旦命中，直接进入高风险或黑名单链路 |\n| **弱关联** | IP 单独命中、姓名单独命中、同址异名 | 进入高风险观察 + 人工复核，不直接认定诈骗 |\n\n#### 6.2 流程图\n\n```mermaid\nflowchart TB\n A[\"风险信号进入
（新订单同步/触达回应/用户接入/退款申请/再次跟进）\"] --> B[\"强弱关联判断\"]\n\n B --> C{\"关联等级\"}\n C -->|强关联| D[\"高风险 / 黑名单链路\"]\n C -->|弱关联| E[\"高风险观察 + 人工复核\"]\n C -->|无关联| F[\"正常继续\"]\n\n D --> D1[\"拦截继续推送\"]\n D --> D2[\"拦截自动退款\"]\n D --> D3[\"拦截自动放行\"]\n D1 & D2 & D3 --> G[\"回写工单 / 推送 / 计划状态\"]\n G --> H[\"提醒客服 / 用户运营 / 审核人员\"]\n\n E --> E1[\"显著风险提醒\"]\n E1 --> E2[\"人工复核\"]\n E2 --> E3{\"复核结论\"}\n E3 -->|确认风险| D\n E3 -->|排除风险| F\n```\n\n#### 6.3 已确认业务问题\n\n1. **双重退款**：APP/OA 已退款 + 用户又向 Amazon 申请退款 → 需要 Amazon 退款与 OA 返款自动比对\n2. **高风险用户**：一旦标记，支付/返款需要人工复核\n3. **风险可见性**：客服、审核、退款等环节必须都能看到风险提醒\n4. **非 APP 用户盲区**：直接走邮件退款，缺设备/注册邮箱等维度，识别能力下降\n5. **每次互动重判**：风险判断不是一次性的，每次有效互动都要重新执行\n\n#### 6.4 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 强弱关联判断 | 邮箱/设备/电话/地址/订单/ProfileID/收款信息/IP | 关联结果、命中维度列表 | 强关联 / 弱关联 / 无 | 命中时高亮命中维度 | - |\n| 高风险链路 | 当前推送/退款/返款状态 | 风险事件、拦截记录 | 已拦截 / 待复核 | 通知所有关联环节 | 拦截继续推送/自动退款/自动放行 |\n| 双重退款检测 | Amazon退款记录 + OA返款记录 | 匹配结果、差异 | 无重复 / 疑似重复 / 确认重复 | 确认重复时强告警 | 确认重复时阻止后续返款 |\n\n---\n\n### 7. 共用能力六：审批工作流\n\n```mermaid\nflowchart LR\n PLAN[\"计划草案\"] --> R1{\"计划类型\"}\n R1 -->|测评计划| A1[\"Amazon运营总监审批\"]\n R1 -->|回评计划| A2[\"Amazon运营总监或指定负责人\"]\n R1 -->|免评计划| A3[\"Amazon运营总监 + 用户负责人\"]\n R1 -->|紧急计划| A4[\"Amazon运营负责人 + 用户负责人 + 主管\"]\n\n A1 & A2 & A3 & A4 --> NEXT[\"周/月推送计划\"]\n NEXT --> N1[\"用户负责人审批\"]\n N1 --> N2[\"渠道负责人审批\"]\n N2 --> APPROVED[\"已批准 → 执行\"]\n```\n\n#### 7.1 审批节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| Amazon运营总监审批 | 计划详情、ASIN健康、风险提醒 | 审批结果、审批意见 | 通过 / 驳回 / 待补充 | 驳回时通知提交人 | - |\n| 用户负责人审批 | 人群快照、额度占用、频控结果 | 审批结果 | 通过 / 驳回 | 额度接近上限时预警 | - |\n| 渠道负责人审批 | 渠道容量、素材、合规 | 审批结果 | 通过 / 驳回 | 素材/文案风险提醒 | 合规风险时拦截 |\n\n---\n\n### 8. 共用能力七：审计与通知中心\n\n| 模块 | 职责 | 关键记录内容 |\n| --- | --- | --- |\n| 状态变更审计 | 所有业务对象的状态流转留痕 | 对象ID、旧状态、新状态、操作人、时间、原因 |\n| 敏感字段访问 | 涉密字段的每次读取记录 | 访问人、访问时间、访问字段、访问上下文 |\n| 导出操作 | 所有数据导出行为留痕 | 导出人、时间、范围、原因、是否含敏感字段 |\n| 人工复核操作 | 所有人工干预决策留痕 | 决策人、决策内容、决策依据、决策时间 |\n| **规则风控提醒** | 触发规则/审核/风控阈值时通知 | 同一ASIN频控过高、同一用户多次推送、设备/邮箱异常、站点任务过密 |\n| **紧急Listing预警** | 评分接近4.2时通知 | ASIN、当前评分、差评摘要、建议动作 |\n| **客服超时提醒** | 工单/答应配合超时通知 | 工单ID、超时类型、超时时长、责任人 |\n| **额度预警** | 额度接近上限时通知 | 真实人、额度类型、已用/上限、受影响计划 |\n\n---\n\n## 第二部分：渠道专属流程图\n\n### 9. 渠道一：IM 推送专属流程\n\n#### 9.1 用户分层与推送策略\n\n```mermaid\nflowchart TB\n U[\"用户注册 + 绑定玩具\"] --> L1{\"识别用户分层\"}\n\n L1 -->|\"A 未参与过
从未走过回评/测评\"| A1[\"推送前校验\"]\n A1 --> A1a[\"查：JOYHUB ID、设备ID、黑名单、绑定产品\"]\n A1 --> A1b{\"设备ID在黑名单？\"}\n A1b -->|是| A2[\"写：打标'长期测评人'
拦截：不推回评/测评卡片
推送：免评产品卡片\"]\n A1b -->|否| A3[\"推送：对应绑定产品的回评卡片
写：推送记录\"]\n\n L1 -->|\"B 已参与过
真实人累计真实提交评价 < 12\"| B1[\"优先催评\"]\n B1 --> B1a[\"查：未回评测评单、真实人累计评价数、标签\"]\n B1 --> B1b[\"推送：催评卡片/消息\"]\n B1b --> B2{\"完成好评提交？\"}\n B2 -->|是| B3[\"写：重新计算真实人累计评价数\"]\n B3 --> B4{\"累计真实提交评价仍 < 12？\"}\n B4 -->|是| B5[\"推送：当日测评计划对应卡片
写：二次转化记录\"]\n B4 -->|否| B6[\"写：打标'长期测评人'→ 推送免评产品\"]\n\n L1 -->|\"C 长期测评人
真实人累计真实提交评价 ≥ 12\"| C1[\"拦截：不推送普通回评/测评卡片
推送：当日免评补单产品
写：免评推送记录\"]\n\n style A2 fill:#fce4ec\n style C1 fill:#fff3e0\n```\n\n#### 9.2 IM 用户提交后的核验与流转\n\n```mermaid\nflowchart TB\n SUBMIT[\"入口：用户在IM中提交回评/测评信息\"] --> ITEMS[\"提交内容：订单号 + 返款账号 + 评论截图/链接\"]\n\n ITEMS --> AUTO[\"查：当前用户标签、关联计划
写：系统自动登记提交记录
状态：待核验\"]\n\n AUTO --> VERIFY[\"订单号核实\"]\n VERIFY --> V1{\"查：是否测评单？\"}\n VERIFY --> V2{\"查：是否为公司产品？\"}\n VERIFY --> V3{\"查：单号格式 xxx-xxxxxxx-xxxxxxx？\"}\n\n V1 & V2 & V3 -->|全部通过| PASS[\"写：登记进系统
状态：已登记\"]\n V1 & V2 & V3 -->|任一不通过| CS[\"转人工：推送客服
状态：待客服处理\"]\n\n CS --> CS1[\"客服沟通用户 → 补充/修正信息\"]\n CS1 --> CS2[\"写：修正记录 → 回到核验\"]\n\n PASS --> CHECK{\"信息完整？\"}\n CHECK -->|完整| FINANCE[\"写：推送财务返款提醒
状态：待返款\"]\n CHECK -->|缺返款账号| TAG1[\"写：打标'xx产品待返款'
提醒：自动通知用户补充
状态：信息待补全\"]\n CHECK -->|缺评论截图/链接| TAG2[\"写：打标'xx产品待回评'
提醒：自动通知用户补充
状态：信息待补全\"]\n\n FINANCE --> PAY[\"查：付款凭证
写：自动推送返款/礼品卡通知
状态：已返款\"]\n PAY --> DONE[\"状态：回评流程走完\"]\n DONE --> TAG3[\"写：打标'xx产品已回评用户'
推送：测评卡片（二次转化）\"]\n\n style SUBMIT fill:#e8f5e9\n style PASS fill:#c8e6c9\n style CS fill:#fff3e0\n style DONE fill:#e3f2fd\n```\n\n#### 9.3 IM 新测评流程\n\n```mermaid\nflowchart TB\n START[\"入口：用户收到测评卡片 → 提交测评信息\"] --> VFY[\"查：订单号是否撤销、是否退款
查：真实人月度测评额度与累计真实提交评价\"]\n\n VFY -->|\"额度允许 + 订单有效\"| REG[\"写：登记进系统
写：打标'xx产品测评单登记'
状态：已登记\"]\n\n REG --> INFO{\"信息完整？\"}\n INFO -->|只有订单号
缺返款账号+截图| TAG_A[\"写：打标'xx产品测评待返款'
提醒：自动通知用户
状态：待补全\"]\n INFO -->|只有截图+链接
缺订单号+返款账号| TAG_B[\"写：打标'xx产品测评单待回评'
提醒：自动通知用户
状态：待补全\"]\n INFO -->|完整| COMP[\"状态：测评流程走完\"]\n\n COMP --> RECALC[\"查：重新计算 review 数量
写：review 数量更新\"]\n RECALC -->|\"累计真实提交评价 ≥ 12\"| LC[\"写：打标'长期测评人'
推送：免评产品卡片\"]\n RECALC -->|\"≤ 12 review\"| NEXT[\"推送：当日测评计划对应卡片
写：二次转化记录\"]\n\n style COMP fill:#c8e6c9\n style LC fill:#fff3e0\n```\n\n#### 9.4 IM 核心标签汇总\n\n| 分类 | 标签 | 触发时机 | 后续动作 |\n| --- | --- | --- | --- |\n| **用户层级** | 未参与过用户 (A) | 注册+绑定后首次识别 | 推送回评卡片 |\n| | 参与过用户 (B) | 已有回评/测评记录，review < 12 | 优先催评 → 二次转化 |\n| | 长期测评人 (C) | review > 12 | 仅推送免评产品 |\n| **回评流程** | xx产品已回评用户 | 回评流程走完 | 推送测评卡片 |\n| | xx产品待回评用户 | 缺截图/链接 | 自动通知补全 |\n| | xx产品待返款 | 缺返款账号 | 自动通知补全 |\n| **测评流程** | xx产品测评单登记 | 订单核实通过 | 继续信息补全 |\n| | xx产品测评待返款用户 | 测评缺返款 | 自动通知补全 |\n| | xx产品测评单待回评 | 测评缺截图 | 自动通知补全 |\n| | xx产品测评单 | 测评流程走完 | review重算 |\n| **免评流程** | xx产品的免评 | 长期测评人参与免评单 | 不再推回评/测评 |\n\n#### 9.5 IM 推送动作与流转动作\n\n| 动作类型 | 动作 | 说明 |\n| --- | --- | --- |\n| **推送** | 回评卡片 | A类用户首次推送 |\n| | 测评卡片 | B类二次转化 / A类设备在黑名单 |\n| | 免评产品卡片 | C类用户 / 黑名单命中用户 |\n| | 催评消息 | B类优先催评 / 紧急催评 |\n| | 返款/礼品卡通知 | 财务有凭证后推送 |\n| **流转** | 推送客服 | 订单号不符合 / 异常 |\n| | 推送财务 | 订单登记完成后 |\n| | 自动打标 | 各流程节点完成时 |\n| | 二次转化 | 回评完成 → 推送测评卡片 |\n\n---\n\n### 10. 渠道二：EDM 邮件推送专属流程\n\n#### 10.1 流程图\n\n```mermaid\nflowchart TB\n START[\"入口：计划已批准，进入EDM执行拆解\"] --> POOL[\"筛选EDM目标用户池\"]\n\n POOL --> COND{\"查：用户条件\"}\n COND -->|\"非APP用户\"| NON[\"进入EDM队列\"]\n COND -->|\"APP低活跃\"| LOW[\"查：IM频控通过后进入EDM队列\"]\n COND -->|\"APP活跃\"| SKIP[\"拦截：跳过EDM，走IM/APP\"]\n\n NON --> PRECHK[\"推送前检查\"]\n LOW --> PRECHK\n\n PRECHK --> C1[\"查：身份——是否有有效邮箱\"]\n PRECHK --> C2[\"查：风险——邮箱是否命中黑名单\"]\n PRECHK --> C3[\"查：退订——是否已退订/硬退信\"]\n PRECHK --> C4[\"查：资格——OA是否有资格\"]\n PRECHK --> C5[\"查：国家——站点与邮箱类型匹配\"]\n\n C1 & C2 & C3 & C4 & C5 -->|全部通过| BEHAVIOR[\"行为筛选\"]\n C1 & C2 & C3 & C4 & C5 -->|任一不通过| EXCLUDE[\"写：排除原因
拦截：不发送\"]\n\n BEHAVIOR --> B1[\"查：最近打开时间、总打开次数\"]\n BEHAVIOR --> B2[\"查：最近3/5次是否连续0打开\"]\n BEHAVIOR --> B3[\"查：最近回复时间、回复后又发送数\"]\n BEHAVIOR --> B4[\"查：是否点击评论链接但未回复\"]\n BEHAVIOR --> B5[\"查：单月收信次数、各邮件类型发送次数\"]\n\n B1 & B2 & B3 & B4 & B5 --> RHYTHM{\"节奏判断\"}\n RHYTHM -->|适合触达| SEND[\"发送EDM
写：发送记录
状态：已发送\"]\n RHYTHM -->|需降频| DELAY[\"写：延后标记
状态：观察中\"]\n RHYTHM -->|不适合| SWITCH[\"切换其他渠道或排除\"]\n\n SEND --> TRACK[\"追踪回收\"]\n TRACK --> T1[\"送达 → 写：送达时间\"]\n T1 --> T2[\"打开 → 写：打开时间、打开次数+1\"]\n T2 --> T3[\"点击 → 写：点击时间、点击目标\"]\n T3 --> T4[\"跳转至APP下载页/产品页\"]\n T4 --> RESULT{\"用户行为\"}\n RESULT -->|\"下载并注册APP\"| TO_IM[\"写：用户渠道升级
后续走IM主流程\"]\n RESULT -->|\"直接回复邮件\"| TO_CS[\"写：生成客服工单
走客服执行流程\"]\n RESULT -->|\"未响应\"| RETRY[\"写：进入再触达队列
（遵循频控间隔）\"]\n RESULT -->|\"退订\"| UNSUB[\"写：退订标记
拦截：该渠道永久排除\"]\n\n SEND --> METRICS[\"写：EDM指标
发送数/送达率/打开率/点击率/回复率/转化数/退订数\"]\n\n style EXCLUDE fill:#fce4ec\n style UNSUB fill:#fce4ec\n style TO_IM fill:#e3f2fd\n style TO_CS fill:#fff3e0\n```\n\n#### 10.2 EDM 专属行为指标\n\n| 字段组 | 具体指标 | 用途 |\n| --- | --- | --- |\n| **打开行为** | 最近打开时间、总打开次数、最近3/5次0打开 | 判断活跃度 → 决定是否继续发 |\n| **回复行为** | 最近回复时间、回复后又发送封数 | 判断兴趣度 → 决定触达节奏 |\n| **点击行为** | 是否点击评论链接、点击后未回复时长 | 判断意向 → 决定是否追加触达 |\n| **触达频率** | 单月收信次数、各邮件类型发送次数 | 频控 → 防止疲劳 |\n| **邮件属性** | 邮件类型、邮箱后缀标签、国家站点 | 匹配 → 确定发送内容 |\n| **排除项** | 风险用户、黑名单、退订、硬退信、OA无资格 | 硬过滤 → 不进池 |\n\n#### 10.3 EDM vs IM 关键差异\n\n| 维度 | IM | EDM |\n| --- | --- | --- |\n| 用户身份强度 | 强（JOYHUB ID + 设备 + 订单绑定） | 弱（仅邮箱，可能无JOYHUB ID） |\n| 风险识别能力 | 高（多维度交叉） | 低（缺设备/注册邮箱等维度） |\n| 转化路径 | 直接提交 → 核验 → 返款 | 引导注册APP → 再进入IM链路 |\n| 退订机制 | 社区屏蔽/消息免打扰 | 邮件退订链接 + 硬退信 |\n| 频控周期 | 按日/按类目 | 按周/按月 |\n| 行为信号 | 绑定/活跃/点击/回复/标签 | 打开/点击/回复/退订/连续0打开 |\n\n---\n\n### 11. 渠道三：APP Push 专属流程\n\n#### 11.1 流程图\n\n```mermaid\nflowchart TB\n START[\"触发源\"] --> T1[\"用户绑定新玩具\"]\n START --> T2[\"用户长期未活跃（7天+）\"]\n START --> T3[\"测评/回评计划到期\"]\n START --> T4[\"Listing健康紧急\"]\n START --> T5[\"活动/促销通知\"]\n\n T1 & T2 & T3 & T4 & T5 --> FILTER[\"查：共用能力过滤\"]\n\n FILTER --> F1[\"查：身份——JOYHUB ID + 设备在线\"]\n FILTER --> F2[\"查：风险——黑名单 + 关联检测\"]\n FILTER --> F3[\"查：频控——当日Push次数 + 用户通知设置\"]\n FILTER --> F4[\"查：标签——匹配推送策略\"]\n\n F1 & F2 & F3 & F4 -->|通过| PUSH[\"发送APP Push
写：推送记录
状态：已发送\"]\n F1 & F2 & F3 & F4 -->|不通过| SKIP[\"写：跳过原因
状态：已跳过\"]\n\n PUSH --> USER{\"用户响应\"}\n USER -->|\"点击打开\"| IN_APP[\"进入APP → 落地页\"]\n USER -->|\"忽略/关闭\"| NOOP[\"写：曝光记录
拦截：短期内不重复推\"]\n USER -->|\"卸载/禁用通知\"| UNINSTALL[\"写：不可再推送标记
降级：转入EDM候选池\"]\n\n IN_APP --> ACT{\"APP内动作\"}\n ACT -->|\"提交回评/测评\"| IM_FLOW[\"走IM提交核验流程（§9.2）\"]\n ACT -->|\"联系客服\"| CS_FLOW[\"生成客服工单（§12）\"]\n ACT -->|\"仅浏览\"| TAG[\"写：记录行为，更新活跃标签\"]\n\n style IN_APP fill:#e3f2fd\n style UNINSTALL fill:#fce4ec\n```\n\n#### 11.2 APP Push 与 IM 的分工\n\n| 场景 | 用 APP Push | 用 IM |\n| --- | --- | --- |\n| 新绑定玩具 → 引导测评 | - | 推送回评/测评卡片 |\n| 用户7天未活跃 | 推送召回通知 | - |\n| 测评计划到期提醒 | - | 推送催评消息 |\n| Listing 紧急 | 推送紧急通知 | 推送紧急催评卡片 |\n| 返款已到账 | 推送到账通知 | - |\n| 活动/促销 | 推送活动通知 | - |\n\n#### 11.3 APP 必查字段\n\n| 字段组 | 内容 |\n| --- | --- |\n| 用户资料 | 注册邮箱、JOYHUB ID、国家、语言 |\n| 设备上下文 | 设备号、设备型号/类型、APP版本、系统版本 |\n| 产品关系 | 绑定玩具、绑定时间、目标产品关系 |\n| 行为数据 | 活跃、打开、点击、回复、站内浏览、广告互动 |\n\n---\n\n### 12. 渠道四：TEL 电话专属流程\n\n#### 12.1 流程图\n\n```mermaid\nflowchart TB\n START[\"触发电话任务\"] --> S1[\"用户答应配合但超时未提交\"]\n START --> S2[\"高价值用户需深度跟进\"]\n START --> S3[\"复杂售后无法文字解决\"]\n START --> S4[\"IM/EDM多次触达无响应\"]\n START --> S5[\"紧急Listing需人工沟通\"]\n START --> S6[\"Amazon页面/说明书来电\"]\n START --> S7[\"计划生成的外呼任务\"]\n\n S1 & S2 & S3 & S4 & S5 & S6 & S7 --> TICKET[\"写：生成电话类客服工单
状态：待分配\"]\n\n TICKET --> PREPARE[\"拨打前准备（必须）\"]\n PREPARE --> P1[\"查：用户完整画像
（身份/订单/历史/标签/风险）\"]\n PREPARE --> P2[\"查：风险状态
拦截：强关联命中 → 暂停拨打 → 先复核\"]\n PREPARE --> P3[\"查：历史沟通记录
（避免重复询问）\"]\n PREPARE --> P4[\"写：准备话术和问题清单\"]\n\n P1 & P2 & P3 & P4 --> CONTACT[\"客服电话联系用户
写：拨打记录
状态：处理中\"]\n\n CONTACT --> RESULT{\"通话结果\"}\n RESULT -->|\"接通-售后问题\"| AFTERSALE[\"先解决售后
查：订单/产品/凭证
写：处理方案
状态：售后处理中\"]\n RESULT -->|\"接通-直接配合\"| COOP[\"确认评价提交时间
写：登记答应配合
状态：答应配合\"]\n RESULT -->|\"接通-拒绝\"| REJECT[\"写：记录拒绝原因
状态：已关闭\"]\n RESULT -->|\"接通-疑似诈骗\"| FRAUD[\"创建诈骗事件
写：诈骗记录
转风险链路（§6）\"]\n RESULT -->|\"未接通\"| RETRY[\"写：拨打次数+1
提醒：安排重试\"]\n\n AFTERSALE --> SAT{\"是否解决/满意？\"}\n SAT -->|是| INVITE[\"引导回评/邀请测评\"]\n SAT -->|否| ESCALATE[\"升级处理 → 转组长/负责人\"]\n\n INVITE --> FOLLOW[\"写：进入答应配合跟进
状态：待提醒\"]\n COOP --> FOLLOW\n FOLLOW --> UPDATE[\"写：更新工单 + 用户标签\"]\n\n RETRY --> DECIDE{\"重试策略\"}\n DECIDE -->|\"< 3次\"| CONTACT\n DECIDE -->|\"≥ 3次未接通\"| DOWNGRADE[\"写：降级至EDM/放弃
状态：待关闭\"]\n\n CONTACT --> RECORD[\"写：通话记录
来电时间/来源/联系方式/订单号
问题类型/描述/处理方案
是否解决/是否邀请测评/用户是否接受\"]\n\n style CONTACT fill:#fff3e0,stroke:#ef6c00\n style FRAUD fill:#fce4ec,stroke:#c62828\n style AFTERSALE fill:#e3f2fd\n```\n\n#### 12.2 TEL 必填记录字段\n\n| 类别 | 字段 | 涉密 |\n| --- | --- | --- |\n| 来电基础 | 来电时间、来源（Amazon页/说明书/外呼）、客服、联系方式 | - |\n| 订单信息 | Amazon订单号、产品型号/款式/颜色、购买时间 | 订单号涉密 |\n| 问题信息 | 问题类型、问题描述、图片/视频凭证 | - |\n| 处理信息 | 处理方案、是否解决、是否需要后续跟进 | - |\n| 评价相关 | 是否邀请回评/测评、用户是否接受、是否涉及差评 | - |\n| 拨打统计 | 拨打次数、通话时长、接通状态 | - |\n\n---\n\n### 13. 渠道五：客服工单执行流程\n\n#### 13.1 流程图\n\n```mermaid\nflowchart TB\n A[\"入口：用户消息 / 推送转人工 / 电话后续 / 风险触发\"] --> B[\"写：生成工单
状态：待分配\"]\n\n B --> C[\"查：班次、在线状态、当前负载、最大工单数
写：自动分配到客服组
状态：已分配\"]\n\n C --> D[\"客服组长分派到组员
状态：处理中\"]\n\n D --> E[\"查：展示用户上下文卡
（身份/历史/风险/设备/触达）\"]\n\n E --> F[\"客服开始处理\"]\n\n F --> G{\"处理结果\"}\n G -->|\"等待用户回复\"| H[\"状态：等待用户
提醒：超时提醒机制\"]\n G -->|\"等待内部协同\"| I[\"状态：等待内部
提醒：超时升级\"]\n G -->|\"用户答应配合\"| J[\"写：生成跟进任务
状态：答应配合
进入答应配合状态机\"]\n G -->|\"疑似诈骗\"| K[\"写：诈骗疑似标记
提醒：组长/负责人复核
转风险链路（§6）\"]\n G -->|\"问题已解决\"| L[\"写：解决记录
状态：已解决\"]\n\n H --> F\n I --> F\n\n J --> M[\"提醒/再联系/等待提交\"]\n M --> N[\"用户提交评价或反馈
状态：已提交评价/已提交反馈\"]\n\n K --> P[\"组长/负责人复核\"]\n P --> Q{\"复核结论\"}\n Q -->|确认诈骗| R[\"转风险链路 → 同步黑名单\"]\n Q -->|退回继续处理| F\n\n L --> S[\"写：关闭工单
状态：已关闭\"]\n```\n\n#### 13.2 三套并行状态\n\n| 状态体系 | 典型状态 | 说明 |\n| --- | --- | --- |\n| **工单状态** | 待分配 → 已分配 → 处理中 → 等待用户/等待内部 → 已解决 / 疑似诈骗 → 已关闭 | 工单生命周期 |\n| **答应配合状态** | 已答应配合 → 待分配负责人 → 待提醒 → 等待提交 → 已提交评价/已提交反馈 → 超时 → 需再次联系 → 已关闭 | 防止承诺用户流失 |\n| **风险状态** | 无异常 → 弱关联高风险 → 强关联高风险 → 疑似诈骗 → 已确认诈骗 → 已同步黑名单 | 风险独立跟踪 |\n\n---\n\n### 14. 客服管理支撑流程\n\n#### 14.1 流程图\n\n```mermaid\nflowchart LR\n A[\"排班设置\"] --> B[\"在线客服池\"]\n C[\"出勤记录\"] --> B\n B --> D[\"工单自动分配
查：在线状态/排班/当前负载/最大工单数\"]\n D --> E[\"回复效率统计\"]\n D --> F[\"转化统计\"]\n F --> G[\"目标完成统计\"]\n E --> H[\"主管看板\"]\n F --> H\n G --> H\n```\n\n#### 14.2 管理指标\n\n| 模块 | 指标 |\n| --- | --- |\n| **出勤** | 应出勤、实际出勤、出勤率、迟到、早退、请假、缺勤 |\n| **回复效率** | 回复用户数、处理工单数、发送消息数、首次回复时长（平均/中位数/最大/最小） |\n| **转化** | RSO回评登记订单数、RDO测评登记订单数、获取评价数、评价完成率 |\n| **目标** | 月目标、当前完成、完成率、历史趋势 |\n\n---\n\n### 15. 评价完成流程\n\n#### 15.1 流程图\n\n```mermaid\nflowchart TB\n A[\"用户提交评价\"] --> B[\"写：记录真实提交事实
状态：已提交待核验\"]\n B --> C[\"写：更新真实人累计评价额度（+1）
提醒：接近12时预警\"]\n\n C --> D{\"查：Amazon是否展示 / 是否可核验\"}\n D -->|\"展示或可核验\"| E[\"写：计入计划完成
状态：已确认展示\"]\n D -->|\"未展示 / 暂不可核验\"| F[\"写：保留已提交事实
状态：未展示待观察\"]\n\n E --> G[\"写：更新ASIN健康与计划完成度\"]\n F --> H[\"进入异常观察队列
提醒：定期复查\"]\n\n G --> I[\"结果回流：更新经营层数据\"]\n```\n\n#### 15.2 必须拆开的两个事实\n\n| 事实 | 是否计入累计12额度 | 是否计入计划完成 | 计数时点 |\n| --- | --- | --- | --- |\n| 用户真实提交评价 | **是** | 还不一定 | 提交时立即计数 |\n| Amazon 展示确认 | 已在上一步计过 | **是** | 展示确认时 |\n\n---\n\n### 16. 渠道六：KOC/KOL 协作专属流程（免评核心通道）\n\n#### 16.1 流程图\n\n```mermaid\nflowchart TB\n START[\"入口：免评计划 / 推新计划已批准\"] --> PLAN[\"查：计划参数
写：拆解KOC/KOL执行方案\"]\n\n PLAN --> STEP1[\"匹配合作对象\"]\n STEP1 --> S1A[\"查：按国家/平台/粉丝量/历史效果筛选\"]\n STEP1 --> S1B[\"查：按产品类目匹配KOC/KOL专长\"]\n STEP1 --> S1C[\"查：合作对象风险（历史纠纷/违约）
提醒：有风险记录时提示\"]\n\n S1A & S1B & S1C --> STEP2[\"写：分配Code/素材/内容Brief\"]\n STEP2 --> STEP3[\"KOC/KOL内容发布\"]\n\n STEP3 --> TRACK[\"跟踪执行结果\"]\n TRACK --> T1[\"查：内容发布链接\"]\n TRACK --> T2[\"查：点击/跳转数据\"]\n TRACK --> T3[\"查：Code使用量\"]\n TRACK --> T4[\"查：带货订单\"]\n TRACK --> T5[\"查：转化销量\"]\n TRACK --> T6[\"查：Listing权重变化\"]\n\n T1 & T2 & T3 & T4 & T5 & T6 --> SYNC[\"从JOYCOLLAB同步数据至USER
写：同步记录
提醒：同步失败时告警\"]\n\n SYNC --> EVAL{\"执行评估\"}\n EVAL -->|\"达标\"| DONE[\"写：结果回流
更新ASIN健康/计划完成度
状态：已完成\"]\n EVAL -->|\"未达标\"| ADJUST[\"调整策略
写：调整记录
更换KOC/调整素材/追加Code\"]\n\n SYNC --> FINANCE[\"财务侧
查：提成计算/返点核算/提款记录
提醒：财务数据独立权限\"]\n```\n\n#### 16.2 KOC/KOL 与评价型渠道的本质差异\n\n| 维度 | 评价型（IM/EDM/APP/TEL） | KOC/KOL |\n| --- | --- | --- |\n| 执行主体 | 系统 + 客服 | 外部KOC/KOL + 运营协同 |\n| 终点 | 用户提交评价 | 内容发布/Code使用/带货销量/权重 |\n| 用户关系 | 平台 ↔ 买家 | 品牌 ↔ 达人 ↔ 达人粉丝 |\n| 数据源 | USER系统内部 | JOYCOLLAB同步 |\n| 财务 | 返款（固定金额） | 提成+返点（按效果） |\n| 风险关注 | 诈骗/双重退款 | 合作纠纷/违约/虚假流量 |\n\n#### 16.3 IM/EDM/APP 在免评中的协同角色\n\n| 协同动作 | 渠道 | 说明 |\n| --- | --- | --- |\n| KOC内容二次分发 | IM/APP | 将KOC发布的优质内容推送给站内用户 |\n| 免评Code触达 | IM/EDM | 将免评Code分发给符合条件的站内用户 |\n| 活动引流 | APP Push | 推送活动通知引导用户进入KOC内容页 |\n| 结果通知 | IM/APP | 通知用户Code到账、订单确认 |\n\n#### 16.4 免评核心结果组\n\n| 结果组 | 跟踪内容 |\n| --- | --- |\n| 内容 | 发布状态、链接、发布时间、互动数据 |\n| 引流 | 点击量、跳转量、Code使用量 |\n| 成交 | 订单数、转化量、销量 |\n| 经营 | 权重变化、ASIN健康变化、品牌搜索变化 |\n\n---\n\n### 17. 店铺紧急催评流程（IM渠道专属子流程）\n\n```mermaid\nflowchart TB\n TRIGGER[\"触发条件
查：店铺当日掉评/差评/需紧急拿好评稳评分
状态：紧急触发\"] --> CALC[\"计算推送量
目标好评数 ÷ 2% = 需触达用户数
写：推送方案\"]\n\n CALC --> EXEC[\"执行\"]\n EXEC --> E1[\"查：筛选可触达用户
写：推送紧急催评消息\"]\n EXEC --> E2[\"查：优先触达高完成率用户\"]\n EXEC --> E3[\"查：持续跟踪回评提交状态\"]\n\n E1 & E2 & E3 --> RESULT{\"结果\"}\n RESULT -->|\"已提交好评\"| R1[\"写：更新已回评/测评完成
状态：已完成\"]\n RESULT -->|\"未提交\"| R2[\"写：保留在待催评池
状态：待催评\"]\n RESULT -->|\"异常\"| R3[\"转人工：推送客服跟进
状态：转客服\"]\n\n style TRIGGER fill:#fce4ec,stroke:#c62828\n```\n\n---\n\n## 第三部分：渠道交叉与协同规则\n\n### 18. 渠道优先级路由\n\n```mermaid\nflowchart LR\n USER_IN[\"同一个用户\"] --> D1{\"查：用户状态\"}\n D1 -->|\"APP注册 + 活跃 + 已绑定\"| IM[\"IM 优先\"]\n D1 -->|\"APP注册 + 低活跃\"| APP_PUSH[\"APP Push优先 + IM补充\"]\n D1 -->|\"未注册APP\"| EDM[\"EDM优先 → 引导注册后转IM\"]\n D1 -->|\"高价值 + 多次无响应\"| TEL[\"TEL人工\"]\n D1 -->|\"长期测评人（C类）\"| IM_FREE[\"IM免评卡片 + KOC/KOL协同\"]\n\n style IM fill:#e3f2fd\n style EDM fill:#fff3e0\n style TEL fill:#fce4ec\n```\n\n### 19. 渠道间去重规则\n\n| 规则 | 说明 |\n| --- | --- |\n| 同一计划同一用户 | 不重复通过多渠道路由，优先走最高优先级渠道 |\n| 用户已在客服工单中 | 暂停自动触达，等待工单关闭后再判断 |\n| 用户已提交评价（待核验） | 所有渠道暂停催评，等待核验结果 |\n| 用户已退订某渠道 | 该渠道永久排除，不影响其他渠道 |\n| 用户命中强关联风险 | **所有渠道暂停自动触达**，进入人工复核 |\n| 用户命中弱关联风险 | 降频 + 提示后继续，但需人工关注 |\n\n### 20. 用户状态 × 渠道可用性矩阵\n\n| 用户状态 | IM | EDM | APP Push | TEL | KOC/KOL |\n| --- | --- | --- | --- | --- | --- |\n| APP活跃 + 已绑定 | **首选** | 不送 | 补充 | - | - |\n| APP活跃 + 未绑定 | 引导绑定 | - | 活动通知 | - | - |\n| APP低活跃 | 降频 | 补充 | **召回** | - | - |\n| 未注册APP | - | **首选** | - | 高价值时 | - |\n| 已答应配合 | 提醒 | - | 到期提醒 | **超时拨打** | - |\n| 长期测评人 (C) | **仅免评** | - | - | - | 可协同 |\n| 黑名单/强关联 | **全暂停** | **全暂停** | **全暂停** | **需复核** | **暂停** |\n| 弱关联风险 | 降频+提示 | 降频+提示 | 降频+提示 | 提示后执行 | 提示 |\n| 累计接近12 | 预警+人工 | 预警+人工 | 预警+人工 | 可正常服务；涉及普通测评邀请时需人工复核 | - |\n| 累计已满12 | 仅免评 | 仅免评 | 仅免评 | 可正常服务；不得绕过普通测评限制 | 可协同 |\n\n---\n\n## 第四部分：第三步数据对象建议\n\n### 21. 第三步建议优先产出的数据对象\n\n| 优先级 | 对象 | 来源能力/渠道 |\n| --- | --- | --- |\n| **P0** | `person_profiles`（真实人） | §2 真实人识别 |\n| **P0** | `person_identity_links`（身份关联） | §2 真实人识别 |\n| **P0** | `contact_context_snapshots`（用户上下文快照） | §2 用户上下文卡 |\n| **P0** | `person_quota_ledgers`（额度台账） | §4 额度台账 |\n| **P0** | `quota_reservations`（额度预占） | §4 额度台账 |\n| **P0** | `risk_signals`（风险信号） | §6 风险判断 |\n| **P0** | `risk_cases`（风险事件） | §6 风险判断 |\n| **P0** | `blacklist_entities`（黑名单实体） | §6 风险判断 |\n| **P0** | `audience_snapshots`（人群快照） | §3 人群生成 |\n| **P0** | `audience_exclusions`（人群排除记录） | §3 人群生成 |\n| **P0** | `channel_route_decisions`（渠道路由决策） | §18 渠道优先级 |\n| **P0** | `channel_dedup_records`（渠道去重记录） | §19 渠道间去重 |\n| **P1** | `im_interaction_records`（IM交互记录） | §9 IM |\n| **P1** | `im_flow_tags`（IM流程标签） | §9 IM |\n| **P1** | `edm_message_events`（EDM事件） | §10 EDM |\n| **P1** | `edm_user_behavior_profiles`（EDM用户行为画像） | §10 EDM |\n| **P1** | `app_touch_events`（APP触达事件） | §11 APP |\n| **P1** | `tel_call_records`（TEL通话记录） | §12 TEL |\n| **P1** | `support_tickets`（客服工单） | §13 客服 |\n| **P1** | `support_followups`（答应配合跟进） | §13 客服 |\n| **P1** | `support_assignment_logs`（工单分配日志） | §13 客服 |\n| **P1** | `review_submission_records`（评价提交记录） | §15 评价完成 |\n| **P1** | `review_display_checks`（评价展示核验） | §15 评价完成 |\n| **P1** | `exemption_plan_tasks`（免评计划任务） | §16 KOC/KOL |\n| **P1** | `creator_content_records`（KOC内容记录） | §16 KOC/KOL |\n| **P1** | `amazon_refund_records`（Amazon退款记录） | §6 双重退款 |\n| **P1** | `oa_refund_records`（OA返款记录） | §6 双重退款 |\n| **P1** | `refund_match_results`（退款比对结果） | §6 双重退款 |\n| **P2** | `attendance_records`（出勤记录） | §14 客服管理 |\n| **P2** | `shift_schedules`（排班表） | §14 客服管理 |\n| **P2** | `support_goal_records`（客服目标） | §14 客服管理 |\n| **P2** | `support_performance_snapshots`（绩效快照） | §14 客服管理 |\n| **P2** | `interaction_audit_logs`（互动审计日志） | §8 审计 |\n| **P2** | `manual_review_tasks`（人工复核任务） | §5/§6 复检与风险 |\n\n---\n\n### 22. 与基线 v1.2 的关系\n\n本文件是基线 v1.2 的下游细化产物：\n\n| 基线 v1.2 章节 | 本文件对应 |\n| --- | --- |\n| §6.1 主动触达支线 | §9 IM、§10 EDM、§11 APP Push |\n| §6.2 免评执行支线 | §16 KOC/KOL + §16.3 协同角色 |\n| §6.3 被动售后与TEL支线 | §12 TEL |\n| §6.4 风险/诈骗拦截支线 | §6 风险判断与黑名单 |\n| §6.5 客服工单与客服管理支线 | §13 客服工单、§14 客服管理 |\n| §7 真实人识别、用户上下文与额度规则 | §2 真实人识别、§4 额度台账 |\n| §8 渠道专属补充事实 | §9-§16 各渠道专属流程 |\n| §11 第二步新入口 | 本文件整体 |\n\n---\n\n### 23. 本版结论\n\nv2.2 吸收了前序文档中的以下优势：\n\n1. **额度体系**（测评4/免评4/累计12）作为独立共用能力，含台账/预占/预警/拦截\n2. **画像拆解**为 7 组字段 × 3 类用途\n3. **节点规则表**统一用 查/写/状态/提醒/拦截/转人工 格式\n4. **EDM 专属行为指标**（3/5次0打开、点击未回复时长、单月收信次数）\n5. **客服管理支撑流**（排班/出勤/绩效/目标）\n6. **评价完成流程**中拆开\"提交即计12\"vs\"展示才计完成\"\n7. **P0/P1/P2 数据对象**优先级\n\n同时保留了我版的核心优势：\n\n1. **IM A/B/C 三层用户完整流转**（提交核验、测评流程、标签汇总、推送/流转动作表）\n2. **渠道交叉与协同规则**（优先级路由、去重规则、用户状态 × 渠道可用性矩阵）\n3. **KOC/KOL JOYCOLLAB 同步链路**及免评协同角色表\n4. **TEL 拨打前准备五步 + 重试策略**\n5. **店铺紧急催评**独立子流程\n6. **三套并行客服状态**（工单/答应配合/风险）\n\n并完成以下收口：\n\n1. 将 IM 里残留的 `Amazon 账号 < / > 12 review` 全部改为 `真实人累计真实提交评价` 口径\n2. 明确 TEL 可继续服务，但不能绕开普通测评额度限制\n3. 补齐渠道路由、渠道去重、IM 流程标签和 EDM 行为画像对应的数据对象\n", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3", "type": "document", "name": "USER 评价业务闭环 — 第三步：数据流与中间对象设计 v3", "filePath": "05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md", "summary": "USER 评价业务闭环 — 第三步：数据流与中间对象设计 v3 文件信息 文件名称： 20260517 USER评价业务闭环 第三步 数据流与中间对象设计 v3.md 项目路径： C:\\XCODE\\USER 当前版本： v3 最近更新： 2026 05 17 上游文档： 工作基线 v1.2 20260517 USER评价业务闭环主流程与后续工作基线 v1.2", "tags": [ "05_需求文档", "需求文档" ], "complexity": "complex", "knowledgeMeta": { "content": "# USER 评价业务闭环 — 第三步：数据流与中间对象设计 v3\n\n## 文件信息\n\n- 文件名称：`20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md`\n- 项目路径：`C:\\XCODE\\USER`\n- 当前版本：`v3`\n- 最近更新：`2026-05-17`\n- 上游文档：\n - [工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md) — 业务规则与额度口径\n - [共用能力图与渠道专属流程 v2.2](20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md) — 每个节点的 查/写/状态/提醒/拦截\n- 前置版本：\n - `数据流与中间对象需求_v1`（Codex，六层架构骨架）\n - `数据流与中间对象设计_v1.1`（Codex，字段字典最全版）\n - `第三步_数据流与中间表设计_v1`（字段级展开 + 流转时序）\n - `第三步_数据流与中间表设计_v2`（吸收 Codex 优点的合并版）\n- 合并策略：以 Codex v1.1 为主骨架（保留其完整字段字典和免评对象），补入 v2 的流转时序表、写入顺序图和快照策略。\n- 文件目的：作为第三步最终主稿，后续数据库物理设计、接口设计和页面点击读写设计均以此为准。\n\n---\n\n## 1. 第三步的目标\n\n第三步不再回答\"流程怎么走\"，而是回答：\n\n1. 现有系统里已经有哪些数据可以复用。\n2. 为什么仅靠现有 `users / amazon_orders / review_plans / push_tasks / support_tickets / fraud_events` 不够。\n3. 必须新增哪些中间对象。\n4. 哪些是正式事务表，哪些只是快照，哪些可以先做成视图。\n5. 从需求形成到结果回流，数据怎样一层一层往下走。\n\n---\n\n## 2. 本步先给出的结论\n\n### 2.1 不能再只围绕单一账号建模\n\n后续所有关键判断都应围绕 **真实人**，而不是只看 JOYHUB ID / 邮箱 / 电话 / Amazon 账号 / 单次订单。JOYHUB 用户只是身份线索之一，真实人才是额度、历史、风险、跨渠道去重和客服上下文的主对象。\n\n### 2.2 现有表能承载业务记录，但承载不了跨流程判断\n\n既有表更接近\"某一模块自己的账\"，但前两步已确认的新需求需要额外的中间层：真实人跨账号归并、每次互动重判、人群入选/排除解释、额度预占与跨渠道去重、客服上下文、评价提交与展示拆分、退款比对。\n\n### 2.3 第三步最重要的是把对象分层\n\n本文件把数据对象分为六层：\n\n```\n源数据层 → 主实体层 → 桥接层 → 事件层 → 快照与决策层 → 结果回流层\n```\n\n---\n\n## 3. 数据设计原则\n\n| 原则 | 说明 |\n| --- | --- |\n| 先识别真实人，再做额度与风险 | 否则 4/4/12 规则都会被多账号绕开 |\n| 事件与快照分离 | 事件是原始事实，快照是某个时点的判断结果 |\n| 当前态与历史态分离 | 当前视图可重算，历史决策必须留痕 |\n| 计划、渠道、客服、风险状态分离 | 不能压成一个字段 |\n| 用户提交与平台展示分离 | 真实提交计额度，Amazon 展示计计划完成 |\n| 能解释\"为什么\" | 入选、排除、拦截、转人工都要能追溯 |\n| 先复用现有对象，再补最小中间层 | 不为了建模漂亮重造全部旧表 |\n| 对敏感数据分层处理 | 原值、标准化值、哈希/指纹、脱敏展示值应区分 |\n\n---\n\n# 第一部分：现有数据源分析\n\n## 4. 现有数据源盘点\n\n| 数据源 | 当前可用内容 | 主要缺口 |\n| --- | --- | --- |\n| 现有 ERP 用户管理 | 用户 ID、用户名、注册时间、最近活跃、国家、性别、邮箱、绑定产品数、标签 | 仍是账号视角，不是真实人视角 |\n| APP / 用户数据库 | JOYHUB ID、邮箱、设备号、设备型号/类型、系统版本、APP版本、绑定玩具、活跃与点击行为 | 需要设备变更轨迹和与订单/客服联动 |\n| Amazon 订单 | 订单号、ASIN、站点、购买时间、订单状态、Profile ID、收件人姓名、收件地址等 | 需要标准化姓名/地址和收件人指纹 |\n| Amazon 评价/Listing | ASIN、评分、评价数、差评数、评价缺口、展示结果 | 用户真实提交与平台展示要拆成两条事实 |\n| 推送系统 | Push 计划、素材、任务、打开、点击、回复、投诉、退订 | IM/EDM/APP 语义不同，不能只用一套粗糙 push 结果 |\n| 客服/TEL | 工单、通话、售后、答应配合、问题处理 | 需要和上下文卡、风险复检、跟进状态联动 |\n| 黑名单/诈骗资料 | 黑名单、诈骗事件、双重退款、强弱关联 | 需要把风险信号与确认案件拆开 |\n| OA 返款/Amazon 退款 | 内部返款与 Amazon 退款 | 缺统一比对对象 |\n| JOYCOLLAB | KOC/KOL、内容、Code、点击、订单、转化、佣金 | 需要和 USER 计划/ASIN 结果打通 |\n\n### 4.1 Amazon 订单字段明细（结合表头.xlsx）\n\n| 字段 | 主要用途 | 涉密 |\n| --- | --- | --- |\n| 订单号 | 订单核验、真实人关联、退款比对 | 是 |\n| 订单状态 | 判断是否撤销、退款、退货、换货 | - |\n| 买家姓名 / 买家邮箱 | 身份关联 | 是 |\n| 收件人 / 电话 | 真实人归并、风险判断 | 是 |\n| 地址 / 城市 / 州 / 邮编 | 收件人归并、同址异名识别 | 是 |\n| ASIN / MSKU / SKU / 品名 / 标题 | 产品匹配、计划归属 | - |\n| 订购日期 / 发货时间 / 结算时间 | 时序判断 | - |\n| 数量 / 单价 / 订单总金额 / 销售额 | 交易画像 | 是 |\n| 是否退款 / 退款总金额 | 双重退款检测 | 是 |\n| 请求评论状态 | 评价缺口判断 | - |\n| 店铺 / 国家 / 销售渠道 | 站点匹配 | - |\n| Order Item ID | 订单行级关联 | - |\n\n### 4.2 订单侧必须补的派生字段\n\n| 字段 | 说明 |\n| --- | --- |\n| `recipient_name_normalized` | 标准化后的收件人姓名 |\n| `recipient_address_normalized` | 标准化后的地址 |\n| `recipient_fingerprint` | 由标准化姓名+地址生成的稳定指纹 |\n| `address_fingerprint` | 仅地址指纹，用于识别同址异名 |\n\n---\n\n## 5. 全局数据流\n\n```mermaid\nflowchart LR\n subgraph S[\"源数据层\"]\n S1[\"现有ERP用户/标签/身份\"]\n S2[\"APP/设备/行为\"]\n S3[\"Amazon订单/评价/Listing\"]\n S4[\"IM/EDM/APP Push/TEL\"]\n S5[\"客服/工单/售后\"]\n S6[\"黑名单/OA返款/Amazon退款\"]\n S7[\"JOYCOLLAB\"]\n end\n\n subgraph M[\"主实体与桥接层\"]\n M1[\"真实人 person_profiles\"]\n M2[\"身份关联 person_identity_links\"]\n M3[\"订单/ASIN/计划/工单\"]\n M4[\"订单关联/路由/去重\"]\n end\n\n subgraph D[\"快照与决策层\"]\n D1[\"画像快照 person_feature_snapshots\"]\n D2[\"上下文卡 contact_context_snapshots\"]\n D3[\"额度台账/预占\"]\n D4[\"风险信号/风险案件\"]\n D5[\"人群快照/排除快照\"]\n D6[\"互动复检/路由决策\"]\n end\n\n subgraph E[\"事件层\"]\n E1[\"渠道事件\"]\n E2[\"客服/TEL事件\"]\n E3[\"退款事件\"]\n E4[\"评价提交事件\"]\n E5[\"免评执行事件\"]\n end\n\n subgraph R[\"结果回流层\"]\n R1[\"评价展示核验\"]\n R2[\"退款比对结果\"]\n R3[\"免评结果\"]\n R4[\"ASIN健康/计划完成\"]\n R5[\"绩效/审计/下一轮需求\"]\n end\n\n S1 & S2 & S3 --> M1\n S1 & S2 & S3 --> M2\n M1 & M2 & M3 --> D1\n M1 & M2 & M3 --> D2\n D1 --> D5\n D3 & D4 --> D5\n D5 --> D6\n D6 --> E1\n S4 --> E1\n S5 --> E2\n S6 --> E3\n E1 & E2 --> E4\n S7 --> E5\n E3 --> R2\n E4 --> R1\n E5 --> R3\n R1 & R2 & R3 --> R4\n R4 --> R5\n R5 --> M3\n```\n\n---\n\n# 第二部分：数据对象分层总表\n\n## 6. 对象分层总表\n\n| 分层 | 对象 | 说明 |\n| --- | --- | --- |\n| 源数据 | `users`、`devices`、`amazon_orders`、`asin_listings`、`push_tasks`、`support_tickets`、`fraud_events`、JOYCOLLAB 数据 | 现有或外部事实来源 |\n| 主实体 | `person_profiles`、`request_tickets`、`review_plans`、`exemption_plans`、`risk_cases`、`blacklist_entities` | 核心业务主体 |\n| 桥接 | `person_identity_links`、`user_order_links`、`plan_task_links`、`channel_route_decisions`、`channel_dedup_records` | 跨主体关系 |\n| 事件 | `im_interaction_records`、`im_flow_tags`、`edm_message_events`、`app_touch_events`、`tel_call_records`、`review_submission_records`、`amazon_refund_records`、`oa_refund_records`、`support_assignment_logs` | 不可丢失的事实 |\n| 快照/决策 | `person_feature_snapshots`、`contact_context_snapshots`、`person_quota_ledgers`、`quota_reservations`、`audience_snapshots`、`audience_exclusions`、`interaction_recheck_records`、`edm_user_behavior_profiles`、`channel_route_decisions`、`channel_dedup_records` | 为某次决策保留当时依据 |\n| 结果/回流 | `review_display_checks`、`refund_match_results`、`exemption_result_snapshots`、`listing_health_snapshots`、`support_performance_snapshots` | 结果与复盘 |\n| 治理 | `interaction_audit_logs`、`manual_review_tasks`、`export_logs`、`audit_logs` | 审计、复核、导出 |\n\n---\n\n## 7. 现有对象如何处理\n\n### 7.1 可以直接复用\n\n| 现有对象 | 处理 |\n| --- | --- |\n| `request_tickets` | 保留，继续作为需求入口 |\n| `amazon_orders` | 保留，补标准化姓名/地址与收件人指纹 |\n| `asin_listings` | 保留，继续作为 ASIN/Listing 主档 |\n| `support_tickets` | 保留，拆出跟进、分派和风险状态辅助表 |\n| `fraud_events` | 保留，上游增加 `risk_signals`，下游衔接 `risk_cases/blacklist_entities` |\n| `audit_logs` | 保留 |\n\n### 7.2 需要扩展\n\n| 现有对象 | 需要补的能力 |\n| --- | --- |\n| `users` | 不再承担真实人主档，只保留 JOYHUB 账号层信息 |\n| `devices` | 补设备型号、系统版本、APP版本、首次/最近出现、设备变化 |\n| `review_plans` | 增加计划族或与 `exemption_plans` 分离 |\n| `push_tasks` | 被更细的渠道事件表补充 |\n| `support_tickets` | 增加与上下文卡、答应配合、风险复核、TEL 记录的关联 |\n\n### 7.3 必须新增\n\n| 对象 | 原因 |\n| --- | --- |\n| `person_profiles` | 真实人主档 |\n| `person_identity_links` | 多线索归并 |\n| `person_feature_snapshots` | 画像解释 |\n| `contact_context_snapshots` | 客服一屏上下文 |\n| `person_quota_ledgers` | 4/4/12 统一额度 |\n| `quota_reservations` | 并发占用与预警 |\n| `audience_snapshots` | 人群生成留痕 |\n| `audience_exclusions` | 排除原因留痕 |\n| `channel_route_decisions` | 渠道路由解释 |\n| `channel_dedup_records` | 跨渠道去重 |\n| `interaction_recheck_records` | 每次有效互动重新判断留痕 |\n| `refund_match_results` | 双重退款识别 |\n| `review_display_checks` | 评价展示拆分 |\n\n---\n\n# 第三部分：P0/P1/P2 优先级\n\n## 8. P0：没有它们，主流程就不可靠\n\n| 对象 | 类型 | 关键用途 |\n| --- | --- | --- |\n| `person_profiles` | 主实体 | 真实人主档 |\n| `person_identity_links` | 桥接 | 账号、邮箱、电话、设备、Profile、收件人归并 |\n| `person_feature_snapshots` | 快照 | 画像依据 |\n| `contact_context_snapshots` | 快照 | 客服上下文卡 |\n| `person_quota_ledgers` | 台账 | 4/4/12 统一额度 |\n| `quota_reservations` | 台账 | 计划并发占用 |\n| `risk_signals` | 事件 | 风险原始信号 |\n| `risk_cases` | 主实体 | 风险案件 |\n| `blacklist_entities` | 主实体 | 确认拦截对象 |\n| `audience_snapshots` | 快照 | 某次人群生成结果 |\n| `audience_exclusions` | 快照 | 排除原因 |\n| `channel_route_decisions` | 决策 | 渠道路由 |\n| `channel_dedup_records` | 决策 | 跨渠道去重 |\n| `interaction_recheck_records` | 决策 | 每次有效互动重判 |\n\n## 9. P1：主流程可走，但没有它们会粗糙且难复盘\n\n| 对象 | 类型 | 关键用途 |\n| --- | --- | --- |\n| `im_interaction_records` | 事件 | IM 细节 |\n| `im_flow_tags` | 事件/派生 | IM 流程流转 |\n| `edm_message_events` | 事件 | EDM 打开/点击/回复/退订 |\n| `edm_user_behavior_profiles` | 快照 | EDM 画像 |\n| `app_touch_events` | 事件 | APP Push 触达 |\n| `tel_call_records` | 事件 | 电话全记录 |\n| `support_followups` | 事务 | 答应配合跟进 |\n| `support_assignment_logs` | 事件 | 分配与升级 |\n| `review_submission_records` | 事件 | 用户真实提交评价 |\n| `review_display_checks` | 结果 | Amazon 展示核验 |\n| `exemption_plans` | 主实体 | 免评计划 |\n| `exemption_plan_tasks` | 事务 | 免评任务 |\n| `creator_content_records` | 事件 | KOC/KOL 内容 |\n| `exemption_result_snapshots` | 结果 | 免评结果 |\n| `amazon_refund_records` | 事件 | Amazon 退款 |\n| `oa_refund_records` | 事件 | OA 返款 |\n| `refund_match_results` | 结果 | 双重退款比对 |\n\n## 10. P2：管理、效率与治理增强\n\n| 对象 | 类型 | 关键用途 |\n| --- | --- | --- |\n| `attendance_records` | 事务 | 出勤 |\n| `shift_schedules` | 事务 | 排班 |\n| `support_goal_records` | 事务 | 目标 |\n| `support_performance_snapshots` | 快照 | 绩效 |\n| `manual_review_tasks` | 事务 | 人工复核 |\n| `interaction_audit_logs` | 审计 | 高敏动作审计 |\n\n---\n\n# 第四部分：完整字段字典\n\n## 11. 真实人与身份层\n\n### 11.1 `person_profiles`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `person_id` | PK | 真实人唯一标识 |\n| `created_at` | datetime | 首次识别时间 |\n| `updated_at` | datetime | 最近归并更新时间 |\n| `merge_confidence` | enum | 高/中/低 |\n| `status` | enum | 正常/观察中/已确认风险 |\n| `primary_country` | string | 当前主要国家 |\n| `primary_language` | string | 当前主要语言 |\n| `latest_active_at` | datetime | 最近活跃时间 |\n| `lifetime_review_submitted_count` | int | 累计真实提交评价数（跨账号合并） |\n| `current_risk_level` | enum | 当前风险等级 |\n\n### 11.2 `person_identity_links`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `link_id` | PK | 关联记录 ID |\n| `person_id` | FK → person_profiles | 所属真实人 |\n| `identity_type` | enum | JOYHUB_ID / EMAIL / PHONE / DEVICE / AMAZON_PROFILE / NAME_ADDRESS / PAYMENT / ORDER |\n| `identity_value_hash` | string | 匹配索引 |\n| `identity_value_encrypted` | string | 仅在必要时保存的加密原值 |\n| `link_strength` | enum | 强/弱 |\n| `confidence_score` | decimal | 归并置信度 |\n| `evidence_summary` | text | 命中依据摘要 |\n| `first_seen_at` | datetime | 首次发现时间 |\n| `last_seen_at` | datetime | 最近确认时间 |\n| `source_type` | enum | AMAZON_ORDER / JOYHUB / MANUAL / TEL / EMAIL / CS_TICKET |\n| `is_active` | bool | 是否仍有效 |\n\n### 11.3 归并口径\n\n| 场景 | 数据处理 |\n| --- | --- |\n| 标准化后姓名+地址完全一致 | 直接归并到同一真实人，link_strength=STRONG |\n| 地址一致但姓名不同 | 记录弱关联，不直接合并 |\n| 多个线索交叉命中 | 形成候选归并，记录证据和置信度 |\n| 只有单个弱线索 | 不做直接归并，只写风险信号 |\n\n### 11.4 `contact_context_snapshots`\n\n| 字段组 | 字段 | 来源 |\n| --- | --- | --- |\n| 快照元数据 | `snapshot_id`、`person_id`、`snapshot_at`、`trigger_event` | 系统 |\n| 当前身份 | `joyhub_ids[]`、`emails[]`、`phones[]`、`devices[]`、`amazon_profile_ids[]` | 身份关联 |\n| 归并摘要 | `standardized_name_address`、`linked_person_count`、`merge_confidence` | 真实人/身份关联 |\n| 历史交易 | `total_orders`、`last_order_at`、`total_refunds`、`total_oa_refunds`、`target_asin_purchases[]` | 订单/返款 |\n| 历史服务 | `total_tickets`、`last_ticket_at`、`total_calls`、`last_call_at`、`open_promises[]` | 工单/电话 |\n| 历史风险 | `blacklist_hits`、`strong_associations`、`weak_associations`、`fraud_cases`、`double_refund_flags` | 风险层 |\n| 当前设备 | `device_count`、`latest_device_model`、`app_version`、`recent_device_change` | APP/设备 |\n| 触达历史 | `im_recent[]`、`edm_recent[]`、`app_recent[]`、`tel_recent[]` | 渠道事件 |\n\n---\n\n## 12. 画像、额度与人群层\n\n### 12.1 `person_feature_snapshots`\n\n| 字段组 | 代表字段 |\n| --- | --- |\n| 快照元数据 | `feature_snapshot_id`、`person_id`、`snapshot_at`、`feature_version` |\n| 基础画像 | `country`、`marketplace`、`language`、`gender`、`age_band`、`registered_at` |\n| 产品关系 | `bound_toy_count`、`bound_categories[]`、`target_product_relation` |\n| 交易画像 | `total_orders`、`last_order_at`、`purchase_frequency`、`bought_target_asin` |\n| 行为画像 | `activity_score`、`open_rate`、`click_rate`、`reply_rate`、`review_rate`、`cooperation_rate` |\n| 触达画像 | `im_reachable`、`edm_reachable`、`app_reachable`、`tel_reachable`、`last_touch_at` |\n| 风险画像 | `risk_level`、`blacklist_hit`、`strong_link_count`、`weak_link_count`、`refund_anomaly_flag` |\n| 计划画像 | `joined_plan_types[]`、`last_plan_result`、`lifetime_review_submitted_count` |\n\n### 12.2 三类画像用途\n\n| 用途 | 说明 | 示例 |\n| --- | --- | --- |\n| **硬过滤** | 决定能不能进入人群池 | 黑名单、退订、强关联、超额、站点不符 |\n| **匹配条件** | 决定适不适合当前计划 | 国家、性别、年龄段、绑定玩具、是否买过目标 ASIN |\n| **排序权重** | 决定优先触达谁 | 活跃度、历史配合率、最近互动、打开/点击行为 |\n\n### 12.3 `person_quota_ledgers`\n\n> **HANDOFF：用户运营核心控制规则。** \"4+4+12\"全部按真实人统计，跨所有关联账号合并计算。一个人不管有几个 JOYHUB ID、几个 Amazon 账号——只要归并到同一个真实人，都受同一套额度控制。\n>\n> 示例：真实人关联 3 个 JOYHUB ID（A/B/C），A 上提交 5 个 + B 上提交 4 个 + C 上提交 3 个 = 累计 12，**全部账号停回评/测评，后续仅免评。**\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `ledger_id` | PK | 台账记录 ID |\n| `person_id` | FK → person_profiles | 真实人 |\n| `period_key` | string | 自然月，如 `2026-05` |\n| `quota_type` | enum | MONTHLY_REVIEW / MONTHLY_EXEMPTION / LIFETIME_REVIEW |\n| `quota_limit` | int | 4 / 4 / 12 |\n| `used` | int | 已完成 |\n| `in_progress` | int | 进行中 |\n| `reserved` | int | 已预占 |\n| `available` | int | 剩余可用 = limit - used - in_progress - reserved |\n| `updated_at` | datetime | 最近更新 |\n\n### 12.4 `quota_reservations`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `reservation_id` | PK | 预占记录 |\n| `person_id` | FK | 真实人 |\n| `plan_id` | FK | 关联计划 |\n| `quota_type` | enum | 测评/免评 |\n| `reserved_count` | int | 预占数量 |\n| `reserved_at` | datetime | 预占时间 |\n| `expires_at` | datetime | 过期释放时间 |\n| `status` | enum | 已预占/已使用/已释放/已过期 |\n\n### 12.5 `audience_snapshots`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `snapshot_id` | PK | 人群快照 ID |\n| `plan_id` | FK | 计划 |\n| `batch_id` | string | 生成人群批次 |\n| `person_id` | FK | 真实人 |\n| `match_score` | decimal | 匹配得分 |\n| `match_reasons` | JSON | 命中画像条件 |\n| `quota_status` | enum | 充足/预警/超限 |\n| `risk_status` | enum | 正常/弱风险/强风险 |\n| `priority_rank` | int | 触达优先级 |\n| `feature_snapshot_id` | FK | 当时引用的画像快照 |\n| `snapshot_at` | datetime | 快照时间 |\n\n### 12.6 `audience_exclusions`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `exclusion_id` | PK | 排除记录 |\n| `plan_id` | FK | 计划 |\n| `batch_id` | string | 批次 |\n| `person_id` | FK | 真实人 |\n| `exclusion_reason` | enum | BLACKLIST / UNSUBSCRIBED / QUOTA_EXCEEDED / FREQ_EXCEEDED / OPEN_TICKET / WRONG_COUNTRY / STRONG_RISK |\n| `excluded_at` | datetime | 排除时间 |\n\n### 12.7 为什么一定需要这些中间表\n\n| 对象 | 如果没有会怎样 |\n| --- | --- |\n| `person_feature_snapshots` | 无法解释当时的画像依据 |\n| `audience_snapshots` | 无法复盘某次计划到底选中了谁 |\n| `audience_exclusions` | 无法解释为什么用户没被选中 |\n| `person_quota_ledgers` | 4/4/12 规则无法跨账号统一计算 |\n| `quota_reservations` | 多个计划并发时会重复占用同一人额度 |\n\n---\n\n## 13. 路由与互动复检层\n\n### 13.1 `channel_route_decisions`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `route_decision_id` | PK | 路由决策 ID |\n| `plan_id` | FK | 计划 |\n| `batch_id` | string | 人群批次 |\n| `person_id` | FK | 真实人 |\n| `candidate_channels` | JSON | 候选渠道 |\n| `selected_channel` | enum | 实际选中渠道 |\n| `excluded_channels` | JSON | 被排除渠道及原因 |\n| `decision_factors` | JSON | 活跃、绑定、可达性、工单、额度、风险 |\n| `decided_at` | datetime | 决策时间 |\n\n### 13.2 `channel_dedup_records`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `dedup_id` | PK | 去重记录 |\n| `person_id` | FK | 真实人 |\n| `plan_id` | FK | 计划 |\n| `selected_channel` | enum | 保留渠道 |\n| `suppressed_channels` | JSON | 被抑制渠道 |\n| `reason` | text | 去重原因 |\n| `created_at` | datetime | 去重时间 |\n\n### 13.3 `interaction_recheck_records`\n\n每次有效互动后，记录本次重新做过哪些检查、结果是什么、为何继续或拦截。这是\"每次互动重判\"的落地证据。\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `recheck_id` | PK | 复检记录 |\n| `interaction_type` | enum | IM / EDM / APP / TEL / CS / REFUND |\n| `interaction_id` | string | 触发互动 |\n| `person_id` | FK | 真实人 |\n| `context_snapshot_id` | FK | 上下文快照 |\n| `quota_snapshot_ref` | string | 额度快照引用 |\n| `risk_case_id` | FK | 关联风险案件 |\n| `identity_result` | enum | 正常/新增关联/冲突 |\n| `history_result` | enum | 无变化/有更新 |\n| `quota_result` | enum | 充足/预警/超限 |\n| `risk_result` | enum | 正常/弱风险/强风险 |\n| `final_action` | enum | 继续/降级/转人工/暂停 |\n| `checked_at` | datetime | 复检时间 |\n\n---\n\n## 14. 风险层\n\n### 14.1 `risk_signals`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `signal_id` | PK | 风险信号 ID |\n| `person_id` | FK | 真实人 |\n| `signal_type` | enum | STRONG_HIT / WEAK_HIT / DOUBLE_REFUND / DEVICE_ANOMALY / ADDRESS_ANOMALY / BLACKLIST_HIT |\n| `hit_dimensions` | JSON | 命中维度 |\n| `source_event_id` | string | 触发事件 |\n| `created_at` | datetime | 产生时间 |\n| `resolved_at` | datetime | 解除时间 |\n| `resolution` | enum | 确认风险/误报/观察中 |\n\n### 14.2 `risk_cases`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `case_id` | PK | 风险案件 |\n| `person_id` | FK | 真实人 |\n| `source_type` | enum | CS_TICKET / TEL_CALL / PUSH_RESPONSE / REFUND / MANUAL |\n| `source_id` | string | 来源对象 |\n| `status` | enum | 待复核/复核中/确认诈骗/排除/已同步黑名单 |\n| `reviewer_id` | FK | 复核人 |\n| `reviewed_at` | datetime | 复核时间 |\n| `sync_status` | enum | 未同步/同步中/已同步/同步失败 |\n\n### 14.3 `blacklist_entities`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `blacklist_entity_id` | PK | 黑名单实体 |\n| `entity_type` | enum | 邮箱/电话/设备/Profile/收款信息/真实人 |\n| `entity_hash` | string | 匹配索引 |\n| `risk_level` | enum | 风险等级 |\n| `source_case_id` | FK | 来源案件 |\n| `synced_at` | datetime | 同步时间 |\n| `status` | enum | 生效/失效/待复核 |\n\n### 14.4 `manual_review_tasks`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `task_id` | PK | 人工复核任务 |\n| `person_id` | FK | 真实人 |\n| `source_type` | enum | 风险/额度/渠道/退款 |\n| `source_id` | string | 来源对象 |\n| `task_reason` | text | 复核原因 |\n| `status` | enum | 待处理/处理中/已完成/已关闭 |\n| `owner_id` | FK | 负责人 |\n| `created_at` | datetime | 创建时间 |\n\n---\n\n## 15. 渠道事件层\n\n### 15.1 `im_interaction_records`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `im_record_id` | PK | IM 记录 |\n| `person_id` | FK | 真实人 |\n| `joyhub_id` | FK | JOYHUB 账号 |\n| `plan_id` | FK | 关联计划 |\n| `action_type` | enum | PUSH_CARD / USER_SUBMIT / USER_REPLY / REMINDER / NOTIFICATION |\n| `card_type` | enum | REVIEW_CARD / EVALUATION_CARD / EXEMPTION_CARD / REMINDER_CARD |\n| `user_submitted_data` | JSON | 订单号/返款账号/截图链接（涉密加密存储） |\n| `order_validation_result` | enum | 通过/非测评单/非公司产品/格式错误/已撤销/已退款 |\n| `tag_changes` | JSON | 本次产生的标签变化 |\n| `created_at` | datetime | 事件时间 |\n\n### 15.2 `im_flow_tags`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `flow_tag_id` | PK | 流程标签记录 |\n| `person_id` | FK | 真实人 |\n| `tag_code` | string | 流程标签 |\n| `source_im_record_id` | FK | 来源 IM 事件 |\n| `effective_from` | datetime | 生效时间 |\n| `effective_to` | datetime | 失效时间 |\n\n### 15.3 `edm_message_events`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `edm_event_id` | PK | EDM 事件 |\n| `person_id` | FK | 真实人 |\n| `email_hash` | string | 邮箱索引 |\n| `campaign_id` | FK | 邮件任务 |\n| `event_type` | enum | SENT / DELIVERED / OPENED / CLICKED / REPLIED / BOUNCED / UNSUBSCRIBED / COMPLAINED |\n| `event_at` | datetime | 事件时间 |\n| `click_target` | string | 点击目标 |\n\n### 15.4 `edm_user_behavior_profiles`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `profile_id` | PK | EDM 行为画像 |\n| `person_id` | FK | 真实人 |\n| `latest_open_at` | datetime | 最近打开 |\n| `latest_reply_at` | datetime | 最近回复 |\n| `open_count_total` | int | 累计打开次数 |\n| `zero_open_last_3` | bool | 最近 3 次 0 打开 |\n| `zero_open_last_5` | bool | 最近 5 次 0 打开 |\n| `clicked_review_link_without_reply_hours` | int | 点击评论链接但未回复时长 |\n| `monthly_receive_count` | int | 当月收信次数 |\n| `mail_type_counts` | JSON | 各邮件类型发送次数 |\n| `mailbox_domain` | string | 邮箱后缀 |\n| `is_unsubscribed` | bool | 是否退订 |\n| `has_hard_bounce` | bool | 是否硬退信 |\n| `snapshot_at` | datetime | 快照时间 |\n\n### 15.5 `app_touch_events`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `app_event_id` | PK | APP 事件 |\n| `person_id` | FK | 真实人 |\n| `joyhub_id` | FK | JOYHUB 账号 |\n| `push_type` | enum | PUSH / IN_APP / BANNER / POPUP |\n| `event_type` | enum | SENT / DISPLAYED / CLICKED / DISMISSED / UNINSTALLED |\n| `landing_page` | string | 落地页 |\n| `event_at` | datetime | 事件时间 |\n\n### 15.6 `tel_call_records`\n\n| 字段 | 类型 | 说明 | 涉密 |\n| --- | --- | --- | --- |\n| `tel_record_id` | PK | 电话记录 | - |\n| `person_id` | FK | 真实人 | - |\n| `ticket_id` | FK | 关联工单 | - |\n| `call_direction` | enum | INBOUND/OUTBOUND | - |\n| `call_source` | enum | AMAZON_PAGE/MANUAL/PLAN_TASK/FOLLOWUP | - |\n| `phone_hash` | string | 电话索引 | 是 |\n| `call_at` | datetime | 通话时间 | - |\n| `duration_seconds` | int | 通话时长 | - |\n| `call_result` | enum | CONNECTED/NO_ANSWER/WRONG_NUMBER/DECLINED | - |\n| `has_after_sale_issue` | bool | 是否有售后 | - |\n| `issue_type` | enum | 问题类型 | - |\n| `issue_description` | text | 问题描述 | - |\n| `solution` | text | 处理方案 | - |\n| `is_resolved` | bool | 是否解决 | - |\n| `is_satisfied` | bool | 是否满意 | - |\n| `invited_review` | bool | 是否邀请回评/测评 | - |\n| `user_accepted` | bool | 是否接受 | - |\n| `agent_id` | FK | 客服 | - |\n\n---\n\n## 16. 客服层\n\n### 16.1 `support_tickets`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `ticket_id` | PK | 工单 |\n| `person_id` | FK | 真实人 |\n| `ticket_type` | enum | 差评跟进/测评跟进/回评跟进/紧急Listing/电话/售后/诈骗样品/KOL进度 |\n| `source` | enum | AMAZON_OP/BRAND_OP/SYSTEM_AUTO/PUSH_ESCALATION/USER_REPLY/TEL_INBOUND |\n| `source_id` | string | 来源对象 |\n| `ticket_status` | enum | 待分配/已分配/处理中/等待用户/等待内部/已解决/疑似诈骗/已关闭 |\n| `assigned_team` | FK | 客服组 |\n| `assigned_agent` | FK | 客服 |\n| `created_at` | datetime | 创建时间 |\n| `first_response_at` | datetime | 首次回复 |\n| `resolved_at` | datetime | 解决时间 |\n| `closed_at` | datetime | 关闭时间 |\n| `context_snapshot_id` | FK | 创建时上下文快照 |\n\n### 16.2 `support_followups`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `followup_id` | PK | 跟进 |\n| `ticket_id` | FK | 工单 |\n| `person_id` | FK | 真实人 |\n| `followup_status` | enum | 已答应配合/待分配/待提醒/等待提交/已提交评价/已提交反馈/超时/需再次联系/已关闭 |\n| `promised_at` | datetime | 承诺时间 |\n| `reminder_count` | int | 已提醒次数 |\n| `last_reminder_at` | datetime | 最近提醒 |\n| `deadline_at` | datetime | 截止时间 |\n| `submitted_at` | datetime | 实际提交 |\n| `submission_type` | enum | 评价/反馈 |\n\n### 16.3 `support_assignment_logs`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `assignment_log_id` | PK | 分配日志 |\n| `ticket_id` | FK | 工单 |\n| `from_owner_id` | FK | 原负责人 |\n| `to_owner_id` | FK | 新负责人 |\n| `assign_type` | enum | 自动分配/组长分派/转派/升级 |\n| `reason` | text | 原因 |\n| `created_at` | datetime | 分配时间 |\n\n### 16.4 `plan_task_links`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `link_id` | PK | 桥接 ID |\n| `plan_id` | FK | 计划 |\n| `task_type` | enum | IM_TASK/EDM_TASK/APP_TASK/TEL_TASK/CS_TASK/KOC_TASK |\n| `task_id` | string | 各渠道任务 ID |\n| `created_at` | datetime | 创建时间 |\n\n---\n\n## 17. 评价与退款结果层\n\n### 17.1 `review_submission_records`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `submission_id` | PK | 提交记录 |\n| `person_id` | FK | 真实人 |\n| `plan_id` | FK | 计划 |\n| `channel` | enum | IM/EDM/APP/TEL/CS |\n| `source_event_id` | string | 来源事件 |\n| `submitted_at` | datetime | 提交时间 |\n| `submission_evidence` | JSON | 截图/链接 |\n| `order_number_hash` | string | 订单索引 |\n| `quota_counted` | bool | 是否已计入 12（提交时即为true） |\n\n### 17.2 `review_display_checks`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `check_id` | PK | 核验记录 |\n| `submission_id` | FK | 提交记录 |\n| `asin` | string | ASIN |\n| `check_at` | datetime | 核验时间 |\n| `is_displayed` | bool | 是否展示 |\n| `is_verifiable` | bool | 是否可核验 |\n| `display_status` | enum | 展示确认/未展示/待核验 |\n| `plan_completed` | bool | 是否计入计划完成（展示确认后才为true） |\n\n### 17.3 `amazon_refund_records` / `oa_refund_records` / `refund_match_results`\n\n| 对象 | 关键字段 |\n| --- | --- |\n| `amazon_refund_records` | `refund_id`、`order_number_hash`、`asin`、`refund_amount`、`refund_at`、`refund_reason` |\n| `oa_refund_records` | `oa_refund_id`、`person_id`、`order_number_hash`、`refund_amount`、`refund_at` |\n| `refund_match_results` | `match_id`、`order_number_hash`、`amazon_refund_id`、`oa_refund_id`、`match_status`、`amount_diff`、`matched_at` |\n\n---\n\n## 18. 免评结果层\n\n### 18.1 `exemption_plans`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `exemption_plan_id` | PK | 免评计划 |\n| `source_request_id` | FK | 来源需求 |\n| `asin` | string | ASIN |\n| `marketplace` | string | 站点 |\n| `goal_type` | enum | 内容发布/引流/带货/权重 |\n| `target_metrics` | JSON | 目标点击、Code、订单、销量、权重 |\n| `status` | enum | 草稿/待审批/执行中/已完成/已关闭 |\n\n### 18.2 `exemption_plan_tasks`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `task_id` | PK | 免评任务 |\n| `exemption_plan_id` | FK | 免评计划 |\n| `task_type` | enum | KOC/KOL/IM/EDM/APP/内容协同 |\n| `owner_id` | FK | 负责人 |\n| `status` | enum | 待执行/执行中/已完成/异常 |\n| `created_at` | datetime | 创建时间 |\n\n### 18.3 `creator_content_records`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `creator_content_id` | PK | 内容记录 |\n| `exemption_task_id` | FK | 免评任务 |\n| `creator_id` | string | KOC/KOL |\n| `content_url` | string | 内容链接 |\n| `published_at` | datetime | 发布时间 |\n| `code_usage_count` | int | Code 使用量 |\n| `click_count` | int | 点击量 |\n| `order_count` | int | 带货订单 |\n| `sales_amount` | decimal | 销售额 |\n\n### 18.4 `exemption_result_snapshots`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `snapshot_id` | PK | 免评结果快照 |\n| `exemption_plan_id` | FK | 免评计划 |\n| `snapshot_at` | datetime | 快照时间 |\n| `content_published_count` | int | 内容发布数 |\n| `click_count` | int | 点击 |\n| `code_usage_count` | int | Code 使用 |\n| `order_count` | int | 订单 |\n| `sales_amount` | decimal | 销售额 |\n| `weight_change_summary` | text | 权重变化摘要 |\n\n---\n\n## 19. 客服管理支撑层\n\n| 对象 | 关键字段 |\n| --- | --- |\n| `attendance_records` | `record_id`、`agent_id`、`date`、`scheduled_hours`、`actual_hours`、`status` |\n| `shift_schedules` | `shift_id`、`team_id`、`agent_id`、`date`、`shift_start`、`shift_end`、`max_tickets` |\n| `support_goal_records` | `goal_id`、`agent_id`、`period_key`、`goal_type`、`target_value`、`current_value` |\n| `support_performance_snapshots` | `snapshot_id`、`agent_id`、`period_key`、`tickets_handled`、`messages_sent`、`first_response_avg_sec`、`rso_orders`、`rdo_orders`、`reviews_obtained`、`review_completion_rate`、`monthly_target`、`monthly_completed` |\n\n---\n\n## 20. 逻辑关系总图\n\n```mermaid\nerDiagram\n PERSON_PROFILES ||--o{ PERSON_IDENTITY_LINKS : \"归并\"\n PERSON_PROFILES ||--o{ PERSON_FEATURE_SNAPSHOTS : \"画像\"\n PERSON_PROFILES ||--o{ CONTACT_CONTEXT_SNAPSHOTS : \"上下文\"\n PERSON_PROFILES ||--o{ PERSON_QUOTA_LEDGERS : \"额度台账\"\n PERSON_PROFILES ||--o{ QUOTA_RESERVATIONS : \"额度预占\"\n PERSON_PROFILES ||--o{ RISK_SIGNALS : \"风险信号\"\n PERSON_PROFILES ||--o{ RISK_CASES : \"风险案件\"\n PERSON_PROFILES ||--o{ AUDIENCE_SNAPSHOTS : \"人群入选\"\n PERSON_PROFILES ||--o{ AUDIENCE_EXCLUSIONS : \"人群排除\"\n PERSON_PROFILES ||--o{ CHANNEL_ROUTE_DECISIONS : \"路由\"\n PERSON_PROFILES ||--o{ CHANNEL_DEDUP_RECORDS : \"去重\"\n PERSON_PROFILES ||--o{ INTERACTION_RECHECK_RECORDS : \"互动复检\"\n PERSON_PROFILES ||--o{ IM_INTERACTION_RECORDS : \"IM\"\n PERSON_PROFILES ||--o{ IM_FLOW_TAGS : \"IM标签\"\n PERSON_PROFILES ||--o{ EDM_MESSAGE_EVENTS : \"EDM\"\n PERSON_PROFILES ||--o{ EDM_USER_BEHAVIOR_PROFILES : \"EDM画像\"\n PERSON_PROFILES ||--o{ APP_TOUCH_EVENTS : \"APP\"\n PERSON_PROFILES ||--o{ TEL_CALL_RECORDS : \"TEL\"\n PERSON_PROFILES ||--o{ SUPPORT_TICKETS : \"工单\"\n PERSON_PROFILES ||--o{ SUPPORT_FOLLOWUPS : \"跟进\"\n PERSON_PROFILES ||--o{ REVIEW_SUBMISSION_RECORDS : \"评价提交\"\n PERSON_PROFILES ||--o{ MANUAL_REVIEW_TASKS : \"人工复核\"\n REVIEW_SUBMISSION_RECORDS ||--o{ REVIEW_DISPLAY_CHECKS : \"展示核验\"\n SUPPORT_TICKETS ||--o{ SUPPORT_ASSIGNMENT_LOGS : \"分配\"\n RISK_CASES ||--o{ BLACKLIST_ENTITIES : \"同步\"\n AMAZON_REFUND_RECORDS ||--o{ REFUND_MATCH_RESULTS : \"退款比对\"\n OA_REFUND_RECORDS ||--o{ REFUND_MATCH_RESULTS : \"退款比对\"\n EXEMPTION_PLANS ||--o{ EXEMPTION_PLAN_TASKS : \"任务\"\n EXEMPTION_PLAN_TASKS ||--o{ CREATOR_CONTENT_RECORDS : \"内容\"\n EXEMPTION_PLANS ||--o{ EXEMPTION_RESULT_SNAPSHOTS : \"结果\"\n REVIEW_PLANS ||--o{ PLAN_TASK_LINKS : \"计划任务\"\n SHIFT_SCHEDULES ||--o{ SUPPORT_TICKETS : \"排班分配\"\n ATTENDANCE_RECORDS }o--|| SHIFT_SCHEDULES : \"出勤关联\"\n```\n\n---\n\n# 第五部分：数据流转\n\n## 21. 关键流转时序\n\n| 阶段 | 读（查） | 写 | 说明 |\n| --- | --- | --- | --- |\n| 真实人识别 | person_identity_links（已有线索） | person_profiles + person_identity_links（新线索） | 每次互动都先跑 |\n| 画像生成 | person_profiles + 七组画像数据 + 各渠道事件 | person_feature_snapshots | 定期或触发式刷新 |\n| 人群生成 | person_feature_snapshots + person_quota_ledgers + risk_signals | audience_snapshots + audience_exclusions + quota_reservations | 快照当下状态 |\n| 路由决策 | audience_snapshots + 用户状态 + 渠道可达性 | channel_route_decisions + channel_dedup_records | 选定渠道+去重 |\n| 渠道发送 | channel_route_decisions + quota_reservations + risk_signals（最新） | 各渠道事件表 | 发送前终校 |\n| 用户回应 | person_identity_links + person_quota_ledgers + risk_signals（全部重读） | interaction_recheck_records + 渠道事件表更新 + im_flow_tags | 每次互动复检留痕 |\n| 评价提交 | person_quota_ledgers（累计额度） | review_submission_records + person_quota_ledgers（+1） | 提交即计12 |\n| Amazon 展示确认 | review_submission_records | review_display_checks + 计划完成度更新 | 展示才计完成 |\n| 退款/返款 | amazon_refund_records + oa_refund_records | refund_match_results + risk_signals（如命中） | 双重退款检测 |\n\n## 22. 每次有效互动的标准写入顺序\n\n```mermaid\nflowchart LR\n A[\"互动发生\"] --> B[\"解析真实人
读 person_identity_links\"]\n B --> C[\"生成/更新上下文卡
写 contact_context_snapshots\"]\n C --> D[\"读取最新额度
读 person_quota_ledgers\"]\n D --> E[\"执行风险判断
读 risk_signals + blacklist\"]\n E --> F[\"写 interaction_recheck_records\"]\n F --> G{\"结果\"}\n G -->|正常| H[\"继续业务\"]\n G -->|预警| I[\"继续 + 高亮提醒\"]\n G -->|拦截| J[\"暂停 + 转人工/风险链路\"]\n```\n\n适用场景：主动推送后回复、用户再次联系、补充订单号、客服回访、TEL 来电、退款/返款/再次触达前。\n\n---\n\n# 第六部分：设计决策与边界\n\n## 23. 对象分类\n\n| 类型 | 对象 | 原因 |\n| --- | --- | --- |\n| **正式事务表** | `person_profiles`、`person_identity_links`、`support_tickets`、`support_followups`、`risk_cases`、`review_submission_records`、`quota_reservations` | 需要增删改和业务状态流转 |\n| **不可变事件表** | `im_interaction_records`、`edm_message_events`、`app_touch_events`、`tel_call_records`、`amazon_refund_records`、`oa_refund_records`、`support_assignment_logs`、`im_flow_tags` | 事实一旦发生不应被覆盖 |\n| **快照表** | `person_feature_snapshots`、`contact_context_snapshots`、`audience_snapshots`、`support_performance_snapshots`、`exemption_result_snapshots` | 需要保留某一时点状态以便复盘 |\n| **决策表** | `channel_route_decisions`、`channel_dedup_records`、`interaction_recheck_records`、`refund_match_results` | 保存系统当时为什么这样判断 |\n| **聚合画像** | `edm_user_behavior_profiles` | 由事件聚合推导，定期刷新 |\n| **可先做视图** | 当前剩余额度、当前风险摘要、当前上下文卡、当前人群统计看板、当前绩效看板 | 可由底层对象实时聚合 |\n\n### 判断法\n\n| 问题 | 如果答案是\"是\" |\n| --- | --- |\n| 后续需要追责\"当时为什么这么做\"吗 | 建正式表或决策表 |\n| 数据后来会变，但历史判断不能跟着变吗 | 建快照 |\n| 只是为了当前页面展示吗 | 优先做视图 |\n| 一旦发生就不该被覆盖吗 | 建事件表 |\n\n## 24. 当前还不能只靠\"老表扩列\"解决的事情\n\n| 问题 | 为什么不能只扩列 |\n| --- | --- |\n| 一个真实人多个账号 | `users` 是账号级，不是人级 |\n| 每次互动重判 | 不是用户静态属性，而是一次次决策事实 |\n| 人群为什么入选/排除 | 不是计划表字段，而是某一批次结果 |\n| 多计划并发占额度 | 需要独立预占 |\n| 用户提交与展示拆分 | 不是一个布尔值能表达 |\n| 退款比对 | 需要两个来源事实加一个比对结果 |\n| 客服上下文 | 不是工单表本身，而是跨源聚合视图+快照 |\n\n## 25. 当前可以先不做成物理表的内容\n\n| 内容 | 当前建议 |\n| --- | --- |\n| 当前剩余额度 | 先由 `person_quota_ledgers + quota_reservations` 聚合成视图 |\n| 当前风险摘要 | 先由 `risk_signals + risk_cases + blacklist_entities` 聚合成视图 |\n| 当前客服上下文卡 | 前台读当前视图，关键接入动作时写 `contact_context_snapshots` |\n| 当前人群统计看板 | 先基于 `audience_snapshots / exclusions` 聚合 |\n| 当前绩效看板 | 先基于工单、通话、跟进事件聚合，后续再沉淀快照 |\n\n## 26. 外部数据引用原则\n\n| 外部数据 | 所属系统 | USER 当前做法 |\n| --- | --- | --- |\n| Amazon 订单全量明细 | Amazon API/报表 | 导入关键字段，不把 USER 做成全量订单数仓 |\n| JOYHUB 用户行为明细 | APP/用户系统 | 取摘要或增量同步，用于画像与上下文 |\n| 黑名单全量数据 | 黑名单系统 | 引用并缓存关键维度，不重复建设 |\n| JOYCOLLAB 全量内容与带货明细 | JOYCOLLAB | 同步 USER 闭环所需结果摘要 |\n| 财务/人事原始表 | 财务/人事系统 | 导入必要摘要，不替代源系统 |\n\n## 27. 涉密字段处理\n\n| 涉密字段 | 建议存储 | 建议查询 |\n| --- | --- | --- |\n| 订单号 | 哈希索引 + 加密原值 | 常规用哈希匹配 |\n| 邮箱 | 哈希索引 + 脱敏展示 | 普通页面不暴露明文 |\n| 电话 | 哈希索引 + 加密原值 | 仅授权角色可揭示 |\n| 姓名/地址 | 标准化值 + 哈希/指纹 | 归并与风险用指纹 |\n| 设备号 | 哈希索引 | 归并/风险用哈希 |\n| IP | 脱敏存储 | 仅用于弱关联 |\n| 收款信息 | 加密存储 | 财务/风险授权查看 |\n| 返款金额/提成 | 权限控制 | 财务角色优先 |\n\n## 28. 快照策略\n\n| 快照对象 | 生成时机 | 保留策略 |\n| --- | --- | --- |\n| `person_feature_snapshots` | 定期刷新 + 人群生成前触发 | 保留最近 N 版 + 每次人群生成引用的版本 |\n| `contact_context_snapshots` | 用户接入/工单创建/拨打前/风险升级 | 每次生成新快照，保留全量历史 |\n| `audience_snapshots` | 人群生成时 | 每次计划保留 |\n| `edm_user_behavior_profiles` | EDM 画像定时刷新 | 按刷新批次保留 |\n| `support_performance_snapshots` | 每日/每周/每月 | 按周期聚合保留 |\n| `exemption_result_snapshots` | 免评执行阶段性同步 | 按结果周期保留 |\n\n---\n\n# 第七部分：谁写谁读\n\n## 29. 读写矩阵\n\n| 对象 | 主要写入方 | 主要读取方 | 依赖它的动作 |\n| --- | --- | --- | --- |\n| `person_profiles` | 身份归并服务 | 用户运营、客服、风险 | 所有真实人级判断 |\n| `person_identity_links` | 身份归并服务 | 风险、客服、订单核验 | 真实人识别 |\n| `person_feature_snapshots` | 画像任务 | 人群生成、客服 | 画像筛选 |\n| `contact_context_snapshots` | 上下文聚合服务 | 客服、用户运营 | 接入处理 |\n| `person_quota_ledgers` | 额度服务 | 人群生成、渠道、客服 | 4/4/12 判断 |\n| `quota_reservations` | 人群/计划服务 | 渠道、额度服务 | 发送前拦截 |\n| `audience_snapshots` | 人群生成服务 | 计划、复盘 | 解释入选 |\n| `channel_route_decisions` | 路由服务 | 推送、复盘 | 选渠道 |\n| `interaction_recheck_records` | 互动复检服务 | 客服、风险、审计 | 决定继续/拦截 |\n| `review_submission_records` | 客服/IM/TEL | 额度、计划、客服 | 计入12 |\n| `review_display_checks` | 运营/系统 | 计划、ASIN看板 | 计入完成 |\n| `refund_match_results` | 退款比对服务 | 风险、客服、财务 | 拦截双重退款 |\n\n---\n\n## 30. 还需要确认但不阻塞第三步的事项\n\n| 事项 | 影响 |\n| --- | --- |\n| Amazon 订单同步频率最终是否为 10 分钟 | 影响订单/退款数据新鲜度 |\n| 黑名单系统最终通过 API、表格还是消息同步 | 影响 `blacklist_entities` 同步方式 |\n| Amazon Profile ID 是否稳定获取 | 影响强关联覆盖率 |\n| APP 设备型号能否拿到具体型号还是只到类型 | 影响客服展示颗粒度 |\n| 年龄字段来自注册资料还是推断 | 影响画像可信度 |\n| KOC/KOL 结果同步周期 | 影响免评结果快照频率 |\n\n---\n\n## 31. 第四步入口\n\n1. **把数据对象转成逻辑 ER 图**：以 §20 的 Mermaid ER 图为基础，明确主键、外键、1对多/多对多关系，区分复用旧表和新增表。\n2. **按关键链路补接口读写**：\n 1. 真实人识别与上下文链路\n 2. 人群/额度/路由链路\n 3. 互动复检/风险链路\n 4. 评价提交/展示与退款比对链路\n 5. 免评结果链路\n3. **回到页面，把每一个点击绑定到明确的数据读写**。\n\n---\n\n## 32. 本版结论\n\nv3 以 Codex v1.1 完整字段字典为主骨架，补入 v2 的流转时序表、写入顺序图和快照策略，形成最终统一主稿：\n\n1. 用 **真实人** 统一账号、订单、设备和风险\n2. 用 **画像快照** 解释人群生成\n3. 用 **额度台账+预占** 保护 4/4/12 规则（跨账号合并）\n4. 用 **路由决策+去重记录** 控制多渠道协同\n5. 用 **互动复检记录** 落实\"每次有效互动都重判\"\n6. 用 **退款比对结果** 识别双重退款\n7. 用 **评价提交记录+展示核验** 拆开用户事实和平台结果\n8. 用 **免评计划→任务→内容→结果快照** 让 KOC/KOL 闭环完整进入 USER 系统\n", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2", "type": "document", "name": "USER 评价业务闭环主流程与后续工作基线 v1.2", "filePath": "05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md", "summary": "USER 评价业务闭环主流程与后续工作基线 v1.2 文件信息 文件名称： 20260517 USER评价业务闭环主流程与后续工作基线 v1.2.md 项目路径： C:\\XCODE\\USER 当前版本： v1.2 最近更新： 2026 05 17 前一版本： 20260517 USER评价业务闭环主流程与后续工作基线 v1.1.md 文件目的：在既有销售到评", "tags": [ "05_需求文档", "需求文档" ], "complexity": "moderate", "knowledgeMeta": { "content": "# USER 评价业务闭环主流程与后续工作基线 v1.2\n\n## 文件信息\n\n- 文件名称：`20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md`\n- 项目路径：`C:\\XCODE\\USER`\n- 当前版本：`v1.2`\n- 最近更新：`2026-05-17`\n- 前一版本：`20260517_USER评价业务闭环主流程与后续工作基线_v1.1.md`\n- 文件目的：在既有销售到评价闭环基线上，补入真实人识别、测评 / 免评额度、用户历史上下文、IM / EDM / TEL / 客服细化口径，作为新版第二步和后续数据流设计的统一依据。\n- 适用范围：当前阶段的 Amazon 业务闭环设计；如后续扩展到独立站或非 Amazon 评价体系，需要在本文件基础上另行增补。\n- 使用方式：下一次继续本项目时，先读取本文件，再读取 `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`，不要再从旧版页面链路重新推导业务主干。\n\n---\n\n## 版本记录\n\n| 版本 | 日期 | 说明 |\n| --- | --- | --- |\n| v1 | 2026-05-17 | 首次固化销售到评价完成的 USER 业务闭环主流程 |\n| v1.1 | 2026-05-17 | 将免评改为独立闭环；明确每次有效互动都要重新做身份与风险判断；明确当前版本不单列商家角色 |\n| v1.2 | 2026-05-17 | 补入用户历史与设备上下文、真实人级 `测评4 / 免评4 / 累计真实提交评价12` 规则、IM / EDM / TEL / 客服新增细节，并把第二步入口改为“共用能力 + 渠道专属流程” |\n\n---\n\n## 1. 已确认目标\n\n1. 系统要支持 USER 部门工作，而不是只做一个回评记录工具。\n2. 业务流必须从“销售发生 / 需求形成”开始，而不是从“推送”开始。\n3. Amazon 运营既可以人工提需求，系统也可以因 Listing 健康或评价缺口自动触发需求。\n4. 用户运营是“需求评估 + 计划调度中心”，负责把需求转成可执行计划并跟踪结果。\n5. 计划类型必须正式保留：\n - 推新计划\n - 回评计划\n - 免评计划\n6. `免评计划` 不是边缘例外，而是需要正式保留的关键业务类型；其与 KOC / KOL、社媒带货、站外流量和 Amazon 权重有关。\n7. 用户提交评价与系统确认评价完成必须拆成两个节点：\n - 用户已真实提交评价\n - Amazon 已展示 / 系统已确认计入计划完成\n8. `真实人` 是后续额度、风险、历史和用户画像的核心对象，不应只围绕某个 JOYHUB ID、邮箱或 Amazon 账号看用户。\n9. 已确认的额度规则为：\n - 同一真实人每月最多参与 `4 次测评`\n - 同一真实人每月最多参与 `4 次免评`\n - 同一真实人累计最多计入 `12 个真实提交的评价`\n10. `12` 的计数时点是 `用户真实提交评价`，不是 `Amazon 展示评价`。\n11. 每次有效互动都要重新做身份、历史、额度和风险判断；主动推送后的回复也不例外。\n12. 客服接入时必须能快速看到用户历史、订单历史、设备上下文、既往风险和当前提醒，而不是只看到当前对话。\n13. 后续系统设计顺序已经确定：\n 1. 先定业务流\n 2. 再做点击操作模拟\n 3. 最后根据业务需求整合现有数据，形成新的数据流和中间表需求\n\n---\n\n## 2. 当前边界与资料依据\n\n### 2.1 当前纳入范围\n\n- Amazon 业务\n- 销售到评价闭环\n- 推新、回评、免评\n- IM、EDM、APP、TEL、KOC / KOL\n- 售后接入\n- 客服执行与客服管理支撑\n- 黑名单与诈骗风险\n- ASIN 健康回流\n\n### 2.2 当前不作为本版主流程展开的内容\n\n- 独立站全链路\n- 完整 BI / 财务 / ROI 系统\n- 完整 KOC / KOL 结算系统\n- 所有历史后台页面逐页重构\n- 数据库最终物理设计\n\n### 2.3 资料依据\n\n本文件基于以下材料整理：\n\n1. `C:\\XCODE\\USER\\评价业务流闭环项目架构文档_v0.8.docx`\n2. `C:\\XCODE\\USER\\docs\\evaluation-business-architecture.md`\n3. `C:\\XCODE\\USER\\docs\\project-phase-one-plan.md`\n4. `C:\\XCODE\\USER\\output\\docs\\20260503_USER后台ERP一期功能与页面设计_v4.md`\n5. `C:\\XCODE\\USER\\output\\docs\\20260503_USER后台ERP自动推送与计划状态机_v4.md`\n6. `C:\\XCODE\\USER\\output\\docs\\20260503_USER后台ERP一期页面原型说明_v4.md`\n7. `C:\\XCODE\\USER\\output\\docs\\20260503_USER后台ERP_MVP角色首页UI规划_v1.md`\n8. `C:\\tcode\\飞书\\飞书聊天记录库\\cloud_files` 中当前主原型 HTML 与 `客服执行.html`\n9. `C:\\Users\\wu_zh\\Downloads\\20260407-法国诈骗问题（已扩散美国）.docx`\n10. `C:\\Users\\wu_zh\\Desktop\\表头.xlsx`\n11. `C:\\Users\\wu_zh\\Downloads\\IM 推送业务流.mm`\n12. `C:\\Users\\wu_zh\\Downloads\\后台回评工作流对接事项.docx`\n13. `C:\\Users\\wu_zh\\Downloads\\客服相关模块.docx`\n14. `C:\\Users\\wu_zh\\Downloads\\电话业务流程知识库.docx`\n15. 用户在当前对话中补充确认的业务规则\n\n若历史资料与当前对话确认口径冲突，以当前对话中最新确认口径为准。\n\n---\n\n## 3. 角色与职责\n\n| 角色 | 核心职责 |\n| --- | --- |\n| Amazon 运营 | 依据销售、ASIN、评价目标提出推新 / 回评 / 免评需求 |\n| Amazon 运营总监 | 审批相关计划，确认优先级与业务必要性 |\n| 品牌运营 | 负责品牌推广、站外节奏和与用户运营 / 内容运营协同 |\n| 内容运营 | 承接社区广告、APP 广告位、内容流量等侧向支持 |\n| 用户运营 | 评估需求、生成计划、分配资源、协调渠道、跟踪结果 |\n| 用户运营负责人 / 组长 | 复核计划、分配组员、处理重点风险和异常 |\n| 菲律宾客服负责人 | 关注工单压力、分配客服组、处理升级工单、查看绩效 |\n| 菲律宾客服组长 | 分配组内工单、复核升级、控制逾期和重点工单 |\n| 菲律宾客服组员 | 实际接待、电话沟通、记录、回复、回访、提交疑似诈骗 |\n| 风险 / 黑名单相关人员 | 接收诈骗疑似、复核、同步黑名单、维护风险口径 |\n| KOC / KOL 运营 | 承接站外带货、合作关系、内容和导购协同 |\n\n当前版本不单列“商家 / 商家运营”角色。这里的“商家”如出现，均按 Amazon 卖家侧语义理解，由 Amazon 运营承接；品牌商当前也只纳入 Amazon 内评价相关协同。\n\n---\n\n## 4. 总体业务结构\n\n### 4.1 主流程\n\n```mermaid\nflowchart LR\n A[\"销售发生 / ASIN销售数据形成\"] --> B[\"需求触发\"]\n B --> B1[\"Amazon运营人工提需求\"]\n B --> B2[\"系统按评价缺口或Listing健康自动触发\"]\n B1 --> C[\"用户运营评估需求\"]\n B2 --> C\n C --> D[\"形成业务计划\"]\n D --> D1[\"推新计划\"]\n D --> D2[\"回评计划\"]\n D --> D3[\"免评计划\"]\n D1 --> E[\"规则 / 风险 / 额度复核\"]\n D2 --> E\n D3 --> E\n E --> F[\"审批通过\"]\n F --> G[\"执行拆解\"]\n G --> H1[\"评价型执行闭环\"]\n G --> H2[\"免评型执行闭环\"]\n H1 --> I1[\"IM / EDM / APP / TEL / 客服协同\"]\n I1 --> J1[\"用户被触达或主动进入\"]\n J1 --> K1[\"每次有效互动均重做身份 / 历史 / 额度 / 风险核验\"]\n K1 --> L1[\"服务 / 售后 / 跟进\"]\n L1 --> M1[\"用户真实提交评价\"]\n M1 --> N1[\"计入真实人累计评价额度\"]\n N1 --> O1[\"Amazon是否展示 / 系统是否确认完成\"]\n O1 --> P[\"结果回流\"]\n H2 --> I2[\"KOC / KOL为核心，IM / EDM / APP等协同参与\"]\n I2 --> J2[\"内容发布 / 站外引流 / 带货执行\"]\n J2 --> K2[\"跟踪点击、Code、订单、转化与权重结果\"]\n K2 --> P\n P --> Q[\"更新ASIN健康、计划完成度、用户画像、流量结果、风险记录\"]\n Q --> C\n```\n\n### 4.2 五个业务层\n\n| 业务层 | 说明 |\n| --- | --- |\n| 经营层 | 销售、ASIN、需求、品牌 / 内容 / KOC-KOL 侧影响 |\n| 计划层 | 推新、回评、免评、审批、规则、额度、风险 |\n| 执行层 | IM、EDM、APP、TEL、客服工单、KOC / KOL 协作 |\n| 服务与身份层 | 用户接入、真实人归并、订单核验、用户上下文、售后处理 |\n| 结果与风险层 | 用户真实提交评价、Amazon 展示确认、免评结果、黑名单、诈骗、结果回流 |\n\n---\n\n## 5. 主流程详细说明\n\n| 阶段 | 业务说明 | 必须检查 | 主要输出 |\n| --- | --- | --- | --- |\n| 1. 销售与需求形成 | 销售发生后，Amazon 运营根据目标或系统根据健康度触发需求 | 销售、ASIN、评分、评价缺口、历史计划 | 新需求 |\n| 2. 用户运营评估 | 判断需求是否成立、是否可做、优先级如何 | ASIN 健康、目标数量、历史完成、当前资源、风险 | 已确认需求 / 待补充 / 驳回 |\n| 3. 计划生成 | 将需求转为推新、回评或免评计划 | 用户池、渠道容量、目标、周期 | 计划草案 |\n| 4. 计划复核与审批 | 对计划做规则、额度和风险复核，再进入审批 | 黑名单、频控、渠道风险、真实人额度、审批权限 | 已批准计划 |\n| 5. 执行拆解 | 把计划拆成渠道任务和人工任务 | 可触达用户、素材、客服负载、KOC / KOL协作 | 推送任务 / TEL任务 / 客服工单 / 协作任务 |\n| 6A. 评价型执行 | 推新、回评进入用户触达、服务与评价链路 | 真实人、订单、历史、额度、风险、售后情况 | 当前处理路径 |\n| 6B. 免评型执行 | 免评以 KOC / KOL 与站外流量为核心，同时可由 IM / EDM / APP 等协同参与 | 合作对象、内容、Code、渠道、素材、节奏、免评额度 | 内容任务 / 引流任务 / 带货任务 |\n| 7A. 用户真实提交评价 | 记录用户是否已经实际提交评价 | 用户反馈、提交证据、对应计划、真实人累计额度 | 已提交评价事实 |\n| 7B. 免评结果跟踪 | 记录免评计划的执行结果 | 内容发布、点击、Code、订单、转化、销量、权重变化 | 免评执行结果 |\n| 8. 评价确认 | 区分用户提交与 Amazon 展示结果 | Amazon 是否展示、是否能核验、是否属本计划 | 计入完成 / 待确认 |\n| 9. 结果回流 | 把评价结果与免评结果重新反馈给经营与计划层 | 计划完成、ASIN 健康、流量结果、风险变化、用户标签 | 新一轮决策输入 |\n\n---\n\n## 6. 关键业务支线\n\n### 6.1 主动触达支线\n\n```mermaid\nflowchart LR\n A[\"计划通过\"] --> B[\"筛选可触达用户池\"]\n B --> C[\"真实人识别 + 人群画像 + 额度校验\"]\n C --> D[\"渠道分配\"]\n D --> D1[\"IM\"]\n D --> D2[\"EDM\"]\n D --> D3[\"APP\"]\n D --> D4[\"TEL\"]\n D1 --> E[\"用户回应\"]\n D2 --> E\n D3 --> E\n D4 --> E\n E --> F[\"每次回应都重做身份 / 历史 / 额度 / 风险核验\"]\n F --> G[\"订单核验\"]\n G --> H[\"服务 / 跟进\"]\n H --> I[\"用户真实提交评价\"]\n```\n\n#### 关键规则\n\n1. IM、EDM、APP 可自动化；TEL 属于人工执行渠道。\n2. `IM` 需要识别用户分层、绑定玩具、设备、测评 / 免评额度和标签流转。\n3. `EDM` 需要识别最近打开、最近回复、点击评论链接但未回复、月度收信次数、最近 3 / 5 次 0 打开、邮箱类型、退订和硬退信。\n4. 计划生成前必须先检查：\n - 用户是否可触达\n - 是否命中风险\n - 是否超频\n - 是否符合站点 / 国家 / 产品目标\n - 是否接近或达到真实人额度上限\n5. 用户回应后，不能沿用上一次判断结果，必须重新检查当前身份、订单、设备、地址、历史、额度与风险状态。\n\n### 6.2 免评执行支线\n\n```mermaid\nflowchart LR\n A[\"免评计划通过\"] --> B[\"拆解执行方案\"]\n B --> C1[\"KOC / KOL协作\"]\n B --> C2[\"IM / EDM / APP辅助触达\"]\n B --> C3[\"内容 / 运营协同\"]\n C1 --> D[\"内容发布 / Code使用 / 站外引流\"]\n C2 --> D\n C3 --> D\n D --> E[\"跟踪点击、跳转、Code、订单、转化、销量与权重变化\"]\n E --> F[\"结果回流到ASIN健康与后续计划\"]\n```\n\n#### 关键规则1\n\n1. 免评计划不是评价型计划的弱化版本，而是以站外流量、带货、销量和权重结果为终点的独立闭环。\n2. KOC / KOL 是免评计划的核心执行通道，但 IM、EDM、APP 等也可以参与协同。\n3. 同一真实人每月最多参与 `4 次免评`；免评额度也要做预警、预占和拦截。\n4. 免评计划不以“用户提交评价”作为完成条件，必须另行跟踪内容发布、Code、点击、订单、转化、销量和权重变化。\n5. 如果免评执行过程中发生用户互动、售后或返款等行为，仍须进入统一的身份与风险判断机制。\n\n### 6.3 被动售后与 TEL 支线\n\n```mermaid\nflowchart LR\n A[\"用户主动联系 / 电话呼入\"] --> B[\"接入即预查\"]\n B --> C[\"识别来源、身份、订单、历史、风险\"]\n C --> D{\"是否有售后问题\"}\n D -->|有| E[\"问题分类与解决方案\"]\n E --> F[\"确认是否解决 / 是否满意\"]\n F --> G[\"满意后进入回评 / 测评邀请\"]\n D -->|无| H[\"确认无其他需求\"]\n H --> I[\"可进入测评邀请\"]\n G --> J[\"记录电话 / 工单 / 后续跟进\"]\n I --> J\n```\n\n#### 关键规则2\n\n1. TEL 当前至少包含两类入口：\n - 计划生成后的人工外呼任务\n - 用户从 Amazon 页面或说明书主动呼入\n2. 有售后问题时，必须先解决售后，再谈评价或测评邀请。\n3. 电话中需要尽量确认：\n - 购买平台\n - 订单号\n - 产品型号 / 款式 / 颜色\n - 购买时间\n - 问题类型\n - 是否有图片、视频或其他凭证\n4. 每通电话结束后，至少要记录：\n - 来电时间\n - 来源\n - 联系方式\n - 订单号\n - 问题类型和描述\n - 处理方案\n - 是否已解决\n - 是否需要后续跟进\n - 是否邀请测评 / 回评\n - 用户是否接受\n5. 当前电话业务的核心是：\n - 自然单回评转化\n - 充分利用电话用户的测评资源\n\n### 6.4 风险 / 诈骗拦截支线\n\n```mermaid\nflowchart LR\n A[\"新订单同步 / 主动触达回应 / 用户接入 / 退款申请 / 再次跟进\"] --> B[\"重新做风险识别\"]\n B --> C{\"是否命中强关联\"}\n C -->|是| D[\"直接进入高风险或黑名单链路\"]\n C -->|否| E{\"是否命中弱关联\"}\n E -->|是| F[\"进入高风险观察 + 人工复核\"]\n E -->|否| G[\"继续正常流程\"]\n D --> H[\"拦截自动退款、继续推送、自动放行\"]\n F --> H\n H --> I[\"提醒客服 / 用户运营 / 审核人员\"]\n```\n\n#### 已确认风险口径\n\n| 风险类型 | 关联项 | 处理原则 |\n| --- | --- | --- |\n| 强关联 | 邮箱、设备号、电话、收件人姓名+地址、订单号、聊天记录、Profile ID、收款信息 | 一旦命中，可直接进入高风险或黑名单链路 |\n| 弱关联 | IP 单独命中、姓名单独命中、同址异名 | 进入高风险观察，不直接认定诈骗 |\n\n#### 已确认业务问题\n\n1. 当前真实事故中存在“双重退款”风险：\n - APP / OA 已退款\n - 用户又向 Amazon 申请退款\n2. 需要把 Amazon 退款与 OA 返款自动比对。\n3. 高风险用户一旦标记，支付 / 返款需要人工复核。\n4. 客服、审核、退款等环节必须都能看到风险提醒。\n5. 非 APP 用户如果直接走邮件退款，因缺少设备、注册邮箱等维度，风险识别能力明显下降。\n6. 风险判断不是一次性的接入动作，而是每次有效互动都要重新执行。\n\n### 6.5 客服工单与客服管理支线\n\n```mermaid\nflowchart LR\n A[\"用户消息进入 / 推送转人工 / 售后触发 / 风险触发\"] --> B[\"生成工单\"]\n B --> C[\"按班次、在线状态、当前负载自动分配\"]\n C --> D[\"客服处理\"]\n D --> E{\"处理结果\"}\n E -->|等待用户| F[\"等待用户回复\"]\n E -->|等待内部| G[\"等待内部协同\"]\n E -->|答应配合| H[\"生成后续跟进\"]\n E -->|疑似诈骗| I[\"转风险链路\"]\n E -->|已解决| J[\"关闭工单\"]\n D --> K[\"回复效率 / 转化 / 目标完成统计\"]\n```\n\n#### 工单与管理事实\n\n1. 客服相关模块不只包括工单，还包括：\n - 出勤管理\n - 排班管理\n - 回复效率统计\n - 转化统计\n - 目标管理\n2. `排班` 与 `在线状态` 会直接影响自动分配。\n3. `工单状态`、`答应配合状态`、`风险状态` 必须拆开存。\n4. 客服转化要区分：\n - RSO 回评\n - RDO 测评\n5. 回复效率至少要统计：\n - 回复用户数\n - 处理工单数\n - 发送消息数\n - 平均 / 中位数 / 最大 / 最小首次回复时长\n6. 转化统计至少要看：\n - 登记订单数\n - 获取评价数\n - 评价完成率\n7. 主管需要看到出勤、排班、绩效、目标完成和工单分配，而不是只看单个会话。\n\n---\n\n## 7. 真实人识别、用户上下文与额度规则\n\n### 7.1 真实人识别原则\n\n1. 当前系统不应只围绕 `JOYHUB ID` 看用户，而应同时围绕：\n - 账号\n - 订单\n - 实际收件人\n - 设备\n - 联系方式\n - 风险关系\n2. 如果用户在 JOYHUB 内提交订单，则订单可直接关联到当前 JOYHUB ID。\n3. 如果用户通过邮件联系：\n - 先问是否有 JOYHUB ID\n - 再用注册邮箱与 JOYHUB ID 做关系查询\n4. 如果用户通过电话联系：\n - 先确认是否注册 APP\n - 结合电话、订单、收件人、地址、设备、邮箱继续识别\n5. 非 APP 用户如需继续参与相关流程，应优先引导注册 APP，再继续后续动作。\n\n### 7.2 实际收件人判定\n\n| 情况 | 处理原则 |\n| --- | --- |\n| 标准化后姓名 + 地址完全一致 | 直接认为是同一实际收件人 |\n| 地址一致但姓名不同 | 只认为存在家庭 / 关联风险，不直接判定同一人 |\n| 邮箱不同、JOYHUB ID 不同 | 不能单独否定“同一实际人” |\n| 订单号命中历史异常 | 应立即拉出历史上下文和风险记录 |\n\n### 7.3 用户上下文卡\n\n客服和用户运营在必要节点应能看到：\n\n| 字段组 | 例子 |\n| --- | --- |\n| 当前身份 | JOYHUB ID、邮箱、电话、真实人 ID、当前订单 |\n| 历史交易 | 历史订单、最近购买、退款 / 返款、目标 ASIN 购买情况 |\n| 历史服务 | 历史工单、聊天、电话、承诺、提醒、关闭原因 |\n| 历史风险 | 黑名单、关联账号、疑似诈骗、双重退款、异常订单 |\n| 当前设备 | 设备号摘要、设备型号 / 类型、系统版本、APP 版本、最近设备变化 |\n| 触达历史 | IM / EDM / APP / TEL 最近触达、回复、退订、投诉 |\n\n### 7.4 额度规则\n\n| 规则 | 统计对象 | 计数口径 |\n| --- | --- | --- |\n| 月度测评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 |\n| 月度免评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 |\n| 累计真实提交评价最多 12 个 | 真实人 | 用户真实提交评价后立即计数 |\n\n### 7.5 额度控制原则\n\n1. 额度判断必须放在 `真实人识别` 之后，而不是只看单一账号。\n2. 系统不能等到真正超限才提示，必须在接近上限时提前预警。\n3. 一旦 `已用 + 进行中 + 已预占 + 本次拟发送` 会导致超限，就不能进入自动推送。\n4. `Amazon 未展示` 不影响 12 次累计额度，因为口径已经确认按 `真实提交` 计数。\n\n---\n\n## 8. 渠道专属补充事实\n\n### 8.1 IM\n\n- 用户需要分层：未参与过、参与过、长期测评人。\n- 触发条件包括注册 App、绑定玩具、识别绑定产品。\n- 需要校验设备 ID、黑名单、绑定产品、额度与标签。\n- 用户提交订单号、返款账号、评论截图 / 链接后，要继续做订单核验和资格登记。\n\n### 8.2 EDM\n\n- EDM 不是简单“发邮件”，而是独立的筛选与节奏引擎。\n- 需要支持：\n - 最近打开时间\n - 最近回复时间\n - 打开次数\n - 最近 3 / 5 次推送 0 打开\n - 点击评论链接但未回复时长\n - 单月收信次数\n - 各邮件类型发送次数\n - 邮箱后缀标签\n - 国家站点\n - 退订、硬退信、风险用户、黑名单、OA 无资格用户排除\n\n### 8.3 APP\n\n- APP 侧至少要纳入：\n - 注册邮箱\n - 设备号\n - 设备型号 / 类型\n - APP 版本\n - 系统版本\n - 用户行为数据\n - 绑定玩具\n - 活跃与点击行为\n- APP 不只是触达渠道，也是身份识别、设备变化和行为画像的重要来源。\n\n### 8.4 TEL\n\n- TEL 同时承担主动外呼和被动来电。\n- 其价值不只是“打电话”，而是：\n - 解决售后\n - 捕捉自然单回评机会\n - 充分利用电话用户的测评资源\n\n---\n\n## 9. 评价结果规则\n\n### 9.1 必须拆开的两个节点\n\n```mermaid\nflowchart LR\n A[\"用户已真实提交评价\"] --> B[\"计入真实人累计评价额度\"]\n B --> C{\"Amazon是否展示 / 是否可核验\"}\n C -->|展示或可核验| D[\"计入计划完成\"]\n C -->|未展示 / 暂不可核验| E[\"保留用户已提交事实\"]\n E --> F[\"进入待确认 / 异常观察\"]\n D --> G[\"更新ASIN健康与计划完成度\"]\n```\n\n### 9.2 原因\n\n1. 用户可能确实已经提交评价。\n2. Amazon 可能因为其他原因不展示该评价。\n3. `额度计数` 与 `计划完成确认` 不是同一个业务事实。\n4. 如果系统只保留一个“评价完成”状态，会把平台展示问题错误归因给执行人员或用户。\n\n---\n\n## 10. 贯穿全程的数据检查点\n\n| 检查点 | 发生时机 | 核心检查 |\n| --- | --- | --- |\n| 经营检查 | 需求形成前 | 销售、ASIN、评分、评价缺口、历史计划 |\n| 计划检查 | 生成计划前 | 人群、渠道、容量、规则、黑名单 |\n| 画像检查 | 生成人群时 | 国家、站点、性别、年龄、绑定玩具、产品关系、活跃、历史行为 |\n| 额度检查 | 生成人群、发送前、继续推进前 | 测评 4、免评 4、累计真实提交 12、进行中与已预占 |\n| 身份检查 | 首次接入与每次有效互动时 | JOYHUB、邮箱、电话、设备、订单、地址、历史记录 |\n| 互动复检 | 主动触达回应、再次联系、补充订单号、客服回访时 | 关键属性是否变化，是否出现新订单、新地址、新设备、新返款记录 |\n| 风险检查 | 每次有效互动、退款、返款、继续推送前 | 双重退款、强弱关联、黑名单、历史异常 |\n| 结果检查 | 评价提交与确认后 | 首评 / 回评、是否属本计划、是否展示、ASIN 健康变化 |\n\n---\n\n## 11. 第二步的新入口\n\n第二步不再按旧版页面链路推进，而改成：\n\n### 11.1 共用能力图\n\n1. 真实人识别与用户上下文卡\n2. 人群生成与画像拆解\n3. 额度与频控控制\n4. 每次有效互动复检\n5. 风险与黑名单\n\n### 11.2 渠道 / 模块专属流程图\n\n1. IM\n2. EDM\n3. APP\n4. TEL\n5. 客服工单\n6. 客服管理支撑\n7. 评价完成\n8. 免评执行\n\n### 11.3 每张图都必须回答\n\n- 进入条件是什么\n- 要先查什么\n- 如何判断\n- 写入什么\n- 状态怎么变\n- 何时提醒\n- 何时拦截\n- 何时转人工\n\n---\n\n## 12. 下一次继续工作时的直接提示\n\n1. 先读取本文件。\n2. 不要重新讨论“是否从销售开始”“是否保留免评”“评价提交与展示是否拆开”，这些已确认。\n3. 额度口径按当前版本执行：\n - 测评每月最多 4\n - 免评每月最多 4\n - 同一真实人累计真实提交评价最多 12\n4. 不要再把风险判断理解成“首次接入才做一次”；每次有效互动都需要重做判断。\n5. 不要再把第二步按页面链路拆；直接进入 `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`。\n6. 旧版 `v1` / `v1.1` 保留为历史版本，不再作为后续主口径。\n\n---\n\n## 13. 本版结论\n\nUSER 部门未来系统的核心，不是单独记录“谁评价了”，而是把以下内容放进同一条可追踪闭环中：\n\n1. 销售与需求\n2. 计划生成与审批\n3. 真实人识别与用户上下文\n4. 测评 / 免评 / 累计评价额度控制\n5. IM / EDM / APP / TEL / 客服协同\n6. 用户身份与订单核验\n7. 售后服务与评价引导\n8. 免评执行与站外流量结果\n9. 用户真实提交评价\n10. Amazon 展示与系统确认\n11. ASIN 健康回流\n12. 风险与黑名单拦截\n\n只有这条闭环建立起来，后续的点击设计、页面设计和数据设计才不会彼此脱节。\n", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/evaluation-business-architecture", "type": "document", "name": "评价业务流闭环项目架构文档", "filePath": "05_需求文档/evaluation-business-architecture.md", "summary": "评价业务流闭环项目架构文档 版本：v0.7 更新时间：2026 04 26 当前阶段：业务框架搭建与部门业务梳理 1. 文档目标 本文档用于沉淀评价业务流闭环的业务结构、部门职责、核心数据、看板规划和后续项目规划依据。 当前重点不是直接进入系统设计，而是先明确： 业务闭环如何运转 各部门在闭环中的职责边界 每个部门需要哪些看板与数据字段 APP 与亚马逊运营", "tags": [ "05_需求文档", "需求文档" ], "complexity": "complex", "knowledgeMeta": { "content": "# 评价业务流闭环项目架构文档\n\n版本：v0.7 \n更新时间：2026-04-26 \n当前阶段：业务框架搭建与部门业务梳理\n\n## 1. 文档目标\n\n本文档用于沉淀评价业务流闭环的业务结构、部门职责、核心数据、看板规划和后续项目规划依据。\n\n当前重点不是直接进入系统设计，而是先明确：\n\n- 业务闭环如何运转\n- 各部门在闭环中的职责边界\n- 每个部门需要哪些看板与数据字段\n- APP 与亚马逊运营、品牌运营、内容运营、用户运营、客服运营之间的数据关系\n- 后续项目需要支持哪些管理动作、数据归因和异常预警\n\n## 2. 总体业务闭环\n\n### 2.1 当前业务主链路\n\n亚马逊运营、品牌运营、内容运营负责拉新与引流。 \n主要带来曝光和点击，其中当前主要流量来源于亚马逊，小部分开始来源于社媒与网站宣发。\n\n↓\n\n亚马逊运营负责亚马逊渠道转化与成交，品牌运营负责独立站转化与成交。\n\n↓\n\n成交后产生订单与成交数据。\n\n↓\n\n用户运营基于成交用户、绑定用户、活跃用户进行触达推送与索评。 \n同时，用户运营或评价运营需要维护 ASIN 健康度，核心依赖回评结果。\n\n↓\n\n客服运营收集售后问题、用户反馈、负面反馈和评价相关问题，并执行处理与改善动作。\n\n↓\n\n数据层和管理层进行复盘，调整产品策略、销售策略、推送策略、评价策略和人员分工。\n\n### 2.2 闭环中的核心角色\n\n| 角色/部门 | 主要职责 | 当前定位 |\n|---|---|---|\n| 亚马逊运营 | 亚马逊销售、产品销售管理、测评计划需求、免评计划需求、关键词推新、评价健康维护协同 | 当前 APP 用户最主要、最优质来源 |\n| 品牌运营 | 独立站品牌宣发、独立站销售转化、社媒品牌形象、品牌推广、新品宣发、活动宣发、粉丝互动 | 品牌侧销售与推广主责方，协助亚马逊扩大品牌市场份额 |\n| 内容运营 | 售前社区广告计划、APP 广告位、社区内容分发、帖子加权、新帖推流、固定流量池管理、用户 KOC/KCO 对接 | 配合亚马逊运营与品牌运营做销售前期宣发和社区流量承接 |\n| 用户运营 | 测评计划落地、用户触达、IM/EDM/TEL 推送、索评、回评跟进、社区互动、合作伙伴渠道管理 | 系统核心使用者，连接销售需求、用户资源、评价结果与客服执行 |\n| 客服运营 | 售后接待、登记、回复、问题完结、负面反馈处理 | 归属用户部门管理，承接售后与评价问题改善 |\n| 数据层/管理层 | 指标复盘、异常监控、成本分析、策略调整 | 统一看板、归因和管理决策 |\n\n## 3. 基础指标与统一数据口径\n\n### 3.1 销售核心指标\n\n- 销量：日销量、月销量、总销量\n- 绑定数：总用户数、月活、日活、产品绑定用户数\n- 评价数：测评数、回评数、每日每产品评价数、计划所需数量、实际完成数量、差评数\n- 成本：产品成本、返现成本、人力成本、提成、管理成本\n\n### 3.2 基础数据维度\n\n| 数据维度 | 说明 |\n|---|---|\n| 渠道影响力 | 衡量各渠道内容、活动、广告位、推送计划的效果 |\n| 用户属性 | 发帖人属性、用户行为、性别、活跃状态、风险标记 |\n| 时间维度 | 每日、每周、每月、活动周期、新品周期 |\n| 产品维度 | 国家、品牌、类目、二级类目、ASIN、产品绑定情况 |\n| 漏斗维度 | 曝光、点击、跳转、转化、成交、绑定、触达、评价 |\n| 风险维度 | 风险标记用户数、差评数、ASIN 健康风险、异常推送效果 |\n\n### 3.3 建议统一主键\n\n后续系统设计应优先统一以下主键，避免销售、用户、评价、售后数据无法串联：\n\n- 用户 ID\n- 订单 ID\n- 产品 ID\n- ASIN\n- 品牌 ID\n- 国家/站点\n- 渠道 ID\n- 推送 ID\n\n## 4. 第一部分：亚马逊运营相关业务\n\n### 4.1 亚马逊运营在闭环中的定位\n\n亚马逊运营负责在亚马逊平台上进行电商销售工作，是当前 APP 用户最主要、最优质的来源。\n\nAPP 与亚马逊运营之间的核心关系是：\n\n1. 亚马逊销售带来订单和用户来源。\n2. APP 需要识别这些购买用户是否下载安装并绑定产品。\n3. 当前每卖出 10 个玩具，约 40% 用户下载并绑定 APP。\n4. 需要亚马逊运营在 Listing、说明书、官网、售后触点等位置配合提升 APP 下载率和产品绑定率。\n5. 亚马逊运营需要提出测评计划、免评计划、推新计划和回评计划相关需求。\n6. APP 内现有用户资源需要根据产品重要级、推新节奏和评价健康度进行分配。\n\n### 4.2 亚马逊运营核心业务模块\n\n| 模块 | 业务内容 | 与 APP 的关系 |\n|---|---|---|\n| 销售管理 | 亚马逊站点销售、销量监控、产品销售报表 | 提供销量、成交、站点、产品数据 |\n| 产品聚合管理 | 按品牌、国家、类目聚合新品、重点产品、清仓产品 | APP 侧需要计算绑定率和用户覆盖情况 |\n| 绑定率提升 | Listing、说明书、官网等触点引导下载与绑定 APP | APP 提供绑定率数据，亚马逊运营优化触点 |\n| 测评计划 | 亚马逊运营根据销售需求提出测评需求和节奏 | 用户运营负责实际实现，品牌运营参与协同 |\n| 免评计划 | 关键词 + 实时销量策略，定时下单，主要承接补单诉求 | 需单独纳入合规与风险监控 |\n| 推新计划 | 面向 S 级或当期重点产品，结合关键词进行推广 | APP 内推送资源分配需要与推新计划匹配 |\n| 回评计划 | 维护链接评价数、回评数和评分等级 | 主要由亚马逊运营与用户运营协作，品牌运营参与协同 |\n| 品牌推广协同 | 亚马逊运营同步品牌推广计划，并在亚马逊站内承接品牌调性 | 品牌运营为亚马逊站外品牌推广主责方 |\n\n### 4.3 独立看板一：产品销量与绑定率看板\n\n#### 4.3.1 看板目标\n\n用于从亚马逊运营视角监控不同品牌、国家、类目、产品类型下的销量与 APP 绑定情况。\n\n该看板需要支持：\n\n- 品牌聚合\n- 国家/站点聚合\n- 类目与二级类目聚合\n- 新品、重点产品、清仓产品拆分\n- 销量与绑定率对比\n- 异常数据报警\n- 对应人员责任归属\n\n#### 4.3.2 产品类型\n\n| 产品类型 | 说明 |\n|---|---|\n| 新品 | 新上市产品，需要重点关注销量、绑定率、评价启动速度 |\n| 重点产品 | 当期重点销售或重点维护产品，如 S 级产品 |\n| 清仓产品 | 需要配合库存、促销、清仓节奏进行销售与触达 |\n\n#### 4.3.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 产品名 | 产品展示名称 |\n| 国家 | 销售国家或市场 |\n| 品牌 | 所属品牌 |\n| 对应人员 | 负责该产品或站点的运营人员 |\n| 二级类目 | 产品所属二级类目 |\n| ASIN | 亚马逊 ASIN |\n| 产品类型 | 新品、重点产品、清仓产品 |\n| 各站点销量 | 各亚马逊站点销量，详细数据涉密 |\n| 总销量 | 汇总销量 |\n| APP 绑定数 | APP 可识别的、已绑定指定玩具的用户数 |\n| 绑定率 | APP 可识别的绑定了指定玩具的用户数 / 销售数 |\n| 异常状态 | 是否出现销量异常、绑定率异常、数据缺失等 |\n| 异常原因 | 异常说明或系统识别原因 |\n| 最近更新时间 | 数据刷新时间 |\n\n#### 4.3.4 重点指标\n\n- 产品销量\n- APP 绑定数\n- APP 绑定率\n- 新品绑定率爬坡情况\n- 重点产品绑定率\n- 清仓产品触达与绑定情况\n- 低绑定率产品列表\n- 异常站点/异常国家/异常类目\n\n#### 4.3.5 异常报警建议\n\n| 异常类型 | 触发逻辑 |\n|---|---|\n| 绑定率过低 | 产品销量正常，但 APP 绑定率低于目标值 |\n| 销量异常波动 | 单日或单周销量较基准值显著上升或下降 |\n| 站点数据缺失 | 某国家/站点销量或绑定数据未同步 |\n| 新品启动异常 | 新品有销量但绑定数或评价启动明显滞后 |\n| 重点产品风险 | S 级或重点产品绑定率、评价数、评分低于目标 |\n\n### 4.4 独立看板二：推新计划与 APP 推送资源分配看板\n\n#### 4.4.1 看板目标\n\n用于管理亚马逊推新计划和 APP 内现有推送资源之间的配合关系。\n\n推新计划的核心是关键词相关的重点产品推广，尤其是当期周度、月度重点产品，如 S 级产品。\n\nAPP 侧需要根据现有用户资源，在 APP 内用户中进行定向推送、曝光、点击、回复、登记和评价转化跟踪。\n\n#### 4.4.2 推新业务结构\n\n| 层级 | 内容 |\n|---|---|\n| 当期重点产品 | 周度、月度重点产品表，例如 S 级产品 |\n| 关键词策略 | 每个重点产品关联的关键词方向 |\n| 推新算法 | 基于产品重要级、用户资源、活跃度、绑定数、历史效果进行推送分配 |\n| APP 推送资源 | APP 内用户、社区消息、广告位、图片点击、活动曝光等 |\n| 效果回收 | 曝光、点击、回复、登记、评价、回评 |\n\n#### 4.4.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 产品名 | 推新产品名称 |\n| ASIN | 对应亚马逊 ASIN |\n| 产品重要级 | 如 S 级、A级、普通等 |\n| 关键词 | 推新关联关键词 |\n| 推送方案 | 当前采用的推送策略或资源组合 |\n| 推送 ID | APP 内推送任务 ID |\n| 关联图片点击率 | 推送图片或关联素材点击率 |\n| 产品绑定数 | 已绑定该产品的用户数 |\n| 总用户数 | APP 总用户数或目标用户池总数 |\n| 当月活跃用户数 | 当月活跃用户规模 |\n| 当月活跃率 | 当月活跃用户数 / 总用户数 |\n| 推送数 | 实际推送数量 |\n| 曝光数 | 用户实际看到的曝光数量 |\n| 点击数 | 用户点击数量 |\n| 回复数 | 用户回复数量 |\n| 登记数 | 用户登记或报名数量 |\n| 评价数 | 最终产生的评价数量 |\n| 回评数 | 最终产生的回评数量 |\n| 推送状态 | 未开始、进行中、已结束、暂停、异常 |\n| 负责人 | 推新或推送负责人 |\n\n#### 4.4.4 核心计算指标\n\n- 曝光率 = 曝光数 / 推送数\n- 点击率 = 点击数 / 曝光数\n- 回复率 = 回复数 / 点击数\n- 登记率 = 登记数 / 点击数\n- 评价转化率 = 评价数 / 登记数\n- 回评转化率 = 回评数 / 评价数\n- 活跃用户覆盖率 = 推送数 / 当月活跃用户数\n\n#### 4.4.5 当前推新资源分配口径\n\n当前推新计划先采用基础规则，后续逐步引入模型。\n\n现阶段基本逻辑：\n\n- S 级产品需求需要最大程度满足。\n- 当前流量池预计约 50% 分配给核心 S 级产品。\n- A 级、B 级及其他产品共同占用剩余约 50% 流量。\n- 产品数量比例上，S 级约 10 来个，其他产品约 200 来个。\n- 后续建议计划需要综合关键词需求、GEO 需求、销量、产品重要级和突发事件生成。\n\n### 4.5 独立看板三：测评计划与免评计划看板\n\n#### 4.5.1 看板目标\n\n用于管理亚马逊运营、用户运营与品牌运营协同的核心评价业务，包括测评计划和免评计划。\n\n协作关系：\n\n- 亚马逊运营：根据亚马逊销售需求提出测评计划、免评计划和回评目标。\n- 用户运营：负责实际触达、推送、登记、索评、回评跟进和结果回收。\n- 品牌运营：由于了解亚马逊运营需求，参与协同对接，但不是实际执行主责方。\n\n其中：\n\n- 测评计划：主要用于新品、重点产品的评价启动、评价数量建设和关键词推广配合。\n- 免评计划：主要基于关键词和实时销量策略进行定时下单，当前主要承接补单诉求。\n\n#### 4.5.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 计划 ID | 测评或免评计划唯一标识 |\n| 计划类型 | 测评计划、免评计划 |\n| 产品名 | 关联产品 |\n| ASIN | 关联 ASIN |\n| 国家/站点 | 亚马逊站点 |\n| 品牌 | 所属品牌 |\n| 产品类型 | 新品、重点、清仓 |\n| 产品重要级 | S 级、A级等 |\n| 关键词 | 计划关联关键词 |\n| 计划周期 | 周、月或指定活动周期 |\n| 计划数量 | 计划执行数量 |\n| 实际完成数量 | 已完成数量 |\n| 完成率 | 实际完成数量 / 计划数量 |\n| APP 配合方式 | 推送、广告位、社区触达、客服触达等 |\n| 风险等级 | 低、中、高 |\n| 审批状态 | 待审批、已审批、执行中、已结束、暂停 |\n| 负责人 | 亚马逊运营负责人 |\n| 协同负责人 | APP 或用户运营负责人 |\n\n#### 4.5.3 审批流口径\n\n测评计划、回评计划、免评计划需要建立审批流。\n\n流程口径：\n\n1. 亚马逊运营提出测评、回评、免评计划。\n2. 亚马逊运营总监审批确认。\n3. 审批通过后进入用户运营执行排期。\n4. 用户运营根据用户池、渠道资源和频控规则制定可执行计划。\n\n#### 4.5.4 风险说明\n\n免评计划、补单诉求、返现或强索评相关动作应进入风险管理与审批机制，不能只作为普通运营动作处理。\n\n建议后续单独规划：\n\n- 合规风险字段\n- 审批流\n- ASIN 风险状态\n- 账号风险状态\n- 高风险动作留痕\n\n### 4.6 独立看板四：回评计划与 ASIN 评价健康度看板\n\n#### 4.6.1 看板目标\n\n用于保障亚马逊链接的评价数和评分等级，尤其是新品爆款周期内，需要评价数量和评价等级与销售节奏匹配。\n\n核心目标：\n\n- 保障链接评价数\n- 保障评分等级\n- 支撑新品爆款周期\n- 识别 ASIN 评价健康风险\n- 区分新品、重点产品、清仓产品的回评需求\n\n#### 4.6.2 评价健康标准\n\n当前业务描述中的核心标准：\n\n- 评价数要与新品爆款周期匹配，原则上数量要多。\n- 评价等级需要维持在较高水平。\n- 新品或爆款产品期望评价等级原则上应达到 4.8 以上。\n- 4.8 属于很健康。\n- 4.5 属于健康。\n- 4.2 属于高风险，需要加强对未回评用户的回评推送。\n\n#### 4.6.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| ASIN | 亚马逊 ASIN |\n| 产品名 | 产品名称 |\n| 国家/站点 | 销售国家或亚马逊站点 |\n| 品牌 | 所属品牌 |\n| 产品类型 | 新品、重点、清仓 |\n| 产品重要级 | S 级、A级等 |\n| 当月计划回评数 | 当月计划获得的回评数量 |\n| 实际回评数 | 当月实际回评数量 |\n| 回评完成率 | 实际回评数 / 当月计划回评数 |\n| 期望评价等级 | 目标评分等级 |\n| 实际评价等级 | 当前实际评分等级 |\n| 当前评价数 | 当前累计评价数量 |\n| 当月新增评价数 | 当月新增评价数量 |\n| 差评数 | 当前或当月差评数量 |\n| 差评率 | 差评数 / 评价数 |\n| 健康状态 | 健康、关注、风险、严重风险 |\n| 负责人 | ASIN 负责人 |\n\n#### 4.6.4 产品类型下的回评管理\n\n| 产品类型 | 回评管理重点 |\n|---|---|\n| 新品 | 评价启动速度、评价数量爬坡、评分稳定性、爆款周期匹配 |\n| 重点产品 | 评分等级维护、差评预警、持续回评目标达成 |\n| 清仓产品 | 根据清仓节奏决定是否继续投入回评资源，避免资源浪费 |\n\n#### 4.6.5 ASIN 评价健康等级\n\n| 实际评价等级 | 健康状态 | 处理建议 |\n|---|---|---|\n| 4.8 及以上 | 很健康 | 维持正常回评节奏，重点保障新品爆款周期 |\n| 4.5-4.79 | 健康 | 保持监控，按计划推进回评 |\n| 4.2-4.49 | 高风险 | 加强对未回评用户的回评推送 |\n| 低于 4.2 | 严重风险 | 需要升级处理，结合客服、用户运营和亚马逊运营共同干预 |\n\n### 4.7 亚马逊运营协同品牌推广计划\n\n品牌推广计划由亚马逊运营与品牌运营协同完成。\n\n除亚马逊站内的品牌承接和销售动作外，以下工作以品牌运营为主进行决策，亚马逊运营同步即可：\n\n- JOYHUB 内推广\n- 社媒互动\n- 新品宣发\n- 活动宣发\n- 粉丝互动管理\n- 销售管理\n- 独立站推广\n- 新品推广\n- 社媒数据\n- KOL 互动数据\n\n#### 4.7.1 品牌推广协同数据\n\n| 字段 | 说明 |\n|---|---|\n| 推广计划 ID | 品牌推广计划唯一标识 |\n| 推广类型 | JOYHUB、社媒、新品宣发、活动宣发、KOL、独立站等 |\n| 产品名 | 关联产品 |\n| ASIN | 关联 ASIN |\n| 品牌 | 所属品牌 |\n| 国家 | 推广国家 |\n| 渠道 | 推广渠道 |\n| 曝光数 | 推广曝光 |\n| 点击数 | 推广点击 |\n| 跳转数 | 跳转到亚马逊或独立站的数量 |\n| 转化数 | 产生转化数量 |\n| 成交数 | 产生订单数量 |\n| 互动数 | 点赞、评论、私信、粉丝互动等 |\n| KOL 信息 | 合作达人或账号 |\n| 负责人 | 推广负责人 |\n\n## 5. 第二部分：品牌运营相关业务\n\n### 5.1 品牌运营在闭环中的定位\n\n品牌运营与亚马逊运营不在同一个办公区，但需要协助亚马逊运营共同建立销售体系。\n\n品牌运营的核心定位是：\n\n1. 负责独立站品牌宣发。\n2. 负责在社媒建立品牌形象。\n3. 负责独立站成交与品牌侧销售管理。\n4. 协助亚马逊运营在亚马逊平台上提高品牌调性。\n5. 协助亚马逊运营扩大品牌在亚马逊上的市场份额。\n6. 与亚马逊运营共同参与品牌推广计划。\n7. 在亚马逊站外品牌推广相关事项上，品牌运营为主责决策方，亚马逊运营同步。\n\n### 5.2 品牌运营与亚马逊运营的分工边界\n\n| 业务事项 | 主责方 | 协同方 | 说明 |\n|---|---|---|---|\n| 亚马逊站内销售 | 亚马逊运营 | 品牌运营 | 品牌运营协助提高品牌调性和市场份额 |\n| 亚马逊站内品牌承接 | 亚马逊运营 | 品牌运营 | Listing、品牌内容、品牌调性需要双方协同 |\n| 独立站品牌宣发 | 品牌运营 | 亚马逊运营同步 | 独立站推广和转化由品牌运营主责 |\n| 独立站成交 | 品牌运营 | 亚马逊运营同步 | 独立站销售数由品牌运营负责 |\n| 社媒品牌形象 | 品牌运营 | 亚马逊运营同步 | 包含账号内容、互动、粉丝维护 |\n| JOYHUB 内推广 | 品牌运营 | 亚马逊运营同步 | 实际为品牌运营工作，亚马逊运营了解进度 |\n| 新品宣发 | 品牌运营 | 亚马逊运营同步 | 站外宣发主责在品牌运营 |\n| 活动宣发 | 品牌运营 | 亚马逊运营同步 | 活动口径需要与销售节奏同步 |\n| 粉丝互动管理 | 品牌运营 | 亚马逊运营同步 | 社媒与品牌用户关系维护 |\n| KOL 互动 | 品牌运营 | 亚马逊运营同步 | KOL 数据和互动效果由品牌运营负责 |\n| AMZ 测评计划 | 亚马逊运营、用户运营 | 品牌运营协同 | 亚马逊运营提需求，用户运营实现，品牌运营参与协同 |\n| 回评计划 | 亚马逊运营、用户运营 | 品牌运营协同 | 主要服务 ASIN 评价健康度 |\n\n### 5.3 品牌运营核心业务模块\n\n| 模块 | 业务内容 | 输出 |\n|---|---|---|\n| 品牌宣发 | 独立站、社媒、JOYHUB、新品、活动等品牌曝光 | 品牌推广计划、宣发内容、渠道效果 |\n| 社媒运营 | 建立品牌形象、粉丝互动、社媒内容发布 | 社媒访问、点击、互动、转化数据 |\n| 独立站推广 | 独立站访问、点击、转化、成交管理 | 独立站销售数、转化漏斗 |\n| 新品推广 | 新品宣发、站外曝光、内容传播 | 新品推广数据、用户兴趣数据 |\n| 活动推广 | 活动宣发、活动页面、粉丝触达 | 活动曝光、点击、转化、成交 |\n| KOL 合作 | KOL 互动、达人合作、内容发布 | KOL 互动数据、访问与转化效果 |\n| 品牌销售管理 | 独立站成交、品牌侧销售数据管理 | 销售数、成交数、转化数 |\n| 亚马逊协同 | 协助亚马逊提升品牌调性和市场份额 | 品牌素材、推广节奏、协同反馈 |\n\n### 5.4 独立看板五：品牌影响力与独立站销售看板\n\n#### 5.4.1 看板目标\n\n用于衡量品牌运营在独立站、社媒、JOYHUB、KOL、新品宣发和活动宣发等渠道中的影响力、转化效果和销售结果。\n\n该看板以品牌运营为主责，亚马逊运营同步查看，用于判断站外品牌推广对亚马逊销售和独立站销售的辅助效果。\n\n#### 5.4.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 品牌 | 所属品牌 |\n| 国家 | 推广国家或市场 |\n| 渠道来源 | 独立站、社媒、JOYHUB、KOL、新品宣发、活动宣发等 |\n| 推广类型 | 新品、活动、日常内容、KOL、粉丝互动等 |\n| 产品名 | 关联产品 |\n| ASIN | 如有关联亚马逊产品，则记录 ASIN |\n| 负责人 | 品牌运营负责人 |\n| 访问数 | 各来源访问量 |\n| 点击数 | 各来源点击量 |\n| 转化数 | 各来源转化数量 |\n| 销售数 | 独立站或品牌侧销售数量，由品牌运营负责 |\n| 成交数 | 实际成交订单数量 |\n| 互动数 | 点赞、评论、分享、私信、粉丝互动等 |\n| KOL 信息 | 合作达人或账号信息 |\n| 内容/活动 ID | 关联内容、活动或投放任务 |\n| 跳转目标 | 亚马逊、独立站、APP、活动页等 |\n| 数据周期 | 日、周、月、活动周期 |\n\n#### 5.4.3 核心指标\n\n- 访问数\n- 点击数\n- 转化数\n- 销售数\n- 成交数\n- 社媒互动数\n- KOL 互动数据\n- 独立站转化率\n- 渠道访问贡献\n- 品牌活动转化效果\n\n#### 5.4.4 品牌影响力评估口径\n\n品牌影响力从两方面评估：\n\n1. 各渠道转化，包括独立站转化、亚马逊跳转转化、APP 承接转化等。\n2. 社媒影响力与调研反馈，包括互动、评论、粉丝反馈和品牌认知反馈。\n\n通过品牌活动前往亚马逊形成的转化，也归属品牌运营 OKR 结果。\n\n### 5.5 独立看板六：品牌推广计划协同看板\n\n#### 5.5.1 看板目标\n\n用于管理品牌运营与亚马逊运营共同参与的品牌推广计划。\n\n该看板需要明确：\n\n- 品牌运营在站外推广中的主责地位\n- 亚马逊运营在亚马逊站内承接品牌调性与销售转化的职责\n- 品牌推广与亚马逊销售、独立站销售、APP 用户增长之间的关系\n- 品牌推广计划与 AMZ 测评计划之间的协同关系\n\n#### 5.5.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 推广计划 ID | 品牌推广计划唯一标识 |\n| 推广计划名称 | 计划名称 |\n| 主责部门 | 品牌运营 |\n| 协同部门 | 亚马逊运营、用户运营、内容运营等 |\n| 推广类型 | JOYHUB、社媒、新品宣发、活动宣发、KOL、独立站等 |\n| 品牌 | 所属品牌 |\n| 国家 | 推广国家 |\n| 产品名 | 关联产品 |\n| ASIN | 关联亚马逊 ASIN |\n| 独立站链接 | 独立站承接地址 |\n| 亚马逊链接 | 亚马逊承接地址 |\n| APP 承接方式 | 是否需要 APP 内承接、推送或活动页 |\n| 计划开始时间 | 推广开始时间 |\n| 计划结束时间 | 推广结束时间 |\n| 预算 | 推广预算 |\n| 访问数 | 推广访问量 |\n| 点击数 | 推广点击量 |\n| 转化数 | 推广转化数量 |\n| 销售数 | 品牌侧销售数量 |\n| 成交数 | 实际成交订单 |\n| 亚马逊同步状态 | 未同步、已同步、需调整 |\n| 计划状态 | 草稿、待确认、执行中、已结束、暂停 |\n\n### 5.6 品牌运营参与 AMZ 测评计划的协作关系\n\nAMZ 测评计划由三方协作完成：\n\n| 角色 | 职责 |\n|---|---|\n| 亚马逊运营 | 根据亚马逊平台销售需求提出测评计划、回评计划、关键词和产品优先级需求 |\n| 品牌运营 | 理解并同步亚马逊运营需求，协同亚马逊运营与用户运营对接 |\n| 用户运营 | 负责实际实现，包括用户触达、推送、登记、索评、回评跟进和结果反馈 |\n\n需要明确的是：\n\n- 测评计划和回评计划的主要协作方是亚马逊运营与用户运营。\n- 品牌运营参与协同，但不是实际落地执行主责方。\n- 品牌运营的核心主责仍然是品牌宣发、社媒品牌形象、独立站成交和站外推广管理。\n\n### 5.7 APP 内资源协同边界\n\n| 资源类型 | 管理分配方 | 品牌运营角色 |\n|---|---|---|\n| APP 内社区资源 | 内容运营分配，品牌运营与内容运营协同 | 将亚马逊运营和品牌运营需求与内容运营协商 |\n| 用户推送资源 | 用户运营管理分配 | 将亚马逊运营和品牌运营需求与用户运营协商 |\n\n品牌运营熟悉内容运营和用户运营两侧资源，负责把亚马逊运营需求和品牌运营自身需求同步给相关部门，并推动协商解决。\n\n### 5.8 品牌运营与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 品牌运营 → 亚马逊运营 | 品牌推广计划、社媒/KOL 数据、新品宣发节奏、活动宣发数据 | 帮助亚马逊站内承接品牌调性和销售转化 |\n| 亚马逊运营 → 品牌运营 | 亚马逊销售需求、重点 ASIN、推新节奏、测评需求、关键词方向 | 品牌运营理解销售重点并做站外协同 |\n| 品牌运营 → 用户运营 | 推广计划、活动节奏、需要 APP 承接的用户触达需求 | APP 内推送、活动承接、用户触达 |\n| 用户运营 → 品牌运营 | APP 用户反馈、触达数据、活动参与、评价反馈 | 优化品牌内容和活动策略 |\n| 品牌运营 → 数据层/管理层 | 访问、点击、转化、销售数、互动数、KOL 数据 | 品牌影响力、渠道 ROI、独立站销售复盘 |\n\n## 6. 第三部分：用户运营相关业务\n\n### 6.1 用户运营在闭环中的定位\n\n用户运营是该系统的核心使用者。客服部门实际也归属用户部门管理。\n\n用户运营的核心定位是：\n\n1. 接收亚马逊运营与品牌运营协同后的销售数据和测评需求。\n2. 根据关键词、销量、产品重要级、ASIN 评价健康度共同制定可执行的测评计划。\n3. 基于 APP 用户、绑定用户、活跃用户、社区用户、非 APP 或低活跃用户进行分层触达。\n4. 在社区中与用户互动，鼓励测评人参与。\n5. 负责推送、登记、索评、回评跟进和结果回收。\n6. 按 ASIN 评价健康度动态调整触达资源和回评节奏。\n7. 管理 TEL、EDM、KOC/KOL/PR、短信、社区、非评价推送等多渠道触达。\n8. 管理客服售后相关执行数据，并将售后反馈纳入触达策略优化。\n\n### 6.2 用户运营核心业务模块\n\n| 模块 | 业务内容 | 输出 |\n|---|---|---|\n| 测评计划执行 | 根据亚马逊销售需求、关键词、销量、产品重要级制定可执行测评计划 | 推送计划、登记数据、评价数、计划完成度 |\n| 用户社区互动 | 在 APP 社区中与用户互动，鼓励用户参与新玩具测评 | 回复数、登记数、评价数 |\n| 回评计划跟进 | 根据 ASIN 评价健康度跟进回评目标 | 回评完成度、风险等级、ASIN 健康状态 |\n| IM 社区消息推送 | 推动新玩具购买与买后索评 | 曝光、点击、回复、登记、出评 |\n| 已成交索评 | 针对已绑定、已购买玩具的用户进行索评 | 实际回评数、评价等级改善 |\n| TEL 电话售后 | 接听售后和呼出电话 | 接听售后数据、呼出数据、售后原因 |\n| EDM 邮件推送 | 针对非 APP 或低 APP 活跃用户进行邮件触达 | 打开、点击、回复、转化 |\n| KOC/KOL/PR 合作 | 通过 JOYCOLLAB 网站管理合作伙伴体系 | 合作伙伴效果、带货链接、销售与提成数据 |\n| 其他触达渠道 | 短信、社区、非评价推送等仍在搭建中的渠道 | 新增测评渠道、内容改善、用户反感度控制 |\n\n### 6.3 测评计划执行数据\n\n用户运营根据亚马逊运营和品牌运营协同后的需求，结合销售数据、关键词和销量生成可执行的测评计划。\n\n测评计划的关键是把“销售侧需求”转化为“用户侧可执行动作”。\n\n#### 6.3.1 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 产品名 | 关联产品 |\n| ASIN | 亚马逊 ASIN |\n| 产品重要级 | S 级、重点、普通等 |\n| 关键词 | 亚马逊运营提出的关键词方向 |\n| 推送方案 | 用户运营制定的触达策略 |\n| 推送 ID | 推送任务唯一标识 |\n| 关联图片点击率 | 推送图片或素材点击率 |\n| 产品绑定数 | 已绑定该产品的用户数 |\n| 总用户数 | 可触达用户总数 |\n| 当月活跃用户数 | 当月活跃用户规模 |\n| 当月活跃率 | 当月活跃用户数 / 总用户数 |\n| 推送数 | 实际推送数量 |\n| 曝光数 | 实际曝光数量 |\n| 点击数 | 实际点击数量 |\n| 回复数 | 用户回复数量 |\n| 登记数 | 用户报名、登记或确认参与数量 |\n| 评价数 | 最终产生的评价数量 |\n\n### 6.4 ASIN 评价健康度与回评计划\n\n用户运营需要根据随时更新的 Listing 健康状况和 ASIN 评价健康度跟进回评计划。\n\n核心原则：\n\n- 新品爆款周期需要与评价数量和评价等级匹配。\n- 新品和爆款原则上评价数量要多。\n- 新品和爆款的期望评价等级原则上应达到 4.8 以上。\n- 常规产品需要保障链接评价数和评分等级。\n- 回评计划需要区分新品、重点产品、清仓产品。\n\n#### 6.4.1 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| ASIN | 亚马逊 ASIN |\n| 产品名 | 关联产品 |\n| 产品类型 | 新品、重点、清仓 |\n| 当月计划回评数 | 当月计划回评数量 |\n| 实际回评数 | 当月实际完成回评数量 |\n| 期望评价等级 | 目标评价等级 |\n| 实际评价等级 | 当前实际评价等级 |\n| 回评完成率 | 实际回评数 / 当月计划回评数 |\n| 风险等级 | 健康、关注、风险、严重风险 |\n| 跟进人 | 用户运营负责人 |\n\n### 6.5 独立看板七：IM 社区消息推送计划看板\n\n#### 6.5.1 业务场景\n\nIM 社区消息推送主要用于推动新玩具测评。\n\n当用户没有购买我们想推动的新玩具时，用户运营通过 IM 社区消息推送促使用户购买新玩具，并在购买后进行索评。\n\n#### 6.5.2 看板目标\n\n按地区、品牌、类目、策略观察不同推送计划的效果。\n\n#### 6.5.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 推送 ID | 推送任务唯一标识 |\n| 关联产品 | 推送关联产品 |\n| ASIN | 关联 ASIN |\n| 国家/地区 | 推送覆盖地区 |\n| 品牌 | 所属品牌 |\n| 类目 | 产品类目 |\n| 策略 | 推送策略 |\n| 曝光 | 推送曝光数 |\n| 点击 | 用户点击数 |\n| 回复 | 用户回复数 |\n| 登记 | 用户登记数 |\n| 出评 | 最终产生评价数 |\n| 转化率 | 出评或登记转化率 |\n| 计划完成度 | 实际完成 / 计划目标 |\n| 订单号 | 订单号，含亚马逊来源和独立站来源，涉密字段 |\n| 订单来源 | 亚马逊、独立站等 |\n| profile ID | 用户 Profile 标识，涉密字段 |\n| joyhub ID | JOYHUB 用户标识，涉密字段 |\n\n### 6.6 独立看板八：已成交索评与回评计划完成度看板\n\n#### 6.6.1 业务场景\n\n当用户已经绑定某个玩具时，APP 能识别用户购买了哪个玩具。用户运营可以针对已有玩具进行已成交索评。\n\n该看板与 ASIN 评价健康度直接关联，用于确保亚马逊链接健康。\n\n#### 6.6.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 产品类型 | 新品、重点、清仓 |\n| 产品名 | 关联产品 |\n| ASIN | 关联 ASIN |\n| 产品计划回评数 | 当前产品计划回评数量 |\n| 实际回评数 | 当前产品实际回评数量 |\n| 回评完成率 | 实际回评数 / 产品计划回评数 |\n| 当前 ASIN 评价等级 | 当前 ASIN 星级或评分 |\n| 风险等级 | 健康、关注、风险、严重风险 |\n| 负责人 | 用户运营负责人 |\n\n### 6.7 独立看板九：TEL 电话售后渠道看板\n\n#### 6.7.1 业务场景\n\nTEL 电话售后渠道包括接听售后和呼出电话，主要用于改善服务、收集售后问题、支撑索评和降低负面反馈。\n\n#### 6.7.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 电话号码 | 高度涉密字段 |\n| 国家 | 用户国家 |\n| 品牌 | 关联品牌 |\n| 产品 | 关联产品 |\n| 售后原因 | 用户咨询或售后原因 |\n| 呼出数 | 呼出电话数量 |\n| 接听数 | 接听电话数量 |\n| 订单号 | 涉密字段 |\n| 跟进人 | 客服或用户运营负责人 |\n| 处理状态 | 待处理、处理中、已完结、需升级 |\n\n### 6.8 独立看板十：EDM 邮件推送渠道看板\n\n#### 6.8.1 业务场景\n\nEDM 邮件推送主要面向非 APP 用户或低 APP 活跃用户，用于补充 APP 内推送触达能力。\n\n#### 6.8.2 看板目标\n\n用于持续改善 EDM 计划，包括邮件打开、点击、回复和转化效果。\n\n#### 6.8.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 国家 | 用户国家 |\n| 地区 | 用户地区 |\n| 邮件服务商 | 邮件服务商 |\n| 用户邮箱 | 高度涉密字段 |\n| USER ID | 非 APP 用户 ID |\n| 推送 ID | EDM 推送任务 ID |\n| 点击数 | 邮件点击数量 |\n| 打开数 | 邮件打开数量 |\n| 回复数 | 邮件回复数量 |\n| 转化数 | 由邮件触达带来的转化数量 |\n| 计划状态 | 草稿、执行中、已结束、异常 |\n\n### 6.9 独立看板十一：KOC/KOL/PR 合作伙伴效果看板\n\n#### 6.9.1 业务场景\n\nKOC、KOL、PR 渠道用于合作伙伴对接和带货推广。合作伙伴体系通过 JOYCOLLAB 网站承接。\n\nKOC 在 JOYCOLLAB 上的带货数据原则上先在 JOYCOLLAB 网站内处理，再同步到大用户后台。财务也会参与销售数据、提成数据和交易金额的核算或校验。\n\n#### 6.9.2 看板目标\n\n用于改善合作伙伴效果，观察合作伙伴在不同国家、平台、产品和带货链路上的实际贡献。\n\n#### 6.9.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 合作伙伴 ID | 合作伙伴唯一标识 |\n| 国家 | 合作伙伴所在国家 |\n| 姓名 | 合作伙伴姓名，涉密字段 |\n| 时间 | 合作或跟进时间 |\n| 平台 | 合作平台 |\n| 粉丝 | 粉丝数量或粉丝规模 |\n| 备注 | 合作备注 |\n| 跟进人 | 用户运营或合作伙伴负责人 |\n| 合作产品 | 合作推广产品 |\n| 带货链接 | 合作伙伴带货链接 |\n| 销售数据 | 通过带货链接产生的销售数据 |\n| 提成数据 | 合作伙伴提成数据，涉密字段 |\n| 交易金额 | 产生的交易金额 |\n\n### 6.10 其他触达渠道\n\n其他渠道包括：\n\n- 短信\n- 社区\n- 非评价推送\n\n这些渠道仍在搭建当中，目标包括：\n\n1. 继续增加测评渠道。\n2. 改善内容触达效果。\n3. 降低用户对高频推送、索评、活动通知的反感。\n4. 为非评价类推送沉淀策略，例如活动、内容、售后提醒、品牌互动。\n\n### 6.11 用户识别、黑名单与频控口径\n\n#### 6.11.1 用户识别主标识\n\n订单号和 JOYHUB ID 是用户索评与黑名单查询中的两个主要标识。\n\n订单号包括：\n\n- 亚马逊来源订单号\n- 独立站来源订单号\n\n当用户注册后，必然有 JOYHUB ID。 \n当用户提供订单号时，JOYHUB ID 和订单号建立关联。\n\nAPP 侧还会保留注册邮箱、用户基础 IP、设备号、用户行为数据等信息。订单号可以关联用户地址、姓名、用户名等信息。\n\n#### 6.11.2 邮箱、账号与风险关联\n\n注册用户的 JOYHUB ID 和邮箱必然关联。部分用户可能使用多个邮箱注册多个账号，每个账号都有独立 JOYHUB ID。\n\n系统需要通过 IP、设备号等信息做黑名单关联。关联后，多个账号可被认定为关联账号，或在后台被划入高度风险关联，并按单一用户处理。\n\n#### 6.11.3 多渠道统一频控\n\nTEL、EDM、IM、社区、短信等渠道需要统一控制触达频率，并统一了解对用户的骚扰程度，避免过于频繁触达导致用户反感。\n\n### 6.12 用户运营与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 亚马逊运营 → 用户运营 | 销售数据、关键词、重点产品、测评需求、回评目标、ASIN 健康状态 | 制定可执行测评计划和回评计划 |\n| 品牌运营 → 用户运营 | 品牌推广计划、活动节奏、站外触达需求、APP 承接需求 | 配合品牌推广进行 APP 内触达 |\n| 用户运营 → 亚马逊运营 | 推送效果、登记数、评价数、回评数、ASIN 风险反馈 | 调整测评计划、推新计划和评价健康策略 |\n| 用户运营 → 品牌运营 | 用户反馈、触达效果、活动参与、转化结果 | 优化品牌内容、活动和独立站推广 |\n| 用户运营 → 客服运营 | 待跟进用户、售后触达需求、负面反馈线索 | 电话售后、问题处理和服务改善 |\n| 客服运营 → 用户运营 | 接听售后数据、呼出数据、售后原因、处理结果 | 优化推送策略、索评节奏和用户分层 |\n| 用户运营 → 数据层/管理层 | 推送、登记、评价、回评、TEL、EDM、合作伙伴数据 | 复盘渠道效果、人效、成本和风险 |\n\n## 7. 第四部分：菲律宾客服相关业务\n\n### 7.1 菲律宾客服在闭环中的定位\n\n菲律宾客服直接接受用户运营指导工作。\n\n当亚马逊运营存在短期需求变动时，不直接绕过用户运营调整客服工作，而是通过用户运营转达和排期。这样可以保证测评计划、回评计划、售后触达、人员安排和成本统计在同一套用户运营口径下管理。\n\n菲律宾客服的核心定位是：\n\n1. 执行用户运营下发的评价、登记、回复、售后跟进等具体任务。\n2. 承接各渠道用户接待与基础沟通。\n3. 配合评价计划落地，提升评价转化和完结评价数。\n4. 反馈客服侧接待、登记、回复、完结情况。\n5. 支撑用户运营进行成本管理、人效管理和渠道效果复盘。\n\n### 7.2 核心指标\n\n| 指标 | 说明 |\n|---|---|\n| 客源 | 来自不同渠道的用户来源或待处理线索 |\n| 转化数 | 从接待、登记、回复到评价完成的转化数量 |\n| 转化率 | 评价转化数 / 客源或登记数 |\n| 节约成本 | 通过客服执行、人效提升、渠道优化节约的成本 |\n\n### 7.3 独立看板十二：菲律宾客服人员管理看板\n\n#### 7.3.1 看板目标\n\n用于管理菲律宾客服人员、出勤、每日工作量和各渠道执行情况。\n\n#### 7.3.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 人员 | 客服人员姓名或账号 |\n| 团队/组别 | 所属客服小组 |\n| 出勤 | 出勤状态、出勤天数或工时 |\n| 日期 | 工作日期 |\n| 渠道 | IM、TEL、EDM、社区、KOC/KOL/PR、其他 |\n| 接待数 | 当日接待用户数量 |\n| 登记数 | 当日登记数量 |\n| 回复数 | 当日回复数量 |\n| 每日评价数 | 当日产生评价数量 |\n| 完结评价数 | 当日完结评价数量，按各渠道统计 |\n| 待处理数 | 尚未处理或未完结任务数量 |\n| 负责人 | 用户运营或客服主管 |\n\n### 7.4 独立看板十三：菲律宾客服评价计划管理看板\n\n#### 7.4.1 看板目标\n\n用于跟踪菲律宾客服执行评价计划的过程和结果，重点观察客源、登记、回复、出评和计划完成度。\n\n#### 7.4.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 评价计划 ID | 关联测评或回评计划 |\n| 推送 ID | 关联用户运营推送任务 |\n| 产品名 | 关联产品 |\n| ASIN | 关联 ASIN |\n| 产品类型 | 新品、重点、清仓 |\n| 渠道 | IM、TEL、EDM、社区、其他 |\n| 客源数 | 进入客服处理池的用户数量 |\n| 接待数 | 客服实际接待数量 |\n| 登记数 | 用户登记或确认参与数量 |\n| 回复数 | 用户回复数量 |\n| 每日评价数 | 每日产生评价数量 |\n| 完结评价数 | 完成闭环的评价数量 |\n| 转化数 | 从客源到评价完成的转化数量 |\n| 转化率 | 转化数 / 客源数或登记数 |\n| 计划完成度 | 实际完成 / 计划目标 |\n| 跟进人 | 菲律宾客服人员 |\n| 指导人 | 用户运营负责人 |\n\n### 7.5 独立看板十四：菲律宾客服成本管理看板\n\n#### 7.5.1 看板目标\n\n用于管理菲律宾客服相关人力成本、财务表和成本节约效果。\n\n#### 7.5.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 人员 | 客服人员 |\n| 出勤 | 出勤天数或工时 |\n| 人力成本 | 人员工资、补贴或对应成本 |\n| 提成 | 如存在评价、转化或完结相关提成，则单独记录 |\n| 管理成本 | 管理、培训、工具等分摊成本 |\n| 完结评价数 | 该人员或团队完成评价数量 |\n| 单评成本 | 总成本 / 完结评价数 |\n| 转化数 | 产生的有效转化数量 |\n| 单转化成本 | 总成本 / 转化数 |\n| 节约成本 | 因流程改善、人效提升或渠道优化节约的成本 |\n| 财务表 | 人事或财务表关联记录 |\n\n### 7.6 菲律宾客服与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 用户运营 → 菲律宾客服 | 评价计划、待跟进用户、推送任务、短期需求变动、售后跟进要求 | 指导客服执行 |\n| 菲律宾客服 → 用户运营 | 出勤、接待、登记、回复、每日评价、完结评价数、售后反馈 | 用户运营复盘渠道效果、人效和计划完成情况 |\n| 亚马逊运营 → 用户运营 → 菲律宾客服 | 亚马逊运营短期测评、回评或售后需求变动 | 通过用户运营统一转达，避免执行口径混乱 |\n| 菲律宾客服 → 数据层/管理层 | 人员、人效、评价转化、成本、财务表数据 | 成本管理、绩效评估和管理复盘 |\n\n## 8. 第五部分：内容运营相关业务\n\n### 8.1 内容运营在闭环中的定位\n\n内容运营在当前以用户运营为核心的业务需求中，主要负责配合亚马逊运营与品牌运营，在销售前期为产品做宣发和社区内流量承接。\n\n内容运营的核心定位是：\n\n1. 配合亚马逊运营和品牌运营做产品售前宣发。\n2. 管理 APP 内广告资源，包括开屏、弹窗、文末、ME、评论末等位置。\n3. 在社区内配合用户 KOC/KCO 对接，支持产品内容传播和测评前期预热。\n4. 执行售前社区广告计划。\n5. 通过推流管理提升重点产品、重点帖子、活动内容的曝光和点击。\n6. 管理加权、新帖、固定位置和固定流量池资源。\n7. 监控曝光、点击、打开、跳转、成交和互动数据，并识别风险。\n\n### 8.2 内容运营核心业务模块\n\n| 模块 | 业务内容 | 输出 |\n|---|---|---|\n| 售前社区广告计划 | 配合产品上市、活动、测评计划做社区前期宣发 | 广告计划、曝光、点击、跳转、成交数据 |\n| APP 广告管理 | 管理开屏、弹窗、文末、ME、评论末等广告位 | 广告位排期、用户行为数据、转化数据 |\n| 推流管理 | 对帖子加权、新帖扶持、固定位置投放、固定流量池管理 | 帖子曝光、点击、打开、互动、风险数据 |\n| KOC/KCO 对接 | 在社区中与用户或内容参与者对接 | 内容互动、测评预热、社区反馈 |\n| 风险识别 | 识别异常用户、异常互动、内容风险或投流风险 | 风险标记、处理建议 |\n\n### 8.3 独立看板十五：APP 广告管理看板\n\n#### 8.3.1 看板目标\n\n用于管理 APP 内广告位资源，支撑亚马逊运营和品牌运营在销售前期进行产品宣发、活动宣发和售前社区触达。\n\n广告位包括：\n\n- 开屏\n- 弹窗\n- 文末\n- ME\n- 评论末\n\n#### 8.3.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 月份 | 月度统计周期 |\n| 日期 | 每日统计周期 |\n| 产品 | 关联产品 |\n| ASIN | 如关联亚马逊产品，则记录 ASIN |\n| 品牌 | 所属品牌 |\n| 国家/地区 | 投放国家或地区 |\n| 广告位 | 开屏、弹窗、文末、ME、评论末等 |\n| 绑定情况 | 产品绑定用户数、绑定率或绑定状态 |\n| 用户行为 | 浏览、点击、打开、跳转、互动、购买等行为 |\n| 性别 | 用户性别 |\n| 其他标记用户数 | 风险用户、重点用户、异常用户或其他业务标记用户数 |\n| 曝光 | 广告曝光数 |\n| 点击 | 广告点击数 |\n| 打开 | 广告打开数 |\n| 跳转 | 跳转到产品页、亚马逊、独立站、活动页或 APP 页面数量 |\n| 成交数 | 由广告触达带来的成交数量 |\n| 负责人 | 内容运营负责人 |\n\n#### 8.3.3 核心指标\n\n- 曝光数\n- 点击数\n- 打开数\n- 跳转数\n- 成交数\n- 点击率\n- 打开率\n- 跳转率\n- 成交转化率\n- 不同广告位效果对比\n\n### 8.4 独立看板十六：推流管理看板\n\n#### 8.4.1 看板目标\n\n用于管理社区内容推流，包括帖子加权、新帖推流、固定位置和固定流量池。\n\n该看板服务于售前社区广告计划，帮助重点产品和重点内容获得更稳定的曝光与互动。\n\n#### 8.4.2 推流动作\n\n| 动作 | 说明 |\n|---|---|\n| 加权 | 对重点帖子或产品内容增加推荐权重 |\n| 新帖 | 对新发布内容进行启动流量扶持 |\n| 固定位置 | 将内容投放到指定社区位置 |\n| 固定流量池管理 | 管理固定流量池分配和资源占用 |\n\n#### 8.4.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 帖子 ID | 社区帖子唯一标识 |\n| 产品 | 关联产品 |\n| ASIN | 如关联亚马逊产品，则记录 ASIN |\n| 品牌 | 所属品牌 |\n| 发帖人属性 | 发帖人身份、用户类型、KOC/KCO、普通用户等 |\n| 帖子周期 | 新帖期、加权期、稳定期、结束期等 |\n| 投流等级 | 投流优先级或资源等级 |\n| 流量等级 | 实际分配的流量层级 |\n| 固定位置 | 是否使用固定位置及位置名称 |\n| 固定流量池 | 是否占用固定流量池及流量池名称 |\n| 曝光 | 帖子曝光数 |\n| 点击 | 帖子点击数 |\n| 打开 | 帖子打开数 |\n| 互动数 | 点赞、评论、收藏、分享、回复等互动总数 |\n| 各互动数 | 各类型互动明细 |\n| 风险 | 内容风险、用户风险、异常互动或投流风险 |\n| 负责人 | 内容运营负责人 |\n\n### 8.5 内容运营与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 亚马逊运营 → 内容运营 | 重点产品、ASIN、推新节奏、售前宣发需求、测评前期需求 | 安排社区广告和推流资源 |\n| 品牌运营 → 内容运营 | 品牌推广计划、新品宣发、活动宣发、素材与口径 | 统一品牌内容和社区投放 |\n| 用户运营 → 内容运营 | 用户触达节奏、测评计划、用户反馈、频控要求 | 避免内容触达与用户推送冲突 |\n| 内容运营 → 亚马逊运营/品牌运营 | 广告曝光、点击、打开、跳转、成交、帖子互动、风险数据 | 复盘售前宣发效果和销售辅助效果 |\n| 内容运营 → 数据层/管理层 | APP 广告、推流、互动、风险、成交归因数据 | 管理社区资源效率和内容投流效果 |\n\n## 9. 亚马逊运营与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 亚马逊运营 → APP/用户运营 | 销量、订单、ASIN、产品、国家、站点、成交用户 | 绑定率计算、用户触达、索评 |\n| APP/用户运营 → 亚马逊运营 | 绑定数、绑定率、活跃用户、推送效果、评价结果 | Listing/说明书/官网优化，评价计划调整 |\n| 亚马逊运营 → 评价运营 | 重点产品、推新计划、测评计划、回评目标 | 制定评价数量和评分维护策略 |\n| 评价运营 → 亚马逊运营 | 实际评价数、回评数、评分、差评、ASIN 健康状态 | 判断链接健康度和销售风险 |\n| 客服运营 → 亚马逊运营 | 售后问题、负面反馈、用户投诉、问题类型 | 优化产品、Listing、说明书和售后策略 |\n| 品牌/内容运营 → 亚马逊运营 | 品牌推广、内容曝光、社媒/KOL 数据 | 辅助亚马逊销售转化和新品启动 |\n\n## 10. 已确认问题与业务口径\n\n| 编号 | 已确认口径 | 后续影响 |\n|---|---|---|\n| Q1 | 绑定率 = APP 可识别的绑定了指定玩具的用户数 / 销售数。 | 绑定率看板按产品和 ASIN 计算。 |\n| Q2 | 支持在权限控制下查看明细，明细需要具体到每个 ASIN。 | 需要做 ASIN 级权限和涉密销量明细权限。 |\n| Q3 | S、A 级重要性由公司领导约 2-3 人和亚马逊核心总监确认，由用户运营指定人员维护。 | 产品重要级需要维护入口、确认记录和变更日志。 |\n| Q4 | 推新先用基础规则，后续逐步引入模型。当前 S 级需求最大程度满足，约 50% 流量给核心 S 级产品，其余 A/B 等产品共享约 50% 流量。 | 推新算法一期用规则引擎，二期再考虑模型。 |\n| Q5 | 测评、回评、免评计划需要审批流。亚马逊运营提出计划，亚马逊运营总监审批确认。 | 需要建立计划审批状态、审批人和审批记录。 |\n| Q6 | 4.8 很健康，4.5 健康，4.2 高风险；4.2 时需要加强对未回评用户的回评推送。 | ASIN 健康看板需要按评分阈值报警。 |\n| Q7 | 用户提供订单号时进行关联。APP 有 JOYHUB ID、注册邮箱、基础 IP、设备号、用户行为数据等；订单号可关联用户地址、姓名、用户名等。 | 用户识别需要订单号 + JOYHUB ID 双主标识，并保留辅助识别信息。 |\n| Q8 | 品牌影响力核心从两方面评估：各渠道转化、社媒影响力与调研反馈。 | 品牌看板需要同时支持转化数据和影响力反馈数据。 |\n| Q9 | 通过品牌活动前往亚马逊形成的转化，也归属品牌运营 OKR 结果。 | 销售归因需要支持品牌活动到亚马逊转化。 |\n| Q10 | APP 内社区资源由品牌运营与内容运营协同、内容运营分配；用户推送资源由用户运营管理分配。品牌运营负责将亚马逊和品牌需求与内容运营、用户运营协商解决。 | 资源排期需要区分社区资源和用户推送资源。 |\n| Q11 | 需要逐步根据亚马逊平台算法，把关键词需求、GEO 需求同步到测评计划中，综合销量、重要级、突发事件生成建议计划，再调动 IM、EDM、电话、KOC、KOL 等渠道。 | 后续需要计划生成引擎和多渠道资源调度。 |\n| Q12 | 订单号和 JOYHUB ID 是两个主要标识。订单号包括亚马逊来源和独立站来源。用户注册后必然有 JOYHUB ID，提供订单号后两者关联。 | 修正字段为“订单号”，不再使用 OA 订单号。 |\n| Q13 | 各渠道需要统一控制频率，并统一了解对用户的骚扰程度，避免过于频繁。 | 需要建设跨渠道频控和用户反感度监控。 |\n| Q14 | 注册用户的 JOYHUB ID 和邮箱必然关联；多个邮箱多账号可通过 IP、设备号等做黑名单关联，后台可按单一用户处理。 | 需要账号关联、黑名单和高风险关联用户机制。 |\n| Q15 | JOYCOLLAB 和财务都会参与。原则上 KOC 在 JOYCOLLAB 上的带货数据在网站内处理后同步到大用户后台。 | KOC/KOL/PR 看板需要支持 JOYCOLLAB 同步和财务核算校验。 |\n\n## 11. 进入项目规划前的系统设计问题\n\n当前业务链条已经基本清晰，可以进入项目规划与系统模块拆分。进入 ERP 系统设计前，需要把以下问题作为系统设计约束统一管理。\n\n### 11.1 角色权限\n\n需要明确不同角色的数据可见范围、操作权限和审批权限。\n\n重点问题：\n\n- 谁能查看销售明细？\n- 谁能查看用户邮箱、电话、订单号、地址、姓名等高度涉密字段？\n- 谁能审批、修改、暂停测评计划、回评计划、免评计划？\n- 菲律宾客服能看到哪些用户字段？\n- 内容运营能看到哪些用户行为和成交归因字段？\n\n### 11.2 计划流程状态\n\n测评、回评、免评、推送、内容投流、客服任务都需要统一状态流。\n\n建议基础状态：\n\n- 草稿\n- 待审批\n- 已审批\n- 执行中\n- 暂停\n- 异常\n- 已完成\n- 已复盘\n\n### 11.3 数据来源\n\n需要在系统层面明确每类数据的来源、同步方式、刷新频率和权限等级。\n\n| 数据类型 | 可能来源 |\n|---|---|\n| 亚马逊销量/订单 | 亚马逊运营数据源、导入表、API 或报表 |\n| 独立站订单 | 独立站系统 |\n| APP 绑定 | JOYHUB/APP 用户系统 |\n| 用户资料 | JOYHUB ID、注册邮箱、IP、设备号、用户行为数据 |\n| EDM 数据 | 邮件服务商 |\n| TEL 数据 | 电话系统或客服登记 |\n| JOYCOLLAB 数据 | JOYCOLLAB 网站 |\n| 财务/人事数据 | 财务表、人事表、成本表 |\n| 内容广告数据 | APP 广告位、社区内容系统 |\n\n### 11.4 核心业务对象\n\n后续建系统时，至少需要统一以下核心对象：\n\n- 用户\n- 订单\n- 产品\n- ASIN\n- 品牌\n- 国家/站点\n- 推送计划\n- 测评计划\n- 回评计划\n- 免评计划\n- 内容投流计划\n- 广告位\n- 客服任务\n- 合作伙伴\n- 成本记录\n- 风险用户/黑名单\n\n### 11.5 计划生成规则\n\n推新和测评计划一期建议先采用规则引擎，后续再逐步引入模型。\n\n仍需继续细化：\n\n- S/A/B 级产品资源比例是否固定，还是允许人工调整？\n- 突发事件如何插队？\n- 一个用户多久不能被重复触达？\n- 一个 ASIN 高风险时是否自动提升优先级？\n- GEO 需求如何进入计划生成？\n- 关键词需求如何与用户池匹配？\n\n### 11.6 评价健康报警\n\n评分阈值已经初步明确，但还需要补充数量类和进度类报警。\n\n待细化：\n\n- 回评数低于计划多少算异常？\n- 新品多少天内必须达到多少评价？\n- 差评率达到多少触发客服或用户运营介入？\n- ASIN 评分下降多少需要升级？\n- 评价健康报警是否自动触发回评推送计划？\n\n### 11.7 成本口径\n\n成本口径需要统一，否则无法做真实 ROI 和人效复盘。\n\n待细化：\n\n- 单评成本如何计算？\n- 返现成本是否纳入单评成本？\n- 菲律宾客服人力成本如何分摊到产品、ASIN、计划？\n- KOC/KOL 提成如何归因到订单？\n- 管理成本如何分摊？\n\n### 11.8 归因规则\n\n多渠道触达一定会发生交叉，归因规则需要系统化。\n\n典型场景：\n\n用户先看到 APP 内容广告，再收到 EDM，最后通过亚马逊购买。\n\n待确定：\n\n- 采用首触归因、末触归因、主要贡献渠道，还是多渠道权重归因？\n- 品牌活动到亚马逊成交如何归因？\n- 内容广告和用户推送都参与时如何拆分贡献？\n- KOC/KOL 带货链接与后续 APP 触达如何处理归因冲突？\n\n### 11.9 黑名单与风险用户处理\n\n黑名单与风险用户需要成为系统基础能力。\n\n待细化：\n\n- 谁能加入黑名单？\n- 黑名单是否影响推送、返现、测评资格？\n- 高风险用户是否允许客服继续跟进？\n- 多账号关联后是否自动合并为单一风险用户？\n- 黑名单查询是否支持订单号和 JOYHUB ID 双入口？\n\n### 11.10 一期项目边界建议\n\n一期不宜追求一次性覆盖所有 ERP 能力，应优先建设评价业务闭环的主干。\n\n建议一期优先：\n\n1. 产品/ASIN 看板\n2. 测评计划、回评计划、免评计划审批流\n3. 用户推送计划\n4. ASIN 评价健康看板\n5. 菲律宾客服执行看板\n6. 基础权限与涉密字段控制\n7. 基础数据导入和统一主键\n\n后续二期及以后再逐步扩展模型化计划生成、多渠道归因、复杂成本核算、内容广告优化、JOYCOLLAB 深度集成和管理层经营分析。\n\n## 12. 修改记录\n\n| 版本 | 日期 | 修改内容 | 记录人 |\n|---|---|---|---|\n| v0.7 | 2026-04-26 | 将业务链条确认后的系统设计问题写入文档；补充角色权限、计划状态流、数据来源、核心业务对象、计划生成规则、评价健康报警、成本口径、归因规则、黑名单与风险用户处理和一期项目边界建议。 | Codex |\n| v0.6 | 2026-04-26 | 追加内容运营相关业务；明确内容运营配合亚马逊运营与品牌运营进行销售前期宣发、售前社区广告计划和社区 KOC/KCO 对接；新增 APP 广告管理看板和推流管理看板，覆盖开屏、弹窗、文末、ME、评论末、加权、新帖、固定位置、固定流量池、用户行为、互动与风险字段。 | Codex |\n| v0.5 | 2026-04-26 | 追加菲律宾客服相关业务；明确菲律宾客服直接接受用户运营指导，亚马逊运营短期需求变动通过用户运营转达；新增核心指标客源、转化数、转化率、节约成本；新增人员管理、评价计划管理、成本管理三个看板及字段；补充菲律宾客服与用户运营、亚马逊运营、数据层/管理层的数据关系。 | Codex |\n| v0.4 | 2026-04-26 | 回答并固化 Q1-Q15 业务口径；明确绑定率公式、ASIN 明细权限、产品重要级确认与维护、推新资源规则、测评/回评/免评审批流、ASIN 评价健康阈值、订单号与 JOYHUB ID 双主标识、品牌影响力评估、品牌活动归因、APP 社区与用户推送资源边界、测评计划建议生成方向、跨渠道频控、黑名单关联和 JOYCOLLAB/财务数据来源。 | Codex |\n| v0.3 | 2026-04-26 | 追加用户运营相关业务；明确用户运营为系统核心使用者，客服部门归属用户部门管理；新增测评计划执行、ASIN 评价健康与回评计划、IM 社区消息推送、已成交索评、TEL 电话售后、EDM 邮件推送、KOC/KOL/PR 合作伙伴、其他触达渠道等模块；新增用户运营与其他部门的数据关系和待确认问题。 | Codex |\n| v0.2 | 2026-04-26 | 追加品牌运营相关业务；明确品牌运营与亚马逊运营不在同一办公区但共同建立销售体系；修正品牌推广计划归属为品牌运营主责、亚马逊运营同步；明确 AMZ 测评计划由亚马逊运营提需求、品牌运营协同、用户运营实际实现；新增品牌影响力与独立站销售看板、品牌推广计划协同看板、品牌运营数据关系和待确认问题。 | Codex |\n| v0.1 | 2026-04-26 | 建立评价业务流闭环项目架构文档；整理总体业务闭环、基础指标、亚马逊运营相关业务；新增销量与绑定率看板、推新计划与 APP 推送资源分配看板、测评与免评计划看板、回评计划与 ASIN 评价健康度看板、品牌推广协同数据和待确认问题。 | Codex |\n", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/README", "type": "document", "name": "需求文档", "filePath": "05_需求文档/README.md", "summary": "type: requirement inbox tags: 需求文档, 需求收集, 知识库更新, Agent aliases: 需求文档目录, 需求收集目录, 需求入口 source: manual status: active owner: 产品经理 / 业务主管 updated: 2026 05 需求文档 本目录用于集中存放后续持续补充的业务需求文档、业", "tags": [ "05_需求文档", "需求文档", "需求收集", "知识库更新", "Agent" ], "complexity": "simple", "knowledgeMeta": { "content": "---\ntype: requirement_inbox\ntags: [需求文档, 需求收集, 知识库更新, Agent]\naliases: [需求文档目录, 需求收集目录, 需求入口]\nsource: manual\nstatus: active\nowner: 产品经理 / 业务主管\nupdated: 2026-05\n---\n\n# 需求文档\n\n本目录用于集中存放后续持续补充的业务需求文档、业务规则文档、流程补充文档和需求变更文档。\n\n## 使用方式\n\n1. 所有新增需求文档优先放入本目录。\n2. 建议使用 `03_规范与模板/需求说明模板.md` 或 `03_规范与模板/业务规则与需求补充模板.md` 创建文档。\n3. 文档确认有效后，同步更新业务流程索引和 Agent 检索索引。\n4. Agent 回答具体业务需求时，应优先检索本目录。\n\n## 推荐命名\n\n```text\n业务域_需求或规则名称_YYYYMMDD.md\n```\n\n示例：\n\n```text\n采购_供应商准入规则_20260526.md\n库存_出入库审批规则_20260526.md\n销售_客户授信额度需求_20260526.md\n```\n\n## 文档状态\n\n每个需求文档建议在 Frontmatter 中维护 `status`：\n\n| 状态 | 含义 |\n|---|---|\n| draft | 草稿，尚未确认 |\n| reviewing | 评审中 |\n| active | 已确认，可作为 Agent 回答依据 |\n| deprecated | 已废弃，仅归档参考 |\n\n## 必填内容\n\n每个需求文档至少包含：\n\n- 需求背景\n- 适用范围\n- 涉及角色\n- 业务规则\n- 业务流程\n- 异常处理\n- 权限要求\n- 验收口径\n- Agent 检索字段\n- 变更记录\n\n## 索引维护\n\n新增或修改需求文档后，需要同步更新：\n\n- `05_需求文档/需求文档索引.md`\n- `01_业务流程/业务规则索引.md`\n- `01_业务流程/业务对象字典.md`\n- `04_Agent检索/关键词索引.md`\n- `04_Agent检索/同义词表.md`\n- `04_Agent检索/来源文件索引.md`\n\n## 验证流程\n\n新增需求文档后，按 `04_Agent检索/知识库持续更新与验证流程.md` 执行验证，并将验证结果记录到：\n\n- `05_需求文档/需求文档索引.md`\n- `01_业务流程/业务补充验证记录.md`\n", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/user_erp_mvp_admin_prototype_v10(1)", "type": "document", "name": "USER 后台 ERP MVP · 管理员总览原型 v10", "filePath": "05_需求文档/user_erp_mvp_admin_prototype_v10(1).html", "summary": "USER 后台 ERP MVP · 管理员总览原型 v10 JOYHUB Ops 模拟数据 第一期模拟 数据 当前模块 经营总览 系统管理员最高权限视图 常用跳转 21 重要事项 3 审核类 4 字段关系 5 问题总结 9 经营总览 系统管理员 · 最高权限 · 全部部门 搜索 至 日 周 月 全部部门 Amazon 运营 用户运营 客服 系统管理员（最高权", "tags": [ "05_需求文档", "需求文档" ], "complexity": "complex", "knowledgeMeta": { "content": "\n\n\n \n \n USER 后台 ERP MVP · 管理员总览原型 v10\n \n\n\n
\n \n\n
\n
\n
\n
\n 经营总览\n 系统管理员 · 最高权限 · 全部部门\n
\n
\n 搜索\n \n
\n
\n
\n
\n \n 至\n \n
\n
\n \n \n \n
\n \n \n \n
\n
\n\n
\n
\n
\n\n
\n \n\n
\n
\n
\n

操作确认

\n \n
\n
\n
\n
\n\n
\n\n \n\n\n", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/user_erp_mvp_admin_prototype_v10", "type": "document", "name": "USER 后台 ERP MVP · 管理员总览原型 v10", "filePath": "05_需求文档/user_erp_mvp_admin_prototype_v10.html", "summary": "USER 后台 ERP MVP · 管理员总览原型 v10 JOYHUB Ops 💬 3 IM 消息 当前模块 经营总览 系统管理员最高权限视图 常用跳转 21 重要事项 3 审核类 4 字段关系 5 问题总结 9 经营总览 系统管理员 · 最高权限 · 全部部门 搜索 至 日 周 月 全部部门 Amazon 运营 用户运营 客服 系统管理员（最高权限） A", "tags": [ "05_需求文档", "需求文档" ], "complexity": "complex", "knowledgeMeta": { "content": "\n\n\n \n \n USER 后台 ERP MVP · 管理员总览原型 v10\n \n\n\n
\n \n\n
\n
\n
\n
\n 经营总览\n 系统管理员 · 最高权限 · 全部部门\n
\n
\n 搜索\n \n
\n
\n
\n
\n \n 至\n \n
\n
\n \n \n \n
\n \n \n \n
\n
\n\n
\n
\n
\n\n
\n \n\n
\n
\n
\n

操作确认

\n \n
\n
\n
\n
\n\n
\n\n
\n \n\n \n\n\n", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/客服执行", "type": "document", "name": "客服执行看板", "filePath": "05_需求文档/客服执行.html", "summary": "客服执行看板", "tags": [ "05_需求文档", "需求文档" ], "complexity": "complex", "knowledgeMeta": { "content": "\n\n \n \n \n 客服执行看板\n \n \n \n
\n \n \n\r\n", "wikilinks": [], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/用户运营系统-单文件", "type": "document", "name": "USER评价业务闭环系统", "filePath": "05_需求文档/用户运营系统-单文件.html", "summary": "USER评价业务闭环系统", "tags": [ "05_需求文档", "需求文档" ], "complexity": "complex", "knowledgeMeta": { "content": "\n\n \n \n \n USER评价业务闭环系统\n \n \n \n \n
\n \n\n", "wikilinks": [ "10,15", "^\\", "^\\", "^\\", "^\\", "3,9", "r,n", "1,0", "1,\"rgba(207,212,219,0.2)\"", "\"rect\"", "e", "0,0", "t,t", "o.x,o.y", "s.x,s.y", "1,\"#E6EBF8\"" ], "category": "layer-requirements" } }, { "id": "doc:05_需求文档/需求文档索引", "type": "document", "name": "需求文档索引", "filePath": "05_需求文档/需求文档索引.md", "summary": "type: requirement index tags: 需求文档, 索引, Agent检索 aliases: 需求索引, 需求文档清单, 需求清单 source: manual status: active owner: 产品经理 / 业务主管 updated: 2026 05 需求文档索引 本文件记录 05 需求文档/ 下所有正式需求文档，供人工维护和", "tags": [ "05_需求文档", "需求文档", "索引", "Agent检索" ], "complexity": "simple", "knowledgeMeta": { "content": "---\ntype: requirement_index\ntags: [需求文档, 索引, Agent检索]\naliases: [需求索引, 需求文档清单, 需求清单]\nsource: manual\nstatus: active\nowner: 产品经理 / 业务主管\nupdated: 2026-05\n---\n\n# 需求文档索引\n\n本文件记录 `05_需求文档/` 下所有正式需求文档，供人工维护和 Agent 检索定位。\n\n## 需求文档清单\n\n| 编号 | 业务域 | 需求/规则名称 | 文件 | 状态 | 负责人 | 更新时间 | 验证状态 |\n|---|---|---|---|---|---|---|---|\n| | | | | | | | 未验证 |\n\n## Agent 检索关键词\n\n| 关键词/问法 | 标准术语 | 命中文件 | 答案要点 |\n|---|---|---|---|\n| | | | |\n\n## 维护规则\n\n1. 新增需求文档后，必须在“需求文档清单”新增一行。\n2. 每个需求文档至少维护 3 个可检索问法。\n3. `状态=active` 的文档可作为 Agent 回答依据。\n4. `status=draft/reviewing` 的文档只能作为草稿参考，Agent 回答时需说明尚未确认。\n5. `status=deprecated` 的文档不得作为当前规则依据，只能说明历史背景。\n\n## 验证记录摘要\n\n| 日期 | 文件 | 验证问题数 | 通过数 | 失败数 | 结论 |\n|---|---|---:|---:|---:|---|\n| | | | | | |\n", "wikilinks": [], "category": "layer-requirements" } } ], "edges": [ { "source": "article:00_首页/知识库首页", "target": "article:00_首页/知识地图", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:00_首页/知识库首页", "target": "article:00_首页/Agent问答入口", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:01_业务流程/README", "target": "article:01_业务流程/业务流程模板", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:01_业务流程/README", "target": "article:01_业务流程/业务对象字典", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:01_业务流程/README", "target": "article:01_业务流程/业务规则索引", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "target": "article:02_项目管理流程/阶段0_项目入口分级", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "target": "article:02_项目管理流程/阶段1_业务需求完整形成", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "target": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "target": "article:02_项目管理流程/阶段2.5_测试提前补漏", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "target": "article:02_项目管理流程/阶段3_研发协作与正式开发", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "target": "article:02_项目管理流程/阶段4_测试培训上线回流", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "target": "article:02_项目管理流程/角色职责矩阵", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "target": "article:02_项目管理流程/阶段交付物清单", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "target": "article:02_项目管理流程/项目检查清单", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/README", "target": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/README", "target": "article:02_项目管理流程/阶段0_项目入口分级", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/README", "target": "article:02_项目管理流程/阶段1_业务需求完整形成", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/README", "target": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/README", "target": "article:02_项目管理流程/阶段2.5_测试提前补漏", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/README", "target": "article:02_项目管理流程/阶段3_研发协作与正式开发", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/README", "target": "article:02_项目管理流程/阶段4_测试培训上线回流", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/README", "target": "article:02_项目管理流程/角色职责矩阵", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/README", "target": "article:02_项目管理流程/阶段交付物清单", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/README", "target": "article:02_项目管理流程/项目检查清单", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/README", "target": "article:02_项目管理流程/常见问题FAQ", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/常见问题FAQ", "target": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/常见问题FAQ", "target": "article:02_项目管理流程/阶段0_项目入口分级", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/常见问题FAQ", "target": "article:02_项目管理流程/角色职责矩阵", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/常见问题FAQ", "target": "article:02_项目管理流程/阶段1_业务需求完整形成", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/常见问题FAQ", "target": "article:02_项目管理流程/阶段2.5_测试提前补漏", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/常见问题FAQ", "target": "article:02_项目管理流程/阶段交付物清单", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/常见问题FAQ", "target": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/常见问题FAQ", "target": "article:02_项目管理流程/阶段3_研发协作与正式开发", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/常见问题FAQ", "target": "article:02_项目管理流程/阶段4_测试培训上线回流", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/常见问题FAQ", "target": "article:02_项目管理流程/项目检查清单", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/角色职责矩阵", "target": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/角色职责矩阵", "target": "article:02_项目管理流程/阶段0_项目入口分级", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/角色职责矩阵", "target": "article:02_项目管理流程/阶段1_业务需求完整形成", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/角色职责矩阵", "target": "article:02_项目管理流程/阶段2.5_测试提前补漏", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/角色职责矩阵", "target": "article:02_项目管理流程/阶段4_测试培训上线回流", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段0_项目入口分级", "target": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段0_项目入口分级", "target": "article:02_项目管理流程/角色职责矩阵", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段0_项目入口分级", "target": "article:02_项目管理流程/阶段交付物清单", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段1_业务需求完整形成", "target": "article:02_项目管理流程/阶段0_项目入口分级", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段1_业务需求完整形成", "target": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段1_业务需求完整形成", "target": "article:02_项目管理流程/角色职责矩阵", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段1_业务需求完整形成", "target": "article:02_项目管理流程/阶段交付物清单", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段2.5_测试提前补漏", "target": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段2.5_测试提前补漏", "target": "article:02_项目管理流程/阶段3_研发协作与正式开发", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段2.5_测试提前补漏", "target": "article:02_项目管理流程/项目检查清单", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", "target": "article:02_项目管理流程/阶段1_业务需求完整形成", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", "target": "article:02_项目管理流程/阶段2.5_测试提前补漏", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", "target": "article:02_项目管理流程/阶段交付物清单", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段3_研发协作与正式开发", "target": "article:02_项目管理流程/阶段2.5_测试提前补漏", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段3_研发协作与正式开发", "target": "article:02_项目管理流程/阶段4_测试培训上线回流", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段3_研发协作与正式开发", "target": "article:02_项目管理流程/阶段交付物清单", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段4_测试培训上线回流", "target": "article:02_项目管理流程/阶段3_研发协作与正式开发", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段4_测试培训上线回流", "target": "article:02_项目管理流程/项目检查清单", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段4_测试培训上线回流", "target": "article:02_项目管理流程/阶段交付物清单", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段交付物清单", "target": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/阶段交付物清单", "target": "article:02_项目管理流程/项目检查清单", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/项目检查清单", "target": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:02_项目管理流程/项目检查清单", "target": "article:02_项目管理流程/阶段交付物清单", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:04_Agent检索/检索说明", "target": "article:04_Agent检索/知识库持续更新与验证流程", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:06_里程碑/README", "target": "article:06_里程碑/里程碑索引", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:06_里程碑/README", "target": "article:06_里程碑/阶段计划模板", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:06_里程碑/README", "target": "article:06_里程碑/里程碑评审记录", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:07_技术文档/README", "target": "article:07_技术文档/技术文档索引", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:07_技术文档/README", "target": "article:07_技术文档/系统架构说明模板", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:07_技术文档/README", "target": "article:07_技术文档/接口说明模板", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:07_技术文档/README", "target": "article:07_技术文档/技术决策记录", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:08_测试相关/README", "target": "article:08_测试相关/测试用例索引", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:08_测试相关/README", "target": "article:08_测试相关/测试用例模板", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:08_测试相关/README", "target": "article:08_测试相关/测试计划模板", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:08_测试相关/README", "target": "article:08_测试相关/缺陷记录模板", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:08_测试相关/README", "target": "article:08_测试相关/验收记录模板", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:08_测试相关/README", "target": "article:03_规范与模板/上线检查模板", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:欢迎", "target": "article:00_首页/知识库首页", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:欢迎", "target": "article:知识库使用说明", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:欢迎", "target": "article:00_首页/知识地图", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:欢迎", "target": "article:00_首页/Agent问答入口", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:欢迎", "target": "article:05_需求文档/README", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:欢迎", "target": "article:06_里程碑/README", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:欢迎", "target": "article:07_技术文档/README", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:欢迎", "target": "article:08_测试相关/README", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:欢迎", "target": "article:04_Agent检索/检索说明", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:欢迎", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:00_首页/知识库首页", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:00_首页/知识地图", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:00_首页/Agent问答入口", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:04_Agent检索/检索说明", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:05_需求文档/README", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:06_里程碑/README", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:07_技术文档/README", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:08_测试相关/README", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:04_Agent检索/来源文件索引", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:05_需求文档/需求文档索引", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:01_业务流程/业务规则索引", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:01_业务流程/业务对象字典", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:04_Agent检索/关键词索引", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:06_里程碑/里程碑索引", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:07_技术文档/技术文档索引", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:08_测试相关/测试用例索引", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:04_Agent检索/同义词表", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "article:知识库使用说明", "target": "article:04_Agent检索/知识库持续更新与验证流程", "type": "related", "direction": "forward", "weight": 0.7 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/00-系统总览", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/01-子系统-用户身份与上下文", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/02-子系统-需求与计划管理", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/03-子系统-额度与频控", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/04-子系统-多渠道触达引擎", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/05-子系统-客服工单与管理", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/06-子系统-风险与反欺诈", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/07-子系统-评价结果追踪", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/08-子系统-KOC-KOL协作", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/09-子系统-审计与通知中心", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/evaluation-business-architecture", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/README", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/user_erp_mvp_admin_prototype_v10(1)", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/user_erp_mvp_admin_prototype_v10", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/客服执行", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/用户运营系统-单文件", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 }, { "source": "flow:layer-requirements", "target": "doc:05_需求文档/需求文档索引", "type": "documents", "direction": "forward", "description": "本层文档", "weight": 0.65 } ], "layers": [ { "id": "layer:使用说明", "name": "使用说明", "description": "使用说明 (1 nodes)", "nodeIds": [ "topic:使用说明" ] }, { "id": "layer:需求文档", "name": "需求文档", "description": "需求文档 (1 nodes)", "nodeIds": [ "topic:需求文档" ] }, { "id": "layer:里程碑", "name": "里程碑", "description": "里程碑 (1 nodes)", "nodeIds": [ "topic:里程碑" ] }, { "id": "layer:技术文档", "name": "技术文档", "description": "技术文档 (1 nodes)", "nodeIds": [ "topic:技术文档" ] }, { "id": "layer:测试相关", "name": "测试相关", "description": "测试相关 (1 nodes)", "nodeIds": [ "topic:测试相关" ] }, { "id": "layer:agent-检索", "name": "Agent 检索", "description": "Agent 检索 (1 nodes)", "nodeIds": [ "topic:agent-检索" ] }, { "id": "layer:other", "name": "Other", "description": "Uncategorized nodes (54)", "nodeIds": [ "article:00_首页/Agent问答入口", "article:00_首页/知识地图", "article:00_首页/知识库首页", "article:01_业务流程/README", "article:01_业务流程/业务对象字典", "article:01_业务流程/业务流程模板", "article:01_业务流程/业务补充验证记录", "article:01_业务流程/业务规则索引", "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", "article:02_项目管理流程/README", "article:02_项目管理流程/常见问题FAQ", "article:02_项目管理流程/角色职责矩阵", "article:02_项目管理流程/阶段0_项目入口分级", "article:02_项目管理流程/阶段1_业务需求完整形成", "article:02_项目管理流程/阶段2.5_测试提前补漏", "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", "article:02_项目管理流程/阶段3_研发协作与正式开发", "article:02_项目管理流程/阶段4_测试培训上线回流", "article:02_项目管理流程/阶段交付物清单", "article:02_项目管理流程/项目检查清单", "article:03_规范与模板/上线检查模板", "article:03_规范与模板/业务流程梳理模板", "article:03_规范与模板/业务规则与需求补充模板", "article:03_规范与模板/会议纪要模板", "article:03_规范与模板/需求说明模板", "article:04_Agent检索/关键词索引", "article:04_Agent检索/同义词表", "article:04_Agent检索/来源文件索引", "article:04_Agent检索/检索说明", "article:04_Agent检索/知识库持续更新与验证流程", "article:04_Agent检索/问答提示词", "article:05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3", "article:05_需求文档/README", "article:05_需求文档/需求文档索引", "article:06_里程碑/README", "article:06_里程碑/里程碑索引", "article:06_里程碑/里程碑评审记录", "article:06_里程碑/阶段计划模板", "article:07_技术文档/README", "article:07_技术文档/技术决策记录", "article:07_技术文档/技术文档索引", "article:07_技术文档/接口说明模板", "article:07_技术文档/系统架构说明模板", "article:08_测试相关/README", "article:08_测试相关/上线检查模板", "article:08_测试相关/测试用例模板", "article:08_测试相关/测试用例索引", "article:08_测试相关/测试计划模板", "article:08_测试相关/缺陷记录模板", "article:08_测试相关/验收记录模板", "article:20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", "article:欢迎", "article:知识库使用说明", "source:AI_驱动_内部系统开发流程_V3" ] }, { "id": "layer-requirements", "name": "需求文档", "description": "所有正式需求、业务规则、需求变更和需求索引。", "nodeIds": [ "flow:layer-requirements", "doc:05_需求文档/00-系统总览", "doc:05_需求文档/01-子系统-用户身份与上下文", "doc:05_需求文档/02-子系统-需求与计划管理", "doc:05_需求文档/03-子系统-额度与频控", "doc:05_需求文档/04-子系统-多渠道触达引擎", "doc:05_需求文档/05-子系统-客服工单与管理", "doc:05_需求文档/06-子系统-风险与反欺诈", "doc:05_需求文档/07-子系统-评价结果追踪", "doc:05_需求文档/08-子系统-KOC-KOL协作", "doc:05_需求文档/09-子系统-审计与通知中心", "doc:05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7", "doc:05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", "doc:05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3", "doc:05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2", "doc:05_需求文档/evaluation-business-architecture", "doc:05_需求文档/README", "doc:05_需求文档/user_erp_mvp_admin_prototype_v10(1)", "doc:05_需求文档/user_erp_mvp_admin_prototype_v10", "doc:05_需求文档/客服执行", "doc:05_需求文档/用户运营系统-单文件", "doc:05_需求文档/需求文档索引" ] } ], "tour": [ { "order": 1, "title": "使用说明", "description": "Explore the 使用说明 section (2 articles)", "nodeIds": [ "topic:使用说明" ] }, { "order": 2, "title": "需求文档", "description": "Explore the 需求文档 section (6 articles)", "nodeIds": [ "topic:需求文档" ] }, { "order": 3, "title": "里程碑", "description": "Explore the 里程碑 section (7 articles)", "nodeIds": [ "topic:里程碑" ] }, { "order": 4, "title": "技术文档", "description": "Explore the 技术文档 section (5 articles)", "nodeIds": [ "topic:技术文档" ] }, { "order": 5, "title": "测试相关", "description": "Explore the 测试相关 section (9 articles)", "nodeIds": [ "topic:测试相关" ] }, { "order": 6, "title": "Agent 检索", "description": "Explore the Agent 检索 section (6 articles)", "nodeIds": [ "topic:agent-检索" ] } ] }