340 lines
6.2 KiB
Markdown
340 lines
6.2 KiB
Markdown
对，你这个判断是对的。**你一个人做产品，如果没有 App 内客服 / 自动答疑系统，后面会非常累，而且体验也会很怪。**
|
||
|
||
用户遇到问题时，他不一定想发邮件，也不一定愿意等你手动回复。尤其是这些基础问题：
|
||
|
||
```text
|
||
怎么创建知识库？
|
||
为什么 Apple 登录失败？
|
||
AI 分析结果怎么看？
|
||
会员怎么取消？
|
||
退款怎么处理？
|
||
安卓什么时候上？
|
||
数据会不会丢？
|
||
上传文件失败怎么办？
|
||
```
|
||
|
||
这些如果都靠你一个人回，肯定扛不住。
|
||
|
||
所以这里应该做一个：
|
||
|
||
```text
|
||
App 内智能客服 + 反馈工单 + 后台处理系统
|
||
```
|
||
|
||
而不是单纯一个“意见反馈表单”。
|
||
|
||
## 它在知习里的定位
|
||
|
||
你可以这么定义：
|
||
|
||
```text
|
||
Dify 智能客服负责解决常见问题；
|
||
反馈系统负责收集真实问题；
|
||
后台管理系统负责处理需要人工介入的问题。
|
||
```
|
||
|
||
它不是学习 Agent，不参与主动回忆、薄弱点分析、复习计划这些核心学习闭环。核心学习 AI 还是走你自己的后端工作流。你的当前主线仍然是把 iOS App 从静态 UI 变成真实功能 App。
|
||
|
||
## 我建议的客服流程
|
||
|
||
可以这样设计：
|
||
|
||
```text
|
||
用户在 App 内点击“帮助与客服”
|
||
→ 先进入智能客服
|
||
→ Dify 根据帮助知识库自动回答
|
||
→ 如果解决了，结束
|
||
→ 如果没解决，用户点击“转人工 / 提交反馈”
|
||
→ 后端创建反馈工单
|
||
→ 后台显示待处理问题
|
||
→ 你有空再处理
|
||
```
|
||
|
||
这样你不是所有问题都要立刻回，而是让系统先挡住 70% 的基础问题。
|
||
|
||
## 第一版客服应该回答什么
|
||
|
||
第一版只回答官方固定内容：
|
||
|
||
```text
|
||
功能使用说明
|
||
登录问题
|
||
知识库创建问题
|
||
文件上传问题
|
||
AI 分析说明
|
||
复习计划说明
|
||
订阅说明
|
||
退款流程说明
|
||
隐私政策
|
||
用户协议
|
||
备案信息
|
||
常见错误处理
|
||
联系方式
|
||
```
|
||
|
||
不要让客服 Bot 去读用户私人知识库内容。
|
||
|
||
这点很重要。
|
||
|
||
客服 Bot 只应该读：
|
||
|
||
```text
|
||
官方帮助中心知识库
|
||
```
|
||
|
||
不要读：
|
||
|
||
```text
|
||
用户上传的学习资料
|
||
用户的主动回忆回答
|
||
用户的私人知识库
|
||
用户的学习分析结果
|
||
```
|
||
|
||
除非以后你专门做了授权机制。
|
||
|
||
## 你真正需要的是三层系统
|
||
|
||
### 第一层：App 内智能客服
|
||
|
||
用户问基础问题，机器人自动回。
|
||
|
||
比如：
|
||
|
||
```text
|
||
“怎么取消订阅？”
|
||
“怎么导入知识点？”
|
||
“为什么我的 AI 分析失败？”
|
||
```
|
||
|
||
机器人可以直接回答流程。
|
||
|
||
### 第二层：反馈 / 工单系统
|
||
|
||
如果机器人解决不了，就创建反馈。
|
||
|
||
反馈字段可以有：
|
||
|
||
```text
|
||
用户 ID
|
||
联系方式
|
||
问题类型
|
||
问题内容
|
||
截图
|
||
设备型号
|
||
系统版本
|
||
App 版本
|
||
当前页面
|
||
处理状态
|
||
创建时间
|
||
```
|
||
|
||
问题类型可以先分成：
|
||
|
||
```text
|
||
功能问题
|
||
登录问题
|
||
订阅问题
|
||
退款问题
|
||
AI 分析问题
|
||
上传问题
|
||
数据问题
|
||
建议反馈
|
||
其他
|
||
```
|
||
|
||
### 第三层：后台处理
|
||
|
||
你在后台看到：
|
||
|
||
```text
|
||
待处理反馈
|
||
高频问题
|
||
用户对话记录
|
||
是否已解决
|
||
是否需要回复
|
||
是否需要更新帮助文档
|
||
```
|
||
|
||
这样你不是被动被消息轰炸，而是集中处理。
|
||
|
||
## 哪些问题机器人可以处理
|
||
|
||
可以自动处理：
|
||
|
||
```text
|
||
功能怎么用
|
||
按钮在哪里
|
||
复习计划怎么理解
|
||
AI 分析结果是什么意思
|
||
会员权益说明
|
||
取消订阅流程
|
||
退款流程说明
|
||
隐私政策说明
|
||
常见错误排查
|
||
```
|
||
|
||
## 哪些问题必须转人工
|
||
|
||
这些不要让机器人自己处理：
|
||
|
||
```text
|
||
退款争议
|
||
账号删除
|
||
数据丢失
|
||
订阅权益异常
|
||
用户投诉
|
||
隐私问题
|
||
内容违规问题
|
||
支付失败但扣款
|
||
Apple / Google 订单问题
|
||
```
|
||
|
||
机器人可以先收集信息，然后创建工单。
|
||
|
||
比如：
|
||
|
||
```text
|
||
这个问题可能需要人工处理。我已经帮你记录反馈，请补充你的订阅平台、订单时间和问题截图。
|
||
```
|
||
|
||
## 技术上怎么接
|
||
|
||
推荐结构是：
|
||
|
||
```text
|
||
iOS App
|
||
→ 你的 NestJS 后端
|
||
→ Dify API
|
||
→ Dify 知识库
|
||
```
|
||
|
||
不要让 iOS 直接调用 Dify。
|
||
|
||
原因是：
|
||
|
||
```text
|
||
Dify API Key 不能暴露在客户端
|
||
客服会话需要绑定 userId
|
||
问题记录要进你的数据库
|
||
后续要接后台工单
|
||
要做限流和审计
|
||
```
|
||
|
||
后端接口可以先设计成：
|
||
|
||
```text
|
||
POST /api/support/chat
|
||
POST /api/support/feedback
|
||
GET /api/support/conversations
|
||
GET /api/support/feedbacks/my
|
||
```
|
||
|
||
后台接口：
|
||
|
||
```text
|
||
GET /api/admin/support/tickets
|
||
GET /api/admin/support/tickets/:id
|
||
PATCH /api/admin/support/tickets/:id
|
||
POST /api/admin/support/tickets/:id/reply
|
||
```
|
||
|
||
## 第一版页面建议
|
||
|
||
App 里做 3 个页面就够：
|
||
|
||
```text
|
||
帮助与客服页
|
||
智能客服聊天页
|
||
提交反馈页
|
||
```
|
||
|
||
“我的”页面里放入口：
|
||
|
||
```text
|
||
帮助与客服
|
||
问题反馈
|
||
隐私政策
|
||
用户协议
|
||
关于知习
|
||
```
|
||
|
||
后台第一版加：
|
||
|
||
```text
|
||
反馈列表
|
||
反馈详情
|
||
客服会话记录
|
||
问题分类统计
|
||
```
|
||
|
||
## Dify 知识库你可以先准备这些文档
|
||
|
||
```text
|
||
知习是什么
|
||
如何创建知识库
|
||
如何添加知识点
|
||
如何开始主动回忆
|
||
AI 分析结果怎么看
|
||
待巩固项是什么
|
||
复习计划是什么
|
||
如何修改个人资料
|
||
如何取消订阅
|
||
如何申请退款
|
||
Apple 登录失败怎么办
|
||
上传文件失败怎么办
|
||
数据安全说明
|
||
隐私政策摘要
|
||
联系客服方式
|
||
```
|
||
|
||
这些文档以后也可以直接变成 App 内帮助中心内容。
|
||
|
||
## 最重要的一点
|
||
|
||
智能客服不是为了“假装有人回复”，而是为了：
|
||
|
||
```text
|
||
基础问题自动解决
|
||
复杂问题收集完整信息
|
||
你只处理真正需要人工判断的问题
|
||
```
|
||
|
||
你一个人做产品，合理的客服策略应该是：
|
||
|
||
```text
|
||
机器人先答
|
||
答不了再建工单
|
||
你集中处理高价值问题
|
||
高频问题沉淀进帮助知识库
|
||
```
|
||
|
||
这样系统会越来越省你的时间。
|
||
|
||
## 我的建议
|
||
|
||
你现在可以把它加入规划，而且我建议尽早预留后端模块：
|
||
|
||
```text
|
||
support
|
||
feedback
|
||
support_tickets
|
||
support_conversations
|
||
admin_support
|
||
```
|
||
|
||
但第一版不要做复杂在线客服。先做：
|
||
|
||
```text
|
||
Dify FAQ 客服
|
||
+ App 内反馈
|
||
+ 后台工单列表
|
||
+ 人工状态处理
|
||
```
|
||
|
||
一句话总结：
|
||
|
||
```text
|
||
你确实应该做 App 内智能客服；它的价值就是替你挡住基础问题，把真正需要人工处理的问题变成后台工单，而不是让所有用户消息都直接压到你一个人身上。
|
||
```
|