微信电脑版每天挂着消息一条接一条弹出来客户问价、朋友闲聊、群里你手动回根本忙不过来。我做过一段时间私域运营手上同时管着好几个微信号最崩溃的就是晚上十一点还有人发在吗第二天早上看到已经凉了。后来琢磨着用 Python 配合 pywinauto 做了一套桌面端自动化方案把重复性的回复、收款确认、定时群发这些活儿全交给脚本跑。这篇文章就把我踩过的坑、调过的参数、以及最终稳定运行的方案完整拆一遍适合有一点 Python 基础、想让电脑端微信自己动起来的同学参考。1. 为什么选 pywinauto 而不是其他方案1.1 桌面端自动化的三条技术路线对比想让微信自动干活市面上能走的路其实就三条一是走微信官方接口二是走网页版协议三是走桌面 UI 自动化。我一开始也想走接口但个人微信号根本没有开放的消息收发接口企业微信倒是有可那又是另一套东西了。网页版协议前几年还能用后来限制越来越严新注册的号基本登不上网页版这条路对大多数人已经堵死。剩下的就是桌面 UI 自动化。这块又分几个库pyautogui 靠屏幕坐标点击appium 主打移动端playwright 偏浏览器而 pywinauto 是专门针对 Windows 桌面程序的。微信电脑版本质上就是一个 Windows 窗口程序它的每一个按钮、每一个列表、每一个输入框在系统层面都是一个可识别的控件pywinauto 能直接拿到这些控件的句柄去操作不用去猜坐标。这就是我最终选 pywinauto 的核心理由基于控件而不是基于坐标。坐标点击最怕的就是窗口位置变了、分辨率变了、微信更新了界面布局脚本立刻报废。而控件操作只要控件的类名和层级没大改脚本就能一直跑。方案原理稳定性上手难度适用场景官方接口调用开放 API高中企业微信、公众号网页协议模拟 HTTP 请求低限制严高已基本不可用坐标点击屏幕像素定位低低简单固定界面pywinauto控件句柄操作中高中微信电脑版1.2 pywinauto 的两种操作模式backend 怎么选pywinauto 有两套 backendwin32 和 uia。这个选择非常关键选错了后面全是坑。win32 backend 用的是老的 Win32 API速度快但对现代 UI 框架支持不好。uia backend 走的是 UI Automation 接口能识别更复杂的控件树微信电脑版这种用自绘控件比较多的程序必须用 uia 才能拿到完整的控件信息。我实测下来微信主窗口、聊天列表、消息输入框这些用 uia 都能正常识别。所以启动的时候要这样写from pywinauto.application import Application app Application(backenduia).connect(pathWeChat.exe)注意connect 是连接已经打开的微信start 是重新启动一个。日常用 connect 就行别让脚本去启动微信否则容易起多个实例。1.3 先搞清楚微信的控件树长什么样在写任何自动化代码之前第一步永远是把控件树打印出来看。pywinauto 提供了 print_control_identifiers() 方法能把当前窗口下所有能识别到的控件、类名、层级全部列出来。dlg app.window(class_nameWeChatMainWndForPC) dlg.print_control_identifiers()这一步的输出会非常长但它是后面所有操作的地图。你会看到类似这样的结构主窗口下面有会话列表SessionList、聊天消息区ChatContactList、输入框Edit、发送按钮Button等等。每个控件都有 auto_id、class_name、control_type 这些属性后面定位就靠它们。我建议把这个输出保存到文件里边写代码边对照比反复打印省事得多。2. 环境搭建与基础封装2.1 Python 环境与依赖安装Python 版本我推荐 3.9 到 3.11太新的版本有时候 pywinauto 的依赖会跟不上。安装就两条命令pip install pywinauto pip install comtypescomtypes 是 uia backend 的底层依赖不装的话 uia 模式起不来。另外如果你要做定时任务还需要 apschedulerpip install apscheduler至于 Python 本身的安装网上教程一大堆记住装的时候勾选Add Python to PATH就行不然后面命令行里敲 python 会提示找不到命令。2.2 把常用操作封装成函数直接在主逻辑里写一堆 dlg.child_window(...) 会非常乱而且微信控件路径又长又容易变。我的做法是先把高频操作封装成独立函数主逻辑只调用函数名这样以后控件变了只需要改一处。核心要封装的几个动作获取主窗口、切换会话、读取未读消息、发送文本、发送文件。下面这个获取主窗口的函数是所有操作的入口def get_wechat_window(): app Application(backenduia).connect(pathWeChat.exe) dlg app.window(class_nameWeChatMainWndForPC) dlg.set_focus() return dlgset_focus() 这行别省微信窗口如果被最小化或者被其他窗口挡住控件虽然还在但操作可能失败先把它激活到前台最稳。2.3 会话切换的定位技巧微信左侧的会话列表是一个 List 控件里面每一项是一个 ListItem。要点击某个联系人可以用联系人名字去匹配def open_chat(dlg, contact_name): session_list dlg.child_window(control_typeList, title会话) target session_list.child_window(titlecontact_name, control_typeListItem) target.click_input()这里有个坑联系人名字必须完全匹配包括备注名。如果你给某人设了备注列表里显示的是备注不是昵称。另外如果这个联系人当前不在可见的会话列表里被折叠或者需要滚动直接 child_window 会找不到得先滚动列表或者用搜索框搜。我一般用搜索框更保险点搜索框、输入名字、等结果出来、点第一个结果。虽然多几步但不管联系人在不在列表里都能找到。3. 自动回复功能的完整实现3.1 消息监听的核心思路自动回复的前提是能知道有新消息。pywinauto 本身没有消息推送机制只能靠轮询。思路很简单每隔几秒去读一次会话列表看有没有带未读红点的会话。微信会话列表里有未读消息的项会带一个未读计数这个信息在控件的属性里能拿到。我实测下来比较可靠的方式是遍历会话列表的所有 ListItem检查它的名字或者某个子控件里有没有数字标记。def scan_unread(dlg): session_list dlg.child_window(control_typeList, title会话) unread [] for item in session_list.items(): name item.window_text() # 检查未读标记具体属性名以实际控件树为准 if has_unread_mark(item): unread.append(name) return unread轮询间隔我设的是 3 秒。太短了 CPU 占用高太长了回复不及时。3 秒是个平衡点实测下来体验比较自然。3.2 关键词匹配与回复策略监听到未读消息后要打开会话读内容然后根据内容决定回什么。这里我设计了一个简单的规则表REPLY_RULES { 价格: 您好具体价格请查看商品详情页有疑问随时问我~, 在吗: 在的请问有什么可以帮您, 发货: 一般下单后48小时内发出请留意物流信息。, 退款: 退款请提供订单号我这边帮您处理。, }匹配逻辑就是遍历规则看消息内容里有没有关键词。这里要注意优先级如果一条消息同时包含价格和退款得决定先匹配哪个。我的做法是把规则做成有序列表从上往下匹配命中就停。提示关键词匹配很容易误触发。比如客户说这个价格太贵了不买了你回一句价格详情就很尴尬。所以我在规则里加了一些否定词过滤命中否定词就不自动回转人工。3.3 发送消息的两种方式发送文本有两种方式一是往输入框里 set_text 然后点发送按钮二是用键盘模拟输入再回车。set_text 快但对某些特殊字符支持不好键盘模拟慢一点但更接近真人操作。def send_message(dlg, text): edit dlg.child_window(control_typeEdit) edit.set_focus() edit.set_text(text) # 方式一点发送按钮 send_btn dlg.child_window(title发送, control_typeButton) send_btn.click_input()我实际用的是 set_text 加发送按钮的组合稳定且快。但有个细节set_text 之后有时候输入框内容没刷新直接点发送会发出空消息。稳妥的做法是 set_text 之后 sleep 0.3 秒再点发送。3.4 防止回复死循环自动回复最怕的就是两个机器人互相回。如果对方也开了自动回复你回一句它回一句能刷屏刷到天亮。我的防护措施有三层一是同一个联系人短时间内只自动回一次二是回复内容里带一个隐藏标记检测到对方消息里有这个标记就不回三是设置一个全局回复频率上限比如每分钟最多回 10 条。import time last_reply {} def can_reply(contact, cooldown60): now time.time() if contact in last_reply and now - last_reply[contact] cooldown: return False last_reply[contact] now return True这个 cooldown 我设的是 60 秒也就是同一个人一分钟内只自动回一次剩下的交给人工。4. 收款确认与定时发消息4.1 收款消息的识别与确认微信收款到账时聊天里会出现一条转账或收款的消息。要自动确认收款得先能识别出这类消息。转账消息在聊天记录里通常是一个特殊的卡片控件control_type 和普通文本消息不一样。我的做法是读取聊天区最后几条消息检查有没有转账卡片。识别到之后卡片上会有一个确认收款或者接收的按钮点它就完成收款。def check_transfer(dlg): msg_list dlg.child_window(control_typeList, title消息) last_msgs msg_list.items()[-5:] for msg in last_msgs: # 查找转账卡片上的接收按钮 btn msg.child_window(title接收, control_typeButton) if btn.exists(): btn.click_input() return True return False注意收款操作涉及资金脚本一定要加日志每一笔确认收款都记录时间、联系人、金额如果能读到。出问题的时候有据可查。4.2 定时发消息的实现定时发消息用 apscheduler 最省事。可以设定固定时间点发也可以设定间隔发。比如每天早上 9 点给客户群发一条问候from apscheduler.schedulers.background import BackgroundScheduler scheduler BackgroundScheduler() def morning_greeting(): dlg get_wechat_window() open_chat(dlg, 客户群) send_message(dlg, 早上好今天有新品上架欢迎咨询~) scheduler.add_job(morning_greeting, cron, hour9, minute0) scheduler.start()cron 表达式和 Linux 的 crontab 一样hour9, minute0 就是每天 9 点整。如果要工作日才发可以加 day_of_weekmon-fri。4.3 群发时的注意事项群发最容易出问题。一是频率太高容易被限制二是发错群很尴尬。我的经验是群发间隔至少 5 秒一次群发不超过 20 个会话发之前先打印一遍目标列表人工确认。另外群发内容里不要带明显的营销词和链接纯文本最安全。图片和文件群发失败率比文本高重要内容建议文本加一句详情私聊。5. 常见问题与排查实录5.1 控件找不到怎么办这是最高频的问题。报错通常是 ElementNotFoundError。排查顺序第一确认微信窗口是不是在前台被遮挡会导致控件不可见第二重新 print_control_identifiers 看控件路径有没有变第三检查是不是微信更新了版本改了控件结构。我遇到过微信更新后输入框的 control_type 从 Edit 变成了 Document脚本直接挂掉。所以微信不要开自动更新锁定一个稳定版本等确认新版本控件没大改再升。5.2 脚本跑着跑着就卡住多半是某个 click_input 点到了弹窗上或者微信弹了个什么提示框挡住了主窗口。解决办法是在关键操作前加一个检查看有没有意外的对话框有就关掉。另外给每个操作加超时别让它无限等。try: target.click_input() except Exception as e: print(f操作失败: {e}) # 记录并跳过不要让整个脚本崩掉5.3 常见问题速查表问题现象可能原因解决办法ElementNotFoundError窗口未激活/控件路径变先 set_focus重打印控件树发出空消息set_text 未刷新set_text 后 sleep 0.3s回复死循环双方都自动回复加冷却时间和标记检测脚本卡死弹窗遮挡操作前检查并关闭弹窗群发被限制频率过高间隔 5s 以上控制数量收款漏确认消息滚动出视野定期扫描最近消息5.4 几个我踩过的坑第一个坑是多开微信。如果你电脑上开了多个微信实例connect 的时候可能连到错误的那个。解决办法是用 process 参数指定 PID或者干脆只开一个。第二个坑是输入法。用键盘模拟输入的时候如果当前是中文输入法输入的字母会变成候选词。set_text 不受影响但如果你用 type_keys 就要先把输入法切到英文。第三个坑是分辨率缩放。Windows 的显示缩放如果不是 100%控件的坐标计算会偏。建议脚本运行的机器把缩放设成 100%。第四个坑是微信锁屏。微信电脑版可以设置离开后自动锁定锁定状态下所有控件都操作不了。要么关掉这个设置要么在脚本里检测锁定状态并解锁。6. 稳定性优化与长期运行建议6.1 加日志和异常恢复脚本要长期跑日志是必须的。我用 logging 模块把每个关键动作都记下来包括时间、操作类型、目标、结果。出问题的时候翻日志比盯着屏幕强一百倍。import logging logging.basicConfig( filenamewechat_assistant.log, levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s )异常恢复的思路是任何一步失败都不要让整个脚本退出捕获异常、记录、然后继续下一轮循环。主循环用 while True 包起来里面套 try except。6.2 用配置文件管理规则回复规则、定时任务、群发名单这些不要写死在代码里放到一个 config.json 或者 yaml 文件里。这样改规则不用动代码重启脚本就生效。{ reply_rules: [ {keyword: 价格, reply: 您好价格请查看详情页~}, {keyword: 在吗, reply: 在的请问有什么可以帮您} ], cooldown: 60, scan_interval: 3 }6.3 关于合规使用的提醒最后说几句实在话。自动化工具是提效的不是用来骚扰别人的。自动回复要克制别把每个联系人都当机器人刷群发要节制别一天发八遍收款确认要谨慎涉及钱的逻辑一定要人工复核兜底。我个人的原则是自动化只处理重复的、标准化的、低风险的环节涉及判断和资金的环节永远留人工入口。这样既省了力气又不会出大乱子。这套方案我断断续续跑了小半年中间因为微信更新修过几次控件路径整体还算稳。真正花时间的不是写代码而是摸清控件树和调各种边界情况。如果你也想动手建议先从最简单的读取未读消息并打印开始跑通了再一步步加功能别一上来就想着全自动那样只会被各种报错劝退。
Python + pywinauto 实现微信电脑版自动化：自动回复、收款确认与定时群发
微信电脑版每天挂着消息一条接一条弹出来客户问价、朋友闲聊、群里你手动回根本忙不过来。我做过一段时间私域运营手上同时管着好几个微信号最崩溃的就是晚上十一点还有人发在吗第二天早上看到已经凉了。后来琢磨着用 Python 配合 pywinauto 做了一套桌面端自动化方案把重复性的回复、收款确认、定时群发这些活儿全交给脚本跑。这篇文章就把我踩过的坑、调过的参数、以及最终稳定运行的方案完整拆一遍适合有一点 Python 基础、想让电脑端微信自己动起来的同学参考。1. 为什么选 pywinauto 而不是其他方案1.1 桌面端自动化的三条技术路线对比想让微信自动干活市面上能走的路其实就三条一是走微信官方接口二是走网页版协议三是走桌面 UI 自动化。我一开始也想走接口但个人微信号根本没有开放的消息收发接口企业微信倒是有可那又是另一套东西了。网页版协议前几年还能用后来限制越来越严新注册的号基本登不上网页版这条路对大多数人已经堵死。剩下的就是桌面 UI 自动化。这块又分几个库pyautogui 靠屏幕坐标点击appium 主打移动端playwright 偏浏览器而 pywinauto 是专门针对 Windows 桌面程序的。微信电脑版本质上就是一个 Windows 窗口程序它的每一个按钮、每一个列表、每一个输入框在系统层面都是一个可识别的控件pywinauto 能直接拿到这些控件的句柄去操作不用去猜坐标。这就是我最终选 pywinauto 的核心理由基于控件而不是基于坐标。坐标点击最怕的就是窗口位置变了、分辨率变了、微信更新了界面布局脚本立刻报废。而控件操作只要控件的类名和层级没大改脚本就能一直跑。方案原理稳定性上手难度适用场景官方接口调用开放 API高中企业微信、公众号网页协议模拟 HTTP 请求低限制严高已基本不可用坐标点击屏幕像素定位低低简单固定界面pywinauto控件句柄操作中高中微信电脑版1.2 pywinauto 的两种操作模式backend 怎么选pywinauto 有两套 backendwin32 和 uia。这个选择非常关键选错了后面全是坑。win32 backend 用的是老的 Win32 API速度快但对现代 UI 框架支持不好。uia backend 走的是 UI Automation 接口能识别更复杂的控件树微信电脑版这种用自绘控件比较多的程序必须用 uia 才能拿到完整的控件信息。我实测下来微信主窗口、聊天列表、消息输入框这些用 uia 都能正常识别。所以启动的时候要这样写from pywinauto.application import Application app Application(backenduia).connect(pathWeChat.exe)注意connect 是连接已经打开的微信start 是重新启动一个。日常用 connect 就行别让脚本去启动微信否则容易起多个实例。1.3 先搞清楚微信的控件树长什么样在写任何自动化代码之前第一步永远是把控件树打印出来看。pywinauto 提供了 print_control_identifiers() 方法能把当前窗口下所有能识别到的控件、类名、层级全部列出来。dlg app.window(class_nameWeChatMainWndForPC) dlg.print_control_identifiers()这一步的输出会非常长但它是后面所有操作的地图。你会看到类似这样的结构主窗口下面有会话列表SessionList、聊天消息区ChatContactList、输入框Edit、发送按钮Button等等。每个控件都有 auto_id、class_name、control_type 这些属性后面定位就靠它们。我建议把这个输出保存到文件里边写代码边对照比反复打印省事得多。2. 环境搭建与基础封装2.1 Python 环境与依赖安装Python 版本我推荐 3.9 到 3.11太新的版本有时候 pywinauto 的依赖会跟不上。安装就两条命令pip install pywinauto pip install comtypescomtypes 是 uia backend 的底层依赖不装的话 uia 模式起不来。另外如果你要做定时任务还需要 apschedulerpip install apscheduler至于 Python 本身的安装网上教程一大堆记住装的时候勾选Add Python to PATH就行不然后面命令行里敲 python 会提示找不到命令。2.2 把常用操作封装成函数直接在主逻辑里写一堆 dlg.child_window(...) 会非常乱而且微信控件路径又长又容易变。我的做法是先把高频操作封装成独立函数主逻辑只调用函数名这样以后控件变了只需要改一处。核心要封装的几个动作获取主窗口、切换会话、读取未读消息、发送文本、发送文件。下面这个获取主窗口的函数是所有操作的入口def get_wechat_window(): app Application(backenduia).connect(pathWeChat.exe) dlg app.window(class_nameWeChatMainWndForPC) dlg.set_focus() return dlgset_focus() 这行别省微信窗口如果被最小化或者被其他窗口挡住控件虽然还在但操作可能失败先把它激活到前台最稳。2.3 会话切换的定位技巧微信左侧的会话列表是一个 List 控件里面每一项是一个 ListItem。要点击某个联系人可以用联系人名字去匹配def open_chat(dlg, contact_name): session_list dlg.child_window(control_typeList, title会话) target session_list.child_window(titlecontact_name, control_typeListItem) target.click_input()这里有个坑联系人名字必须完全匹配包括备注名。如果你给某人设了备注列表里显示的是备注不是昵称。另外如果这个联系人当前不在可见的会话列表里被折叠或者需要滚动直接 child_window 会找不到得先滚动列表或者用搜索框搜。我一般用搜索框更保险点搜索框、输入名字、等结果出来、点第一个结果。虽然多几步但不管联系人在不在列表里都能找到。3. 自动回复功能的完整实现3.1 消息监听的核心思路自动回复的前提是能知道有新消息。pywinauto 本身没有消息推送机制只能靠轮询。思路很简单每隔几秒去读一次会话列表看有没有带未读红点的会话。微信会话列表里有未读消息的项会带一个未读计数这个信息在控件的属性里能拿到。我实测下来比较可靠的方式是遍历会话列表的所有 ListItem检查它的名字或者某个子控件里有没有数字标记。def scan_unread(dlg): session_list dlg.child_window(control_typeList, title会话) unread [] for item in session_list.items(): name item.window_text() # 检查未读标记具体属性名以实际控件树为准 if has_unread_mark(item): unread.append(name) return unread轮询间隔我设的是 3 秒。太短了 CPU 占用高太长了回复不及时。3 秒是个平衡点实测下来体验比较自然。3.2 关键词匹配与回复策略监听到未读消息后要打开会话读内容然后根据内容决定回什么。这里我设计了一个简单的规则表REPLY_RULES { 价格: 您好具体价格请查看商品详情页有疑问随时问我~, 在吗: 在的请问有什么可以帮您, 发货: 一般下单后48小时内发出请留意物流信息。, 退款: 退款请提供订单号我这边帮您处理。, }匹配逻辑就是遍历规则看消息内容里有没有关键词。这里要注意优先级如果一条消息同时包含价格和退款得决定先匹配哪个。我的做法是把规则做成有序列表从上往下匹配命中就停。提示关键词匹配很容易误触发。比如客户说这个价格太贵了不买了你回一句价格详情就很尴尬。所以我在规则里加了一些否定词过滤命中否定词就不自动回转人工。3.3 发送消息的两种方式发送文本有两种方式一是往输入框里 set_text 然后点发送按钮二是用键盘模拟输入再回车。set_text 快但对某些特殊字符支持不好键盘模拟慢一点但更接近真人操作。def send_message(dlg, text): edit dlg.child_window(control_typeEdit) edit.set_focus() edit.set_text(text) # 方式一点发送按钮 send_btn dlg.child_window(title发送, control_typeButton) send_btn.click_input()我实际用的是 set_text 加发送按钮的组合稳定且快。但有个细节set_text 之后有时候输入框内容没刷新直接点发送会发出空消息。稳妥的做法是 set_text 之后 sleep 0.3 秒再点发送。3.4 防止回复死循环自动回复最怕的就是两个机器人互相回。如果对方也开了自动回复你回一句它回一句能刷屏刷到天亮。我的防护措施有三层一是同一个联系人短时间内只自动回一次二是回复内容里带一个隐藏标记检测到对方消息里有这个标记就不回三是设置一个全局回复频率上限比如每分钟最多回 10 条。import time last_reply {} def can_reply(contact, cooldown60): now time.time() if contact in last_reply and now - last_reply[contact] cooldown: return False last_reply[contact] now return True这个 cooldown 我设的是 60 秒也就是同一个人一分钟内只自动回一次剩下的交给人工。4. 收款确认与定时发消息4.1 收款消息的识别与确认微信收款到账时聊天里会出现一条转账或收款的消息。要自动确认收款得先能识别出这类消息。转账消息在聊天记录里通常是一个特殊的卡片控件control_type 和普通文本消息不一样。我的做法是读取聊天区最后几条消息检查有没有转账卡片。识别到之后卡片上会有一个确认收款或者接收的按钮点它就完成收款。def check_transfer(dlg): msg_list dlg.child_window(control_typeList, title消息) last_msgs msg_list.items()[-5:] for msg in last_msgs: # 查找转账卡片上的接收按钮 btn msg.child_window(title接收, control_typeButton) if btn.exists(): btn.click_input() return True return False注意收款操作涉及资金脚本一定要加日志每一笔确认收款都记录时间、联系人、金额如果能读到。出问题的时候有据可查。4.2 定时发消息的实现定时发消息用 apscheduler 最省事。可以设定固定时间点发也可以设定间隔发。比如每天早上 9 点给客户群发一条问候from apscheduler.schedulers.background import BackgroundScheduler scheduler BackgroundScheduler() def morning_greeting(): dlg get_wechat_window() open_chat(dlg, 客户群) send_message(dlg, 早上好今天有新品上架欢迎咨询~) scheduler.add_job(morning_greeting, cron, hour9, minute0) scheduler.start()cron 表达式和 Linux 的 crontab 一样hour9, minute0 就是每天 9 点整。如果要工作日才发可以加 day_of_weekmon-fri。4.3 群发时的注意事项群发最容易出问题。一是频率太高容易被限制二是发错群很尴尬。我的经验是群发间隔至少 5 秒一次群发不超过 20 个会话发之前先打印一遍目标列表人工确认。另外群发内容里不要带明显的营销词和链接纯文本最安全。图片和文件群发失败率比文本高重要内容建议文本加一句详情私聊。5. 常见问题与排查实录5.1 控件找不到怎么办这是最高频的问题。报错通常是 ElementNotFoundError。排查顺序第一确认微信窗口是不是在前台被遮挡会导致控件不可见第二重新 print_control_identifiers 看控件路径有没有变第三检查是不是微信更新了版本改了控件结构。我遇到过微信更新后输入框的 control_type 从 Edit 变成了 Document脚本直接挂掉。所以微信不要开自动更新锁定一个稳定版本等确认新版本控件没大改再升。5.2 脚本跑着跑着就卡住多半是某个 click_input 点到了弹窗上或者微信弹了个什么提示框挡住了主窗口。解决办法是在关键操作前加一个检查看有没有意外的对话框有就关掉。另外给每个操作加超时别让它无限等。try: target.click_input() except Exception as e: print(f操作失败: {e}) # 记录并跳过不要让整个脚本崩掉5.3 常见问题速查表问题现象可能原因解决办法ElementNotFoundError窗口未激活/控件路径变先 set_focus重打印控件树发出空消息set_text 未刷新set_text 后 sleep 0.3s回复死循环双方都自动回复加冷却时间和标记检测脚本卡死弹窗遮挡操作前检查并关闭弹窗群发被限制频率过高间隔 5s 以上控制数量收款漏确认消息滚动出视野定期扫描最近消息5.4 几个我踩过的坑第一个坑是多开微信。如果你电脑上开了多个微信实例connect 的时候可能连到错误的那个。解决办法是用 process 参数指定 PID或者干脆只开一个。第二个坑是输入法。用键盘模拟输入的时候如果当前是中文输入法输入的字母会变成候选词。set_text 不受影响但如果你用 type_keys 就要先把输入法切到英文。第三个坑是分辨率缩放。Windows 的显示缩放如果不是 100%控件的坐标计算会偏。建议脚本运行的机器把缩放设成 100%。第四个坑是微信锁屏。微信电脑版可以设置离开后自动锁定锁定状态下所有控件都操作不了。要么关掉这个设置要么在脚本里检测锁定状态并解锁。6. 稳定性优化与长期运行建议6.1 加日志和异常恢复脚本要长期跑日志是必须的。我用 logging 模块把每个关键动作都记下来包括时间、操作类型、目标、结果。出问题的时候翻日志比盯着屏幕强一百倍。import logging logging.basicConfig( filenamewechat_assistant.log, levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s )异常恢复的思路是任何一步失败都不要让整个脚本退出捕获异常、记录、然后继续下一轮循环。主循环用 while True 包起来里面套 try except。6.2 用配置文件管理规则回复规则、定时任务、群发名单这些不要写死在代码里放到一个 config.json 或者 yaml 文件里。这样改规则不用动代码重启脚本就生效。{ reply_rules: [ {keyword: 价格, reply: 您好价格请查看详情页~}, {keyword: 在吗, reply: 在的请问有什么可以帮您} ], cooldown: 60, scan_interval: 3 }6.3 关于合规使用的提醒最后说几句实在话。自动化工具是提效的不是用来骚扰别人的。自动回复要克制别把每个联系人都当机器人刷群发要节制别一天发八遍收款确认要谨慎涉及钱的逻辑一定要人工复核兜底。我个人的原则是自动化只处理重复的、标准化的、低风险的环节涉及判断和资金的环节永远留人工入口。这样既省了力气又不会出大乱子。这套方案我断断续续跑了小半年中间因为微信更新修过几次控件路径整体还算稳。真正花时间的不是写代码而是摸清控件树和调各种边界情况。如果你也想动手建议先从最简单的读取未读消息并打印开始跑通了再一步步加功能别一上来就想着全自动那样只会被各种报错劝退。
