Files

Your Name cf46b27610 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()

2026-05-01 20:56:25 +08:00

6.0 KiB

Raw Permalink Blame History

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 的公告系统是当前竞品中最接近客服沟通的能力，其设计值得借鉴：

数据模型:

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. 对产品规划的影响

强化方向

公告系统参考 Sub2API：
- 状态机：draft → active → archived
- 通知模式：silent / popup
- 定向规则：按用户群体、渠道、版本号定向
- 时间窗管理：starts_at / ends_at
- 已读跟踪
用户体系参考 Sub2API：
- 用户/订阅/用量的关联查询
- API Key 状态查询
- 用户分组与权限
工单系统参考 NewAPI：
- 基础工单状态机
- 用户反馈收集

新增差异化能力

AI 自动回复：竞品不具备，是核心差异化
- 基于 RAG 的知识库查询
- 意图识别与问题分类
- 对话上下文维护
多渠道接入：支持 Telegram/Discord/微信/邮件/网页 Widget
智能转接：AI 无法解决时自动升级到人工客服
运营大盘：客服专属的运营分析视图
自动化工单：基于问题类型和客服负载的智能分派

5. 对技术规划的影响

应引入的设计模式

设计模式	来源	应用场景
公告状态机	Sub2API	客服公告/通知的发布流程管理
通知模式	Sub2API	静默 vs 弹窗的分级触达
Targeting 规则	Sub2API	按用户群体、渠道、版本号定向推送
已读跟踪	Sub2API	通知透达率统计
用户-订阅-用量关联	Sub2API	客服场景下的用户信息快速查询
工单状态机	NewAPI	问题跟踪与处理流程

技术避坑

知识库选型: Sub2API 的 PRD 建议在 TechLead 前完成 Milvus/Qdrant/PGVector 的 POC，验证中文检索延迟 < 200ms。竞品分析建议优先考虑 PGVector（与 PostgreSQL 集成，减少运维复杂度），次之 Qdrant（轻量级），最后 Milvus（大规模场景）。
对话上下文存储: 需要设计高效的对话上下文管理机制，支持长对话上下文的截断与摘要。
多渠道适配层: 每个渠道（Telegram/Discord/微信）都有独特的消息格式和限制，需要适配层抽象。
LLM 容灾设计: 必须设计主备模型 + 降级方案，避免单点故障。

6.0 KiB Raw Permalink Blame History Unescape Escape