一个跑了两年多的 AI 客服陪跑项目里，AI 已覆盖超七成客服场景、承接接近一半真实流量，可综合成本仍然高于人工。从能回答到能干活，中间隔着场景、数据、权限、评测与人工兜底等一整套工程。

今天的案例是我们最近 2 年创业一个比较重要的 AI 客服陪跑项目，其中数据全部脱敏、并且取得了甲方的认同，现在整理发出，应该是关于 AI 客服比较系统性的文章，能写的知识都写了，不能写的，可能只能线下聚会敞聊了…

甲方是国内一家电商公司，原本在上海、成都和武汉都有客服团队。上海团队服务成本最高，一张工单的综合处理成本达到数十元，一名客服一天大约只能处理二三十单。团队已经优化过话术、排班和客服系统，但人的操作速度基本到了上限。

这里的意思，传统数字化、管理动作上的工作已经做了，就去年我们的看法，一致认为只能 AI 切入，不然无法继续提升了。

成都和武汉原本合计有数十名客服。随着业务调整和自动化系统逐渐上线，常驻的一线人员已经缩减到个位数。

公司接下来的计划，是继续收缩高成本的上海团队，在成都和武汉保留一支规模很小的兜底队伍，让 AI 承接大部分标准化服务。

可以看出来，这个项目从最初就是带着裁员的目的出发的，而这也使得 AI 客服项目从一开始就背负了很重的任务。

因为这里的核心是替代人或者某个人物，所以和一般的“Demo 类项目”差距很大，它不能只做一个展示效果不错的智能问答，也不能只帮客服把话说得更漂亮。

项目正关心的是：AI 能不能独立处理用户问题，能不能查订单、改状态、发起售后，能不能逐步接走原来由几十个人完成的工作。

我们在做这个项目的时候，也是分不同阶段的，一开始，AI 只能回答规则明确的政策咨询；几个月后，它已经覆盖超过七成的客服场景，并承接了接近一半的真实流量（这个公司流量很大！）。

而这里也先分享个可能会突破大家认知的问题：

现在 AI 和人工相比，成本到底差多少？

目前 AI 的综合成本仍然高于人工

可能很多老板就傻眼了，AI 已经接管了接近一半的流量，公司也在持续缩减客服团队，为什么反而更贵？

这个矛盾反而真实展示了生产级 AI 客服的真实面貌：从能回答到能干活，中间隔着场景、数据、权限、系统、评测、运营和人工兜底等一整套工程。

接下来，我便为大家做详细展开：

目标：替代人

我们在之前也跟很多公司做过知识库类项目，但至少从他们表面告诉我的目标都是“更好的知识问答、或者更好的数据检索”。

比如，企业把商品说明、售后政策和常见问题上传到知识库。用户提出问题，系统检索相关资料，再由大模型组织成一段通顺的回答。

理想很美好、现实很无奈，一般来说这套系统在 Demo 阶段表现都很不错、也不费什么成本，但只要他敢上生产，马上全部完蛋！

因为，用户一定不会按照你预想的方式去问，并且你还会不住的骂这批用户不会问、实在太愚蠢了，给套好系统都用不明白！

例如，我们期待用户的问题是：

退货期是多久

答案可以直接从规则中找到，但真实情况用户的问题是：

我上周买的商品已经拆封

用了两次感觉有问题

现在还能不能退？

这个处理起来就很麻烦，系统需要继续完成多步判断：

1. 找到用户所说的具体订单；
2. 确认下单时间和签收时间；
3. 判断商品所属类别；
4. 检查该品类是否支持拆封退货；
5. 判断用户描述的是质量问题还是主观不满意；
6. 决定是直接发起售后、补充询问，还是转给人工；
7. 最后还要把动作真正写入售后系统。

一个熟练客服看似只回复了几句话，背后实际上完成了信息理解、数据查询、规则匹配、风险判断和系统操作。

如果我们的目的是替换/蒸馏这个熟练客服。那么，这个生产级 AI 客服至少要接管五层工作：

• 第一层是理解：用户到底在说什么，真实诉求是什么；
• 第二层是查询：从订单、物流、会员和售后系统中获得事实；
• 第三层是判断：根据政策、业务规则和上下文决定怎么处理；
• 第四层是执行：提交申请、修改状态或触发下一步流程；
• 第五层是负责：知道哪些事情可以自动完成，哪些必须交给人。

从这里开始大家就会逐渐感受到 Demo 与生产系统、知识库和 AI 客服的差异所在了：

1. 知识库主要解决“知道什么”；
2. 生产级 AI 客服还要解决“现在应该做什么”、“能不能做”和“做完是否成功”；

这些差异也是项目后面所有复杂性的来源：你如果只想 AI 回答得像个人，那么成本很低、但如果你想要 AI 替代人，那成本就奇高了！

接下来是项目的几个阶段：

一、从咨询、查询开始

项目刚启动时，团队没有直接让 AI 接管售后，先选择了最简单的一批场景：常见问题查询。

例如优惠券为什么不能使用、商品支持几天无理由退货、物流何时送达……

这些问题有三个共同特点：

1. 答案相对固定；
2. 通常不需要修改业务数据；
3. 回答错误造成的损失比较有限。

团队先整理客服历史话术，把同一个问题下互相冲突、已经过期或表达含糊的内容清理掉，再让 AI 根据当前信息生成回复。

这一阶段很容易快速看到效果。用户用不同方式提问，AI 也能识别出背后的同一个问题；过去需要客服在几十条规则中搜索答案，现在系统几秒钟就能生成一段完整回复。

但这里初期也不是自己上 AI 客服了，而是做了一个 客服效率工具，AI 会推荐回复内容，又客服选择使用什么。

这个阶段客服反馈很好，着实提升了一波效率，但它距离替代客服还很远。

因为在一定周期后，我们灰度了 1% 流量来做完整的 AI 客服回答，只要问题涉及具体订单，AI 就可能缺少上下文；只要需要退款、补发或修改信息，它就没有执行权限；只要规则出现例外，系统也不知道该继续追问还是转人工。

总而言之，这套系统初期推进很慢、很小心，随便一点小小的失误、几个“敏感”客服的吐槽、抵抗就很危险。

所以第一阶段更准确的价值，是证明 AI 能听懂用户表达，并在一批稳定场景中给出可用建议。它为后续积累了信心，也暴露了进入真实业务必须解决的问题。

二、AI 与人的“蜜月期”

前面我们说了，系统第一次正式上线时，团队采用了非常保守的方式，做了一套客服 AI 效率工具：AI 处理每一条用户消息，但不直接把结果发出去，让客服主动选择。

AI 会识别问题、生成回复，有时还会给出处理建议。所有内容都先展示给客服，由客服逐条审核，确认没有问题后，再由人工发送或执行。

这是一种典型的客服 Copilot 模式，也是整个客服团队跟 AI 最和谐也是最后和谐的相处时间…

这种协作模式，把风险控制在很低的水平，也给项目带来了第一批宝贵的真实样本：

1. 哪些表达经常被识别错；
2. 哪些政策容易出现冲突；
3. 哪些问题缺少必要数据；
4. 哪些建议客服几乎每次都会采用；
5. 哪些场景客服一定会修改或拒绝 AI 的答案。

人工每一次接受、修改和驳回，都在给系统提供反馈。产品和技术团队据此调整场景分类、提示词、知识内容和处理规则。

因为这个阶段所有的动作都在试探能力边界，所以出现了一个非常典型的问题：

过去客服自己判断、自己回复；现在还要阅读 AI 建议、判断是否可靠，必要时重新修改；AI 表现不稳定时，审核甚至可能增加工作量。

所以，AI 上线了，人力成本并没有降下来，反而高了很多！

如果当时甲方爸爸没有耐心，那么也就没有后续的故事了，总之我在这里做的“向上管理”、画饼忽悠动作是很多的

这也是很多 AI 客服项目容易产生的错觉：AI 参与了大量对话，看起来覆盖率很高，但每条回复仍需人工确认，AI 覆盖了对话，并不等于接管了工作。

不过，对于一个刚进入生产环境的系统，全量审核仍然有必要，这种 Copilot 模式几乎成了我们实施生产级 AI 客服的固化方法论了。

三、AI 开始“夺权”

积累了一批真实数据后，团队开始做第二次关键改造：按照不同场景的风险和成熟度逐步放权。

我们把客服问题划分为几类：

已经经过足够样本验证，并且准确率稳定、风险可控的场景，会进入自动处理白名单。AI 判断用户问题属于这些场景后，可以直接回复，或者继续调用业务系统完成动作。

至此，AI 客服开始获得两类非常重要的能力。

第一类是查。

它可以查询订单状态、支付信息、物流轨迹、会员等级、优惠券使用记录和售后进度。原来客服需要在多个后台之间来回切换，现在 AI 可以根据用户身份和对话内容自动读取相关数据。

第二类是写。

在权限允许的情况下，AI 可以修改部分订单信息、调用 API 触发业务流程。

业务系统原本已有的接口通过 HTTP 方式提供，再封装成 AI 可以调用的工具。每个工具都有明确的输入、权限和返回结果。

例如，AI 想查询物流，必须提交有效订单号；想发起售后，必须先完成身份、时效、商品状态和规则校验。

从这个阶段开始，我们不断的在测试边界、在双盲测试，这里的结果就是 Token 使用爆了，但效率一点没提高，这里的双盲技巧可以分享下：

几个白名单客服所有的操作，AI 会同步做一次，并且留下日志信息，背后有一套“影子系统”

这一步接受后，AI 客服开始从“会回答问题”推进到了“能解决问题”。

这个阶段的技术关键在于控制权限：每一种权限都必须绑定已经验证的场景、明确的规则和可检查的结果。

但是，实际执行起来，技术难点倒是其次，毕竟麻烦的是“客服觉醒”，整个客服团队的反抗情绪空前，并且总是在报一些莫须有的系统 BUG，他们就是要证明：

AI 是不行的，用 AI 一定会导致很大的生产事故

至于如何解决，就很见仁见智了，反正稳不住也就失败了，因为这些问题全部是混淆因子，没什么价值

四、场景地图

到这里会有一段阵痛期，根据我们之前的经验：快的话一个月、慢的话三个月，团队磨合就结束了，该任命的基本任命了、不认命的基本就离开了…

当所有的管理内耗消失后，AI 团队级别的效率就会迎来炸裂的增长！如果你也是这么想的，那么就很尴尬了，因为当管理问题消失后，我们陷入了一段时间的迷茫期，包括目标迷茫期和技术架构迷茫期以及产品效果迷茫期…

团队遇到了一个新的问题：

大家已经很难说清楚 AI 究竟会什么、不会什么，下一步最值得建设的又是什么。

最初团队按售前、售中、售后做简单分类，很快发现粒度太粗。同属于售后，退款进度查询、质量问题举证、补发申请、地址修改和高额赔付的处理逻辑完全不同，所需数据、工具和风险等级也不同。

于是，团队开始从结构化角度重新整理所有客服问题，为每一个场景定义：

1. 用户意图和常见表达；
2. 进入场景所需的前置条件；
3. 需要读取的数据；
4. 适用的业务规则；
5. 可以调用的工具；
6. 自动处理的风险等级；
7. 成功和失败的验收标准；
8. 何种情况下必须转人工。

这些动作其实初期也做过，过程中甚至不断被提及，但每次有点不知道怎么办的时候，这个全景图就出来了，我觉得这东西的核心作用是：

让 AI 客服能力从一个模糊概念，变成了一张 make sense 的场景地图

要完整的形成这张地图，一般需要至少一个季度的迭代，只有时间足够，AI 覆盖的场景能力边界才能真正清晰。

这里需要区分两个经常被混用的指标：场景覆盖率和流量接管率。

场景覆盖超过七成，代表系统已经具备处理这些类型问题的能力

流量接管接近一半，代表在真实生产环境中，实际有多少对话由 AI 独立承担

一个场景可能已经完成建设，但因为风险高、样本不足，仍然不会把全部流量交给 AI。

同样，场景数量也不等于业务量。几十个长尾场景可能只占很少的咨询，一两个高频场景却可能贡献大量流量。

因此，团队没有盲目追求场景数量越多越好，优先处理高频、标准、风险可控，并且能够真正释放人力的场景：

五、可观测性与飞轮系统

用户永远会提出团队没有想到的问题。

AI 不能稳定处理的对话，需要被记录下来，进入一个场景 backlog，也就是待建设场景池。有些是现有意图的特殊表达，有些缺少业务规则，有些需要新的系统接口，还有一些属于从未出现过的业务组合。

这里就一定有个大前提：客服团队是一定不能全部裁完的，一定要有一批熟悉业务、拥抱 AI 的留下来持续配合建设这一切。

AI 客服上线后会不断暴露新的能力缺口，每一个缺口都要经历完整处理：

1. 收集失败对话和用户反馈；
2. 判断它是偶发问题还是独立场景；
3. 评估频率、价值和风险；
4. 补充知识、规则、数据或工具；
5. 构造正常、异常和边界测试样本；
6. 通过离线评测和人工验收；
7. 小范围放量并观察真实表现；
8. 达标后进入自动处理白名单。

传统软件的产品 backlog 通常记录待开发功能，AI 客服的 backlog 记录的是一名数字员工尚未掌握的业务能力

大家要注意：正经的、长期的 AI 知识库团队，到这个阶段才算是入门了。

因为他们只有在场景评测出来后，才不会笼统地说优化模型准确率，而是开始明确本周要提升哪些场景、每个场景缺少什么能力、达到什么标准才允许上线，这里做过的和没做过的是有天壤之别的。

六、系统衍生

只要是生产级的 AI 知识库系统，一般到第四个月就会呈现体系化发展的趋势，团队构成和分工也会发生不小的变化：

这里会衍生出很多运营工具，包括：提示词系统、数据工程系统、可观测性系统、调试系统等等。

原因很简单，当场景只有十几个时，团队可以用文档或表格管理；当场景不断扩张，并且每个场景都有不同规则、工具、测试集和放量状态时，靠人工维护很快就会失控。

这里，我们就简单介绍下这里的可观测性平台，这套平台主要包含六部分能力：

第一，场景发现。

系统从转人工、人工改写记录、用户差评、工具调用失败和未识别问题，持续发现可能的新场景。高频失败问题会自动聚类，避免运营人员逐条翻聊天记录。

第二，场景定义。

产品和业务人员为场景补充名称、意图、适用条件、风险等级、所需知识和处理流程。相似场景需要合并，过大的场景需要继续拆分：

第三，能力建设。

团队判断问题究竟缺少哪一种能力：如果缺少信息，就补知识或接数据；如果判断不稳定，就补规则和样本；如果只能回答不能解决，就增加工具；如果风险太高，就设计人工确认节点。

第四，测试与评测。

每个场景都建立独立测试集，既包含常规表达，也包含信息缺失、规则冲突、越权请求和系统异常。只有达到约定标准，场景才可以进入生产环境。

第五，灰度与切流。

新能力先承接很小比例的真实请求，再逐渐扩大流量。过程中一旦错误率、转人工率或用户反馈异常，就暂停放量，必要时收回自动执行权限。

第六，监控与回流。

系统持续记录意图识别、回复结果、工具调用、人工接管和最终解决情况。新的失败样本重新进入场景池，形成下一轮优化。

于是，AI 客服形成了一条稳定的运营闭环：发现场景、评估价值、建设能力、通过评测、灰度上线、监控结果，再从真实结果中发现新问题。

这套闭环也是项目能够从简单问答扩展到大量业务场景的核心原因。

沿着这个案例回头看，一套完整的 AI 客服大致可以拆成七层：

更复杂一点的 AI 知识库大概是这个层次，大家感受下就好：

最后，转人工时，系统还应把已经收集的信息、判断过程和失败原因一并交给客服，避免用户重新讲一遍，这七层共同构成完整业务系统，大模型和知识库只是其中的一部分。

AI 客服比人更贵？

回到开头那个最反常识的问题：

AI 覆盖了大量场景，也承接了接近一半多的流量厚，居然发现 AI 综合成本居然高于人工

这很难理解啊！于是需要去盘下账单：

首先，如果项目处于建设期。模型调用费之外，还有产品、研发、测试、场景运营、数据整理和系统接入成本，这笔研发费用是很高的！

其次，传统客服系统已经运行多年，成本被长期摊薄，意思是他们成本本来也不很高，再叠加 AI 客服正在补齐基础设施，两者直接比较很容易失真。

再其次，部分场景仍然处在双重成本阶段。AI 先完成理解和生成，人工再进行审核或接管，同一张工单同时消耗模型和客服时间。

然后其次，AI 调用真的不便宜，尤其是复杂 Agent 往往需要多轮模型调用。它要识别意图、补充信息、选择工具、读取结果、检查风险，再生成回复。上下文越长、工具越多、重试越频繁，单次处理成本越高。

此外，AI 的价值还没有完全通过组织调整释放出来。如果 AI 已经承接一半流量，但原有排班和人员规模没有同步变化，系统节省的只是理论工时，这也是 AI 客服最容易被诟病的点：搞了半天，你依旧不能 100% 替代？

所以，关于 AI 客服这里就很难圆，项目负责人往往会找很多角度、很多成本计算口径去包装这一切，但都避免不了一个事实：生产级 AI 客服成本不会低，你需要一个研发团队，哪怕这个团队很小…

而我当时陪跑这个项目也就做到这个地步了，后面再去了解情况也是一样：最终 AI 客服的成本也没有完全优于人工客服…

团队真正要等待的拐点，是更多成熟场景取消逐条审核、AI 自动解决率持续提升、人工团队规模和排班随之调整。到了这个阶段，平台固定成本被更大流量摊薄，单次工单的边际成本才可能明显下降。

所以，很多还处在能力建设和组织切换的中间阶段 AI 项目，初期要遭受很多管理内耗，中后期要面对的是各种成本账，到最后甚至不得不选择便宜的模型、牺牲服务的质量…

结语

今天这个生产级 AI 客服的案例，可能告诉了大家不一样的故事：原来就算 AI 原生走到比较深的阶段，依旧会有很高的成本，只不过账单从客服人力成本转移到了产研 + Token 的费用。

至于这一切是否值得，还是需要算账，并且需要看长期、看趋势！

而就今天我分享的案例，至少现阶段整个公司还在持续推进，并且取得了很多组织、分工层面的变化，比如：

原来客服团队的主要工作，是一张接一张处理工单。随着 AI 开始介入，人的职责逐渐转向处理异常问题、审核高风险决策、运营新场景和改进系统能力。

并且，客服人数不再严格跟随业务量增长。一线团队从大规模执行队伍，逐渐变成一支规模更小、专业度更高的兜底和运营团队。