startup-plan/客服设计详案.md at 5c3f4930712c3fa7f0639636ed3e2b35df59ab97

WangDL 5c3f493071 docs(startup-plan): 重构项目文档结构，整合所有产品决策

- 删除旧版 v0.1 规划，只保留完全版
- 更新全部 7 大模块文档，补充具体决策和实操内容
- 新增 AI架构设计、营销冷启动调研方案、客服设计详案等子文档
- 新增 潜在问题清单（56项技术+方向问题）
- 整理图片到 images/ 目录

2026-05-12 17:07:28 +08:00

6.2 KiB

Raw Blame History

对，你这个判断是对的。你一个人做产品，如果没有 App 内客服 / 自动答疑系统，后面会非常累，而且体验也会很怪。

用户遇到问题时，他不一定想发邮件，也不一定愿意等你手动回复。尤其是这些基础问题：

怎么创建知识库？
为什么 Apple 登录失败？
AI 分析结果怎么看？
会员怎么取消？
退款怎么处理？
安卓什么时候上？
数据会不会丢？
上传文件失败怎么办？

这些如果都靠你一个人回，肯定扛不住。

所以这里应该做一个：

App 内智能客服 + 反馈工单 + 后台处理系统

而不是单纯一个“意见反馈表单”。

它在知习里的定位

你可以这么定义：

Dify 智能客服负责解决常见问题；
反馈系统负责收集真实问题；
后台管理系统负责处理需要人工介入的问题。

它不是学习 Agent，不参与主动回忆、薄弱点分析、复习计划这些核心学习闭环。核心学习 AI 还是走你自己的后端工作流。你的当前主线仍然是把 iOS App 从静态 UI 变成真实功能 App。

我建议的客服流程

可以这样设计：

用户在 App 内点击“帮助与客服”
→ 先进入智能客服
→ Dify 根据帮助知识库自动回答
→ 如果解决了，结束
→ 如果没解决，用户点击“转人工 / 提交反馈”
→ 后端创建反馈工单
→ 后台显示待处理问题
→ 你有空再处理

这样你不是所有问题都要立刻回，而是让系统先挡住 70% 的基础问题。

第一版客服应该回答什么

第一版只回答官方固定内容：

功能使用说明
登录问题
知识库创建问题
文件上传问题
AI 分析说明
复习计划说明
订阅说明
退款流程说明
隐私政策
用户协议
备案信息
常见错误处理
联系方式

不要让客服 Bot 去读用户私人知识库内容。

这点很重要。

客服 Bot 只应该读：

官方帮助中心知识库

不要读：

用户上传的学习资料
用户的主动回忆回答
用户的私人知识库
用户的学习分析结果

除非以后你专门做了授权机制。

你真正需要的是三层系统

第一层：App 内智能客服

用户问基础问题，机器人自动回。

比如：

“怎么取消订阅？”
“怎么导入知识点？”
“为什么我的 AI 分析失败？”

机器人可以直接回答流程。

第二层：反馈 / 工单系统

如果机器人解决不了，就创建反馈。

反馈字段可以有：

用户 ID
联系方式
问题类型
问题内容
截图
设备型号
系统版本
App 版本
当前页面
处理状态
创建时间

问题类型可以先分成：

功能问题
登录问题
订阅问题
退款问题
AI 分析问题
上传问题
数据问题
建议反馈
其他

第三层：后台处理

你在后台看到：

待处理反馈
高频问题
用户对话记录
是否已解决
是否需要回复
是否需要更新帮助文档

这样你不是被动被消息轰炸，而是集中处理。

哪些问题机器人可以处理

可以自动处理：

功能怎么用
按钮在哪里
复习计划怎么理解
AI 分析结果是什么意思
会员权益说明
取消订阅流程
退款流程说明
隐私政策说明
常见错误排查

哪些问题必须转人工

这些不要让机器人自己处理：

退款争议
账号删除
数据丢失
订阅权益异常
用户投诉
隐私问题
内容违规问题
支付失败但扣款
Apple / Google 订单问题

机器人可以先收集信息，然后创建工单。

比如：

这个问题可能需要人工处理。我已经帮你记录反馈，请补充你的订阅平台、订单时间和问题截图。

技术上怎么接

推荐结构是：

iOS App
→ 你的 NestJS 后端
→ Dify API
→ Dify 知识库

不要让 iOS 直接调用 Dify。

原因是：

Dify API Key 不能暴露在客户端
客服会话需要绑定 userId
问题记录要进你的数据库
后续要接后台工单
要做限流和审计

后端接口可以先设计成：

POST /api/support/chat
POST /api/support/feedback
GET  /api/support/conversations
GET  /api/support/feedbacks/my

后台接口：

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 个页面就够：

帮助与客服页
智能客服聊天页
提交反馈页

“我的”页面里放入口：

帮助与客服
问题反馈
隐私政策
用户协议
关于知习

后台第一版加：

反馈列表
反馈详情
客服会话记录
问题分类统计

Dify 知识库你可以先准备这些文档

知习是什么
如何创建知识库
如何添加知识点
如何开始主动回忆
AI 分析结果怎么看
待巩固项是什么
复习计划是什么
如何修改个人资料
如何取消订阅
如何申请退款
Apple 登录失败怎么办
上传文件失败怎么办
数据安全说明
隐私政策摘要
联系客服方式

这些文档以后也可以直接变成 App 内帮助中心内容。

最重要的一点

智能客服不是为了“假装有人回复”，而是为了：

基础问题自动解决
复杂问题收集完整信息
你只处理真正需要人工判断的问题

你一个人做产品，合理的客服策略应该是：

机器人先答
答不了再建工单
你集中处理高价值问题
高频问题沉淀进帮助知识库

这样系统会越来越省你的时间。

我的建议

你现在可以把它加入规划，而且我建议尽早预留后端模块：

support
feedback
support_tickets
support_conversations
admin_support

但第一版不要做复杂在线客服。先做：

Dify FAQ 客服
+ App 内反馈
+ 后台工单列表
+ 人工状态处理

一句话总结：

你确实应该做 App 内智能客服；它的价值就是替你挡住基础问题，把真正需要人工处理的问题变成后台工单，而不是让所有用户消息都直接压到你一个人身上。

6.2 KiB Raw Blame History Unescape Escape