企业微信客户群机器人怎么做

默认沉默，比答得准更值钱

客户群的消息流是杂的：客户在聊自己的事，销售在跟进，群里可能还坐着第三方的人。一个无差别监听全部消息、靠语义判断要不要开口的机器人，在这种环境里的稳定表现就是时不时冒出一句莫名其妙的话。触发条件必须是显式的、可枚举的、运营同学扫一眼就能看懂的。

• 显式点名：群里点到这个账号，是最没有歧义的触发面。
• 指令前缀：约定一个日常聊天里不会出现的前缀，适合群内的自己人用，客户看不懂也就不会误触。
• 白名单词表：只对明确列举的词有反应，词表由运营维护、可以随时下线，不需要发版。

这三种之外一律不回。听起来保守，但客户群机器人的价值来自它在该说话的时候可靠，不是来自它无处不在。真想做开放式问答，先在内部群或者单聊里跑几周，把误答率压到你敢在客户面前承担的水平再说。

有一类消息看着该回、其实最不该抢答：客户点名找某个销售。机器人这时候插进去，等于当着客户的面把人替了。正确处理是走提醒 —— 把消息推给被点到的人，约定时间内没人接，再由机器人兜一句「已经通知同事」，而不是直接开始答业务问题。

还有一件产品上的事要早定：客户看到的只是一个账号头像，分不出对面是人还是程序。让机器人发出的内容带一个稳定、克制的标识 —— 一句固定的开头或者结尾都行 —— 客户不会觉得被骗，你自己在事后翻记录时也能一眼分清哪些话不是同事说的。

同一条群消息，可能到达你两次

这是客户群特有的坑：一个外部群里常常同时有你们的多个企业微信账号，销售一个、客服一个。如果它们都托管在你的系统里，同一条群消息会以不同账号的视角被推过来多次，不处理的结果就是机器人在群里连着回三遍。

解法不是按账号去重 —— 那样每个账号都觉得该由自己回。要把「群 + 消息」当成一次会话事件的唯一标识，先在群维度选出一个负责应答的账号（固定指定，或者按群做稳定哈希分配），只有它继续往下走路由，其余直接丢弃。用 wecomapi 的群消息事件驱动时，事件里带有群与消息两个维度的标识，用它们拼幂等键，别用本地生成的时间戳 —— 两个账号收到同一条消息的本地时间几乎不可能相同。

// 示意逻辑。normalize 是你自己的接入层，原始事件的字段名以线上文档为准
async function onGroupMessage(raw) {
  const e = normalize(raw);                 // { group, message, speaker, text }
  if (!shouldSpeak(e)) return;              // 点名 / 前缀 / 词表，命中才继续

  const key = `${e.group}:${e.message}`;    // 群 + 消息，不带账号
  if (!(await dedupe.acquire(key))) return; // 同群多账号只留一个
  if (!(await quota.take(e.group))) return; // 每群每小时的发言上限

  const reply = await route(e);
  if (!reply) return;                       // 路由不中就闭嘴，别发「系统繁忙」
  await send(e.group, reply);               // POST https://manager.wecomapi.com/message/sendText
}

选哪个账号来应答也是个判断。固定一个「机器人账号」最清晰，但客户看到的是一个从没跟进过他的陌生头像；用群里已有的客户经理账号来回，体验连贯，代价是这个人的会话里会混进自动发出的内容，人工接手时得能立刻分清。两种都可行，别在同一批群里混着用。

入群欢迎的三个坑都在时序上

入群欢迎是客户群机器人最常见的第一个需求，也是最容易在上线当天翻车的一个。三个坑全都出在时序上，跟话术写得好不好没有关系。

1. 1事件到达时，这个人的资料未必已经可查。想在欢迎语里带上称呼或者来源标签，很可能拿到空值。允许一次短暂的延迟重试，仍然拿不到就退回不带称呼的通用话术，绝不能发出一句「欢迎 undefined」。
2. 2批量入群会刷屏。活动扫码进群时几十个人在一分钟内涌进来，逐条欢迎等于自己在群里刷屏。用一个几十秒的窗口把入群事件聚合成一条，宁可晚一点、合并着说。
3. 3同一个人反复进退群。冷却要按「人 + 群」记，不是按事件记 —— 一天之内同一个人再次入群，不该再收到一次欢迎语。

第四个判断和时序无关，但同样常被跳过：入群来源决定话术。扫码进来的、被销售拉进来的、被其他成员邀请进来的，需要听到的第一句不一样。来源拿得到就分开写，拿不到就用通用话术，别靠猜 —— 猜错的欢迎语比没有欢迎语更伤。

还有一个要先定的产品选择：欢迎语发群里还是私聊。群规、服务时间这类公共信息发群里合适；带个人信息、带引导链接的走私聊更合适，也不占群里的注意力。两个都要，就群里一句短的、详细内容私聊补。这两条在 wecomapi 的发送接口里是同一种调用形态，区别只在收件方是群还是人，业务层不必为此分叉出两套逻辑。

群里的关键词路由，三种典型错法

单聊的路由环境很干净：一个人、一条时间线、一个上下文。群里这三样全都不成立，把单聊那套直接搬过来，最常见的是下面三种错法。

• 分不清谁在问。发言人和「这条消息在替谁问」未必是同一个人，销售完全可能在替客户转述。回复时把问题原文带上、明确回给发言人，比默默回一句更不容易造成误会。
• 把整群消息当上下文。群里的消息是交错的，把最近二十条不加区分塞进上下文窗口，模型会把三个人的话拼成一个人的诉求。会话键应该是「群 + 发言人」，不是「群」。
• 会话不设超时。群里没有「会话结束」这个信号，一段多轮问答隔了两小时又被接上，答出来的东西必然错位。给会话一个几分钟的静默超时，超时就断开重来。

还有一笔账要算：群里的消息量比单聊高一个量级，把每条群消息都送去做意图分类，账单涨得比效果快。先用词表把明显不需要理解语义的挡在外面，剩下的再往上送。

路由本身三级就够：精确词表最优先，然后是意图分类，都不中就沉默或者交给人。用 wecomapi 的事件回调拿到群消息之后，接入层要做的第一件事是把它归一化成内部事件，路由层只认这个内部结构 —— 谁点的名、消息里的格式标记、来自哪个账号，全都该在接入层剥干净。路由层一旦开始关心原始事件长什么样，它就再也换不掉了。

群里坐着的是人，不是一张成员表

下面三件是客户群里最容易被顺手加上的想法，前两件在能力边界上本来就不成立，第三件能做，但一定会在合规评审上被拦下来。

• 自动私聊群里的陌生成员。群成员和客户是两个集合，同在一个群不等于建立了可直接触达的关系，这条在能力边界上就不成立。要单独联系，可行路径是在群里做引导，由本人发起或明确同意之后再走添加流程。
• 自动把群成员整体搬进另一个群。同样受上一条的限制，而且人是自己进来的，不是可以被搬来搬去的资源，这类操作的投诉率通常高过它带来的转化。
• 把群聊原文不加限制地落进内部系统。客户群里的内容含有对方的业务信息，落库要有明确的访问权限、保留期限和用途说明 —— 这条在合规评审时一定会被问到。

共同点是它们都把「群」当成了一个可以随便操作的数据结构，而群里坐着的是人。客户群机器人做加法的空间本来就小，把这三样去掉，剩下的部分反而更容易被接受。

同理还有主动开口：机器人一旦具备了不被触发也能发言的能力，频次、时段和分层就得单独管一套，那是另一个话题，站内另有一篇。这里只强调一条边界 —— 应答型机器人的发言应当全部由群内的动作触发，不接受外部定时器直接驱动它在客户群里说话。

上线前必须有的五个开关

这五个开关不是「有余力再加」的东西。客户群机器人出问题的时刻通常是半夜或者周末，那个时候你需要的是一个能立刻止损的旋钮，不是一次紧急发版。

1. 1群级开关。任何一个群都能被单独关停，不用发版。客户投诉时你需要的是三十秒内让它闭嘴。
2. 2发言频次上限。每群每小时最多几句，撞上限就沉默并告警。这个数比你以为的要小，通常是个位数。
3. 3兜底行为。路由不中、下游超时、模型报错都要有明确动作，默认是不发，而不是发一句「系统繁忙」。
4. 4转人工入口。群里的人要知道怎么找到真人，机器人回答之后留一个明确的去处。
5. 5全量日志。谁触发的、命中哪条规则、发了什么、耗时多少。客户群里的每一句话都可能需要事后解释。

五条里最容易被砍掉的是全量日志，理由通常是「群消息量太大，存不起」。真要省，只存机器人自己参与的那些轮次就行 —— 触发的那条消息、命中的规则、发出去的内容、耗时，量级立刻降下来，而它们恰好就是事后需要拿出来解释的全部。