{
"version": "1.0.0",
"kind": "codebase",
"project": {
"name": "如愿知识库",
"languages": [
"markdown"
],
"frameworks": [
"Understand-Anything",
"Obsidian"
],
"description": "按需求文档、里程碑、技术文档、测试相关、Agent检索组织的流程式知识库。",
"analyzedAt": "2026-05-29T06:03:33.440Z",
"gitCommitHash": ""
},
"nodes": [
{
"id": "doc:00_首页/Agent问答入口",
"type": "document",
"name": "Agent 问答入口",
"filePath": "00_首页/Agent问答入口.md",
"summary": "当用户询问业务或项目流程时,Agent 应先检索本知识库 Markdown 文件,再组织回答。",
"tags": [
"00_首页",
"Agent检索"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-overview"
}
},
{
"id": "doc:00_首页/知识地图",
"type": "document",
"name": "知识地图",
"filePath": "00_首页/知识地图.md",
"summary": "- [[../知识库使用说明|知识库使用说明]]",
"tags": [
"00_首页"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-overview"
}
},
{
"id": "doc:00_首页/知识库首页",
"type": "document",
"name": "如愿知识库首页",
"filePath": "00_首页/知识库首页.md",
"summary": "本知识库用于沉淀如愿内部系统建设中的业务流程、项目管理流程、角色职责、交付物、检查清单与 Agent 检索问答规范。",
"tags": [
"00_首页"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-overview"
}
},
{
"id": "doc:02_项目管理流程/AI驱动内部系统开发流程_V3_总览",
"type": "document",
"name": "AI 驱动内部系统开发流程 V3 总览",
"filePath": "02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md",
"summary": "本流程适用于公司当前阶段的 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。",
"tags": [
"02_项目管理流程"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "doc:02_项目管理流程/README",
"type": "document",
"name": "项目管理流程",
"filePath": "02_项目管理流程/README.md",
"summary": "本目录基于 `AI_驱动_内部系统开发流程_V3.docx` 拆解,用于指导 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。",
"tags": [
"02_项目管理流程"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "doc:02_项目管理流程/常见问题FAQ",
"type": "document",
"name": "常见问题 FAQ",
"filePath": "02_项目管理流程/常见问题FAQ.md",
"summary": "通常经过阶段0项目入口分级、阶段1业务需求完整形成、阶段2高保真模型与业务对象确认、阶段2.5测试提前补漏、阶段3研发协作与正式开发、阶段4测试培训上线回流。文档还定义了阶段5技术债治理与能力沉淀。",
"tags": [
"02_项目管理流程"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "doc:02_项目管理流程/角色职责矩阵",
"type": "document",
"name": "角色职责矩阵",
"filePath": "02_项目管理流程/角色职责矩阵.md",
"summary": "业务主管保证方向正确、主流程清楚、需求不漏大块。",
"tags": [
"02_项目管理流程"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "doc:02_项目管理流程/阶段0_项目入口分级",
"type": "document",
"name": "阶段0 项目入口分级",
"filePath": "02_项目管理流程/阶段0_项目入口分级.md",
"summary": "不是所有需求都应该进入完整开发流程。阶段0用于判断项目是否值得做,以及走轻流程还是完整流程。",
"tags": [
"02_项目管理流程"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "doc:02_项目管理流程/阶段1_业务需求完整形成",
"type": "document",
"name": "阶段1 业务需求完整形成",
"filePath": "02_项目管理流程/阶段1_业务需求完整形成.md",
"summary": "业务侧通过 Vibe Coding 跑完整需求。阶段1追求需求完整,不追求产品完善。",
"tags": [
"02_项目管理流程",
"需求文档"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "doc:02_项目管理流程/阶段2.5_测试提前补漏",
"type": "document",
"name": "阶段2.5 测试提前补漏",
"filePath": "02_项目管理流程/阶段2.5_测试提前补漏.md",
"summary": "在开发前用测试视角发现需求漏洞。测试提前补漏,不只是上线前找 Bug。",
"tags": [
"02_项目管理流程",
"测试相关"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "doc:02_项目管理流程/阶段2_高保真模型与业务对象确认",
"type": "document",
"name": "阶段2 高保真模型与业务对象确认",
"filePath": "02_项目管理流程/阶段2_高保真模型与业务对象确认.md",
"summary": "把完整但粗糙的需求收敛成可开发模型。阶段2追求模型高效,前端必须深度参与。",
"tags": [
"02_项目管理流程"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "doc:02_项目管理流程/阶段3_研发协作与正式开发",
"type": "document",
"name": "阶段3 研发协作与正式开发",
"filePath": "02_项目管理流程/阶段3_研发协作与正式开发.md",
"summary": "基于高保真模型进行模块化、安全、可维护开发。研发阶段以代码质量、模块化、安全性、可维护性为中心。",
"tags": [
"02_项目管理流程"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "doc:02_项目管理流程/阶段4_测试培训上线回流",
"type": "document",
"name": "阶段4 测试培训上线回流",
"filePath": "02_项目管理流程/阶段4_测试培训上线回流.md",
"summary": "完成测试、培训、上线验收和问题回流。测试保证系统真实可用,并帮助业务人员正确使用。",
"tags": [
"02_项目管理流程",
"测试相关"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "doc:02_项目管理流程/阶段交付物清单",
"type": "document",
"name": "阶段交付物清单",
"filePath": "02_项目管理流程/阶段交付物清单.md",
"summary": "- [[AI驱动内部系统开发流程_V3_总览]]",
"tags": [
"02_项目管理流程"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "doc:02_项目管理流程/项目检查清单",
"type": "document",
"name": "项目检查清单",
"filePath": "02_项目管理流程/项目检查清单.md",
"summary": "- [ ] 确认项目值得做。",
"tags": [
"02_项目管理流程"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "doc:04_Agent检索/关键词索引",
"type": "document",
"name": "关键词索引",
"filePath": "04_Agent检索/关键词索引.md",
"summary": "知识库文档。",
"tags": [
"04_Agent检索",
"Agent检索"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-agent"
}
},
{
"id": "doc:04_Agent检索/同义词表",
"type": "document",
"name": "同义词表",
"filePath": "04_Agent检索/同义词表.md",
"summary": "知识库文档。",
"tags": [
"04_Agent检索",
"Agent检索"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-agent"
}
},
{
"id": "doc:04_Agent检索/来源文件索引",
"type": "document",
"name": "来源文件索引",
"filePath": "04_Agent检索/来源文件索引.md",
"summary": "- 从原始 docx 更新流程时,需要同步更新阶段文件、角色职责矩阵、交付物清单、检查清单、FAQ、关键词索引和同义词表。",
"tags": [
"04_Agent检索",
"Agent检索"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-agent"
}
},
{
"id": "doc:04_Agent检索/检索说明",
"type": "document",
"name": "Agent 检索说明",
"filePath": "04_Agent检索/检索说明.md",
"summary": "让 Agent 在回答业务流程和项目管理流程问题时,优先基于本地 Markdown 知识库检索,而不是凭空回答。",
"tags": [
"04_Agent检索",
"Agent检索"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-agent"
}
},
{
"id": "doc:04_Agent检索/知识库持续更新与验证流程",
"type": "document",
"name": "知识库持续更新与验证流程",
"filePath": "04_Agent检索/知识库持续更新与验证流程.md",
"summary": "确保业务规则、业务需求和流程补充后,Agent 能通过文件检索命中新内容,并基于知识库给出可追溯回答。",
"tags": [
"04_Agent检索",
"Agent检索"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-agent"
}
},
{
"id": "doc:04_Agent检索/问答提示词",
"type": "document",
"name": "问答提示词",
"filePath": "04_Agent检索/问答提示词.md",
"summary": "你是如愿内部知识库问答 Agent。你必须优先检索本地 Markdown 知识库,再回答业务流程、项目管理流程、角色职责、交付物、检查清单和模板相关问题。",
"tags": [
"04_Agent检索",
"Agent检索"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-agent"
}
},
{
"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_需求文档/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_需求文档/需求文档索引",
"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"
}
},
{
"id": "doc:06_里程碑/README",
"type": "document",
"name": "里程碑",
"filePath": "06_里程碑/README.md",
"summary": "本目录用于存放项目阶段计划、里程碑节点、阶段评审记录和上线节奏说明。",
"tags": [
"06_里程碑",
"里程碑"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "doc:06_里程碑/里程碑索引",
"type": "document",
"name": "里程碑索引",
"filePath": "06_里程碑/里程碑索引.md",
"summary": "- 新增里程碑计划后,在本索引登记。",
"tags": [
"06_里程碑",
"里程碑"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "doc:06_里程碑/里程碑评审记录",
"type": "document",
"name": "里程碑评审记录",
"filePath": "06_里程碑/里程碑评审记录.md",
"summary": "知识库文档。",
"tags": [
"06_里程碑",
"里程碑"
],
"complexity": "simple",
"knowledgeMeta": {
"content": "---\ntype: milestone_review_log\ntags: [里程碑, 评审, 记录]\naliases: [阶段评审记录, 里程碑评审]\nsource: manual\nstatus: active\nowner: 项目经理\nupdated: 2026-05\n---\n\n# 里程碑评审记录\n\n| 日期 | 项目 | 阶段 | 评审结论 | 遗留问题 | 负责人 | 后续动作 |\n|---|---|---|---|---|---|---|\n| | | | | | | |\n",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "doc:06_里程碑/阶段计划模板",
"type": "document",
"name": "阶段计划模板",
"filePath": "06_里程碑/阶段计划模板.md",
"summary": "- 需求文档:",
"tags": [
"06_里程碑",
"里程碑"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "doc:07_技术文档/README",
"type": "document",
"name": "技术文档",
"filePath": "07_技术文档/README.md",
"summary": "type: technical docs home tags: 技术文档, 架构, 开发, 知识库 aliases: 技术文档入口, 技术资料 source: manual status: active owner: 技术负责人 updated: 2026 05 技术文档 本目录用于存放系统架构、数据模型、接口说明、实现方案、部署说明和技术决策记录。 二级入",
"tags": [
"07_技术文档",
"技术文档",
"架构",
"开发",
"知识库"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [
"技术文档索引",
"系统架构说明模板",
"接口说明模板",
"技术决策记录",
"../05_需求文档/README|需求文档",
"../08_测试相关/README|测试相关",
"../06_里程碑/README|里程碑"
],
"category": "layer-technical"
}
},
{
"id": "doc:07_技术文档/技术决策记录",
"type": "document",
"name": "技术决策记录",
"filePath": "07_技术文档/技术决策记录.md",
"summary": "type: adr log tags: 技术文档, 技术决策, ADR aliases: 技术决策, ADR source: manual status: active owner: 技术负责人 updated: 2026 05 技术决策记录 日期 决策主题 背景 决策结论 影响范围 关联需求/技术文档",
"tags": [
"07_技术文档",
"技术文档",
"技术决策",
"ADR"
],
"complexity": "simple",
"knowledgeMeta": {
"content": "---\ntype: adr_log\ntags: [技术文档, 技术决策, ADR]\naliases: [技术决策, ADR]\nsource: manual\nstatus: active\nowner: 技术负责人\nupdated: 2026-05\n---\n\n# 技术决策记录\n\n| 日期 | 决策主题 | 背景 | 决策结论 | 影响范围 | 关联需求/技术文档 |\n|---|---|---|---|---|---|\n| | | | | | |\n",
"wikilinks": [],
"category": "layer-technical"
}
},
{
"id": "doc:07_技术文档/技术文档索引",
"type": "document",
"name": "技术文档索引",
"filePath": "07_技术文档/技术文档索引.md",
"summary": "type: technical docs index tags: 技术文档, 索引, Agent检索 aliases: 技术索引, 技术资料清单 source: manual status: active owner: 技术负责人 updated: 2026 05 技术文档索引 技术文档清单 模块/系统 文档类型 文件 关联需求 负责人 更新时间 状态 Ag",
"tags": [
"07_技术文档",
"技术文档",
"索引",
"Agent检索"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-technical"
}
},
{
"id": "doc:07_技术文档/接口说明模板",
"type": "document",
"name": "接口说明模板",
"filePath": "07_技术文档/接口说明模板.md",
"summary": "type: api template tags: 技术文档, 接口, 模板 aliases: 接口模板, API说明模板 source: manual status: active owner: 技术负责人 updated: 2026 05 接口说明模板 基本信息 项目 内容 接口名称 所属模块 关联需求 负责人 状态 draft 接口用途 请求说明 字段 ",
"tags": [
"07_技术文档",
"技术文档",
"接口",
"模板"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-technical"
}
},
{
"id": "doc:07_技术文档/系统架构说明模板",
"type": "document",
"name": "系统架构说明模板",
"filePath": "07_技术文档/系统架构说明模板.md",
"summary": "type: architecture template tags: 技术文档, 架构, 模板 aliases: 架构说明模板 source: manual status: active owner: 技术负责人 updated: 2026 05 系统架构说明模板 基本信息 项目 内容 系统/模块 关联需求 负责人 状态 draft 背景与目标 架构说明 模块",
"tags": [
"07_技术文档",
"技术文档",
"架构",
"模板"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-technical"
}
},
{
"id": "doc:08_测试相关/README",
"type": "document",
"name": "测试相关",
"filePath": "08_测试相关/README.md",
"summary": "type: testing home tags: 测试, 测试用例, 验收, 知识库 aliases: 测试相关入口, 测试文档 source: manual status: active owner: 测试负责人 updated: 2026 05 测试相关 本目录用于存放测试计划、测试用例、测试报告、缺陷记录、验收记录和上线检查材料。 二级入口 测试用例索",
"tags": [
"08_测试相关",
"测试相关",
"测试",
"测试用例",
"验收",
"知识库"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [
"测试用例索引",
"测试用例模板",
"测试计划模板",
"缺陷记录模板",
"验收记录模板",
"上线检查模板",
"../05_需求文档/README|需求文档",
"../07_技术文档/README|技术文档",
"../06_里程碑/README|里程碑",
"../02_项目管理流程/阶段2.5_测试提前补漏|阶段2.5 测试提前补漏",
"../02_项目管理流程/阶段4_测试培训上线回流|阶段4 测试培训上线回流"
],
"category": "layer-testing"
}
},
{
"id": "doc:08_测试相关/上线检查模板",
"type": "document",
"name": "上线检查模板",
"filePath": "08_测试相关/上线检查模板.md",
"summary": "type: go live checklist template tags: 上线检查, 测试, 模板 aliases: 上线检查, 发布检查 source: manual status: active owner: 测试负责人 / 项目经理 updated: 2026 05 上线检查模板 基本信息 项目 内容 项目/模块 关联需求 关联里程碑 负责人 检查",
"tags": [
"08_测试相关",
"测试相关",
"上线检查",
"测试",
"模板"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-testing"
}
},
{
"id": "doc:08_测试相关/测试用例模板",
"type": "document",
"name": "测试用例模板",
"filePath": "08_测试相关/测试用例模板.md",
"summary": "type: test case template tags: 测试用例, 测试, 模板 aliases: 用例模板, 测试用例 source: manual status: active owner: 测试负责人 updated: 2026 05 测试用例模板 基本信息 项目 内容 项目/模块 关联需求 关联技术文档 测试负责人 状态 draft 测试范围 ",
"tags": [
"08_测试相关",
"测试相关",
"测试用例",
"测试",
"模板"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-testing"
}
},
{
"id": "doc:08_测试相关/测试用例索引",
"type": "document",
"name": "测试用例索引",
"filePath": "08_测试相关/测试用例索引.md",
"summary": "type: test case index tags: 测试用例, 测试, 索引, Agent检索 aliases: 测试用例清单, 用例索引 source: manual status: active owner: 测试负责人 updated: 2026 05 测试用例索引 测试用例清单 编号 项目/模块 用例集名称 文件 关联需求 关联技术文档 负责人 ",
"tags": [
"08_测试相关",
"测试相关",
"测试用例",
"测试",
"索引",
"Agent检索"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-testing"
}
},
{
"id": "doc:08_测试相关/测试计划模板",
"type": "document",
"name": "测试计划模板",
"filePath": "08_测试相关/测试计划模板.md",
"summary": "type: test plan template tags: 测试计划, 测试, 模板 aliases: 测试计划模板 source: manual status: active owner: 测试负责人 updated: 2026 05 测试计划模板 基本信息 项目 内容 项目/模块 关联需求 关联里程碑 测试负责人 计划周期 测试目标 测试范围 不在范围",
"tags": [
"08_测试相关",
"测试相关",
"测试计划",
"测试",
"模板"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-testing"
}
},
{
"id": "doc:08_测试相关/缺陷记录模板",
"type": "document",
"name": "缺陷记录模板",
"filePath": "08_测试相关/缺陷记录模板.md",
"summary": "type: defect template tags: 缺陷, 测试, 模板 aliases: Bug记录模板, 缺陷记录 source: manual status: active owner: 测试负责人 updated: 2026 05 缺陷记录模板 基本信息 项目 内容 缺陷编号 BUG 项目/模块 关联需求 关联用例 严重级别 当前状态 open ",
"tags": [
"08_测试相关",
"测试相关",
"缺陷",
"测试",
"模板"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-testing"
}
},
{
"id": "doc:08_测试相关/验收记录模板",
"type": "document",
"name": "验收记录模板",
"filePath": "08_测试相关/验收记录模板.md",
"summary": "type: acceptance template tags: 验收, 测试, 模板 aliases: 验收记录, UAT模板 source: manual status: active owner: 测试负责人 / 业务负责人 updated: 2026 05 验收记录模板 基本信息 项目 内容 项目/模块 关联需求 关联测试用例 验收负责人 验收日期 验",
"tags": [
"08_测试相关",
"测试相关",
"验收",
"测试",
"模板"
],
"complexity": "simple",
"knowledgeMeta": {
"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",
"wikilinks": [],
"category": "layer-testing"
}
},
{
"id": "doc:欢迎",
"type": "document",
"name": "欢迎使用如愿知识库",
"filePath": "欢迎.md",
"summary": "请从 [[00_首页/知识库首页]] 开始。",
"tags": [
"欢迎.md"
],
"complexity": "simple",
"knowledgeMeta": {
"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检索/检索说明]]",
"wikilinks": [],
"category": "layer-overview"
}
},
{
"id": "doc:知识库使用说明",
"type": "document",
"name": "如愿知识库使用说明",
"filePath": "知识库使用说明.md",
"summary": "本文档说明如愿知识库的用途、目录结构、文档存放规则、索引维护规则、Obsidian 图谱使用方式,以及 Agent 如何基于知识库回答问题。",
"tags": [
"知识库使用说明.md"
],
"complexity": "moderate",
"knowledgeMeta": {
"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\n放入:\n\n```text\n99_归档/\n```\n\n适合存放:\n\n- 已废弃文档\n- 历史版本\n- 仅供参考内容\n- 不再作为当前依据的旧规则\n\n归档文档不应作为 Agent 当前回答依据,除非问题明确询问历史背景。\n\n## 6. Agent 检索优先级\n\nAgent 回答问题时,按以下顺序查找依据:\n\n1. `05_需求文档/`:正式需求、业务规则、需求变更。\n2. `06_里程碑/`:项目节点、阶段计划、阶段评审、上线节奏。\n3. `07_技术文档/`:系统架构、数据模型、接口说明、实现方案、技术决策。\n4. `08_测试相关/`:测试计划、测试用例、缺陷记录、验收记录、上线检查。\n5. `02_项目管理流程/`:内部系统开发流程、阶段、角色、门禁、交付物、检查清单。\n6. `01_业务流程/`:真实业务流程、业务对象、业务规则。\n7. `04_Agent检索/`:关键词、同义词、来源索引、回答规则。\n8. `03_规范与模板/`:需要产出模板或文档时使用。\n\nAgent 回答必须注明来源文件。\n\n## 7. 不同问题应该查哪里\n\n| 问题类型 | 优先查找位置 |\n|---|---|\n| 某个需求是什么 | `05_需求文档/`、`05_需求文档/需求文档索引.md` |\n| 某个业务规则是什么 | `05_需求文档/`、`01_业务流程/业务规则索引.md` |\n| 某个业务对象怎么定义 | `01_业务流程/业务对象字典.md`、相关需求文档 |\n| 项目当前到哪个阶段 | `06_里程碑/`、`06_里程碑/里程碑索引.md` |\n| 某阶段要交付什么 | `02_项目管理流程/阶段交付物清单.md` |\n| 技术怎么实现 | `07_技术文档/`、`07_技术文档/技术文档索引.md` |\n| 接口怎么设计 | `07_技术文档/`、具体接口说明文档 |\n| 数据模型怎么设计 | `07_技术文档/`、具体数据模型文档、需求文档 |\n| 测试用例在哪里 | `08_测试相关/`、`08_测试相关/测试用例索引.md` |\n| 缺陷如何记录 | `08_测试相关/缺陷记录模板.md` |\n| 上线前检查什么 | `08_测试相关/上线检查模板.md`、`02_项目管理流程/项目检查清单.md` |\n| Agent 为什么这样回答 | `04_Agent检索/检索说明.md`、`04_Agent检索/来源文件索引.md` |\n\n## 8. 新增文档标准流程\n\n新增文档建议按以下流程操作:\n\n```text\n确定文档类型\n ↓\n放入对应目录\n ↓\n按推荐命名规则命名\n ↓\n补充 Frontmatter\n ↓\n正文写清背景、规则、流程、验收口径\n ↓\n补充 Agent 检索字段\n ↓\n更新对应索引\n ↓\n更新关键词/来源文件索引\n ↓\n在 Obsidian 中检查链接和图谱\n```\n\n## 9. 推荐 Frontmatter\n\n每个正式文档建议在顶部维护 Frontmatter:\n\n```yaml\n---\ntype: requirement\ntags: [需求文档, USER评价业务闭环]\naliases: [数据流与中间对象设计]\nsource: manual\nstatus: active\nowner: 产品经理\nupdated: 2026-05-26\n---\n```\n\n常用字段:\n\n| 字段 | 说明 |\n|---|---|\n| `type` | 文档类型,如 requirement、technical_doc、test_case、milestone |\n| `tags` | 标签,用于 Obsidian 和 Agent 检索 |\n| `aliases` | 别名,便于搜索同义叫法 |\n| `source` | 来源,如 manual、docx、meeting、requirement |\n| `status` | 状态,如 draft、reviewing、active、deprecated |\n| `owner` | 负责人 |\n| `updated` | 最近更新时间 |\n\n## 10. 文档状态说明\n\n| 状态 | 含义 | Agent 使用规则 |\n|---|---|---|\n| `draft` | 草稿 | 只能作为参考,回答时需说明尚未确认 |\n| `reviewing` | 评审中 | 可引用但需说明仍在评审 |\n| `active` | 已确认 | 可作为正式回答依据 |\n| `deprecated` | 已废弃 | 不作为当前规则依据,只能说明历史背景 |\n\n## 11. 索引维护规则\n\n### 11.1 需求索引\n\n新增需求文档后,维护:\n\n```text\n05_需求文档/需求文档索引.md\n```\n\n至少登记:\n\n- 编号\n- 业务域\n- 需求/规则名称\n- 文件路径\n- 状态\n- 负责人\n- 更新时间\n- 验证状态\n\n### 11.2 里程碑索引\n\n新增里程碑后,维护:\n\n```text\n06_里程碑/里程碑索引.md\n```\n\n至少登记:\n\n- 项目\n- 里程碑名称\n- 文件\n- 阶段\n- 负责人\n- 计划时间\n- 当前状态\n\n### 11.3 技术文档索引\n\n新增技术文档后,维护:\n\n```text\n07_技术文档/技术文档索引.md\n```\n\n至少登记:\n\n- 模块/系统\n- 文档类型\n- 文件\n- 关联需求\n- 负责人\n- 更新时间\n- 状态\n\n### 11.4 测试用例索引\n\n新增测试用例后,维护:\n\n```text\n08_测试相关/测试用例索引.md\n```\n\n至少登记:\n\n- 项目\n- 模块\n- 用例名称\n- 文件\n- 关联需求\n- 测试类型\n- 状态\n- 负责人\n\n## 12. Obsidian 链接规则\n\n推荐使用 Obsidian 双链:\n\n```markdown\n[[05_需求文档/需求文档索引]]\n[[07_技术文档/技术文档索引]]\n[[08_测试相关/测试用例索引]]\n```\n\n也可以使用 Markdown 链接:\n\n```markdown\n[需求文档索引](05_需求文档/需求文档索引.md)\n```\n\n优先建议使用双链,方便图谱建立关系。\n\n## 13. Obsidian 图谱说明\n\nObsidian 图谱会显示两类节点:\n\n1. 已存在的 Markdown 文件。\n2. 文档中链接到、但本地还不存在的 Markdown 文件。\n\n如果你只放了一个文件,但图谱出现多个节点,通常是因为该文件引用了其他文档。\n\n示例:\n\n```markdown\n[工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md)\n```\n\n即使这个文件尚未放入目录,Obsidian 也可能在图谱中显示它。这是“未创建链接 / dangling link”,不是目录里真的多了文件。\n\n如果只想显示真实存在的文件,可在图谱中开启:\n\n```text\n图谱视图 → 筛选 → 仅显示已有文件\n```\n\n如果希望知识链路完整,应把被引用的上游文档补充到对应目录。\n\n## 14. 知识地图维护规则\n\n知识地图文件:\n\n```text\n00_首页/知识地图.md\n```\n\n知识地图只维护主入口和关键二级入口,不需要把每个具体项目文档都放进去。\n\n推荐主结构:\n\n```text\n知识地图\n├─ 需求文档\n├─ 里程碑\n├─ 技术文档\n├─ 测试相关\n└─ Agent 检索\n```\n\n新增普通需求、测试用例、技术方案时,一般只维护对应索引,不需要直接改知识地图。\n\n只有新增重要分类或核心入口时,才更新知识地图。\n\n## 15. Agent 回答规则\n\nAgent 基于知识库回答问题时,应遵守:\n\n1. 先查知识库,再回答。\n2. 优先引用 `active` 状态文档。\n3. 先给结论,再展开依据。\n4. 需求问题优先查需求文档。\n5. 技术问题优先查技术文档。\n6. 测试问题优先查测试相关。\n7. 里程碑问题优先查里程碑。\n8. 如果知识库没有明确记录,回答“知识库未明确记录”。\n9. 不要根据经验补充未记录的事实。\n10. 回答末尾必须说明来源文件。\n\n推荐引用格式:\n\n```text\n来源:05_需求文档/xxx.md\n```\n\n## 16. 测试用例管理要求\n\n测试用例应单独存放在:\n\n```text\n08_测试相关/\n```\n\n每个测试用例应尽量包含:\n\n- 用例编号\n- 关联需求\n- 测试模块\n- 前置条件\n- 操作步骤\n- 预期结果\n- 实际结果\n- 优先级\n- 状态\n- 负责人\n\n测试用例必须关联需求文档或业务规则,避免出现无法追溯来源的测试项。\n\n## 17. 文档关系建议\n\n推荐建立以下关系:\n\n```text\n需求文档\n ↓\n里程碑 / 阶段计划\n ↓\n技术文档\n ↓\n测试计划 / 测试用例\n ↓\n缺陷记录 / 验收记录\n ↓\n上线检查 / 复盘回流\n```\n\n每个下游文档应尽量写明上游来源。\n\n示例:\n\n```markdown\n## 关联文档\n\n- 需求来源:[[05_需求文档/xxx需求文档]]\n- 技术方案:[[07_技术文档/xxx技术方案]]\n- 测试用例:[[08_测试相关/xxx测试用例]]\n```\n\n## 18. 不建议放入知识库的内容\n\n不建议直接放入:\n\n- 密码\n- Token\n- API Key\n- 未脱敏客户隐私\n- 未脱敏订单号、电话、邮箱、地址\n- 临时截图\n- 个人草稿\n- 与项目无关的资料\n\n如果必须记录敏感业务规则,应先脱敏再写入知识库。\n\n## 19. 提交前检查清单\n\n新增或修改文档后,检查:\n\n- [ ] 文件放在正确目录。\n- [ ] 文件名能表达业务域和用途。\n- [ ] 正式文档已写 Frontmatter。\n- [ ] 文档状态正确。\n- [ ] 关键业务规则有来源。\n- [ ] 需求文档已更新需求文档索引。\n- [ ] 技术文档已更新技术文档索引。\n- [ ] 测试用例已更新测试用例索引。\n- [ ] 重要关键词已补充到关键词索引。\n- [ ] 需要追溯的来源已补充到来源文件索引。\n- [ ] Obsidian 链接可以正常跳转,或确认是有意保留的上游虚链接。\n- [ ] 不包含密码、Token、密钥和未脱敏敏感信息。\n\n## 20. 常见问题\n\n### 20.1 为什么只放一个文档,图谱显示多个节点?\n\n因为文档中链接了其他 Markdown 文件。Obsidian 会把被链接但尚未创建的文件也显示成节点。\n\n### 20.2 README.md 为什么会出现在图谱里?\n\n因为 README.md 也是 Markdown 文件,Obsidian 会把它作为普通节点显示。\n\n### 20.3 一个具体项目文档要不要加到知识地图?\n\n通常不需要。具体项目文档登记到对应索引即可。知识地图只放主入口和关键二级入口。\n\n### 20.4 需求文档和业务流程怎么区分?\n\n- 尚在新增、变更、评审中的内容放 `05_需求文档/`。\n- 已稳定、可复用的业务流程沉淀到 `01_业务流程/`。\n\n### 20.5 测试用例应该跟需求还是技术文档关联?\n\n优先关联需求文档;如果测试点来自技术实现细节,再补充关联技术文档。\n\n### 20.6 Agent 回答错了怎么办?\n\n优先检查:\n\n1. 对应文档是否存在。\n2. 文档是否放在正确目录。\n3. 索引是否维护。\n4. 关键词或同义词是否缺失。\n5. 来源文件索引是否登记。\n6. 文档状态是否为 `active`。\n\n必要时更新:\n\n- [[04_Agent检索/关键词索引]]\n- [[04_Agent检索/同义词表]]\n- [[04_Agent检索/来源文件索引]]\n- [[04_Agent检索/知识库持续更新与验证流程]]\n\n## 21. 维护原则\n\n1. 文档要放对目录。\n2. 正式内容要有来源。\n3. 关键文档要有索引。\n4. 测试用例要能追溯需求。\n5. 技术文档要能追溯需求或业务流程。\n6. 里程碑要能追溯阶段目标和交付物。\n7. Agent 回答要能追溯来源文件。\n8. 废弃内容要归档,不要混在当前依据中。\n9. 敏感信息要脱敏。\n10. 知识库持续维护比一次性整理更重要。\n",
"wikilinks": [],
"category": "layer-overview"
}
},
{
"id": "flow:layer-overview",
"type": "document",
"name": "1. 知识库入口",
"summary": "知识库使用说明、首页、知识地图和问答入口。先从这里理解知识库结构与检索方式。",
"tags": [
"流程入口",
"知识库入口"
],
"complexity": "simple",
"knowledgeMeta": {
"content": "# 知识库入口\n\n知识库使用说明、首页、知识地图和问答入口。先从这里理解知识库结构与检索方式。\n\n本层包含 5 个文档。点击右侧 Files 或在本层详情中选择具体文档查看内容。",
"wikilinks": [],
"category": "layer-overview"
}
},
{
"id": "flow:layer-requirements",
"type": "document",
"name": "2. 需求文档",
"summary": "所有正式需求、业务规则、需求变更和需求索引。点击本层可查看全部需求文档并检索。",
"tags": [
"流程入口",
"需求文档"
],
"complexity": "simple",
"knowledgeMeta": {
"content": "# 需求文档\n\n所有正式需求、业务规则、需求变更和需求索引。点击本层可查看全部需求文档并检索。\n\n本层包含 32 个文档。点击右侧 Files 或在本层详情中选择具体文档查看内容。",
"wikilinks": [],
"category": "layer-requirements"
}
},
{
"id": "flow:layer-milestones",
"type": "document",
"name": "3. 里程碑",
"summary": "项目阶段计划、里程碑节点、评审记录、准入准出和交付物节奏。",
"tags": [
"流程入口",
"里程碑"
],
"complexity": "simple",
"knowledgeMeta": {
"content": "# 里程碑\n\n项目阶段计划、里程碑节点、评审记录、准入准出和交付物节奏。\n\n本层包含 16 个文档。点击右侧 Files 或在本层详情中选择具体文档查看内容。",
"wikilinks": [],
"category": "layer-milestones"
}
},
{
"id": "flow:layer-technical",
"type": "document",
"name": "4. 技术文档",
"summary": "系统架构、数据模型、接口说明、技术方案和技术决策。点击本层可查看全部技术文档并检索。",
"tags": [
"流程入口",
"技术文档"
],
"complexity": "simple",
"knowledgeMeta": {
"content": "# 技术文档\n\n系统架构、数据模型、接口说明、技术方案和技术决策。点击本层可查看全部技术文档并检索。\n\n本层包含 6 个文档。点击右侧 Files 或在本层详情中选择具体文档查看内容。",
"wikilinks": [],
"category": "layer-technical"
}
},
{
"id": "flow:layer-testing",
"type": "document",
"name": "5. 测试相关",
"summary": "测试计划、测试用例、缺陷记录、验收记录、上线检查和测试资产。点击本层可查看全部测试相关文档并检索。",
"tags": [
"流程入口",
"测试相关"
],
"complexity": "simple",
"knowledgeMeta": {
"content": "# 测试相关\n\n测试计划、测试用例、缺陷记录、验收记录、上线检查和测试资产。点击本层可查看全部测试相关文档并检索。\n\n本层包含 8 个文档。点击右侧 Files 或在本层详情中选择具体文档查看内容。",
"wikilinks": [],
"category": "layer-testing"
}
},
{
"id": "flow:layer-agent",
"type": "document",
"name": "6. Agent检索",
"summary": "检索说明、关键词、同义词、来源索引和持续更新验证流程。",
"tags": [
"流程入口",
"Agent检索"
],
"complexity": "simple",
"knowledgeMeta": {
"content": "# Agent检索\n\n检索说明、关键词、同义词、来源索引和持续更新验证流程。\n\n本层包含 6 个文档。点击右侧 Files 或在本层详情中选择具体文档查看内容。",
"wikilinks": [],
"category": "layer-agent"
}
},
{
"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 |\n",
"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 |\n",
"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 |\n",
"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 |\n",
"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 |\n",
"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 |\n",
"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 |\n",
"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