「企业微信自动发消息」被搜得很多真正要的不是脚本连点发送而是业务条件满足时系统按规则发出去还能停、还能对账、还不会连发两条。这篇按自动发送落地来写。自动发消息不是一个开关完整链路是这样的条件成立订单/课次/审核通过 → 生成发送任务 → 命中账号 外部群 → 检查窗口、间隔、勿扰 → 发出 → 回执 → 关闭任务或按原因重试只做最后「发出」这一步系统会在错误的时间、对错误的群、用错误的号说话。企业微信自动发消息的质量取决于前面的闸门不取决于文案库有多厚。先配「不发」再配「发什么」上线清单倒着写账号离线会话或群已标记勿扰、客诉中不在工作时段该群今天主动额度已用完同一 requestId 已经成功过目标已不是外部群或账号已退群这些做成硬开关。运营再怎么加活动也打不穿。自动发消息最常见的事故是闸门太少不是话术不够好。发送时机比文案更影响体验同样一句「明天上午 10 点上课」发早了像刷屏发晚了像失职。建议按事件配时机不要全局 0 秒秒发。场景建议时机原因状态变更通知变更后进入最近一个工作窗口避开深夜到课 / 到店提醒前一天白天或当天早上太早没人记太晚来不及活动预告人工审核后的固定窗口必须有人看过名单失败重试下一窗口绝不凌晨补发补发比漏发更伤自动发消息要像坐席的工作习惯不像服务器的 cron。对象和内容拆开存对象业务群 ID → 外部群 ID → 账号实例。内容一条短文案最多一个动作可选一张图。任务requestId、状态、下次可发时间。不要把「发给所有门店群的那张海报」写成一段不可拆的脚本。对象变了应该换映射不该复制一套发送代码。防重复是自动发送的底线三条规则写死同一 requestId 只许成功一次同一群 同一主题冷却期内不发通道超时只查询结果不换单号重发外部群里出现两条一模一样的自动消息成员会直接判断你们是机器后续通知再准也没人看。通道怎么接员工应用消息走官方。外部群自动发会话消息走账号在线的二次开发通道。业务系统不要直接操作企业微信窗口。现成方案里QiWe API把外部群主动发送做成 HTTP自动发消息引擎只负责任务、窗口和去重。先用测试号对一个测试群把「条件触发 → 发出 → 回执」跑通再接真实客户群。登录、发送、回执字段以QiWe API文档为准。文档地址平台介绍 - QiWe API企微 API 开发文档上线节奏第一周测试群 一类节点通知 不发清单。第二周加上窗口、间隔、requestId 幂等。第三周小范围活动必须审核。第四周多号多群。全量最后做。小结企业微信自动发消息要先做闸门、窗口和去重再做文案和规模。能自动也要能停能发也要对账。需要外部群通道时用QiWe API接 RPA 封装接口把自动发送做成任务系统而不是定时点击。发得少、发得准、重复发不出去这套自动才算能用。