客服 70% 的时间
在回答同样的问题

原来的样子

售后接到咨询，先在微信里问「你是哪台设备、什么型号、什么问题」，然后翻 PDF 手册、翻历史维修记录、问技术部。一个问题平均来回 6–8 条消息，才能给出答案。技术部同时在装机器，经常两小时后才回。

客户的感受是「找不到人」。而企业真正的问题不是人手不够，是知识没有被组织成可以检索的东西：手册有 400 页、维修记录在 Excel 里、老师傅的经验在他自己脑子里。

我们的判断

先不要做「在线客服系统」，先做「一个能被问出答案的知识库」。

很多企业一上来就想上一套带工单、带 SLA、带质检的客服平台，结果发现最核心的问题没解决：AI 也好、新人也罢，都答不上来。所以我们把项目拆成了两件事：

1. 把知识整理成机器能读的结构——按设备型号、故障现象、处理步骤切片，而不是整本手册丢进去。
2. 做一个「先答后转」的问答入口——AI 有把握就答，没把握就带着上下文转人工，人工的回答自动回流进知识库。

怎么做的

1. 知识切片

把 400 页手册按「现象 → 可能原因 → 处理步骤 → 需要的配件」重新组织，每条独立成块，附带型号与适用条件。这一块花了整个项目一半的时间，但它是后面所有效果的地基。

2. 检索 + 生成

客户用自然语言描述问题（「机器报警 E03 怎么回事」），系统先检索相关片段，再由大模型组织成一段人话回答，并附上手册页码与处理步骤截图。关键约束：回答只能来自知识库，不允许自由发挥，避免编造维修方案。

3. 人工兜底与回流

置信度低的直接转人工，并把这轮对话的上下文一起带过去。人工答完后，一键把答案补充进知识库——系统会越用越准。

4. 入口放在客户已经在的地方

没有做 App。入口有两个：官网的一个页面，和企业微信客服的自动回复。客户不需要学新东西。

结果与目标

说明：以上为立项时共同确认的验收方向。实际达成取决于知识整理的完整度与一线使用习惯，我们不做跨项目的效果承诺。

复盘：哪一步最容易翻车

不是模型选型，是知识质量。同样的模型，喂进去「整本 PDF」和喂进去「切片后的 300 条结构化问答」，效果差一个量级。第二个容易翻车的地方是「没人维护」——所以我们在交付时把「人工答完一键入库」做成了一个按钮，而不是一份需要培训的流程文档。

还有一个反直觉的结论：不要追求 100% 自动。把自动处理率做到 70%、剩下 30% 快速转人工，客户体验比「AI 硬答但答错」好得多。我们在界面上明确标注了「以下回答来自知识库，仅供参考，涉及安全操作请以工程师确认为准」。