干中学奠定的一个起点路飞学城智能客服V1带过在线教育产品的朋友应该都有体会客服永远是最容易被低估的环节。课程咨询、退费规则、学习计划调整、账号异常看起来都是“小事”但一天几百条消息砸过来的时候运营团队基本就陷在复制粘贴里了。我之前在内部一直想做一套能自动应答的客服系统但每次都被“等需求稳定再动”“先跑通流程”这类理由拖着。后来索性换了个思路不追求一上来就完美先做一个智能客服V1用真实业务去磨它边做边学边学边改。这个项目的名字就是这么来的——“干中学-路飞学城智能客服V1”。干中学的意思很直白先搭一个能用的东西在真实使用里发现坑、填坑再迭代。V1的目的也不是炫技而是把最高频、最重复的咨询问题自动化掉让真人客服从机械劳动里腾出手来去处理真正需要人工判断的事情。这篇内容会把整个项目从需求圈定、技术选型、知识库搭建、意图识别、会话管理到联调上线和问题排查的完整过程都讲一遍。如果你想在团队里从零做一个客服机器人又不想被大厂那套复杂的框架劝退这篇应该能给你省不少时间。1. 项目概述V1到底要做什么1.1 核心需求拆解路飞学城算是一个在线课程学习平台用户会反复咨询的东西无非就是几类课程怎么选、价格有没有优惠、学习遇到卡顿怎么办、退课流程怎么走、发票怎么开。这几类问题有一个共同点答案相对固定不依赖具体对话背景。也就是说用户问“你们有没有Python课程”和问“我想学Python但不知道买哪个课”本质上是在问同一件事。这类问题最适合交给机器人处理因为答案明确、判断逻辑简单、不会因为回答偏差引发纠纷。所以V1的需求我圈定为四点覆盖课程咨询、退费规则、账号问题、发票问题这四类高频咨询。支持多轮追问比如用户先问“退费政策是什么”再问“有没有时间限制”机器人要知道他还在聊退费。答不上来的情况下必须转人工不能硬撑。所有对话记录可查方便事后复盘和优化知识库。这四个需求听起来简单但真的落地才发现每一条都有不少学问。尤其是“多轮追问”这一条稍不注意就会做成两个互不相干的问答机器人。1.2 为什么从V1开始而不是直接做完整版很多人在聊智能客服时会直接想到大语言模型、庞大的向量知识库、复杂的对话策略。这些是后来的事V1阶段碰这些很容易翻车。原因其实很现实团队对用户问法没有沉淀数据样本不足业务规则本身还在变比如课程价格经常调整如果系统太复杂改一次规则要动很多地方缺少经验团队里没人完整做过这类项目启动成本必须控制。在干中学的思路下V1的价值不是一步到位而是搭出一条从需求到上线的闭环路径。哪怕效果粗糙有了这条路后续优化才有落点。就像你要去一个没去过的城市先画一张粗线条地图比对着卫星图抠细节更重要。1.3 适用人群与场景边界我建议团队如果满足下面情况可以照这个思路来做业务有一定重复咨询量但还没有条件上大模型团队里有能做简单服务端开发的人业务方愿意配合梳理常见问题清单能够接受初期应答率在七成左右、后续逐步提升的预期。反过来说如果你要处理的对话高度开放、没有固定答案比如情感陪伴类、心理咨询类那V1这种基于规则和关键词的方案就不合适了。还得回到大模型或人机协同方向。这个边界一定要先想清楚不然项目很容易做到一半发现方向就错了。2. 整体设计思路让机器学会“分诊”2.1 从人工客服的思维方式出发我最早在构思这个系统时并没有立刻想技术选型而是先观察真人客服是怎么回消息的。观察下来发现客服的动作其实可以拆成三步判断用户意图也就是用户想干什么查找对应答案从自己的知识库或文档里找组织语言回复如果拿不准就转给更专业的人。这个观察直接影响了我后面的设计。智能客服V1本质上不是做一个“会聊天”的系统而是做一个“会分诊”的系统。它先判断今天来的是什么类型的病人再把病人送到对应的科室。科室里面怎么处理反而可以做得朴素一些。这个思路帮了大忙。因为一旦这样理解系统的各个模块边界就清晰了意图识别负责分诊知识库负责存储答案会话管理负责维持上下文人工接管负责兜底。四个模块各干各的改动起来不会互相拖累。2.2 技术选型不追新只求稳技术选型方面我一开始也心动过那些开源的对话平台。看了一圈发现它们的问题是复杂度超出项目需要。部署一个对话平台往往还要配套学它的对话管理协议、插件机制、权限模型。花在“理解平台”上的时间比花在业务本身上的还多。干中学不等于给自己增加负担学习成本得控制在合理范围。所以最后选了非常传统的一套组合后端直接用轻量级Web服务框架比如Flask或FastAPI意图识别用规则加关键词打分暂时不训练模型知识库用MongoDB存结构化程度不高胜在改起来灵活前端就是一个简单的聊天窗口组件也支持接入企业微信或公众号。这套组合在技术圈看起来可能不够“智能”但它有一个巨大的优势每一行逻辑我都掌握出了问题能够快速定位改个关键词或者加一条知识十分钟内就能生效。对V1来说维护成本比单次响应准确率更重要。2.3 为什么放弃“先训练一个模型”的想法我也考虑过用文本分类模型来做意图识别给它标注几千条语料训练一个意图分类器。算下来标注成本太高了。团队里没人专门做数据标注让运营去标每个人对类别的理解还不一样弄出来的数据质量很难保证。而且课程名、优惠活动这种词一直在变模型的更新周期跟不上业务。规则的局限性我也清楚遇到没见过的说法机器人很可能答不上来。但V1阶段我选择接受这一点因为它的定位本来就是覆盖高频、固定的咨询而不是解决长尾问题。等系统跑起来积累了足够多的真实对话语料再升级意图识别模块也不迟。3. 核心细节解析知识库、意图识别与会话管理3.1 知识库设计把答案拆成“标准问”和“标准答”知识库是整个系统的地基。如果知识库的数据结构设计得不好后面意图识别做得再好也白搭。我用的结构很简单每条知识包含这么几个字段分类对应课程咨询、退费规则这类大方向。标准问题这是这个知识点的“官方问法”。标准答案客服回复的正文。关键词列表用来和用户提问做匹配。附属问题列表常见同义问法。关联知识ID比如用户问完退费规则后可以引导到“申请退课流程”。关键词列表这个设计帮了大忙。比如“退费”它的关键词除了“退费”还会包括“退款”“退钱”“不学了能退吗”“钱能拿回来吗”。只要把运营团队平时收到的真实问法整理一遍关键词覆盖就能做得不错。知识条目不需要一上来就做几百条。我按“先粗后细”的原则第一批只整理了六十多条最核心的知识覆盖大约八成的常见咨询。剩下的长尾问题等上线后根据日志慢慢补。3.2 意图识别从分诊开始用打分排序V1的意图识别没有用模型而是用“关键词命中加加权打分”。实现思路是这样的用户发送一条消息之后系统遍历知识库里的所有知识条目统计这条消息命中了哪些关键词每个关键词有一个预先设定的权重加总后取分数最高的那个分类作为当前意图如果最高分低于阈值就判定为无法识别转人工。举个例子用户问“这个课程学完真的能找到工作吗”里面的关键词“课程”“学完”“工作”会同时命中课程咨询类知识和就业保障类知识。但如果前一类知识条目的总权重更高系统就会优先认为是课程咨询再在回复里附带就业相关的说明。权重怎么定是一个经验活。我一开始给所有关键词都设为1后来发现“退费”这种强烈意图词应该给更高权重不然用户发一句“我不满意想退款”关键词“不满意”会先命中售后反馈类导致意图判断跑偏。后来调整了一下权重强意图词一律设为2或3中性词设为1效果好很多。需要注意的是市面上很多客服系统宣传的语义理解多么智能本质上也只是在这个打分逻辑上加了更复杂的层。对小体量项目来说把关键词打准再辅以同义词扩展就已经能解决不少问题了。3.3 会话管理让机器人记住对话上下文单轮问答最容易做但体验最差。用户问一句“你们有什么Java课”机器人回一句课表这没问题。但用户接着问“哪个适合零基础”如果机器人没记住他刚问过Java课就会一脸懵地回复“您想咨询哪方面课程呢”。这种体验比不做客服机器人还糟糕。会话管理在V1里是用会话ID加状态字段实现的。每个用户在进入对话时分配一个会话ID后端用一张会话表存状态。状态字段包括当前命中的意图分类、最近一次推荐的课程ID、是否已经在退费流程中、是否转人工等。举一个真实发生过的场景。用户先问“Java和Python哪个好上手”机器人回复了一些对比信息并记录了用户的潜在兴趣是“入门”。接着用户问“Python课多少钱”机器人就能结合“用户有入门倾向”这个上下文推荐价格最低的那门入门课。如果会话状态设计得不好这个“结合上下文”的能力根本做不到。3.4 服务接口与前端接入后端接口我设计了三个会话初始化接口在用户进入聊天窗口时调用消息接口接收前端用户消息并返回机器人回复人工接管接口由客服端触发的状态切换。聊天前端最开始用的是网页悬浮窗组件后来又对接了企业微信自建应用的口子用户在公司官网或微信里都能发起咨询。前后端通过HTTP请求交互机器人回复里面带一个专门的字段标明是否是转人工状态前端根据这个字段决定是否弹出“转人工”提示窗口。上线之前我一直担心接口并发问题。后来压测发现基于规则的引擎单机跑个几十并发非常轻松这个V1项目一年之内根本到不了性能瓶颈心就放下来了。4. 实操推进从零搭建到联调上线的完整步骤4.1 第一批知识库的整理方法知识库看似简单做起来最花时间。我找运营同事要了过去三个月的客服聊天记录把它们导出成表格按问题类型做了归类。归类的时候有一个小技巧不要只看标题要读正文因为同一个问题用户会换一百种说法。比如“课程有效期到什么时候”用户在对话里会表达成“我这个课会不会过期”“买完能学多久”“一年后还能看吗”。这些问法如果都靠人工一条条录入效率太低。我的做法是先归类出二十个核心问题再为每个核心问题收集所有问法把高频问法直接作为关键词和附属问题。这一轮整理下来大约花了三个工作日产出六十多条知识和五百多个关键词。这个阶段不要追求数据完美先把框架搭起来后续边用边补比反复修改结构更重要。4.2 关键词与权重的配置过程关键词配置直接决定了意图识别效果。我一开始犯了一个典型错误就是追求关键词数量。结果发现关键词越多误命中越多。比如“怎么”这个词本身没有意义几乎每条问题都会带上把它加入关键词就是给系统添乱。后来我总结了几个原则优先配置有业务辨识度的实体词比如课程名、价格、退款、发票、账号等避免虚词比如“怎么”“如何”“我想问”同义词只收常用说法不搞穷举强意图词给高权重中性词给默认权重。配置流程我放在一个统一的关键词表里定期根据日志调整。比如发现某段时间“课程目录打不开”这类报障问法增多我就会把“打不开”“闪退”提升权重让它们更容易命中故障反馈类。4.3 规则引擎的实现细节规则引擎的核心代码逻辑其实不算复杂。伪代码大致是这样def match_intent(user_message, knowledge_base): best_score 0 best_knowledge None for item in knowledge_base: score 0 for keyword in item.keywords: if keyword in user_message: score keyword.weight if score best_score: best_score score best_knowledge item if best_score THRESHOLD: return None # 转人工 return best_knowledge所有逻辑都在内存里跑没有依赖外部服务。这意味着系统单机部署也能扛住日常压力。但这里的匹配方式要说明一下默认是纯字符串包含判断没有做分词。中文字符串包含有一个问题“退款”能匹配“退款吗”但无法匹配“把钱退给我”。这类说法差异只能靠同义词扩展补。如果后续要升级可以引入分词库比如jieba把分词和词性过滤加进来就能提升泛化能力这是V2值得考虑的方向。4.4 多轮追问的处理策略多轮追问的具体实现我设计了两个机制。第一个是槽位填充。当系统判断出意图是“选课推荐”时它需要知道三个信息感兴趣的编程方向、当前技术水平、学习目标。如果用户在第一条消息里没提供完整信息机器人就会逐条追问直到槽位填满再给出推荐结果。第二个是话题覆盖。系统存了一个字段记录当前对话的话题ID如果用户下一条消息中没有命中任何新的知识分类系统就默认延续上一个话题。比如用户刚问过退费规则接着问“那要多久到账”这句本身没有强意图词但系统因为记住了话题就能关联到退费流程知识回复退款到账时间。这个机制实现起来很简单但对用户体感提升非常明显。实测下来有话题覆盖的会话比没有覆盖的用户多追问一轮的比例高了不少。4.5 转人工机制与人工坐席端转人工机制我是用一个简单的状态标识实现的。只要系统判断分数低于阈值或者用户连续两次说“人工”“转人工”“找人”就会把会话状态置为人工接手。与此同时系统把之前机器人和用户的对话记录打包推送给人工具座席端方便人工快速了解前情。人工坐席端我做得比较朴素就是一个带会话列表和聊天窗口的管理页面。需要保证的就是三件事能看到用户正在输入的最新消息能查看机器人历史回复能修改会话状态把人工处理完的会话重新交还机器人。这个转人工流程看起来基础但上线后是运营同事满意度最高的功能。4.6 上线前的测试与灰度策略上线前测试我用的是“影子模式”。也就是系统在后台对真实聊天记录同时跑一遍但返回结果不直接发给用户只记录到日志里。连续跑一周把机器人的“模拟回复”和真人客服的实际回复做对比根据准确率来调整关键词和知识库。这种方法能让系统在真实数据上成长又不会影响用户体验。影子模式跑到第七天的时候我的模拟准确率大概在七成左右。这个数字作为一个只有规则引擎的V1我认为是可以接受的。之后就开始灰度先放5%的真实流量观察两天没有异常再逐步提升到30%、50%最后全量。灰度期间机器人只负责回答课程咨询和账号类问题退费和发票这种涉及资金和用户敏感信息的问题一律转人工。5. 常见问题排查与避坑经验记录5.1 典型的线上问题表现上线一个月后日志里逐渐暴露出一些有意思的问题。我整理了一个速查表列在这里方便参考问题现象可能原因解决动作用户问A问题系统回答成B问题关键词权重设置不当B分类被误命中检查B分类里的通用关键词降低权重或删除用户换个说法就答不上来同义词覆盖不足从日志里提取高频未命中问法加入关键词表机器人“失忆”记不住上下文会话状态超时或会话ID没有正确传递确认前端每次请求都带上会话ID检查状态过期时间多轮追问陷入死循环槽位填充里的枚举值没有兜底选项增加“其他”选项不满足条件时直接转人工回复内容太长用户只看一句标准答案里口语化程度不够把标准答案拆成“一句话结论详细说明”两层其中会话ID没传这个坑被我踩过。最开始前端只在初始化时拿一次会话ID但用户刷新页面后前端没有重新拉取导致后续消息都用了一个失效的ID。后端查不到会话状态就回退成单轮问答模式。后来把会话ID的获取逻辑挪到了每次点击聊天窗口的时候这个问题就消失了。5.2 需要特别注意的三个细节第一回复文案要像人话。很多机器人答不上来时会回复“对不起我不理解您的意思”这种话用户看到就想关窗口。我把无法识别时的兜底回复改成了一段解释性文案说明机器人能帮用户做什么并引导用户触发常见问题菜单比如“您可以试试问我有什么Java课/课程怎么退款/怎么联系人工”。实测点击率明显提升。第二知识库一定需要有负责人。项目上线后业务规则会不断变化比如某个课程停售了、退款时限从三天改成七天。如果没有人专门维护知识库系统很快会给出过期信息造成客诉。我在团队里安排了一位运营同事兼职做知识库管理员每次规则变更都同步更新知识内容并且保留变更记录这样出了问题也能追溯。第三日志一定要留足。我在项目里做了两个层次的日志一份是原始聊天记录一份是每次机器人做出决策的中间信息比如命中了哪些关键词、各项得分多少、为什么选这个答案。没有这层中间日志想复盘一个答错的问题只能靠猜效率极低。有了决策日志排查就变成了读记录的问题。5.3 从V1到后续迭代的思考跟这个项目跟了两个月我最大的体会是干中学的核心不是“边做边学”这四个字本身而是你要敢把一个不完美的系统扔到真实环境里然后快速迭代去修补它。V1的效果一定不是最好的它甚至连“智能”都算不上但它帮团队真正跑通了一条自动应答的链路沉淀出了一套知识库的维护方法也验证了哪些用户问题适合机器处理、哪些必须人工介入。后续想升级的方向已经有眉目了。一是把分词引入意图识别替换掉纯字符串包含的匹配方式解决同义泛化问题。二是基于这几个月积累的对话日志去标注一批高质量数据训练一个真正的文本分类模型。三是把客服后台的报表做起来让运营每周都能看到答非所问的案例持续迭代知识库。最后再分享一个实际经验不要只盯着准确率这个数字。我见过有人把一个客服机器人的准确率从70%调到82%结果用户满意度反而下降了。原因就是那12%的提升是靠牺牲转人工门槛换来的也就是系统更敢“硬答”了答案错了用户更生气。准确率只是手段让用户的问题得到解决才是这个项目真正的目的。V1阶段宁可在边界处多转人工也别为了好看的数据强行回答。这个原则我到现在都觉得很值得坚持。
