这是这个系列的最后一篇。前面九篇分别讲了 AI 客服的各个侧面——架构演进、模型选型、知识库、多场景处理、人机协同。这篇把它们串起来按时间线讲从零到上线的完整流程给准备动手的人一张路线图。一、流程全景接入 AI 客服不是写代码的事是项目推进的事。完整流程分五个阶段准备 → 验证 → 开发 → 试运行 → 正式上线每个阶段有不同的目标和产出物跳过任何一个后面都要补课。二、准备阶段先把底摸清动手前要搞清楚四件事业务现状。当前客服团队多少人、日均消息量多少、客户问题集中在哪几类、高峰期是什么时候。没有这些数据AI 客服做到什么程度算成功都没法定义。知识库盘点。公司有没有现成的 FAQ、产品文档、客服话术库。有的话整理成可用的格式没有的话先建没知识库的 AI 客服等于没接。团队分工。谁做接口对接、谁调 prompt、谁管知识库、谁做质检。AI 客服是持续运营项目不是做完就不用管了。预算评估。模型 API 月费、向量库费用、服务器费用、人力维护成本。算清楚月均开销别跑到一半发现预算扛不住。准备阶段的产出物一份业务现状报告、一份知识库清单、一份分工表、一份预算表。三、验证阶段最小闭环跑通不写完整系统先验证技术路线走得通。最小闭环就三步开通企微 API扫码登录拿 appid配回调地址收到客户消息代码里把消息转发给模型 API把模型回复发回企微这三步 50 行代码能搞定。目的是验证API 能收消息、模型 API 能调通、回复能发回企微。# 最小验证闭环 app.post(/hook) async def hook(request): body await request.json() msg extract_text(body) # 提取文本 if msg: reply await llm.chat(msg) # 调模型 send_text(appid, body[conversationId], reply) # 发回复 return {}用一周时间收集 50-100 条真实客户消息人工评估 AI 回复可用率。可用率超过 50% 值得往下做低于 30% 先补知识库。这个阶段的成本极低但决定了项目要不要继续。四、开发阶段搭完整架构验证通过后进入开发。按模块拆分每个模块独立开发独立测试回调处理模块。验签、去重、入队、异步分发。这是基础设施所有后续功能都建在这上面。规则引擎模块。高频问题的关键词匹配和固定回复。先做 20 条规则覆盖最高频的问题。AI 对话模块。上下文管理、prompt 工程、模型调用、回复格式化。核心是 prompt 设计和上下文窗口管理。知识库模块。文档切片、向量化、检索、结果格式化。知识库质量决定 AI 回复质量多花时间在切片和标注上。转人工模块。置信度判断、紧急问题识别、值班通知、次日处理队列。人机协同的边界全在这里。# 完整处理流程 def handle_message(msg, session): # 1. 规则优先 rule rule_engine.match(msg) if rule: return execute_rule(rule, session) # 2. 知识库检索 docs retrieve_knowledge(msg, top_k3) if not docs: return transfer_human(session, 知识库未覆盖) # 3. AI生成 reply, confidence ai_generate(msg, session, docs) # 4. 质量兜底 if confidence 0.6: return transfer_human(session, 置信度不足) return reply开发阶段建议 4-6 周别拖太长。先做核心闭环规则AI转人工监控和统计后做。五、试运行阶段小范围验证开发完了别直接上线先试运行。选一个小范围比如一个客服号、一类客户跑 2 周指标跟踪。自动回复覆盖率、AI 回复可用率、转人工率、客户满意度。问题收集。AI 回复不合格的、知识库没覆盖的、规则误触发的全记下来分类。迭代优化。试运行期间每天看数据、调 prompt、补知识库。这是个快速迭代期别怕改。试运行的退出标准AI 回复可用率 70%知识库覆盖率 80%客户投诉 1%转人工率 30%达不到就继续优化达到了再进入正式上线。六、正式上线灰度推进试运行达标后别一次性切全量。灰度推进第一周覆盖 20% 客户盯监控第二周覆盖 50%收集反馈第三周覆盖 100%每步都有回退方案——监控指标恶化就回退到上一步。回退不是失败是负责任。上线后的日常运维每日AI 回复质量抽检、转人工问题分析每周知识库更新、prompt 调优、规则库维护每月效果评估报告、模型成本核算、下月优化计划七、整个流程的时间线参考阶段时长产出准备1-2 周业务报告、知识库清单、预算表验证1 周最小闭环、可用率评估开发4-6 周完整系统试运行2 周指标达标、问题修复上线3 周灰度全量总计3-4 个月时间线不是死的团队能力强、知识库已有积累可以压缩团队没经验、知识库要建可以拉长。但别压缩验证和试运行这两步省了后面翻车概率极高。八、几个常见误区跳过验证直接开发。没验证模型对业务问题的回答能力开发完发现可用率低浪费 4 周。试运行时间太短。跑 3 天觉得没问题就上线客户问题有周期性至少跑 2 周才能覆盖工作日和周末的不同模式。知识库做一次性。上线后不更新知识库产品迭代后 AI 回的还是旧内容。知识库是活物要持续维护。没有回退方案。灰度推进时没有指标恶化就回退的机制出了问题硬扛小问题拖成大事故。接口对接的细节在开发文档里开通测试在Eyun平台。整个流程的第一步就在这里——开通、跑通最小闭环、评估可用率后面的事看这步的结果决定。写在最后四批四十篇到这里就结束了。最后这篇讲的是方法论准备充分再动手、最小验证再开发、试运行再上线、灰度再全量。这个节奏看起来慢实际比快速开发、火速上线、紧急回退的快节奏省时间。AI 客服是长期项目不是一次性交付做扎实了后面省心做糙了后面天天救火。