前言

上一篇《真心建议做一人企业的你，早点把智能客服搭起来》发出去之后，被问得最多的就是那句对接企业微信到底怎么接。
所以这篇单独把它拆开，写成一份对接文档，把入口选型、消息链路、服务端职责和几个坑一次讲清。

我的场景没变。
青萍语音小程序里有专属客服入口，公众号上也挂了咨询入口，两边消息统一汇进企业微信的微信客服通道。
AI 在后面接住重复咨询，拿不准的再转给我。

入口为什么选微信客服

先回答选型问题，自己做个客服页面不行吗？
行是行，但有两个绕不开的麻烦。
一个是触达，客户咨询完就退出了，你的回复要能推进他的微信里，这需要消息通道足够稳。
另一个是入口覆盖，客户分散在小程序、公众号、视频号里，每个地方都得做一个咨询入口。

微信客服是腾讯官方的客服组件，天然解决这两件事。
用户在微信里点开就能聊，不用加好友，不用关注。
小程序、公众号、视频号、搜一搜、网页，都能挂上客服账号，客户不管从哪里进来，最后都汇到同一个客服账号。
更关键的是，企业可以用 API 完全接管客服账号，消息收发、会话分配全部程序化处理，这正是 AI 客服需要的地基。

有一个开关要对准。
在管理后台把客服账号设为通过 API 管理之后，企微原生的接待规则就不再生效，所有消息都交给程序处理，AI 什么时候回、人工什么时候上，都由代码说了算。

消息怎么流进我的服务

这是整篇最值得读的一节，因为消息链路跟直觉不太一样。

企微的回调并不推送消息内容，只通知一声有新消息。
真正的交互分两步，企业微信先把事件发到我指定的回调地址，我再拿着事件里的凭据去调拉取接口，把消息内容取回来。

完整走一遍是这样的。
客户在小程序里发了一句咨询，企微回调一个事件给我的服务，我调 sync_msg 接口拉到这条消息，检索知识库交给大模型组织答案，再调发送接口把回复写回会话，客户在微信里几秒内收到。

几个细节单独拎出来说。
拉取接口靠游标做增量，官方明确建议把游标落库，每次接着上次的位置拉，服务中断重启也能续上，不丢消息。
消息里有个 origin 字段区分来源，客户发的、系统事件、接待人员人工回的各有编号，我的服务只响应客户消息，人工消息直接跳过，不然 AI 会跟自己对聊。
单次拉取上限 1000 条，消息保留 3 天，对一人企业的咨询量绰绰有余。

服务端要干的四件事

注册自建应用。
在企业微信后台创建一个自建应用，配置成微信客服可调用的应用，拿好凭据，按指引填回调地址完成验证。

实现回调与拉取。
回调服务收到事件就触发拉取，解析出文本消息，转给 AI 编排层。

接 AI 编排。
先检索知识库命中相关片段，再让大模型基于片段作答，具体做法上一篇写过，这里不重复。

监听回复与异常。
回复走发送消息接口，同时订阅发送失败事件，哪条消息没送出去、什么原因，都要能感知。

有一个时间窗口必须心里有数。
客户发消息后的 48 小时内，企业才能主动发消息，超窗再发会收到会话过期的失败通知。
AI 回复都是紧跟客户消息的，正常聊不到这条线，但想发主动关怀消息时就得掐着表。

人工兜底怎么做

AI 的定位是把重复问题滤掉，而不是把服务全接走。
咨询量还小的阶段，其实不用急着写代码，企微原生的接待加快捷回复就能顶一阵，等重复问题占比上来了再上 AI 也来得及。

我的规则有三条。
知识库里检索不到依据的问题，AI 不硬答，标记出来提醒我。
客户表达不满或者谈到报价成交，立即转人工。
人工在企微客户端接进去之后，AI 对这个会话自动让位，判断依据就是前面说的 origin 字段和会话状态事件。

客户那头是无感的，他分不清回答的是人还是 AI，只知道这家店回消息真快。

踩过的坑，记三条

回调验证卡过我一阵，回调地址要公网可访问，还要按企微的加解密规范回应校验请求，本地调试得先搭好内网穿透。

接口突然报 60030，查了半天才发现是接待人员不在应用的可见范围里，把他加进去就好了。

印象最深的一次是服务重启后游标没恢复，把 3 天内的历史消息重新拉了一遍，AI 对着旧消息挨个回，答非所问。
从那以后，游标落库和消息去重成了我上线前必查的两项。

现在这条链路日夜替我守着微信，我最近在做的事，是把 AI 没答好的对话逐条翻出来补进知识库，让下一轮回答更准。