客户说机器人回了两遍」——这类工单里，研发爱查发送，产品爱怪模型。消息回调重推很难彻底消灭，但重复消费可以消灭。去重规则写在你自己的服务里，这是底线能力。

回调出问题最难受：客户说机器人不理人，你日志里一片安静，或者只有一句「error」。没有线索，就只能猜。

活跃群一天进进出出，机器人成了群里最大噪音源。欢迎可以有，但要限频：同一个人一天一次够了。还有个细节：群消息常常带着「谁说的」前缀。某团队给学员群接了关键词自动回复：有人喊「打卡」，机器人就甩作业链接；有人发广告词，机器人就警告，警告两次踢人。「打开」「打卡」「链接」这种短词，群里天天有。十几个群同一句话连发，没有灰度，没有间隔。发猛了，号先受不了，群友也受不了。新规则先记录「本该踢谁」，跑两天再

服务重启、历史同步、失败重试，都可能让你「回两遍」。不回显得死，回两遍显得傻。你还在慢悠悠思考，对面已经当你死了，这次推送直接扔掉。个人微信自动化那套，消息不是你去「拉」的，是平台往你服务器「推」的。推过来之后，规矩很死：你得在大概三秒内点头说「收到了」。你要是不管三七二十一见消息就回，机器人可能跟自己聊起来，越聊越热闹，客户看得一脸懵。所以你要是遇到「在线但不回」，别先骂大模型，也别先重启微信。

AI 客服要跑起来，瓶颈往往不在「能不能生成一句像样的话」，而在整条接待流水线：账号是否在线、咨询是否进队、规则与模型如何分流、答复如何发回原会话、该转人工时是否真的停掉自动。个人微信没有官方接待机器人；自动化接待通常是节点保活 + 回调入站 + 发送出站，AI 挂在队列后面。

客户已经在微信里问进度、催报价，若还靠人工逐条翻会话，响应和质检都很难规模化。「自动处理咨询」不是某个 AI 专用开关，而是一条固定流水线：话进来 → 服务判断能否自动答 → 能则生成并发送，不能则转人工。个人微信客户会话没有官方机器人 URL，通道一般是回调收、发送回。

客服机器人最难看的现场，是客户连收两句一模一样的话。根因通常不是词库，而是这篇讲消息去重怎么做。

Node 适合做微信机器人网关：回调是 HTTP，发送也是 HTTP，事件驱动和队列都顺手。个人号没有官方 Node SDK 时，自己包一层 client 即可。这篇用 Express 给出可落地的接入方式。

用 Python 做微信机器人，适合快速验证规则和接大模型。个人号侧一般是 HTTP 通道：你发请求登录和发送，对方把新消息 POST 到你的 webhook。这篇用 FastAPI 写最小可运行结构，Flask 同理。

用 Java 做微信机器人，适合已经有 Spring 后台的团队。这篇按 Spring Boot 习惯写最小闭环，不绑具体厂商。