为什么企业微信成了我们唯一能用的外发通道
做自动化最怕两件事：跑完了人不知道，出错了人收不到。我们先后试过个人微信机器人、邮件推送，结果前者授权反复掉线、后者长期收不到，最后每天真能推到手机的，只剩企业微信这一个通道。与其多头铺设，不如把企业微信机器人做扎实，让它当"唯一可信的外发出口"。
经验：外发通道不在多，在于"推得出、收得到、查得实"。先把一个通道跑通并验证到位，比同时维护三四个半死不活的通道省钱省心。
最隐蔽的坑：用命令行内联 JSON 发消息
一开始图省事，直接这么发：wecom-cli message send --chat-id xxx --text '{"content":"..."}'。本地手动敲好像没毛病，放进自动化就翻车——Windows 的 cmd 会把双引号吃掉，正文里一旦出现 > 这类符号，直接被当成输出重定向截断。结果很迷惑：命令返回 0（成功），但手机上什么都没收到。
坑："命令退出码 0"不等于"消息送达"。内联 JSON + 特殊字符，会让 shell 在到达发送逻辑前就把内容改掉，发送端拿到残缺甚至空的 body，自然什么都不推。
修法：一律把正文先写进一个
.txt 文件，再调用 wecom_push.py file <path> 读文件发送。正文里无论有什么符号、多长，都原样进发送逻辑，再也不会被 shell 截断。这是踩过的最值钱的一课。授权类故障：850003 / 850001 不是重连能解的
某段时间推送突然回 850003 authorization expired。第一反应是"重连、重启"，折腾半天没用。后来确认：这是云端「消息」类权限过期，必须在企业微信授权页手动续权，本地重连、重启进程都救不回来。续权后历史堆积的消息会按服务端机制自动补投，不用手动补发。
经验：看到 85xxxx 这类授权码，先判断是"本地会话断了"还是"云端权限过期"。后者只能走授权页续权，别在本地瞎重试浪费额度。
推送失败不能阻断主流程
调度任务一天要跑十几个子步骤，任何一步失败都不该把"发通知"也拖死。设计是：所有子步骤各自 try/except 隔离，失败就记进汇总，最后统一由一条汇总消息兜底。这样即使中间某步挂了，第二天打开手机仍能看到"哪几步失败、原因是什么"，而不是一片空白。
- 每天只推一条汇总，不分步刷屏；
- 发送后必须回读验证，拿到
DELIVERED: True才算真送达； - 若首次回读是
False或QUEUED，重跑一次；仍失败就如实写"推送失败"，绝不假装成功。
铁律："已推送"必须有
DELIVERED: True 回读命中。没有回读确认，就不许在汇报里写"已通知"。把通知内容压到扫一眼就懂
汇总消息首行固定以标识开头，正文控制在 200 字内，写清：完成几项、失败几项及原因、留资 pending 是否为 0、站点在线页数、招标命中数、签到结果。额度耗尽之类异常也要明说，不藏着。
经验：手机通知是"扫读"场景，不是"精读"场景。结论前置、异常标红、数字说话，比写一大段散文有用得多。
留资引导
想让福运帮你把日报、告警、任务进度自动推到手机？留下联系方式，我们给你一套可复制的 wecom-cli 推送骨架：https://szgcy.online/contact.html