构建原生AI客户服务系统

# 构建原生AI客户服务

近三年来，我们一直在为 Picnic 的客户服务进行自动化改造。我们尝试了各种方式：使用现成工具、自己构建智能体，然后推倒重来、从零开始。如今，66% 的对话无需人工干预即可解决，且好评率达到 90%。

本文的目的是分享我们的历程和主要经验，希望对正在经历类似处境的人有所帮助。

# 我们的发展历程

## 为什么决定押注 AI 客服？

我们押注 AI，不仅仅是为了削减成本。我们相信，它将是大规模提供最高质量服务的方式。原因如下：

1. 高度个性化且精准的上下文：借助正确的数据，AI 可以查阅您已提交的工单、理解您使用产品的方式，并整合一系列信息——这对于人工客服来说几乎不可能在保证响应速度的同时做到。

1. 让人工客服保持一致性绝非易事：每个人都有自己的个性、回应方式和专业知识。确保支持团队保持高度一致是一项巨大挑战，尤其是当产品像 Picnic 一样复杂时。

1. 持续积累的改进：我们能够将一项改进融入整个运营体系，并确信它将与其他正在进行的改进叠加累积。

## 我们的第一个 AI 客服智能体

我们最初通过一个平台起步，该平台会查询一系列文档并据此给出回答。AI 能解决的问题量占比相对较小，而且在部分案例中，它的回答帮了倒忙。但当它真正奏效时，效果美妙至极。

那时，我们面临的主要问题并不来自 AI 本身，而是流程、工具和指标的缺失。我们没有一个组织有序的支持部门，于是开始使用 Zendesk 来规范服务流程，并建立持续改进的机制。

## 内部自建

我们的 AI 回答存在一些难以解决的问题。在一次试图找出原因的尝试中，我们向自己的 AI 和当时刚刚发布的 GPT-5 提出了同样的关于 Picnic 的问题。我们的 AI 答错了，而 GPT-5 通过搜索我们的帮助中心答对了，并且没有任何针对 Picnic 的专项配置。

我们进行了更多测试，最终决定采用更开放的模型会优于我们当时的解决方案。由于我们认为将 AI 深度集成到产品中是我们愿景的核心，我们决定打造自己的解决方案。2025 年 10 月，经过六周的开发，我们发布了 Nick V1——我们自主研发的客服智能体。

它解决了我们长期存在的一些问题：在用户问题尚未真正解决前就关闭工单、在需要升级给人工客服的情况下未能及时升级，以及在 AI 本应能够解决的工单中上下文检索失败。

## 借助工具构建

Nick V1 能够基于我们的文档进行回答，但没有接入任何工具来查询余额、核实交易或获取客户的上下文信息。它可以解释产品的运作方式，却无法调查该账户究竟发生了什么。

随着新模型（Opus 4.5）的发布，我们使用 Claude Code 的经验改变了我们对 Nick 的期望。我们希望她也能够主动获取上下文、调用工具并自主做出决策。于是我们决定放弃 Nick V1，以更大的自由度和自主性重新构建她。

Nick V2 可以在同一次对话中完成：查询客户资料、核查交易记录、检查操作状态，以及从帮助中心检索信息。这一切只需数秒，而且非常便于持续优化服务质量。

七月，我们正式退役了 Nick V1，将全部客服工作交由 V2 承接。虽然还有很多工作要做，但我读过的大多数工单都让我感到满意，有些案例甚至让我印象深刻——AI 在诊断问题、协助用户方面能走多远，着实令我叹服。

# 主要经验总结

## 1. 建立流程、指标、时限与负责人

我们曾经面临的问题之一，是存在大量工单，却不清楚谁需要跟进处理。客户在一旁等待，而我们迟迟未能察觉。

理顺运营管理，让我们得以回答一些最基本的问题：哪些紧急工单还没有得到回复？所有工单是否都有负责人和截止时间？有多少工单正在等待合作伙伴处理，已等待多久？哪些类别集中了最多的问题？

这种可见性对于改善服务质量至关重要。没有它，我们很难诊断和优先处理核心问题；有了它，我们的工作才真正产生了更大的影响。

## 2. 信任 AI，并赋予她工具

当我们不再试图逐步定义 AI 应该做什么时，我们的构建方式发生了改变。如今，我们为 Nick 提供工具、指令和边界，让她自主选择如何解决问题。

如果一次搜索没有奏效，她可以尝试另一种方式。如果文档不够充分，她可以查询客户数据。她不需要在开始之前就规划好完整的路径——她可以根据已发现的信息决定下一步。

这大大简化了我们的工作，也让 AI 能够处理更广泛的问题。

## 3. 使用技能模块来管理复杂性

我们的系统提示词变得越来越臃肿。每个新问题都带来更多指令、例外和规则，副作用变得极难控制。

按技能模块拆分大有裨益。登录、PIX、信用卡和 KYC 各有专属处理流程，按需加载。我们可以深入细化某项调查，而无需将所有主题的指令塞进同一个提示词。

这也让 Nick 更易于维护。如果我们需要调整她处理信用卡问题的方式，我们清楚地知道相关规则在哪里，以及需要测试哪些其他场景。

## 4. 在人工与 AI 智能体之间共享工作流

我们做出的最佳决策之一，是让人工团队和 Nick 使用相同的自动化流程。

人工客服可以在处理工单时触发一个宏。Nick 可以识别出该流程适用于当前情况，并将案例转入同一工作流。从那一刻起，双方共用相同的执行逻辑。

这避免了维护同一流程的两个版本。例如，如果我们修改了联系某合作伙伴的处理方式，就不需要分别更新一套面向人工的自动化和另一套面向 AI 的自动化。运营知识统一沉淀在共享流程之中。

举个例子：如果实体卡未到账，Nick 会查询订单、核实时效，并在符合补发条件时请客户确认地址。随后，她会触发与人工客服相同的宏指令，向合作方发起补发申请。

## 5. 使用评估机制保障质量

有一段时间，我们似乎总是修好一个问题又破坏另一个。单独测试那个出错的问题并不够——它可能变好了，但其他场景却在悄悄变差。

因此，每次改动都必须先明确：我们要修复什么，以及什么必须保持不变。我们会分别在旧版本和新版本上跑测试用例，对比两者的行为表现。

评估不能只看回复的文本内容，还要关注：智能体是否查询了必要的数据？是否选择了正确的流程？是否在该升级时进行了升级？措辞得当的回复，完全可能掩盖一个错误的决策。

举个例子：如果客户要求发送凭证，Nick 回复"我来发送"是远远不够的。评估必须验证她是否真正调用了发送文件的工具。

## 6. 用智能体帮助改进智能体本身

目前，我每周会与一个专项技能（skill）进行一次复盘，由它分析服务记录并协助识别改进机会。这使我能够审查远超个人精力所及的对话数量。

但发现一条糟糕的回复，并不意味着就要往提示词里添加一条指令。问题可能出在数据、工具、产品，或是相互矛盾的规则上。

为此，我们创建了一个名为 CX Improve 的专项技能，专门负责主导调查、定义评估标准，并在有限范围内测试修复方案。目标是改善行为，而不是为每一张工单打一个补丁。有时，所需的改变是移除一处矛盾，而不是再添一条规则。

--

希望这些内容对你有所帮助！

衷心感谢所有参与这一过程的人，尤其是 @pury_br——这套系统的大部分架构正是由他设计的。