用 Python 做微信机器人最常见的起步方式是找个示例、复制一段发送代码、在测试好友上点一点。能发出去当然高兴但一接到真实业务——自动回、CRM、AI——就会发现收不稳、回双份、偶发找不到人。个人微信 API 实战建议把目标定小一点先跑通最小收发闭环。闭环的意思是消息能稳定进来处理不重复回复回得对人并且留得下日志。GeWe API 可作为通道接到你的 Python 服务具体字段和调用方式以官方文档为准这里不编造参数。闭环长什么样客户发消息 → 你的 Webhook 收到推送 → 校验 去重 入队 → 快速返回成功 → Worker 取出任务 → 生成回复先写死一句话也行 → 发送 → 记录结果 客户手机里能看到回复别把「调通一个发送例子」当成闭环。没有「收」和「去重」上线后一样会炸。Python 侧怎么拆两个角色角色 AWebhook 服务Flask / FastAPI 均可负责接收回调做来源校验按你配置的安全方式生成去重键重复则直接成功返回把原始事件写入 Redis 列表、RQ/Celery、或数据库任务表马上返回角色 BWorker 服务负责循环取任务匹配关键词或调用业务逻辑调用发送能力把回复发出去写下业务单号、设备、目标会话、成功与否、耗时两个角色可以先跑在同一台机器两个进程里联调够用。三条硬规矩写进代码注释里都值得1. 回调里不做重活查 CRM、调 OpenAI、拼长文案全部给 Worker。回调越快丢消息和重复推送越少。2. 同一条消息只消费一次去重键优先用消息唯一编号没有就用设备 聊天对象 发送人 时间 内容摘要。3. 发送目标和设备对齐回复时用进线设备会话标识用系统回写值不要用微信号当发送目标。私聊、群聊分字段存别混。建议的联调顺序只收不回回调能入队日志能打印出发送人与内容摘要探针发送对已知正确的测试好友发「探针-时间戳」人眼确认收到固定话术自动回例如收到「人工」就回转接提示再接业务库把客户 ID、会话标识映射起来最后才接 AI一步到位上 AI出问题你分不清是模型、队列还是会话映射。日志最少记这些客户说「没收到」时你要能回答当时用哪台设备发的发到哪个会话有没有记到成功结果整段花了多久没有这些只能和客户对线「我们系统显示成功了」说服力很弱。小结Python 开发个人微信 API语法从来不是主难点。主难点是工程节奏收要快、去重要准、发要对人、账要记得清。最小闭环跑稳了再叠 CRM 和 AI才会越做越顺。详见 GeWe API 文档