犀牛急救 · 客户发掘系统 — 真实业务可行性分析
分析日期：2026-02-11
分析对象：lead-discovery 前端 Demo 全部 7 个页面 + 2 个服务
分析维度：每个功能模块的设计意图 → 当前实现 → 技术可行性 → 落地差距 → 建议方案
一、系统全局架构评估
当前架构
Angular 19 SPA（纯前端）
├── MockDataService ← 所有数据硬编码，无后端
├── QuickScreenService ← 模拟 AI 分类，规则写死
├── EML 解析 API ← 唯一的真实外部服务调用
└── 7 个页面组件 ← 纯展示 + 本地状态操作
核心问题
| 维度 |
现状 |
生产要求 |
| 数据持久化 |
内存中的硬编码数组，刷新即丢 |
数据库 + API |
| AI 能力 |
if-else 关键词匹配 |
LLM / ML 模型 |
| 邮件接入 |
硬编码 6 封模拟邮件 |
IMAP/SMTP 或邮件网关 |
| 多用户 |
无认证、无权限 |
登录 + RBAC |
| 数据来源 |
仅邮件 + 手动录入 |
展会、平台 API、爬虫等 |
二、逐页面/模块深度分析
1. AI 仪表盘（Dashboard）
设计意图：一屏展示 AI 每日批量处理结果，销售人员只需验证。
✅ 可行的部分
| 功能 |
可行性 |
说明 |
| 今日统计卡片（新线索/待验证/已确认/管线总值） |
✅ 完全可行 |
标准 BI 聚合查询，任何数据库都能支持 |
| AI 批次状态展示 |
✅ 可行 |
需要后端任务调度系统（如 Celery / BullMQ） |
| 待验证线索列表 + 确认/无效操作 |
✅ 可行 |
标准 CRUD，加上状态机流转 |
| 画像分布柱状图 |
✅ 可行 |
简单的 GROUP BY 聚合 |
⚠️ 需要补足的部分
| 功能 |
当前状态 |
落地所需 |
| "AI 每日批量处理" |
硬编码的 discoveryBatches 数组 |
真实的定时任务系统：每日凌晨拉取新邮件 → 调用 LLM 分类 → 写入数据库 → 生成批次报告 |
| 最近活动流 |
硬编码 6 条假数据 |
需要事件总线 / 操作日志表 |
| 画像分类准确性 |
if-else 关键词匹配 |
需要 LLM（GPT-4o / Claude）或微调模型 |
💡 技术建议
- 定时批处理：使用 Node.js + BullMQ 或 Python + Celery，每日 08:00 触发
- AI 分类：GPT-4o 的 structured output 模式，输入邮件正文，输出
{persona, grade, confidence, keywords}
- 预估成本：每封邮件约 $0.01-0.03（GPT-4o-mini），日均 50 封 ≈ $0.5-1.5/天
2. 邮件收件箱（Inbox）
设计意图：接收邮件 → 快速筛选 → 创建线索的核心工作流。
✅ 可行的部分
| 功能 |
可行性 |
说明 |
| 邮件列表 + 详情阅读 |
✅ 可行 |
对接 IMAP 协议即可（如 Gmail API / Microsoft Graph） |
| 附件展示与下载 |
✅ 可行 |
邮件附件存储到 OSS/S3 |
| EML 文件导入 + 解析 |
✅ 已实现 |
已对接 eml.brainwork.club API，含附件分析和产品需求提取 |
| 快速筛选 → 创建线索 |
✅ 可行 |
筛选逻辑替换为 LLM 调用即可 |
| 批量筛选 |
✅ 可行 |
并发调用 LLM API + 进度反馈 |
⚠️ 需要补足的部分
| 功能 |
当前状态 |
落地所需 |
| 邮件实时接收 |
硬编码 6 封模拟邮件 |
IMAP 轮询 / Webhook（Gmail Push / Microsoft Graph Subscription） |
| 快速筛选 AI |
classifyByDomain() 用 if-else |
替换为 LLM API 调用，Prompt 中嵌入 6 个画像定义 |
| 筛选结果持久化 |
内存操作，刷新丢失 |
后端 API + 数据库 |
| EML 导入后的线索关联 |
创建了线索但未持久化 |
需要后端存储 |
💡 技术建议
| 方案 |
复杂度 |
实时性 |
推荐场景 |
| IMAP 轮询（每 5 分钟） |
低 |
中 |
MVP 阶段 |
| Gmail API + Pub/Sub |
中 |
高 |
用 Gmail 的团队 |
| Microsoft Graph + Webhook |
中 |
高 |
用 Outlook 的团队 |
| 自建邮件网关（Postfix） |
高 |
最高 |
需要完全控制 |
AI 筛选 Prompt 设计（已有良好基础）：
你是一个外贸线索分类专家。根据以下邮件内容，判断客户画像：
P1-医药分销商 / P2-工业安全供应商 / P3-政府机构采购 / P4-品牌OEM / P5-电商零售 / P6-低质量
输出 JSON：{ persona, personaLabel, valueGrade, confidence, matchedKeywords[], mainBusiness }
EML 导入已具备真实能力：当前的 EML 解析 API 是整个系统中唯一真正可用的外部服务，可直接用于生产
3. 线索看板（Kanban）
设计意图：多维度可视化线索状态，支持按等级/画像/阶段三种视图。
✅ 可行的部分
| 功能 |
可行性 |
说明 |
| 三种看板视图切换 |
✅ 完全可行 |
纯前端 UI 逻辑，数据从 API 获取即可 |
| 按客户类型过滤 |
✅ 可行 |
标准筛选查询 |
| 线索卡片展示 |
✅ 可行 |
数据模型设计合理 |
⚠️ 需要补足的部分
| 功能 |
当前状态 |
落地所需 |
| 拖拽排序/移动阶段 |
❌ 未实现 |
需要 Angular CDK DragDrop + 后端状态更新 API |
| 实时协作 |
❌ 无 |
WebSocket / SSE 推送（多人同时操作看板） |
| 数据持久化 |
内存数据 |
后端 API |
💡 技术建议
- 看板的 UI 设计已经很成熟，落地成本低
- 拖拽功能用
@angular/cdk/drag-drop 即可，约 1-2 天工作量
- 建议先不做实时协作，MVP 阶段用乐观更新 + 冲突提示
4. 线索管理（Lead List）
设计意图：全量线索的表格视图 + 按画像分组 + 统计面板。
✅ 可行的部分
| 功能 |
可行性 |
说明 |
| 列表视图 + 搜索过滤 |
✅ 完全可行 |
标准数据表格 |
| 按画像分组视图 |
✅ 可行 |
前端分组 + 折叠 |
| 统计视图（画像/等级/阶段分布） |
✅ 可行 |
后端聚合查询 |
⚠️ 需要补足的部分
| 功能 |
当前状态 |
落地所需 |
| 分页 |
❌ 无（全量加载） |
线索量超过 100 条后必须分页 |
| 排序 |
❌ 无 |
服务端排序 |
| 批量操作 |
❌ 无 |
批量确认/批量分配/批量导出 |
| 导出 Excel |
❌ 无 |
后端生成 + 下载 |
💡 技术建议
- 数据量 < 500 条时前端分页足够，> 500 条需服务端分页
- 建议增加「导出 Excel」功能，外贸团队强需求
5. 线索详情（Lead Detail）
设计意图：单条线索的全景视图 + AI 画像分析 + 销售验证 + 产品推荐 + 跟进管理。
✅ 可行的部分
| 功能 |
可行性 |
说明 |
| 客户画像分析卡片 |
✅ 可行 |
数据结构完善，展示逻辑清晰 |
| 快速筛选结果展示 |
✅ 可行 |
已有完整的数据模型 |
| 销售验证表单（确认/修改画像） |
✅ 高价值 |
人工反馈 → 可用于微调 AI 模型 |
| 跟进阶段时间线 |
✅ 可行 |
状态机设计合理 |
| 推荐产品列表 |
✅ 可行 |
基于客户类型的规则匹配 |
⚠️ 需要补足的部分
| 功能 |
当前状态 |
落地所需 |
| AI 调研报告 |
硬编码模拟文本 |
需要真实的 AI 调研流程（见下方详述） |
| "深度分析"按钮 |
点击后弹 SnackBar "Phase 3 上线" |
需要实现完整的深度分析 Pipeline |
| 验证结果反馈循环 |
仅修改前端状态 |
需要存储反馈 → 定期用反馈数据优化 AI 模型 |
💡 AI 调研报告的真实实现方案
这是系统中技术挑战最大的功能：
触发深度分析
↓
Step 1: 抓取公司官网（Puppeteer / Playwright）
↓
Step 2: 提取关键信息（LLM 结构化提取）
- 公司规模、主营业务、产品线
- 联系方式、社交媒体
↓
Step 3: 产品匹配分析（LLM + 本地产品库）
- 匹配我方产品 → 客户需求
- 计算利润空间
↓
Step 4: 竞品分析（可选，需要爬虫）
↓
Step 5: 生成销售策略建议（LLM）
↓
输出结构化报告（3-5 分钟）
技术可行性：✅ 可行，但需要注意：
- 官网抓取可能被反爬（需要代理池）
- 耗时较长（3-5 分钟），需要异步任务 + 进度推送
- LLM 调用成本：每次深度分析约 $0.05-0.15
6. 客户画像知识库（Personas）
设计意图：定义和管理 6 类客户画像，作为 AI 分类的知识基础。
✅ 可行的部分
| 功能 |
可行性 |
说明 |
| 6 类画像定义展示 |
✅ 设计优秀 |
P1-P6 的定义、关键词、策略体系完整 |
| AI 行动规则（4 步流程） |
✅ 可行 |
可直接作为 LLM Prompt 的一部分 |
| 销售经验备注（可添加） |
✅ 高价值 |
团队知识沉淀，可反哺 AI |
| 代表线索预览 |
✅ 可行 |
简单查询 |
⚠️ 需要补足的部分
| 功能 |
当前状态 |
落地所需 |
| 画像定义编辑 |
硬编码在 lead.model.ts |
需要后端 CRUD API，支持管理员编辑画像规则 |
| 关键词管理 |
固定数组 |
支持增删改关键词，修改后实时影响 AI 分类 |
| 经验备注持久化 |
仅内存操作 |
需要数据库存储 |
| 画像效果统计 |
硬编码的 leadCount 和 conversionRate |
需要从真实数据计算 |
💡 技术建议
- 画像知识库是整个系统的核心资产，当前的 6 类画像定义质量很高
- 建议将画像定义存入数据库，作为 LLM Prompt 的动态模板
- 销售经验备注可以用 RAG（检索增强生成）方式注入 AI 上下文
7. 产品目录（Product Catalog）
设计意图：展示公司产品线，支持搜索和按客户类型过滤。
✅ 可行的部分
| 功能 |
可行性 |
说明 |
| 产品卡片展示 |
✅ 完全可行 |
标准商品目录 |
| 搜索 + 客户类型过滤 |
✅ 可行 |
简单查询 |
| 价格展示（批发/零售） |
✅ 可行 |
— |
⚠️ 需要补足的部分
| 功能 |
当前状态 |
落地所需 |
| 产品图片 |
❌ 无图片 |
需要产品图片上传和 CDN |
| 库存状态 |
❌ 无 |
对接 ERP/库存系统 |
| 价格策略 |
固定价格 |
阶梯价格、客户专属价格 |
| 产品编辑 |
硬编码 |
后台管理界面 |
8. 快速筛选服务（QuickScreenService）
设计意图：模拟 AI 对邮件/手动输入进行快速分类。
当前实现 vs 真实需求
| 维度 |
当前（模拟） |
生产（真实） |
| 分类方法 |
classifyByDomain() — 关键词 if-else |
LLM API 调用（GPT-4o / Claude） |
| 国家识别 |
域名后缀推断（.de → DE） |
IP 地理定位 + LLM 推断 |
| 置信度 |
硬编码数值 |
LLM 自评估 + 历史校准 |
| 产品推荐 |
按客户类型固定映射 |
LLM 理解需求 → 语义匹配产品库 |
| 耗时 |
simulateDelay(1500ms) |
真实 LLM 调用 2-5 秒 |
💡 真实实现方案
// 生产环境的 screenEmail 伪代码
async screenEmail(email: Email): Promise<QuickScreenResult> {
// 1. 调用 LLM 进行结构化分析
const llmResult = await this.openai.chat.completions.create({
model: 'gpt-4o-mini',
response_format: { type: 'json_schema', schema: screenResultSchema },
messages: [
{ role: 'system', content: this.buildSystemPrompt() }, // 包含 6 个画像定义
{ role: 'user', content: `邮件主题：${email.subject}\n正文：${email.body}` }
]
});
// 2. 解析结果
const parsed = JSON.parse(llmResult.choices[0].message.content);
// 3. 基于画像匹配产品（规则 + 语义混合）
const products = await this.matchProducts(parsed.persona, email.body);
return { ...parsed, suggestedProducts: products };
}
可行性：✅ 完全可行，GPT-4o-mini 的 JSON 模式输出稳定，成本低（$0.01/次）
三、核心 AI 能力可行性总结
| AI 功能 |
技术成熟度 |
准确率预估 |
成本/次 |
建议 |
| 邮件画像分类（P1-P6） |
⭐⭐⭐⭐⭐ |
85-92% |
$0.01 |
GPT-4o-mini，Prompt 中嵌入画像定义 |
| 价值等级评估（S/A/B/C） |
⭐⭐⭐⭐ |
80-88% |
同上 |
与画像分类一起输出 |
| 关键词提取 |
⭐⭐⭐⭐⭐ |
90%+ |
同上 |
LLM 原生能力 |
| 产品需求提取（从邮件） |
⭐⭐⭐⭐ |
85%+ |
$0.02 |
已有 EML API 支持 |
| 官网抓取 + 分析 |
⭐⭐⭐ |
75-85% |
$0.05-0.15 |
需要 Puppeteer + LLM，反爬是挑战 |
| 竞品分析 |
⭐⭐ |
60-75% |
$0.10+ |
数据源有限，建议作为辅助参考 |
| 销售话术生成 |
⭐⭐⭐⭐ |
N/A |
$0.02 |
LLM 强项，但需要人工审核 |
四、数据源接入可行性
当前系统支持的线索来源
| 来源 |
代码中的 source 值 |
当前状态 |
真实接入方案 |
| 邮件 |
'email' |
✅ 有 EML 导入 + 模拟收件箱 |
IMAP 轮询 / Gmail API |
| 手动录入 |
'manual' |
✅ 有表单 |
已可用 |
| 展会 |
'exhibition' |
❌ 仅硬编码 |
批量 CSV 导入 / 名片 OCR |
| 平台 |
'platform' |
❌ 仅硬编码 |
阿里国际站 API / Made-in-China API |
| AI 发现 |
'ai_discovery' |
❌ 仅定义，无实现 |
定时爬虫 + LLM 筛选 |
各来源接入难度
| 来源 |
难度 |
工期 |
说明 |
| 邮件（IMAP） |
⭐⭐ |
1-2 周 |
成熟方案，imapflow 库 |
| 邮件（Gmail API） |
⭐⭐ |
1 周 |
需要 OAuth 2.0 |
| CSV 批量导入 |
⭐ |
2-3 天 |
前端解析 + 后端存储 |
| 阿里国际站 |
⭐⭐⭐ |
2-3 周 |
需要开放平台账号 + API 对接 |
| 名片 OCR |
⭐⭐ |
1 周 |
用现成 OCR API（百度/腾讯） |
| 网络爬虫发现 |
⭐⭐⭐⭐ |
3-4 周 |
反爬、数据清洗、法律合规 |
五、落地路线图建议
Phase 1：MVP（4-6 周）— 让系统真正能用
✅ 后端 API + 数据库（NestJS/Express + PostgreSQL）
✅ 用户认证（JWT）
✅ 邮件接入（IMAP 轮询，每 5 分钟）
✅ AI 快速筛选（GPT-4o-mini 替换 if-else）
✅ 线索 CRUD + 持久化
✅ EML 导入（已有，保留）
✅ CSV 批量导入（展会/平台线索）
Phase 2：增强（3-4 周）— 提升效率
✅ AI 每日批量处理（定时任务）
✅ 看板拖拽
✅ 画像知识库可编辑
✅ 产品目录管理后台
✅ 销售验证反馈收集
✅ 数据导出（Excel）
Phase 3：智能化（4-6 周）— AI 深度能力
✅ AI 深度调研报告（官网抓取 + 分析）
✅ 产品语义匹配（向量搜索）
✅ 销售话术自动生成
✅ 基于反馈的模型优化
✅ 平台 API 对接（阿里国际站等）
六、结论
整体评价
| 维度 |
评分 |
说明 |
| 业务逻辑设计 |
⭐⭐⭐⭐⭐ |
画像体系、分类流程、跟进阶段设计专业且完整 |
| 数据模型 |
⭐⭐⭐⭐⭐ |
Lead / Email / Product / Persona 模型覆盖全面 |
| UI/UX 质量 |
⭐⭐⭐⭐ |
Material Design 风格统一，交互流畅 |
| AI 功能真实性 |
⭐⭐ |
核心 AI 全部是模拟，需要替换为真实 LLM |
| 数据持久化 |
⭐ |
无后端，刷新全丢 |
| 生产就绪度 |
⭐⭐ |
优秀的原型，但距离生产还需 Phase 1 的全部工作 |
一句话总结
这是一个业务逻辑设计极其优秀的原型系统。 画像体系（P1-P6）、分类流程、产品匹配规则都经过深思熟虑，可直接指导生产开发。当前最大的差距是缺少后端和真实 AI 能力，但所有设计的功能在 2026 年的技术条件下均可实现，核心 AI 分类功能使用 GPT-4o-mini 即可达到 85%+ 准确率，成本可控（日均 $1-3）。建议按 Phase 1 → 2 → 3 的路线图推进，4-6 周即可交付可用的 MVP。
