做Python后端或搞运维的朋友，我猜你迟早会遇到一个需求：用Python做一个微信机器人，把程序里的告警、通知、日报，自动发到微信群里。早几年大家都喜欢用itchat之类的方式去模拟登录个人微信，但说实话，今天这条路风险很大，封号概率太高。我自己踩过坑，后来彻底转向企业微信机器人的Webhook方案，又稳又简单。这篇文章就把我整个“Python微信机器人”从原理到落地的完整过程讲清楚，包含可以直接复制走的代码、参数说明、定时配置和报错排查，适合刚入门Python、需要做群消息推送或自动化通知的开发者参考。
1. 项目概述与技术路线选择
1.1 微信机器人的三种主流实现路线
先别急着写代码，回头把市面上实现“微信机器人”的路线理了一遍，大致分三类，各有各的适用场景。
路线一：企业微信群机器人Webhook。这是企业微信官方提供的能力，你在任意一个企业微信群中添加一个“群机器人”，会得到一个Webhook地址。当你通过HTTP POST请求往这个地址推送一条JSON消息时，群里的机器人就会把消息发出去。整个过程不涉及登录、不涉及协议模拟、不需要维护会话，是最干净、最合规的玩法。
路线二：企业微信应用消息。在企业微信管理后台自建一个“应用”，通过应用可以主动给成员发消息，也可以接收成员在对话中发给应用的消息。这一类能实现双向交互，适合做客服机器人、自动回复等场景。相比群机器人，需要拿到企业ID、应用Secret、部门ID等一堆参数，还要处理回调验证和消息解密，复杂度明显更高。
路线三：个人微信第三方协议库。比如itchat、以及各种基于逆向HOOK的方案。这类方案在技术社区里讨论最热闹，因为能实现“个人微信号全自动处理”：加好友、自动回复、群发、朋友圈监控等。但核心问题是它们大都游走在微信官方规则之外，账号被限制、被冻结是常态，动辄需要养号或者更换号码。把生产业务放在这种不稳定地基上，风险太大。
为了方便对比，我列个表：
| 路线 | 实现难度 | 合规性 | 稳定性 | 适用场景 |
|---|---|---|---|---|
| 企业微信群机器人Webhook | 极低 | 官方支持 | 高 | 告警通知、定时推送、业务播报 |
| 企业微信应用消息 | 中 | 官方支持 | 高 | 双向交互、客服机器人、内部系统对接 |
| 个人微信协议库 | 高 | 高风险 | 低 | 不建议用于生产环境 |
1.2 我为什么选择Webhook方案
如果你只是想把“系统里的某条消息”推送到微信，比如服务器告警、订单通知、定时天气、爬虫结果，那么企业微信群机器人Webhook是最合适的。
我的理由很直接：第一，它几乎没有学习成本，你唯一要掌握的是怎么用Python发一个HTTP POST请求；第二，它不需要长期维护一个微信登录态，也不会有会话过期、验证码拦截一类破事；第三，它被官方支持，接口规则清晰，出了问题查文档就好，不用跟逆向工程周旋。
有人会觉得它只能往群里发、不能读群里的消息。确实是这样，但你把需求梳理一下会发现，很多真实需求压根不需要“读”。比如运维告警，是系统主动推送；比如每日日报，是定时任务推送；比如电商订单播报，是业务方推送。这些场景里，核心动作只有一个：把消息发出去。所以Webhook方案完全够用，先跑起来比什么都重要。
1.3 你需要准备的环境与工具
在动手之前，把环境理清楚。
- Python 3.6及以上版本。企业微信Webhook的接口很简单，用标准库、requests、httpx都可以。我自己用的是Python 3.10 + requests 2.31。
- 安装requests库：
pip install requests。Windows用户如果安装时报错，大概率是没把Python加入PATH，重装时记得勾选“Add Python to PATH”；macOS用户建议用Homebrew安装Python，避免系统自带版本的各种权限问题。 - 一台能访问公网的电脑或服务器。因为Webhook地址是公网域名，需要能发起HTTPS请求。内网机器如果出网受限，会发不出去。
- 一个企业微信。个人也可以注册企业微信，不是必须有公司实体。用手机号就能创建企业，不需要营业执照（部分高级功能需要认证）。
- 一个测试微信群。可以单独建一个只有机器人和你自己的群，方便调试，避免误发到全员群。
很多新手会卡在第一步：没有企业微信怎么办？其实企业微信支持个人注册，整个流程跟在应用商店下载App、用手机号登录差不多。注册完之后，你既能在手机端操作，也能在电脑端管理，机器人配置入口完全一样。下面咱们进入正题。
2. Webhook机器人的核心原理
2.1 Webhook是什么，为什么这么简单
Webhook这个词翻译过来就是“网络钩子”，理解成“有事件发生时，外部系统主动调你的接口”即可。企业微信群机器人的做法反过来了：你的程序主动调用企业微信提供的这个接口。本质上就是给一个固定URL发POST请求，企业微信收到请求后解析JSON内容，把它渲染成群里的消息。
你可以把它类比成家庭门铃：你按门铃（发HTTP请求），门铃发出声音（群里显示消息）。门铃不会管你是谁、为什么按，只要按的动作符合规格就能响。所以开发重心只在“组装JSON消息”和“决定什么时候按”这两件事上。
一个典型的请求是这样的：POST一个JSON对象到Webhook地址，JSON里的msgtype字段声明消息类型，比如text表示文本，markdown表示Markdown文本，image表示图片。企业微信那边收到之后，会把对应的字段渲染出来。整个过程不涉及鉴权、不涉及Token、不涉及签名，所以无比简单。
如果你想先手工验证一下，直接用curl就能测通：
curl 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的key' \ -H 'Content-Type: application/json' \ -d '{"msgtype":"text","text":{"content":"hello from curl"}}'如果群里有消息弹出，说明地址没问题。这一步验证的价值在于：把网络、地址、消息格式这几种问题隔离起来。一旦curl能通，后面再用Python写代码时就可以把排查范围缩到代码层面。
2.2 获取Webhook地址与管理配置
咱们现在去企业微信里创建一个群机器人，拿到Webhook地址：
- 打开企业微信，进入一个群聊，点击右上角“...”进入群设置。
- 找到“群机器人”入口，点击“添加机器人”。
- 给机器人起个名字，比如“运维告警助手”，也可以上传一个头像。
- 添加成功后，会生成一个Webhook地址，形如：
https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx。 - 把Webhook地址复制保存，后续程序就用它发消息。
这里有几个细节值得提醒：
- 一个群能添加多个机器人。实操中几十个都可以，但没必要用太多，建议按业务类型分组，比如“监控告警”“业务订单”“每日日报”各用各的机器人。
- Webhook地址里的key是这个机器人的唯一凭证。企业微信生成的Webhook地址默认长期有效，但如果你删除机器人再重新添加，地址就会变化，程序里也需要同步更新。
- 不要把Webhook地址写到公开仓库，更不要贴到群里。任何人拿到这个地址，都能往你的群里发消息，甚至发垃圾内容。
- 群管理里有权限配置，有的团队会限制普通成员添加机器人。如果找不到“群机器人”入口，可以让群主或管理员开启权限。
顺利拿到地址后，你就算完成了一半。剩下的工作就是写代码了。
2.3 消息类型与JSON结构速查
企业微信群机器人目前支持以下几类消息，平时最常用的就是text和markdown：
text：纯文本，支持mentioned_list和mentioned_mobile_list两个字段，用来@指定成员或所有人。markdown：支持部分Markdown语法，比如标题、加粗、链接、引用、代码块。注意限制：总长度不能超过2000字节（注意是字节不是字符），不支持复杂的HTML。image：base64编码后的图片数据，加上md5值。图片上限2MB。news：图文消息，最多8条。template_card：模板卡片消息，可以展示更丰富的样式和按钮，适合做交互。
如果你只想快速跑通，记住最简单的text结构就够了：
{ "msgtype": "text", "text": { "content": "大家好，我是机器人" } }至于markdown，基本结构是这样的：
{ "msgtype": "markdown", "markdown": { "content": "**告警通知**\n> 服务器负载过高" } }有的同学问，markdown到底支持哪些语法？根据我的实测，标题、加粗、斜体、引用、代码块、链接、图片这些基础语法没问题，但复杂的表格、嵌套列表、任务清单这类高级特性不一定都能渲染。建议在开发前先用一个小测试工具把你要用的语法试一遍，不要想当然。
3. 从零写一个可用的发送机器人
3.1 发送文本消息的完整代码
现在开始写代码。先写最简版本，用requests库往Webhook地址发一条文本消息：
import requests webhook_url = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的key" def send_text(webhook, content, mentioned_list=None): data = { "msgtype": "text", "text": { "content": content, "mentioned_list": mentioned_list if mentioned_list else [] } } resp = requests.post(webhook, json=data) print(resp.json()) if __name__ == "__main__": send_text(webhook_url, "这是来自Python的机器人消息")运行这段代码后，群里会马上收到一条消息。如果返回结果里errcode是0、errmsg是ok，说明一切正常。
解释一下参数细节：
content：文本内容，长度限制为2048字节。中文字符在UTF-8编码下占3个字节，所以中文内容建议控制在1000字以内。判断字节数不要用len(content)，要用len(content.encode("utf-8"))。mentioned_list：数组，传的是成员的userid列表。注意是企业微信的userid，不是微信昵称。mentioned_mobile_list：数组，传成员的手机号列表。如果想@所有人，可以传"@all"。同时传两个列表时，谁在哪个列表里谁就会被@到。
对于常见的“@所有人”需求，改一下参数即可：
def send_text_all(webhook, content): data = { "msgtype": "text", "text": { "content": content, "mentioned_list": ["@all"] } } requests.post(webhook, json=data)这种方式很适合发“紧急故障通知”，因为群成员能第一时间收到强提醒。
3.2 封装通用消息发送函数
日常项目里，我们不会只发一种消息，所以我习惯封装一个通用的发送函数，支持text、markdown、image、news这几种常用类型。这样无论是被监控系统调用，还是被定时任务调用，代码看起来都很清爽。
我的通用封装大概是这个样子：
import requests import hashlib import base64 class WeChatWebhookRobot: def __init__(self, webhook_url): self.webhook_url = webhook_url def _post(self, data): resp = requests.post(self.webhook_url, json=data, timeout=5) result = resp.json() if result.get("errcode") != 0: raise RuntimeError(f"wechat webhook send failed: {result}") return result def send_text(self, content, mentioned_list=None, mentioned_mobile_list=None): text = {"content": content} if mentioned_list: text["mentioned_list"] = mentioned_list if mentioned_mobile_list: text["mentioned_mobile_list"] = mentioned_mobile_list return self._post({"msgtype": "text", "text": text}) def send_markdown(self, content): return self._post({"msgtype": "markdown", "markdown": {"content": content}}) def send_image(self, image_path): with open(image_path, "rb") as f: image_data = f.read() content_base64 = base64.b64encode(image_data).decode("utf-8") md5 = hashlib.md5(image_data).hexdigest() return self._post({ "msgtype": "image", "image": {"base64": content_base64, "md5": md5} })使用的时候，只需要初始化一个机器人对象，然后按需调用：
robot = WeChatWebhookRobot(webhook_url) robot.send_text("Hello World") robot.send_markdown("**这是一条加粗消息**") robot.send_image("/tmp/screenshot.png")封装类的意义在于：把HTTP请求、异常处理、参数组装都收拢到一个地方。后续如果接口有变动，只改一个类就好了。这个习惯不管做什么项目都适用——单函数负责单职责。如果是在团队里，建议把这个类放到公共模块，人人都能复用。
3.3 定时任务与自动化推送
机器人能发消息只是第一步，真正让它产生价值的是自动化。我经常接到需要“每天定时推送日报/天气/股票行情/比赛结果”的需求，这里以一个每日天气播报为例。
思路很简单：用一个定时任务框架调度，每天固定时间触发Python脚本，脚本去请求天气API，拿到数据后组装成markdown，推送到群里。
安装APScheduler：
pip install apscheduler然后写定时任务：
import requests from apscheduler.schedulers.blocking import BlockingScheduler from robot import WeChatWebhookRobot webhook_url = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的key" robot = WeChatWebhookRobot(webhook_url) def fetch_weather(city): # 以和风天气为例，请替换为自己的API Key和接口 url = "https://api.qweather.com/v7/weather/now" params = { "location": city, "key": "你的API Key" } resp = requests.get(url, params=params, timeout=5).json() now = resp["now"] return f"{city}当前温度：{now['temp']}℃，天气：{now['text']}" def daily_report(): weather_info = fetch_weather("101010100") content = f"## 每日天气播报\n> {weather_info}\n\n---\n消息由Python定时任务自动发送" robot.send_markdown(content) scheduler = BlockingScheduler() scheduler.add_job(daily_report, "cron", hour=8, minute=30, id="daily_weather") scheduler.start()这段代码的关键点是：
- 使用
cron触发器，类似Linux的crontab，可以灵活定义执行时间。比如hour=8, minute=30代表每天8:30执行。 - 在函数内部组装markdown消息，推送内容里包含标题、引用和分割线，渲染效果好看很多。
- 定时任务进程不能在后台退出。部署服务器时用nohup或者systemd守护进程，保证它长期运行。
如果你不想用APScheduler，用crontab也可以：写一个独立脚本，然后crontab -e添加规则。两种方式没有本质区别，看你的部署习惯。不管用哪种，记得给脚本加日志，不然哪天没推送，你连原因都查不到。
4. 进阶实战：自动回复与多场景联动
4.1 用Flask接收企业微信回调实现自动回复
上面讲的群机器人Webhook只能单向推送。如果你需要用户给机器人发消息、机器人自动回复，就得走企业微信“应用消息”的路子：在企业微信后台创建一个自建应用，配置回调URL，当用户给应用发消息时，企业微信会把这个消息POST到你的回调URL。
我用Flask做过一个简单的自动回复Demo，核心思路如下：
- 在企业微信管理后台，进入“应用管理”，创建一个自建应用。
- 在应用里配置“接收消息”的URL，比如
https://your-domain.com/wechat/callback，同时设置Token和EncodingAESKey。 - Flask提供两个路由：一个处理GET请求用于URL验证，一个处理POST请求用于接收消息。
- 收到消息后解析XML，拿到用户发送的内容，调用智能回复接口（比如聊天机器人API或自己的业务逻辑），再把回复消息POST回企业微信。
先展示URL验证这一段。企业微信的回调URL验证逻辑是：GET请求带msg_signature、timestamp、nonce、echostr参数，我们需要用Token和加密Key做签名校验，解密echostr并原样返回。
from flask import Flask, request import time import xml.etree.ElementTree as ET from WXBizMsgCrypt import WXBizMsgCrypt app = Flask(__name__) TOKEN = "你的Token" ENCODING_AES_KEY = "你的EncodingAESKey" CORP_ID = "你的企业ID" @app.route("/wechat/callback", methods=["GET", "POST"]) def callback(): wxcpt = WXBizMsgCrypt(TOKEN, ENCODING_AES_KEY, CORP_ID) if request.method == "GET": verify_msg_sign = request.args.get("msg_signature", "") verify_timestamp = request.args.get("timestamp", "") verify_nonce = request.args.get("nonce", "") verify_echostr = request.args.get("echostr", "") ret, echo_str = wxcpt.VerifyURL(verify_msg_sign, verify_timestamp, verify_nonce, verify_echostr) if ret == 0: return echo_str return "bad request" else: # POST请求里是企业微信推送过来的消息密文 req_msg_sign = request.args.get("msg_signature", "") req_timestamp = request.args.get("timestamp", "") req_nonce = request.args.get("nonce", "") data = request.data ret, xml_content = wxcpt.DecryptMsg(data, req_msg_sign, req_timestamp, req_nonce) if ret != 0: return "bad request" root = ET.fromstring(xml_content) msg_type = root.find("MsgType").text content = root.find("Content").text from_user = root.find("FromUserName").text reply = f"你刚刚说：{content}" # 构造回复消息并加密返回 reply_xml = f"""<xml> <ToUserName><![CDATA[{from_user}]]></ToUserName> <FromUserName><![CDATA[{CORP_ID}]]></FromUserName> <CreateTime>{int(time.time())}</CreateTime> <MsgType><![CDATA[text]]></MsgType> <Content><![CDATA[{reply}]]></Content> </xml>""" ret, encrypt_reply = wxcpt.EncryptMsg(reply_xml, req_timestamp, req_nonce) return encrypt_reply if __name__ == "__main__": app.run(host="0.0.0.0", port=5000)这里使用了官方提供的第三方类WXBizMsgCrypt，在企业微信开发者文档里可以下载WXBizMsgCrypt.py，放到项目目录后直接导入。千万不要自己去实现AES加解密，很容易在填充、字节序上翻车。
这个方案比群机器人复杂不少，但换来的是双向交互能力：用户给应用发一条消息，应用可以回复一条消息，还能调用各种接口处理业务逻辑。典型的场景是内部IT支持机器人、会议预订机器人。
另外提醒一句，回调接口必须部署在公网可以访问的HTTPS域名下，开发阶段可以临时用一个可访问的域名或隧道工具测试，生产环境建议使用公网服务器，并且提前做好HTTPS证书配置。
4.2 对接监控系统与业务系统告警
Webhook机器人最常见的落地场景之一，就是对接各类监控系统，把故障信息第一时间推到群里。
以Prometheus + Alertmanager为例。Alertmanager支持配置自定义Webhook receiver，将告警数据POST到你的Python服务，再由Python服务把告警格式化成markdown发到企业微信群。架构大概是：
报警事件 -> Alertmanager -> Python Webhook服务 -> 企业微信群机器人
你也可以不用Python中转，直接用Alertmanager的通用Webhook配置，把告警直接POST到企业微信机器人的Webhook地址。不过企业微信要求的JSON结构和Alertmanager的默认结构不一致，直接对接需要对Alertmanager做template配置。用Python中转的好处是能灵活做消息格式转换、聚合去重，减少群里的告警轰炸。
写一个简单的Flask中转接口，接收Alertmanager的POST请求，再把处理后的消息通过机器人推送：
from flask import Flask, request from robot import WeChatWebhookRobot import json app = Flask(__name__) robot = WeChatWebhookRobot(webhook_url) @app.route("/alert", methods=["POST"]) def alert_receiver(): data = request.json alerts = data.get("alerts", []) if not alerts: return "ok" lines = [] for alert in alerts[:5]: # 只取前5条告警，避免刷屏 status = "严重" if alert["status"] == "firing" else "恢复" name = alert["labels"].get("alertname", "未知") desc = alert.get("annotations", {}).get("description", "无描述") lines.append(f"> **[{status}]** {name}\n> {desc}") content = "\n".join(lines) robot.send_markdown(content) return "ok" if __name__ == "__main__": app.run(host="0.0.0.0", port=5000)像这样把告警消息做一次“瘦身”，只保留最关键信息，比直接把原始JSON怼到群里清晰得多。我在实际项目里还遇到过告警风暴的问题，一天收到几百条，后来加了简单的去重和降噪逻辑——相同告警在十分钟内只发一次，紧急程度高的才立刻发，群里瞬间安静了。
4.3 多群多机器人管理与配置化
业务大了之后，你会发现自己手里有一堆Webhook地址，对应不同群、不同机器人。如果每个项目都硬编码URL，改起来就麻烦了。
我的做法是抽一个配置文件，用yaml管理所有机器人信息：
# robots.yaml monitor: webhook: "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=aaa" name: "监控告警" business: webhook: "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=bbb" name: "业务订单" daily: webhook: "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=ccc" name: "每日日报"然后在代码里读取配置，按key选择机器人：
import yaml with open("robots.yaml", "r", encoding="utf-8") as f: robots = yaml.safe_load(f) def get_robot(name): conf = robots[name] return WeChatWebhookRobot(conf["webhook"]) # 用法 get_robot("monitor").send_text("数据库连接异常，请检查") get_robot("daily").send_markdown("今日销售数据如下...")用配置中心管理还有一个额外好处：机器人换绑、增加群、故障转移时，只改配置不重启服务，降低了变更风险。如果团队已经用了Consul、Apollo等配置中心，同样可以做到动态更新，不必局限于本地yaml文件。
5. 常见问题、避坑指南与经验总结
5.1 高频报错与排查速查表
我把自己过去踩过的坑整理成了一张速查表，方便你对号入座：
| 返回码或现象 | 可能原因 | 解决办法 |
|---|---|---|
| errcode 40001 | 不合法的access_token | 检查是不是用了旧接口或旧地址，确认Webhook地址完整 |
| errcode 40002 | 不合法的消息类型 | 检查msgtype是否在支持列表内：text/markdown/image/news/template_card |
| errcode 40003 | 不合法的成员userid | 检查mentioned_list里的userid是否存在 |
| errcode 44004 | 文本内容超长 | text内容限制2048字节，markdown限制2000字节，精简内容 |
| errcode 45009 | 接口调用超过频率限制 | 每个机器人每分钟最多20条消息，做好限速和聚合 |
| errcode 93000 | 机器人不存在 | Webhook地址里的key可能与当前群不匹配，重新添加机器人 |
| HTTP 404 | 地址错误或拼写错误 | 检查地址是否完整，尤其不要漏掉query参数key |
| 超时或网络不通 | 网络环境无法访问企业微信域名 | 检查服务器出网策略、DNS、代理设置 |
一个实用的排查思路：先把出问题的JSON用curl原样发一遍。如果curl能通、代码不通，问题多半在requests的编码或者网络代理上。如果curl也不通，那就再去对比官方文档的字段名，排查写错的键。另外，生产环境一定要给发送函数加try...except和日志记录，否则等真正出错的时候，你只能在群里干瞪眼。
5.2 企业微信机器人的限制清单与应对
这节专门讲限制，因为很多新手写好了脚本，上线跑了一天后发现被限流或者消息发不出来了。
- 每个机器人每分钟最多发送20条消息。这个限额是硬性的，瞬间大批量推送会触发返回码45009。应对方案是：批量消息合并成一条，或者做异步队列、平滑发送。我曾经帮一个团队做过一个“缓冲队列+定时flush”的模块，把高峰期的几百条消息按每秒一条的速度慢慢发出去，群里不会刷屏，接口也不会报错。
- 内网地址不能访问Webhook接口。企业微信的Webhook地址是公网域名，如果你的程序部署在内网，需要确认出网权限。这一点机房托管的朋友特别容易踩。
- text消息content字段2048字节，markdown消息content字段2000字节，image消息图片不能超过2MB。超长会被拒绝。推送长文时，建议先截断再发送。
- markdown支持的是精简版语法，不是完整GFM。比如列表缩进、复杂表格这些不一定都支持，复杂排版还是建议用
template_card消息。 - Webhook地址不含过期时间，但企业换绑、删除机器人会导致key失效。建议每周或每月做一次连通性检查，发现失效及时换key。
这些限制写在文档里容易被忽略，但实际生产中每条都可能导致线上问题。提前了解，比出了故障再查文档高效太多。
5.3 个人微信协议的现状与合规建议
看到这里，肯定有人要问：那我要是就想操作个人微信号呢？说实话，前几年itchat这类库确实很火，我也写过不少基于它的脚本。但后来微信官方对非官方客户端的管控越来越严格，大量协议库已经失效，还在维护的也基本转入地下。用这类方案做机器人，最直接的体验就是今天能用、明天被封，账号被限制登录不是新鲜事。把业务流程绑上去，等于把命门交到别人手里。
我的态度很明确：做内部工具、做自动化通知，优先使用企业微信官方接口，稳定、合规、可维护。如果你确实有“个人微信机器人”的需求，最稳妥的办法是使用企业微信里的“微信客服”能力，用户通过微信客服入口联系你，你在后台用API进行回复，这同样是官方通道。
技术探索是好事，但凡是和账号安全沾边的事情，一定要想清楚风险。我不建议任何人拿重要的微信号去折腾第三方协议库，不仅封号心痛，还可能给自己带来不必要的麻烦。
5.4 一些实战经验与个人心得
文章写到这，把几个核心经验再串一遍。
第一，先把“消息内容”设计好，再写代码。我发现很多时候脚本逻辑很简单，复杂的是内容：告警要写清楚系统名、实例IP、时间、影响范围、处理建议；日报要写清楚关键指标和对比值。消息是给人看的，内容质量决定这个机器人是不是好用。
第二，把机器人当作一个“Webhook服务”来设计，让它成为团队的基础设施。不要在每个项目里复制一份发送代码，而是把封装好的模块作为公共组件，其他人调用即可。团队里有人不知道企业微信还有机器人，我推荐了他之后，他说这比邮件通知好用太多了。
第三，调试的时候先试发给自己。单独建一个只有机器人的群，把调试消息发到那里，不要一上来就往生产群里发。我见过有人调试时把测试内容发到全员群，场面相当尴尬。养成用独立测试群的习惯，能少挨很多骂。
最后再说一个小技巧：企业微信机器人Webhook不仅适合Python，任何语言都能调用。这意味着它天然适合做“消息出口”或者“通知通道”：允许任何语言发消息到统一入口，再由机器人推送到群。我在公司甚至用脚本把CI构建结果、数据库备份结果、爬虫任务状态都汇入同一个群，真正做到了“一屏看所有系统状态”。希望这篇文章能帮你把机器人的价值真正用起来。
