docs: update WishFulfilled knowledge base
This commit is contained in:
qiaoxinjiu
@@ -1,9 +1,9 @@
|
||||
import fs from 'node:fs';
|
||||
import path from 'node:path';
|
||||
import { execFileSync } from 'node:child_process';
|
||||
|
||||
const root = 'D:/AIcoding/WishFulfilled/知识库/under-anything';
|
||||
const wiki = `${root}/wishfulfilled-wiki`;
|
||||
const reqDir = `${wiki}/05_需求文档`;
|
||||
const graphPaths = [
|
||||
`${wiki}/.understand-anything/knowledge-graph.json`,
|
||||
`${root}/wishfulfilled-dashboard/knowledge-graph.json`,
|
||||
@@ -13,14 +13,73 @@ const metaPaths = [
|
||||
`${root}/wishfulfilled-dashboard/meta.json`,
|
||||
];
|
||||
|
||||
const files = fs.readdirSync(reqDir)
|
||||
.filter((name) => /\.(md|html?)$/i.test(name))
|
||||
const directoryConfigs = [
|
||||
{
|
||||
dir: `${wiki}/05_需求文档`,
|
||||
relDir: '05_需求文档',
|
||||
layerId: 'layer-requirements',
|
||||
flowId: 'flow:layer-requirements',
|
||||
layerName: '需求文档',
|
||||
layerDescription: '所有正式需求、业务规则、需求变更和需求索引。点击本层可查看全部需求文档并检索。',
|
||||
defaultTags: ['05_需求文档', '需求文档'],
|
||||
category: 'layer-requirements',
|
||||
fallbackSummary: '需求文档。',
|
||||
},
|
||||
{
|
||||
dir: `${wiki}/07_技术文档`,
|
||||
relDir: '07_技术文档',
|
||||
layerId: 'layer-technical',
|
||||
flowId: 'flow:layer-technical',
|
||||
layerName: '技术文档',
|
||||
layerDescription: '系统架构、数据模型、接口说明、技术方案和技术决策。点击本层可查看全部技术文档并检索。',
|
||||
defaultTags: ['07_技术文档', '技术文档'],
|
||||
category: 'layer-technical',
|
||||
fallbackSummary: '技术文档。',
|
||||
},
|
||||
{
|
||||
dir: `${wiki}/08_测试相关`,
|
||||
relDir: '08_测试相关',
|
||||
layerId: 'layer-testing',
|
||||
flowId: 'flow:layer-testing',
|
||||
layerName: '测试相关',
|
||||
layerDescription: '测试计划、测试用例、缺陷记录、验收记录、上线检查和测试资产。点击本层可查看全部测试相关文档并检索。',
|
||||
defaultTags: ['08_测试相关', '测试相关'],
|
||||
category: 'layer-testing',
|
||||
fallbackSummary: '测试相关文档。',
|
||||
},
|
||||
];
|
||||
|
||||
function listFiles(dir) {
|
||||
if (!fs.existsSync(dir)) return [];
|
||||
return fs.readdirSync(dir)
|
||||
.filter((name) => /\.(md|html?|xlsx)$/i.test(name))
|
||||
.sort((a, b) => a.localeCompare(b, 'zh-Hans-CN'));
|
||||
}
|
||||
|
||||
function readText(filePath) {
|
||||
if (/\.xlsx$/i.test(filePath)) return readXlsxText(filePath);
|
||||
return fs.readFileSync(filePath, 'utf8');
|
||||
}
|
||||
|
||||
function readXlsxText(filePath) {
|
||||
const script = [
|
||||
'import json, sys',
|
||||
'from openpyxl import load_workbook',
|
||||
'path = sys.argv[1]',
|
||||
'wb = load_workbook(path, data_only=True, read_only=True)',
|
||||
'out = []',
|
||||
'for ws in wb.worksheets:',
|
||||
' out.append(f"# Sheet: {ws.title}")',
|
||||
' for row in ws.iter_rows(values_only=True):',
|
||||
' vals = [str(v).strip() for v in row if v is not None and str(v).strip()]',
|
||||
' if vals:',
|
||||
' out.append(" | ".join(vals))',
|
||||
'print(json.dumps("\\n".join(out), ensure_ascii=False))',
|
||||
].join('\n');
|
||||
const stdout = execFileSync('python', ['-c', script, filePath], { encoding: 'utf8', maxBuffer: 50 * 1024 * 1024 });
|
||||
return JSON.parse(stdout);
|
||||
}
|
||||
|
||||
function cleanLineNumbers(text) {
|
||||
const lines = text.split(/\r?\n/);
|
||||
let changed = 0;
|
||||
@@ -56,15 +115,15 @@ function titleFor(fileName, text) {
|
||||
return path.basename(fileName, path.extname(fileName)).replace(/^\d+[-_]/, '').replace(/_/g, ' ');
|
||||
}
|
||||
|
||||
function summaryFor(fileName, text) {
|
||||
function summaryFor(fileName, text, fallbackSummary) {
|
||||
const plain = /\.html?$/i.test(fileName)
|
||||
? stripHtml(text)
|
||||
: text.replace(/[`*_>#|\-\[\]()]/g, ' ').replace(/\s+/g, ' ').trim();
|
||||
return plain ? plain.slice(0, 180) : '需求文档。';
|
||||
return plain ? plain.slice(0, 180) : fallbackSummary;
|
||||
}
|
||||
|
||||
function tagsFor(text) {
|
||||
const tags = ['05_需求文档', '需求文档'];
|
||||
function tagsFor(text, defaultTags) {
|
||||
const tags = [...defaultTags];
|
||||
const match = text.match(/^tags:\s*\[(.*?)\]/m);
|
||||
if (!match) return tags;
|
||||
for (const item of match[1].split(/[,，]/)) {
|
||||
@@ -80,6 +139,36 @@ function complexityFor(text) {
|
||||
return 'simple';
|
||||
}
|
||||
|
||||
function ensureLayer(graph, config) {
|
||||
let layer = graph.layers.find((item) => item.id === config.layerId);
|
||||
if (!layer) {
|
||||
layer = {
|
||||
id: config.layerId,
|
||||
name: config.layerName,
|
||||
description: config.layerDescription,
|
||||
nodeIds: [config.flowId],
|
||||
};
|
||||
graph.layers.push(layer);
|
||||
}
|
||||
layer.name = config.layerName;
|
||||
layer.description = config.layerDescription;
|
||||
layer.nodeIds ??= [];
|
||||
if (!layer.nodeIds.includes(config.flowId)) layer.nodeIds.unshift(config.flowId);
|
||||
return layer;
|
||||
}
|
||||
|
||||
function updateFlowNode(byId, layer, config) {
|
||||
const count = layer.nodeIds.filter((id) => id !== config.flowId).length;
|
||||
const flow = byId.get(config.flowId);
|
||||
if (flow) {
|
||||
flow.summary = config.layerDescription;
|
||||
flow.knowledgeMeta ??= {};
|
||||
flow.knowledgeMeta.content = `# ${config.layerName}\n\n${config.layerDescription}\n\n本层包含 ${count} 个文档。点击右侧 Files 或在本层详情中选择具体文档查看内容。`;
|
||||
flow.knowledgeMeta.category = config.category;
|
||||
}
|
||||
return count;
|
||||
}
|
||||
|
||||
function updateGraph(graphPath) {
|
||||
const graph = JSON.parse(fs.readFileSync(graphPath, 'utf8'));
|
||||
graph.nodes ??= [];
|
||||
@@ -88,23 +177,17 @@ function updateGraph(graphPath) {
|
||||
|
||||
const byId = new Map(graph.nodes.map((node) => [node.id, node]));
|
||||
const edgeKeys = new Set(graph.edges.map((edge) => `${edge.source}|${edge.target}|${edge.type}`));
|
||||
let layer = graph.layers.find((item) => item.id === 'layer-requirements');
|
||||
if (!layer) {
|
||||
layer = {
|
||||
id: 'layer-requirements',
|
||||
name: '需求文档',
|
||||
description: '所有正式需求、业务规则、需求变更和需求索引。',
|
||||
nodeIds: ['flow:layer-requirements'],
|
||||
};
|
||||
graph.layers.push(layer);
|
||||
}
|
||||
layer.nodeIds ??= [];
|
||||
const stats = [];
|
||||
|
||||
for (const config of directoryConfigs) {
|
||||
const files = listFiles(config.dir);
|
||||
const layer = ensureLayer(graph, config);
|
||||
let added = 0;
|
||||
let updated = 0;
|
||||
|
||||
for (const fileName of files) {
|
||||
const absolutePath = `${reqDir}/${fileName}`;
|
||||
const relPath = `05_需求文档/${fileName}`;
|
||||
const absolutePath = `${config.dir}/${fileName}`;
|
||||
const relPath = `${config.relDir}/${fileName}`;
|
||||
const nodeId = `doc:${relPath.replace(/\.[^.]+$/, '')}`;
|
||||
const text = cleanLineNumbers(readText(absolutePath));
|
||||
const node = {
|
||||
@@ -112,13 +195,13 @@ function updateGraph(graphPath) {
|
||||
type: 'document',
|
||||
name: titleFor(fileName, text),
|
||||
filePath: relPath,
|
||||
summary: summaryFor(fileName, text),
|
||||
tags: tagsFor(text),
|
||||
summary: summaryFor(fileName, text, config.fallbackSummary),
|
||||
tags: tagsFor(text, config.defaultTags),
|
||||
complexity: complexityFor(text),
|
||||
knowledgeMeta: {
|
||||
content: text,
|
||||
wikilinks: [...text.matchAll(/\[\[([^\]]+)\]\]/g)].map((match) => match[1]),
|
||||
category: 'layer-requirements',
|
||||
category: config.category,
|
||||
},
|
||||
};
|
||||
|
||||
@@ -132,10 +215,10 @@ function updateGraph(graphPath) {
|
||||
}
|
||||
|
||||
if (!layer.nodeIds.includes(nodeId)) layer.nodeIds.push(nodeId);
|
||||
const edgeKey = `flow:layer-requirements|${nodeId}|documents`;
|
||||
const edgeKey = `${config.flowId}|${nodeId}|documents`;
|
||||
if (!edgeKeys.has(edgeKey)) {
|
||||
graph.edges.push({
|
||||
source: 'flow:layer-requirements',
|
||||
source: config.flowId,
|
||||
target: nodeId,
|
||||
type: 'documents',
|
||||
direction: 'forward',
|
||||
@@ -146,19 +229,13 @@ function updateGraph(graphPath) {
|
||||
}
|
||||
}
|
||||
|
||||
const count = layer.nodeIds.filter((id) => id !== 'flow:layer-requirements').length;
|
||||
const flow = byId.get('flow:layer-requirements');
|
||||
if (flow) {
|
||||
flow.summary = '所有正式需求、业务规则、需求变更和需求索引。点击本层可查看全部需求文档并检索。';
|
||||
flow.knowledgeMeta ??= {};
|
||||
flow.knowledgeMeta.content = `# 需求文档\n\n所有正式需求、业务规则、需求变更和需求索引。点击本层可查看全部需求文档并检索。\n\n本层包含 ${count} 个文档。点击右侧 Files 或在本层详情中选择具体文档查看内容。`;
|
||||
flow.knowledgeMeta.category = 'layer-requirements';
|
||||
stats.push({ layer: config.layerName, added, updated, count: updateFlowNode(byId, layer, config) });
|
||||
}
|
||||
|
||||
graph.project ??= {};
|
||||
graph.project.analyzedAt = new Date().toISOString();
|
||||
fs.writeFileSync(graphPath, `${JSON.stringify(graph, null, 2)}\n`, 'utf8');
|
||||
return { graphPath, added, updated, requirements: count, nodes: graph.nodes.length };
|
||||
return { graphPath, stats, nodes: graph.nodes.length };
|
||||
}
|
||||
|
||||
const results = graphPaths.map(updateGraph);
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
import { useEffect, useMemo, useState } from "react";
|
||||
import { Highlight, themes } from "prism-react-renderer";
|
||||
import ReactMarkdown from "react-markdown";
|
||||
import { useDashboardStore } from "../store";
|
||||
import { useI18n } from "../contexts/I18nContext";
|
||||
|
||||
@@ -76,6 +77,11 @@ function formatBytes(bytes: number): string {
|
||||
return `${(bytes / (1024 * 1024)).toFixed(1)} MB`;
|
||||
}
|
||||
|
||||
function isMarkdownSource(source: SourceFile | null, language: string): boolean {
|
||||
if (!source) return false;
|
||||
return language === "markdown" || /\.md$/i.test(source.path);
|
||||
}
|
||||
|
||||
export default function CodeViewer({
|
||||
accessToken,
|
||||
presentation = "sidebar",
|
||||
@@ -165,6 +171,7 @@ export default function CodeViewer({
|
||||
|
||||
const source = state.source;
|
||||
const language = source?.language ?? fallbackLanguage(node.filePath);
|
||||
const shouldRenderMarkdown = isMarkdownSource(source, language);
|
||||
const lineInfo = highlightedRange
|
||||
? `${t.codeViewer.lines} ${highlightedRange.start}-${highlightedRange.end}`
|
||||
: t.codeViewer.fullFile;
|
||||
@@ -245,6 +252,11 @@ export default function CodeViewer({
|
||||
<span>{source.lineCount} {t.codeViewer.linesLabel}</span>
|
||||
<span>{formatBytes(source.sizeBytes)}</span>
|
||||
</div>
|
||||
{shouldRenderMarkdown ? (
|
||||
<article className={`markdown-reader ${isModal ? "markdown-reader-modal" : ""}`}>
|
||||
<ReactMarkdown>{source.content}</ReactMarkdown>
|
||||
</article>
|
||||
) : (
|
||||
<Highlight code={source.content} language={language} theme={themes.vsDark}>
|
||||
{({ className, style, tokens, getLineProps, getTokenProps }) => (
|
||||
<pre
|
||||
@@ -282,6 +294,7 @@ export default function CodeViewer({
|
||||
</pre>
|
||||
)}
|
||||
</Highlight>
|
||||
)}
|
||||
</>
|
||||
)}
|
||||
</div>
|
||||
|
||||
@@ -218,6 +218,190 @@ body {
|
||||
overflow: hidden;
|
||||
}
|
||||
|
||||
/* Markdown document reader */
|
||||
.markdown-reader {
|
||||
width: min(100%, 980px);
|
||||
margin: 0 auto;
|
||||
padding: 32px 40px 56px;
|
||||
color: var(--color-text-primary);
|
||||
font-family: var(--font-sans);
|
||||
font-size: 15px;
|
||||
line-height: 1.85;
|
||||
letter-spacing: 0.01em;
|
||||
}
|
||||
|
||||
.markdown-reader-modal {
|
||||
width: min(100%, 1040px);
|
||||
padding: 40px 56px 72px;
|
||||
font-size: 16px;
|
||||
}
|
||||
|
||||
.markdown-reader h1,
|
||||
.markdown-reader h2,
|
||||
.markdown-reader h3,
|
||||
.markdown-reader h4,
|
||||
.markdown-reader h5,
|
||||
.markdown-reader h6 {
|
||||
color: var(--color-text-primary);
|
||||
font-family: var(--font-sans);
|
||||
font-weight: 750;
|
||||
line-height: 1.32;
|
||||
letter-spacing: -0.01em;
|
||||
scroll-margin-top: 24px;
|
||||
}
|
||||
|
||||
.markdown-reader h1 {
|
||||
margin: 0 0 24px;
|
||||
padding-bottom: 16px;
|
||||
border-bottom: 1px solid var(--color-border-medium);
|
||||
font-size: 2rem;
|
||||
}
|
||||
|
||||
.markdown-reader h2 {
|
||||
margin: 42px 0 18px;
|
||||
padding-left: 14px;
|
||||
border-left: 3px solid var(--color-accent);
|
||||
font-size: 1.5rem;
|
||||
}
|
||||
|
||||
.markdown-reader h3 {
|
||||
margin: 32px 0 14px;
|
||||
color: var(--color-accent-bright);
|
||||
font-size: 1.18rem;
|
||||
}
|
||||
|
||||
.markdown-reader h4,
|
||||
.markdown-reader h5,
|
||||
.markdown-reader h6 {
|
||||
margin: 24px 0 10px;
|
||||
color: var(--color-text-secondary);
|
||||
font-size: 1rem;
|
||||
}
|
||||
|
||||
.markdown-reader p,
|
||||
.markdown-reader ul,
|
||||
.markdown-reader ol,
|
||||
.markdown-reader blockquote,
|
||||
.markdown-reader table,
|
||||
.markdown-reader pre {
|
||||
margin: 0 0 18px;
|
||||
}
|
||||
|
||||
.markdown-reader p {
|
||||
color: var(--color-text-secondary);
|
||||
}
|
||||
|
||||
.markdown-reader strong {
|
||||
color: var(--color-text-primary);
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
.markdown-reader a {
|
||||
color: var(--color-node-document);
|
||||
text-decoration: none;
|
||||
border-bottom: 1px solid color-mix(in srgb, var(--color-node-document) 45%, transparent);
|
||||
}
|
||||
|
||||
.markdown-reader ul,
|
||||
.markdown-reader ol {
|
||||
padding-left: 1.5rem;
|
||||
color: var(--color-text-secondary);
|
||||
}
|
||||
|
||||
.markdown-reader li {
|
||||
margin: 7px 0;
|
||||
padding-left: 4px;
|
||||
}
|
||||
|
||||
.markdown-reader li::marker {
|
||||
color: var(--color-accent);
|
||||
}
|
||||
|
||||
.markdown-reader blockquote {
|
||||
border-left: 3px solid var(--color-border-medium);
|
||||
background: color-mix(in srgb, var(--color-accent) 7%, transparent);
|
||||
padding: 14px 18px;
|
||||
border-radius: 0 10px 10px 0;
|
||||
color: var(--color-text-secondary);
|
||||
}
|
||||
|
||||
.markdown-reader code {
|
||||
color: var(--color-accent-bright);
|
||||
background: color-mix(in srgb, var(--color-accent) 12%, transparent);
|
||||
border: 1px solid var(--color-border-subtle);
|
||||
border-radius: 5px;
|
||||
padding: 0.12em 0.36em;
|
||||
font-family: var(--font-mono);
|
||||
font-size: 0.9em;
|
||||
}
|
||||
|
||||
.markdown-reader pre {
|
||||
overflow: auto;
|
||||
border: 1px solid var(--color-border-subtle);
|
||||
border-radius: 12px;
|
||||
background: color-mix(in srgb, var(--color-root) 82%, var(--color-elevated));
|
||||
padding: 18px 20px;
|
||||
line-height: 1.65;
|
||||
}
|
||||
|
||||
.markdown-reader pre code {
|
||||
display: block;
|
||||
padding: 0;
|
||||
border: 0;
|
||||
background: transparent;
|
||||
color: var(--color-text-primary);
|
||||
font-size: 0.88em;
|
||||
white-space: pre;
|
||||
}
|
||||
|
||||
.markdown-reader hr {
|
||||
margin: 34px 0;
|
||||
border: 0;
|
||||
border-top: 1px solid var(--color-border-subtle);
|
||||
}
|
||||
|
||||
.markdown-reader table {
|
||||
display: block;
|
||||
width: 100%;
|
||||
overflow: auto;
|
||||
border-collapse: collapse;
|
||||
border: 1px solid var(--color-border-subtle);
|
||||
border-radius: 10px;
|
||||
}
|
||||
|
||||
.markdown-reader th,
|
||||
.markdown-reader td {
|
||||
border: 1px solid var(--color-border-subtle);
|
||||
padding: 10px 12px;
|
||||
vertical-align: top;
|
||||
}
|
||||
|
||||
.markdown-reader th {
|
||||
background: color-mix(in srgb, var(--color-accent) 11%, transparent);
|
||||
color: var(--color-text-primary);
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
.markdown-reader td {
|
||||
color: var(--color-text-secondary);
|
||||
}
|
||||
|
||||
@media (max-width: 768px) {
|
||||
.markdown-reader,
|
||||
.markdown-reader-modal {
|
||||
padding: 24px 20px 44px;
|
||||
font-size: 15px;
|
||||
}
|
||||
|
||||
.markdown-reader h1 {
|
||||
font-size: 1.6rem;
|
||||
}
|
||||
|
||||
.markdown-reader h2 {
|
||||
font-size: 1.28rem;
|
||||
}
|
||||
}
|
||||
|
||||
/* Hide scrollbar but keep scroll functionality */
|
||||
.scrollbar-hide {
|
||||
-ms-overflow-style: none;
|
||||
|
||||
14
wishfulfilled-dashboard/assets/CodeViewer-Boblkcge.js
Normal file
14
wishfulfilled-dashboard/assets/CodeViewer-Boblkcge.js
Normal file
File diff suppressed because one or more lines are too long
@@ -0,0 +1 @@
|
||||
import{j as e}from"./react-vendor-BVoutfaX.js";import{a as d,f as x}from"./index-C3mrB48A.js";import"./xyflow-CYMCcsWN.js";import"./graph-layout-7tFr_anw.js";import"./elk-CXeXGyKz.js";import"./graphology-BgTy_cc3.js";function j({shortcuts:i,onClose:o}){const{t:s}=d(),n=i.reduce((t,r)=>(t[r.category]||(t[r.category]=[]),t[r.category].push(r),t),{}),l={General:s.keyboardShortcuts.general,Navigation:s.keyboardShortcuts.navigation,Tour:s.keyboardShortcuts.tour,View:s.keyboardShortcuts.view};return e.jsx("div",{className:"fixed inset-0 bg-black/50 backdrop-blur-sm flex items-center justify-center z-50",onClick:o,children:e.jsxs("div",{className:"glass rounded-lg shadow-2xl max-w-2xl w-full max-h-[80vh] overflow-auto m-4",onClick:t=>t.stopPropagation(),children:[e.jsxs("div",{className:"sticky top-0 glass-heavy border-b border-border-subtle px-6 py-4 flex items-center justify-between",children:[e.jsxs("div",{children:[e.jsx("h2",{className:"text-xl font-heading text-text-primary",children:s.keyboardShortcuts.title}),e.jsx("p",{className:"text-xs text-text-muted mt-1",children:s.keyboardShortcuts.toggleHint})]}),e.jsx("button",{onClick:o,className:"text-text-muted hover:text-text-primary transition-colors",children:e.jsx("svg",{className:"w-5 h-5",fill:"none",stroke:"currentColor",viewBox:"0 0 24 24",children:e.jsx("path",{strokeLinecap:"round",strokeLinejoin:"round",strokeWidth:2,d:"M6 18L18 6M6 6l12 12"})})})]}),e.jsx("div",{className:"p-6 space-y-6",children:Object.entries(n).map(([t,r])=>e.jsxs("div",{children:[e.jsx("h3",{className:"text-sm font-semibold text-accent uppercase tracking-wider mb-3",children:l[t]??t}),e.jsx("div",{className:"space-y-2",children:r.map((a,c)=>e.jsxs("div",{className:"flex items-center justify-between py-2 px-3 rounded hover:bg-elevated transition-colors",children:[e.jsx("span",{className:"text-sm text-text-secondary",children:a.description}),e.jsx("kbd",{className:"kbd",children:x(a)})]},c))})]},t))}),e.jsx("div",{className:"sticky bottom-0 glass-heavy border-t border-border-subtle px-6 py-3 text-center",children:e.jsx("p",{className:"text-xs text-text-muted",children:s.keyboardShortcuts.closeHint})})]})})}export{j as default};
|
||||
1
wishfulfilled-dashboard/assets/LearnPanel-DahajoWG.js
Normal file
1
wishfulfilled-dashboard/assets/LearnPanel-DahajoWG.js
Normal file
File diff suppressed because one or more lines are too long
@@ -0,0 +1 @@
|
||||
import{a as d,j as t}from"./react-vendor-BVoutfaX.js";import{a as b}from"./index-C3mrB48A.js";import"./xyflow-CYMCcsWN.js";import"./graph-layout-7tFr_anw.js";import"./elk-CXeXGyKz.js";import"./graphology-BgTy_cc3.js";const p="ua-onboarding-title";function P({onDismiss:a}){const{t:o}=b(),i=o.onboarding.steps,[e,s]=d.useState(0);d.useEffect(()=>{const r=n=>{n.key==="Escape"&&(n.stopPropagation(),a(!1))};return document.addEventListener("keydown",r,!0),()=>document.removeEventListener("keydown",r,!0)},[a]);const m=e===0,x=e===i.length-1,l=i[e];return t.jsxs("div",{style:h,onClick:r=>{r.target===r.currentTarget&&a(!1)},children:[t.jsx("style",{children:u}),t.jsxs("div",{role:"dialog","aria-modal":"true","aria-labelledby":p,style:f,children:[t.jsxs("div",{style:v,children:[t.jsxs("span",{style:S,children:["0",e+1]}),t.jsxs("span",{children:[" / 0",i.length]}),t.jsx("span",{style:j}),t.jsx("span",{children:o.onboarding.header})]}),t.jsx("h2",{id:p,style:k,children:l.title}),t.jsx("p",{style:z,children:l.body}),l.hint&&t.jsxs("blockquote",{style:E,children:[t.jsx("span",{style:{color:"var(--color-accent)",marginRight:8},children:"·"}),l.hint]}),t.jsx("div",{style:I,children:i.map((r,n)=>t.jsx("div",{style:{...T,background:n===e?"var(--color-accent)":"var(--color-border-medium)",width:n===e?28:6}},n))}),t.jsxs("div",{style:w,children:[t.jsx("button",{type:"button",onClick:()=>a(!0),style:{...c,...y},children:o.onboarding.skipForever}),t.jsx("div",{style:{flex:1}}),!m&&t.jsx("button",{type:"button",onClick:()=>s(e-1),style:{...c,...y},children:o.onboarding.prev}),x?t.jsx("button",{type:"button",onClick:()=>a(!0),style:{...c,...g},children:o.onboarding.finish}):t.jsx("button",{type:"button",onClick:()=>s(e+1),style:{...c,...g},children:o.onboarding.next})]})]})]})}const u="@keyframes ua-fade-in { from { opacity: 0 } to { opacity: 1 } }",h={position:"fixed",inset:0,background:"rgba(0, 0, 0, 0.78)",backdropFilter:"blur(6px)",zIndex:9999,display:"flex",alignItems:"center",justifyContent:"center",padding:16,fontFamily:"var(--font-sans)",animation:"ua-fade-in 0.4s cubic-bezier(0.22, 1, 0.36, 1)"},f={background:"var(--color-elevated)",color:"var(--color-text-primary)",maxWidth:580,width:"100%",padding:"48px 48px 36px",border:"1px solid var(--color-border-subtle)",borderTop:"2px solid var(--color-accent)",position:"relative"},v={fontSize:"0.72rem",letterSpacing:"0.3em",color:"var(--color-text-muted)",textTransform:"uppercase",marginBottom:24,display:"flex",alignItems:"center",flexWrap:"wrap",gap:4},S={fontFamily:"var(--font-heading)",color:"var(--color-accent)",fontSize:"0.9rem",letterSpacing:"0.1em",marginRight:4},j={width:4,height:4,background:"var(--color-accent)",borderRadius:"50%",margin:"0 12px"},k={fontFamily:"var(--font-heading)",fontSize:"1.7rem",fontWeight:400,letterSpacing:"0.02em",lineHeight:1.3,marginBottom:16,color:"var(--color-text-primary)"},z={fontSize:"0.98rem",lineHeight:1.7,color:"var(--color-text-secondary)",marginBottom:0},E={margin:"20px 0 0",padding:"12px 18px",borderLeft:"2px solid var(--color-border-medium)",background:"var(--color-accent-overlay-bg)",fontSize:"0.86rem",color:"var(--color-accent)",fontStyle:"italic"},I={display:"flex",gap:6,marginTop:36,marginBottom:28},T={height:4,borderRadius:2,transition:"width 0.5s cubic-bezier(0.22, 1, 0.36, 1), background 0.3s"},w={display:"flex",alignItems:"center",gap:10},c={padding:"10px 22px",fontSize:"0.82rem",letterSpacing:"0.12em",textTransform:"uppercase",border:"1px solid",cursor:"pointer",fontFamily:"inherit",transition:"all 0.3s cubic-bezier(0.22, 1, 0.36, 1)",fontWeight:400},y={background:"transparent",borderColor:"var(--color-border-medium)",color:"var(--color-text-muted)"},g={background:"var(--color-accent)",borderColor:"var(--color-accent)",color:"var(--color-root)",fontWeight:500};export{P as default};
|
||||
File diff suppressed because one or more lines are too long
4
wishfulfilled-dashboard/assets/RagAssistant-BEmyfNge.js
Normal file
4
wishfulfilled-dashboard/assets/RagAssistant-BEmyfNge.js
Normal file
File diff suppressed because one or more lines are too long
42
wishfulfilled-dashboard/assets/index-C3mrB48A.js
Normal file
42
wishfulfilled-dashboard/assets/index-C3mrB48A.js
Normal file
File diff suppressed because one or more lines are too long
1
wishfulfilled-dashboard/assets/index-L1cEqadP.css
Normal file
1
wishfulfilled-dashboard/assets/index-L1cEqadP.css
Normal file
File diff suppressed because one or more lines are too long
@@ -11,14 +11,14 @@
|
||||
href="https://fonts.googleapis.com/css2?family=DM+Serif+Display&family=Inter:wght@300;400;500;600&family=JetBrains+Mono:wght@400;500&display=swap"
|
||||
rel="stylesheet"
|
||||
/>
|
||||
<script type="module" crossorigin src="/assets/index-DLs0sBAY.js"></script>
|
||||
<script type="module" crossorigin src="/assets/index-C3mrB48A.js"></script>
|
||||
<link rel="modulepreload" crossorigin href="/assets/react-vendor-BVoutfaX.js">
|
||||
<link rel="modulepreload" crossorigin href="/assets/xyflow-CYMCcsWN.js">
|
||||
<link rel="modulepreload" crossorigin href="/assets/graph-layout-7tFr_anw.js">
|
||||
<link rel="modulepreload" crossorigin href="/assets/elk-CXeXGyKz.js">
|
||||
<link rel="modulepreload" crossorigin href="/assets/graphology-BgTy_cc3.js">
|
||||
<link rel="stylesheet" crossorigin href="/assets/xyflow-BZV40eAE.css">
|
||||
<link rel="stylesheet" crossorigin href="/assets/index-tPU2SFKT.css">
|
||||
<link rel="stylesheet" crossorigin href="/assets/index-L1cEqadP.css">
|
||||
</head>
|
||||
<body>
|
||||
<div id="root"></div>
|
||||
|
||||
File diff suppressed because one or more lines are too long
@@ -1,8 +1,8 @@
|
||||
{
|
||||
"lastAnalyzedAt": "2026-05-27T07:14:45.072Z",
|
||||
"lastAnalyzedAt": "2026-05-29T06:03:33.594Z",
|
||||
"gitCommitHash": "",
|
||||
"version": "1.0.0",
|
||||
"analyzedFiles": 60,
|
||||
"analyzedFiles": 73,
|
||||
"theme": {
|
||||
"presetId": "dark",
|
||||
"accentId": "cyan"
|
||||
|
||||
File diff suppressed because one or more lines are too long
@@ -1,8 +1,8 @@
|
||||
{
|
||||
"lastAnalyzedAt": "2026-05-27T07:14:45.036Z",
|
||||
"lastAnalyzedAt": "2026-05-29T06:03:33.528Z",
|
||||
"gitCommitHash": "",
|
||||
"version": "1.0.0",
|
||||
"analyzedFiles": 60,
|
||||
"analyzedFiles": 73,
|
||||
"theme": {
|
||||
"presetId": "dark",
|
||||
"accentId": "cyan"
|
||||
|
||||
@@ -0,0 +1,261 @@
|
||||
# USER ERP 0-1需求重构 - 01 主流程说明 v1
|
||||
|
||||
## 文件信息
|
||||
|
||||
- 文件名称：`20260527_USER_ERP_0-1需求重构_01_主流程说明_v1.md`
|
||||
- 项目路径：`C:\XCODE\USER`
|
||||
- 输出位置：`C:\XCODE\USER\output\docs`
|
||||
- 当前版本：`v1`
|
||||
- 最近更新：`2026-05-27`
|
||||
- 所属阶段：Stage 1 完整业务需求
|
||||
- 负责人：业务负责人
|
||||
- 核心参与：USER运营、客服、渠道运营、KOC/KOL运营、财务、风险、产品、前端观察员
|
||||
- 文件目的：把 USER ERP 的完整业务主流程从需求进入写到结果复盘，避免后续只围绕单页或单模块开发。
|
||||
|
||||
## 主流程总览
|
||||
|
||||
USER ERP 的主流程不是从推送开始，也不是从测评单开始，而是从“需求能否变成可执行计划”开始。
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
A["需求进入"] --> B["需求评估"]
|
||||
B --> C["产品/ASIN/库存/评分校验"]
|
||||
C --> D["生成或调整计划"]
|
||||
D --> E["执行资源匹配"]
|
||||
E --> F["渠道任务/客服任务/KOC-KOL任务生成"]
|
||||
F --> G["用户或达人响应"]
|
||||
G --> H["客服承接与信息补全"]
|
||||
H --> I["订单/评价/内容/返款/佣金履约"]
|
||||
I --> J["风险复检与异常处理"]
|
||||
J --> K["结果回流到计划与需求"]
|
||||
K --> L["复盘、关闭或二次计划"]
|
||||
```
|
||||
|
||||
## 主流程核心原则
|
||||
|
||||
1. 需求完整性优先于 V1 实现边界。
|
||||
2. 每个需求必须能追到执行计划、执行对象、执行结果和复盘结论。
|
||||
3. 测评、回评、免评、KOC/KOL任务共用真实人、风险、额度、订单、客服上下文。
|
||||
4. 客服既是承接用户问题的执行团队，也是评价转化、订单登记、催评和异常闭环的核心执行资源。
|
||||
5. KOC/KOL不是纯外部接口，而是完整需求域：线索、分层、任务、内容、带货、佣金、风险都要在阶段1被定义。
|
||||
6. 每次有效互动都要复检身份、额度、风险、订单和未关闭承诺。
|
||||
7. 用户提交评价与 Amazon 展示确认必须拆开；计划完成口径不能混用。
|
||||
|
||||
## 业务对象
|
||||
|
||||
| 对象 | 含义 | 阶段 |
|
||||
| --- | --- | --- |
|
||||
| 需求 | OA/销售/运营/异常触发/KOC-KOL合作请求 | V1必做 |
|
||||
| 计划 | 测评、回评、免评、KOC/KOL任务、客服跟进计划 | V1必做 |
|
||||
| 执行资源 | 渠道、人群、客服、测评人、KOC/KOL、H5/卡片、返款能力 | V1必做 |
|
||||
| 真实人 | 跨账号、邮箱、电话、Profile、设备归并后的核心身份 | V1必做 |
|
||||
| 测评人 | 可参与测评/回评/免评的运营对象，是真实人的业务视图 | V1必做 |
|
||||
| KOC/KOL | 创作者/带货/内容合作对象，可与测评人身份重叠 | V1预留 |
|
||||
| 订单 | Amazon订单、测评订单、回评订单、免评订单、样品/带货订单 | V1必做 |
|
||||
| 评价 | 用户提交、评论链接/截图、Amazon展示确认、掉评/差评 | V1必做 |
|
||||
| 返款/佣金 | 用户返款、礼品卡、财务返款、KOC/KOL佣金 | 用户返款V1必做，佣金V1预留 |
|
||||
| 工单 | 客服消息、售后问题、催评、答应配合、异常跟进 | V1必做 |
|
||||
| 风险事件 | 黑名单、重复退款、额度超限、异常账号、内容/佣金风险 | V1必做 |
|
||||
| 复盘记录 | 需求关闭、计划表现、渠道表现、客服表现、KOC/KOL表现 | V1预留 |
|
||||
|
||||
## 主流程分解
|
||||
|
||||
### 1. 需求进入
|
||||
|
||||
| 内容 | 说明 |
|
||||
| --- | --- |
|
||||
| 触发来源 | OA测评计划、销售/运营手动需求、ASIN评分异常、掉评/差评、库存/Listing状态变化、KOC/KOL合作需求、客服反馈 |
|
||||
| 必填信息 | 需求编号、需求类型、产品/ASIN、站点、店铺、目标、优先级、截止时间、需求人、负责人 |
|
||||
| 可选信息 | 关键词、关键词链接、目标受众、目标Review数、预算/追加金额、指定渠道、指定KOC/KOL |
|
||||
| 输出 | 进入需求池，状态为待评估 |
|
||||
| 阶段 | V1必做 |
|
||||
|
||||
### 2. 需求评估
|
||||
|
||||
运营需要判断：
|
||||
|
||||
- 需求是测评、回评、免评、KOC/KOL任务、客服跟进，还是混合需求。
|
||||
- ASIN当前评分、Review数、差评、掉评、库存、Listing状态是否支持执行。
|
||||
- 需求目标是否超过可用人群、额度、渠道和客服容量。
|
||||
- 是否存在产品禁用、店铺异常、关键词失效、H5/卡片缺失。
|
||||
- 是否需要审批、拆分计划、延迟、驳回或转其他计划类型。
|
||||
|
||||
输出状态：
|
||||
|
||||
- 评估通过，进入计划生成。
|
||||
- 需补充信息，退回需求人。
|
||||
- 暂缓，等待产品/库存/Listing恢复。
|
||||
- 驳回，记录原因。
|
||||
|
||||
阶段：V1必做。
|
||||
|
||||
### 3. 产品/ASIN/库存/评分校验
|
||||
|
||||
| 校验项 | 处理 |
|
||||
| --- | --- |
|
||||
| 产品是否启用 | 禁用则禁止生成渠道任务，允许进入待恢复池 |
|
||||
| ASIN是否正确 | 错误则退回补充或人工修正 |
|
||||
| 站点/店铺是否匹配 | 不匹配则阻断计划下发 |
|
||||
| 库存是否充足 | 库存紧张时限制测评/免评节奏 |
|
||||
| 评分/掉评/差评 | 触发回评或紧急催评策略 |
|
||||
| 关键词/H5/卡片 | 缺失则生成维护任务 |
|
||||
|
||||
阶段：V1必做。
|
||||
|
||||
### 4. 计划生成或调整
|
||||
|
||||
计划类型必须保留：
|
||||
|
||||
| 计划类型 | 说明 | 阶段 |
|
||||
| --- | --- | --- |
|
||||
| 测评计划 | 为产品增加评价、冲销量、拉排名、新品启动等 | V1必做 |
|
||||
| 回评计划 | 对已购/已测/待评价人群催评或稳定评分 | V1必做 |
|
||||
| 免评计划 | 面向长期测评人、KOC/KOL或补单需求，不计普通测评额度 | V1必做 |
|
||||
| KOC/KOL合作任务 | 样品、内容、带货、佣金、复盘 | V1预留/V2实现 |
|
||||
| 客服跟进计划 | 售后、催评、答应配合、异常用户跟进 | V1必做 |
|
||||
|
||||
计划生成时必须写入：
|
||||
|
||||
- 关联需求编号。
|
||||
- 产品/ASIN/站点/店铺。
|
||||
- 计划目标、周期、每日节奏、优先级。
|
||||
- 渠道策略。
|
||||
- 目标人群条件。
|
||||
- 额度预占策略。
|
||||
- 风险排除策略。
|
||||
- 客服承接要求。
|
||||
- H5/卡片/素材要求。
|
||||
- 关闭条件。
|
||||
|
||||
### 5. 执行资源匹配
|
||||
|
||||
计划不是创建后直接发出去，必须先匹配资源。
|
||||
|
||||
| 资源 | 匹配规则 |
|
||||
| --- | --- |
|
||||
| 人群 | 用户层级、国家、品类偏好、活跃、历史订单、Review额度、风险 |
|
||||
| 测评人 | 可测评次数、可免评次数、可上评次数、合作状态、掉评率、退款取消记录 |
|
||||
| KOC/KOL | 分层、品类、内容能力、带货能力、合作状态、风险状态 |
|
||||
| 渠道 | IM/EDM/Phone/APP/KOC-KOL可用性、频控、退订、投诉、转化 |
|
||||
| 客服 | 在线状态、排班、工单量、国家/语言、转化目标、当前压力 |
|
||||
| 产品素材 | H5、卡片、关键词链接、首图、编码图、跳转链接 |
|
||||
| 财务 | 可返款方式、返款账号、礼品卡卡密、审核队列 |
|
||||
| 风险 | 黑名单、强弱关联、退款取消、重复订单/评论/返款 |
|
||||
|
||||
阶段：V1必做半自动匹配，V2增强自动推荐。
|
||||
|
||||
### 6. 渠道任务 / 客服任务 / KOC-KOL任务生成
|
||||
|
||||
| 任务 | 生成条件 | 输出 |
|
||||
| --- | --- | --- |
|
||||
| IM推送任务 | 有可推人群、卡片/H5可用、频控通过 | 推送任务、渠道事件、标签 |
|
||||
| EDM任务 | 域名/邮箱/IP健康、UID人群正常、邮件素材/H5可用 | 邮件计划、AB Test、发送结果 |
|
||||
| Phone任务 | 用户有电话、适合电话沟通、客服容量可承接 | 电话名单、回拨任务、通话记录 |
|
||||
| 客服工单 | 用户回复、订单异常、信息缺失、售后问题、投诉 | 工单、处理人、状态 |
|
||||
| KOC/KOL任务 | 有合适达人、样品/免评/内容目标明确 | 合作任务、内容/带货跟踪 |
|
||||
| 财务返款任务 | 用户信息完整、订单/评价状态满足返款条件 | 请款/返款任务 |
|
||||
|
||||
### 7. 用户或达人响应
|
||||
|
||||
响应包括：
|
||||
|
||||
- 用户点击、回复、提交订单号、提交返款账号、上传评论截图/链接。
|
||||
- 用户只提交部分信息。
|
||||
- 用户投诉、退订、不感兴趣。
|
||||
- KOC/KOL接受任务、拒绝任务、提交内容链接、提交带货链接。
|
||||
|
||||
每次响应都要写入渠道事件，并触发有效互动复检。
|
||||
|
||||
### 8. 客服承接与信息补全
|
||||
|
||||
客服核心动作：
|
||||
|
||||
- 查看用户上下文卡。
|
||||
- 回复用户。
|
||||
- 查询/核验订单号。
|
||||
- 补充返款账号、截图、评论链接。
|
||||
- 登记订单。
|
||||
- 催评。
|
||||
- 记录售后问题和解决方案。
|
||||
- 标记答应配合。
|
||||
- 升级风险、财务、运营或主管。
|
||||
- 关闭或重开工单。
|
||||
|
||||
客服管理动作：
|
||||
|
||||
- 分配/转移工单。
|
||||
- 调整排班。
|
||||
- 设置目标。
|
||||
- 统计回复、工单、转化、满意度。
|
||||
|
||||
阶段：V1必做。
|
||||
|
||||
### 9. 履约：订单 / 评价 / 返款 / 佣金
|
||||
|
||||
| 履约对象 | 核心状态 |
|
||||
| --- | --- |
|
||||
| 订单 | 待登记、已登记、已发货、已取消、已退款、异常 |
|
||||
| 评价 | 待提交、已提交、待展示核验、已展示、未展示、掉评、差评 |
|
||||
| 返款 | 待请款、待审核、审核失败、待返款、返款成功、返款锁定 |
|
||||
| KOC/KOL内容 | 待接受、待寄样、待提交、待审核、已发布、链接异常 |
|
||||
| KOC/KOL佣金 | 待归因、待计算、待审核、待结算、已结算、争议 |
|
||||
|
||||
### 10. 风险复检与异常处理
|
||||
|
||||
复检时机：
|
||||
|
||||
- 需求评估。
|
||||
- 计划生成。
|
||||
- 人群生成。
|
||||
- 渠道发送前。
|
||||
- 用户提交订单/评价/返款账号。
|
||||
- 客服登记订单。
|
||||
- 请款/返款。
|
||||
- KOC/KOL接受任务、提交内容、结算佣金。
|
||||
|
||||
风险结果：
|
||||
|
||||
- 正常，继续执行。
|
||||
- 弱风险，提醒人工确认。
|
||||
- 强风险，阻断并生成风险事件。
|
||||
- 确认风险，同步黑名单。
|
||||
|
||||
### 11. 结果回流与复盘
|
||||
|
||||
结果必须回流到：
|
||||
|
||||
- 原需求：是否达成、是否关闭、是否需补量。
|
||||
- 计划：完成数、节奏、渠道表现、成本。
|
||||
- ASIN：评分、Review、差评、掉评。
|
||||
- 用户/测评人：额度、合作状态、标签、风险。
|
||||
- 客服：转化、回复、目标、绩效。
|
||||
- KOC/KOL：内容、带货、佣金、合作等级。
|
||||
- 渠道：素材、频控、人群、AB Test。
|
||||
|
||||
阶段：V1预留复盘记录，核心指标 V1必做。
|
||||
|
||||
## 状态总表
|
||||
|
||||
| 状态域 | 必须拆开 |
|
||||
| --- | --- |
|
||||
| 需求状态 | 草稿、待评估、需补充、已通过、已驳回、已转计划、已关闭 |
|
||||
| 计划状态 | 草稿、待审批、进行中、暂停、已完成、已取消、需补量 |
|
||||
| 资源匹配状态 | 待匹配、匹配中、匹配不足、匹配完成、需人工确认 |
|
||||
| 渠道任务状态 | 待发送、发送中、已发送、失败、已下架、暂停 |
|
||||
| 用户响应状态 | 未响应、已点击、已回复、已提交部分信息、已提交完整信息、投诉/退订 |
|
||||
| 工单状态 | 待分配、待处理、处理中、等待用户、已解决、已关闭、已重开 |
|
||||
| 订单状态 | 待登记、已登记、已发货、已取消、已退款、异常 |
|
||||
| 评价状态 | 待提交、已提交、待核验、已展示、未展示、掉评、差评 |
|
||||
| 返款状态 | 待请款、待审核、审核失败、待返款、返款成功、锁定 |
|
||||
| KOC/KOL任务状态 | 待分配、待接受、进行中、待内容、待审核、已发布、已结算、异常 |
|
||||
| 风险状态 | 正常、弱风险、强风险、已拦截、复核中、已解除、已拉黑 |
|
||||
|
||||
## Gate 1 - 主流程完成条件
|
||||
|
||||
- 主流程从需求进入到结果复盘完整。
|
||||
- 需求与执行计划匹配被明确为核心流程。
|
||||
- 客服被写入主流程核心位置。
|
||||
- KOC/KOL被作为完整需求域纳入，而不是仅做接口预留。
|
||||
- 测评、回评、免评、客服、渠道、财务、风险、看板之间的流转关系清楚。
|
||||
- V1必做、V1预留、V2实现、待确认有明确标注。
|
||||
|
||||
@@ -0,0 +1,198 @@
|
||||
# USER ERP 0-1需求重构 - 02 日常操作页面结构 v1
|
||||
|
||||
## 文件信息
|
||||
|
||||
- 文件名称：`20260527_USER_ERP_0-1需求重构_02_日常操作页面结构_v1.md`
|
||||
- 项目路径：`C:\XCODE\USER`
|
||||
- 输出位置：`C:\XCODE\USER\output\docs`
|
||||
- 当前版本：`v1`
|
||||
- 最近更新：`2026-05-27`
|
||||
- 所属阶段：Stage 1 完整业务需求
|
||||
- 负责人：业务负责人 / 产品负责人
|
||||
- 核心参与：USER运营、客服主管、渠道负责人、KOC/KOL负责人、风险、财务、前端观察员
|
||||
- 文件目的：定义每个岗位每天打开系统后先看什么、判断什么、处理什么，并据此组织页面结构。
|
||||
|
||||
## 页面设计原则
|
||||
|
||||
1. 第一屏必须是日常作战台，不是普通任务列表。
|
||||
2. 页面围绕“发现异常 -> 判断优先级 -> 分配动作 -> 执行 -> 跟进结果 -> 复盘沉淀”设计。
|
||||
3. 每个页面必须说明贡献哪个OKR：用户增长、评价转化、销售转化、活动转化、满意度、风险控制。
|
||||
4. 页面结构要服务需求与执行计划匹配，不能只展示静态数据。
|
||||
5. 客服执行和客服管理是一级核心入口。
|
||||
6. KOC/KOL在阶段1必须有页面结构，即使V1只预留部分入口。
|
||||
|
||||
## 一级导航建议
|
||||
|
||||
| 一级入口 | 定位 | 阶段 |
|
||||
| --- | --- | --- |
|
||||
| 今日作战台 | 所有角色的每日首页，显示异常、目标、今日必处理 | V1必做 |
|
||||
| 需求与计划调度中心 | 需求池、计划生成、执行资源匹配、计划调整 | V1必做 |
|
||||
| 评价计划与订单中心 | 测评、回评、免评计划和订单履约 | V1必做 |
|
||||
| 客服执行中心 | 工单、聊天、答应配合、催评、订单登记 | V1必做 |
|
||||
| 客服管理中心 | 出勤、排班、目标、绩效、服务质量 | V1必做 |
|
||||
| 渠道运营中心 | IM、EDM、Phone、APP/H5/卡片、推送任务 | V1必做 |
|
||||
| KOC/KOL协作中心 | 线索、达人、任务、内容、带货、佣金、风险 | V1预留/V2实现 |
|
||||
| 测评人/真实人中心 | 测评人档案、身份归并、额度、风险、历史 | V1必做 |
|
||||
| 风险与黑名单中心 | 风险事件、黑名单、退款比对、异常复检 | V1必做 |
|
||||
| 数据复盘看板 | 计划、ASIN、渠道、客服、KOC/KOL、财务复盘 | V1必做核心，V2增强 |
|
||||
| 系统配置 | 权限、渠道配置、字段、标签、通知、导入导出 | V1预留 |
|
||||
|
||||
## 01 今日作战台
|
||||
|
||||
### 目标
|
||||
|
||||
让主管和各岗位每天开屏后立刻知道：昨天有什么异常、本周目标是否危险、今天必须推进什么、哪些任务没人处理、哪些结果需要复盘。
|
||||
|
||||
### 页面区块
|
||||
|
||||
| 区块 | 展示内容 | 操作 |
|
||||
| --- | --- | --- |
|
||||
| 昨日核心指标 | 需求新增、计划新增、完成、缺口、客服工单、风险、返款 | 查看详情 |
|
||||
| P0/P1异常 | Review低于计划、渠道下滑、客服超时、产品禁用、风险事件 | 指派处理、升级 |
|
||||
| 今日必跟进 | 待评估需求、待补量计划、待催评用户、待返款、待审核内容 | 进入处理 |
|
||||
| 目标进度 | 月度测评、回评、免评、客服转化、KOC/KOL内容/带货 | 调整计划 |
|
||||
| 资源压力 | 可用人群、额度、客服容量、KOC/KOL资源、返款队列 | 资源调度 |
|
||||
| 昨日复盘 | TOP/BOTTOM任务、异常原因、沉淀动作 | 创建复盘 |
|
||||
|
||||
### 角色视图
|
||||
|
||||
| 角色 | 首页重点 |
|
||||
| --- | --- |
|
||||
| 高级主管 | OKR、资源、P0异常、跨部门阻塞 |
|
||||
| USER运营 | 需求、计划、执行缺口、渠道/客服压力 |
|
||||
| 渠道运营 | 触达漏斗、素材、可推人群、退订/投诉 |
|
||||
| 客服主管 | 在线、排班、待处理工单、首次回复、转化目标 |
|
||||
| KOC/KOL运营 | 线索、任务、内容、带货、风险 |
|
||||
| 风险/财务 | 待审核、待返款、双重退款、敏感操作 |
|
||||
|
||||
## 02 需求与计划调度中心
|
||||
|
||||
### 子页面
|
||||
|
||||
| 页面 | 说明 | 阶段 |
|
||||
| --- | --- | --- |
|
||||
| 需求池 | OA/销售/运营/异常/KOC-KOL需求统一入口 | V1必做 |
|
||||
| 需求评估页 | 校验ASIN、产品、库存、评分、目标、优先级 | V1必做 |
|
||||
| 计划编排页 | 生成测评、回评、免评、客服、KOC/KOL计划 | V1必做 |
|
||||
| 执行匹配看板 | 人群、渠道、客服、KOC/KOL、风险、H5/卡片匹配 | V1必做基础 |
|
||||
| 计划调整页 | 补量、暂停、恢复、转免评、关闭、拆分/合并 | V1必做 |
|
||||
|
||||
### 需求池字段
|
||||
|
||||
| 字段 | 说明 |
|
||||
| --- | --- |
|
||||
| 需求编号 | OA/系统生成 |
|
||||
| 需求来源 | OA、销售、运营、ASIN异常、客服反馈、KOC/KOL |
|
||||
| 需求类型 | 测评、回评、免评、客服跟进、KOC/KOL内容/带货 |
|
||||
| 产品/ASIN/站点/店铺 | 执行基础 |
|
||||
| 目标 | 目标订单数、Review数、评分、内容数、带货数 |
|
||||
| 优先级 | S/A/B/C 或 P0/P1/P2 |
|
||||
| 截止时间 | 计划完成约束 |
|
||||
| 当前状态 | 待评估、需补充、已转计划、暂停、关闭 |
|
||||
| 负责人 | 运营负责人 |
|
||||
|
||||
## 03 评价计划与订单中心
|
||||
|
||||
### 页面结构
|
||||
|
||||
| 页面 | 说明 | 阶段 |
|
||||
| --- | --- | --- |
|
||||
| 测评计划 | 产品测评需求、计划周期、渠道、目标、进度、评分、库存 | V1必做 |
|
||||
| 回评计划 | 掉评/差评/维稳/冲刺等回评需求与每日目标 | V1必做 |
|
||||
| 免评计划 | 长期测评人/KOC-KOL/补单免评计划 | V1必做 |
|
||||
| 测评订单 | 订单登记、上传回评、请款、返款、状态跟踪 | V1必做 |
|
||||
| 回评订单 | 回评上传、确认、返款、售后来源、处理记录 | V1必做 |
|
||||
| 产品/ASIN详情 | 评分、Review、库存、关键词、渠道、H5/卡片 | V1预留 |
|
||||
|
||||
## 04 客服执行中心
|
||||
|
||||
客服执行中心是 V1 核心入口。
|
||||
|
||||
| 页面 | 每天要解决的问题 | 核心操作 |
|
||||
| --- | --- | --- |
|
||||
| 工单池 | 哪些用户消息没人处理，哪些工单快超时 | 分配、领取、转移、标记解决、关闭 |
|
||||
| 我的工单 | 当前客服今天处理什么 | 回复、登记订单、催评、上传结果、升级 |
|
||||
| 聊天/消息 | 用户具体说了什么 | 快捷回复、补充信息、创建跟进 |
|
||||
| 服务聊天记录 | 复查历史沟通 | 查询、查看上下文 |
|
||||
| 答应配合 | 用户答应评价/反馈后是否完成 | 确认、拒绝、提醒、过期 |
|
||||
| 催评池 | 哪些测评/回评待催 | 发送提醒、转人工、关闭 |
|
||||
| 售后详情 | 用户问题、解决方案、订单、返款 | 记录方案、回访、升级 |
|
||||
|
||||
## 05 客服管理中心
|
||||
|
||||
| 页面 | 展示 | 操作 |
|
||||
| --- | --- | --- |
|
||||
| 客服Dashboard | 在线客服、今日工单、待处理、今日转化、本月目标 | 查看详情 |
|
||||
| 出勤管理 | 应出勤、实际出勤、出勤率、迟到/请假/缺勤 | 导入/调整 |
|
||||
| 排班管理 | 早班、午班、晚班、渠道、最大工单数 | 设置、批量排班、调整 |
|
||||
| 工单分配管理 | 分配规则、当前工单量、超时工单 | 自动分配、手动调整 |
|
||||
| 回复统计 | 回复用户数、处理工单、消息数、首次回复 | 导出 |
|
||||
| 转化绩效 | RSO/RDO登记订单、获取评价、完成率 | 查看排行 |
|
||||
| 目标管理 | 月目标、历史完成、客服个人趋势 | 设置目标、调整 |
|
||||
|
||||
## 06 渠道运营中心
|
||||
|
||||
| 页面 | 说明 | 阶段 |
|
||||
| --- | --- | --- |
|
||||
| IM推送 | 用户分层、卡片、推送任务、回复、转化 | V1必做 |
|
||||
| IM卡片/H5管理 | 卡片、图片、链接、跳转、产品禁用联动 | V1必做 |
|
||||
| EDM每日检查 | 域名/邮箱/IP信誉、UID、H5、AB Test、转化 | V1必做基础 |
|
||||
| Phone工作台 | 未接/待回拨、国家/时段、问题类型、客服容量 | V1预留 |
|
||||
| 推送配置 | 渠道账号、日限额、状态、负责人 | V1预留 |
|
||||
| 渠道漏斗看板 | 推送、曝光、点击、回复、订单、评价 | V1必做 |
|
||||
|
||||
## 07 KOC/KOL协作中心
|
||||
|
||||
阶段1必须完整定义，V1可部分预留。
|
||||
|
||||
| 页面 | 说明 | 阶段 |
|
||||
| --- | --- | --- |
|
||||
| KOC/KOL线索池 | 新增线索、来源、标签、风险、分层 | V1预留 |
|
||||
| 达人档案 | 国家、品类、内容能力、带货能力、合作状态 | V1预留 |
|
||||
| 合作任务 | 样品、免评、内容、带货、佣金任务 | V1预留/V2 |
|
||||
| 内容记录 | 内容链接、审核、发布时间、表现 | V2实现 |
|
||||
| 带货归因 | Code、链接、订单、销售额 | V2实现 |
|
||||
| 佣金结算 | 佣金规则、结算、争议 | V2实现 |
|
||||
| KOC/KOL风险 | 标签混乱、重复触达、违规内容、佣金争议 | V1预留 |
|
||||
|
||||
## 08 测评人/真实人中心
|
||||
|
||||
| 页面 | 说明 | 阶段 |
|
||||
| --- | --- | --- |
|
||||
| 测评人列表 | 编号、Joyhub、邮箱、电话、Profile、国家、标签、合作状态 | V1必做 |
|
||||
| 测评人详情 | 额度、订单、评价、返款、风险、沟通记录 | V1必做 |
|
||||
| 真实人归并 | 标准化姓名+地址、设备、邮箱、电话、Profile、收款信息等自动归并；人工确认/拆分作为修正入口 | 自动归并 V1必做，人工确认/拆分 V1预留 |
|
||||
| 额度台账 | 月度测评、月度免评、累计Review、预占/释放 | V1必做 |
|
||||
| 风险记录 | 黑名单、退款取消、掉评、弱/强关联 | V1必做 |
|
||||
|
||||
说明：`4/4/12`额度控制依赖真实人维度，V1必须先具备自动归并能力，否则 `person_quota_ledgers` 无法跨 JOYHUB ID、Amazon 账号和 Profile 合并计算。
|
||||
|
||||
## 09 风险与黑名单中心
|
||||
|
||||
| 页面 | 说明 |
|
||||
| --- | --- |
|
||||
| 风险事件 | 所有风险信号与人工复核案件 |
|
||||
| 黑名单 | 生效中/已移除、风险等级、来源、原因 |
|
||||
| 退款比对 | Amazon退款与OA返款双重比对 |
|
||||
| 关联风险 | 邮箱、电话、设备、IP、Profile、地址、返款账号 |
|
||||
| 内容/佣金风险 | KOC/KOL内容不合规、归因失败、佣金争议 |
|
||||
|
||||
## 10 数据复盘看板
|
||||
|
||||
| 看板 | 指标 |
|
||||
| --- | --- |
|
||||
| 计划看板 | 总计划、进行中、完成率、缺口、补量 |
|
||||
| ASIN看板 | 评分、Review、差评、掉评、库存、风险ASIN |
|
||||
| 渠道看板 | 推送、曝光、点击、回复、转化、退订/投诉 |
|
||||
| 客服看板 | 工单、响应、解决、满意度、RSO/RDO转化 |
|
||||
| 测评人看板 | 额度、完成率、掉评率、风险、合作状态 |
|
||||
| KOC/KOL看板 | 线索、任务、内容、带货、佣金、风险 |
|
||||
| 财务看板 | 待请款、待审核、返款成功、异常返款 |
|
||||
|
||||
## Gate 1 - 页面结构完成条件
|
||||
|
||||
- 今日作战台和岗位每日工作方式已定义。
|
||||
- 需求与计划调度中心作为一级核心入口。
|
||||
- 客服执行中心和客服管理中心作为一级核心入口。
|
||||
- KOC/KOL协作中心已有完整需求结构，即使V1不全量实现。
|
||||
- 各页面能对应主流程中的对象、状态、动作和复盘指标。
|
||||
@@ -0,0 +1,190 @@
|
||||
# USER ERP 0-1需求重构 - 03 功能页面按钮盘点表 v1
|
||||
|
||||
## 文件信息
|
||||
|
||||
- 文件名称：`20260527_USER_ERP_0-1需求重构_03_功能页面按钮盘点表_v1.md`
|
||||
- 项目路径：`C:\XCODE\USER`
|
||||
- 输出位置：`C:\XCODE\USER\output\docs`
|
||||
- 当前版本：`v1`
|
||||
- 最近更新：`2026-05-27`
|
||||
- 所属阶段：Stage 1 完整业务需求
|
||||
- 负责人：产品负责人 / 前端观察员
|
||||
- 核心参与：业务用户、客服主管、渠道运营、KOC/KOL运营、财务、风险、后端、测试
|
||||
- 文件目的：盘点阶段1涉及的页面按钮、业务含义、读写对象、状态变化、权限和审计要求，作为 Stage 2 按钮行为矩阵的输入。
|
||||
|
||||
## 盘点规则
|
||||
|
||||
| 字段 | 说明 |
|
||||
| --- | --- |
|
||||
| 页面 | 按一级/二级页面归类 |
|
||||
| 按钮/动作 | 用户可点击或系统触发的动作 |
|
||||
| 业务含义 | 为什么需要这个按钮 |
|
||||
| 读取对象 | 点击前必须读的数据 |
|
||||
| 写入对象 | 点击后必须落盘的数据 |
|
||||
| 状态变化 | 影响哪些状态 |
|
||||
| 权限 | 哪些角色可操作 |
|
||||
| 审计 | 是否必须记录操作日志 |
|
||||
| 阶段 | V1必做、V1预留、V2实现、待确认 |
|
||||
|
||||
## 对象命名对照
|
||||
|
||||
按钮盘点表中的“读取对象/写入对象”保留页面语境简称；进入 Stage 2 接口和数据设计时，应优先映射到数据对象 v3 的正式对象名。
|
||||
|
||||
| 按钮盘点简称 | v3正式对象或聚合口径 |
|
||||
| --- | --- |
|
||||
| person | `person_profiles` |
|
||||
| identity | `person_identity_links` |
|
||||
| reviewer | `person_identity_links` + `person_quota_ledgers` 聚合视图 |
|
||||
| quota / quota_ledger | `person_quota_ledgers` |
|
||||
| quota_reservation | `quota_reservations` |
|
||||
| audience / audience_snapshot | `audience_snapshots` |
|
||||
| exclusion | `audience_exclusions` |
|
||||
| risk_event | `risk_signals` / `risk_cases` |
|
||||
| risk | `risk_signals` / `risk_cases` / `blacklist_entities` 聚合摘要 |
|
||||
| order / review_order | `amazon_orders`、`review_submission_records`、`review_display_checks` |
|
||||
| push_task / channel_event | `channel_route_decisions`、`channel_dedup_records`、各渠道事件表 |
|
||||
| interaction_recheck | `interaction_recheck_records` |
|
||||
| koc_kol / creator | JOYCOLLAB 的 `creator_id`，以及 `exemption_plan_tasks`、`creator_content_records`、`exemption_result_snapshots` |
|
||||
|
||||
## 01 今日作战台
|
||||
|
||||
| 按钮/动作 | 业务含义 | 读取对象 | 写入对象 | 状态变化 | 权限 | 审计 | 阶段 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| 查看异常 | 进入昨日/今日异常详情 | alert、plan、channel_event、ticket、risk_event | - | - | 主管、运营 | 否 | V1必做 |
|
||||
| 指派处理人 | 把异常转成可执行任务 | alert、staff、shift | task、notification | 异常：待处理 -> 已指派 | 主管、运营 | 是 | V1必做 |
|
||||
| 升级异常 | P0/P1问题升级主管或跨部门 | alert、risk_event、ticket | escalation、notification | 异常：待处理 -> 已升级 | 主管、风险 | 是 | V1必做 |
|
||||
| 调整计划 | 从作战台直接进入计划调整 | demand、plan、progress | plan_change_log | 计划：进行中 -> 调整中/暂停/补量 | 主管、运营 | 是 | V1必做 |
|
||||
| 创建复盘 | 对异常或任务形成复盘记录 | plan、channel_event、ticket、order | retrospective | 异常：已处理 -> 待复盘 | 主管、运营 | 是 | V1预留 |
|
||||
|
||||
## 02 需求与计划调度中心
|
||||
|
||||
| 页面 | 按钮/动作 | 业务含义 | 读取对象 | 写入对象 | 状态变化 | 权限 | 审计 | 阶段 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| 需求池 | 新增需求 | 手动录入销售/运营/KOC-KOL需求 | product、asin、staff | demand | 需求：草稿 | 运营、主管 | 是 | V1必做 |
|
||||
| 需求池 | 导入OA需求 | 从OA或表格批量导入需求 | import_file | demand、import_log | 需求：待评估 | 运营、管理员 | 是 | V1必做 |
|
||||
| 需求池 | 需求评估 | 判断需求是否可执行 | demand、product、asin、inventory、risk | demand_review | 待评估 -> 已通过/需补充/驳回 | 运营、主管 | 是 | V1必做 |
|
||||
| 需求池 | 退回补充 | 信息不足时退回需求人 | demand | demand、notification | 待评估 -> 需补充 | 运营 | 是 | V1必做 |
|
||||
| 需求池 | 生成计划 | 将需求转成测评/回评/免评/KOC-KOL/客服计划 | demand、product、audience、quota、risk | plan、plan_log | 已通过 -> 已转计划 | 运营、主管 | 是 | V1必做 |
|
||||
| 计划编排 | 拆分计划 | 一个需求拆成多个站点/渠道/周期计划 | demand、plan | plan、plan_relation | 计划：草稿/进行中 | 运营、主管 | 是 | V1预留 |
|
||||
| 计划编排 | 合并计划 | 合并同产品/同周期/同目标计划 | plan | plan_relation、plan_log | 计划：合并/关闭旧计划 | 主管 | 是 | V1预留 |
|
||||
| 执行匹配 | 匹配人群 | 生成候选用户/测评人/KOC-KOL名单 | person、reviewer、koc_kol、quota、risk | audience_snapshot、exclusion | 匹配：待匹配 -> 完成/不足 | 运营 | 是 | V1必做 |
|
||||
| 执行匹配 | 预占额度 | 锁定测评/免评/Review额度 | audience_snapshot、quota_ledger | quota_reservation | 额度：可用 -> 预占 | 运营 | 是 | V1必做 |
|
||||
| 执行匹配 | 手动释放预占 | 预占超时、计划取消或人群撤出后释放额度 | quota_reservation、quota_ledger、plan | quota_reservation_log、quota_ledger | 额度：已预占 -> 已释放 | 主管、管理员 | 是 | V1必做 |
|
||||
| 执行匹配 | 分配客服 | 按容量、语言、工单量分配承接客服 | plan、ticket、shift、agent_capacity | task、ticket_assignment | 待分配 -> 已分配 | 主管、客服主管 | 是 | V1必做 |
|
||||
| 执行匹配 | 生成推送任务 | 从计划生成人群和渠道任务 | plan、audience、card、h5、channel_config | push_task、channel_event | 待发送 | 渠道运营 | 是 | V1必做 |
|
||||
| 执行匹配 | 匹配KOC/KOL | 将需求匹配给合适创作者 | koc_kol_profile、task、risk | koc_kol_task | 待分配 -> 待接受 | KOC/KOL运营 | 是 | V1预留 |
|
||||
| 计划调整 | 调整名额 | 增减计划数量 | plan、progress、resource | plan_change_log | 计划目标变化 | 运营、主管 | 是 | V1必做 |
|
||||
| 计划调整 | 暂停计划 | 禁止继续执行但保留历史 | plan、risk、product | plan_log、notification | 进行中 -> 暂停 | 主管 | 是 | V1必做 |
|
||||
| 计划调整 | 恢复计划 | 恢复已暂停计划 | plan、product、risk | plan_log | 暂停 -> 进行中 | 主管 | 是 | V1必做 |
|
||||
| 计划调整 | 转免评 | 普通测评/回评因店铺/订单/用户问题转免评 | plan、order、reviewer | plan、order_log | 测评/回评 -> 免评 | 运营、主管 | 是 | V1必做 |
|
||||
| 计划调整 | 关闭需求 | 需求完成或取消 | demand、plan、progress | demand_close_log | 需求：已关闭 | 主管 | 是 | V1必做 |
|
||||
|
||||
## 03 评价计划与订单中心
|
||||
|
||||
| 页面 | 按钮/动作 | 业务含义 | 读取对象 | 写入对象 | 状态变化 | 权限 | 审计 | 阶段 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| 测评计划 | 新建测评计划 | 从需求或人工创建计划 | demand、product、asin | review_plan | 草稿/未开始 | 运营 | 是 | V1必做 |
|
||||
| 测评计划 | 编辑计划 | 修改目标、渠道、周期、负责人 | review_plan | plan_log | 计划字段变化 | 运营、主管 | 是 | V1必做 |
|
||||
| 测评计划 | 复制关键词链接 | 运营执行用 | review_plan | copy_event | - | 运营 | 否 | V1必做 |
|
||||
| 测评计划 | 查看关联推送 | 查看计划下发的渠道任务 | plan、push_task | - | - | 运营、渠道 | 否 | V1必做 |
|
||||
| 测评计划 | 查看关联订单 | 查看计划履约订单 | plan、order | - | - | 运营 | 否 | V1必做 |
|
||||
| 回评计划 | 新建回评计划 | 因掉评/差评/维稳生成回评计划 | asin、review_stats | reply_plan | 待开始 | 运营 | 是 | V1必做 |
|
||||
| 回评计划 | 调整今日目标 | 根据评分/掉评变化调整当天目标 | reply_plan、asin_stats | plan_log | 今日目标变化 | 运营、主管 | 是 | V1必做 |
|
||||
| 免评计划 | 新建免评计划 | 给长期测评人/KOC-KOL/补单池创建免评计划 | demand、reviewer、koc_kol | free_plan | 待审批/进行中 | 运营 | 是 | V1必做 |
|
||||
| 测评订单 | 新增订单 | 记录测评执行单 | plan、person、product | review_order | 待上传回评/待登记 | 运营、客服 | 是 | V1必做 |
|
||||
| 测评订单 | 上传订单 | 绑定Amazon订单号 | review_order、amazon_order | review_order、audit_log | 订单：待登记 -> 已登记 | 运营、客服 | 是 | V1必做 |
|
||||
| 测评订单 | 上传回评 | 绑定评论ID/链接/截图 | review_order、comment | review_submission | 待回评 -> 待确认/已提交 | 运营、客服 | 是 | V1必做 |
|
||||
| 测评订单 | 提交排队 | 评论暂不能绑定，进入排队 | review_order、comment_query | review_queue | 待确认 | 运营、客服 | 是 | V1必做 |
|
||||
| 测评订单 | 请款 | 发起用户返款 | review_order、refund_account | refund_request | 待请款 -> 待审核 | 运营、客服 | 是 | V1必做 |
|
||||
| 测评订单 | 更换订单 | 用新订单替代原订单 | review_order、amazon_order | order_change_log | 订单号变化 | 运营、主管 | 是 | V1必做 |
|
||||
| 测评订单 | 更改订单 | 修正订单字段 | review_order | order_change_log | 订单字段变化 | 运营、主管 | 是 | V1必做 |
|
||||
| 测评订单 | 撤销 | 撤销错误/风险订单 | review_order、risk | order_log、quota_release | 进行中 -> 撤销 | 风险、主管 | 是 | V1必做 |
|
||||
| 测评订单 | 批量导出 | 导出当前筛选结果 | order、permission | export_task | - | 有导出权限 | 是 | V1必做 |
|
||||
| 回评订单 | 回评确认 | 核验回评是否有效 | review_submission、comment | review_display_check | 待确认 -> 已回评/未通过 | 运营、审核 | 是 | V1必做 |
|
||||
|
||||
## 04 客服执行中心
|
||||
|
||||
| 页面 | 按钮/动作 | 业务含义 | 读取对象 | 写入对象 | 状态变化 | 权限 | 审计 | 阶段 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| 工单池 | 自动分配 | 按在线、工单量、排班分配客服 | ticket、agent、shift | ticket_assignment | 待分配 -> 待处理 | 客服主管 | 是 | V1必做 |
|
||||
| 工单池 | 手动分配 | 指定处理人 | ticket、agent | ticket_assignment | 待分配 -> 待处理 | 客服主管 | 是 | V1必做 |
|
||||
| 工单池 | 转移工单 | 换客服处理 | ticket、agent | ticket_transfer_log | 处理人变化 | 客服、主管 | 是 | V1必做 |
|
||||
| 我的工单 | 回复用户 | 处理用户消息 | ticket、chat、context_snapshot | chat_message、ticket_log | 待处理 -> 处理中/等待用户 | 客服 | 是 | V1必做 |
|
||||
| 我的工单 | 登记订单 | 客服拿到订单号后登记 | ticket、amazon_order、person | review_order、ticket_log | 工单推进 | 客服 | 是 | V1必做 |
|
||||
| 我的工单 | 催评 | 提醒用户提交评价 | ticket、order、followup | reminder_event、followup | 催评次数+1 | 客服、运营 | 是 | V1必做 |
|
||||
| 我的工单 | 标记解决 | 用户问题解决 | ticket | ticket_log | 处理中 -> 已解决 | 客服 | 是 | V1必做 |
|
||||
| 我的工单 | 关闭工单 | 完成或无需继续 | ticket | ticket_log | 已解决/等待用户 -> 已关闭 | 客服、主管 | 是 | V1必做 |
|
||||
| 我的工单 | 重开工单 | 用户再次反馈 | ticket | ticket_log | 已关闭 -> 已重开/处理中 | 客服、主管 | 是 | V1必做 |
|
||||
| 答应配合 | 确认答应 | 用户答应评价/反馈 | ticket、person | support_followup | 待确认 -> 已确认 | 客服 | 是 | V1必做 |
|
||||
| 答应配合 | 拒绝 | 用户拒绝配合 | ticket | support_followup | 待确认 -> 已拒绝 | 客服 | 是 | V1必做 |
|
||||
| 答应配合 | 标记过期 | 超时未提交 | followup | support_followup | 已确认 -> 已过期 | 客服、系统 | 是 | V1必做 |
|
||||
|
||||
## 05 客服管理中心
|
||||
|
||||
| 页面 | 按钮/动作 | 业务含义 | 读取对象 | 写入对象 | 状态变化 | 权限 | 审计 | 阶段 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| 出勤管理 | 导入出勤 | 导入当天/本月出勤 | attendance_file | attendance_record | 出勤记录更新 | 客服主管、人事 | 是 | V1预留 |
|
||||
| 出勤管理 | 调整出勤状态 | 修正迟到/请假/缺勤 | attendance_record | attendance_log | 状态变化 | 客服主管 | 是 | V1必做 |
|
||||
| 排班管理 | 设置班次 | 给客服设置早/午/晚班 | agent、date | shift_schedule | 排班变化 | 客服主管 | 是 | V1必做 |
|
||||
| 排班管理 | 批量排班 | 一次生成多天排班 | agent、date_range | shift_schedule | 排班批量变化 | 客服主管 | 是 | V1必做 |
|
||||
| 目标管理 | 设置月目标 | 设置RSO/RDO登记和上评目标 | agent、period | support_target | 目标变化 | 客服主管 | 是 | V1必做 |
|
||||
| 绩效看板 | 导出绩效 | 导出回复/转化/目标完成 | performance_snapshot | export_task | - | 客服主管 | 是 | V1必做 |
|
||||
|
||||
## 06 渠道运营中心
|
||||
|
||||
| 页面 | 按钮/动作 | 业务含义 | 读取对象 | 写入对象 | 状态变化 | 权限 | 审计 | 阶段 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| IM推送 | 新增推送 | 创建IM触达任务 | plan、audience、card | im_push_task | 草稿/待发送 | 渠道运营 | 是 | V1必做 |
|
||||
| IM推送 | 上架/下架 | 控制任务是否可执行 | im_push_task | channel_log | 已上架/已下架 | 渠道运营 | 是 | V1必做 |
|
||||
| IM推送 | 批量分配 | 将任务分配到账号/渠道 | push_task、im_account | assignment | 待分配 -> 已分配 | 渠道运营 | 是 | V1预留 |
|
||||
| IM卡片 | 新增卡片 | 创建卡片素材 | product、h5 | im_card | 已上架/草稿 | 渠道运营 | 是 | V1必做 |
|
||||
| IM卡片 | 下架卡片 | 产品禁用/素材失效时下架 | im_card、product | card_log | 已上架 -> 已下架 | 渠道运营 | 是 | V1必做 |
|
||||
| EDM | 检查基础设施 | 确认域名/邮箱/IP信誉 | edm_config、deliverability | daily_check | 健康/异常 | EDM运营 | 否 | V1必做 |
|
||||
| EDM | 创建AB Test | 测试标题/素材/按钮 | edm_campaign | ab_test | 运行中 | EDM运营 | 是 | V1预留 |
|
||||
| Phone | 创建回拨任务 | 对未接/待跟进用户安排电话 | tel_pool、agent_shift | tel_task | 待拨打 | Phone/客服 | 是 | V1预留 |
|
||||
| 渠道配置 | 配置去重规则 | 定义跨IM/EDM/APP/Phone/KOC触达的去重、例外和频控条件 | channel_config、person、risk、quota | channel_dedup_rule、channel_log | 规则生效/停用 | 渠道主管、管理员 | 是 | V1预留 |
|
||||
|
||||
## 07 KOC/KOL协作中心
|
||||
|
||||
| 页面 | 按钮/动作 | 业务含义 | 读取对象 | 写入对象 | 状态变化 | 权限 | 审计 | 阶段 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| 线索池 | 新增线索 | 新增KOC/KOL候选人 | source、contact | creator_profile | 待审核 | KOC/KOL运营 | 是 | V1预留 |
|
||||
| 线索池 | 打标分层 | 区分新手KOC、稳定测评者、垂直专家、带货型KOL | creator_profile、metrics | creator_tag、tier_log | 分层变化 | KOC/KOL运营 | 是 | V1预留 |
|
||||
| 任务管理 | 创建合作任务 | 样品、免评、内容、带货任务 | demand、product、creator | creator_task | 待接受 | KOC/KOL运营 | 是 | V1预留 |
|
||||
| 任务管理 | 分配样品/免评名额 | 执行合作资源分配 | creator_task、inventory、quota | sample_order/free_order | 待寄样/待执行 | KOC/KOL运营 | 是 | V1预留 |
|
||||
| 内容记录 | 上传内容链接 | 记录发布内容 | creator_task | content_record | 待审核/已发布 | KOC/KOL运营 | 是 | V2实现 |
|
||||
| 内容记录 | 审核内容 | 判断内容合规和是否可分发 | content_record、content_policy | content_audit | 通过/驳回 | 审核、运营 | 是 | V2实现 |
|
||||
| 带货归因 | 同步订单 | 记录Code/链接带来的订单 | attribution、order | creator_order | 待结算 | KOC/KOL运营 | 是 | V2实现 |
|
||||
| 佣金结算 | 计算佣金 | 根据规则生成佣金 | creator_order、commission_rule | commission_record | 待审核 | 财务、运营 | 是 | V2实现 |
|
||||
| 风险处理 | 暂停合作 | 风险/投诉/作弊时暂停 | creator_profile、risk | creator_status_log | 可合作 -> 暂停 | 风险、主管 | 是 | V1预留 |
|
||||
|
||||
## 08 测评人/真实人中心
|
||||
|
||||
| 页面 | 按钮/动作 | 业务含义 | 读取对象 | 写入对象 | 状态变化 | 权限 | 审计 | 阶段 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| 真实人归并 | 手动合并 | 修正自动归并不足，把多个账号/身份线索合并到同一真实人 | person、identity、quota_ledger、risk | person_identity_link、merge_log、quota_ledger | 多个身份 -> 同一真实人 | 主管、风险、管理员 | 是 | V1预留 |
|
||||
| 真实人归并 | 手动拆分 | 纠正误合并，拆开不同真实人 | person、identity、quota_ledger、risk | person_identity_link、split_log、quota_ledger | 同一真实人 -> 多个真实人 | 主管、风险、管理员 | 是 | V1预留 |
|
||||
| 额度台账 | 查看额度明细 | 查看4/4/12额度、预占、释放、提交计数来源 | person、quota_ledger、quota_reservation、review_submission | - | - | 运营、客服主管、风险 | 否 | V1必做 |
|
||||
| 互动复检 | 查看审计记录 | 追溯每次有效互动为什么继续、拦截或转人工 | interaction_recheck、person、quota_ledger、risk | - | - | 运营、风险、客服主管 | 否 | V1必做 |
|
||||
|
||||
## 09 风险与财务
|
||||
|
||||
| 页面 | 按钮/动作 | 业务含义 | 读取对象 | 写入对象 | 状态变化 | 权限 | 审计 | 阶段 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| 风险事件 | 创建风险事件 | 人工或系统发现风险 | person、order、refund、creator | risk_case | 待复核 | 风险、系统 | 是 | V1必做 |
|
||||
| 风险事件 | 复核通过 | 确认风险 | risk_case | risk_case、blacklist | 复核中 -> 确认风险 | 风险 | 是 | V1必做 |
|
||||
| 风险事件 | 排除风险 | 解除误报 | risk_case | risk_case | 复核中 -> 排除 | 风险 | 是 | V1必做 |
|
||||
| 黑名单 | 新增黑名单 | 阻断后续触达/返款/合作 | person、creator、identity | blacklist_item | 生效中 | 风险 | 是 | V1必做 |
|
||||
| 退款比对 | 标记双重退款 | Amazon退款+OA返款命中 | refund_records | risk_signal | 疑似/确认双重退款 | 风险、财务 | 是 | V1必做 |
|
||||
| 返款 | 审核请款 | 付款前审核 | refund_request、order、risk | refund_record | 待审核 -> 待返款/失败 | 财务 | 是 | V1必做 |
|
||||
| 返款 | 确认返款 | 完成付款/卡密发送 | refund_record | refund_record、notification | 待返款 -> 成功 | 财务 | 是 | V1必做 |
|
||||
|
||||
## Gate 1 - 按钮盘点完成条件
|
||||
|
||||
- 核心页面按钮均有业务含义，不只是UI动作。
|
||||
- 每个关键按钮都有读写对象、状态变化、权限和审计要求。
|
||||
- 客服执行与客服管理按钮覆盖完整。
|
||||
- KOC/KOL按钮覆盖需求完整性，并标注实现阶段。
|
||||
- 需求与计划匹配相关按钮覆盖生成、匹配、分配、调整、暂停、补量、关闭。
|
||||
- 额度预占释放、真实人合并/拆分、互动复检审计、渠道去重规则已有按钮入口。
|
||||
- Stage 2 可按对象命名对照表把页面简称映射到数据对象 v3 的正式对象。
|
||||
@@ -0,0 +1,352 @@
|
||||
# USER ERP 0-1需求重构 - 04 分支流程_完整需求域 v1
|
||||
|
||||
## 文件信息
|
||||
|
||||
- 文件名称：`20260527_USER_ERP_0-1需求重构_04_分支流程_完整需求域_v1.md`
|
||||
- 项目路径：`C:\XCODE\USER`
|
||||
- 输出位置：`C:\XCODE\USER\output\docs`
|
||||
- 当前版本：`v1`
|
||||
- 最近更新：`2026-05-27`
|
||||
- 所属阶段：Stage 1 完整业务需求
|
||||
- 负责人：业务负责人
|
||||
- 核心参与：USER运营、渠道运营、客服、KOC/KOL运营、财务、风险、产品
|
||||
- 文件目的：整理主流程下所有核心分支，确保阶段1需求完整，不因V1实现边界遗漏KOC/KOL、客服或计划匹配。
|
||||
|
||||
## 分支一：需求与计划匹配
|
||||
|
||||
### 触发条件
|
||||
|
||||
- OA测评计划新增或变化。
|
||||
- 销售/运营提交产品推广需求。
|
||||
- ASIN评分、差评、掉评触发回评/紧急催评。
|
||||
- 新品、库存、Listing、关键词状态变化。
|
||||
- KOC/KOL合作或带货需求进入。
|
||||
- 客服反馈某类用户或产品问题集中出现。
|
||||
|
||||
### 流程
|
||||
|
||||
```text
|
||||
需求进入
|
||||
-> 校验产品/ASIN/站点/店铺/库存/评分/关键词
|
||||
-> 判断需求类型
|
||||
-> 匹配计划类型
|
||||
-> 匹配执行资源
|
||||
-> 生成计划、渠道任务、客服任务或KOC/KOL任务
|
||||
-> 执行结果回流需求
|
||||
```
|
||||
|
||||
### 读取
|
||||
|
||||
- demand、product、asin、inventory、rating、review_stats、keyword、h5/card。
|
||||
- person_feature、reviewer、creator、quota、risk。
|
||||
- channel_config、agent_shift、agent_capacity、refund_capacity。
|
||||
|
||||
### 写入
|
||||
|
||||
- plan、plan_change_log、audience_snapshot、quota_reservation。
|
||||
- push_task、ticket、creator_task、risk_exclusion。
|
||||
|
||||
### 关闭条件
|
||||
|
||||
- 需求已转计划并完成。
|
||||
- 需求被驳回并有原因。
|
||||
- 需求被拆分或合并，并保留引用关系。
|
||||
- 需求进入待补充或待恢复，不再误触发执行。
|
||||
|
||||
### 阶段
|
||||
|
||||
V1必做。
|
||||
|
||||
## 分支二：IM推送
|
||||
|
||||
### 用户分层
|
||||
|
||||
| 层级 | 定义 | 策略 |
|
||||
| --- | --- | --- |
|
||||
| 未参与过用户 | 注册App并绑定玩具，未参与回评/测评 | 优先推绑定产品回评卡片 |
|
||||
| 参与过用户 | 已参与回评/测评，真实人累计提交评价 < 12 | 优先催评，再推新测评 |
|
||||
| 长期测评人 | 真实人累计提交评价 >= 12 | 不优先普通测评，优先免评补单 |
|
||||
| 回评待完成 | 订单已登记但未上传评价/截图 | 催评 |
|
||||
| 测评待返款 | 已登记但缺返款信息或待返款 | 补信息/财务提醒 |
|
||||
|
||||
### 流程
|
||||
|
||||
```text
|
||||
人群生成
|
||||
-> 频控与风险复检
|
||||
-> 选择卡片/H5/文字/图片
|
||||
-> 推送
|
||||
-> 用户点击/回复/提交信息
|
||||
-> 系统核验订单号/返款账号/评论截图
|
||||
-> 完整则进入订单/返款/评价流程
|
||||
-> 不完整则生成客服工单或待补信息标签
|
||||
```
|
||||
|
||||
### 必查
|
||||
|
||||
- 用户是否黑名单。
|
||||
- 读取 `person_quota_ledgers`，按真实人判断累计提交评价、月度测评和月度免评额度。
|
||||
- 是否有未完成测评/回评。
|
||||
- 是否退款/取消订单。
|
||||
- 产品是否禁用。
|
||||
- H5/卡片是否有效。
|
||||
- 同一用户今日是否已触达。
|
||||
|
||||
### 阶段
|
||||
|
||||
V1必做。
|
||||
|
||||
## 分支三：EDM每日运营
|
||||
|
||||
### 每日先看
|
||||
|
||||
- 域名、邮箱、IP信誉是否健康。
|
||||
- OA测评计划是否变化。
|
||||
- KV/UID人群是否正常。
|
||||
- 产品选择、H5制作和H5数据维护是否受产品禁用影响。
|
||||
- 邮件发送、打开、点击、回复、退订、投诉。
|
||||
- 当天推送计划、AB Test、审核状态。
|
||||
- 菲律宾问题、订单、客服跟进清单。
|
||||
- 邮件转化数据。
|
||||
|
||||
### 流程
|
||||
|
||||
```text
|
||||
基础设施检查
|
||||
-> 同步OA计划
|
||||
-> 检查UID人群
|
||||
-> 检查产品/H5/链接
|
||||
-> 生成或调整EDM任务
|
||||
-> 发送与AB Test
|
||||
-> 回收打开/点击/回复/退订/投诉
|
||||
-> 转化到订单/客服/风险/复盘
|
||||
```
|
||||
|
||||
### 阶段
|
||||
|
||||
V1必做基础；深度AB自动优化 V2实现。
|
||||
|
||||
## 分支四：Phone工作流
|
||||
|
||||
### 每日先看
|
||||
|
||||
- 未接电话和待回拨。
|
||||
- 问题类型分布。
|
||||
- 国家/语言/时段。
|
||||
- 哪个国家电话量最高。
|
||||
- 哪个国家未接率最高。
|
||||
- 高峰时段客服是否不足。
|
||||
- 是否需要调整排班或回拨时间。
|
||||
- 客服效率和转化。
|
||||
|
||||
### 流程
|
||||
|
||||
```text
|
||||
生成电话名单
|
||||
-> 匹配国家/语言/时段/客服排班
|
||||
-> 拨打或回拨
|
||||
-> 记录通话结果
|
||||
-> 如有订单/评价意向则进入客服转化
|
||||
-> 如有投诉/售后则进入工单
|
||||
-> 如有KOC/KOL意向则转线索池
|
||||
```
|
||||
|
||||
### 阶段
|
||||
|
||||
V1预留，客服和Phone结合较强时进入V1必做。
|
||||
|
||||
## 分支五：客服承接
|
||||
|
||||
### 入口
|
||||
|
||||
- 用户通过App/Email/IM/Phone发送消息。
|
||||
- 用户提交信息不完整。
|
||||
- 渠道推送带来咨询、投诉或售后问题。
|
||||
- 测评/回评/返款异常。
|
||||
- 用户答应配合后需要跟进。
|
||||
|
||||
### 流程
|
||||
|
||||
```text
|
||||
用户消息进入
|
||||
-> 系统生成待处理工单
|
||||
-> 自动或手动分配客服
|
||||
-> 客服查看上下文卡
|
||||
-> 客服回复和补全信息
|
||||
-> 登记订单/催评/上传结果/升级异常
|
||||
-> 工单解决或关闭
|
||||
-> 回复、转化、满意度、目标数据回流
|
||||
```
|
||||
|
||||
### 客服转化流程
|
||||
|
||||
```text
|
||||
客服沟通用户
|
||||
-> 用户下单或提供订单号
|
||||
-> 客服登记订单
|
||||
-> 后续拿到用户评价
|
||||
-> 上传评价结果
|
||||
-> 返款/核验
|
||||
-> 完成转化
|
||||
```
|
||||
|
||||
### 管理流程
|
||||
|
||||
```text
|
||||
排班
|
||||
-> 出勤
|
||||
-> 工单分配
|
||||
-> 回复统计
|
||||
-> RSO/RDO转化统计
|
||||
-> 月目标管理
|
||||
-> 绩效复盘
|
||||
```
|
||||
|
||||
### 阶段
|
||||
|
||||
V1必做。
|
||||
|
||||
## 分支六：评价型订单与免评执行
|
||||
|
||||
### 6A 评价型订单：测评/回评
|
||||
|
||||
```text
|
||||
计划分配人群
|
||||
-> 生成订单或等待用户提交订单
|
||||
-> 核验订单号
|
||||
-> 绑定产品/ASIN/店铺/站点
|
||||
-> 上传回评/评论链接/截图
|
||||
-> 展示核验
|
||||
-> 返款/请款
|
||||
-> 完成或异常关闭
|
||||
```
|
||||
|
||||
#### 关键规则
|
||||
|
||||
- 非公司产品阻断。
|
||||
- 订单撤销或退款阻断。
|
||||
- 用户提交评价不等于Amazon展示确认。
|
||||
- 提交评价立即计入真实人累计提交额度；展示确认才计入评价型计划完成。
|
||||
- 更换订单、更改订单、转免评、撤销必须有日志。
|
||||
|
||||
### 6B 免评执行：KOC/KOL为主，IM/EDM/APP协同
|
||||
|
||||
```text
|
||||
免评计划批准
|
||||
-> 拆解KOC/KOL任务、免评Code、内容协同任务
|
||||
-> 匹配KOC/KOL、长期测评人或站外流量资源
|
||||
-> 发布内容、分发Code、同步IM/EDM/APP协同触达
|
||||
-> 回收点击、Code使用、订单、内容互动、权重结果
|
||||
-> 形成免评结果快照
|
||||
-> 达标关闭或调整KOC/素材/Code/渠道策略
|
||||
```
|
||||
|
||||
#### 关键规则
|
||||
|
||||
- 免评执行不以“用户提交评价”为终点，也不以 Amazon 展示评价作为完成口径。
|
||||
- 免评结果应写入 `exemption_plan_tasks`、`creator_content_records`、`exemption_result_snapshots` 等对象。
|
||||
- KOC/KOL任务、长期测评人免评补单、IM/EDM/APP协同触达可以服务同一个免评计划，但必须分别记录任务来源和结果口径。
|
||||
- 免评Code、点击、订单、内容链接、带货归因和权重结果需要单独复盘，不混入测评/回评订单完成数。
|
||||
|
||||
### 阶段
|
||||
|
||||
6A V1必做；6B 的免评补单与协同入口 V1必做，完整内容/归因/佣金闭环 V2实现。
|
||||
|
||||
## 分支七：财务返款
|
||||
|
||||
### 用户返款
|
||||
|
||||
```text
|
||||
返款条件满足
|
||||
-> 发起请款
|
||||
-> 财务/审核确认
|
||||
-> 付款或礼品卡
|
||||
-> 凭证/卡密通知用户
|
||||
-> 返款状态回写订单和工单
|
||||
```
|
||||
|
||||
### KOC/KOL佣金
|
||||
|
||||
```text
|
||||
带货订单归因
|
||||
-> 计算佣金
|
||||
-> 审核
|
||||
-> 结算
|
||||
-> 争议处理
|
||||
-> 复盘表现
|
||||
```
|
||||
|
||||
### 阶段
|
||||
|
||||
用户返款 V1必做；KOC/KOL佣金 V1预留，V2实现。
|
||||
|
||||
## 分支八：KOC/KOL协作
|
||||
|
||||
### 入口
|
||||
|
||||
- 新增KOC/KOL线索。
|
||||
- KOC每日工作流发现可合作用户。
|
||||
- 免评计划需要长期测评人或达人补单。
|
||||
- 商家/产品需要内容或带货合作。
|
||||
|
||||
### 流程
|
||||
|
||||
```text
|
||||
线索进入
|
||||
-> 账号/标签/风险状态检查
|
||||
-> 自动打标与人工修正
|
||||
-> 分层：新手KOC/稳定测评者/垂直专家/带货型KOL/品牌合作型
|
||||
-> 匹配产品/样品/免评/内容/带货任务
|
||||
-> 达人接受或拒绝
|
||||
-> 样品/订单/内容执行
|
||||
-> 上传内容链接或带货链接
|
||||
-> 审核、发布、归因
|
||||
-> 佣金/返款
|
||||
-> 风险与复盘
|
||||
```
|
||||
|
||||
### 必须区分
|
||||
|
||||
- KOC/KOL身份和普通测评人身份可能重叠，但业务对象不同。
|
||||
- KOC/KOL标签、带货、测评、免评标签不能混。
|
||||
- KOC/KOL内容任务和普通回评/测评订单不能混用完成口径。
|
||||
|
||||
### 阶段
|
||||
|
||||
需求完整性必须覆盖；V1预留核心入口与字段，免评补单相关 V1必做，完整内容/佣金 V2实现。
|
||||
|
||||
## 分支九：风险与黑名单
|
||||
|
||||
### 流程
|
||||
|
||||
```text
|
||||
风险信号产生
|
||||
-> 判断弱风险/强风险
|
||||
-> 弱风险提醒人工确认
|
||||
-> 强风险阻断执行
|
||||
-> 人工复核
|
||||
-> 解除/确认风险
|
||||
-> 同步黑名单或恢复执行
|
||||
```
|
||||
|
||||
### 风险来源
|
||||
|
||||
- 黑名单命中。
|
||||
- 邮箱/电话/设备/IP/Profile/地址强弱关联。
|
||||
- 退款/取消订单。
|
||||
- 双重退款。
|
||||
- 多账号/多Profile异常。
|
||||
- 重复订单、重复评论、重复返款。
|
||||
- 差评/掉评异常。
|
||||
- KOC/KOL内容违规、佣金争议、带货归因异常。
|
||||
|
||||
### 阶段
|
||||
|
||||
V1必做。
|
||||
|
||||
## Gate 1 - 分支流程完成条件
|
||||
|
||||
- 所有核心分支都有触发、执行、写入、关闭条件。
|
||||
- 客服与KOC/KOL均作为完整需求域出现。
|
||||
- 分支结果能回流主流程和复盘。
|
||||
- 各分支有 V1必做、V1预留、V2实现边界。
|
||||
@@ -0,0 +1,138 @@
|
||||
# USER ERP 0-1需求重构 - 05 异常流程_完整需求域 v1
|
||||
|
||||
## 文件信息
|
||||
|
||||
- 文件名称：`20260527_USER_ERP_0-1需求重构_05_异常流程_完整需求域_v1.md`
|
||||
- 项目路径：`C:\XCODE\USER`
|
||||
- 输出位置：`C:\XCODE\USER\output\docs`
|
||||
- 当前版本：`v1`
|
||||
- 最近更新：`2026-05-27`
|
||||
- 所属阶段：Stage 1 完整业务需求
|
||||
- 负责人：业务负责人 / 风险负责人 / 客服主管
|
||||
- 核心参与：USER运营、渠道运营、客服、KOC/KOL运营、财务、风险、测试
|
||||
- 文件目的：定义完整需求域中的异常、拦截、提醒、升级、人工复核和恢复机制，为 Stage 2 测试用例和状态机做输入。
|
||||
|
||||
## 异常分级
|
||||
|
||||
| 等级 | 含义 | 处理要求 |
|
||||
| --- | --- | --- |
|
||||
| P0 | 直接影响今日核心目标、资金、合规或账号安全 | 当天处理，主管可见 |
|
||||
| P1 | 影响本周目标或大量用户体验 | 24小时内处理 |
|
||||
| P2 | 局部异常，可进入跟进列表 | 按责任人处理 |
|
||||
| P3 | 观察项，暂不阻断 | 持续监控 |
|
||||
|
||||
## 01 需求与执行计划不匹配
|
||||
|
||||
| 异常 | 自动发现 | 处理 | 关闭条件 | 阶段 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 需求目标高于可用人群/额度 | 计划生成时匹配不足 | 提醒运营降低目标、拆分周期、转免评或补充渠道 | 目标调整或资源补足 | V1必做 |
|
||||
| 产品禁用但计划仍在执行 | 产品状态变化 | 自动暂停计划和下架H5/卡片，通知负责人 | 产品恢复或计划关闭 | V1必做 |
|
||||
| 库存不足但继续推测评/免评 | 库存低于安全线 | 限制节奏或暂停，通知运营 | 库存恢复或调整计划 | V1必做 |
|
||||
| ASIN/店铺/关键词变化未同步 | ASIN信息与计划不一致 | 阻断新推送，生成H5/卡片维护任务 | 链接和卡片确认有效 | V1必做 |
|
||||
| 计划有名额但渠道无可推人群 | 人群生成结果为空或不足 | 提醒补充人群、换渠道、延长周期 | 匹配成功或关闭计划 | V1必做 |
|
||||
| 渠道有响应但客服容量不足 | 工单/回复超时、在线人数不足 | 暂停或降频推送，调整排班 | 客服容量恢复 | V1必做 |
|
||||
| 需求变更后旧计划未暂停 | 同需求存在多个冲突计划 | 提醒主管确认，自动标记冲突 | 旧计划暂停/合并/关闭 | V1预留 |
|
||||
| 完成数口径不一致 | 计划完成、订单完成、评价展示不一致 | 进入口径复核 | 口径修正并记录 | V1必做 |
|
||||
|
||||
## 02 评价/订单异常
|
||||
|
||||
| 异常 | 自动发现 | 处理 | 关闭条件 | 阶段 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 订单号格式错误 | 用户提交时校验 | 提示用户重填，必要时转客服 | 正确订单号提交 | V1必做 |
|
||||
| 非公司产品 | 订单核验 | 阻断登记，转客服说明 | 工单关闭或人工改判 | V1必做 |
|
||||
| 店铺下错 | 订单店铺与计划不一致 | 转人工处理，可转免评 | 订单状态修正 | V1必做 |
|
||||
| 订单已取消 | Amazon状态 | 阻断回评和返款 | 用户换单或关闭 | V1必做 |
|
||||
| 订单已退款 | Amazon退款命中 | 进入退款比对和风险 | 风险结论完成 | V1必做 |
|
||||
| 评论重复绑定 | 评论ID/链接已绑定 | 阻断或申请例外审核 | 绑定唯一或审核通过 | V1必做 |
|
||||
| 订单重复绑定 | 订单号已绑定其他单 | 阻断，进入人工复核 | 确认归属 | V1必做 |
|
||||
| 用户只提交部分信息 | 缺返款账号/截图/链接 | 自动打标，生成客服跟进 | 信息补齐或关闭 | V1必做 |
|
||||
| 评论未展示 | Amazon展示核验失败 | 标记未展示，计划不计完成 | 后续展示或关闭 | V1必做 |
|
||||
| 掉评/差评 | Review状态变化 | 触发回评/紧急催评/风险 | 计划调整或风险关闭 | V1必做 |
|
||||
|
||||
## 03 返款/佣金异常
|
||||
|
||||
| 异常 | 自动发现 | 处理 | 关闭条件 | 阶段 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 缺返款账号 | 用户提交不完整 | 自动打标待返款，客服跟进 | 账号补齐 | V1必做 |
|
||||
| 返款账号格式异常 | 表单校验/人工审核 | 退回补充 | 格式正确 | V1必做 |
|
||||
| 重复请款 | 同订单/同返款ID重复 | 阻断并提醒财务 | 去重完成 | V1必做 |
|
||||
| 双重退款 | Amazon退款+OA返款命中 | 生成风险事件 | 风险确认或解除 | V1必做 |
|
||||
| 非APP用户邮件退款 | 邮件退款链路缺设备/注册邮箱维度 | 标记风险盲区，补充邮箱、订单、地址、收款信息等识别线索 | 识别维度补齐或人工复核完成 | V1必做 |
|
||||
| 返款超额 | 金额超过规则 | 进入超额审核 | 审核通过/拒绝 | V1必做 |
|
||||
| 卡密/凭证缺失 | 返款成功但无凭证 | 生成财务待补任务 | 凭证补齐 | V1预留 |
|
||||
| KOC/KOL佣金争议 | 达人反馈或金额不一致 | 进入佣金复核 | 结算修正或驳回 | V2实现 |
|
||||
|
||||
## 04 客服异常
|
||||
|
||||
| 异常 | 自动发现 | 处理 | 关闭条件 | 阶段 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 无客服在线 | 在线人数为0但有待处理工单 | 提醒主管，暂停部分推送 | 有客服承接 | V1必做 |
|
||||
| 工单未分配 | 待分配超时 | 自动分配或主管手动分配 | 工单有处理人 | V1必做 |
|
||||
| 首次回复超时 | 首次回复时长超过阈值 | 提醒客服/主管 | 已回复或转移 | V1必做 |
|
||||
| 等待用户超时 | 用户长时间未回复 | 自动提醒或关闭 | 用户回复/关闭 | V1必做 |
|
||||
| 客服转移失败 | 目标客服离线或超负荷 | 重新选择处理人 | 转移成功 | V1必做 |
|
||||
| 排班不足 | 高峰工单大于客服容量 | 主管调整排班或降频推送 | 容量恢复 | V1必做 |
|
||||
| 目标异常 | 月目标明显低于进度 | 提醒主管调度 | 目标追平或调整 | V1必做 |
|
||||
| 客服误登记订单 | 人工发现或订单核验失败 | 更改订单并留痕 | 订单修正 | V1必做 |
|
||||
| 用户投诉客服 | 投诉/负反馈 | 升级主管复核 | 处理结论 | V1预留 |
|
||||
|
||||
## 05 渠道异常
|
||||
|
||||
| 异常 | 自动发现 | 处理 | 关闭条件 | 阶段 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| IM点击低 | 漏斗低于阈值 | 换素材/卡片/人群 | 指标恢复或复盘 | V1必做 |
|
||||
| IM回复低于3% | 日常监控 | 更换图片/话术 | 回复率恢复 | V1必做 |
|
||||
| 退订或不感兴趣升高 | 退订/投诉异常 | 降频、暂停素材、调整人群 | 指标恢复 | V1必做 |
|
||||
| EDM域名/IP信誉异常 | 每日检查 | 暂停发送、切换账号、通知负责人 | 信誉恢复 | V1必做 |
|
||||
| KV/UID人群导出失败 | 人群数量异常 | 暂停推送，重跑导出 | 人群正常 | V1必做 |
|
||||
| H5链接失效 | 链接检测或用户反馈 | 下架任务，修复链接 | 链接有效 | V1必做 |
|
||||
| 卡片产品禁用未同步 | 产品状态变更 | 自动下架卡片 | 卡片状态正确 | V1必做 |
|
||||
| Phone未接率过高 | 电话数据 | 调整时段/排班/回拨 | 未接率下降 | V1预留 |
|
||||
|
||||
## 06 KOC/KOL异常
|
||||
|
||||
| 异常 | 自动发现 | 处理 | 关闭条件 | 阶段 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| KOC标签混乱 | 同人存在KOC/测评/带货冲突 | 人工复核标签 | 标签修正 | V1预留 |
|
||||
| KOC/KOL与C类测评人身份重叠 | 同一真实人同时命中免评推送和KOC任务 | 阻断重复触达，进入身份/任务冲突复核 | 明确走免评协同或KOC任务，不重复计完成 | V1必做 |
|
||||
| 达人重复触达 | 同一KOC/KOL多任务冲突 | 合并或暂停任务 | 冲突解除 | V1预留 |
|
||||
| 样品发出未产出内容 | 任务超时 | 催办、暂停合作、风险记录 | 内容提交或任务关闭 | V2实现 |
|
||||
| 内容链接无效 | 链接检测失败 | 要求重提 | 链接有效 | V2实现 |
|
||||
| 内容不合规 | 内容审核 | 驳回、下架、降权 | 内容修正或关闭 | V2实现 |
|
||||
| 带货订单归因失败 | Code/链接无法匹配 | 进入人工归因 | 归因完成或驳回 | V2实现 |
|
||||
| 佣金争议 | 金额或订单争议 | 财务/运营复核 | 结算修正或驳回 | V2实现 |
|
||||
| 高风险KOC继续推送 | 风险状态命中 | 阻断任务 | 风险解除或拉黑 | V1预留 |
|
||||
|
||||
## 07 风险异常
|
||||
|
||||
| 异常 | 自动发现 | 处理 | 关闭条件 | 阶段 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 黑名单命中 | 身份线索命中 | 阻断触达/返款/合作 | 人工解除或保持黑名单 | V1必做 |
|
||||
| 强关联命中 | 邮箱/电话/设备/Profile/地址 | 阻断并复核 | 风险结论 | V1必做 |
|
||||
| 弱关联命中 | IP/相似地址等 | 提醒人工确认 | 确认/排除 | V1必做 |
|
||||
| 额度超限 | 月度/累计额度命中 | 阻断普通测评，转免评池 | 额度恢复或转免评 | V1必做 |
|
||||
| 多账号归并冲突 | 同一真实人下多个 JOYHUB/Profile 额度不一致 | 按 `person_quota_ledgers` 重新汇总，进入人工复核 | 额度统一并记录合并/拆分结论 | V1必做 |
|
||||
| 频控超限 | 当日/周期触达超限 | 暂停触达 | 到期恢复 | V1必做 |
|
||||
| 敏感字段导出风险 | 导出包含敏感字段 | 强制脱敏/审批 | 导出完成或拒绝 | V1必做 |
|
||||
|
||||
## 异常处理通用状态
|
||||
|
||||
```text
|
||||
待发现 -> 已发现 -> 待处理 -> 处理中 -> 待复核 -> 已关闭
|
||||
```
|
||||
|
||||
可选状态：
|
||||
|
||||
- 已升级。
|
||||
- 已驳回。
|
||||
- 已阻断。
|
||||
- 已恢复。
|
||||
- 需补充信息。
|
||||
- 需跨部门协同。
|
||||
|
||||
## Gate 1 - 异常流程完成条件
|
||||
|
||||
- 需求计划、评价订单、客服、渠道、KOC/KOL、返款、风险异常均覆盖。
|
||||
- 每类异常有发现方式、处理动作、关闭条件。
|
||||
- P0/P1/P2/P3等级可用于今日作战台。
|
||||
- 异常能回流计划调整、客服任务、风险事件和复盘记录。
|
||||
@@ -0,0 +1,209 @@
|
||||
# USER ERP 0-1需求重构 - 06 VibeCoding页面验证记录 v1
|
||||
|
||||
## 文件信息
|
||||
|
||||
- 文件名称：`20260527_USER_ERP_0-1需求重构_06_VibeCoding页面验证记录_v1.md`
|
||||
- 项目路径：`C:\XCODE\USER`
|
||||
- 输出位置：`C:\XCODE\USER\output\docs`
|
||||
- 当前版本：`v1`
|
||||
- 最近更新：`2026-05-27`
|
||||
- 所属阶段：Stage 1 完整业务需求
|
||||
- 负责人：产品负责人 / 前端观察员
|
||||
- 核心参与：业务负责人、USER运营、客服主管、渠道负责人、KOC/KOL负责人、技术负责人
|
||||
- 文件目的：把现有 Vibe Coding / AI 原型作为需求验证材料，记录已覆盖能力、暴露缺口和 Stage 2 高保真模型输入。
|
||||
|
||||
## 验证原则
|
||||
|
||||
1. 原型不是生产代码，不作为正式系统底座。
|
||||
2. 原型用于发现页面、字段、按钮、状态和流程缺口。
|
||||
3. 验证重点不是“页面能不能打开”，而是“需求是否完整、业务对象是否统一、每日操作是否可执行”。
|
||||
4. 阶段1必须记录原型未覆盖的需求域，特别是 KOC/KOL、客服管理、需求计划匹配和复盘口径。
|
||||
|
||||
## 验证材料
|
||||
|
||||
| 材料 | 用途 | 结论 |
|
||||
| --- | --- | --- |
|
||||
| `C:\XCODE\USER\input\user-review-system` | React/Vite原型，含计划、测评人、订单、客服、渠道、风险、看板；入口参考 `src\App.tsx`、`src\config\routes.tsx`、`src\config\menu.tsx` | 覆盖面较广，可作为页面/字段参考 |
|
||||
| `C:\XCODE\USER\input\user-review-system\docs\review-order-PRD.md` | 回评/测评订单详细PRD | 订单页面细，但只是局部，不足以代表ERP主流程 |
|
||||
| `C:\XCODE\USER\input\user-review-system\docs\review-order-architecture.md` | 订单页面技术架构 | 可参考组件拆分和待确认问题 |
|
||||
| `C:\XCODE\USER\src\user_erp_mvp_admin_prototype_v10.html` | 既有 v10 HTML 原型 | 可参考早期管理端页面，但不直接复用为新系统底座 |
|
||||
| `C:\XCODE\USER\input\用户运营系统-单文件.html` | 大型单文件运营系统原型 | 可参考全局菜单和字段，但不直接复用 |
|
||||
| `C:\XCODE\USER\input\amazon_operator_test_entry.html` | 亚马逊提评入口原型 | 可参考需求提报、IM账号、推送策略 |
|
||||
| `C:\XCODE\USER\input\客服执行.html` | 客服执行/管理原型 | 客服核心需求的重要参考 |
|
||||
| `C:\XCODE\USER\input\IM 推送业务流.mm` | IM业务流脑图 | IM分层和流转最完整 |
|
||||
|
||||
## user-review-system 验证
|
||||
|
||||
### 已覆盖能力
|
||||
|
||||
| 模块 | 已覆盖 |
|
||||
| --- | --- |
|
||||
| 菜单/路由 | 工作台、评价计划、评价人管理、测评订单、回评订单、客服中心、渠道推送、风险中心、数据看板 |
|
||||
| 计划 | 测评计划、回评计划、免评计划，含列表、表单、详情、关联推送/订单 |
|
||||
| 测评人 | 测评人列表、详情、表单、额度、订单、风险、联系记录 |
|
||||
| 订单 | 测评订单、回评订单、上传订单、上传回评、请款、返款、详情抽屉 |
|
||||
| 客服 | 工单池、聊天、聊天记录、答应配合、客服绩效看板 |
|
||||
| 渠道 | 推送任务、IM推送、IM卡片、IM/EDM配置 |
|
||||
| 风险 | 风险事件、黑名单、退款比对 |
|
||||
| 看板 | 计划、ASIN、客服绩效 |
|
||||
|
||||
### 暴露的缺口
|
||||
|
||||
| 缺口 | 影响 | 后续处理 |
|
||||
| --- | --- | --- |
|
||||
| 需求池与计划生成链路弱 | 无法解释需求如何变成计划 | Stage 2 需新增需求与计划调度中心 |
|
||||
| 计划匹配资源视图不足 | 人群、客服、渠道、H5/卡片、风险没有统一调度 | 需新增执行匹配看板 |
|
||||
| 客服管理不完整 | 排班、出勤、目标、首次回复、转化绩效不足 | 结合客服执行原型补齐 |
|
||||
| KOC/KOL需求域不足 | 线索、任务、内容、带货、佣金缺失 | 阶段1必须补出完整需求 |
|
||||
| 订单PRD局部过细 | 容易用订单页面替代ERP主流程 | 保留为订单模块参考 |
|
||||
| 状态枚举不统一 | 测评、回评、返款、计划、客服状态口径混乱 | Stage 2需统一状态机 |
|
||||
| Mock 数据含临时品类 | 部分示例与真实业务不一致 | 只取字段结构，不取业务事实 |
|
||||
|
||||
## 用户运营系统单文件验证
|
||||
|
||||
### 已覆盖
|
||||
|
||||
- USER评价业务闭环系统的全局菜单雏形。
|
||||
- 产品、计划、订单、客服、风险、真实人、用户信息等多类字段。
|
||||
- 较多运营筛选、状态、详情、操作入口。
|
||||
|
||||
### 缺口
|
||||
|
||||
- 文件过大，页面和数据逻辑混杂，不适合做正式底座。
|
||||
- 未清晰区分需求完整范围和V1实现范围。
|
||||
- KOC/KOL相关需求不完整。
|
||||
- 客服核心执行与管理需要与 `客服执行.html` 合并分析。
|
||||
- 需求到计划再到执行匹配的调度视图不足。
|
||||
|
||||
## amazon_operator_test_entry 验证
|
||||
|
||||
### 已覆盖
|
||||
|
||||
- 亚马逊提评入口。
|
||||
- 提评单列表。
|
||||
- IM推送。
|
||||
- IM账号管理。
|
||||
- 新建提评单。
|
||||
- 推送策略。
|
||||
- 卡片内容管理。
|
||||
- 业务类型：测评、免评、回评。
|
||||
|
||||
### 可纳入需求
|
||||
|
||||
- 提评需求提报字段：站点、ASIN、商品、关键词、关键词链接、品牌、新品状态、要求数量、店铺、原因、备注。
|
||||
- IM账号和身份管理：官方客服、品牌客服、达人、内部/外部品牌。
|
||||
- 推送策略：用户标签、去除标签、优先级、间隔时间、内容形式、跳转链接。
|
||||
|
||||
### 缺口
|
||||
|
||||
- 未打通完整需求池和计划对象。
|
||||
- 提评入口与USER运营调度中心的关系需重构。
|
||||
- IM账号管理需与渠道配置、权限和风险联动。
|
||||
|
||||
## 客服执行原型验证
|
||||
|
||||
### 已覆盖
|
||||
|
||||
- 客服执行看板。
|
||||
- 首页Dashboard。
|
||||
- 出勤管理。
|
||||
- 排班管理。
|
||||
- 工单管理。
|
||||
- 回复统计。
|
||||
- 转化绩效。
|
||||
- 目标管理。
|
||||
- 角色权限：客服与主管/管理员视角。
|
||||
|
||||
### 可纳入需求
|
||||
|
||||
| 能力 | 说明 |
|
||||
| --- | --- |
|
||||
| 工单自动分配 | 在线优先、按工单量平均、最大工单数 |
|
||||
| 客服视角 | 只看自己工单、绩效和目标 |
|
||||
| 主管视角 | 查看团队数据、调整工单、排班和目标 |
|
||||
| 绩效统计 | RSO/RDO登记订单、上评、完成率 |
|
||||
| 出勤/排班 | 早班、午班、晚班、迟到、早退、请假、缺勤 |
|
||||
|
||||
### 缺口
|
||||
|
||||
- 与评价计划、渠道推送和订单履约的联动需要补强。
|
||||
- 客服容量尚未进入需求与计划匹配。
|
||||
- 客服误登记、投诉、转移失败、排班不足等异常需要补全。
|
||||
|
||||
## IM推送业务流验证
|
||||
|
||||
### 已覆盖
|
||||
|
||||
- 用户分层：未参与、参与过、长期测评人。
|
||||
- 推送前风控校验。
|
||||
- 回评卡片、测评卡片、免评产品、催评消息。
|
||||
- 用户提交订单号、返款账号、评论截图/链接。
|
||||
- 订单号核实和客服补全。
|
||||
- 财务返款提醒。
|
||||
- 自动打标体系。
|
||||
- 店铺紧急催评。
|
||||
|
||||
### 可直接作为Stage 2输入
|
||||
|
||||
- IM用户分层。
|
||||
- 核心标签体系。
|
||||
- 每次互动复检。
|
||||
- 未完成流程的标签与自动通知。
|
||||
- 长期测评人转免评策略。
|
||||
|
||||
### 缺口
|
||||
|
||||
- IM流程需要与统一计划、额度台账、客服工单和风险事件对象对齐。
|
||||
- 文档中提到的“当天测评计划需要刷的名额”需要接入计划匹配。
|
||||
|
||||
## KOC/KOL需求验证
|
||||
|
||||
### 已有线索
|
||||
|
||||
- `KOC 每日工作流.md` 提到账号、标签、风险、新增线索、用户分层、自动打标、任务去重、回复、订单、返款、Review、带货、风险。
|
||||
- `商家KOL商业服务系统-USER项目知识迁移清单.md` 提供服务包、KOC/KOL分层、佣金原则、内容分级和推荐分发接口意识。
|
||||
- 现有原型仅零散覆盖KOC/KOL，未形成完整中心。
|
||||
|
||||
### 阶段1必须补出的需求
|
||||
|
||||
- KOC/KOL线索池。
|
||||
- KOC/KOL档案和分层。
|
||||
- KOC/KOL与测评人/真实人的身份关系。
|
||||
- 内容任务、样品/免评、带货任务。
|
||||
- 内容审核、链接、Code、订单归因。
|
||||
- 佣金计算与结算接口。
|
||||
- KOC/KOL风险和异常。
|
||||
|
||||
### 阶段建议
|
||||
|
||||
- V1必做：免评补单相关的KOC/KOL入口、标签、风险和任务关联。
|
||||
- V1预留：KOC/KOL档案、线索池、合作状态。
|
||||
- V2实现：内容审核、带货归因、佣金结算、商家服务包完整后台。
|
||||
|
||||
## 进入Stage 2的输入清单
|
||||
|
||||
| 输入 | 说明 |
|
||||
| --- | --- |
|
||||
| 需求与计划调度中心 | 需要新设计，不应从现有订单页面改 |
|
||||
| 今日作战台 | 需要按OKR和岗位每日工作方式设计 |
|
||||
| 客服执行/管理 | 可综合 `客服相关模块.md` 和 `客服执行.html` |
|
||||
| IM推送 | 可基于 `IM 推送业务流.mm` 和 user-review-system IM页面 |
|
||||
| 订单页面 | 可参考 review-order PRD，但需合并测评/回评/免评口径 |
|
||||
| 测评人/真实人 | 可参考 `测评信息字段管理.xlsx` 和数据对象v3 |
|
||||
| KOC/KOL中心 | 现有原型不足，需要新建需求模型 |
|
||||
| 风险中心 | 可参考现有风险页面，但需扩展KOC/KOL与计划匹配异常 |
|
||||
|
||||
## 不能直接继承的内容
|
||||
|
||||
- 不能直接继承 Vibe Coding 的文件结构作为正式工程结构。
|
||||
- 不能把 mock 数据当业务事实。
|
||||
- 不能把回评/测评订单PRD当成整个 ERP PRD。
|
||||
- 不能因为 V1不实现完整KOC/KOL平台，就在阶段1删除KOC/KOL需求。
|
||||
- 不能把客服降级为“工单页面”，客服是核心执行和转化资源。
|
||||
|
||||
## Gate 1 - Vibe Coding验证完成条件
|
||||
|
||||
- 已记录所有原型的可用需求点。
|
||||
- 已记录原型不能支撑的业务缺口。
|
||||
- 已确认正式系统需要重新做 Stage 2 高保真模型。
|
||||
- 已确认KOC/KOL、客服、需求计划匹配是现有原型的主要补强方向。
|
||||
@@ -0,0 +1,209 @@
|
||||
# USER ERP 0-1需求重构 - 06 VibeCoding页面验证记录 v1
|
||||
|
||||
## 文件信息
|
||||
|
||||
- 文件名称：`20260527_USER_ERP_0-1需求重构_06_VibeCoding页面验证记录_v1.md`
|
||||
- 项目路径：`C:\XCODE\USER`
|
||||
- 输出位置：`C:\XCODE\USER\output\docs`
|
||||
- 当前版本：`v1`
|
||||
- 最近更新：`2026-05-27`
|
||||
- 所属阶段：Stage 1 完整业务需求
|
||||
- 负责人：产品负责人 / 前端观察员
|
||||
- 核心参与：业务负责人、USER运营、客服主管、渠道负责人、KOC/KOL负责人、技术负责人
|
||||
- 文件目的：把现有 Vibe Coding / AI 原型作为需求验证材料，记录已覆盖能力、暴露缺口和 Stage 2 高保真模型输入。
|
||||
|
||||
## 验证原则
|
||||
|
||||
1. 原型不是生产代码，不作为正式系统底座。
|
||||
2. 原型用于发现页面、字段、按钮、状态和流程缺口。
|
||||
3. 验证重点不是“页面能不能打开”，而是“需求是否完整、业务对象是否统一、每日操作是否可执行”。
|
||||
4. 阶段1必须记录原型未覆盖的需求域，特别是 KOC/KOL、客服管理、需求计划匹配和复盘口径。
|
||||
|
||||
## 验证材料
|
||||
|
||||
| 材料 | 用途 | 结论 |
|
||||
| --- | --- | --- |
|
||||
| `C:\XCODE\USER\input\user-review-system` | React/Vite原型，含计划、测评人、订单、客服、渠道、风险、看板；入口参考 `src\App.tsx`、`src\config\routes.tsx`、`src\config\menu.tsx` | 覆盖面较广，可作为页面/字段参考 |
|
||||
| `C:\XCODE\USER\input\user-review-system\docs\review-order-PRD.md` | 回评/测评订单详细PRD | 订单页面细，但只是局部，不足以代表ERP主流程 |
|
||||
| `C:\XCODE\USER\input\user-review-system\docs\review-order-architecture.md` | 订单页面技术架构 | 可参考组件拆分和待确认问题 |
|
||||
| `C:\XCODE\USER\src\user_erp_mvp_admin_prototype_v10.html` | 既有 v10 HTML 原型 | 可参考早期管理端页面，但不直接复用为新系统底座 |
|
||||
| `C:\XCODE\USER\input\用户运营系统-单文件.html` | 大型单文件运营系统原型 | 可参考全局菜单和字段，但不直接复用 |
|
||||
| `C:\XCODE\USER\input\amazon_operator_test_entry.html` | 亚马逊提评入口原型 | 可参考需求提报、IM账号、推送策略 |
|
||||
| `C:\XCODE\USER\input\客服执行.html` | 客服执行/管理原型 | 客服核心需求的重要参考 |
|
||||
| `C:\XCODE\USER\input\IM 推送业务流.mm` | IM业务流脑图 | IM分层和流转最完整 |
|
||||
|
||||
## user-review-system 验证
|
||||
|
||||
### 已覆盖能力
|
||||
|
||||
| 模块 | 已覆盖 |
|
||||
| --- | --- |
|
||||
| 菜单/路由 | 工作台、评价计划、评价人管理、测评订单、回评订单、客服中心、渠道推送、风险中心、数据看板 |
|
||||
| 计划 | 测评计划、回评计划、免评计划，含列表、表单、详情、关联推送/订单 |
|
||||
| 测评人 | 测评人列表、详情、表单、额度、订单、风险、联系记录 |
|
||||
| 订单 | 测评订单、回评订单、上传订单、上传回评、请款、返款、详情抽屉 |
|
||||
| 客服 | 工单池、聊天、聊天记录、答应配合、客服绩效看板 |
|
||||
| 渠道 | 推送任务、IM推送、IM卡片、IM/EDM配置 |
|
||||
| 风险 | 风险事件、黑名单、退款比对 |
|
||||
| 看板 | 计划、ASIN、客服绩效 |
|
||||
|
||||
### 暴露的缺口
|
||||
|
||||
| 缺口 | 影响 | 后续处理 |
|
||||
| --- | --- | --- |
|
||||
| 需求池与计划生成链路弱 | 无法解释需求如何变成计划 | Stage 2 需新增需求与计划调度中心 |
|
||||
| 计划匹配资源视图不足 | 人群、客服、渠道、H5/卡片、风险没有统一调度 | 需新增执行匹配看板 |
|
||||
| 客服管理不完整 | 排班、出勤、目标、首次回复、转化绩效不足 | 结合客服执行原型补齐 |
|
||||
| KOC/KOL需求域不足 | 线索、任务、内容、带货、佣金缺失 | 阶段1必须补出完整需求 |
|
||||
| 订单PRD局部过细 | 容易用订单页面替代ERP主流程 | 保留为订单模块参考 |
|
||||
| 状态枚举不统一 | 测评、回评、返款、计划、客服状态口径混乱 | Stage 2需统一状态机 |
|
||||
| Mock 数据含临时品类 | 部分示例与真实业务不一致 | 只取字段结构，不取业务事实 |
|
||||
|
||||
## 用户运营系统单文件验证
|
||||
|
||||
### 已覆盖
|
||||
|
||||
- USER评价业务闭环系统的全局菜单雏形。
|
||||
- 产品、计划、订单、客服、风险、真实人、用户信息等多类字段。
|
||||
- 较多运营筛选、状态、详情、操作入口。
|
||||
|
||||
### 缺口
|
||||
|
||||
- 文件过大，页面和数据逻辑混杂，不适合做正式底座。
|
||||
- 未清晰区分需求完整范围和V1实现范围。
|
||||
- KOC/KOL相关需求不完整。
|
||||
- 客服核心执行与管理需要与 `客服执行.html` 合并分析。
|
||||
- 需求到计划再到执行匹配的调度视图不足。
|
||||
|
||||
## amazon_operator_test_entry 验证
|
||||
|
||||
### 已覆盖
|
||||
|
||||
- 亚马逊提评入口。
|
||||
- 提评单列表。
|
||||
- IM推送。
|
||||
- IM账号管理。
|
||||
- 新建提评单。
|
||||
- 推送策略。
|
||||
- 卡片内容管理。
|
||||
- 业务类型：测评、免评、回评。
|
||||
|
||||
### 可纳入需求
|
||||
|
||||
- 提评需求提报字段：站点、ASIN、商品、关键词、关键词链接、品牌、新品状态、要求数量、店铺、原因、备注。
|
||||
- IM账号和身份管理：官方客服、品牌客服、达人、内部/外部品牌。
|
||||
- 推送策略：用户标签、去除标签、优先级、间隔时间、内容形式、跳转链接。
|
||||
|
||||
### 缺口
|
||||
|
||||
- 未打通完整需求池和计划对象。
|
||||
- 提评入口与USER运营调度中心的关系需重构。
|
||||
- IM账号管理需与渠道配置、权限和风险联动。
|
||||
|
||||
## 客服执行原型验证
|
||||
|
||||
### 已覆盖
|
||||
|
||||
- 客服执行看板。
|
||||
- 首页Dashboard。
|
||||
- 出勤管理。
|
||||
- 排班管理。
|
||||
- 工单管理。
|
||||
- 回复统计。
|
||||
- 转化绩效。
|
||||
- 目标管理。
|
||||
- 角色权限：客服与主管/管理员视角。
|
||||
|
||||
### 可纳入需求
|
||||
|
||||
| 能力 | 说明 |
|
||||
| --- | --- |
|
||||
| 工单自动分配 | 在线优先、按工单量平均、最大工单数 |
|
||||
| 客服视角 | 只看自己工单、绩效和目标 |
|
||||
| 主管视角 | 查看团队数据、调整工单、排班和目标 |
|
||||
| 绩效统计 | RSO/RDO登记订单、上评、完成率 |
|
||||
| 出勤/排班 | 早班、午班、晚班、迟到、早退、请假、缺勤 |
|
||||
|
||||
### 缺口
|
||||
|
||||
- 与评价计划、渠道推送和订单履约的联动需要补强。
|
||||
- 客服容量尚未进入需求与计划匹配。
|
||||
- 客服误登记、投诉、转移失败、排班不足等异常需要补全。
|
||||
|
||||
## IM推送业务流验证
|
||||
|
||||
### 已覆盖
|
||||
|
||||
- 用户分层：未参与、参与过、长期测评人。
|
||||
- 推送前风控校验。
|
||||
- 回评卡片、测评卡片、免评产品、催评消息。
|
||||
- 用户提交订单号、返款账号、评论截图/链接。
|
||||
- 订单号核实和客服补全。
|
||||
- 财务返款提醒。
|
||||
- 自动打标体系。
|
||||
- 店铺紧急催评。
|
||||
|
||||
### 可直接作为Stage 2输入
|
||||
|
||||
- IM用户分层。
|
||||
- 核心标签体系。
|
||||
- 每次互动复检。
|
||||
- 未完成流程的标签与自动通知。
|
||||
- 长期测评人转免评策略。
|
||||
|
||||
### 缺口
|
||||
|
||||
- IM流程需要与统一计划、额度台账、客服工单和风险事件对象对齐。
|
||||
- 文档中提到的“当天测评计划需要刷的名额”需要接入计划匹配。
|
||||
|
||||
## KOC/KOL需求验证
|
||||
|
||||
### 已有线索
|
||||
|
||||
- `KOC 每日工作流.md` 提到账号、标签、风险、新增线索、用户分层、自动打标、任务去重、回复、订单、返款、Review、带货、风险。
|
||||
- `商家KOL商业服务系统-USER项目知识迁移清单.md` 提供服务包、KOC/KOL分层、佣金原则、内容分级和推荐分发接口意识。
|
||||
- 现有原型仅零散覆盖KOC/KOL，未形成完整中心。
|
||||
|
||||
### 阶段1必须补出的需求
|
||||
|
||||
- KOC/KOL线索池。
|
||||
- KOC/KOL档案和分层。
|
||||
- KOC/KOL与测评人/真实人的身份关系。
|
||||
- 内容任务、样品/免评、带货任务。
|
||||
- 内容审核、链接、Code、订单归因。
|
||||
- 佣金计算与结算接口。
|
||||
- KOC/KOL风险和异常。
|
||||
|
||||
### 阶段建议
|
||||
|
||||
- V1必做：免评补单相关的KOC/KOL入口、标签、风险和任务关联。
|
||||
- V1预留：KOC/KOL档案、线索池、合作状态。
|
||||
- V2实现：内容审核、带货归因、佣金结算、商家服务包完整后台。
|
||||
|
||||
## 进入Stage 2的输入清单
|
||||
|
||||
| 输入 | 说明 |
|
||||
| --- | --- |
|
||||
| 需求与计划调度中心 | 需要新设计，不应从现有订单页面改 |
|
||||
| 今日作战台 | 需要按OKR和岗位每日工作方式设计 |
|
||||
| 客服执行/管理 | 可综合 `客服相关模块.md` 和 `客服执行.html` |
|
||||
| IM推送 | 可基于 `IM 推送业务流.mm` 和 user-review-system IM页面 |
|
||||
| 订单页面 | 可参考 review-order PRD，但需合并测评/回评/免评口径 |
|
||||
| 测评人/真实人 | 可参考 `测评信息字段管理.xlsx` 和数据对象v3 |
|
||||
| KOC/KOL中心 | 现有原型不足，需要新建需求模型 |
|
||||
| 风险中心 | 可参考现有风险页面，但需扩展KOC/KOL与计划匹配异常 |
|
||||
|
||||
## 不能直接继承的内容
|
||||
|
||||
- 不能直接继承 Vibe Coding 的文件结构作为正式工程结构。
|
||||
- 不能把 mock 数据当业务事实。
|
||||
- 不能把回评/测评订单PRD当成整个 ERP PRD。
|
||||
- 不能因为 V1不实现完整KOC/KOL平台，就在阶段1删除KOC/KOL需求。
|
||||
- 不能把客服降级为“工单页面”，客服是核心执行和转化资源。
|
||||
|
||||
## Gate 1 - Vibe Coding验证完成条件
|
||||
|
||||
- 已记录所有原型的可用需求点。
|
||||
- 已记录原型不能支撑的业务缺口。
|
||||
- 已确认正式系统需要重新做 Stage 2 高保真模型。
|
||||
- 已确认KOC/KOL、客服、需求计划匹配是现有原型的主要补强方向。
|
||||
1568
wishfulfilled-wiki/05_需求文档/20260528_USER_ERP_0-1需求重构_可点击参考原型_v1.html
Normal file
1568
wishfulfilled-wiki/05_需求文档/20260528_USER_ERP_0-1需求重构_可点击参考原型_v1.html
Normal file
File diff suppressed because it is too large
Load Diff
1107
wishfulfilled-wiki/05_需求文档/20260528_USER_ERP_完整参考原型_v2.html
Normal file
1107
wishfulfilled-wiki/05_需求文档/20260528_USER_ERP_完整参考原型_v2.html
Normal file
File diff suppressed because it is too large
Load Diff
398
wishfulfilled-wiki/05_需求文档/通用EDM业务流程说明.md
Normal file
398
wishfulfilled-wiki/05_需求文档/通用EDM业务流程说明.md
Normal file
@@ -0,0 +1,398 @@
|
||||
# 通用 EDM 业务流程说明
|
||||
|
||||
更新时间：2026-05-26
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本文用于新的 EDM 子系统设计或重构，目标是在功能保持一致的前提下，将现有 EDM 业务抽象成通用流程，便于后续拆分服务、设计数据模型、规划 Kafka 消费链路、接入邮件发送通道和处理邮件客服工单。
|
||||
|
||||
## 2. 业务范围
|
||||
|
||||
通用 EDM 子系统建议分为三条业务线：
|
||||
|
||||
| 业务线 | 说明 |
|
||||
| --- | --- |
|
||||
| 批量营销邮件 | 管理后台创建邮件任务，按标签、站点、产品、用户状态筛选目标用户，生成待发送邮件记录，通过队列异步发送 |
|
||||
| 自动 / 实时策略邮件 | 根据用户注册、访问、在线、站点、产品、行为、无消息等规则自动筛选用户，并生成策略邮件 |
|
||||
| 邮件工单 | 用户来信、表单提交或外部收信服务进入后台后，生成或更新邮件工单，由客服处理、回复、转发、关闭 |
|
||||
|
||||
如果新系统还需要普通邮箱功能，可以作为独立模块处理。普通邮箱收发不一定进入 EDM 工单链路，是否合并需要单独确认。
|
||||
|
||||
## 3. 总体架构
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["管理后台"] --> B["EDM 任务服务"]
|
||||
B --> C["目标用户筛选服务"]
|
||||
C --> D["邮件记录生成服务"]
|
||||
D --> E["Kafka / 队列"]
|
||||
E --> F["邮件发送消费者"]
|
||||
F --> G["外部发送通道"]
|
||||
G --> H["AWS SES / SMTP / Gmail / Microsoft"]
|
||||
H --> I["事件回调"]
|
||||
I --> J["事件处理服务"]
|
||||
J --> K["统计与黑名单"]
|
||||
|
||||
L["用户来信 / 表单提交"] --> M["入站接收服务"]
|
||||
M --> N["Kafka / 入站队列"]
|
||||
N --> O["EDM 工单服务"]
|
||||
O --> P["客服工作台"]
|
||||
P --> E
|
||||
```
|
||||
|
||||
核心组件职责：
|
||||
|
||||
| 组件 | 职责 |
|
||||
| --- | --- |
|
||||
| 管理后台 | 创建邮件任务、审核任务、查看统计、处理邮件工单 |
|
||||
| 任务服务 | 保存任务配置、正文、模板、发送时间、审核状态 |
|
||||
| 用户筛选服务 | 根据标签、站点、产品、黑名单、订阅状态、发送频率等规则筛选目标用户 |
|
||||
| 邮件记录服务 | 按用户生成单封待发送邮件记录和正文快照 |
|
||||
| Kafka / 队列 | 解耦任务生成、邮件发送、入站消息、事件统计 |
|
||||
| 发送消费者 | 消费待发送邮件，调用外部发送通道，并保存发送结果 |
|
||||
| 入站接收服务 | 接收表单、用户来信或外部邮件服务回调，写入入站队列 |
|
||||
| 工单服务 | 根据来信生成或更新邮件工单，维护状态、负责人、未读数和处理记录 |
|
||||
| 事件处理服务 | 处理送达、打开、点击、退信、投诉、拒信等邮件事件 |
|
||||
| Redis / 缓存 | 保存并发锁、游标、限流计数、近期任务统计、临时筛选集合 |
|
||||
|
||||
## 4. 核心数据模型
|
||||
|
||||
新子系统建议至少抽象以下对象：
|
||||
|
||||
| 对象 | 说明 |
|
||||
| --- | --- |
|
||||
| 邮件任务 EmailTask | 批量营销或策略邮件任务，保存任务名称、类型、发送时间、审核状态、目标条件 |
|
||||
| 邮件内容 EmailContent | 任务级正文、标题、模板、发件人、回复地址、附件配置 |
|
||||
| 目标用户 TaskRecipient | 任务命中的用户关系，便于统计和去重 |
|
||||
| 单封邮件 EmailMessage | 最终发送或接收的一封邮件记录，包含方向、收件人、发件人、状态、message_id、工单 ID |
|
||||
| 邮件正文 EmailBody | 单封邮件正文快照，避免模板后续变化影响历史邮件 |
|
||||
| 工单 EmailTicket | 用户来信或客服主动发起的一次处理过程 |
|
||||
| 分配记录 Assignment | 工单分配、移交、释放、代班等操作记录 |
|
||||
| 节点日志 NodeLog | 创建、分配、首次回复、关闭、未解决、转化中等关键节点 |
|
||||
| 发送事件 EmailEvent | 送达、打开、点击、退信、投诉、拒信、渲染失败等事件 |
|
||||
| 黑名单 / 退订名单 Suppression | 退信、投诉、退订、风险用户等不可发送或需谨慎发送的人群 |
|
||||
|
||||
## 5. 批量营销邮件流程
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["后台创建邮件任务"] --> B["校验任务配置"]
|
||||
B --> C["写入任务、内容、标签条件"]
|
||||
C --> D["进入待审核"]
|
||||
D --> E{"审核结果"}
|
||||
E -->|通过| F["进入待执行"]
|
||||
E -->|驳回| G["记录驳回原因并结束"]
|
||||
F --> H["到达发送时间"]
|
||||
H --> I["筛选目标用户"]
|
||||
I --> J["生成单封待发送邮件记录"]
|
||||
J --> K["投递 Kafka"]
|
||||
K --> L["发送消费者调用外部邮件通道"]
|
||||
L --> M["更新发送状态和 message_id"]
|
||||
```
|
||||
|
||||
创建任务时建议校验：
|
||||
|
||||
1. 任务名称不能重复。
|
||||
2. 邮件模板或正文必须存在。
|
||||
3. 发件邮箱必须存在并可用。
|
||||
4. 发件域名必须在允许范围内。
|
||||
5. 必须选择目标人群或策略条件。
|
||||
6. 发送时间必须符合业务规则。
|
||||
7. 如果绑定活动，发送时间需要满足活动时间约束。
|
||||
8. 目标人数需要预估，避免误发全量用户。
|
||||
|
||||
目标用户筛选建议包含：
|
||||
|
||||
1. 标签包含和标签排除。
|
||||
2. 站点、产品、品牌、语言、地区。
|
||||
3. 订阅状态、退订状态、黑名单、投诉用户、永久退信用户。
|
||||
4. 近期发送频率限制，避免短时间重复触达。
|
||||
5. 任务级去重，避免同一用户重复生成同一任务邮件。
|
||||
|
||||
## 6. 自动 / 实时策略邮件流程
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["策略配置"] --> B["定时任务生成当日策略任务"]
|
||||
B --> C["实时策略扫描"]
|
||||
C --> D["按用户行为和条件筛选"]
|
||||
D --> E["应用黑名单、退订、频率控制"]
|
||||
E --> F["生成待发送邮件"]
|
||||
F --> G["投递发送队列"]
|
||||
G --> H["发送消费者调用邮件通道"]
|
||||
H --> I["事件回调更新统计"]
|
||||
```
|
||||
|
||||
策略邮件与批量邮件的区别：
|
||||
|
||||
1. 批量邮件通常由运营手动创建，发送时间明确。
|
||||
2. 策略邮件通常由系统按规则自动生成，可能按分钟或按天扫描。
|
||||
3. 策略邮件更依赖幂等和频率控制，避免同一用户在同一策略下反复触发。
|
||||
4. 策略邮件应记录策略 ID、触发原因、触发时间，便于归因。
|
||||
|
||||
建议策略执行时做并发锁，避免多个任务实例重复生成邮件。
|
||||
|
||||
## 7. 邮件发送链路
|
||||
|
||||
通用发送链路：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["待发送邮件记录"] --> B["写入 Kafka"]
|
||||
B --> C["发送消费者"]
|
||||
C --> D["读取发件通道配置"]
|
||||
D --> E{"发送通道"}
|
||||
E -->|批量营销| F["AWS SES 或批量发送通道"]
|
||||
E -->|客服回复| G["SMTP / Gmail / Microsoft"]
|
||||
F --> H["保存发送结果"]
|
||||
G --> H
|
||||
H --> I["通知前端或更新统计"]
|
||||
```
|
||||
|
||||
发送消费者需要处理：
|
||||
|
||||
1. 队列消息反序列化。
|
||||
2. 邮件正文、标题、收件人、发件人、回复地址、附件组装。
|
||||
3. 发送通道选择。
|
||||
4. 调用外部服务。
|
||||
5. 成功后保存 `message_id`、发送时间和成功状态。
|
||||
6. 失败后保存错误信息、失败状态和重试次数。
|
||||
|
||||
发送通道建议按场景区分：
|
||||
|
||||
| 场景 | 推荐处理 |
|
||||
| --- | --- |
|
||||
| 批量营销邮件 | 走支持批量和事件回调的邮件服务，例如 AWS SES |
|
||||
| 策略邮件 | 可复用批量发送通道，但必须做频率和幂等控制 |
|
||||
| 工单客服回复 | 按发件邮箱配置选择 SMTP、Gmail API 或 Microsoft Graph |
|
||||
| 普通邮箱回复 | 可独立于工单链路，同步或异步发送均可 |
|
||||
|
||||
## 8. 邮件事件回调与统计
|
||||
|
||||
邮件发送后，外部服务会产生事件。通用事件包括：
|
||||
|
||||
| 事件 | 处理建议 |
|
||||
| --- | --- |
|
||||
| Delivery / 送达 | 标记邮件已送达，记录送达时间和发送 IP |
|
||||
| Bounce / 退信 | 区分永久退信和临时退信，更新任务统计；永久退信可加入黑名单 |
|
||||
| Open / 打开 | 标记打开时间，更新任务打开统计 |
|
||||
| Click / 点击 | 记录点击链接和点击时间，更新点击统计 |
|
||||
| Complaint / 投诉 | 记录投诉，加入抑制名单或黑名单 |
|
||||
| Subscription / 订阅变更 | 更新订阅或退订状态 |
|
||||
| Reject / 拒信 | 记录拒信原因，更新失败统计 |
|
||||
| Rendering Failure / 渲染失败 | 记录模板或内容渲染失败 |
|
||||
| DeliveryDelay / 延迟 | 可记录延迟事件，是否统计需业务确认 |
|
||||
|
||||
事件处理要点：
|
||||
|
||||
1. 事件必须通过 `message_id` 或自定义追踪 ID 关联到本地邮件记录。
|
||||
2. 同一事件可能重复回调，需要幂等处理。
|
||||
3. 打开和点击事件存在图片加载、隐私保护、客户端屏蔽等不确定性，统计只能作为参考指标。
|
||||
4. 投诉、退订、永久退信应优先进入发送抑制规则。
|
||||
|
||||
## 9. 入站邮件 / 表单进入工单流程
|
||||
|
||||
入站来源可以有多种：
|
||||
|
||||
1. 网站表单提交。
|
||||
2. 用户真实邮件来信。
|
||||
3. 外部收信服务回调。
|
||||
4. IM 或其他渠道转入邮件客服。
|
||||
|
||||
通用流程：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["用户来信或表单提交"] --> B["入站接收服务"]
|
||||
B --> C["写入 Kafka 入站队列"]
|
||||
C --> D["EDM 工单消费者"]
|
||||
D --> E["保存入站邮件和正文"]
|
||||
E --> F{"是否存在未关闭工单"}
|
||||
F -->|否| G["创建新工单"]
|
||||
F -->|是| H["绑定到原工单并更新未读数"]
|
||||
G --> I["写入节点日志"]
|
||||
H --> I
|
||||
I --> J["通知客服工作台"]
|
||||
```
|
||||
|
||||
创建或更新工单时建议：
|
||||
|
||||
1. 以发件邮箱、收件邮箱、业务用户 ID、会话标识等组合判断是否复用未关闭工单。
|
||||
2. 新工单记录来源、用户邮箱、发件邮箱、团队、状态、未读数、最后来信时间。
|
||||
3. 已有工单更新最后来信时间、未读数、用户来信数。
|
||||
4. 如果当前客服离线，可以释放负责人，让工单重新进入分配池。
|
||||
5. 入站正文应保存原始内容和清洗后的展示内容。
|
||||
|
||||
## 10. 工单客服处理流程
|
||||
|
||||
### 10.1 工单状态
|
||||
|
||||
通用状态建议：
|
||||
|
||||
| 状态 | 说明 |
|
||||
| --- | --- |
|
||||
| 待处理 | 新入站邮件或表单生成工单，等待客服处理 |
|
||||
| 服务中 | 客服已接手并正在处理 |
|
||||
| 未解决 | 客服标记暂未解决，需要后续跟进 |
|
||||
| 转化中 | 进入销售或转化跟进阶段 |
|
||||
| 已关闭 | 本次邮件工单处理结束 |
|
||||
|
||||
状态值可以由新系统自行定义，但需要保证列表筛选、统计、自动关闭和权限校验口径统一。
|
||||
|
||||
### 10.2 自动分配
|
||||
|
||||
自动分配建议流程：
|
||||
|
||||
1. 找到待处理且未分配的工单。
|
||||
2. 根据收件邮箱、团队、站点、语言或业务线确定可服务团队。
|
||||
3. 获取在线客服。
|
||||
4. 按接单上限、当前处理数、最近分配时间选择客服。
|
||||
5. 更新工单负责人。
|
||||
6. 写入分配记录和节点日志。
|
||||
7. 通知客服工作台。
|
||||
|
||||
### 10.3 客服回复
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["客服点击发送"] --> B["校验客服在线、权限、工单状态"]
|
||||
B --> C["写入待发送邮件记录和正文"]
|
||||
C --> D["更新工单未读数、首次响应、回复耗时"]
|
||||
D --> E["投递客服回复队列"]
|
||||
E --> F["发送消费者选择 SMTP / Gmail / Microsoft"]
|
||||
F --> G["保存发送成功或失败结果"]
|
||||
G --> H["通知客服工作台"]
|
||||
```
|
||||
|
||||
发送前建议校验：
|
||||
|
||||
1. 客服必须在线。
|
||||
2. 工单必须存在且未关闭。
|
||||
3. 当前客服必须是工单处理人，或具备接手权限。
|
||||
4. 工单必须属于当前客服可处理团队。
|
||||
5. 主题、正文、收件人、回复地址必须合法。
|
||||
6. 附件大小、类型、数量需要符合业务规则和发送通道限制。
|
||||
|
||||
### 10.4 转发和主动开工单
|
||||
|
||||
转发：
|
||||
|
||||
1. 需要填写新的收件人。
|
||||
2. 转发邮件可以不绑定到原工单作为普通回复。
|
||||
3. 原邮件和转发邮件需要建立关联，方便追溯。
|
||||
4. 发送链路仍可复用客服回复队列。
|
||||
|
||||
主动开工单：
|
||||
|
||||
1. 客服选择发件邮箱和目标用户邮箱。
|
||||
2. 系统校验发件邮箱归属团队。
|
||||
3. 如果同一发件邮箱和用户邮箱已有未关闭工单，应拒绝重复创建或要求接手原工单。
|
||||
4. 创建服务中工单，负责人为当前客服。
|
||||
5. 写入节点日志和分配记录。
|
||||
6. 发送第一封邮件。
|
||||
|
||||
## 11. 工单辅助任务
|
||||
|
||||
新子系统可按需要保留以下后台任务：
|
||||
|
||||
| 任务 | 说明 |
|
||||
| --- | --- |
|
||||
| 自动分配 | 将未分配待处理工单分配给在线客服 |
|
||||
| 自动移交 | 当前负责人离线且有新来信时，按代班或团队规则重新分配 |
|
||||
| DDL 释放 | 工单分配后超过配置时间未处理，释放为未分配 |
|
||||
| 未回复提醒 | 用户新来信超过配置时间未回复，提醒负责人 |
|
||||
| 自动关闭 | 服务中工单超过配置时间无新用户来信时自动关闭 |
|
||||
| 未分配告警 | 未分配工单数量超过阈值时通知团队管理员 |
|
||||
| 统计同步 | 定时刷新任务发送数、回复数、打开数、点击数等统计 |
|
||||
|
||||
具体调度频率和启用范围需要按新系统 SLA 确认。
|
||||
|
||||
## 12. 通用限制与风控点
|
||||
|
||||
### 12.1 任务和发送限制
|
||||
|
||||
建议配置化管理：
|
||||
|
||||
1. 单任务最大目标人数。
|
||||
2. 单轮投递队列数量。
|
||||
3. 单发件邮箱每分钟、每小时、每天发送上限。
|
||||
4. 单用户每天或一段时间内最大触达次数。
|
||||
5. 单域名发送上限。
|
||||
6. 批量邮件和客服回复是否共享额度。
|
||||
|
||||
### 12.2 内容限制
|
||||
|
||||
建议校验：
|
||||
|
||||
1. 邮件主题最大长度。
|
||||
2. 正文最小和最大长度。
|
||||
3. 附件大小、类型、数量。
|
||||
4. 发件邮箱和回复邮箱格式。
|
||||
5. 链接合法性和追踪参数。
|
||||
6. 必要的退订入口和合规声明。
|
||||
|
||||
### 12.3 人群抑制
|
||||
|
||||
发送前应排除：
|
||||
|
||||
1. 退订用户。
|
||||
2. 投诉用户。
|
||||
3. 永久退信用户。
|
||||
4. 风险用户。
|
||||
5. 明确不允许触达的用户。
|
||||
6. 已达到频率上限的用户。
|
||||
|
||||
### 12.4 幂等和重试
|
||||
|
||||
需要幂等的场景：
|
||||
|
||||
1. 任务生成邮件记录。
|
||||
2. 邮件记录投递 Kafka。
|
||||
3. Kafka 消费发送。
|
||||
4. 外部事件回调。
|
||||
5. 入站邮件生成工单。
|
||||
|
||||
失败重试建议区分：
|
||||
|
||||
1. 可重试：网络超时、临时服务不可用、临时退信、限流。
|
||||
2. 不可重试：邮箱格式错误、发件权限错误、账号不存在、永久退信、投诉抑制。
|
||||
|
||||
## 13. 可观测性
|
||||
|
||||
建议至少记录以下指标：
|
||||
|
||||
| 指标 | 说明 |
|
||||
| --- | --- |
|
||||
| 任务创建数 | 按类型、状态统计 |
|
||||
| 目标用户数 | 预估人数、实际生成邮件数、过滤人数 |
|
||||
| 队列积压 | 批量发送队列、客服回复队列、入站队列 |
|
||||
| 发送成功率 | 按通道、发件邮箱、任务统计 |
|
||||
| 失败原因分布 | 发送失败、退信、拒信、限流 |
|
||||
| 送达率、打开率、点击率 | 以事件回调统计，注意打开和点击有误差 |
|
||||
| 投诉率、退订率 | 作为发送风控核心指标 |
|
||||
| 工单响应时长 | 首次响应、最近响应、关闭时长 |
|
||||
| 未分配工单数 | 用于团队容量和告警 |
|
||||
|
||||
|
||||
## 14. 参考代码位置
|
||||
|
||||
以下为现有项目中可参考的代码位置，重构时可按新架构重新命名和拆分：
|
||||
|
||||
| 模块 | 现有参考 |
|
||||
| --- | --- |
|
||||
| 邮件任务后台入口 | `app/admin/controller/MailTaskController.php` |
|
||||
| 邮件任务服务 | `app/service/MailTaskService.php` |
|
||||
| 批量邮件生成与投递参考 | `app/service/UserService.php` |
|
||||
| 批量邮件发送消费者 | `app/command/kafkaConsumer/BatchMailCommand.php` |
|
||||
| 工单后台入口 | `app/admin/controller/EdmChatController.php` |
|
||||
| 工单服务 | `app/service/EdmChatService.php` |
|
||||
| 客服回复消费者 | `app/command/kafkaConsumer/MailSendCommand.php` |
|
||||
| 表单数据消费者 | `app/command/kafkaConsumer/QaForm.php` |
|
||||
| 表单创建工单 | `app/service/WebFormDataService.php` |
|
||||
| 邮件事件回调 | `app/controller/AmazonEmailController.php` |
|
||||
| 普通邮箱服务 | `app/admin/controller/MailboxController.php`、`app/service/MailboxService.php` |
|
||||
| 邮件发送封装 | `app/service/Mail.php` |
|
||||
| Microsoft 邮件服务 | `app/service/MicrosoftService.php` |
|
||||
| 策略邮件命令 | `app/command/EdmDoRealTimeStrategy.php`、`app/command/EdmSendRealTimeStrategy.php`、`app/command/EdmDayCurrentTask.php` |
|
||||
| 工单辅助命令 | `app/command/EdmAllocate.php`、`app/command/EdmMove.php`、`app/command/EdmDealLine.php`、`app/command/EdmTimeout.php`、`app/command/EdmWorkOrderAutoClose.php` |
|
||||
|
||||
309
wishfulfilled-wiki/05_需求文档/通用IM业务流程与接口频率限制说明.md
Normal file
309
wishfulfilled-wiki/05_需求文档/通用IM业务流程与接口频率限制说明.md
Normal file
@@ -0,0 +1,309 @@
|
||||
# 通用 IM 业务流程与接口频率限制说明
|
||||
|
||||
更新时间：2026-05-26
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本文用于新的 IM 子系统重构设计，目标是在功能保持一致的前提下，将现有 IM 业务抽象成通用流程，便于后续拆分服务、设计数据模型、规划 Kafka 消费链路、控制腾讯云 IM REST API 调用频率。
|
||||
|
||||
## 2. 总体架构
|
||||
|
||||
通用 IM 链路由以下组件组成：
|
||||
|
||||
| 组件 | 职责 |
|
||||
| --- | --- |
|
||||
| App 客户端 | 用户通过 App 使用腾讯云 IM SDK 发送和接收消息 |
|
||||
| 腾讯云 IM | 负责即时消息投递、账号体系、消息格式、离线推送、服务端 REST API、回调触发 |
|
||||
| App 后台 | 接收腾讯云 IM 回调，识别需要管理后台处理的消息，并写入 Kafka |
|
||||
| Kafka | 解耦 App 后台与管理后台 IM 子系统，承接入站消息、推送消息、异步任务 |
|
||||
| IM 子系统 / 管理后台 | 消费 Kafka 消息，维护本地会话、消息、工单、分配、状态流转和客服操作 |
|
||||
| 本地数据库 | 作为管理后台 IM 业务的长期数据源，保存消息流水、会话状态、工单状态、操作记录 |
|
||||
| Redis / 缓存 | 保存在线状态、分配触发标记、限流计数、幂等键、临时游标 |
|
||||
| WebSocket / 站内通知 | 将新消息、分配变化、发送结果、状态变化推送给管理后台前端 |
|
||||
|
||||
## 3. 总体消息流
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["用户在 App 发送 IM 消息"] --> B["腾讯云 IM SDK 投递消息"]
|
||||
B --> C["腾讯云 IM 回调 App 后台"]
|
||||
C --> D["App 后台校验回调并识别管理后台相关消息"]
|
||||
D --> E["App 后台写入 Kafka"]
|
||||
E --> F["IM 子系统消费 Kafka"]
|
||||
F --> G["幂等校验与消息解析"]
|
||||
G --> H["写入本地消息表"]
|
||||
H --> I["更新会话、工单、未读数、最后消息时间"]
|
||||
I --> J["触发分配、提醒或状态流转"]
|
||||
J --> K["管理后台客服前端展示"]
|
||||
```
|
||||
|
||||
核心原则：
|
||||
|
||||
1. App 客户端消息先进入腾讯云 IM。
|
||||
2. 腾讯云 IM 将消息回调给 App 后台。
|
||||
3. App 后台不直接写管理后台业务库，而是将管理后台关心的消息写入 Kafka。
|
||||
4. 管理后台 IM 子系统消费 Kafka 后入库，并维护本地会话、工单和客服状态。
|
||||
5. 管理后台后续展示、检索、统计、客服处理，应以本地数据库为主数据源。
|
||||
|
||||
## 4. 核心数据模型
|
||||
|
||||
新子系统建议至少抽象以下数据对象：
|
||||
|
||||
| 对象 | 说明 |
|
||||
| --- | --- |
|
||||
| IM 账号 | 业务用户、品牌账号、客服账号在腾讯云 IM 中的账号映射 |
|
||||
| 消息 Message | 本地保存的消息流水，包含方向、发送方、接收方、消息类型、消息体、腾讯消息 ID、业务扩展字段 |
|
||||
| 会话 Conversation | 用户与品牌/客服之间的当前会话指针，包含未读数、最后消息时间、当前工单 ID |
|
||||
| 工单 Ticket / ChatRecord | 一次客服处理过程，包含状态、负责人、团队、首次响应时间、关闭时间 |
|
||||
| 分配记录 Assignment | 自动分配、手动接手、转接、释放、代班等操作记录 |
|
||||
| 节点日志 NodeLog | 工单生成、分配、首次回复、转接、未解决、转化中、关闭等关键节点 |
|
||||
| 推送任务 PushTask | 运营或策略创建的 IM 推送任务 |
|
||||
| 推送记录 PushRecord | 单个用户、单条内容的实际待发送记录和发送结果 |
|
||||
|
||||
## 5. 入站消息流程
|
||||
|
||||
### 5.1 用户发送消息
|
||||
|
||||
1. 用户在 App 中通过腾讯云 IM SDK 发送文本、图片、视频、自定义卡片或其他消息。
|
||||
2. 腾讯云 IM 完成消息投递，并根据配置触发服务端回调。
|
||||
3. App 后台接收腾讯云 IM 回调，完成签名、来源、事件类型和消息结构校验。
|
||||
4. App 后台判断该消息是否需要管理后台处理。
|
||||
5. 需要管理后台处理的消息，由 App 后台写入 Kafka。
|
||||
6. IM 子系统消费 Kafka，执行幂等校验，解析消息体。
|
||||
7. IM 子系统写入本地消息流水，并更新会话和工单状态。
|
||||
8. 若消息产生新的待处理工单，则进入分配流程。
|
||||
9. 管理后台前端通过列表查询、WebSocket 或站内通知看到新消息。
|
||||
|
||||
### 5.2 幂等与顺序
|
||||
|
||||
腾讯云回调、App 后台写 Kafka、Kafka 消费都可能出现重试，因此 IM 子系统必须做幂等处理。
|
||||
|
||||
建议幂等键优先级：
|
||||
|
||||
1. 腾讯云 IM 消息唯一标识。
|
||||
2. 发送方、接收方、消息随机数、消息序列号、消息时间组合。
|
||||
3. App 后台写入 Kafka 时生成的业务事件 ID。
|
||||
|
||||
同一会话内需要尽量按消息时间和腾讯云消息顺序展示。若存在乱序到达，应允许入库后按消息时间、序列号或腾讯消息 ID 排序展示。
|
||||
|
||||
## 6. 客服处理流程
|
||||
|
||||
### 6.1 会话和工单状态
|
||||
|
||||
通用状态建议如下：
|
||||
|
||||
| 状态 | 说明 |
|
||||
| --- | --- |
|
||||
| 待接入 | 用户有新消息，尚未分配或尚未被客服处理 |
|
||||
| 服务中 | 客服已接入并正在处理 |
|
||||
| 已转接 | 工单被转给其他客服或团队，等待新处理人接手 |
|
||||
| 未解决 | 客服标记暂未解决，需要后续跟进 |
|
||||
| 转化中 | 进入转化或商机跟进阶段 |
|
||||
| 已关闭 | 本次客服处理结束 |
|
||||
|
||||
状态值可以由新子系统自行定义，但需要保证列表筛选、统计口径、自动关闭、转接和重新打开逻辑一致。
|
||||
|
||||
### 6.2 自动分配
|
||||
|
||||
自动分配通常在新消息入库后触发：
|
||||
|
||||
1. 找到待接入工单。
|
||||
2. 根据品牌、站点、团队、语言、业务线等条件确定可服务团队。
|
||||
3. 获取在线客服列表。
|
||||
4. 按客服接单上限、当前处理数、最近分配时间等规则筛选。
|
||||
5. 选择目标客服并更新工单负责人。
|
||||
6. 写入分配记录和节点日志。
|
||||
7. 通知管理后台前端。
|
||||
|
||||
建议将分配能力独立成可重试任务，避免 Kafka 入站消费被复杂分配逻辑拖慢。
|
||||
|
||||
### 6.3 客服打开会话
|
||||
|
||||
客服打开会话时，系统通常需要：
|
||||
|
||||
1. 校验客服是否在线、是否有处理权限。
|
||||
2. 查询会话和工单详情。
|
||||
3. 拉取本地消息列表。
|
||||
4. 清理当前客服视角下的未读数。
|
||||
5. 必要时将工单从待接入或已转接推进到服务中。
|
||||
6. 记录读取、接手或首次处理节点。
|
||||
|
||||
### 6.4 客服发送消息
|
||||
|
||||
客服发送消息的通用链路：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["客服在管理后台发送消息"] --> B["IM 子系统校验权限、会话、工单状态"]
|
||||
B --> C["组装腾讯云 IM 消息体"]
|
||||
C --> D["调用腾讯云 REST API"]
|
||||
D --> E{"腾讯云返回结果"}
|
||||
E -->|成功| F["写入本地消息流水并更新会话"]
|
||||
E -->|失败| G["记录失败原因并进入重试或人工处理"]
|
||||
F --> H["通知管理后台前端发送成功"]
|
||||
G --> I["通知管理后台前端发送失败"]
|
||||
```
|
||||
|
||||
发送前建议校验：
|
||||
|
||||
1. 当前客服必须具备客服身份。
|
||||
2. 当前客服必须有该会话或工单处理权限。
|
||||
3. 工单不能处于已关闭状态，除非业务允许重新打开。
|
||||
4. 消息体大小、消息类型、媒体文件大小必须符合业务和腾讯云限制。
|
||||
5. 对运营推送和客服消息应区分业务来源，方便统计和风控。
|
||||
|
||||
### 6.5 转接、释放和自动关闭
|
||||
|
||||
通用处理规则：
|
||||
|
||||
1. 手动转接给个人：校验当前处理人权限，更新负责人，记录转接节点。
|
||||
2. 手动转接给团队：记录目标团队，等待团队内客服接手或自动分配。
|
||||
3. 客服离线释放：如果负责人离线且有未读用户消息，可释放为待分配。
|
||||
4. 超时未处理释放：待接入或已转接超过配置时间后，重新进入分配池。
|
||||
5. 自动关闭：服务中会话在配置时间内无新用户消息或无新客服动作时，自动关闭。
|
||||
|
||||
## 7. 运营 IM 推送流程
|
||||
|
||||
运营推送与客服消息都可能调用腾讯云 IM REST API，但应在业务上区分：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["后台创建推送任务"] --> B["审核或直接进入待发送"]
|
||||
B --> C["按标签、站点、产品、用户状态筛选目标人群"]
|
||||
C --> D["生成 PushRecord"]
|
||||
D --> E["写入 Kafka 推送队列"]
|
||||
E --> F["推送消费者限速发送"]
|
||||
F --> G["调用 sendmsg 或 batchsendmsg"]
|
||||
G --> H["保存腾讯云返回结果"]
|
||||
H --> I["汇总任务完成状态"]
|
||||
```
|
||||
|
||||
建议：
|
||||
|
||||
1. 大批量运营推送优先评估 `batchsendmsg`，减少单发接口压力。
|
||||
2. 推送消费者必须按 SDKAppID 和接口维度做限速。
|
||||
3. 推送记录需要保存发送状态、错误码、重试次数、腾讯云返回结果。
|
||||
4. 发送失败应区分可重试错误和不可重试错误。
|
||||
5. 推送消息应写入业务扩展字段，便于后续归因和统计。
|
||||
|
||||
## 8. 本地存储与历史消息
|
||||
|
||||
管理后台 IM 子系统建议以本地数据库作为长期主数据源。
|
||||
|
||||
腾讯云 IM 漫游消息适合用于消息补偿、短期核对或异常排查，不建议作为客服记录、统计报表和审计的唯一长期来源。原因是历史消息存储时长与套餐、增值服务和控制台配置有关，且可能产生额外费用。
|
||||
|
||||
建议本地保存：
|
||||
|
||||
1. 入站用户消息。
|
||||
2. 客服发送消息。
|
||||
3. 系统提示消息。
|
||||
4. 运营推送消息及发送结果。
|
||||
5. 转接、关闭、分配、未解决、转化等节点日志。
|
||||
|
||||
## 9. 腾讯云 IM 接口频率限制说明
|
||||
|
||||
以下为腾讯云官方文档口径，实际限制可能随套餐、数据中心、控制台配置和商务协议变化，最终以腾讯云控制台和合同为准。
|
||||
|
||||
### 9.1 通用限制
|
||||
|
||||
| 项目 | 限制 |
|
||||
| --- | --- |
|
||||
| 单聊、群聊单条消息长度 | 最大 12KB |
|
||||
| UserID | 长度不超过 32 字节，不支持特殊字符，建议使用英文字母或数字 |
|
||||
| REST API 通用调用频率 | 多数 REST API 默认最高 200 次/秒 |
|
||||
| 导入多个账号、删除账号、查询账号 | 默认最高 100 次/秒 |
|
||||
| 查询在线状态 | 单次请求最多查询 500 个用户 |
|
||||
| 批量发单聊消息 | 单次最多给 500 个用户发送 |
|
||||
| 导入多个账号 | 单次最多导入 100 个用户名 |
|
||||
| 单个用户好友数 | 默认支持 3000 个好友 |
|
||||
| 单个用户黑名单数 | 最多 1000 人 |
|
||||
|
||||
### 9.2 常用 REST API 频率
|
||||
|
||||
| 接口 | 默认频率限制 | 叠加包增量 | 说明 |
|
||||
| --- | --- | --- | --- |
|
||||
| `v4/openim/sendmsg` 单发单聊消息 | 200 次/秒 | 每个叠加包 +100 次/秒 | 体验版和开发版每日累计发送量限制为 1000 条/天 |
|
||||
| `v4/openim/batchsendmsg` 批量发单聊消息 | 200 次/秒，同时 12000 条/分钟 | 每个叠加包 +6000 条/分钟 | 条数按接收方数量计算，一次发给 500 人计 500 条 |
|
||||
| `v4/profile/portrait_set` 设置资料 | 200 次/秒 | 每个叠加包 +100 次/秒 | 用于更新头像、昵称等资料 |
|
||||
| `v4/profile/portrait_get` 拉取资料 | 200 次/秒 | 每个叠加包 +100 次/秒 | 用于查询资料 |
|
||||
| `v4/openim/query_online_status` 查询在线状态 | 200 次/秒 | 每个叠加包 +100 次/秒 | 单次最多查询 500 个用户 |
|
||||
| `v4/openim/get_c2c_unread_msg_num` 查询单聊未读数 | 200 次/秒 | 每个叠加包 +100 次/秒 | 如新系统需要同步未读数需注意限频 |
|
||||
| `v4/group_open_http_svc/send_group_msg` 群内发普通消息 | 200 次/秒 | 每个叠加包 +100 次/秒 | 单个群发送频率上限为 40 条/秒 |
|
||||
| `v4/sns/black_list_get` 拉取黑名单 | 200 次/秒 | 每个叠加包 +100 次/秒 | 关系链相关能力需控制调用频率 |
|
||||
|
||||
### 9.3 调频收费说明
|
||||
|
||||
腾讯云 IM 服务端 API 调频属于增值服务。官方公告口径为：
|
||||
|
||||
| 数据中心 | 服务端 API 调用频率叠加包价格 |
|
||||
| --- | --- |
|
||||
| 国内数据中心 | 10 元/个/日，日结后付费 |
|
||||
| 境外数据中心 | 20 元/个/日，日结后付费 |
|
||||
|
||||
注意事项：
|
||||
|
||||
1. 调频对单个 SDKAppID 生效，多个 SDKAppID 需要分别配置。
|
||||
2. 每个调频项按当日配置的最高数值计费，次日出账。
|
||||
3. 体验版不支持调整服务端 API 调用频率上限。
|
||||
4. 如果新子系统存在大规模运营推送，必须提前评估 `sendmsg` 与 `batchsendmsg` 的峰值。
|
||||
|
||||
## 10. 新子系统设计建议
|
||||
|
||||
### 10.1 按接口维度做限流
|
||||
|
||||
建议在 IM 子系统服务端增加统一腾讯云 IM Client，并在 Client 内按以下维度做限流：
|
||||
|
||||
1. SDKAppID。
|
||||
2. API 路径，例如 `openim/sendmsg`、`openim/batchsendmsg`。
|
||||
3. 业务来源，例如客服消息、运营推送、系统通知。
|
||||
|
||||
Kafka 消费者不能只依赖消费并发控制，否则高峰期可能瞬间打满腾讯云 API 限频。
|
||||
|
||||
### 10.2 单发和批量发送分流
|
||||
|
||||
建议策略：
|
||||
|
||||
| 场景 | 推荐接口 |
|
||||
| --- | --- |
|
||||
| 客服一对一即时回复 | `openim/sendmsg` |
|
||||
| 系统给单个用户发送提示 | `openim/sendmsg` |
|
||||
| 运营批量推送相同或相似内容 | 优先评估 `openim/batchsendmsg` |
|
||||
| 需要强个性化卡片、每人内容不同 | 可用 `sendmsg`，但必须限速 |
|
||||
|
||||
### 10.3 错误处理和重试
|
||||
|
||||
建议将发送结果分为：
|
||||
|
||||
1. 成功：腾讯云返回 `ErrorCode=0` 且业务认为发送完成。
|
||||
2. 部分成功：批量发送时部分账号失败，需要保存失败账号列表。
|
||||
3. 可重试失败：网络异常、超时、腾讯云内部错误、限频。
|
||||
4. 不可重试失败：账号不存在、消息体非法、权限错误、消息包超长。
|
||||
|
||||
重试建议采用延迟重试，并设置最大重试次数。超过次数后进入失败表或死信队列，供人工排查。
|
||||
|
||||
### 10.4 回调链路可观测性
|
||||
|
||||
入站链路建议记录以下指标：
|
||||
|
||||
1. 腾讯云回调接收量。
|
||||
2. App 后台写 Kafka 成功量和失败量。
|
||||
3. Kafka 积压量。
|
||||
4. IM 子系统消费延迟。
|
||||
5. 入库成功量和幂等重复量。
|
||||
6. 会话创建量、工单创建量、分配成功量。
|
||||
|
||||
发送链路建议记录：
|
||||
|
||||
1. 每个 API 的 QPS。
|
||||
2. 限流等待时间。
|
||||
3. 腾讯云错误码分布。
|
||||
4. 发送成功率。
|
||||
5. 可重试失败量和最终失败量。
|
||||
|
||||
## 11. 参考来源
|
||||
|
||||
- 腾讯云 IM 使用限制：https://cloud.tencent.com/document/product/269/32429
|
||||
- 腾讯云 IM 单发单聊消息：https://cloud.tencent.com/document/product/269/2282
|
||||
- 腾讯云 IM 批量发单聊消息：https://cloud.tencent.com/document/product/269/1612
|
||||
- 腾讯云 IM 服务端 API 调频收费公告：https://cloud.tencent.com/document/product/269/93324
|
||||
|
||||
430
wishfulfilled-wiki/07_技术文档/01-子系统-identity-数据库表关系.md
Normal file
430
wishfulfilled-wiki/07_技术文档/01-子系统-identity-数据库表关系.md
Normal file
@@ -0,0 +1,430 @@
|
||||
# identity 子系统 — doris数据库相关表与关联关系（供参考）
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 1. 数据库全景
|
||||
|
||||
| 数据库 | 说明 | 与 identity 的关系 |
|
||||
|--------|------|-------------------|
|
||||
| `ods_app_base_data` | APP基础数据（用户、设备、好友、产品） | **核心** — 用户身份主数据 |
|
||||
| `ods_app_app_community` | 社区数据（帖子、评论、关注） | 行为数据，辅助归并 |
|
||||
| `ods_app_jh_data` | JOYHUB事件数据 | 行为数据，辅助归并 |
|
||||
| `ods_oa_oaaftersales` | OA售后系统（客户、订单、测评） | **核心** — 非APP用户身份线索 |
|
||||
| `app_tag_data` | 标签数据 | **关键** — 已有 OneID 归并表 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 核心发现：已存在的 OneID 归并表
|
||||
|
||||
### `app_tag_data.user_oneid` — 用户唯一标识归并表（6 字段，已有数据）
|
||||
|
||||
> **这是 identity 子系统 M2（归并引擎）的核心参考**，已实现 uuid → one_id 的归并逻辑
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `uuid` | VARCHAR(64) | UNI, NOT NULL | 原始客户唯一标识符 |
|
||||
| `one_id` | VARCHAR(64) | NOT NULL | 用户唯一标识（归并后的ID） |
|
||||
| `bridge_uuid` | STRING | | 当前 uuid 对应的非当前桥接 uuid |
|
||||
| `association_fields` | STRING | | 关联字段 |
|
||||
| `detail` | STRING | | uuid 指向 one_id 的证据说明（JSON） |
|
||||
| `update_time` | DATETIME(3) | | 同步更新时间 |
|
||||
|
||||
**关键设计点**：
|
||||
- `uuid` → `one_id` 是多对一关系（多个 uuid 可归并到同一个 one_id）
|
||||
- `bridge_uuid` 记录桥接关联，用于跨系统身份串联
|
||||
- `detail` 字段存储归并证据（JSON），与设计文档中 `person_profiles.merge_evidence` 概念一致
|
||||
- `association_fields` 记录关联字段，对应设计文档中的线索类型
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心表状态
|
||||
|
||||
设计文档定义的 4 张核心表 **尚未在数据库中创建**：
|
||||
|
||||
| 表名 | 设计文档定义 | 数据库状态 | 与现有表的关系 |
|
||||
|------|-------------|-----------|--------------|
|
||||
| `person_profiles` | 真实人主表 | **不存在** | 可参考 `app_tag_data.user_oneid`（one_id） |
|
||||
| `person_identity_links` | 身份线索关联表 | **不存在** | 可参考 `ods_oa_oaaftersales.customer_platform_info`（type映射线索类型） |
|
||||
| `contact_context_snapshots` | 上下文快照 | **不存在** | 需聚合多表新建 |
|
||||
| `device_records` | 设备变化记录 | **不存在** | 可参考 `user_device_token_log`（已有252万条记录） |
|
||||
|
||||
---
|
||||
|
||||
## 4. 已存在的数据源表
|
||||
|
||||
### 4.1 用户与身份核心表
|
||||
|
||||
#### `ods_app_base_data.users` — 用户主表（36 字段）
|
||||
|
||||
> identity 子系统的核心用户数据源，提供 JOYHUB ID、邮箱、设备号等身份线索
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | BIGINT | UNI | 用户ID（JOYHUB ID） |
|
||||
| `userName` | STRING | | 用户名 |
|
||||
| `email` | STRING | | 邮箱 |
|
||||
| `deviceToken` | VARCHAR(300) | | 设备推送令牌 |
|
||||
| `IMEI` | STRING | | 设备IMEI |
|
||||
| `sysType` | VARCHAR(765) | | 系统类型（安卓/IOS/Windows Phone） |
|
||||
| `deviceId` | STRING | | 设备ID |
|
||||
| `appVersion` | VARCHAR(90) | | APP版本 |
|
||||
| `contact_information` | VARCHAR(765) | | 联系方式（电话号码） |
|
||||
| `mobile` | STRING | | 手机号 |
|
||||
| `area_code` | BIGINT | | 区域代码（美国1，中国86） |
|
||||
| `status` | TINYINT | | 1活跃/2封禁/3注销 |
|
||||
| `sysTime` | DATETIME | | 系统时间（注册时间） |
|
||||
| `created_at` | DATETIME | | 创建时间 |
|
||||
|
||||
#### `ods_app_base_data.user_login_last` — 最近登录信息（21 字段）
|
||||
|
||||
> 提供设备型号、系统版本、APP版本、国家等信息，是设备变化识别（M4）的重要数据源
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `UserId` | BIGINT | UNI | 用户ID → 关联 `users.id` |
|
||||
| `deviceId` | STRING | | 设备ID |
|
||||
| `deviceModel` | VARCHAR(150) | | 手机型号 |
|
||||
| `device` | VARCHAR(150) | | 手机系统 |
|
||||
| `sysType` | VARCHAR(150) | | 系统设备信息与版本 |
|
||||
| `appVersion` | VARCHAR(45) | | APP版本号 |
|
||||
| `appChannel` | INT | | 渠道 |
|
||||
| `countryName` | VARCHAR(600) | | 国家名称 |
|
||||
| `countryCode` | VARCHAR(30) | | 国家缩写 |
|
||||
| `Time` | DATETIME | | 登录时间 |
|
||||
| `Ip` | STRING | | IP地址 |
|
||||
|
||||
#### `ods_app_base_data.user_device_token_log` — 设备令牌变更日志（7 字段，252万行）
|
||||
|
||||
> 记录设备令牌的添加和更新，可用于追踪设备变化
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | INT | UNI | 主键 |
|
||||
| `user_id` | INT | | 用户ID → 关联 `users.id` |
|
||||
| `type` | TINYINT | | 0添加/1更新 |
|
||||
| `device_id` | STRING | | 设备ID |
|
||||
| `new_device_token` | VARCHAR(300) | | 新设备令牌 |
|
||||
| `created_at` | DATETIME | | 创建时间 |
|
||||
| `client_time` | DATETIME | | 客户端时间 |
|
||||
|
||||
#### `ods_app_base_data.user_contact_information_history` — 联系方式变更历史（11 字段，20万行）
|
||||
|
||||
> 记录用户手机号等联系方式的变更历史，可用于身份线索追踪
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | DECIMAL(20,0) | UNI | 主键 |
|
||||
| `user_id` | BIGINT | | 用户ID → 关联 `users.id` |
|
||||
| `user_type` | VARCHAR(150) | | 用户角色 |
|
||||
| `area_code` | BIGINT | | 区域代码 |
|
||||
| `mobile` | STRING | | 手机号 |
|
||||
| `area_id` | INT | | 区域ID |
|
||||
| `marketing_phone` | TINYINT | | 营销电话开关 |
|
||||
| `marketing_sms` | TINYINT | | 个性化广告开关 |
|
||||
| `status` | SMALLINT | | 1生效中/2已过期 |
|
||||
| `verify_status` | SMALLINT | | 短信验证状态：1通过/2未通过 |
|
||||
| `created_at` | BIGINT | | 创建时间 |
|
||||
|
||||
#### `ods_app_base_data.banned_device_id` — 设备封禁表（3 字段，6831行）
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | INT | UNI | 主键 |
|
||||
| `device_id` | VARCHAR(765) | | 封禁设备ID |
|
||||
| `created_at` | INT | | 创建时间 |
|
||||
|
||||
#### `ods_app_base_data.blacklist_users_aggregate` — 用户黑名单汇总（8 字段）
|
||||
|
||||
> 按 uid、设备、IP 维度的黑名单，用于风险判断
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | INT | UNI | 主键 |
|
||||
| `target_id` | INT | | 1=uid, 2=设备, 3=IP |
|
||||
| `target_value` | VARCHAR(1500) | | 字段值 |
|
||||
| `category_id` | INT | | 黑名单类别ID |
|
||||
| `describe` | VARCHAR(1500) | | 加入原因 |
|
||||
|
||||
|
||||
### 4.2 OA 售后系统 — 客户身份数据
|
||||
|
||||
#### `ods_oa_oaaftersales.customer` — 客户主表（22 字段，23万行）
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | DECIMAL(20,0) | UNI | 客户ID |
|
||||
| `name` | STRING | | 客户名 |
|
||||
| `country` | VARCHAR(60) | | 国家 |
|
||||
| `is_black` | TINYINT | | 是否黑名单 |
|
||||
| `high_risk` | TINYINT | | 是否高风险 |
|
||||
| `erp_contact` | STRING | | ERP联系方式 |
|
||||
| `erp_pay_account` | VARCHAR(1500) | | ERP付款账号 |
|
||||
|
||||
#### `ods_oa_oaaftersales.customer_platform_info` — 客户平台信息（8 字段，26万行）
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | BIGINT | UNI | 主键 |
|
||||
| `type` | TINYINT | | **1电话/2邮箱/3joyhub_id/4邮箱编码/5twitter/6facebook** |
|
||||
| `customer_id` | INT | | 客户ID → 关联 `customer.id` |
|
||||
| `account` | STRING | | 账号值 |
|
||||
| `is_delete` | TINYINT | | 是否删除 |
|
||||
|
||||
#### `ods_oa_oaaftersales.customer_address` — 客户地址（18 字段，5631行）
|
||||
|
||||
> 提供姓名+地址组合，可用于 ORDER_NAME_ADDRESS 线索归并
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | BIGINT | UNI | 主键 |
|
||||
| `customer_id` | INT | | 客户ID → 关联 `customer.id` |
|
||||
| `recipient_name` | STRING | | 收件人姓名 |
|
||||
| `phone` | STRING | | 电话 |
|
||||
| `zip_code` | STRING | | 邮编 |
|
||||
| `country` | VARCHAR(300) | | 国家 |
|
||||
| `city` | STRING | | 城市 |
|
||||
| `state` | STRING | | 州/省 |
|
||||
| `detail` | VARCHAR(1500) | | 详细地址 |
|
||||
|
||||
#### `ods_oa_oaaftersales.customer_payment_account` — 客户付款账号（12 字段，10万行）
|
||||
|
||||
> 提供收款信息（银行卡、PayPal等），可作为身份归并线索
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | BIGINT | UNI | 主键 |
|
||||
| `ct_id` | INT | | 客户ID → 关联 `customer.id` |
|
||||
| `pay_name` | VARCHAR(150) | | 支付方式 |
|
||||
| `account_number` | STRING | | 账号 |
|
||||
| `account_name` | STRING | | 账户名 |
|
||||
| `card_no` | VARCHAR(300) | | 卡号 |
|
||||
|
||||
#### `ods_oa_oaaftersales.customer_bind` — 客户绑定关系（6 字段，4980行）
|
||||
|
||||
> 客户间的绑定关系，已有归并概念
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | BIGINT | UNI | 主键 |
|
||||
| `customer_ids` | STRING | | 绑定的客户ID集合 |
|
||||
| `unbind_time` | DATETIME | | 解绑时间 |
|
||||
| `is_deleted` | TINYINT | | 是否删除 |
|
||||
|
||||
#### `ods_oa_oaaftersales.customer_bind_log` — 客户绑定日志（6 字段，1.2万行）
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | BIGINT | UNI | 主键 |
|
||||
| `user_id` | INT | | 操作人ID |
|
||||
| `bind_customer_ids` | STRING | | 绑定的客户ID |
|
||||
| `type` | VARCHAR(765) | | 操作类型 |
|
||||
|
||||
#### `ods_oa_oaaftersales.evaluation_order` — 测评订单（55+ 字段，45万行）
|
||||
|
||||
> 包含丰富的身份线索：邮箱、电话、JOYHUB ID、社交媒体账号
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | BIGINT | UNI | 订单ID |
|
||||
| `ct_id` | INT | | 客户ID → 关联 `customer.id` |
|
||||
| `amazon_order_id` | STRING | | 亚马逊订单号 |
|
||||
| `email` | STRING | | 邮箱 |
|
||||
| `phone` | STRING | | 电话 |
|
||||
| `joyhub_id` | VARCHAR(150) | | JOYHUB ID |
|
||||
| `twitter` | STRING | | Twitter账号 |
|
||||
| `facebook` | STRING | | Facebook账号 |
|
||||
|
||||
#### `ods_oa_oaaftersales.lingxing_order` — 亚马逊订单（30+ 字段，2142万行）
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | DECIMAL(20,0) | UNI | 订单ID |
|
||||
| `amazon_order_id` | VARCHAR(150) | | 亚马逊订单号 |
|
||||
| `buyer_name` | VARCHAR(765) | | 买家姓名 |
|
||||
| `buyer_email` | VARCHAR(765) | | 买家邮箱 |
|
||||
| `phone` | VARCHAR(90) | | 电话 |
|
||||
| `postal_code` | VARCHAR(765) | | 邮编 |
|
||||
| `address` | VARCHAR(765) | | 地址 |
|
||||
|
||||
#### `ods_oa_oaaftersales.phone_records` — 电话记录（30+ 字段，8万行）
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | BIGINT | UNI | 主键 |
|
||||
| `ct_id` | INT | | 客户ID → 关联 `customer.id` |
|
||||
| `phone` | STRING | | 电话 |
|
||||
| `email` | STRING | | 邮箱 |
|
||||
| `joyhub_id` | VARCHAR(150) | | JOYHUB ID |
|
||||
|
||||
### 4.3 社区行为表
|
||||
|
||||
#### `ods_app_app_community.posts` — 帖子表（35 字段）
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | DECIMAL(20,0) | UNI | 帖子ID |
|
||||
| `user_id` | INT | | 用户ID → 关联 `users.id` |
|
||||
| `status` | SMALLINT | | 10待审核/20拒绝/30通过 |
|
||||
| `deleted_at` | INT | | 删除时间（0=未删除） |
|
||||
|
||||
#### `ods_app_app_community.post_likes` — 点赞表（5 字段）
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | DECIMAL(20,0) | UNI | 主键 |
|
||||
| `post_id` | BIGINT | | 帖子ID → 关联 `posts.id` |
|
||||
| `user_id` | INT | | 用户ID → 关联 `users.id` |
|
||||
|
||||
#### `ods_app_app_community.comments` — 评论表（14 字段）
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | DECIMAL(20,0) | UNI | 评论ID |
|
||||
| `post_id` | DECIMAL(20,0) | | 帖子ID → 关联 `posts.id` |
|
||||
| `user_id` | DECIMAL(20,0) | | 用户ID → 关联 `users.id` |
|
||||
|
||||
#### `ods_app_app_community.follows` — 关注关系表（7 字段）
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | DECIMAL(20,0) | UNI | 主键 |
|
||||
| `user_id` | INT | | 关注者ID → 关联 `users.id` |
|
||||
| `following_user_id` | INT | | 被关注者ID → 关联 `users.id` |
|
||||
|
||||
#### `ods_app_base_data.friends` — 好友关系表（6 字段）
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | DECIMAL(20,0) | UNI | 主键 |
|
||||
| `user_id` | DECIMAL(20,0) | | 用户ID → 关联 `users.id` |
|
||||
| `friend_id` | DECIMAL(20,0) | | 好友ID → 关联 `users.id` |
|
||||
|
||||
### 4.4 事件行为表
|
||||
|
||||
#### `ods_app_jh_data.events` — APP事件表（18 字段）
|
||||
|
||||
> event_type: 13=home, 8=玩具连接, 5=视频等
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | BIGINT | UNI | 事件ID |
|
||||
| `add_date` | DATE | UNI | 记录日期 |
|
||||
| `uid` | BIGINT | | 用户ID → 关联 `users.id` |
|
||||
| `event_type` | INT | | 事件类型 |
|
||||
| `pid` | BIGINT | | 产品ID → 关联 `def_product_list.id` |
|
||||
|
||||
#### `ods_app_jh_data.remote_events` — 远程连接事件表（15 字段）
|
||||
|
||||
| 字段 | 类型 | 键 | 说明 |
|
||||
|------|------|---|------|
|
||||
| `id` | BIGINT | UNI | 事件ID |
|
||||
| `uid` | BIGINT | | 用户ID → 关联 `users.id` |
|
||||
| `call_sn` | VARCHAR(600) | | 远程序列号（格式：uid1_uid2_uuid） |
|
||||
| `mode` | INT | | 1文字/2语音/3视频 |
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 5. 表关联关系图
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ identity 子系统数据关系 │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
┌───────────────────────┐
|
||||
│ app_tag_data │
|
||||
│ .user_oneid │
|
||||
│ uuid ──► one_id │
|
||||
│ (已有归并逻辑) │
|
||||
└───────────┬───────────┘
|
||||
│ uuid 可能是 email/phone/device
|
||||
▼
|
||||
┌──────────────────────────────────────────────────────────────────────┐
|
||||
│ ods_app_base_data（APP用户体系） │
|
||||
│ │
|
||||
│ users ◄── user_profiles (user_id) │
|
||||
│ │ user_login_last (UserId) ── deviceId, deviceModel │
|
||||
│ │ user_device_token_log (user_id) ── 252万条设备变更记录 │
|
||||
│ │ user_contact_information_history (user_id) ── 20万条变更 │
|
||||
│ │ friends (user_id / friend_id) │
|
||||
│ │ banned_device_id (device_id) ── 设备封禁 │
|
||||
│ │ blacklist_users_aggregate (target_id+target_value) │
|
||||
│ │ │
|
||||
│ └── id = JOYHUB_ID │
|
||||
└──────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
┌──────────────────────────────────────────────────────────────────────┐
|
||||
│ ods_oa_oaaftersales（OA售后体系） │
|
||||
│ │
|
||||
│ customer ◄── customer_platform_info (customer_id) │
|
||||
│ │ type: 1电话/2邮箱/3joyhub_id/5twitter/6facebook │
|
||||
│ │ customer_address (customer_id) ── 姓名+地址+电话 │
|
||||
│ │ customer_payment_account (ct_id) ── 收款账号 │
|
||||
│ │ customer_bind (customer_ids) ── 客户绑定关系 │
|
||||
│ │ customer_bind_log ── 绑定操作日志 │
|
||||
│ │ evaluation_order (ct_id) ── 邮箱/电话/joyhub_id/社媒 │
|
||||
│ │ phone_records (ct_id) ── 电话/邮箱/joyhub_id │
|
||||
│ │ order_refund (ct_id) ── 返款详情 │
|
||||
│ │ │
|
||||
│ lingxing_order ── buyer_name + buyer_email + phone + address │
|
||||
│ └── lingxing_order_item (amazon_order_id) │
|
||||
└──────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
┌──────────────────────────────────────────────────────────────────────┐
|
||||
│ 社区行为（ods_app_app_community） │
|
||||
│ │
|
||||
│ posts ◄── post_likes (post_id, user_id) │
|
||||
│ │ comments (post_id, user_id) │
|
||||
│ └── follows (user_id, following_user_id) │
|
||||
└──────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
┌──────────────────────────────────────────────────────────────────────┐
|
||||
│ 事件行为（ods_app_jh_data） |
|
||||
│ │
|
||||
│ events (uid, event_type, pid) │
|
||||
│ communities (uid, event_type) │
|
||||
│ remote_events (uid, call_sn ── 含对端uid) │
|
||||
└──────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. identity 设计表与现有表的字段映射
|
||||
|
||||
### 6.1 person_identity_links（身份线索关联表）— 待建
|
||||
|
||||
| clue_type | 设计文档定义 | 数据来源表 | 来源字段 | 数据量级 |
|
||||
|-----------|-------------|-----------|---------|---------|
|
||||
| JOYHUB_ID | JOYHUB用户ID | `users.id` | id | - |
|
||||
| EMAIL | 邮箱 | `users.email` / `evaluation_order.email` / `lingxing_order.buyer_email` / `edm_contact_user.email` / `customer_platform_info`(type=2) | email | - |
|
||||
| PHONE | 电话 | `users.contact_information` / `users.mobile` / `evaluation_order.phone` / `lingxing_order.phone` / `customer_platform_info`(type=1) | phone | - |
|
||||
| DEVICE | 设备号 | `users.deviceId` / `user_login_last.deviceId` / `user_device_token_log.device_id` | deviceId | 252万条日志 |
|
||||
| ORDER_NAME_ADDRESS | 订单姓名+地址 | `lingxing_order.buyer_name` + `lingxing_order.address` / `customer_address.recipient_name` + `customer_address.detail` | name+address | 5631条地址 |
|
||||
| SOCIAL_ACCOUNT | 社交媒体（扩展） | `evaluation_order.twitter` / `evaluation_order.facebook` / `customer_platform_info`(type=5,6) | twitter/facebook | - |
|
||||
| PAYMENT_ACCOUNT | 收款账号（扩展） | `customer_payment_account.account_number` / `customer.erp_pay_account` | account | 10万条 |
|
||||
|
||||
### 6.2 device_records（设备变化记录）— 待建
|
||||
|
||||
| 设计字段 | 数据来源表 | 来源字段 |
|
||||
|---------|-----------|---------|
|
||||
| `joyhub_id` | `users.id` | id |
|
||||
| `device_id` | `users.deviceId` / `user_login_last.deviceId` / `user_device_token_log.device_id` | deviceId |
|
||||
| `device_model` | `user_login_last.deviceModel` | deviceModel |
|
||||
| `os_version` | `user_login_last.device` / `user_login_last.sysType` | device/sysType |
|
||||
| `app_version` | `user_login_last.appVersion` / `users.appVersion` | appVersion |
|
||||
| `change_type` | `user_device_token_log.type` | 0=NEW, 1=UPDATE |
|
||||
|
||||
### 6.3 contact_context_snapshots（上下文快照）— 待建
|
||||
|
||||
| 设计字段 | 数据来源子系统 | 来源表 |
|
||||
|---------|--------------|--------|
|
||||
| `identity_snapshot` | identity | person_profiles + person_identity_links |
|
||||
| `transaction_snapshot` | planning | lingxing_order, lingxing_order_item |
|
||||
| `service_snapshot` | support | order_refund, evaluation_order, phone_records |
|
||||
| `risk_snapshot` | risk | customer.is_black, customer.high_risk, banned_device_id, blacklist_users_aggregate |
|
||||
| `device_snapshot` | identity(M4) | device_records, user_login_last |
|
||||
| `outreach_snapshot` | outreach | （待确认） |
|
||||
|
||||
|
||||
BIN
wishfulfilled-wiki/08_测试相关/USER用户运营系统_原型逐页详细测试用例集.xlsx
Normal file
BIN
wishfulfilled-wiki/08_测试相关/USER用户运营系统_原型逐页详细测试用例集.xlsx
Normal file
Binary file not shown.
Reference in New Issue
Block a user