一、先把现实摆清楚：能用的外发通道只剩一条
我们试过的"自动推送到手机"通道，大部分长期不可用：微信公众号会话层 disconnected、微信 bot 同样断开、个人邮箱/QQ 邮箱要么没接要么送达率感人。最后跑通、且至今稳定的，只有企业微信——通过 wecom-cli 把文字/文件直接推到本人对话。
结论先行： 小团队做"任务跑完自动通知我"，别贪多通道。先把唯一能用的企业微信钉死，比铺一堆半死不活的通道靠谱得多。
二、一条命令搞定推送
推送本质就是一行 CLI。我们用的是新接口写法（老 msg send_message 已废）：
文本推送
wecom-cli message send --chat-id <你的userid> --msg-type text --text '{"content":"【福运通知】夜间运营中枢 - 守护成功/技术分享已上线"}'
文件/图片推送
日报、监控简报、视频封面这类，先走 wecom-cli media 拿到 media_id，再用 message send --msg-type file 发出。注意 chat-id 是本人 userid，不是群号——群推送要换群 chat-id。
三、授权类故障：850003 / 850001 怎么快速救
企业微信最大的坑是"突然推不动"，报错集中在两类：
850003 · authorization expired： 通讯录/消息类权限过期。最快修法是回授权页续"消息"权限；若仍不行，直接索取 msg 的 StreamableHTTP URL，用改写脚本更新本地加密配置（
_wecom_cfg_update.js msg <url>），返回 errcode=0 即恢复。850001 · invalid api key： API Key 失效或写错。检查本地凭证文件是否到位、是否被人改过；重填 Key 后重试。
排查顺序： 先看 errcode 是 850003 还是 850001 → 对应续权或换 Key → 用 msg 接口先发一条测试，errcode=0 再并入自动化。
四、关键设计：推送失败绝不能阻断主流程
这是最容易翻车的地方。通知只是"顺手告诉你"，不是业务本身。我们的铁律：
- 每条自动化收尾都推企业微信，成功/失败都发，让用户知道今天发生了什么；
- 推送动作包在独立 try 里，推送失败只记警告，不抛异常、不阻塞主任务；
- 摘要 ≤200 字，写明哪几个子任务成功/跳过/失败，失败给原因。
为什么这样设计： 曾经有次推送组件卡死，把整条自动化拖到超时。从那以后，通知永远是最外层、最可有可无的一环——主产出先保住。
五、踩过的坑（都是真事）
坑 1 · userid 写错： 早期把"华先生"的显示名当 chat-id，推了半天查无此人。必须用通讯录查出来的真实 userid，不是昵称。
坑 2 · 老接口突然失效：
msg send_message 某天直接废了，没预警。统一切到 message send 新写法后稳定。坑 3 · 把私密数据塞进公开通知： 通知是明文推到对话的，客户名单、密钥、身份证号这类绝对不能进推送文本，只发"已生成/已上线"这类状态。
六、给后来者的可抄清单
- 通道只信企业微信，别的先当备用；
- 命令用新接口
message send，老接口早晚废； - 授权过期先看 errcode，850003 续权、850001 换 Key；
- 推送包 try，失败不阻断；
- 通知文本只放状态，不放敏感数据。
一句话： 企业微信是目前唯一"免费+稳定+能推到手机"的通道，把它做成自动化收尾的标准动作，你就不用再盯屏等结果了。