#WorkBuddy# 广告公司老板接入企业微信机器人：不做服务器，从零到第一条自动通知

#WorkBuddy# 广告公司老板接入企业微信机器人：不做服务器，从零到第一条自动通知

我在苏州开一家广告制作公司，前店后厂，二十来年。店里最费神的不是设计，是节点跟踪：一张名片单子从接单到出货要经过排版、打样、客户确认、印刷、后道、送货，任何一环卡住，客户第二天就打电话来问。

我一直想在这样的节点上收到一条消息，而不是靠人记、靠嘴问。但我不会编程，也没打算为此买服务器、搞一套 OA。

这篇写我怎么用 WorkBuddy 把这件事先跑通第一步：让一个机器人用企业微信的身份，给我自己发第一条通知。整个过程没有写一行后端代码，没有备案域名，没有买服务器。

一、先想清楚：为什么要"机器人身份"

企业微信有三种常见接法：

我选第三种，理由很实在：我的需求是"给指定的人/群发一条文本"，不需要接收回调、不需要做菜单、不需要网页授权。用 CLI 直连企业微信 API，最重的活（鉴权、加解密）都被工具吃掉了，我只需要拼一句命令。

WorkBuddy 客户端全景（侧栏内容已打码）

二、接入：其实只有两步

第 1 步：确认工具在、状态是授权的

先看状态，这是所有后续动作的前提：

$ wecom-cli auth show --status
authorized

`authorized` 就代表这张"通行证"是有效的，可以直接发消息。如果这里不是 `authorized`，就要走一次初始化授权（弹二维码、手机确认），这一步必须本人操作，没有别的办法绕过。

**这一步我建议养成习惯**：每次动手前先 `auth show --status`，不要凭记忆认为"上次授权过"。我踩过一次坑——业务流程跑了半天没消息，最后发现是授权过期，而工具本身不报错，只是不发。

### 第 2 步：发第一条消息

消息发送的参数很少，但每个都必须填对：

```bash

--chat-id 会话 ID：单聊传接收人的 userid，群聊传群会话 ID

--msg-type 目前支持 text

--text 文本内容（JSON）

一条真实可用的命令长这样：

wecom-cli message send \
  --chat-id "ZhangSan" \
  --msg-type text \
  --text '{"content":"【时代广告】名片单 A1024 已完成打样，等待客户确认，已挂起 6 小时。"}'

两个细节值得单独说：

1. --chat-id 传的是 userid 或群会话 ID，不是昵称。传昵称不会报错得很明显，只会找不到会话。这是最容易出错的一处。
2. 先 --dry-run。这个参数只在本地校验请求体，不真的发送。第一次接的时候我靠它省了好几条发错的测试消息：

wecom-cli message send --chat-id "ZhangSan" --msg-type text \
  --text '{"content":"test"}' --dry-run

第一条消息发出去、手机上"叮"一声响，这事就算通了。之后所有通知都从这条通道走，剩下的只是决定"什么事件、发给谁、说什么"。

三、它第一件真正干的活，是给自己发告警

接入之后我没急着做业务通知，先解决了一个更急的问题。

我有一套每日自动任务（签到、数据采集之类），靠浏览器会话跑。10 月 28 日那天它失败了，原因是网页登录态过期：打开目标页面被 302 重定向到登录页，显示"微信扫码登录"，脚本找不到任何可操作元素，按规则安全退出。

问题在于：它失败了，但我不知道。自动化最危险的状态不是报错，是静默失败——你以为它在跑，其实它已经停了三天。

所以我做的第一件事是让失败路径调机器人：

任务失败 → 判断失败原因 → 发一条企微消息给我 → 我扫码 → 重跑

那天我收到的消息大意是"网页掉登录，需人工扫码"。我扫码、重跑、当天补回。这是这条管道产生的第一个真实价值，也是我认为每个自动化项目都应该先做告警、再做业务的原因。

顺序反过来（先做业务、后补告警）的项目，基本都会在半年的某个时点烂掉，因为没人知道它什么时候开始不工作了。

每日积分自动化的会话：执行过程和消耗都有记录

四、两个必须知道的坑

坑 1：权限错误 850002 / 850003 不是"连接断了"

发消息时如果返回 850002 或 850003，附带一段说明和一个授权链接，含义是：机器人这个身份的某项能力没授权或已过期。

这时候最错误的动作是"重新连接"或"重新扫码"——连接本身是好的，重连解决不了能力授权。正确做法是：

1. 停下来，别再试；
2. 打开返回的那条授权链接，把对应能力授权上；
3. 确认授权完成，再重试原来的操作。

这条经验救了我一下午：第一次看到这个错误，直觉就是"掉线了，重连一下"，重连三次全失败，越试越乱。

坑 2：把新个人微信绑到企业微信，有冷却期

我原本的计划是把新注册的个人微信绑到企业微信，这样"人 + 机器人"在同一个客户端里，看消息更顺。实际操作发现绑定有系统冷却期，短期内完不成，只能等。

这一点不影响主链路（机器人发消息不需要个人微信绑定），但会影响你的时间预期。别把关键节点压在需要人工审核/冷却的功能上，先把不依赖它的部分跑通。

五、边界：机器人不该干什么

用了几周，我给自己定了三条规矩：

1. 只发通知，不做决定。机器人可以告诉我"这张单卡了 6 小时"，但不能自动替客户确认、不能自动改单。判断必须留给人。
2. 不群发、不营销。给客户群发消息是另一件事，涉及合规和关系，不放进自动化里。
3. 消息里不放敏感数据。金额、客户手机号、账期这类信息不进通知正文，只说"哪张单、什么状态、挂了多久"，细节回系统里看。

六、下一步：把门店系统的事件接进来

管道通了之后，真正的活才开始。我的目标是：

门店经营系统（本地数据库）→ 判断节点 → 组一条文本 → 企微机器人推送

比如：某张生产单在"待客户确认"超过 4 小时 → 推给我；某天 18:00 营业额低于阈值 → 推给店长。

这条路的技术难点不在发消息（已经通了），在读懂门店系统的数据结构——那是另一篇文章的事。但方向很明确：先把"能通知"这件事做成基础设施，后面每加一个业务规则，成本都很低。

收尾：给同样不懂编程的经营者

如果你也在传统行业，想给自己搞点自动化，我的建议只有三条：

1. 先做告警，再做业务。让系统会喊疼，比让它多干活重要得多。
2. 选不需要服务器的方案。服务器意味着备案、续费、安全、运维，每一样都能让项目死在半路。
3. 先跑通一条最短链路。一条消息发到自己手机上，比画一张漂亮的架构图有用一百倍。