1. 引言
自动化办公不是把所有窗口都脚本化。订单出库要推到客户群、审批通过要通知负责人、考勤异常要提醒主管,这些是事件驱动的投递。点窗口能演示,接不住高峰,也做不到幂等。
2. 先定事件,再定出口
一次自动化要能解释:哪个员工号、发给谁、发什么、同一业务只成功一次。群名、审批单标题、客户备注都不能当地址。地址用会话 ID。
QiWe API 按事件投递,不读屏幕。
| 层 | 适合 | 不适合 |
|---|---|---|
| 人值守 | 登录、二次验证 | 每笔订单点一次发送 |
| 官方应用 | 内部审批、通讯录 | 外部群实时推经常不够 |
| HTTP 出站 | 通知、回复、按群投递 | 替代登录本身 |
发送和回调怎么接,以 API文档 为准。
3. 最小架构
业务系统产出事件 → 写入任务表(带环境、业务键)→ 发送进程出站 → 聊天窗口验收。
python
def on_order_done(device, to, text, db):
key = f"order:{device}:{to}:done"
if db.try_insert(key):
db.enqueue(device, to, text)
保存工单的页面里不要又点又发。连点就是重复通知。出站交给 QiWe API。
4. 办公场景怎么拆
- 通知:已审文案,走通知队列,转人工后仍可发物流
- 回复:词表命中才开口,未命中记账
- 群:一个外部群一个接收方,员工不在群就停任务
- 定时:计划时刻带时区,错过窗口不要原文补发
频率、会话类型和附件不要猜,文字过了再排期。
5. 验收
事件写入任务后,目标会话出现原文;号掉线时任务停在存活而不是狂点;同一订单同一状态只有一条。脚本跑完一遍不能当验收。
6. 总结
企业微信API做自动化办公,核心是事件、幂等、会话 ID。点击脚本只能放在登录旁边当权宜。