企业微信协议自动化的边界

边界该画在责任上，不是画在能力上

多数团队画自动化边界用的是技术边界：接口支持就做，不支持就不做。这条线的位置是错的。接口支持的动作里有相当一部分，做成全自动之后第一次误触发就是客户投诉、销售返工，或者一场需要有人出面解释的事故 —— 而它在技术上一点问题都没有。

管用的是责任边界：这个动作出错时，损失能不能在系统内部消化掉。能，就尽量自动；不能，要么加人，要么不做。按这条线，所有动作会落进三档。

• 全自动：错了在系统内部改得回来，对外不可见。标签写错、字段同步漏了、内部通知发重了都算。
• 人确认后执行：动作对外可见但可控，批量执行前要有人看一眼这个批次 —— 看批次，不是看每一条。
• 不做自动化：不可逆、对外可见、且以某个具体的人的名义发生。这一档只保留人工发起入口，程序做准备工作。

分档的粒度是动作，不是功能模块。「客户运营」不是一档，「给已成交客户打一个内部标签」和「给未回复客户再发一条跟进」分属两档。按模块分档的团队，最后都会退化成整个模块一起放开、或者一起锁死。

三个判据，按顺序过

判据一：这个动作可不可逆

改一条标签、补一次数据同步、更新一个内部状态，错了改回来就行，代价是一次修复。发出去的消息、已经拉了人的群、已经通过的好友请求没有撤销键，事后只能靠解释。可逆的默认进第一档，不可逆的至少从第二档起评。

判据二：错了谁看得见

同一个 bug，只有你的监控看得见，和客户在会话里看得见，代价差一个量级。这条判据还有个反直觉的推论：把动作做得更快更多，同时也在放大它的可见性 —— 一分钟发错一条和一分钟发错一千条，是两种事故等级。

判据三：以谁的名义发生

动作是以系统的名义做的，还是以某个员工的名义做的？以个人身份发出的内容，客户事后找的是那个人，不是你的服务。这类动作不该在当事人不知情的情况下由程序发起 —— 这不是技术判断，是这套系统能不能在公司内部长期活下去的判断。

三条按顺序过：全中的直接进第三档，不用再算投入产出比；只中一条的进第二档补一个确认点就够；中两条的先按第二档跑满一个季度，再谈要不要上移。

三类动作不该做成全自动

判据落到具体动作上，有三类反复出现，共同点是三条判据里至少中两条，而它们在实现难度上恰恰是最低的那一批 —— 所以几乎总是第一批被做成全自动的。

• 带承诺的内容，以及对陌生对象的首次发起：前者是价格、折扣、赔付、交付时间，后者是加好友、拉群、第一条触达。这两类站内讲营销机器人能力边界那篇按可撤回成本拆得更细，结论一致，这里不再展开。
• 批量且不可撤回：群发、批量移出成员、批量改群资料。错一次就是全量错，而且发现的时候通常已经跑完了。
• 以员工个人身份的表态：客户群里的口径澄清、敏感问题的回复、代替本人发出的内容。这些动作在组织里是有主体的，程序不该冒名。

这三类拦的是「全自动」，不是「不能用接口做」。准备数据、生成草稿、排好批次、算好时段，全都该由程序做完，留给人的只有最后那一下确认。人留在这个位置，效率损失通常不到 5%，风险降一个数量级。

还有一条实操判断：如果一个动作的正确性依赖「对方现在是什么状态」，而这个状态你只能猜，它就不该全自动。程序判断得了数据，判断不了对方此刻愿不愿意被打扰。

人留在哪一层才不会退化

加人不等于加审批。逐条审批是最常见的失败形态：第一周认真看，第二周开始闭眼点通过，第三周这个环节实际上已经不存在了，只是没人承认。审批的有效性和它的数量成反比。

1. 1批次级，不是条目级。人看的是「这批 300 条，抽 5 条长这样，时段和频率是这个」，而不是点 300 次确认。
2. 2抽样加事后核查，替代全量前置审批。前置只拦批次，事后按比例回看，异常再回滚。
3. 3例外驱动：规则能判的直接执行，判不了的才交给人。人处理的是尾部，不是主干。
4. 4降级而不是停机：外部依赖异常时把动作降级成待人工处理，而不是让整条链路挂在那里反复重试。

例外驱动最省事的落法是让两条路径共用同一个执行出口：规则判不了的分支不直接发，而是写进一张待办表，人在后台确认后再触发一次调用，走 wecomapi 的同一套发送接口，只是发起者从定时器换成了人。这样人工路径和自动路径的日志、配额与幂等都是同一套，不会出现两条通道行为不一致。

一个可以量化的自检：某个审批环节的通过率长期高于 95%，说明它已经不在做判断了，应该换成抽样加事后核查。留着它只会让人对「审批」这两个字脱敏，真需要拦的时候拦不住。

上线前的四道闸门，以及推进顺序

自动化链路的触发端通常是事件：用 wecomapi 的事件回调拿到消息与成员变更，规则命中后再决定要不要执行动作。四道闸门就装在「命中」和「执行」之间这一步，而不是散落在业务代码深处 —— 位置错了，它们都会在某个分支上被绕开。

• 配额：按账号、按时段的执行上限。超限的动作排队等下一个窗口，不是丢弃，也不是硬发。
• 灰度：新规则先对一小部分对象生效，跑满一个完整业务周期再放量。规则的错误往往要到周末或月初才暴露。
• 静默窗口：这道闸门挂在接收对象上，不挂在触发源上。
• 一键停摆：三十秒内让所有自动动作停下来，且不需要发版。

// 示意逻辑，只表达控制流位置；精确字段与端点以线上接口文档为准
async function execute(action) {
  if (killSwitch.on())               return skip("stopped");
  if (!gray.covers(action.target))   return skip("not-in-gray");
  if (silent.hit(action.target))     return defer(action);  // 挂在接收方
  if (!quota.take(action.accountId)) return defer(action);  // 排队，不丢弃

  return http.post("https://manager.wecomapi.com/message/sendText", {
    guid:    action.accountId,
    toId:    action.target,
    content: action.text,
  });
}

四道里最常被跳过的是最后一道，理由通常是「改个配置就能停」。真出事那天你会发现改配置要走发布、发布要过流水线、流水线上还堆着别人的变更，而错误消息正在以每秒若干条的速度发出去。停摆开关唯一的设计要求是：不经过部署。

1. 1先上只读与内部状态类自动化，跑满两周，攒出一份正常时段、正常速率的基线。没有基线，后面所有告警阈值都是拍脑袋。
2. 2再上可逆的对外动作，带抽样复核。这一步的目标不是省人力，是验证规则的准确率。
3. 3最后上批量动作，先灰度后放量，每次放量的倍数不超过 3。第三档的动作永远保留人工发起入口。