AI 客服 · 分享2026
C 端 AI 客服
C 端 AI 客服分享
在泥泞中基于业务指标的选择与权衡
分享人 · Austin1 / 32
开场不讲趋势不讲模型，直接下判断。
全场结构2 / 32
今天只讲五件事
3
不同渠道必须做差异化策略
同一套策略换个渠道，用户会骂人
4
skill+CLi让业务算法原地升天
不是为了追新，是老办法已经装不下了。
1 · 业务现实3 / 32
AI客服业务背景
01
覆盖业务
保洁清洗、维修、搬家、洗衣洗鞋，上千个SKU
02
覆盖链路
售前、待履约、临近履约、服务中、售后，同一句话在不同阶段含义完全不同
03
覆盖渠道
IM、企微、400。输入质量、时延容忍、用户情绪和系统责任都不一样
04
真实矛盾
你说什么没那么重要，能不能解决用户的问题。
核心指标：转化率，解决率，客诉率，转人工率，满意度，成本，对整个业务的贡献。
补上为什么值得听。
第一段 · 先把问题立住4 / 32
先做一道题
如果你是 AI 客服系统产品经理，你怎么回？
互动：先举手选，再往下讲。
第一幕 · 你以为你懂了5 / 32
语义对了，动作也可能错
哪里错了
- 语义上，识别成查进度完全正确。
- 业务上，已超预约 30 分钟，这是迟到风险，不该按普通查进度处理。
- 系统漏掉了更关键的一点：当前订单状态已经变了。
决定怎么处理的，不是句子本身，而是句子发生时的业务事实。
这页奠定全场主矛盾：语义对了，动作也可能错。
第一幕 · 你以为你懂了6 / 32
同一句师傅什么时候能来，五个阶段五个意思
售后
历史承诺追问
可能是返工，也可能是追之前的承诺。
让听众对阶段优先有体感。
第一幕 · 你以为你懂了7 / 32
AI 客服不是聊天机器人，是业务控制层
控阶段
售前、待履约、服务中、还是售后？先把交易语境定住。
控对象
哪一单、哪一笔退款、哪一次承诺？没确认对象就别动手。
控风险
超时、重复不满、物损、强投诉信号出现时，系统得知道该停。
这四件事塞进一个意图标签，分类器只会越来越臃肿，系统也越来越不透明。
第一幕总判断。
第二幕 · 从分类到路由8 / 32
一句输入进来，先答三个问题，再谈细主题
Question 1
在哪个阶段？
售前、待履约、临近履约、服务中、售后。阶段一变，同一句话后面允许的动作空间就变了。
Question 2
要推什么动作？
查状态、问规则、求执行、求升级。方向先定，再谈细分类。
Question 3
风险有多高？
高风险时不该硬猜，更不该继续普通自动化。走错了，业务代价有多大？
Then
再收细主题
订单进度、退款、返工、物损等，放在正确的动作空间里再分。
Result
从会分到会处理
系统开始像路由器，不只是文本分类器。
这是PM学员可以带走的决策框架。
第二幕 · 从分类到路由9 / 32
把用户这句怎么还没来跑一遍完整链路
状态层
有订单，预约 14:00，当前 14:32，已超时 32 分钟，状态是已分配未上门。
生命周期
当前不算普通待履约，已进临近履约的异常风险区间。
动作层
用户不只是问一下，更像在推动 求执行 / 求升级。
统一化
统一后写成 询问上门进度 + 已表达超时不满，风险信号不能被洗掉。
对象解析
锁定 当前唯一活跃订单，不用反问订单号。
风险门控
停止普通自动化。允许催单、升级、建单；禁止继续输出请耐心等待。
执行层
触发催单升级 skill，承认超时 + 已联系服务方 + 给反馈时点。
用同一条 case 把全场串起来。紧跟架构，不再隔15页。
第二幕 · 从分类到路由10 / 32
你来判断：这两个意图，边界在哪？
查上门进度 vs 催上门
前者要信息；后者要推进履约动作。超时强不满时可能从查询升级为催单。
投诉 vs 求补救
投诉偏升级追责；补救偏问题解决（重派、返工）。常一起出现，不能混成一个意图。
互动：让听众先讨论1分钟再揭晓答案。
第二幕 · 从分类到路由11 / 32
意图体系不是标签表，是系统接问题的定义表
每一条意图，系统至少要定义清楚这七件事。
定义不清楚，后面的识别、路由、执行全在猜。标签表只管分类，定义表管的是系统怎么接住问题。
让学员理解定义意图不是起个名字，是写一份系统契约。
第二幕 · 从分类到路由12 / 32
阶段是前置上下文，不是意图名
订单阶段不该直接当意图名，它是前置上下文状态。三根轴各管一件事，不能混。
状态轴（阶段）
用户现在在哪
售前、待履约、临近履约、服务中、售后。阶段决定动作空间，不是意图名。
意图轴（动作方向）
用户想推什么
查状态、问规则、求执行、求升级。一级按动作切，不按售前/售后切。
主题轴（对象与话题）
用户在说什么
订单进度、上门时间、人员、退款、返工、物损等。主题跟着对象走。
阶段决定语境，意图体系决定动作，主题决定对象。三根轴拆开，系统才不会把不同性质的东西混在一张表里。
开场金句可照读。
第二幕 · 从分类到路由13 / 32
一级按动作切，不按售前/售后切
4 + 1 结构
查状态
想知道现在怎么样了，覆盖订单、上门、人员、退款、工单、返工进度等。
问规则
想知道规则，覆盖范围、价格、改约、取消、退款、赔付规则等。
求执行
要推进事，如下单、改约、取消、催单、联系、申请退款或返工、补信息等。
求升级
普通处理不够时，如投诉、物损或安全、态度争议、强要人工、严重履约异常等。
兜底 / OOS
落不进体系、信息不足、语义冲突、新场景、需人工判断。
一级意图结构。
第二幕 · 从分类到路由14 / 32
二级看业务对象，三级看可执行诉求
一级定方向，二级定对象，三级定动作。
查状态（一级）拆法示例
- 二级：履约进度 → 三级：查上门进度、查服务人员位置
- 二级：售后进度 → 三级：查退款进度、查返工进度、查工单状态
- 二级：订单信息 → 三级：查订单详情、查预约时间
求执行（一级）拆法示例
- 二级：履约推进 → 三级：催上门、联系师傅、改约
- 二级：售后申请 → 三级：申请退款、申请返工、申请赔付
- 二级：订单操作 → 三级：取消订单、修改地址、补充信息
二级按业务对象聚类，三级按可执行诉求拆。拆到三级，系统才知道该调什么接口、走什么流程。
用两个一级的拆法示例，让学员理解二三级的拆分逻辑。
第二幕 · 从分类到路由15 / 32
完整定义示例：查询上门进度
定义与层级
用户希望获取当前订单对应服务人员的上门状态：是否出发、预计到达、是否迟到、位置等。
层级 一级查状态 → 二级履约进度 → 三级查询上门进度
示例 直接：师傅几点到、到哪了。模糊：怎么还没来、出发了吗。
边界与升降级
不等于催上门、不等于投诉迟到、不等于改约。
超时 + 强不满 → 可升级为催单 / 投诉。纯信息需求 + 无风险 → 留在查进度。
承接动作
锁单 → 取预约与当前时间 → 调履约接口 → 返回 ETA / 是否迟到 → 超时进风险门控。
兜底：信息不足引导补单；高风险转人工。定义写到这个粒度，识别和执行才有据可依。
用一个完整示例让学员理解定义不只是起个名字，是写系统契约。
第二幕 · 从分类到路由16 / 32
多重意图：怎么拆，怎么处理
真实案例拆解
师傅还没到，我要投诉，今天必须给我处理。
- 主意图 求升级 / 投诉履约异常（诉求已从推进履约抬到升级处理）
- 伴随意图 催上门（用户还是想让师傅来）
- 风险标记 高风险（强不满 + 时间压力 + 投诉信号）
处理原则
- 先走主意图路由，决定系统进哪条处理链路。
- 伴随意图挂载不丢，主流程处理完后可以接着推进。
- 风险标记全程跟随，不因为意图切换而被洗掉。
- 升降级有条件，超时+强不满时查询可升级为催单/投诉。
不能只看字面，要看当前动作方向与风险层级。边界画不清，多重意图就拆不开。
多重意图是实际系统中最常出错的地方，处理原则比识别准确率更重要。
第二幕 · 三级识别落地17 / 32
第一级：关键词层——高确定性 + 风险信号
高确定性词：直接走强规则
- 转人工 → 直接转人工，不进分类器。
- 投诉 → 标记高风险，走升级路由。
- 退款 → 进退款流程，不走普通意图。
- 订单号、退款单号 → 直接绑定对象。
风险信号词：叠加风险标记
- 半小时了、还没来、弄坏了 → 不改意图，但叠加风险。
- 风险标记跟着 query 走，后面每一层都能看到。
- 关键词层不做分类，只做拦截和标记。
关键词层的价值不是识别准，是确定性高的不浪费算力，风险高的不漏掉。
PM在这一层的决策：定义哪些词是高确定性、哪些是风险信号。
第二幕 · 三级识别落地18 / 32
第二级：BERT 层——主分类器，扛大头
BERT 做什么
- 关键词没拦住的，全进 BERT。
- 输出：意图标签 + 置信度分数。
- 高置信（>阈值）→ 直接进控制层。
- 低置信（<阈值）→ 交给大模型兜底。
PM 在这一层定义什么
- 分类体系：用什么 taxonomy，几级几类。
- 置信度阈值：设多少才放行，设多少进大模型。
- 输入上下文：要不要叠加阶段、渠道、订单状态、是否超时。
BERT 是主力，但它只管分类。阶段、风险、对象这些事不该压在 BERT 上。
BERT层是线上流量的主承接者，PM要定义taxonomy和阈值。
第二幕 · 三级识别落地19 / 32
第三级：大模型层——只接边界 case
什么时候触发大模型
- BERT 置信度低于阈值。
- 多轮对话，上下文复杂。
- 多意图混合，需要拆解。
- OOS / 新场景，体系里没有的。
PM 在这一层定义什么
- 触发条件：不是所有 query 都过大模型，只有边界 case。
- 输出结构：必须输出主意图、伴随意图、风险、下一步动作。
- 红线：不能替代前面的层做总判断，不能自由发挥。
大模型不是万能兜底，是精准补位。用得越少说明前面的层越稳。
大模型层的核心是受控使用，不是什么都扔给它。
第二幕 · 三级识别落地20 / 32
六步在线管线：一条 query 怎么跑完全程
① 绑定订单
用户进线 → 关联身份 → 锁定活跃订单 → 拿到世界状态（阶段、履约状态、历史承诺）。
② 关键词扫描
高确定性词直接拦截走强规则；风险信号词叠加标记，不改意图。
③ BERT 分类
输入 = query + 阶段 + 渠道 + 订单状态。输出 = 意图标签 + 置信度。高置信放行，低置信进大模型。
④ 大模型补位
只接低置信、多意图、OOS。输出必须是结构化：主意图 + 伴随 + 风险 + 下一步。
⑤ 控制层收窄
Query 统一 → 对象解析 → 风险门控。该停的停，该升级的升级，该走 skill 的走 skill。
⑥ 执行层闭环
触发对应 skill → 调工具 → 生成受控回复 → 记录动作 → 评估闭环质量。
六步不是六个模型，是六个决策点。PM 要定义的是每一步的输入、输出和边界。
这是整个识别管线的完整视图，让学员看到一条query从进来到处理完的全过程。
第二幕 · 从分类到路由21 / 32
五句话收成
关键词拦截、BERT 扛大头、大模型补边界，分工不是抢活。
第二幕收束。五句话对应五个核心认知。
第三幕 · 渠道·Skills·评估22 / 32
同一套策略换个渠道，用户会骂人
输入质量
IM 文本相对完整，企微上下文连续，400 有 ASR 噪声和口语跳跃。原始信息差别很大。
时延容忍
IM 能追问一两轮，企微能持续推进，400 容不得系统长时间澄清。
系统责任
IM 适合自动化承接，企微像推进状态机，400 更像高风险分流。
最危险的是拿 IM 的成功标准去做 400。表面自动化更深了，实际是把高风险问题压在系统里更久。
第三幕开始。
第三幕 · 渠道·Skills·评估23 / 32
怎么还没来放到三个渠道，处理方式就该不一样
渠道
系统先看什么
允许做什么
最怕怎么错
IM文本清晰，能补一两轮信息。
先读订单状态与时间窗，再决定是查进度还是进风险路由。
可自动锁单、澄清、查单、调用 skill，自动化可以做得更深。
该自动闭环的没吃到，白白堆给人工。
企微很多时候是在追上次那件事。
优先看会话推进到了哪一步、上次承诺是什么。
重点是接住历史上下文，把处理往前推。
推进断档，用户反复从头讲，系统显得很笨。
400口语噪声更大，情绪更强，容错更低。
先做身份与订单关联，再做风险分流，少问多判。
宁可保守转升级，也不要让高风险问题继续停留在普通自动化里。
该退出时没退出，系统只会把矛盾越推越大。
这是第三幕最该被记住的一页。
第三幕 · 渠道·Skills·评估24 / 32
旧系统装不下了，所以走向 skills
旧做法怎么崩
- 规则越来越多，prompt 越来越长，状态越来越散。
- 经验分散在不同人脑子里，新人接手极慢。
- 出了问题，说不清是识别错、路由错、还是执行错。
skills 带来的变化
- 经验从口头传承变成模块化能力。
- 执行边界可写清、可复用、可评估。
- 识别、控制、执行的责任终于分开了。
skills 不是追新，是旧系统装不下复杂度的自然结果。
去掉底座宣讲感，只讲为什么必须这样做。
第三幕 · 渠道·Skills·评估25 / 32
拿催单升级 skill 举例：好 skill 接住的是已经收窄过的问题
触发条件
已锁定订单；临近履约或已超预约；用户表达催促/不满；风险门控允许走催单路径。
输入契约
订单对象、预约时间、履约状态、联系能力、历史承诺、当前渠道。缺字段先补，不带缺口硬执行。
执行步骤
确认风险级别 → 调联系/催单工具 → 记录动作 → 生成受控回复 → 必要时转人工或建单。
输出契约
回复至少三件事：承认当前异常、说明已采取动作、给出反馈时点。不能只安抚不给下一步。
失败兜底
对象不明、工具失败、多次不满、触达失败时，直接升级或人工分流，不允许继续安抚。
评估指标
误触发率、执行成功率、风险拦截率、工具成功率、升级及时率、用户后续追问率。
Skill 的职责是把已判定的问题闭环掉，不要再充当总大脑，不然只会越来越胖。
用一个真实 skill 替代抽象框架说明。
第三幕 · 渠道·Skills·评估26 / 32
Skills·评估
更值得盯的口径
- 动作正确率，系统后续动作对不对。
- 对象正确率，有没有拿对订单、工单、退款对象。
- 风险拦截率，该停的时候有没有停。
- 闭环质量，问题有没有真的往前推进。
- 渠道适配度，不同渠道有没有用对成功标准。
把系统评价从 NLP 拉回业务。
第三幕 · 渠道·Skills·评估27 / 32
做对了是什么样
正确的处理方式
AI
非常抱歉让您久等了，您的订单已超过预约时间 32 分钟，我已经联系服务方加急处理，预计 15 分钟内给您反馈进展。如果届时仍未解决，我会直接为您升级处理。
从能回答到能解决，差的不是模型能力，是系统知道什么时候该做什么。
首尾呼应，让听众看到完整的对比。
第三幕 · 渠道·Skills·评估28 / 32
你的系统，哪一层在替别的层扛结局？
问题三
Skill 是不是胖到在吃前置层的不确定性？
互动：让听众对照自己了解的系统思考1分钟。这是第三幕到第四幕的过渡。
第四幕 · 这是你的活29 / 32
AI PM 最值钱的地方：定义边界和结构
不必在这些地方跟算法硬碰
- 模型结构怎么改更优。
- 训练细节怎么调更强。
- 某个 benchmark 的分数高低。
- 参数如何取到最优点。
更该拿住的定义权
- 系统必须知道哪些世界状态。
- 语义坐标系怎么分层——阶段、动作、主题、状态、风险各放哪。
- 自动化边界画在哪，什么时候该停。
- 对象解析、risk gate、skill 契约怎么统一。
- 系统以什么业务口径被评估。
最后交付的不该只是一句 prompt，而应该是一整套能照着落地的材料：意图怎么分、各场景边界怎么划、风险信号怎么判、订单对象怎么锁定、每个 skill 接什么与怎么接、以及业务上用什么指标验收。
从角色价值落到具体交付物。
第四幕 · 这是你的活30 / 32
落地分三回合，别一口气全上
1
第一回合 · 先做底盘
先把系统看世界的方式定下来
先把这几件事定清楚：
- 系统怎么判断现在在哪个阶段
- 系统先看哪些业务事实
- 主要意图怎么分
一句话理解先让系统知道自己面对的是什么问题。
2
第二回合 · 补控制层
再把容易走错的地方拦住
把这几件事补上：
- 用户说的是哪一单
- 这句话到底要往哪条路走
- 什么情况下不能再自动处理
一句话理解先别急着把能力做多，先把错路堵住。
3
第三回合 · skill 与闭环
最后再把处理能力一个个做起来
等前面都稳了，再去做：
一句话理解前面都看清楚了、路也走对了，这时候再把事办深。
能不能进下一回合，不看模块上没上线，看当前主错误有没有从结构性问题降到局部边界问题。
最后给的是推进顺序，不只是方法论。
第四幕 · 这是你的活31 / 32
最后只留三句话
第一句
所有 AI 客服的失败，最后复盘都不是模型的问题。
第二句
意图识别的尽头不是更准，是系统学会在不确定时不动手。
第三句
PM 最难的不是定义系统该做什么，是定义系统不该做什么。
三句话收全场。
AI 客服 · 业务分享2026
分享人 · Austin32 / 32