1.1 业务痛点：一个五人客服组每天答一百个重复问题

我们公司做一款面向中小团队的 SaaS 产品，注册用户不少，付费转化主要靠官网引流。客服组一共五个人：组长老周，两个干了两年多的老员工，还有三个入职不到半年的新人。产品上线四年，功能越加越多，客服工单也跟着年年涨。到今年，客服组每天平均要处理一百出头的工单——这个数是我们后来做需求调研时，让老周从工单系统连续导了两周得出来的，没掺水。

一周工单分类统计

最开始 CEO 对一百这个数字没概念，觉得客服不就是聊聊天。我懒得跟他吵，直接让老周按工单分类导了某一周（周一到周日）的完整明细，自己用表格归拢了一下：

看起来单个工单处理时长都不长，但架不住量大。一百个工单乘以平均八分钟，一天就是十三个小时以上的人力——五个人满负荷也紧紧巴巴。更要命的是，我逐条翻了这一周的记录，其中至少六成的问题，答案是固定那几句：发票走哪个流程、验证码收不到先查什么、导出入口在哪个菜单，帮助中心全都写着，客户就是不看，客服就得一遍遍复述。老周说他在工位上一天下来，脑子里全是同一套话术循环播放，下班一句话都不想说。

为了确认这周是不是特例，我又让老周导了前两周的数据做交叉验证：各类占比浮动不超过三个百分点，结论稳定。另外一个细节引起了我的注意：晚上八点到十点还有一个小高峰，是客户下班后集中处理工作的时间段，而那个时段客服已经陆续下班，工单只能堆到第二天早上，第二天一早系统里总是先积一波。

算一笔人力账

我把这张表又往前推了一步。按客服平均月薪折算成时薪，再把每类工单的日均量乘上处理时长，得出一个粗糙但不失真的结论：我们每个月花在重复问答上的人力成本，足够再雇半个客服；而客服组真正值钱的工作——故障排查、大客户跟进、把用户吐槽沉淀成产品改进建议——反而被挤到了加班时间。老周跟我抱怨过好几次：新人培训两三个月刚上手，又觉得天天复制粘贴没有成长，提了离职；招人、培训、再离职，这个轮转让他心力交瘁。损耗的不只是钱，还有团队的稳定性。我私底下算过一笔账：招一个新人，招聘加两个月带教，真要能独立干活得花小半年，这期间他处理的问答质量还得老员工兜底；等他能独立顶班了，也就到了离职高发期。这笔账怎么算都亏。

客服工作里还有一个看不见的成本：知识断层。老员工脑子里记着各种边角案例和临时口径，文档里没写，人一走就带走了；新人只能靠翻群聊记录和厚着脸皮问人，成长速度完全看运气，同一个问题不同老员工还可能给出两种答案，客户体验像开盲盒。这正是知识库和 AI 能补上的地方——把藏在人脑子里的隐性知识，变成团队可检索、可复用的显性资产。

响应时效的瓶颈

真正让我下定决心的是一件事。周二下午我们发了个小版本，改了导出功能的入口位置。当天下午四点开始，产品咨询类的工单突然涌进来二十多条，全是问导出按钮去哪了。新人不熟悉旧版本布局，只能一边翻 FAQ 文档一边回消息，一条工单来回确认两三轮，平均耗时直接拉到十五分钟以上。老周自己也在处理工单，企业微信里还不断有客户私聊追问，回慢了客户就催，催急了就有人投诉态度问题。

那天晚上我留下来加班，把这二十多条工单的记录从头看了一遍，发现答案都在帮助中心里躺着。客服不是不会答，而是要在多个文档间翻找、确认版本、再组织语言发出去，而且每个人每次都要重复这个过程。新人翻文档的时间是老员工的三倍，回答质量还看运气。有的客户等不及，同一问题在工单、邮件、企业微信三个渠道各问一遍，客服就要回三遍，工单系统里重复单乱飞。那一刻我突然想通一件事：我们缺的不是更努力的客服，而是一个随叫随到、永不疲倦、答案始终最新的前端入口。

那天之后我又观察了三天，发现问题的全貌比这一晚更难看：每天早上的工单积压要消化一个小时，客服打开电脑第一件事是回昨夜留言；遇到产品发版，当天的平均响应时长直接翻倍；周末只留一个人值班，遇到突发就是灾难现场。客服并不是不努力，五个人已经把响应时效压到了团队极限，人力这条路到头了，剩下的只能靠工具。

官网本身是拿轻量服务器搭起来的，帮助中心也挂在同一套站点上。官网和帮助中心怎么从零搭起来，可以看我另一本轻量建站实战，这里就不展开了。

什么样的重复问题适合交给 AI

拍脑袋说一句全交给 AI 是不靠谱的。我跟老周把高频问题一条一条过了一遍，总结出一个判断标准，直接上结论：

按这个标准套下来，我们工单里大约六成可以纳入 AI 的服务范围。其中产品咨询和账号登录两类覆盖得最干净，张口就是固定答案；价格与售后的固定部分也能覆盖大半；故障类反而要留给人——排查往往要看用户的截图、后台日志和具体操作环境，这种非结构化的沟通 AI 目前顶不住。

举一个具体的对照：验证码收不到这条问题，排查涉及手机信号、邮箱拦截、企业邮箱网关等多种原因，人工客服靠经验一步步引导，处理时长五分钟左右，但成功率稳定；同样的问题丢给大模型，不给调取日志的工具，它只能把帮助中心那段通用说明复述一遍，跟没答差不多。所以后来这类问题的分工是：AI 先接住通用部分并给出自助排查清单，真正复杂的由 AI 带着对话记录转给人工，人工从中间接手而不是从头问起。

这张表后来被贴在客服组墙上，来了新工单先照着过一遍，成了判断哪些问题值得进知识库的第一道筛子，也奠定了后面所有选型和设计的基础。

还有一个判断维度是错误答案的代价。客服口头说错一句，大不了道个歉纠正；系统性的错误回答被成百上千个访客看到，损失的是信任。所以涉及价格、合规、法律边界的问题，我们要求回答必须引用知识库原文，宁可说不知道也不能现编。客服组长对这条最满意——他们被瞎编价格的坑过，有次客服随口说能打折，客户拿着截图来要求兑现，最后只能捏鼻子认了。这条原则后来写进了提示词，是全书所有调试的前提。

这就是本书要做的项目

跟 CEO 碰了一次，目标定了：做一个企业 AI 智能客服助手，挂在官网访客侧，覆盖产品、价格、账号这一类高频问答；同时给客服自己开一个内部知识检索入口，让新人不用再靠翻群聊成长；能查订单的走工具调用，不再让人肉去系统里查；知识库覆盖不了的问题，自动转人工工单并把完整对话上下文一并转交，绝不能让客户感觉被踢皮球。技术底座用腾讯云那一套：智能体平台做编排核心，对象存储 COS 放知识库原文，API 网关对外，云服务器 CVM 跑业务后端，轻量任务交给云函数。整套架构听起来产品不少，但每个产品都有明确的分工，后面每一篇都会对应落地，不用一次性全搞懂。怎么一步步从零搭起来，就是后面二十几篇要讲的事。衡量这件事成败的指标，我们也提前定了两条：一是重复工单占比能不能从六成降到三成以下，二是转人工之后的客户满意度不能掉低于原来的水平。先存着这两条，第五篇会拿出来对照验收。定目标的时候老周提了个要求：别让 AI 把客服的活抢没了，我们一致同意——这个项目的定位是帮客服挡住重复问题，不是替代他们。客服转去做更有价值的排查和大客户跟进，这才是大家想看到的局面。

公司做 SaaS，自己服务却还停留在人肉客服阶段，CEO 觉得这事说出去不好听，加上每年客服组的扩编申请，压力全压在我这边。作为技术负责人，兼着后端和半个架构的活儿，我对 AI 的态度一直很实际：能省人力的就用，不能省的就老老实实放给人做。这一节先把痛点和数据摊开，不谈技术，只谈问题本身——因为后面所有的技术选择，都是被这些数据推着走的。

做需求调研的那半个月，我把客服问答的口径碎片顺手理了一份笔记，用的是知识库整理的那套标签体系，具体方法写在笔记知识库里，后来正式整理知识库时确实帮上大忙。老周也把他脑子里的边角案例一条条口述给我，我录音转文字再归档，这部分原料后来成了知识库最宝贵的一批内容。开工之前，我把调研结论做了一页总结发给 CEO：重复工单六成可覆盖，月成本半个客服，四周出 MVP。他回了两个字：搞吧。

延伸阅读

• 想对比本地知识库方案的，看NAS 家庭服务器。
• 知识管理方法论，看笔记知识库。