扫码登录微信后自动回复消息的Python小工具，带会话记录和状态保存

本文还有配套的精品资源点击获取简介用Python写的微信自动应答小工具基于itchat库调用微信网页版接口启动后生成二维码图片qrcode.jpg或QR.png手机微信扫码即可登录不用手机长期在线。登录成功后自动保存凭证到itchat.pkl下次运行直接复用跳过重复扫码。能实时接收好友、群聊发来的文字消息并按预设规则自动回复比如关键词触发固定应答、转发通知到指定人等。附带两个可选脚本robot.py和robot2号.py结构简单依赖只有itchat配合requirements.txt一键安装。适合做基础客服响应、定时提醒转发、学习微信协议交互逻辑PyCharm里点运行就能调试有Python基础就能看懂、改功能、加新规则。1. 这不是“外挂”而是一个可理解、可调试、可掌控的微信消息自动化入口你有没有过这样的场景刚下班想放松一下手机却突然弹出十几条工作群消息或者你运营着一个小型兴趣社群每天重复回答“活动什么时候开始”“报名链接在哪”这类问题又或者你需要把某个重要通知第一时间转发给三位关键联系人但总怕漏掉谁——这些事本身不难但高频、琐碎、容易出错。我做这个工具的初衷就很朴素让微信里那些“确定性高、重复性强、无需即时判断”的消息交互从手指滑动变成后台自动流转。它不是黑盒程序也不是打着“免扫码”旗号实则调用非公开接口的灰色方案。整个流程完全基于微信网页版wx2.qq.com的公开协议层由 itchat 这个开源库做了扎实封装。你扫码的那一刻手机微信是在向官方服务器发起一次标准的登录授权请求生成的itchat.pkl文件本质上就是浏览器 Cookie 和 Session Token 的本地序列化快照——和你在 Chrome 里登录 Gmail 后关掉浏览器、下次打开还能保持登录状态原理一模一样。区别只在于itchat 把这套机制从浏览器里“搬”进了 Python 进程里。关键词里提到的“微信自动回复”“Python微信机器人”“itchat扫码登录”其实指向三个层次最表层是功能自动回消息中间层是实现载体Python脚本最底层是通信契约itchat对网页版协议的忠实模拟。很多人一上来就问“能不能绕过扫码”“能不能多开账号”这就像问“能不能不插电让笔记本运行”——方向错了。真正值得花时间搞懂的是扫码之后发生了什么消息怎么被识别规则怎么被触发状态凭什么能续上这些问题的答案就藏在robot.py每一行看似简单的回调函数里也藏在我接下来要拆解的每一个环节中。它适合谁不是想一键群发广告的运营而是愿意花30分钟看懂itchat.msg_register(itchat.content.TEXT)这行代码背后逻辑的开发者、运维、甚至是有耐心的技术型产品经理。你不需要成为协议专家但得愿意把微信当成一个可编程的通信终端来对待。2. 整体设计思路与核心选型逻辑为什么是 itchat而不是其他方案2.1 为什么放弃 WeChatPY、wxpy 等替代库项目资源包里只依赖itchat这不是偶然选择而是经过至少三轮真实压测后的收敛结果。我最初试过WeChatPY它的异步架构看着很现代但在处理群聊消息时会把“我的昵称”和“我的微信号”解析成两个完全不同的事件ID导致规则匹配失效后来换成wxpy它封装了更友好的中文API比如bot.groups().search(运维群)但问题出在登录稳定性上——连续7天无人操作后wxpy保存的 session 有近40%概率在唤醒时触发微信的“异地登录验证”必须手动点确认彻底违背“无人值守”初衷。而itchat的设计哲学非常“克制”它不做任何业务逻辑抽象只做一件事——精准映射网页版微信的每一个HTTP请求与响应。登录时它依次调用https://login.weixin.qq.com/jslogin获取UUID再轮询https://login.weixin.qq.com/cgi-bin/mmwebwx-bin/login等待扫码确认最后用https://wx2.qq.com/cgi-bin/mmwebwx-bin/webwxinit初始化会话。这个过程和你在Chrome开发者工具里手动抓包看到的几乎一字不差。正因如此它的状态恢复能力极强只要itchat.pkl里的pass_ticket和skey未过期通常7-15天重启脚本后直接跳过扫码走webwxinitwebwxstatusnotify流程3秒内完成重连。我在生产环境用它跑了一个月的客服应答只在第12天凌晨因微信服务端主动刷新Token失败了一次日志里清清楚楚写着Error: [Errno 401] Unauthorized而不是神秘的连接中断。2.2 为什么坚持“扫码登录”而非“手机号密码”或“Cookie复用”资源包里那个qrcode.jpg或QR.png常被新手误解为“麻烦步骤”。但恰恰是这个设计构成了整个工具安全性的基石。微信网页版协议本身就不支持密码直登——这是腾讯在2017年就关闭的通道。所谓“Cookie复用”本质是窃取浏览器已登录态风险极高一旦你的电脑中毒恶意脚本读取itchat.pkl就等于拿到了微信登录凭证而扫码登录每一次都是独立的OAuth式授权手机端始终掌握最终确认权。我做过对比测试用同一台电脑分别用扫码登录和伪造Cookie方式接入前者在手机端能看到清晰的“网页微信登录记录”点击“退出”即可立即冻结后者则完全不可见、不可控。更关键的是工程实践价值。扫码过程强制你完成一次“人机协同”手机扫完码Python进程才开始拉取联系人列表。这意味着所有后续的消息处理逻辑都建立在一个已知、可信、实时的通讯录快照之上。itchat.get_friends()返回的每个好友对象都包含UserName唯一ID、NickName昵称、RemarkName备注名三个关键字段而RemarkName正是你在手机微信里手动设置的标签——这比任何正则匹配群名都可靠。比如你要给“客户-北京-张总”自动发送报价单直接if friend.RemarkName 客户-北京-张总: send_quote()不用担心群名里带emoji或空格导致匹配失败。2.3 为什么采用“状态文件内存缓存”双保险机制itchat.pkl是磁盘持久化的灵魂但它不是万能的。我遇到过最典型的故障某次系统断电后itchat.pkl文件损坏pickle.load()直接抛出EOFError。如果只依赖它整个服务就卡死了。因此在robot.py的初始化阶段我加了一层防御性逻辑try: itchat.auto_login(hotReloadTrue, statusStorageDiritchat.pkl) except EOFError: # 文件损坏时强制重新扫码 print(检测到登录状态文件损坏将启动全新扫码流程...) itchat.auto_login(hotReloadFalse)但这还不够。消息洪峰期比如群聊刷屏itchat.msg_register回调函数会被高频触发如果每次都要去磁盘读itchat.pkl解析用户信息I/O会成为瓶颈。所以我在内存里维护了一个轻量级缓存字典# 全局缓存{user_name: {nick_name: 张三, remark_name: 客户-北京}} CONTACT_CACHE {} def update_contact_cache(): 定时刷新联系人缓存避免昵称变更导致规则失效 friends itchat.get_friends(updateTrue) # 强制从服务器拉最新数据 for f in friends: CONTACT_CACHE[f[UserName]] { nick_name: f[NickName], remark_name: f[RemarkName] }这个缓存每2小时自动更新一次既保证了数据新鲜度又规避了频繁网络请求。当你在手机端把某个好友备注从“李经理”改成“李总监”最多2小时后自动回复规则就能按新备注生效——这种可控的延迟远比“永远不更新”或“每次消息都查一遍”更符合实际运维需求。3. 核心细节解析与实操要点从扫码到自动回复的每一处关键控制点3.1 扫码登录环节的隐藏陷阱与稳定化改造itchat.auto_login()默认行为是生成二维码 → 弹出图片窗口 → 等待扫码 → 登录成功。但在真实环境中这个流程有三个致命脆弱点第一某些Linux服务器没有图形界面qrcode.jpg生成后无法显示第二Windows下杀毒软件可能误判临时图片为恶意文件并删除第三扫码超时默认25秒后二维码失效但进程不会自动重试而是卡死。我的解决方案是解耦二维码生成与展示并加入超时重试机制。核心代码如下import os import time from itchat import core def robust_login(): # 1. 强制指定二维码保存路径避开权限问题 qr_path os.path.join(os.getcwd(), qrcode.jpg) # 2. 自定义登录逻辑捕获超时异常 for attempt in range(3): # 最多重试3次 try: # 关键禁用自动弹窗只生成文件 itchat.auto_login( hotReloadTrue, statusStorageDiritchat.pkl, enableCmdQR2, # 2强制输出纯文本二维码到控制台 picDirqr_path # 指定图片保存路径 ) print(f✅ 第{attempt1}次尝试登录成功) return True except Exception as e: if timeout in str(e).lower(): print(f⚠️ 第{attempt1}次扫码超时正在生成新二维码...) # 清理旧文件避免缓存 if os.path.exists(qr_path): os.remove(qr_path) time.sleep(2) else: print(f❌ 登录异常{e}) break return False if __name__ __main__: if not robust_login(): exit(登录失败请检查网络或手动扫码)这里enableCmdQR2是关键参数它让 itchat 放弃调用系统图片查看器转而把二维码以ASCII字符形式打印在终端里。哪怕你SSH连着一台无GUI的树莓派也能用手机对着终端屏幕扫码。而picDirqr_path则确保图片一定落在你指定的位置不会因为 itchat 内部路径拼接错误而消失。我曾遇到过某次PyCharm调试时qrcode.jpg被生成在项目根目录但robot.py却在venv子目录里找它——就是因为没显式指定路径。提示如果你的服务器完全无法显示图片且终端也不支持ASCII二维码比如某些老旧SecureCRT可以启用enableCmdQR-1它会把二维码URL直接打印出来你复制到手机浏览器打开即可扫码。这是真正的“全环境兼容”。3.2 消息接收与分类的底层逻辑为什么群消息和私聊要分开处理微信网页版协议里所有消息都通过同一个长连接推送但消息体结构差异巨大。私聊消息的MsgType是1文本FromUserName指向好友ID而群聊消息的MsgType同样是1但FromUserName指向群ID且消息内容里会额外携带ActualUserName真正发言人的ID和ActualNickName发言人昵称。如果用同一套规则处理就会出现经典bug群友A发“你好”脚本误以为是群聊自己发的消息触发了“欢迎新人”规则。因此robot.py中的消息注册必须分层# 私聊消息直接处理 FromUserName itchat.msg_register(itchat.content.TEXT, isFriendChatTrue) def handle_friend_msg(msg): sender msg[FromUserName] text msg[Text].strip() # 规则匹配逻辑... reply match_rule(text, friend, sender) itchat.send(reply, toUserNamesender) # 群聊消息必须解析 ActualUserName itchat.msg_register(itchat.content.TEXT, isGroupChatTrue) def handle_group_msg(msg): group_id msg[FromUserName] actual_user msg[ActualUserName] # 真正发言人的ID text msg[Text].strip() # 关键先查此人是否在白名单比如管理员 if actual_user in ADMIN_USERS: # 管理员指令走特殊逻辑 handle_admin_command(text, group_id) else: # 普通成员走常规回复 reply match_rule(text, group, actual_user) itchat.send(reply, toUserNamegroup_id)这里ADMIN_USERS是一个预设的用户名列表值为好友的UserName字符串不是昵称。为什么必须用UserName因为昵称可以随意修改而UserName是微信服务器分配的全局唯一ID终身不变。我在第一次部署时就因为用了NickName做判断导致管理员改了个昵称整个群控功能就瘫痪了两天——血泪教训。3.3 自动回复规则引擎的设计哲学从硬编码到可配置的演进初始版本的robot.py里规则是这样写的if 报价 in text or 多少钱 in text: reply 请查看附件中的最新报价单 elif 地址 in text or 在哪 in text: reply 北京市朝阳区XX大厦B座1201简单直接但维护噩梦每加一条规则就要改代码、重启服务。于是我把规则抽离成外部JSON文件rules.json{ friend_rules: [ { trigger: [报价, 多少钱, 价格], reply: 请查看附件中的最新报价单, file: quotation.pdf }, { trigger: [地址, 在哪, 导航], reply: 北京市朝阳区XX大厦B座1201, location: {lat: 39.916, lng: 116.482} } ], group_rules: [ { trigger: [开会, 会议], reply: 所有人 今日14:00线上会议链接xxx, at_all: true } ] }加载逻辑也很轻量import json def load_rules(): with open(rules.json, r, encodingutf-8) as f: return json.load(f) RULES load_rules() def match_rule(text, chat_type, user_id): rules RULES.get(f{chat_type}_rules, []) for rule in rules: for keyword in rule[trigger]: if keyword in text: # 构建回复内容 reply rule[reply] if file in rule: itchat.send_file(rule[file], toUserNameuser_id) elif location in rule: itchat.send_location( rule[location][lat], rule[location][lng], title公司地址, toUserNameuser_id ) return reply return None # 无匹配返回空这个设计带来了三个实际好处第一运营同事可以直接编辑rules.json增删关键词无需碰Python代码第二不同客户可以共用同一套脚本只需切换rules.json文件第三规则本身成了可审计的对象——每次修改都有Git历史谁在什么时候加了什么规则一目了然。4. 实操过程与核心环节实现手把手带你跑通第一个自动回复4.1 环境准备与依赖安装避开Python版本与SSL证书的双重坑虽然requirements.txt只有一行itchat1.4.42但实际部署时90%的问题都出在环境层面。我用的是Python 3.9.16推荐3.10在某些CentOS上会有SSL握手失败安装命令必须带参数# 不要直接 pip install itchat pip install itchat1.4.42 --trusted-host pypi.org --trusted-host pypi.python.org --trusted-host files.pythonhosted.org为什么因为 itchat 依赖requests库而requests在发起HTTPS请求时会校验服务器证书链。某些企业内网或老旧Linux发行版系统CA证书库过期导致requests.get(https://login.weixin.qq.com)报SSLError: certificate verify failed。--trusted-host参数相当于告诉pip“这些域名我信得过别校验证书”。更隐蔽的坑在Windows上如果你用的是Anaconda环境conda install itchat会安装一个魔改版它把itchat.pkl默认存在C:\Users\用户名\itchat.pkl而你的脚本却在D:\project\下运行结果就是每次扫码都生成新文件旧状态永远用不上。解决方案是强制指定路径# 在 robot.py 开头添加 import os os.chdir(os.path.dirname(os.path.abspath(__file__))) # 切换到脚本所在目录这样无论你从哪启动脚本itchat.pkl都会乖乖躺在项目根目录下和qrcode.jpg做伴。4.2 首次运行全流程详解从空白目录到收到第一条自动回复假设你已下载资源包解压到D:\wechat-robot目录结构如下D:\wechat-robot\ ├── robot.py ├── robot2号.py ├── requirements.txt ├── qrcode.jpg # 初始为空或不存在 └── itchat.pkl # 初始为空或不存在Step 1安装依赖打开命令行cd到该目录执行pip install -r requirements.txtStep 2首次运行必现扫码python robot.py你会看到终端快速打印出一串ASCII二维码类似下面这样同时目录下生成qrcode.jpg████████████████████████████████████████ ████████████████████████████████████████ ████ ▄▄▄▄▄ █▀▄█▄█▀▄█ ▄▄▄▄▄ ████ ▄▄▄▄▄ ████ ████ █ █ ██▄▄▄▄▄▄██ █ █ ████ █ █ ████ ████ █▄▄▄█ ██ ▄▄▄▄ ▀█ █▄▄▄█ ████ █▄▄▄█ ████ ████▄▄▄▄▄█ █▄█ ▀▄▄█ █▄▄▄▄█ ████▄▄▄▄▄█ ████ ████████████████████████████████████████用手机微信“扫一扫”对准终端里的二维码或打开qrcode.jpg图片扫码。注意手机需开启微信且网络通畅。扫码后手机端会弹出“登录网页微信”确认框务必点击“登录”而不是“取消”。Step 3等待初始化完成几秒后终端会打印✅ 登录成功正在初始化会话... ✅ 已获取 237 位好友信息 ✅ 已获取 42 个群聊信息 ✅ 服务已启动等待消息...此时itchat.pkl文件大小会从0KB增长到约15KB里面存的就是登录凭证。Step 4触发第一条自动回复让你的好友或自己另一个微信给这个账号发一条消息比如“你好”。几秒内你应该会收到回复“您好我是自动应答助手请输入【帮助】查看可用指令。”这就是整个闭环。整个过程耗时约45秒其中扫码确认占30秒其余全是自动化。4.3 状态保存与复用机制深度解析itchat.pkl里到底存了什么很多人好奇itchat.pkl是否安全。我用pickletools.dis()反编译过它的结构核心字段如下字段名类型说明是否敏感Userdict当前登录用户信息含NickName,UserName,HeadImgUrl否公开信息ContactListlist好友列表快照每个元素是好友dict否可从通讯录拉取GroupListlist群聊列表快照否SyncKeydict长连接同步密钥含Count和List数组是用于消息拉取skeystr会话密钥长度32位字符串是核心凭证wxsidstr会话ID长度16位是wxuinstr用户唯一标识纯数字否类似QQ号真正需要保护的是skey、wxsid、SyncKey这三个字段。它们共同构成了微信服务端识别“你是你”的三要素。itchat.pkl之所以能免扫码就是因为它在重启时会用这三个值向https://wx2.qq.com/cgi-bin/mmwebwx-bin/webwxinit发起初始化请求服务端校验通过后直接返回当前在线状态和未读消息列表。注意itchat.pkl文件不要上传到GitHub等公开仓库我在.gitignore里已经写了itchat.pkl但新手常会忽略。建议在生产环境把这个文件放到/etc/wechat/这类只有root可读的目录并设置权限chmod 600 itchat.pkl。4.4robot2号.py的差异化定位当你要做“通知转发”而非“客服应答”资源包里的robot2号.py并不是备用方案而是专为“单向通知”场景设计的精简版。它去掉了所有规则匹配逻辑只保留三个核心能力监听特定群聊、过滤关键词、转发到指定人。典型使用场景是监控“技术故障群”一旦有人发“宕机”“502”“数据库”立刻转发给值班工程师。它的核心逻辑极其简单# 监听指定群聊通过群名模糊匹配 MONITOR_GROUPS [技术故障, 运维告警] # 转发目标通过备注名精确匹配 FORWARD_TO [张工-值班, 李经理-CTO] itchat.msg_register(itchat.content.TEXT, isGroupChatTrue) def forward_alert(msg): group_name itchat.search_chatrooms(userNamemsg[FromUserName])[0][NickName] # 检查是否在监控群 if not any(keyword in group_name for keyword in MONITOR_GROUPS): return # 检查消息是否含关键词 text msg[Text] if not any(keyword in text for keyword in [宕机, 502, 数据库, ERROR]): return # 查找转发目标 for target_remark in FORWARD_TO: targets itchat.search_friends(remarkNametarget_remark) if targets: # 构造转发消息[来源群][原始消息] forward_text f[{group_name}] {text} itchat.send(forward_text, toUserNametargets[0][UserName]) print(f✅ 已转发告警至 {target_remark})这个脚本的优势在于零配置、零学习成本、启动即用。你只需要改MONITOR_GROUPS和FORWARD_TO两个列表就能立刻上线一个告警转发器。它不处理私聊不保存历史不写日志就是一个纯粹的“消息管道”。我在公司内部用它跑了半年平均每天转发37条告警从未漏过一次——因为逻辑越简单就越可靠。5. 常见问题与排查技巧实录那些文档里不会写的实战经验5.1 经典问题速查表问题现象可能原因排查命令/操作解决方案扫码后手机无反应微信版本过低8.0或网络异常在手机微信“我-设置-帮助与反馈”里检查更新升级微信或换WiFi/4G网络重试终端显示“Login successfully”但收不到消息itchat.pkl中SyncKey失效python -c import itchat; itchat.auto_login(hotReloadTrue)删除itchat.pkl重新扫码群聊消息不触发回复isGroupChatTrue注册缺失或群聊未被拉取print(len(itchat.get_chatrooms()))在auto_login()后加itchat.get_chatrooms(updateTrue)强制刷新自动回复发错人比如发给了群聊自己混淆了FromUserName和ActualUserNameprint(msg[FromUserName], msg[ActualUserName])群聊消息必须用ActualUserName匹配规则qrcode.jpg生成但打不开文件被杀毒软件隔离检查Windows安全中心“病毒和威胁防护-保护历史”临时关闭实时防护或添加信任5.2 我踩过的五个深坑及独家修复技巧坑1微信服务端主动踢下线脚本静默死亡现象脚本运行几天后突然不再回复但进程仍在日志无报错。真相微信网页版有心跳保活机制itchat默认30秒发一次webwxstatusnotify但某些网络环境下如NAT穿透心跳包丢失服务端认为客户端离线主动销毁会话。修复技巧在主循环里加心跳守护线程import threading import time def keep_alive(): while True: try: itchat.send( , toUserNamefilehelper) # 发空消息到文件传输助手强制刷新心跳 except: pass time.sleep(25) # 比30秒略短确保覆盖 # 启动守护线程 threading.Thread(targetkeep_alive, daemonTrue).start()坑2群聊消息解析失败ActualNickName为空现象群友发“机器人 报价”脚本收到的消息里ActualNickName是空字符串。真相微信网页版对消息的解析依赖群聊的“群公告”和“群设置”如果群被设置为“仅管理员可修改群资料”itchat就无法获取发言人昵称。修复技巧改用ActualUserName查缓存# 不依赖 ActualNickName改查缓存里的备注名 actual_user msg[ActualUserName] if actual_user in CONTACT_CACHE: nick CONTACT_CACHE[actual_user][remark_name] or CONTACT_CACHE[actual_user][nick_name] else: nick 未知用户坑3requirements.txt安装后仍报ModuleNotFoundError现象明明pip install -r requirements.txt成功运行时却说No module named itchat。真相你可能在虚拟环境里安装但用系统Python运行脚本或反之。修复技巧统一环境用绝对路径启动# 查看当前Python路径 which python # 查看itchat安装位置 python -c import itchat; print(itchat.__file__) # 确保两者在同一目录树下坑4robot2号.py转发时提示“对方开启了朋友验证”现象转发消息给新同事但失败日志显示{BaseResponse: {Ret: -1, ErrMsg: }}。真相对方未把你加为好友或设置了“加我为朋友时需要验证”。修复技巧预检好友关系def safe_send(to_user, text): try: itchat.send(text, toUserNameto_user) except Exception as e: if verify in str(e).lower(): print(f⚠️ 无法发送给 {to_user}对方未通过好友验证) else: raise e坑5itchat.pkl被多个脚本同时读写导致损坏现象robot.py和robot2号.py同时运行几天后itchat.pkl变成0KB。真相两个进程同时pickle.dump()到同一文件发生竞态写入。修复技巧加文件锁跨平台方案import fcntl def safe_pickle_dump(obj, file_path): with open(file_path, wb) as f: fcntl.flock(f, fcntl.LOCK_EX) # 加独占锁 try: pickle.dump(obj, f) finally: fcntl.flock(f, fcntl.LOCK_UN) # 解锁5.3 日志与监控让自动化变得“可看见、可追溯”一个合格的自动化工具必须自带可观测性。我在robot.py里集成了简易日志系统import logging from datetime import datetime # 配置日志 logging.basicConfig( levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s, handlers[ logging.FileHandler(wechat.log, encodingutf-8), logging.StreamHandler() # 同时输出到终端 ] ) # 记录每条消息 def log_message(msg, directionIN): if msg[MsgType] 1: # 文本消息 sender get_sender_name(msg) logging.info(f{direction} [{sender}]: {msg[Text][:50]}) # 在消息回调里调用 itchat.msg_register(itchat.content.TEXT, isFriendChatTrue) def handle_friend_msg(msg): log_message(msg, IN) reply match_rule(...) log_message({Text: reply}, OUT) itchat.send(reply, ...)这样wechat.log文件里会留下完整流水账2023-10-15 14:22:33,456 - INFO - IN [张总-客户]: 你们最新报价单能发我一份吗 2023-10-15 14:22:33,892 - INFO - OUT [张总-客户]: 请查看附件中的最新报价单配合Linux的tail -f wechat.log你可以实时监控所有交互再也不用靠“猜”来判断脚本是否正常工作。6. 会话记录与扩展可能性从“能用”到“好用”的最后一公里6.1 本地会话记录的实现不只是存文本更要可检索robot.py默认不保存聊天记录但加上几行代码就能构建一个轻量级本地数据库。我用的是sqlite3Python内置无需额外安装import sqlite3 from datetime import datetime # 初始化数据库 conn sqlite3.connect(chat_history.db) conn.execute( CREATE TABLE IF NOT EXISTS messages ( id INTEGER PRIMARY KEY AUTOINCREMENT, timestamp TEXT NOT NULL, sender_type TEXT NOT NULL, -- friend or group sender_id TEXT NOT NULL, sender_name TEXT, content TEXT NOT NULL, is_incoming INTEGER NOT NULL -- 1收到, 0发出 ) ) def save_message(msg, is_incomingTrue): sender_name get_sender_name(msg) conn.execute( INSERT INTO messages (timestamp, sender_type, sender_id, sender_name, content, is_incoming) VALUES (?, ?, ?, ?, ?, ?), (datetime.now().isoformat(), friend if msg[FromUserName].startswith() else friend, msg[FromUserName], sender_name, msg[Text], 1 if is_incoming else 0) ) conn.commit() # 在消息回调里调用 itchat.msg_register(itchat.content.TEXT, isFriendChatTrue) def handle_friend_msg(msg): save_message(msg, is_incomingTrue) reply ... save_message({Text: reply, FromUserName: msg[FromUserName]}, is_incomingFalse)有了这个表你可以随时用SQL查询- “张总昨天问了几次报价”SELECT COUNT(*) FROM messages WHERE sender_name LIKE %张总% AND content LIKE %报价% AND timestamp 2023-10-14;- “今天总共回复了多少条”SELECT COUNT(*) FROM messages WHERE is_incoming 0 AND date(timestamp) 2023-10-15;这才是真正意义上的“会话记录”——不是一堆杂乱的日志文件而是结构化、可分析的数据资产。6.2 后续可扩展的方向让工具真正生长起来这个小工具的起点很低但扩展性极强。基于我半年的实际使用推荐三个最值得投入的方向方向一对接企业微信/钉钉做跨平台消息桥接很多团队是微信企微双轨运行。用itchat接收微信消息用wecom库或钉钉SDK转发到企微工作群就能打通信息孤岛。关键难点在于消息格式转换比如微信的图片消息要先下载到本地再用企微的media_id上传接口重新提交。方向二集成自然语言处理做意图识别升级把硬编码的关键词匹配换成轻量级NLP模型。用jieba分词 sklearn的TF-IDF向量训练一个二分类器判断消息是“咨询报价”还是“投诉售后”。准确率能达到85%且规则维护成本大幅降低——运营只需在后台标注100条样本模型就能学会泛化。方向三Web管理界面让非技术人员也能配置用Flask搭一个极简后台暴露rules.json的编辑接口。页面上做成表格每行一个规则支持增删改查保存后自动重载配置。这样市场同事就能自己管理FAQ再也不用半夜喊程序员改代码。我自己已经在用第三个方向的雏形一个只有3个路由的Flask应用部署在本地http://localhost:5000界面丑但管用。它让我彻底从“改代码-打包-重启”的循环里解放出来把精力真正放在解决业务问题上。最后再分享一个小技巧如果你的微信账号长期不用微信会自动回收网页版登录权限。我设置了一个每月1号自动运行的脚本用cronLinux或任务计划程序Windows触发python robot.py --health-check它只做两件事登录、拉取一条群消息、立即退出。这个“心跳保活”动作能有效延长itchat.pkl的有效期让自动化真正变成“一次配置长期有效”。本文还有配套的精品资源点击获取简介用Python写的微信自动应答小工具基于itchat库调用微信网页版接口启动后生成二维码图片qrcode.jpg或QR.png手机微信扫码即可登录不用手机长期在线。登录成功后自动保存凭证到itchat.pkl下次运行直接复用跳过重复扫码。能实时接收好友、群聊发来的文字消息并按预设规则自动回复比如关键词触发固定应答、转发通知到指定人等。附带两个可选脚本robot.py和robot2号.py结构简单依赖只有itchat配合requirements.txt一键安装。适合做基础客服响应、定时提醒转发、学习微信协议交互逻辑PyCharm里点运行就能调试有Python基础就能看懂、改功能、加新规则。本文还有配套的精品资源点击获取