企业微信自动化解决方案怎么落地

阶段的分界不是规模，是「谁在改」

最常见的划法是按消息量或账号数分阶段，这个划法没用 —— 有日均几十万条消息还跑在一个脚本里的，也有一天两千条就搭了一整套平台的。真正的分界线是：改动的发起方是谁。

• 阶段一，改动方是写它的那个人。要改话术就去找他；他休假，这周就不改了。
• 阶段二，改动方是开发团队。有人接手、有值班、有发布流程，个人休假不影响。
• 阶段三，改动方是业务方自己。运营在后台改规则、加流程，开发只维护能力和边界。

用这个标准量一下，很多自称「已经平台化」的系统其实停在阶段二 —— 业务方每次改规则还是提工单，那不是平台，是一个配置界面做得比较像样的服务。这个判断不是抠字眼：阶段三的成本几乎全在「让别人能自己改还不出事」上，没跨过这条线，这笔成本你就没付，也就不该按阶段三去排期和要人。

还有一个跟着阶段走的指标，比架构图更能说明你在哪一段：灰度单位。阶段一的灰度单位是脚本 —— 改坏了停掉它就完事；阶段二是账号 —— 新逻辑先在一个账号上跑几天；阶段三是业务方 —— 一个组先切新版本，其他组不受影响。你现在实际能做到哪一级灰度，基本就是你所处的阶段。

阶段一：单点脚本能撑到哪，哪三样后面补不回来

单点脚本被严重低估。一个 cron 加几百行脚本能覆盖相当一部分真实需求，而且它最大的优点是改起来快、错了影响面小、丢掉不心疼。这个阶段唯一该抵制的冲动是提前架构。

但有三样东西必须从第一个脚本就做对，因为它们不是代码而是数据形状，后面补的代价是迁移，不是重构。

1. 1自己生成的内部主键。客户、会话、任务在你库里的主键必须由你自己发，外部标识只作为映射列存在。第一天存对是加一列的事，攒了十万行之后再改是一次停机。
2. 2原始事件留存。收到的每个事件先把原始报文落一份，再做业务。它是你唯一的时光机 —— 后面任何一次口径变更、任何一次修完 bug 要补数据，都得靠它。
3. 3账号维度进数据模型。哪怕现在只有一个账号，每张业务表也要带账号标识。这条最容易跳过也最贵：接第二个账号时如果没有这一列，等于把整个数据层重做一遍。

这三样和走哪条接入路线无关，但用 wecomapi 这种账号实例托管的形态时，第三条格外容易被忘 —— 单账号跑起来太顺，顺到你根本意识不到自己正在往代码里写死单账号的假设。

反过来，这个阶段不该做的事也很明确：别上编排引擎、消息中间件这类基础设施。它们解决的是阶段二的问题，在阶段一只会让你多学两个组件、多两个可能挂掉的东西，而这个阶段真正的瓶颈根本不在技术 —— 是你还没想清楚要自动化什么。

阶段二：把「谁在跑」变成「什么在跑」

服务化不是把脚本挪进一个仓库，是把三样散落的东西收敛掉：事件入口、动作执行、状态存储。事件入口收敛，意味着所有事件从一个地方进、落一次、再分发，而不是每个脚本各自订阅一遍；动作执行收敛，意味着限流、重试、发送记录只有一份实现；状态存储收敛，意味着「这个客户当前处在什么状态」有唯一答案，而不是三个脚本各存一份、各不相同。

落地顺序上先收事件入口：用 wecomapi 的事件回调把所有事件收到一个地方，先快速 ACK 再入队异步分发。这一步做完你才有全局视角，后面两件事才有地方挂。反过来先做动作执行层的团队，通常会在接第二个事件源时把它推翻重来。

这个阶段最值得花时间的其实是可观测，不是功能。具体是三样：每个自动化动作都能反查到触发它的那个事件、每个账号的调用量和失败率能单独看、以及一个能一键停掉某条自动化的开关。第三样在演示时毫无价值，在出事那天是唯一有用的东西。

• 把脚本原样搬进服务，只是换了个进程：收敛没做，故障域反而变大了 —— 原来一个脚本崩了只影响它自己，现在是一起崩。
• 配置写在环境变量里：改一句话术要发一次版，业务方会绕过你直接手工操作，然后数据就对不上了。
• 没有账号级的用量视图：多条自动化共用同一批账号，其中一条跑飞就把别的饿死，而你在监控上看到的只是「整体调用量正常」。

还有一个非技术的分界，比代码结构更能说明你到没到阶段二：值班。脚本时代出问题是「找写它的那个人」，服务化之后必须有一条不依赖具体某个人的响应路径 —— 告警发给谁、谁能重启、谁有权限把某条自动化停掉。这套东西不写下来，服务化就只完成了一半：代码是团队的，知识还是个人的。该离开阶段二的信号同样具体：业务方开始直接找你改话术且频率到了每周、第二个业务组要接进来共用同一批账号、或者你开始为「这条自动化到底是谁的」争论。

阶段三：真正的难题是配额与归属

多数人以为平台化的难点是流程编排和可视化配置。那部分是工作量，不是难题，有成熟模式可抄。真正的难题是多个业务方共用同一批账号之后冒出来的两个问题：配额怎么分，责任怎么算。

配额问题长这样：市场组挂了一条批量触达，把某个账号的发送节奏占满，客服组的自动回复开始排队。技术上每次调用都成功，监控上一切正常，体感上客服链路慢了十倍。被抢的不是计费额度 —— 按账号订阅、订阅内可无限次调用接口、不按调用次数计费，适用公平使用策略 —— 被抢的是单个账号在单位时间内能稳妥发出去的那点量。这类问题在阶段二根本不存在，因为那时只有一个使用方。

可用的做法是把账号当成一种要分配的资源：给每个业务方分配账号级的份额和优先级，实时触达类的动作优先，批量类的动作可被延后，超额时先拒绝低优先级的任务，而不是让所有人一起变慢。这里的关键判断是 —— 「一起变慢」永远比「明确拒绝一部分」更糟，因为前者不会有任何人知道发生了什么。

# 示意配置，只表达配额模型，不对应任何真实格式
account: acct-01                # 一个账号 = 一份要分配的吞吐

quotas:
  - owner: 客服组               # 实时触达，优先级高，不可延后
    priority: high
    share: 60%
  - owner: 市场组               # 批量任务，超额时先延后它
    priority: low
    share: 40%
    deferrable: true

# 分配在自己这侧做，实际调用仍走统一执行层：
# https://manager.wecomapi.com/message/sendText

归属问题更简单，也更容易被漏：每条自动化必须有一个明确的负责人和一个可停的开关，而且这个开关要能被负责人自己按下去。没有归属，平台上会慢慢积起一批「不知道谁建的、也没人敢关的」流程，两年后它们能占掉你三分之一的调用量。

还有一件只有阶段三才会遇到的事：变更的爆炸半径变大了。阶段二改一条规则只影响一条自动化；阶段三业务方改一个共享的客户分层定义，可能同时影响五条流程、三个业务组。所以平台化必须配一样东西 —— 改动之前能看到「这个改动会波及哪些流程」。做不到这一点，自助配置就不是效率提升，是把风险平摊给了所有人。

三阶段速览，以及两种典型错法

阶段         改动方      灰度单位  基础设施最小集                升级信号
-----------  ----------  --------  ----------------------------  --------------------------
一 单点脚本  写它的人    脚本      内部主键 / 原始事件 / 账号列  脚本互相依赖、不敢周五改
二 服务化    开发团队    账号      统一入口 / 执行层 / 可观测    业务方每周提改动、第二组接入
三 平台化    业务方      业务方    配额 / 归属 / 自助配置与审计  —

「基础设施最小集」这一列是累加的，不是替换 —— 阶段三仍然依赖阶段一那三样。所以第一列没做对，后面两个阶段都是在流沙上盖楼。

跳级是第一种错法：第一天就照阶段三的样子设计，先做一套流程配置界面、一套权限模型、一套审计日志，然后发现真正在跑的只有两条自动化，还都是开发自己在改。这种系统的问题不是浪费了工期，是它会锁死你的认知 —— 界面一旦定型，业务上真正需要的形状就很难再冒出来了。

滞留是另一种：明明已经十几条自动化、三个业务方在用，还靠一堆脚本加口头约定撑着。滞留的代价是慢慢累积的，而且它有个特征 —— 从来不会有某一天让你觉得「今天必须重构」，它只会让每件事都慢一点，直到某次故障把账一次性算给你。

判断自己在哪一头，一个问题就够：现在要新增一条自动化，是改代码、改配置，还是业务方自己就能建？跳级的修法是砍功能，通常一周；滞留的修法是补基础设施，通常一个季度 —— 所以滞留看着更保守，实际是更贵的那种错。