# 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 容灾设计**: 必须设计主备模型 + 降级方案，避免单点故障。