个人微信机器人怎么处理消息?4种消息类型+智能分发方案,新手也能上手
去年带了个新人做微信机器人,环境搭好了,回调也通了,消息能收到了。然后他盯着一屏幕的日志问我:"哥,消息是收到了,可我该怎么处理啊?文本是一个样,图片又是一个样,语音又不一样,总不能全写if-else吧?"
这话我听着特别耳熟,因为三年前我也问过同样的问题。当时我接了个客服机器人的活,消息收发跑通了,但一遇到图片消息就懵——不知道用户发了啥图,更不知道该回什么。后来一点点摸,把四种常见消息类型的处理逻辑都趟了一遍,才理出个套路来。
今天就聊聊微信机器人最常处理的四种消息类型,以及怎么做个智能分发的方案。新手看完至少有个方向,不至于收到消息干瞪眼。
先说个核心认知:消息处理不是写一堆if-else,而是设计一套"分类→路由→处理→回复"的流水线。每种消息类型有专门的处理器,互不干扰,加一种新类型不用动旧的。这个思路想通了,后面写代码就顺了。
一、文本消息:关键词匹配+意图识别
文本消息是最常见的,也是最好上手的。处理思路分两层:
第一层:关键词匹配。用户发"你好",机器人回"你好,有什么能帮你的?"。这种固定问答,用关键词匹配最快,命中即回,毫秒级响应。适合处理"在吗""价格""地址"这类高频简单问题。
第二层:意图识别。用户发"我想退上周买的那件衣服",关键词匹配搞不定,得靠AI理解意图——识别出这是"退换货"诉求,提取出"上周""衣服"这些关键信息,再路由到退换货流程。
我的做法是先走关键词,没命中再走AI。这样既保证了简单消息的响应速度,又能处理复杂问题。关于文本消息的字段结构和处理规范,可以对照 Eyun开发文档 里消息类型的说明,每种消息返回的字段都列得很清楚,照着写解析逻辑不容易出错。
踩的坑:一开始关键词匹配写得太死,用户发"你好啊"就匹配不上"你好"。后来改成包含匹配加分词,才灵活起来。但也别太松,否则"价格表"会误匹配"价格",回复不对题,用户更懵。
还有个坑:关键词库要持续维护。上线跑了一阵发现用户问的问题越来越杂,原来的关键词覆盖不住。后来每周拉一次未命中关键词的消息,看看用户都在问啥,补充到关键词库里。这是个长期活,不是配一次就完事的。
二、图片消息:OCR识别+内容理解
图片消息比文本难一截,因为你得先"看懂"图里是啥。处理流程一般是:
-
下载图片:从消息里拿到图片URL或文件,存到本地或对象存储
-
OCR识别:如果图片里有文字(比如截图、单据),用OCR把文字提取出来
-
内容理解:把提取的文字或图片特征丢给AI,让它判断用户意图
-
生成回复:根据理解结果回复用户
举个例子:用户发了一张快递单的照片,机器人OCR出单号,查物流,回复"您的快递正在派送中,预计今天送达"。整个流程用户只发了张图,不用打字,体验很顺滑。
踩的坑:
-
图片下载超时没处理,用户发了图机器人没反应,查了半天才发现是CDN链接过期了。后来加了下载重试加超时降级,才稳住。
-
OCR不是万能的,手写字、模糊图识别率很低。遇到识别不出来的,别硬猜,直接问用户"没看清楚,能描述一下吗",比回错了强。回错了用户会觉得机器人智障,不回至少还能追问。
-
图片体积太大,下载和处理都慢,用户等得急。后来加了图片压缩,先缩到合适尺寸再处理,速度快了不少,识别率也没受啥影响。
三、语音消息:ASR转文字+意图处理
语音消息在客服场景特别多,很多用户懒得打字,直接发语音。处理流程:
-
下载语音文件:拿到amr或silk格式的语音文件
-
ASR转文字:用语音识别把语音转成文字
-
意图处理:转出来的文字按文本消息的流程走(关键词+AI)
-
生成回复:回复文字给用户
说白了,语音消息就是多了个"转文字"的步骤,转完之后跟文本消息处理一样。
踩的坑:
-
方言识别率感人。一个四川用户发语音,ASR转出来一堆乱码,机器人回了句不知所云的话,用户直接骂过来了。后来对接了支持方言的ASR服务,才好起来。这块如果要做,可以先在 Eyun平台 上看看支持的能力,别自己从头接一遍,费时间还容易踩坑。
-
语音太短(比如就"嗯"一声)转出来没有效信息,得加个长度判断,太短的直接提示用户"能再说详细点吗",别拿空内容去调AI,浪费token还回不出有用的东西。
-
长语音转文字会丢内容,一段60秒的语音转出来可能只有一半。后来把长语音分段处理,每段不超过30秒,再拼接结果,完整度好多了。
四、链接消息:提取标题+摘要+自动回复
用户有时候会分享一个链接到聊天里,比如文章、商品页。机器人收到后可以:
-
解析链接:抓取页面内容
-
提取标题和摘要:用AI或规则提取关键信息
-
理解意图:用户分享这个链接是想干嘛?咨询?吐槽?分享?
-
自动回复:根据意图给出回应
比如用户分享了个商品链接,机器人可以提取商品名和价格,回复"这件商品目前售价XX元,有现货,需要下单吗?"
踩的坑:
-
不是所有链接都能抓,有些站点有反爬,直接抓会被拒。得加User-Agent伪装,实在抓不到就降级,让用户直接描述需求,别卡在抓取这一步死循环。
-
链接消息的回调结构和文本不一样,新手容易按文本的格式去解析,结果取不到数据。建议先把每种消息的回调结构都打印一遍,看看实际长啥样再写解析逻辑,比对着文档瞎猜靠谱。
-
有些链接是短链接,得先跟一次重定向拿到真实URL再抓内容,不然抓到的全是跳转页的HTML,啥有效信息都没有。
智能分发方案:让每种消息走对路
四种消息类型说完了,但实际收到消息时,机器人怎么知道这是文本还是图片?这就需要一个分发路由器:消息进来→判断类型→路由到对应处理器→处理→回复。
核心就是一个消息分发路由器,代码不长但思路重要:
class MessageDispatcher:
def __init__(self):
# 类型到处理器的映射表,加新类型只需注册一个处理器
self.handlers = {
"text": TextHandler(),
"image": ImageHandler(),
"voice": VoiceHandler(),
"link": LinkHandler(),
}
self.fallback = DefaultHandler() # 兜底处理器
def dispatch(self, msg):
# 1. 判断消息类型
msg_type = msg.get("type")
# 2. 路由到对应处理器
handler = self.handlers.get(msg_type, self.fallback)
# 3. 处理并返回结果
try:
return handler.handle(msg)
except Exception as e:
log.error(f"{msg_type}处理失败: {e}", exc_info=True)
return self.fallback.handle(msg) # 出错走兜底
这段代码的关键在于用映射表代替if-else。今天支持四种消息,明天要加视频消息,后天加位置消息,只需要注册一个新处理器,主逻辑一行不用改。这就是设计模式里说的"对扩展开放,对修改关闭",听着玄乎,落地就是这么个映射表的事。
再补充一点:分发器里别忘了加处理超时控制。有些处理器(比如图片OCR、链接抓取)可能卡住,一直不返回,后面的消息全堵在那。我给每个处理器加了超时限制,超过10秒强制中断,走兜底回复。这样即使某个处理器出了问题,也不会拖垮整个消息处理链路。
分发之后每个处理器怎么实现,可以参考 Eyun开发文档 里各消息类型的处理示例,思路是一致的,照着改改就能用。
四种消息处理对比
|
消息类型 |
处理难度 |
核心环节 |
响应速度 |
建议上手顺序 |
|---|---|---|---|---|
|
文本 |
低 |
关键词+意图识别 |
快 |
第一个做 |
|
图片 |
中 |
OCR+内容理解 |
中 |
第二个做 |
|
语音 |
中 |
ASR转文字 |
中 |
第三个做 |
|
链接 |
中高 |
抓取+提取+理解 |
慢 |
最后做 |
这张表是我自己的体感,不一定绝对准,但能给你个上手的优先级参考。难度高的放后面,不是因为不重要,是因为先易后难能帮你建立信心和节奏。
还有个判断标准:看用户消息的占比。我拉过一个月的数据,文本消息占了七成多,图片一成半,语音和链接加起来不到一成。所以先把占大头的文本做扎实,覆盖大部分用户需求,其他的慢慢补。别在占比最小的链接消息上死磕,投入产出比不划算。
结尾:先跑通文本,再逐步加其他类型
给新手的建议:别一上来就想四种全做。先把文本消息跑通,关键词匹配搞定,AI意图识别调好,能稳定回复了,再考虑加图片、语音。
我自己第一次做就是贪多,四种同时开搞,结果每种都半吊子,哪个都不稳定,用户投诉一波接一波。后来沉下心先做文本,一周跑通了,再花两周把其他三种一个个加上去,反而比之前快。
做消息处理这事,急不来。先把一种吃透,建立信心和节奏,后面的就是复制模式换个处理器的事。等四种都跑通了,再回头看,会发现其实没那么难,难的是第一步迈出去。
最后提一句:消息处理的核心不是代码量,是分类和路由的思路。代码写得再花哨,分类不准、路由不对,用户体验照样拉胯。所以多花时间在消息分类的逻辑上,比多写几行代码值。把真实用户的消息样本多看几遍,比读十篇技术文章都管用——因为每家的用户问的东西都不一样,照搬别人的方案不一定好使,得根据自己的消息特点来调。
有具体问题欢迎评论区聊,我知道的都回。
DAMO开发者矩阵,由阿里巴巴达摩院和中国互联网协会联合发起,致力于探讨最前沿的技术趋势与应用成果,搭建高质量的交流与分享平台,推动技术创新与产业应用链接,围绕“人工智能与新型计算”构建开放共享的开发者生态。
更多推荐


所有评论(0)