fix: P0-1 RateLimiter并发写安全 + P0-2工单操作错误码区分 + P1 rows.Close修复
P0-1 (limits.go): Allow()方法改为全程使用写锁保护counters map读写，避免RLock写入时的data race P0-2 (ticket_workflow.go+ticket_handler.go): Assign/Resolve/Close操作先查询ticket存在性和状态，返回明确的CS_TICKET_4001/CS_TKT_4002/CS_TICKET_4092/CS_TICKET_4093错误码，handler根据错误前缀路由HTTP状态码 P1-1 (ticket_store.go): 移除GetStats中3处手动rows.Close()，只保留defer Close()
This commit is contained in:
Your Name
148
prd/competitor-analysis.md
Normal file
148
prd/competitor-analysis.md
Normal file
@@ -0,0 +1,148 @@
|
||||
# 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 容灾设计**: 必须设计主备模型 + 降级方案，避免单点故障。
|
||||
Reference in New Issue
Block a user