上个月我在某电商公司喝茶听到老板在走廊上对运营组长说你们组最近是不是偷偷申请了加人名额我怎么看后台夜里还有三个客服在线值班。运营组长一脸懵说没有啊就我一个人。老板说那凌晨两点的退款咨询是谁在回复早上六点的发票问题又是谁处理的运营组长指了指我旁边工位的阿凯都是他那套用 DeepSeek Dify 搭的东西在自动回复。老板愣了几秒然后说那你等于招了三个人啊。这个故事后来我在不止一个技术群里讲过每次讲完都有人追问真的假的一个人真能顶三个客服答案是真的能但前提是你把客服这份工作拆开看拆对了。这篇文章就把阿凯那套系统的完整链路、选型逻辑、落地步骤和踩坑记录拿出来聊聊想在公司复刻一套的人可以直接照着这个思路走。1. 这个项目到底做了什么一个AI客服背后其实藏着三个岗位很多人听到“AI客服”第一反应就是“接个大模型API写个Prompt挂到网页上”。真这么简单老板就不会产生“招了三个人”的错觉了。阿凯一个人干完的实际上是三个岗位的活。1.1 “三个岗位”是怎么拆出来的第一个是客服运营/产品岗。要把日常客服说的话、解决过的问题、公司已有的FAQ、售后政策、产品手册全部整理成结构化的知识。这一步不是丢给模型就完事你需要想清楚什么问题必须答对、什么问题可以转人工、什么话术是公司底线性要求。第二个是开发/算法岗。要选模型、搭知识库、做向量检索、写工作流编排、把AI客服嵌进网页和IM工具、处理并发和限流、设计转人工的兜底逻辑。这一层才是真正的“系统”。第三个是运维/分析岗。客服机器人上线之后日志得有地方看、答错的要能捞出来、知识库要每周更新、用户情绪和转人工率要持续监控。阿凯的日常就是上午调工作流节点下午改知识库分段规则晚上看日志挑错。一个人干了三个人的事老板看到的后台数据自然像有三个人在轮班。1.2 这不是聊天机器人而是一个“能办事”的系统这里要划个重点AI客服和通用聊天机器人是两回事。聊天机器人可以天南海北地聊但客服系统必须守边界——它要能查订单、能引导退款、能发起售后工单、能在解决不了时把人转给真人员工。阿凯的这套系统最终跑起来的链路是这样的用户进来先判断意图再检索知识库生成回答如果遇到投诉、退款、反复追问这类敏感场景自动转人工如果判断用户要查订单就通过工单接口调用后台数据返回结果。整条链路里模型承担的是“理解和生成”而“流程控制”由工作流平台完成两边配合才像一个完整的客服系统。2. 为什么是 DeepSeek模型选型背后的成本账与效果账选模型是整个方案里最容易被忽视、但最影响结果的一步。阿凯当时也纠结过要不要用更贵的商用大模型API后来算了一笔账才定下来。2.1 客服场景对模型能力的要求其实很“刁钻”客服输入和写文章完全不一样。用户不会给你一段完整规范的文本而是经常出现“我上周买的那个蓝色玩意你们发错颜色了咋办”“退退退不要了”“付了钱一直不发货”中文口语化、错别字、语义省略、情绪化表达这些都需要模型有很强的中文理解能力。DeepSeek在中文场景的表现并不比当时的主流商用模型差尤其在意图识别和口语改写上反馈比较稳。这点在客服场景里权重极高因为你没法要求用户把问题写规范了再提问。另外客服回答要简洁、准确、语气可控。DeepSeek本身对指令跟随的执行力不错配合Prompt约束之后基本能稳定输出“一句话结论一句操作指引”的风格。2.2 我们来算一笔成本账客服系统的成本账不能只看模型API价格要把并发、调用量、维护成本都算进去。阿凯当时拉了一个表对比了三类方案对比项雇佣一个人工客服传统关键词问答机器人DeepSeek Dify月基础成本工资社保数千元起开发维护成本高且要持续配置关键词API调用费按量付费并发处理能力一次只能服务一个人简单问题可并发复杂问题基本废掉可并发能处理复杂语境回答质量最稳但依赖个人经验生硬覆盖范围小依赖知识库质量稳定后可接近人工维护成本培训新人成本高关键词表越维护越庞大主要是知识库更新具体到API费用按当时的DeepSeek定价如果把单轮对话控制在1500 token左右约用户输入300字系统输出200字一个月跑一万轮对话费用基本是几十元到一百多元的级别。这个价格比雇佣客服便宜了两个数量级比商用通用模型API也便宜一大截。阿凯当时算完直接定了他。有一种说法是“模型越贵越聪明”在纯开放域聊天里成立但在客服场景里决定上限的是知识库而不是模型价格。模型再聪明如果知识库检索不到正确资料照样会答错。所以选模型的核心指标是中文理解够用、支持函数调用/结构化输出、成本可控、有条件私有化部署。2.3 数据不出内网也是一条硬约束某电商公司当时有几份售后政策、价格文件和内部流程文档老板明确说这些不能送到外部模型去训练也不能随便让第三方平台存。这个约束就把很多商用模型挡在门外了。DeepSeek这个选择的价值在于如果你只是调用API数据是服务端接收一次推理请求如果后续政策收紧它还有开源版本可以拿去私有化部署模型参数和业务数据都能留在内网。有这条“退路”在方案在公司层面的接受度会高很多。2.4 最关键的一个认知模型不是用来“背答案”的这个认知我想单独强调一下阿凯的系统里DeepSeek从不靠自己的记忆回答业务问题。所有价格、政策、退换货规则全部来自知识库检索结果。模型只负责“基于检索到的内容组织成一段客服话术”。背后的原因是模型训练数据里的信息可能过时也可能和你公司的规定不一致。靠检索增强生成RAG这种方式知识库更新了回答就跟着更新模型本身完全不需要重新训练。这也是为什么整套系统里最重的活是知识库建设而不是模型调优。3. Dify 在中间扮演的“胶水”角色它到底代替了多少代码DeepSeek是“大脑”Dify就是“神经系统”。没有Dify这种平台实现同一个需求你要写的代码量保守估计翻三到五倍。3.1 没有Dify时这个项目要写多少代码先捋一捋实现AI客服需要的手工活准备一个向量数据库自己管理文档切片写Embedding调用逻辑写召回逻辑还要考虑阈值和排序设计一套Prompt模板管理多轮对话上下文写API服务端处理流式响应给前端网页写聊天组件给企业微信/飞书写机器人适配再做一个后台日志页面方便自己排查问题这一整套做完正常得一两周还得有人在后面持续维护。Dify把这些事情做成了“配置项”知识库上传文档之后自动完成切块和向量化工作流用画布拖拽编排应用可以一键发布成API自带日志和标注功能。对单人或小团队来说这省下的不止是时间而是“能不能做得成”的区别。3.2 Dify里的核心物件其实就四样把Dify拆开看阿凯用的东西主要就四类知识库上传FAQ、帮助文档设置分段规则自动向量化支持检索测试应用类型聊天助手、Agent、工作流、Chatflow聊天工作流等。AI客服用的是Chatflow工作流节点开始、LLM、知识检索、条件分支、变量赋值、HTTP请求、结束节点等发布通道发布成网页应用、API接口、嵌入脚本理解了这个结构再看整套系统就不神秘了知识库负责“资料”LLM节点负责“生成”条件分支负责“决策”HTTP请求负责“对接外部业务系统”。Dify解决的是把这些东西串联起来的工程问题。3.3 一条完整Chatflow长什么样这条流程直接用文字描述比画图更直观用户消息进来先进入“问题分类器”LLM节点。这一步判断用户是想咨询发票、退货还是投诉、闲聊。如果判断为业务咨询走到知识库检索节点用用户问题和Embedding模型算相似度把最相关的前三条记录取出来。在生成节点里Prompt把检索结果拼进去要求“只根据资料内容作答资料里没有就说不确定并引导转人工”。在条件分支节点里判断是否触发转人工用户明确要求人工、情绪激烈、知识库分数过低、LLM输出的标记字段是true。转人工路径调用企业微信机器人接口把会话转给值班客服不转人工则直接把回答返回给用户。每个节点都能单独调试。阿凯做得最多的操作就是“把某条真实用户会话拖进调试台看每一步输出什么”这种可视化排错能力在传统代码开发里要多花几倍时间才能做到。3.4 三个容易被忽略但很重要的设置日常使用中很多人只调“模型”和“知识库”但下面三个设置对结果影响极大必须注意会话变量用来在单个用户会话里传递“用户ID”“订单号”这类信息。设计好变量后续调接口、记日志都会轻松很多。温度参数客服场景建议把温度调到0到0.3之间。温度越高模型越“自由发挥”客服回答不需要文学创作低温度更稳定。引用出处在回答里带上“参考了哪条知识”方便用户看到来源也方便你排查错误回答到底来自哪份文档。4. 从零搭到上线完整实施步骤复盘如果看完前面思路你已经决定在公司内部试一套下面是阿凯实际操作时走通的完整步骤。每一步都有坑顺序也最好不要乱。4.1 第一步把客服脑子里的知识搬进知识库知识库是整个系统的地基。阿凯当初花了一周多时间做这件事而不是先急着写Prompt。第一步是把客服聊天记录里高频问题整理出来做成“问答对”格式。FAQ适合直接整理成“问题-答案”条目每条独立检索命中率最高。第二步是处理公司已有的帮助中心文章、售后政策PDF、价目表这类长文档需要切分。切分规则直接沿用常见做法按段落切分段长度控制在几百个token每段之间保留部分重叠避免一句话被拦腰切断。Embedding模型的选型上如果嫌外部API有诸多限制可以用本地部署的开源Embedding模型例如BGE-M3这类效果不错且能完全内网运行。文档全部向量化之后一定要做的验证动作是“拿真实问题去检索”看返回的前几条到底相不相关。这一关不过后面模型生成再漂亮都白搭。4.2 第二步写一套“知道自己是客服”的提示词知识库搭好之后Prompt决定AI的性格和边界。阿凯的系统提示词大框架是这样的你是某电商公司的人工智能在线客服助手你的名字是“小E”。 你的任务是根据“知识库”中提供的资料回答用户问题。 必须遵守的规则 1. 只依据知识库内容回答不得编造任何价格、活动或政策信息。 2. 如果知识库中没有相关内容请直接回答“这个问题我需要帮您转接人工处理”不要尝试猜测。 3. 回答风格要礼貌、简洁、口语化避免长篇大论。 4. 涉及退款、投诉、人身攻击、催发货等敏感场景必须输出“转人工”标记。 5. 如果用户主动要求人工立即输出“转人工”标记。 每次回答前先判断是否需要转人工如果需要回答格式为 [转人工] 原因xxx 否则正常回答用户问题。注意里面“转人工”标记是通过约定标准字段输出的这样后面的条件分支节点才能读取并决定跳转路径。Prompt写得“像制度”比写得“像聊天”更重要模型会把规则执行得更稳定。4.3 第三步接上人工兜底和工单链路AI客服一定要给自己留“认怂”的出口。阿凯设计了三级转人工触发第一级关键词触发。用户消息里出现“人工、投诉、退款、差评”等词直接转人工。第二级情绪触发。系统检测到用户多次重复同一个问题、语气强烈、连续追问判定为潜在不满意用户转人工。第三级知识兜底。知识库检索分数过低或者LLM输出为“[转人工]”进入人工通道。转人工后会话记录要完整带过去接入企业微信客服由真人客服继续处理。同时可以通过HTTP请求节点把会话生成一条工单提交到公司内部工单系统记录来访时间、问题分类、处理状态。这样老板在后台看到的就是“三个客服在值班”的效果——人工只处理被升级进来的少数会话其余全被AI消化掉了。4.4 第四步用测试集逼着自己修问题这部分最容易被跳过但也是阿凯的系统和“玩具Demo”拉开距离的关键。他从真实客服会话里抽了200条高频问题做成了测试集覆盖售前、售后、物流、价格、退换货五个分类。每改一次知识库或Prompt就把这200条问题跑一遍统计三个指标指标含义阿凯当时的优化目标准确率回答内容是否与标准答案一致从65%提到90%以上兜底率触发转人工的比例控制在15%以内越权率模型回答明显超出知识范围越低越好有些问题效果一直不好就回到知识库看是检索不到还是检索到了但排名太低还是Prompt表达有歧义。反复迭代几轮之后整套系统才真正稳定下来。5. 上线一个月我记下来的真实踩坑记录跑起来只是开始真正见功力的是上线之后排坑。以下都是实际踩过的问题不是Demo演示能暴露的。5.1 知识库命中率低问题不在模型在分段和检索上线第三天准确率突然掉到谷底。查日志发现用户问“手机壳多久发货”这种问题知识库里明明有答案但检索不到。后来发现问题是文档分段。那篇发货说明文章里“发货时间”被写在一大段介绍的最末尾切分的时候被切碎了导致只有单独包含这句话的片段才召回而片段里的上下文又不够形成完整回答。解决办法是把长文档按“标题正文”的结构重切同时把每个段落的首句设计成核心结论。如果你不确定怎么切可以直接用Dify的分段规则试几个参数拿真实问题去对照召回结果。另外在检索后面加了Rerank环节把候选结果重新排序。这两项改动之后准确率直接拉了十几个百分点。5.2 会话记忆越长回答越“飘”上下文管理有段时间用户问连续的问题模型回答开始出现前后矛盾的情况。原因是多轮对话默认会把历史消息全送进模型上下文越长模型越被历史信息干扰而且费用也在涨。后来在Dify里把历史消息轮数限制为最近六轮再配合“如果用户新问题语义不完整优先参考最新消息”的Prompt指令回答稳定性明显好转。成本方面单日token消耗也降了大概三分之一。上下文不是越多越好够用就行这个度需要一个月的数据来校准。5.3 客服的“温度”被模型学歪了上线初期回答经常出现“亲非常抱歉给您带来不便呢”“咱们马上帮您处理哟”这类话术。阿凯本来没觉得有问题客服经理看了一遍后直摇头我们客服正常说话没有那么“甜”用户会被搞得很尴尬。调整方案是给Prompt加了一句“语气自然、克制不要使用过度亲昵的称呼不要使用网络用语和重复叠词”同时把温度从默认0.7降到0.2。效果立竿见影。客服场景的“温度”是建立在准确和克制基础上的太过拟人反而显得假。5.4 并发、限流与半夜告警项目第一次遇到流量高峰是在一次促销活动上线后。大量用户同时咨询Dify默认的并发限制被顶满部分用户消息提示“排队中”体验很不好。后来把DeepSeek侧的并发上限和Dify侧的工作流并发都做了规划同时在系统里设置了每分钟调用量的监控告警超过阈值会通知到群里。还有一次凌晨出现了模型接口超时原因是那天半夜知识库更新任务和在线服务抢资源。从那之后知识库更新都改到凌晨低峰期跑并且更新完必须自动跑一遍核心测试集防止新文档把旧知识顶掉。5.5 数据回流AI客服如何越用越聪明最后一条是最容易被忽视的日志不是只用来排查问题的它是知识库迭代的源泉。阿凯每周末干一件事把这一周所有“AI回答被用户点了踩”的会话捞出来整理出高频没有覆盖的问题下一周写进知识库。同时把“转人工但确实能在知识库找到答案”的案例找出来反向修正检索逻辑。这个数据回流机制跑了一个月之后转人工率从最初的20%左右降到了10%上下准确率也稳定到了90%左右。AI客服的“聪明”不是一蹴而就的而是靠持续的数据反馈养出来的这一点没法偷懒。6. 老板为什么会觉得“招了三个人”可复制的经验与延伸前五章聊的是技术最后想聊聊这套系统的真正价值以及你自己复刻的时候需要具备什么。6.1 一个人的工具箱三个人的岗位阿凯这套方案的本质是把“客服组长、后端开发、运维分析”三个岗位的日常任务压缩到了一个人加上两个开源工具里。这确实会让老板产生“你背后是不是有一支团队”的错觉。但这件事的前提是得有人既懂业务流程又愿意碰代码和Prompt还愿意持续看日志。工具只能降低门槛不能替代判断力。如果公司里有人能吃透这三个角色的部分职责哪怕只做到六十分配合Dify和DeepSeek这套组合也能在一个月内交付一个真正可用的AI客服。6.2 换到你公司先准备这三件事别急着选模型和平台先确认三件事有没有足够的真实客服对话记录如果没有AI客服没有学习素材只能从0开始摸索话术。业务方愿不愿意每周花时间对知识库做审核知识库是持续运营的资产不是上线后就静止的文件。有没有一个明确的“转人工”通道如果公司连人工客服都没有AI客服的兜底就无从谈起。这三件事里缺任何一件建议先补齐再动工。6.3 同样的架构还能复制到哪这套“DeepSeek Dify 知识库 转人工”思路换个知识库内容就是另一套系统。内部IT支持可以用它回答办公软件问题人事部门可以用它处理入离职和假期咨询销售团队可以用它做产品资料的实时问答甚至财务部门催报销进度也可以用类似方案。AI客服只是个起点它证明的是一件更大的事原本需要一整个技术团队才能交付的企业内部智能应用现在一个熟悉业务的聪明人配上开源模型和低代码平台就可能直接做出来。这种“一个人顶一个小组”的现象会越来越多地出现在我们身边。最后再说一个我自己的观点如果你想复刻这套东西不要在模型选型和平台选择上纠结太久DeepSeek和Dify都已经是非常成熟的开源选项。真正花时间的应该是文档清洗和知识库迭代那才是AI客服的地基。地基打扎实上面哪怕换个模型、换个平台系统都不会塌地基不牢再强的模型也救不回来。