词典、学习硬件、在线课程，三条产品线看起来都是"学习类产品"，但用户问的问题完全不同。词典用户关心的是单词翻译、例句用法、词库版本；课程用户问的是课时进度、退款政策、课程有效期；硬件用户问的是设备无法开机、蓝牙连不上、屏幕不亮。同一个客服入口，用户打一句"怎么用不了"，AI 客服机器人如果不知道他问的是词典 App 查不了词、课程打不开、还是硬件充不进电，就只能反问"请问您用的是我们哪款产品"——这跟传统 FAQ 机器人的体验没有差别，用户一进来就想转人工。

在线客服 Agent 要解决的核心问题，不是接到咨询后怎么从知识库里找到答案，而是先判断这条咨询属于哪条产品线，再切进对应的知识库。本文拆解这套"先判后答"的路由机制怎么设计。

在线-填单记录.jpg

一、先理解三条产品线的问法有什么不同

设计路由之前，先要把三条产品线的典型问法特征梳理清楚。如果连"什么样的问法大概率属于哪条线"都说不清楚，路由就只能靠用户自己选择，Agent 的价值就打了折扣。

1. 词典产品线的问法特征

词典用户的典型问题集中在"查询行为"本身：

  • "这个词什么意思""XX 的用法""有没有例句"

  • "词库怎么更新""为什么查不到这个词"

  • "翻译结果不对""语音发音不准"

  • "会员和免费版有什么区别""离线包怎么下载"

关键词特征：单词本身、翻译、例句、发音、词库、离线包、词典版本。问题通常很短，核心是一个具体的词或短语。

2. 在线课程产品线的问法特征

课程用户的典型问题集中在"学习进度和交易行为"：

  • "我的课程怎么不见了""学到一半找不到了"

  • "怎么退款""课程有效期多久""能延期吗"

  • "这个课程适合什么水平""有没有试听课"

  • "课程视频卡顿""音频不同步"

关键词特征：课程、退款、有效期、进度、课时、试听、购买、支付。问题往往涉及订单状态、退款规则和有效期计算，需要连接订单系统。

3. 学习硬件产品线的问法特征

硬件用户的典型问题集中在"设备状态和物理操作"：

  • "开不了机""充不进电""屏幕不亮了"

  • "蓝牙连不上""Wi-Fi 连接失败"

  • "怎么重置""固件怎么升级"

  • "保修多久""哪里可以维修""配件怎么买"

关键词特征：开机、充电、蓝牙、Wi-Fi、屏幕、重置、保修、维修、配件。问题通常涉及设备型号、故障现象和操作步骤，部分需要 SN 码查询保修状态。

在线客服-快捷导航.jpg

二、设计"先判产品线再进知识库"的两层路由

搞清楚三条线的问法特征后，路由设计就清晰了：把产品线判断做成独立的第一层，判准了再进入第二层知识检索。两层之间互不干扰，各自承担不同的失败兜底策略。

1. 第一层：产品线路由

这一层只做一件事——判断用户当前咨询属于词典、课程还是硬件。

判断依据分三级，按优先级依次尝试：

  • 第一级：前置引导菜单的显式选择。 用户进入客服入口时，在聊天界面预置快捷问题按钮，例如"词典问题""课程问题""硬件问题"三个入口。用户点击任一按钮，产品线直接确定，无需语义判断。这是最准确的方式，适合用户主动配合的场景。

  • 第二级：关键词特征匹配。 用户没有点击菜单而是直接输入问题，Agent 用关键词特征做快速分类。每条产品线预设一组高区分度关键词——例如"单词、翻译、例句、发音"指向词典，"课程、退款、课时、试听"指向课程，"开机、蓝牙、充电、屏幕"指向硬件。同时为每条线设一组排他词：当同时出现两条线的关键词时，排他词辅助判定优先级。比如"课程"+"蓝牙"→ 可能是问课程 App 的蓝牙连接问题，但"蓝牙"在课程产品线中出现的概率远低于硬件，所以优先判为硬件，再追问确认。

  • 第三级：语义兜底。 前两级都无法判定时（比如用户只说"用不了""怎么搞"），Agent 用语义理解做一次兜底判断——结合上下文和模糊语义推断最可能的产品线。如果语义也无法确定，进入追问确认流程："请问您遇到的是词典、课程还是硬件方面的问题？"追问一次即可，不要反复追问。

2. 第二层：知识检索与回答

第一层判定了产品线后，第二层进入对应知识库检索答案。三条产品线各自维护独立的知识域：

  • 词典知识域：词库版本说明、翻译准确性问题排查、离线包下载指引、会员权益对比

  • 课程知识域：退款政策、有效期规则、课程进度恢复、App 使用指引

  • 硬件知识域：故障排查步骤（按型号）、保修政策、固件升级指引、配件购买渠道

三条产品线可能共享一些通用知识——比如"App 怎么下载""账号怎么注册"——这类问题放在一个公共知识域中，不经过产品线路由，直接回答。

3. 跨线追问的处理

用户可能在一次会话中先问词典问题、再问课程问题。Agent 需要判断每次新消息是否切换了产品线。处理方式：每次收到新消息时，重新走一遍第一层路由，而不是锁定在首次判断的产品线中。但上下文要保留——如果上一轮用户问的是词典问题、这一轮说"那退款呢"，Agent 应该判断"退款"属于课程域，切到课程知识库，同时在回复中确认："您是想问课程的退款政策对吗？"避免静默切换让用户感到答非所问。

在线客服-话术推荐.jpg

三、在聊天入口前置引导，降低判断难度

两层路由的设计依赖判断准确率。判断准确率越高，用户越不需要手动选择。但有一条原则：宁可让 Agent 准确率略低时走追问兜底，也不要为了提高准确率把前置菜单设计成强制选择——用户一进来就面对"请选择产品线"的菜单，跟传统 IVR"词典请按1、课程请按2"没有本质区别，在线客服的优势就丢掉了。

推荐的做法是"轻度引导 + 智能判断"：

  • 入口页展示三个快捷按钮，但不阻塞用户直接输入。用户可以直接打字，Agent 走关键词+语义判断；也可以点按钮，Agent 直接跳过判断层进知识库。

  • 快捷按钮的文案不是"词典""课程""硬件"，而是用户视角的典型问题："查单词 / 翻译""课程进度 / 退款""设备故障 / 保修"——降低用户的认知负担，不用思考"我的问题属于哪条线"。

  • 非工作时间用户点按钮后，Agent 直接返回对应答案；工作时间复杂问题标记为"需人工"，转人工时携带已判定的产品线和对话摘要。

客服机器人.jpg

四、产品线边界模糊时怎么兜底

实际运营中，总有一部分问题是跨产品线的，或者用户自己也不清楚属于哪条线。对于这类情况，需要明确的兜底策略。

1. 跨产品线问题

典型如："我在课程 App 里查单词为什么查不到？"——既涉及课程产品（课程 App），又涉及词典功能（查单词）。处理方式：先判主要意图——"查单词"是核心动作，判入词典域。回答时先覆盖词典域的标准答案，再补充一句"如果您是在课程 App 里使用的词典功能，不同课程 App 版本可能有差异，可以告诉我具体是哪个课程，我帮您进一步确认"。

2. 用户自己不知道属于哪条线

用户说"我的账号登不上"，这可能是三条线共性的问题。Agent 判断为"跨线共性"→ 直接进入公共知识域，返回账号登录的通用解决方案。如果公共知识域无法覆盖（比如涉及硬件 SN 码绑定），再追问确认产品线。

3. 追问超过一次仍未判定的处理

Agent 追问一次后用户仍无法说清（比如回复"不知道""就是不好用"），直接标记为"产品线未判定"，转人工并携带完整对话上下文。不要反复追问——追问两轮以上体验已经差于直接转人工。

五、不同实现方式的适配分析

"先判产品线再答"这个需求，不同的实现方式能达到的效果差异很大。企业在选型时可以对照以下几种路线：

  • 纯 FAQ 关键词匹配：给每条产品线配置一组关键词，命中后返回预设话术。优点是部署快，缺点是用户稍微偏离关键词就匹配不到，体验跟传统机器人没有差别。适合产品线区分度极高、用户问法极其标准化的场景，但在词典/课程/硬件这类用户表达多样的场景中，命中率会快速下降。

  • 大模型直接回答 + 知识库混合检索：不设显式的产品线路由，直接把三条线的知识混在一起让大模型检索回答。大模型可能自行判断产品线，但判断逻辑不可控——同一个"怎么用不了"的问题，上午判成词典、下午判成硬件，一致性无法保证。这种方式适合产品线区分度极低、问题同质化高的场景，但词典/课程/硬件显然不满足这个条件。

  • 独立路由层 + 分域知识库：在产品线和知识检索之间插一层显式路由，路由层只判产品线，判完再进对应知识库。路由层的判断逻辑可配置、可优化、可监控——运营人员可以看路由准确率、修改关键词特征、补充语义训练样本。这是适合多产品线场景的正解。亿捷云智能客服的在线客服 Agent 可以作为这类方案的参照——它支持基于意图理解的智能路由，将客户问题分配到对应 Agent 或技能组，同时悦问知识库支持按业务域划分知识、按权限控制检索范围，刚好覆盖"先判后答"需要的前端路由和后端知识分层。

落到词典/课程/硬件场景，评估方案时重点看三个条件：

  • 路由层能否配置多条产品线的判断规则，且规则可被运营人员持续优化

  • 知识库是否支持按产品线独立维护，同一平台切换而非多个系统拼接

  • 路由判断失败时是否有追问、兜底和转人工的完整降级链路

六、自查清单

如果你的企业也面临多条产品线进同一个客服入口的问题，可以先拿下面几个问题自测：

  • 每条产品线的典型用户问法是否已经梳理清楚？如果连"词典用户一般怎么问""硬件用户一般怎么问"都说不清楚，路由规则就没有设计依据。

  • 是否有一定比例的共性问题（如账号、支付、App 下载）可以放在公共知识域中统一回答，而不需要走产品线路由？

  • 当前客服入口是否已经设置了快捷问题引导？如果有，点击率和自主解决率分别是多少？如果没有，前置引导是第一步该做的事，而非直接跳到路由设计。

  • 路由判断失败的场景中，追问一次后用户是否能说清产品线？如果追问后仍有较高比例无法判定，说明前置引导做得不够，或者产品线本身的边界就模糊。

  • 知识库是否按产品线做了独立维护？如果三条线的知识混在一起，Agent 即使判对了产品线，也可能检索到其他产品线的答案。

  • 人工坐席在转接时是否能看到 Agent 已判定的产品线和对话摘要？如果看不到，坐席需要从头问起，Agent 的前置判断就没有产生实际价值。

如果前三个问题的答案都清晰，先做前置引导和公共知识域，再做产品线路由，最后补充跨线兜底。如果知识库尚未分域维护，建议先花时间把三条产品线的知识各自归位——知识不分域，路由判得再准也答不对。




如需智能客服、AI客服机器人产品，请联系【亿捷云智能客服】，联系电话： 4006-345-690