企业做 AI 客服，第一版最容易做偏的地方，是把目标写成“替代人工客服”。
这个目标听起来完整，但工程上太粗。售后客服不是一个单点问答窗口，它背后有工单系统、知识库、订单数据、权限边界、转人工规则和技术支持流程。只看模型能不能回答一句话，基本判断不出系统能不能上线。
更稳的切入点，是先做一个客服协同智能体：它不承诺替代整个售后团队，而是先把工单分流、知识库命中、上下文整理和转人工交接跑稳定。
先把问题从“能不能替代人”拆成“哪段流程最重复”
售后团队里最消耗时间的，通常不是复杂投诉，而是大量重复问题和低质量交接。
客户问安装步骤、账号权限、发票开具、退款进度、故障排查。客服要先判断问题类型，再查 SOP、翻知识库、看订单状态，必要时问技术。换一个处理人以后，客户又要重新讲一遍背景。
AI 客服第一期要解决的不是“所有问题都自动闭环”，而是让这条链路少断几次：问题先进来，系统先分类；能查知识库就给标准答案；缺字段就补问；需要转人工时，把上下文整理好再交出去。
第一版建议拆成四个模块
第一层是入口和分类。来自在线客服、企微、表单、App 反馈、售后群的问题，进入系统后先做类型判断。安装、账号、发票、故障、退款、投诉升级，不同问题对应不同处理路径。
第二层是知识库检索。这里不要只做向量库问答。真正要落地，至少要区分 FAQ、SOP、产品文档、历史工单和人工补充答案。模型可以负责组织语言，但答案来源要能追溯。
第三层是字段补齐。故障类问题缺设备型号、报错截图、发生时间；退款类问题缺订单号和支付渠道；账号类问题缺企业 ID 和用户角色。AI 客服要知道缺什么，而不是每次都问一句“请详细描述一下问题”。
第四层是转人工和日志。转人工时不能只扔一句“用户需要帮助”。更好的交接内容应该包括客户身份、问题类型、已尝试方案、命中的知识库条目、缺失字段、当前状态和建议下一步。
这类项目最容易踩的坑
第一个坑是把知识库问答当成完整客服系统。知识库只能解决“答案在哪里”，不能解决“谁有权限处理”“工单状态怎么变”“什么时候必须转人工”。
第二个坑是没有人工确认点。涉及退款、赔付、合同、故障定责、投诉升级的问题，不能让模型直接拍板。第一版应该明确哪些动作只能建议，哪些动作允许自动执行。
第三个坑是没有过程日志。一次分流为什么进了故障类，知识库命中了哪条，人工为什么改了分类，这些都要记录。否则系统上线以后，出了问题只能靠猜。
第四个坑是没有知识库反写。人工处理完的新问题，如果不会沉淀回知识库，AI 客服就会一直停在旧答案里。客服系统会变成一个好看的入口，而不是一个会变好的流程。
验收标准不要只看回复效果
Demo 里模型回复得自然，不代表它能进真实售后。
更实际的验收标准应该是：工单分类准确率是否可复盘；知识库答案是否能追溯来源；缺失字段是否能自动补问；转人工摘要是否能让客服直接接手；人工修改分类后，系统是否记录原因；同类新问题是否能沉淀到知识库。
这些指标不花哨，但它们决定系统能不能被客服团队持续使用。
写在最后
AI 客服的第一步，不是把人拿掉。
更现实的价值，是先把重复咨询、工单分流、字段补齐、转人工交接这些高频动作跑顺。等这些基础链路稳定以后，再去扩自动处理范围，风险会小很多。
