149 lines
6.0 KiB
Markdown
149 lines
6.0 KiB
Markdown
|
# AI-Customer-Service 智能客服 — 竞品分析报告
|
|||
|
|
|
|||
|
|
## 1. 竞品范围
|
|||
|
|
|
|||
|
|
| 竞品 | 项目地址 | 技术栈 | 相关能力 |
|
|||
|
|
|-------|---------|--------|---------|
|
|||
|
|
| **Sub2API** | Wei-Shaw/sub2api | Go/Gin/Ent | 平台公告系统（定向、排期、弹窗通知） |
|
|||
|
|
| **LiteLLM** | berriai/litellm | Python/FastAPI | 无直接客服能力，仅有用户/团队管理 |
|
|||
|
|
| **NewAPI / OneAPI** | Calcium-Ion/new-api | Go/Gin/GORM | 用户反馈/工单功能（基础） |
|
|||
|
|
|
|||
|
|
注：LLM Gateway 类产品普遍缺乏内建的 AI 客服能力，这正是我们的机会。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2. 核心能力对标
|
|||
|
|
|
|||
|
|
### 2.1 平台公告系统（Sub2API）
|
|||
|
|
|
|||
|
|
Sub2API 的公告系统是当前竞品中最接近客服沟通的能力，其设计值得借鉴：
|
|||
|
|
|
|||
|
|
**数据模型**:
|
|||
|
|
```go
|
|||
|
|
type Announcement struct {
|
|||
|
|
ent.Schema
|
|||
|
|
}
|
|||
|
|
// Fields:
|
|||
|
|
// title — 公告标题（200字）
|
|||
|
|
// content — 内容（Markdown，text 类型）
|
|||
|
|
// status — draft / active / archived
|
|||
|
|
// notify_mode — silent(仅铃铛) / popup(弹窗)
|
|||
|
|
// targeting — 展示条件（JSONB 规则）
|
|||
|
|
// starts_at — 开始时间
|
|||
|
|
// ends_at — 结束时间
|
|||
|
|
// created_by — 管理员ID
|
|||
|
|
// reads — 已读记录关联
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**关键设计细节**:
|
|||
|
|
- **状态机**: draft → active → archived，支持预发布审核
|
|||
|
|
- **通知模式**: 静默模式（仅显示红点）vs 弹窗模式（强制届到）
|
|||
|
|
- **定向规则**: JSONB 存储展示条件，支持按用户群体定向
|
|||
|
|
- **排期管理**: starts_at / ends_at 支持时间窗控制
|
|||
|
|
- **已读跟踪**: `AnnouncementRead` 关联表，记录每个用户的阅读状态
|
|||
|
|
- **索引优化**: status, created_at, starts_at, ends_at 均有索引
|
|||
|
|
|
|||
|
|
**公告阅读流程**:
|
|||
|
|
```
|
|||
|
|
用户登录 → 查询有效公告列表
|
|||
|
|
→ 应用 targeting 规则过滤
|
|||
|
|
→ 检查已读状态
|
|||
|
|
→ 弹窗/铃铛通知
|
|||
|
|
→ 用户阅读 → 写入 AnnouncementRead
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 2.2 用户与订阅体系（Sub2API）
|
|||
|
|
|
|||
|
|
Sub2API 提供了完整的用户身份与使用情况查询能力，这是客服系统的基础数据来源：
|
|||
|
|
|
|||
|
|
- `User`: 基础用户信息
|
|||
|
|
- `UserSubscription`: 订阅计划、配额、到期时间
|
|||
|
|
- `UsageLog`: 详细用量记录（模型、token 数、成本、时间戳）
|
|||
|
|
- `ApiKey`: 用户 API Key 管理
|
|||
|
|
- `PromoCode` / `RedeemCode`: 营销代码
|
|||
|
|
|
|||
|
|
**用户分组与权限**:
|
|||
|
|
- `Group`: 用户分组
|
|||
|
|
- `UserAllowedGroup`: 用户-分组关联
|
|||
|
|
- `AccountGroup`: 上游账号分组
|
|||
|
|
|
|||
|
|
### 2.3 用户反馈（NewAPI/OneAPI 基础功能）
|
|||
|
|
|
|||
|
|
NewAPI/OneAPI 提供基础的工单/反馈功能：
|
|||
|
|
- 用户可提交问题反馈
|
|||
|
|
- 管理员可回复
|
|||
|
|
- 状态跟踪（待处理/处理中/已解决）
|
|||
|
|
- 缺乏 AI 自动回复和知识库支持
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 3. 差距分析（我们的机会）
|
|||
|
|
|
|||
|
|
| 能力维度 | 竞品现状 | 我们的机会 |
|
|||
|
|
|---------|---------|---------|
|
|||
|
|
| **AI 自动回复** | 竞品均不具备 | 基于 RAG 的知识库自动回复，核心差异化 |
|
|||
|
|
| **多渠道接入** | Sub2API 仅支持内置公告 | 支持 Telegram/Discord/微信/邮件/网页 Widget |
|
|||
|
|
| **意图识别** | 竞哆均不具备 | LLM 驱动的意图分类，准确定位问题 |
|
|||
|
|
| **上下文感知** | 竞品均不具备 | 维护对话上下文，支持多轮对话 |
|
|||
|
|
| **人工转接** | NewAPI 有基础工单，但无智能转接 | 智能转接：AI 无法解决时自动升级到人工客服 |
|
|||
|
|
| **运营大盘** | Sub2API 有基础用户/用量查询 | 客服专属运营大盘：问题分类、解决率、响应时间、用户满意度 |
|
|||
|
|
| **自动化工单** | NewAPI 有基础工单，需人工处理 | 自动化工单分派：基于问题类型和客服负载 |
|
|||
|
|
| **知识库** | 竞品均不具备 | 维护知识库，支持 Markdown 和语义检索 |
|
|||
|
|
| **用户身份核验** | Sub2API 有完整的用户体系 | 直接复用，支持通过多种渠道认证用户 |
|
|||
|
|
| **用量查询** | Sub2API 有 UsageLog 和订阅体系 | 直接复用，支持客服场景下的快速查询 |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 4. 对产品规划的影响
|
|||
|
|
|
|||
|
|
### 强化方向
|
|||
|
|
|
|||
|
|
1. **公告系统参考 Sub2API**：
|
|||
|
|
- 状态机：draft → active → archived
|
|||
|
|
- 通知模式：silent / popup
|
|||
|
|
- 定向规则：按用户群体、渠道、版本号定向
|
|||
|
|
- 时间窗管理：starts_at / ends_at
|
|||
|
|
- 已读跟踪
|
|||
|
|
|
|||
|
|
2. **用户体系参考 Sub2API**：
|
|||
|
|
- 用户/订阅/用量的关联查询
|
|||
|
|
- API Key 状态查询
|
|||
|
|
- 用户分组与权限
|
|||
|
|
|
|||
|
|
3. **工单系统参考 NewAPI**：
|
|||
|
|
- 基础工单状态机
|
|||
|
|
- 用户反馈收集
|
|||
|
|
|
|||
|
|
### 新增差异化能力
|
|||
|
|
|
|||
|
|
4. **AI 自动回复**：竞品不具备，是核心差异化
|
|||
|
|
- 基于 RAG 的知识库查询
|
|||
|
|
- 意图识别与问题分类
|
|||
|
|
- 对话上下文维护
|
|||
|
|
5. **多渠道接入**：支持 Telegram/Discord/微信/邮件/网页 Widget
|
|||
|
|
6. **智能转接**：AI 无法解决时自动升级到人工客服
|
|||
|
|
7. **运营大盘**：客服专属的运营分析视图
|
|||
|
|
8. **自动化工单**：基于问题类型和客服负载的智能分派
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 5. 对技术规划的影响
|
|||
|
|
|
|||
|
|
### 应引入的设计模式
|
|||
|
|
|
|||
|
|
| 设计模式 | 来源 | 应用场景 |
|
|||
|
|
|---------|------|---------|
|
|||
|
|
| **公告状态机** | Sub2API | 客服公告/通知的发布流程管理 |
|
|||
|
|
| **通知模式** | Sub2API | 静默 vs 弹窗的分级触达 |
|
|||
|
|
| **Targeting 规则** | Sub2API | 按用户群体、渠道、版本号定向推送 |
|
|||
|
|
| **已读跟踪** | Sub2API | 通知透达率统计 |
|
|||
|
|
| **用户-订阅-用量关联** | Sub2API | 客服场景下的用户信息快速查询 |
|
|||
|
|
| **工单状态机** | NewAPI | 问题跟踪与处理流程 |
|
|||
|
|
|
|||
|
|
### 技术避坑
|
|||
|
|
|
|||
|
|
1. **知识库选型**: Sub2API 的 PRD 建议在 TechLead 前完成 Milvus/Qdrant/PGVector 的 POC，验证中文检索延迟 < 200ms。竞品分析建议优先考虑 PGVector（与 PostgreSQL 集成，减少运维复杂度），次之 Qdrant（轻量级），最后 Milvus（大规模场景）。
|
|||
|
|
2. **对话上下文存储**: 需要设计高效的对话上下文管理机制，支持长对话上下文的截断与摘要。
|
|||
|
|
3. **多渠道适配层**: 每个渠道（Telegram/Discord/微信）都有独特的消息格式和限制，需要适配层抽象。
|
|||
|
|
4. **LLM 容灾设计**: 必须设计主备模型 + 降级方案，避免单点故障。
|