扫码登录微信后自动回复消息的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天），重启脚本后直接跳过扫码，走webwxinit+webwxstatusnotify流程，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(hotReload=True, statusStorageDir='itchat.pkl') except EOFError: # 文件损坏时，强制重新扫码 print("检测到登录状态文件损坏，将启动全新扫码流程...") itchat.auto_login(hotReload=False)

但这还不够。消息洪峰期（比如群聊刷屏），@itchat.msg_register回调函数会被高频触发，如果每次都要去磁盘读itchat.pkl解析用户信息，I/O会成为瓶颈。所以我在内存里维护了一个轻量级缓存字典：

# 全局缓存：{user_name: {'nick_name': '张三', 'remark_name': '客户-北京'}} CONTACT_CACHE = {} def update_contact_cache(): """定时刷新联系人缓存，避免昵称变更导致规则失效""" friends = itchat.get_friends(update=True) # 强制从服务器拉最新数据 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( hotReload=True, statusStorageDir='itchat.pkl', enableCmdQR=2, # 2=强制输出纯文本二维码到控制台 picDir=qr_path # 指定图片保存路径 ) print(f"✅ 第{attempt+1}次尝试登录成功！") return True except Exception as e: if "timeout" in str(e).lower(): print(f"⚠️ 第{attempt+1}次扫码超时，正在生成新二维码...") # 清理旧文件，避免缓存 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("登录失败，请检查网络或手动扫码")

这里enableCmdQR=2是关键参数：它让 itchat 放弃调用系统图片查看器，转而把二维码以ASCII字符形式打印在终端里。哪怕你SSH连着一台无GUI的树莓派，也能用手机对着终端屏幕扫码。而picDir=qr_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, isFriendChat=True) def handle_friend_msg(msg): sender = msg['FromUserName'] text = msg['Text'].strip() # 规则匹配逻辑... reply = match_rule(text, 'friend', sender) itchat.send(reply, toUserName=sender) # 群聊消息：必须解析 ActualUserName @itchat.msg_register(itchat.content.TEXT, isGroupChat=True) 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, toUserName=group_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', encoding='utf-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'], toUserName=user_id) elif 'location' in rule: itchat.send_location( rule['location']['lat'], rule['location']['lng'], title='公司地址', toUserName=user_id ) return reply return None # 无匹配，返回空

这个设计带来了三个实际好处：第一，运营同事可以直接编辑rules.json增删关键词，无需碰Python代码；第二，不同客户可以共用同一套脚本，只需切换rules.json文件；第三，规则本身成了可审计的对象——每次修改都有Git历史，谁在什么时候加了什么规则，一目了然。

4. 实操过程与核心环节实现：手把手带你跑通第一个自动回复

4.1 环境准备与依赖安装：避开Python版本与SSL证书的双重坑

虽然requirements.txt只有一行itchat==1.4.42，但实际部署时，90%的问题都出在环境层面。我用的是Python 3.9.16（推荐，3.10+在某些CentOS上会有SSL握手失败），安装命令必须带参数：

# 不要直接 pip install itchat！ pip install itchat==1.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.txt

Step 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()反编译过它的结构，核心字段如下：

真正需要保护的是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, isGroupChat=True) def forward_alert(msg): group_name = itchat.search_chatrooms(userName=msg['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(remarkName=target_remark) if targets: # 构造转发消息：[来源群][原始消息] forward_text = f"[{group_name}] {text}" itchat.send(forward_text, toUserName=targets[0]['UserName']) print(f"✅ 已转发告警至 {target_remark}")

这个脚本的优势在于：零配置、零学习成本、启动即用。你只需要改MONITOR_GROUPS和FORWARD_TO两个列表，就能立刻上线一个告警转发器。它不处理私聊，不保存历史，不写日志，就是一个纯粹的“消息管道”。我在公司内部用它跑了半年，平均每天转发37条告警，从未漏过一次——因为逻辑越简单，就越可靠。

5. 常见问题与排查技巧实录：那些文档里不会写的实战经验

5.1 经典问题速查表

5.2 我踩过的五个深坑及独家修复技巧

坑1：微信服务端主动踢下线，脚本静默死亡
现象：脚本运行几天后，突然不再回复，但进程仍在，日志无报错。
真相：微信网页版有心跳保活机制，itchat默认30秒发一次webwxstatusnotify，但某些网络环境下（如NAT穿透），心跳包丢失，服务端认为客户端离线，主动销毁会话。
修复技巧：在主循环里加心跳守护线程：

import threading import time def keep_alive(): while True: try: itchat.send(' ', toUserName='filehelper') # 发空消息到文件传输助手，强制刷新心跳 except: pass time.sleep(25) # 比30秒略短，确保覆盖 # 启动守护线程 threading.Thread(target=keep_alive, daemon=True).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 = '未知用户'

坑3：requirements.txt安装后仍报ModuleNotFoundError
现象：明明pip install -r requirements.txt成功，运行时却说No module named 'itchat'。
真相：你可能在虚拟环境里安装，但用系统Python运行脚本，或反之。
修复技巧：统一环境，用绝对路径启动：

# 查看当前Python路径 which python # 查看itchat安装位置 python -c "import itchat; print(itchat.__file__)" # 确保两者在同一目录树下

坑4：robot2号.py转发时提示“对方开启了朋友验证”
现象：转发消息给新同事，但失败，日志显示{'BaseResponse': {'Ret': -1, 'ErrMsg': ''}}。
真相：对方未把你加为好友，或设置了“加我为朋友时需要验证”。
修复技巧：预检好友关系：

def safe_send(to_user, text): try: itchat.send(text, toUserName=to_user) except Exception as e: if 'verify' in str(e).lower(): print(f"⚠️ 无法发送给 {to_user}：对方未通过好友验证") else: raise e

坑5：itchat.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( level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s', handlers=[ logging.FileHandler('wechat.log', encoding='utf-8'), logging.StreamHandler() # 同时输出到终端 ] ) # 记录每条消息 def log_message(msg, direction='IN'): if msg['MsgType'] == 1: # 文本消息 sender = get_sender_name(msg) logging.info(f"{direction} [{sender}]: {msg['Text'][:50]}") # 在消息回调里调用 @itchat.msg_register(itchat.content.TEXT, isFriendChat=True) 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默认不保存聊天记录，但加上几行代码，就能构建一个轻量级本地数据库。我用的是sqlite3（Python内置，无需额外安装）：

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_incoming=True): 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, isFriendChat=True) def handle_friend_msg(msg): save_message(msg, is_incoming=True) reply = ... save_message({'Text': reply, 'FromUserName': msg['FromUserName']}, is_incoming=False)

有了这个表，你可以随时用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号自动运行的脚本，用cron（Linux）或任务计划程序（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基础就能看懂、改功能、加新规则。

本文还有配套的精品资源，点击获取