生成式AI在客服场景的系统化实践 01 ｜ 从规则到生成式：我在客服项目里的几点思考

全文共 5367 字，预计阅读时间 15 分钟

前言

这是一篇迟来的分享，去年，我在国内一家O2O类互联网公司的中台部门实习了一段时间，做的是智能客服相关的业务。说实话，刚进去的时候，我以为智能客服已经是一个“成熟得不能再成熟”的领域——FAQ、规则引擎、意图识别、多轮对话……感觉都很标准化。

但真正参与进去之后，我才发现：智能客服并不是一个“技术问题”，而是一个“业务进化问题”。

很多问题，不是系统做不到，而是原来的方法似乎已经走到了阶段性的天花板。

从外采到自建：智能客服的第一阶段

每当我在接触一个全新工作之前，我都会习惯性问问当前问题的背景，这次也不例外。据了解，公司在 21 年之前，其实是依赖外采客服中台的。简单说，就是“买一套成熟系统，用规则去搭业务”。

21 年开始，由于公司业务规模和业态丰富度的进一步扩展，外采系统的迭代速度难以满足一些个性化需求，于是乎，公司决定自建客服系统。

这一步其实很关键——因为自建意味着：

在这个阶段，智能客服的目标其实很明确，即是提高分流率，降低人工成本。

通过不断打磨规则和意图模型，分流率确实提升得很快。尤其是对于标准问题，比如：

这些结构清晰的问题，往往已经有业务整理好了相应的SOP，用规则+意图匹配，效果很好。那几年，其实算是“基于规则的客服系统的黄金时代”。

业务更复杂后 规则到了瓶颈

大概在23年前后，情况有所变化。业务规模变大、场景变多、链路变长，业务侧观察到客服问题开始出现几个明显变化

多轮对话越来越复杂

业务简单的时候，用户的提问可能非常简单：

“怎么取消订单？”

当业务更加复杂的时候，例如引入了更加复杂的申诉规则后，问题可能会变成了这样：

“司机迟到 40 分钟了，我现在在赶时间，如果取消会不会扣我钱？我之前遇到过类似情况你们说可以申诉，这种情况算谁的责任？”

很显然，这类问题，已经不是简单的“意图识别 + 固定话术”能解决的。

分流率摸到了天花板

分流率通常是客服系统的一个常用的北极星指标，因为它可以代表智能客服能承接多少用户进线咨询，为公司省下多少人工客服的成本。当业务复杂度提升后，部分复杂场景的分流率（非转人工率）开始卡住，业务侧发现了问题：越来越碎的场景导致规则树的分支设计越来越复杂，业务方和产品方为此承担了极大的心智负担。此外，像任何软件工程一样，客服系统也迎来了他的“二八法则”，规则可以解决“80%的标准问题”，但最后那 20%，会吃掉产研团队 80% 的精力。

缺乏情绪安抚能力

传统规则型客服还有一个天然短板：它不会“安抚”。当用户情绪激动说出： “你们是不是不想解决问题？”时，规则系统只会继续根据SOP走完规则树，这往往是用户不希望的回答。

对于用户的情绪化表达，系统会通过拒识功能去避免红线对话的产生，但这往往会间接抬高转人工率，拒识模块让系统变成了“被用户绕着走”的东西。

在我进入公司之初，业界所有做智能客服的公司，无论是做内部系统还是商业SaaS，都在大谈“拥抱AI”、“拥抱LLM”；与此同时，业界也有一个共识，智能客服是当前生成式AI在B端落地路径最清晰的一个方向之一。

从外部看，这个判断并不难理解。客服天然是对话形态，历史数据丰富，规则体系清晰，也具备明确的降本增效空间。相比C端的内容创作或开放问答产品非常依赖于底层模型，缺乏自身护城河；客服产品沉淀的行业数据更易构建护城河，也更容易看到业务价值。

但真正进入项目之后，感受却有些不同。

这篇文章，也想系统地分享一下：从基于规则的智能客服到LLM客服，我在参与实际项目当中踩过的坑，以及一些真实的思考。

----

找准LLM的定位

团队花了一段时间找到了LLM在智能客服当中的定位，最后也达成了初步的共识：

大模型不是替代规则，而是补充规则解决不了的那一部分。

传统的基于规则和小模型的智能客服仍有其工程价值，因为他的可解释性和高确定性，这和80%标准问题中的客服场景当中要求客服机器人的精准、合规回答的要求是不谋而合的。

从产品视角来看，LLM为智能客服引入了一些关键特性：

全新的连续对话体验

规则系统是路径控制型，你要提前设计好所有路径。大模型更像是语义处理层。它不需要知道完整规则树，也能理解连续对话当中用户隐藏的主诉求，这让连续对话变得更加自然。

对于分流策略的新理解

以前，业务和产品的统一目标是尽量降低转人工率，从直觉上来看，策略的设计应该围绕避免让用户转人工，但实践起来往往不尽人意，一些问题天然不适合客服机器人回答，例如一些复杂的双边纠纷，涉及到赔付金额、责任归属等敏感问题；一味的拦截转人工只会降低客户满意度。所以正确的策略设计围绕的目标应该是：

让合适的问题流转到合适的处理方式上去

在过往基于规则的智能客服时代，这个策略的设计成本是非常巨大的，因为这非常考验团队对于意图和任务型的拆分和提炼能力；而如今LLM的语义理解能力显著降低了这一块的构建成本。大模型参与后，团队能做的策略可以更多：例如可以先做用户情绪的判断，再判断意图或任务型决定是否转人工，或者先引导用户澄清需求再做判断。

从策略层面看，大模型更像是能力补位，而不是体系替代。但当真正进入工程阶段时，问题远比讨论复杂。

经验一：在意图识别上，我们选择“保守升级”，而不是推倒重来

在引入大模型之前，团队最先讨论的问题，并不是“用哪个模型”，而是“是否要重构意图识别体系”。

过去几年，智能客服的核心能力建立在一套较为完整的意图识别体系之上：基于规则匹配与小模型分类的混合方案。业务团队围绕这套体系，积累了大量的意图标签、相似句库以及置信度策略。系统能够根据置信度区间，明确区分“直接回答”“二次确认”“拒识”等处理路径。这种策略的优点在于决策链条清晰、可解释性强，运营和风控团队能够理解并参与优化。

当大模型进入讨论范围时，团队内部确实出现过“是否整体替换”的声音。但在评估后，我们最终选择保留原有意图识别层，主要基于三个考虑。

首先是知识资产的连续性问题。自 21 年以来沉淀的意图体系，本质上是一套经过真实业务验证的知识结构。如果完全切换为纯大模型语义理解，意味着需要放弃多年积累的规则经验，这在风险和成本上都不可控。

其次是可解释性与稳定性问题。原有小模型的置信度区间策略，使得分流逻辑高度透明。例如，高置信度意图可直接回答，中置信度触发澄清，低置信度转人工。这种基于概率区间的分层决策，在客服场景中具有天然优势。而大模型并不天然提供稳定、可校准的置信度输出。即便通过提示词或后处理方式进行打分，也难以达到传统分类模型那样的确定性。

第三点是寒暄类与低复杂度意图的处理。大量简单高频场景，如闲聊、简单确认、辱骂，在规则体系下已经非常成熟。如果全部交由大模型处理，成本的付出并不划算。

经验二：模型选择，本质是团队选择

我们实际测试过多种模型，包括 GPT-4.1、DeepSeek V3/V3.1，以及带有深度思考的 R1等。不同模型在客服场景下呈现出明显差异。

以 GPT-4.1 为代表的海外模型在语义理解、多轮上下文保持以及生成稳定性方面表现较好，尤其在提示词优化程度不高的情况下，仍能给出较为稳健的结果。这降低了前期工程复杂度，使模型能够较快投入业务验证。但在高并发客服场景中，当对话轮次较多时，费用压力较大。因此我们一度将其作为效果标杆模型，用来对比其他方案的上限表现。

但当流量逐步放开之后，成本问题就变得现实起来。客服场景天然具有高并发、多轮对话的特点，模型的单次调用价格并不能完整反映真实支出，更关键的是整体吞吐能力与单位输出成本。

在评估 DeepSeek V3.1 时，我们也经历了一个认知转变。表面上看，其计价模型相比上一版本上涨了约 40%，如果只看单次请求价格，很容易得出“变贵了”的结论。但进一步拆解后发现，核心变化并不只在价格本身。

总而言之，这个认识就是要从整体 TCO（总拥有成本）去算账。表面上看，其计价模型相比上一版本上涨约 40%，但核心变化不止于单价。并发能力提升，一个并发用户可支持的请求数从 1 提升至 5；吞吐效率优化，使单位时间内可处理的请求更多。在合理进行请求裁剪和上下文控制后，单位有效输出成本反而更可控。对于高并发客服场景而言，更高的吞吐能力，意味着整体资源利用率提升，均摊后的真实成本并不一定更高。

至于 R1，我们在评估阶段发现其响应时延偏高，同时在复杂规则解释场景下存在一定幻觉风险。在高频、低延迟要求的客服环境中，并不适合作为主模型。

模型选型的核心并非单纯对比效果指标，而是结合团队能力与业务阶段综合判断。如果团队具备较强的提示词调优能力、完备的 A/B 测试体系以及充足的优化周期，那么性价比模型完全可以通过工程手段达到较好效果；反之，如果业务窗口期较短、对稳定性要求高，则优先选择成熟模型更为稳妥。

经验三：提示词工程，从技巧问题到管理问题

在客服场景落地过程中，提示词工程往往被视为“写 prompt 的技巧问题”。但在实际工程中，我们逐渐意识到，它更接近一个管理与体系化建设问题。

在具体实践中，我们采用结构化提示词设计，将角色设定、行为边界、任务指令、输出格式等分块定义，并通过 Markdown 形式增强结构清晰度。这种方式在稳定模型输出风格方面效果显著。下面提供一个结构化提示词的最简化示例：

# Role
你是一名专业的在线服务助手。
// 仅定义身份，不嵌入具体业务

# Profile
- Author: 
- Version: 
- Language:
- Description: 
// 元数据管理部分，便于版本控制与协作。

# Rules
1. 所有回答仅基于 {{KNOWLEDGE_SCOPE}}。
2. 不得补充未提供的信息。
3. 若无法回答，输出 {{FALLBACK_MESSAGE}}。
// 使用常量占位符，而非写死文本

# OutputFormat
- 使用简洁、清晰的中文
- 如涉及步骤，请使用编号说明

# Execution
请基于以下上下文进行回答：
{{CONTEXT_BLOCK}}

用户问题：
{{USER_QUERY}}

# Context
用户身份：{{USER_ROLE}}
订单状态：{{ORDER_STATUS}}
规则条款：{{RULE_SECTION}}
多轮对话摘要：{{DIALOGUE_SUMMARY}}

这里列举几种实践当中常用的提示词结构：

| 中文名 | 英文名 | 用法 |

在实践中，很少单独使用某一种模板，而是根据场景组合使用。例如，在复杂责任判定场景下，往往同时使用角色设定、思维链与示例学习。

这里个人认为最有用的就是示例学习；在实际使用示例学习时，我自己踩过一个很常见的坑：只给示例不够，最好再补一个“判定依据 / 评价点”（reason），告诉模型这条示例为什么是对的、好在哪里。如果示例只有结论，没有判断依据，模型容易在类似场景下产生偏差。

后来我们开始在示例中补充简要 reason，例如说明“为什么此场景适用某条规则”“为什么不能做出某种承诺”。这种做法并不是强行拉长 prompt，而是帮助模型对齐判断标准。

例如，同样是“需要转人工”的场景，光给一问一答，模型可能只学到固定话术；但如果同时给出一两条简短的结果说明，比如“该问题涉及金额承诺，必须走人工处理”“该场景信息不足，需要先澄清”，模型更容易把示例背后的决策逻辑固化下来，后续迁移到相似问题时也更稳定。

另外，在一些严谨或高风险场景里，仅靠 rules/restrictions 还不够。我更倾向于加入“负向 shot”，也就是专门给一两个反例：什么样的回答是错误的、哪些表述属于越界、出现这类输出就应该触发拒答或转人工。它的作用有点像在限制条件之外，再给模型一个更直观的“不要这么做”的参照系，尤其适用于涉及承诺、责任归属、敏感解释等场景。

更多结构化提示词的内容可以参考阅读：[https://github.com/langgptai/LangGPT]()

但随着提示词数量增加，一个新的问题逐渐显现：提示词本身开始变成“不可管理资产”。

为此，我们在早期通过共享文档与表格进行管理，记录提示词版本、创建人、修改时间、关联评测指标以及对应 bad case。每次修改后，必须进行指标对比与样本回归验证。虽然方式较为原始，但能够保证提示词迭代具备可追溯性。

从长期来看，提示词管理完全可以演化为中台能力，包括版本控制、效果对比、实验分流以及异常样本自动回溯。提示词并非一次性文本，而是可持续迭代的系统组件。

当然，对于追求快速上线和开发成本有限的小型团队，使用一些体系化的工具也可以代替中台的建设；例如，扣子罗盘（Coze Loop）在本地调试和对比不同版本提示词时就非常方便，能够快速看到输出差异，适合小规模实验阶段。

而像开源项目

https://github.com/linshenkx/prompt-optimizer?tab=readme-ov-file这类工具，通过自动化方式优化 prompt 结构，帮助减少冗余与不必要的指令。同样值得推荐。

### 经验四：警惕提示词过长的隐性风险

一个容易被忽视的问题是：提示词并非越长越好，在超过某个拐点后，提示词越长，模型行为越不可控。过多的上下文信息可能会带来不可预见的幻觉。因此线上版本的提示词必须被压缩；

第一条经验，是单一职责原则。

不要让一个节点同时承担回答生成、多轮改写、情绪识别等能力。例如，我们会将“回答生成”与“多轮改写”拆分为两个独立节点，由流程控制器进行编排。情绪识别也尽量作为独立原子能力，而不是嵌入到回答模型的 system prompt 中。

这种拆分带来的好处非常直接。每个节点的长度明显缩短，行为边界更清晰，回归测试也更容易定位问题。更重要的是，当某一能力需要调整时，不再需要重写整段 Prompt，而是只修改对应模块。

第二条经验是常量抽离。对于高度固定的内容，例如欢迎语、免责声明话术等，我们不再直接写入 prompt，而是使用常量名占位。模型输出后，再通过代码的后处理逻辑替换为真实文本。这样做至少有两个好处：

结语

本文主要围绕智能客服在大模型阶段的架构演进，分享了几个关键实践点。

首先，在意图识别层面，我观察到团队没有选择彻底替换原有规则与小模型体系，而是保留其在置信度分流与可解释性方面的优势，将大模型定位为语义增强与复杂表达处理能力。这种分层策略确保了升级过程的稳定性与风险可控。

其次，在模型选型上，我们强调“能力—成本—团队匹配”的综合判断，而非单纯的效果对比。不同模型在稳定性、成本结构与工程复杂度上的差异，决定了其适用阶段。

最后，在提示词工程方面，我们将其从“技巧问题”转化为“管理问题”，通过结构化设计与版本管理，使提示词成为可迭代的系统资产，而不是一次性文本。

很多决策在当时看起来并不激进，甚至有些“保守”。但回过头看，正是这些看似保守的取舍，让整个系统在升级过程中保持了稳定。

在接下来的几篇文章里，我会继续整理一些在工程层面印象更深的实践经验，包括：

这些内容更偏向系统化建设与长期治理，希望能够从工程体系层面，进一步补充本篇未展开的部分。