企业微信自动运营怎么搭

先算清楚那个减法，再列清单

自动化的收益不是「省了多少次点击」，而是「单次省下的时间乘以频次」再减去「出错时的收拾成本」。这个减法里第二项经常被当成零，于是团队把最该留给人的判断动作自动掉了，反而把真正机械的搬运工作留在人手上。

一个动作值不值得交出去，看四件事：频次够不够高、每次的判断能不能写成规则、做错了能不能撤回、以及错了多久会被发现。前两项决定能不能做，后两项决定该做到哪一档 —— 全自动、半自动（程序准备、人确认），还是只做提醒。

• 高频 + 规则明确 + 可撤回 → 全自动。给新客户打来源标签、把会话状态同步进自有系统都属于这一类。
• 高频 + 规则明确 + 不可撤回 → 全自动，但必须配速率闸门和一键停止。对外发消息是典型。
• 低频 + 判断复杂 → 别自动。把上下文准备好推给人，让人点一下就行。
• 错了几天才会被发现的 → 无论频次多高，先把对账做出来再谈自动。

凭印象估频次是这一步最常犯的错。运营说「这事儿天天都在做」，真去数一周的操作记录，可能一共十七次，其中十二次挤在周一上午。这种分布下值得做的不是全自动，是把周一那批变成一个可提交的批量作业。动手之前先数一遍，成本是半小时，省掉的是一个季度的错投入。

还有一条边界先划清楚：这篇回答的是「运营台账上哪些活该交给程序、按什么顺序交」，不是「自动化接口按驱动方式怎么分类」。后者站内另有一篇，两件事的先后是先判断值不值得交，再决定用哪种方式接。

切入点一：触发式回应，买的是响应时延

第一类是「有人做了什么，系统立刻做出反应」：客户发来消息、通过好友申请、进群、退群。这一类的价值不在省人力，在把响应时延从分钟级压到秒级 —— 人不可能 7×24 盯着，程序可以。

工程形态很固定：用 wecomapi 的事件回调订阅消息与成员变化，收到后先快速返回 2xx 再异步处理，命中规则再走出向接口回写。进和出都是现成通路，整条链路上真正要你维护的只有中间那段决策逻辑 —— 这也是它应该第一个做的原因。

坑不在链路，在规则的边界。最常见的三个：机器人回复了另一个机器人，两边互相触发停不下来；同一个客户被三个业务模块各回了一条；测试账号的消息进了生产规则。前两个靠发送前的合并与去重挡住，第三个靠事件源上的账号白名单挡住。

还有一个容易漏掉的设计点：触发式回应必须能容忍事件迟到。事件晚了三分钟才到，那条「刚进群的欢迎语」还该不该发？多数场景的答案是不该。给每类回应设一个时效窗口，超窗就丢弃并记一条日志，比发出一条莫名其妙的消息强得多。

// 示意逻辑，精确字段与端点以线上文档为准
async function react(evt, rule) {
  if (age(evt) > WINDOW[rule.id]) return drop(evt, "expired");   // 迟到就丢，不补发
  if (!(await cooldown.pass(evt.subject, rule.id))) return drop(evt, "cooldown");

  await post("https://manager.wecomapi.com/message/sendText", {
    guid:    evt.accountId,
    toId:    evt.subject,
    content: render(rule, evt),
  });
  await audit(evt.id, rule.id);   // 留痕：哪条规则、被哪个事件触发
}

• 「同一对象每 N 分钟最多一次」的闸门是最便宜的保险，别等出事再加。
• 自动发出的内容带来源标记 —— 哪条规则、哪个事件触发的，出事时能一秒定位。
• 保留人工接管入口。规则拿不准的时候，不回比回错便宜。

切入点二：定时对账，最被低估的那一档

事件能告诉你「刚刚发生了什么」，但拿不到「过去某个时刻漏掉了什么」。回调会丢、消费会失败、有人直接在客户端上做的改动不一定都有对应事件 —— 只靠事件，你的库和真实状态一定会漂。

所以第二个切入点是定时对账：按固定周期用 wecomapi 的客户、群与成员接口把关键实体拉一遍，和自己库里的状态逐项比对，差异先如实记下来：只有「以哪边为准」事先写死、影响面又可控的那几类才自动修复，其余进人工队列。它不产生任何新功能，却是前面所有自动化能长期跑下去的地基。

1. 1定对象与口径：先对「存在性」（这个客户、这个群还在不在），再对「关键属性」（归属人、标签），最后才轮到明细。上来就全量对齐一切，既慢又没必要。
2. 2定周期：变化快、影响大的每小时一次，变化慢的每天一次。别把所有任务都写成整点执行，错开到不同分钟数上。
3. 3定处置：差异分成「以平台为准直接覆盖」「以自有系统为准回写」「拿不准进人工队列」三类，写死在规则里，不要每次靠人判断；并给单次自动修复设条数上限，差异量突然放大时先停下等人 —— 那种时候更可能是你这边的期望值算错了。
4. 4定观测：对账本身要出数 —— 这次比对了多少条、差异多少条、修了多少条。差异率突然抬头，通常意味着上游的事件链路出了问题。

对账也不等于全量拉取。客户几千的时候全量扫一遍还行，上万之后既慢，也会给账号侧压上不必要的负担。可行的做法是分层：最关键的实体每天在低峰全量一次，其余按分批轮转，每次只扫一部分，一周覆盖完整。对账要保证的是「漂移不会长期存在」，不是「任何时刻都严格一致」，这两个目标的成本差一个数量级。

切入点三：批量作业，把一次性人工操作程序化

第三类是把运营同学「照着表格一条条操作」的活变成可提交的作业：批量打标签、批量建群、按名单分批触达。判断标准很直白 —— 只要一件事需要人对着列表重复几十次以上，它就该是一个作业，而不是一个下午。

关键是别把它写成一次性脚本。作业要能查进度、能中途停、能只重跑失败的那部分，这三件事决定了它是资产还是负债。执行层则要薄到只认「一条待办」：规则判断在上游做完，执行只负责发出去并逐条落状态。

脚本和作业真正的分界不在代码质量，在谁能发起。脚本的发起人永远是研发，作业的发起人应该是运营自己。只要每次执行都得找研发跑一下，这件事就没有被自动化，只是换了个人做 —— 而且研发这一环还会成为它的排期瓶颈。

• 每条记录独立状态，重跑按状态过滤。整批重来是重复发送的头号来源。
• 「已提交」和「已确认」分开记：接口返回成功只代表请求被接受了。
• 进度要让业务方自己看得懂，否则运营会一边等作业一边手工再做一遍。

分片、限速与断点续跑的具体做法站内另有一篇专讲，这里只强调一句：批量任务的成败不取决于重试写得多好，取决于它有没有被摊平到足够长的时间窗里。

切入点四：人工辅助，不替人做决定

第四类最容易被跳过，收益却常常最高：不自动执行，只把判断需要的东西准备好推到人面前。客户发来一条含义不明的消息，系统把历史订单、上次沟通记录、几条可选话术一起推给坐席，人点一下就发出去。

它值钱的地方在于避开了自动化最贵的那部分成本 —— 你不需要把规则写到能覆盖所有边界，只需要把上下文收集全。对判断复杂、出错代价高的场景，这一档往往是唯一能真正上线的方案。而且它天然产出训练数据：人选了哪一条、改了哪几个字，都是后面做全自动的依据。

落地上它和全自动共用同一条通路，差别只有一个确认动作。用 wecomapi 的会话与客户接口把上下文取齐，推给内部工作台，人确认之后走同一个发送出口 —— 出口只有一个，限速、留痕、幂等都不用做两遍。

这一档的成败在界面，不在接口：上下文推过去之后，坐席要能在一屏之内做完决策，否则它会退化成一个没人看的通知栏。确认队列的交互怎么打磨、采纳率与改动率怎么看，站内讲智能运营的那篇有专门一节，这里不重复。

排期顺序与三个止损开关

四个切入点不是四个阶段，同一条业务链路上经常同时用到三种：入群事件触发欢迎语属于触发式，每天核对群成员和自有库属于对账，运营发起一次分层触达属于批量作业。需要排期的是「先把哪条链路做完整」，而不是「先做完哪一类」。

顺序建议：先做触发式回应里最窄的一条，比如新客户自动打来源标签，拿到第一条闭环；接着补对账，让这条闭环不会悄悄坏掉；然后把最痛的那个批量操作作业化；人工辅助放最后，因为它依赖前面沉淀下来的上下文数据。反过来做的团队，通常在第二个月就开始清理脏数据。每一条新规则都先只对少量账号或对象生效，观察一到两天再放开 —— 自动化的错误是成规模发生的。

1. 1开关：全局一个、每条规则一个，能在不发版的情况下关掉任意一条自动链路。这是企微自动运营里唯一不能省的功能。
2. 2留痕：每个自动动作记「谁触发的、依据是什么」。这是事后唯一能解释清楚的东西，也是被业务方质疑时的凭据。
3. 3归属：每条自动链路写清楚负责人。没有归属的规则只会一直堆积，因为谁都不敢删别人写的那条。