LikeShop 智能客服自动回复二开：关键词匹配答疑、订单类问题自助解决 - 文章 - 开发者社区

一、原生客服的真实形态：一个“话术库”，不是一套应答引擎

LikeShop 原生确实有在线客服和IM客服系统，也提供了“客服话术”功能，运营可以在后台新增话术条目，客服在工作台快捷调取、发送给用户。微信公众号侧还有“关键词回复”能力，回复类型分为关注回复、关键词回复和默认回复，匹配方式支持全匹配和模糊匹配，关键词相同同时按 sort 排序值决定优先级。

但把这套能力放到 LikeShop 的 IM 客服工作台里看，它的本质是“人工客服的辅助工具”，不是“自动应答引擎”：话术是给客服点选发送的，不是用户发消息后系统自动匹配回复的；微信公众号的关键词回复是独立商城 IM 的另一套配置，不读取订单状态，不感知用户身份，更不会因为“用户问的是某笔具体订单的物流”而自动去查库。

这就导致一个很现实的局面：物流到哪儿了、什么时候发货、退款怎么还没到、优惠券怎么用——这些占客服兑换量最大比例的问题，用户每问一次，就需要人工客服切一次订单列表、查一次物流、翻一次规则文档，然后手动组织语言回复。话术库只是让“打字”快了一点，没有让“判断”快一步。

智能客服二开要做的，不是把话术库做得更大，而是在用户消息进入人工客服之前，插入一层自动应答流水线：先判断这句话能不能被知识库或订单接口自动解决，能解决就自动回复，解决不了才转人工。核心策略是：不修改 LikeShop 原生 IM 的会话和消息土链路，自动应答作为消息分发前的“拦截层”独立建表、独立执行；订单查询走只读接口，不写订单状态；转人工保留显著入口，不被自动回复淹没。

二、知识库：从“话术文本”到“可检索的标准问-答对”

2.1 话术和知识的本质差异

原生话术的字段是“标题 + 内容 + 排序”，它建设的是“客服已经知道该发哪条话术”。知识库的字段必须多一层“这个问题怎么被匹配到”——标准问、相似问、关键词、分类、适用场景、生效时间。没有标准问和相似问，关键词匹配就只能靠运营把用户可能说的每一句话都穷举一遍，维护成本会迅速失控。

知识库表的设计参考 FAQ 的通用结构，把“问题侧”和“答案侧”放在同一条记录中，同时保留分类和优先级：

sql

CREATE TABLE `ls_kb_entry` (
  `id` int UNSIGNED NOT NULL AUTO_INCREMENT,
  `category_id` int UNSIGNED NOT NULL DEFAULT 0 COMMENT '知识分类ID',
  `standard_question` varchar(200) NOT NULL COMMENT '标准问',
  `similar_questions` text COMMENT '相似问列表，JSON数组',
  `keywords` varchar(500) NOT NULL DEFAULT '' COMMENT '关键词，逗号分隔',
  `answer_type` tinyint NOT NULL DEFAULT 1 COMMENT '答案类型：1-文本，2-图文，3-订单查询指令',
  `answer_content` text COMMENT '答案内容',
  `priority` int NOT NULL DEFAULT 0 COMMENT '优先级，数值越大越优先',
  `match_threshold` decimal(4,2) NOT NULL DEFAULT 0.60 COMMENT '最低匹配得分',
  `is_enable` tinyint NOT NULL DEFAULT 1,
  `effective_start` int UNSIGNED NOT NULL DEFAULT 0,
  `effective_end` int UNSIGNED NOT NULL DEFAULT 0,
  `create_time` int UNSIGNED NOT NULL DEFAULT 0,
  `update_time` int UNSIGNED NOT NULL DEFAULT 0,
  PRIMARY KEY (`id`),
  KEY `idx_category` (`category_id`),
  KEY `idx_enable_priority` (`is_enable`, `priority`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='客服知识库条目表';

answer_type 是知识库和话术库的关键分野：类型 3（订单查询指令）意味著这条知识不是返回一段静态文字，而是触发一次受控的订单查询动作，把结果化结果组织成自然语言回复。这是“自动答疑”和“自助解决订单问题”的交汇点。

effective_starta 和 effective_end 用于活动规则类知识——大促期间的运费规则和日常不同，过期知识不应该继续被匹配到，定时上下线比人工逐条禁用更可靠。

2.2 知识的三层结构

知识库不能把所有内容平铺在一个层级上。建议按“商品事实 → 服务规则 → 平台政策”三层组织：商品事实包括规格、材质、适用场景；服务规则包括发货时效、退换条件、运费承担；平台政策包括优惠券使用规则、积分规则、发票流程。三层知识的匹配优先级和兜底策略不同——商品事实类问题匹配不到时可以引导用户换一种问法，平台政策类问题匹配不到时应该直接转人工，因为政策解释错误的代价远高于“没答上来”。

三、关键词匹配：全匹配保准确，模糊匹配保召回

3.1 原生全匹配/模糊匹配的工程含义

LikeShop 原生回复管理的 matching_type 只有1（全匹配）和2（模糊匹配）两档。全匹配要求用户消息与关键词完全一致，准确率极高但召回率极低——用户说“请问什么时候发货”和“什么时候能发货”，全匹配“什么时候发货”都命中不了。模糊匹配通常退化为“关键词包含在消息中”，又会引入误命中——用户说“我不想要这个了，能退款吗”，但用户真正想要的是售后流程，不是退款规则。

只靠两档匹配方式，无法在“答得准”和“答得多”之间取得平衡。

3.2 三层匹配策略

更可落地的做法是把匹配拆成三层，按优先级依次尝试：

第一层，全匹配（精准命中）。用户消息与标准问或某个相似问完全一致时直接命中，准确率最高，用于处理“发货时间”“退货地址”这类用户表述高度固定的高频问题。
第二层：关键词加权匹配。从用户消息中提取关键词，与知识条目的 keywords 做加权计算。关键词分核心词和场景词两级——核心词（如“退款”“发货”“发票”）决定命中的主题域，场景词（如“多久”“怎么”“在哪里”）用于区分同一主题下的不同问法。得分公式为核心词命中数 x 2 + 场景词命中数 x 1，除以该条目关键词总数做归一化，再与 match_threshold 比较。
第三层，字符级模糊匹配（降级）。前两层都未命中时，用 2-gram 切词 + 余弦相似度做兜底，相似度阈值建议在0.6-0.75 直接。这一层只用于“可能相关”的候选排序，不直接作为高置信度答案返回——命中后仍然展示给用户“您是不是想问：......”的确认选型，而不是直接给出确定性的答案。

排序与冲突处理：同一层内命中的多条知识，按 priority 降序排列，priority 相同时按 match_threshold 从高到低。如果一条知识的得分低于其自身的 match_threshold，即使它是最高分也不返回，进入兜底逻辑。

php

public function match($message)
{
    $normalized = trim($message);

    // 第一层：全匹配
    $entry = KbEntryModel::where('is_enable', 1)
        ->where(function ($q) use ($normalized) {
            $q->where('standard_question', $normalized)
              ->whereOr('similar_questions', 'like', '%"' . $normalized . '"%');
        })
        ->order('priority', 'desc')->find();
    if ($entry) return ['entry' => $entry, 'layer' => 'exact'];

    // 第二层：关键词加权
    $candidates = $this->keywordScore($normalized);
    if (!empty($candidates)) {
        return ['entry' => $candidates[0]['entry'], 'layer' => 'keyword'];
    }

    // 第三层：2-gram 模糊，返回候选列表而非单一答案
    $fuzzy = $this->fuzzyCandidates($normalized);
    return ['candidates' => $fuzzy, 'layer' => 'fuzzy'];
}

四、订单类问题自助解决：只读查询 + 身份校验 + 结构化答复

4.1 什么能自动查，什么不能

订单自助查询的边界必须画清楚。能自助查的：订单状态、物流轨迹、退款进度、优惠券是否到账，发票开具状态——这些是“查询事实”，不改变任何业务状态。不能自动处理的：修改收货地址、取消订单、发起退款、修改发票抬头——这些是“执行操作”，涉及资金和履约，必须由人工或用户本人在订单页面完成。智能客服的定位是“告诉用户现在是什么状态、下一步该去哪里”。而不是“替用户操作”。

4.2 身份校验是订单查询的前置条件

智能客服查询订单，必须先确认“这条消息的发送者有权查看这笔订单”。如果用户在对话中报出一个订单号，客服直接按订单号查库返回，等于任何人都能通过猜订单号查看让他人的订单信息。

正确的做法是双因子校验：用户消息中提取订单号，同时从当前会话的登录态中取用户ID，查询时必须同时满足order_sn =提取订单号 AND user_id = 当前登录用户。未登录用户不提供订单查询能力，只返回知识库的通用答复。

php

public function queryOrder($userId, $message)
{
    if ($userId <= 0) {
        return ['type' => 'need_login', 'tip' => '请先登录后查询订单'];
    }

    preg_match('/\b(\d{12,20})\b/', $message, $m);
    if (empty($m[1])) {
        return ['type' => 'need_order_sn', 'tip' => '请提供订单号'];
    }

    $order = OrderModel::where('order_sn', $m[1])
        ->where('user_id', $userId)
        ->find();
    if (!$order) {
        return ['type' => 'not_found', 'tip' => '未找到该订单，请核对订单号'];
    }

    return $this->buildOrderReply($order);
}

4.3 结构化结果的答复组织

订单查询返回的是结构化数据，但用户需要的是自然语言。组织答复时按订单状态分文；待发货返回“预计发货时间”，已发放返回最新物流节点 + 物流单号，售后中返回当前售后子状态状态子状态和下一步操作指引。不返回一段原生 JSON，也不把订单了的敏感段（完整手机号、详细地址）原样回显——脱敏是自动答复的底线。

如果订单状态设计需要人工判断”的节点（如售后被驳回=物流异常停滞），自动回复只陈述事实，并附带“是否转人工进一步处理”的选项，不管用户做判断。

五、转人工：兜底、显式入口与上下文交接

5.1 转人工的三个触发条件

智能客服必须保留清晰的转人工路径，而不是把用户困在自动回复循环里。触发条件收敛为三类：

显式要求。用户消息中包含“转人工”“人工客服”“找客服”等意图，直接转接，不做任何二次确认。国标和行业实践都明确要求人工入口醒目、不得层层隐藏。
连续未命中。同一会话连续 2-3 次自动应答未能命中或用户表示“答非所问”，触发转人工。兜底话术可以先行安抚，但不应无限循环。
高风险意图。涉及价格争议、退款金额、赔偿、投诉、人身安全等场景，自动回复只做规则解释和材料收集，最终确认必须由人工完成。这类意图通过关键词 + 分类联合判断，不依赖单一关键词命中。

5.2 上下文交接

转人工时，把自动应答阶段收集的信息一并带给人工客服：用户已发送的消息、命中的知识条目、已查询的订单号和状态、未命中的原因。人工客服不需要从零开始重新问一遍，用户体验是连续的，而不是“换了一个人就要重新讲一遍问题”。

六、后台配置与开发注意事项

6.1 后台配置清单

配置项	类型	说明
智能客服总开关	开关	关闭后所有消息直接进入人工工作台
知识分类树	树形结构	商品事实 / 服务规则 / 平台政策三层
知识条目管理	动态列表	标准问、相似问、关键词、答案类型、优先级、生效时间
关键词匹配权重	配置	核心词权重、场景词权重、归一化方式
模糊匹配阈值	数字	默认 0.6–0.75，低于阈值不返回答案
订单查询开关	开关	是否允许自动查询订单状态和物流
连续未命中转人工次数	数字	默认 2–3 次
高风险意图词表	文本	触发强制转人工的关键词和分类
兜底话术	文本	未命中且未转人工时的引导话术

6.2 开发注意事项

自动应答是消息分发前的“拦截层”，不是人工工作台的替代品。用户消息先经过意图判断和知识匹配，能自动解决的直接回复并不创建人工工单，解决不了的才进入人工队列。这个顺序不能反——先创建工单再自动回复，人工客服看到的会是大量已经被自动答复过的“空工单”。
订单查询必须做用户身份绑定，不能只凭订单号。order_sn + user_id 双条件校验是防止订单信息越权泄露的最低要求。未登录用户只走知识库通用答复，不开放任何订单查询能力。
模糊匹配只做候选推荐，不直接当作确定答案。2-gram 相似度在阈值边缘时误命中率不低，直接返回“确定答案”会让用户觉得“客服在胡说”。低置信度时返回“您是不是想问”的候选列表，比强行给一个错误答案更安全。
转人工入口必须显式、可达。连续未命中后的转人工是“兜底”，但用户主动说“转人工”时转人工是“权利”。后者不能被自动回复拦截或要求“先描述问题”，否则会直接触犯用户体验和合规底线。
知识库的生效时间必须参与匹配。活动规则类知识过期后继续被匹配到，比“没答上来”更危险——用户会拿着过期的规则截图来投诉。effective_start 和 effective_end 在查询时必须作为硬条件，不能只在展示时判断。
兼容性。新增的知识库表、匹配日志表、转人工规则表独立于 LikeShop 原生的 IM 会话表和客服话术表。智能客服作为消息分发前的独立 Service 运行，不修改原生 IM 的消息投递逻辑；关闭总开关时，所有消息行为回退到原生人工工作台。订单查询走只读模型，不调用 OrderLogic 的任何写方法，不影响订单状态机和库存扣减链路。