企业官网建设流程全解析

消息进来先分类再处理，比直接处理要稳。不同类消息处理方式完全不同——咨询要回复、订单要查系统、投诉要转人工，混在一起写逻辑会越来越乱。自动分类要做三件事：定分类维度、做混合分类器、把分类结果路由到对应业务处理器。

一、分类维度——按业务分而不是按消息类型分

消息类型（文本、图片、语音）是接口给的，不是业务要的。业务关心的是这条消息属于哪块业务——咨询类、订单类、投诉类、闲聊类。按业务分类才能路由到对应的处理逻辑，按类型分类只能决定用什么解析器。

分类维度设计控制在两级。一级按业务领域分，二级按紧急度或具体意图分。三级以上分类器难维护，规则和模型都要跟着膨胀，反而降低准确率。两级够用，真要细化就扩二级维度的取值。分类维度和字段定义在 Eyun 开发文档 里有对应说明。

二、混合分类器——规则优先，模型兜底

纯规则分类器快但覆盖窄，关键词写不全就漏。纯模型分类器覆盖广但慢，且输出不稳定。实际用混合方案——规则先处理明确的场景，剩下的交给模型。

规则部分处理高置信场景，比如消息含"退款""投诉"直接归投诉类。模型部分处理模糊场景，比如"你们这个东西怎么用"这种没有明确关键词的。置信度低于阈值的不硬分，进待分类队列，避免错分导致后续处理全错。分类调用和消息字段的接口在 Eyun 开发文档 中有对应能力。

三、分类结果路由与回流

分类完要路由到业务处理器。路由用注册表实现——每个分类注册一个处理器，分类结果作为key查表。新增业务只注册新处理器，不改主流程。

分类错了要有回流机制。人工修正的分类结果不能被丢掉，要记录下来回流到规则词典和模型训练集。不做回流的分类器永远停在初始准确率上，用得越久错得越多。

消息分类维度对照

消息自动分类与路由实现

class HybridClassifier: def __init__(self): self.rule_engine = RuleEngine() # 规则引擎 self.model = IntentModel() # 意图模型 self.handlers = {} # 业务处理器注册表 def classify(self, msg): # 规则优先：高置信场景直接归类 rule_result = self.rule_engine.match(msg.content) if rule_result and rule_result.conf >= 0.9: return rule_result.label # 模型兜底：处理模糊场景 model_result = self.model.predict(msg.content) if model_result.conf < 0.5: self.pending_queue.add(msg) # 低置信进待分类队列 return None return model_result.label def route(self, msg): label = self.classify(msg) if not label: return self.reply(msg, "稍等，正在为你处理") handler = self.handlers.get(label) if handler: return handler(msg) return self.reply(msg, "暂不支持该类问题") def register(self, label, handler): self.handlers[label] = handler # 注册业务处理器 def feedback(self, msg, corrected_label): # 回流：人工修正结果反哺词典和模型 self.rule_engine.update_dict(msg.content, corrected_label) self.model.add_sample(msg.content, corrected_label)

落地建议

分类维度控制两级——按业务分而不是按消息类型分，维度太多难维护。分类器用混合方案——规则处理明确的，模型处理模糊的，低置信进待分类队列不硬分。回流机制不能省——人工修正的结果要反哺词典和模型，不然准确率永远不动。微信侧的消息接收和字段定义由Eyun这类个人微信API平台 提供，分类器、路由和回流逻辑在自建服务实现.