先说结论：如果你想让一个客服入口同时管退款、查物流、改地址、投诉这四五件事，别在一个大提示词里硬塞，先做意图识别分流。我自己踩过坑，一个 prompt 塞了七八个业务，结果用户问退款它给查物流，问物流它开始道歉，乱成一锅粥。

为什么要分流

道理其实挺朴素的。一个大模型，你给它的活越杂，它越容易串。我一开始图省事，把所有业务规则写一个超长系统提示，三千多字。测了两天发现召回退款流程的准确率大概只有七成，剩下三成要么答非所问，要么把改地址的话术安到退款上。

后来想明白了，得在用户说完第一句话之后、真正干活之前，先判断这句话到底属于哪类业务，再把它甩给专门处理那类业务的分支。每个分支只管自己那摊事，提示词短、规则清，串台概率立马降下来。

这套东西我是在一个能拖拽配节点的低代码平台上搭的，省得自己写路由框架。

分流节点怎么配

核心就一个意图识别节点，输入是用户那句话，输出是一个意图标签。我配了五个标签：

• refund 退款

• logistics 物流

• address 改地址

• complaint 投诉

• other 兜底（识别不出来的全进这里）

节点后面接一个条件分支，按标签走不同的下游。退款标签进退款处理子流程，物流进物流子流程，以此类推。other 这条特别重要，别省，不然识别不出的请求会卡死或者乱跳。我第一版没配兜底，有个用户问"你们公司在哪上班"，整个流程直接空转，日志里啥也没有，排查了半天。

意图识别这步我没用规则关键词匹配，关键词太脆，用户说"东西到哪了"和"我的快递呢"是一个意思但一个关键词都不重合。直接让模型做分类，给它五个标签的定义和两三个例句，让它只输出标签名。提示词大概长这样：

你是意图分类器。读用户输入，只输出下列标签之一，不要解释：
refund / logistics / address / complaint / other

refund：用户想退货退款、取消订单、要钱回来
logistics：问快递到哪了、什么时候到、物流停了
address：要改收货地址、改电话
complaint：表达不满、要投诉、骂人
other：以上都不是

记得加"只输出标签名，不要解释"，不然它动不动给你输出一整段分析，下游条件节点匹配不上。这点我吃过亏，模型挺爱多嘴的。

一个真实取舍

分流多一层，延迟会涨。我实测每个请求多了大概 600 到 900 毫秒，就因为多调了一次模型做分类。对客服场景这点延迟无所谓，用户等一秒看到回复很正常。但要是你做的是那种毫秒级的接口，这套就不太划算，得换成更轻的分类方式，比如用小模型或者本地的文本分类器。我这场景不敏感，就忍了。

还有个坑：标签别设太多。我后来贪心加到九个标签，识别准确率反而掉了，模型在相近的标签之间犹豫。后来合并回六个，把"退款"和"取消订单"并一类，准确率又上去了。标签之间界限要清楚，能合就合。

怎么验证分流准不准

我整理了一百条历史客服记录，手工标好真实意图，跑一遍分类节点，对比输出。第一版六成多，调了提示词和例句之后到九成出头。剩下那一成主要是用户一句话里塞了俩诉求，比如"东西不对我要退而且换个地址"，这种就让它优先走退款，剩下的引导用户再说一遍。完美解决不了，能用就行。

搭这么个分流客服，从配节点到调通大概小半天。模型那块我直接走的讯飞星辰 MaaS，现成的大模型 API 调，没自己部署算力，省事。