简介这是面向电商商家和开发者的闲鱼自动发货系统基于Python 3.7与asyncio异步架构通过闲鱼API实现虚拟商品自动发货、消息自定义回复并可接入ChatGPT、文心一言等大语言模型进行智能问答适用于批量处理闲鱼交易的高频场景。压缩包共27个文件约751KB包含9个Python核心源码文件、3个前端JavaScript脚本以及配置文件、日志、说明文档等辅助材料结构完整便于二次开发。系统内置错误重试与超时机制支持通过global_config.yml灵活配置能适应不同虚拟商品的自动交易需求。目前已有1248人学习源码附有配置说明和API接口文档可直接部署运行亦可作为学习异步编程和电商自动化的参考实例。 做闲鱼虚拟商品交易的朋友十有八九都遇到过这个问题半夜睡得正香买家拍下商品等不到自动回复第二天就申请退款白天忙工作一不留神有人拍了自动发货的商品结果卡密迟迟发不出去买家直接差评。我卖的是软件授权码和资料包一开始全靠手动复制粘贴后来实在顶不住干脆自己写了这套闲鱼自动发货系统跑到现在小半年漏单率降到接近零库存也没再乱过。这篇文章不聊虚的直接拆解这套可运行源码的完整设计思路、核心模块、实操步骤以及我调这套系统时踩过的各种坑。不管你只是想找一套能用的发货工具还是想学桌面自动化、图像识别和状态机设计都能从里面拿到可以直接抄作业的东西。1. 项目全貌这套系统到底在解决什么问题1.1 闲鱼虚拟商品交易的核心痛点先说交易链路。闲鱼上的虚拟商品比如软件授权码、网盘资料、课程账号、会员卡密买家拍下付款后卖家需要把货物通过聊天窗口发给买家。这个环节听起来简单做起来全是问题。第一个问题是时效性。虚拟商品买家普遍没有耐心你说稍等他转头就去别家拍了。凌晨的单子、午休的单子、节假日的大单你不可能24小时盯着手机。第二个问题是重复发货。人工记录不严谨的时候同一张卡密发了两次或者A商品的卡密发给了B买家售后够你喝一壶。第三个问题是库存管理。卡密池有1000条卖掉多少、还剩多少、哪些失效了Excel表格管理很容易乱。我做的这套系统本质就是把人盯着聊天窗口、手动发卡这件事变成程序盯着聊天窗口、自动发卡、自动记录库存。它解决的不仅是效率更是虚拟交易当中最容易出错的那几个环节。1.2 系统的整体设计思路一个订单状态机整个系统的核心逻辑我总结下来就一句话把发货流程抽象成一个状态机程序循环判断当前订单处于哪个状态然后执行对应的动作。这里先画一个逻辑链路监控窗口里有没有新消息/新订单→ 识别这条消息的买家是谁、拍了什么商品、是否已付款→ 校验这个订单是否已经发过货→ 发货从库存池取卡密拼接话术模拟发送→ 记录写出订单流水扣减库存。所有模块都围绕这个循环转。这么做的好处是程序不会因为某一个环节卡住就全盘崩溃哪个环节出问题都能单独排查。我在源码里把每一步都留了日志就是因为一开始测试的时候经常不知道系统到底卡在哪一步后面才狠下心把状态流转全部打印出来。1.3 技术选型为什么是Python PC客户端 图像识别很多朋友一上来会问闲鱼不是有开放平台吗为什么不直接调API非要搞什么图像识别、模拟点击我实测下来的结论是闲鱼开放平台确实存在但面向个人卖家的订单能力非常有限尤其是聊天发消息这个核心动作根本没有对外开放的接口。想自动发货要么走违规的协议破解路线不建议碰账号风险极高要么走PC客户端操作模拟路线。后者虽然笨但是稳定而且不破坏平台规则更适合个人卖家小规模使用。技术栈上我选了Python 3.9 pyautogui鼠标键盘模拟 PaddleOCR文字识别 SQLite本地库存和订单存储。这个组合的好处是生态成熟出了问题网上能搜到大量解决方案。整套源码跑在Windows 10/11上不需要额外部署服务器一台普通家用电脑就能昼夜运行。下面章节我会把每个模块怎么写的、为什么这么写讲清楚。2. 核心模块拆解从订单到发货的完整链路2.1 订单与消息监控模块程序怎么知道有人拍下了这是整套系统最基础也最关键的模块。程序首先要能做到当买家发来消息、或者订单状态发生变化时及时感知到这个变化。闲鱼PC客户端本质是一个窗口程序我没办法直接读取它的内部数据所以我用的是轮询 窗口比对的方案。具体来说程序每间隔几秒截取一次客户端前台窗口的截图与上一轮截图做对比如果发现指定区域的画面发生了变化比如底部任务栏图标出现红色数字角标、聊天列表窗口的横幅出现新的会话就触发后续的身份识别与订单校验流程。这里有一个关键的设计细节轮询间隔不能太短否则CPU占用高而且极容易触发风控也不能太长否则买家等太久。我调试下来3到5秒是比较平衡的值。# 监控主循环简版 import time import pyautogui def watch_loop(region, interval4): last_img None while True: img pyautogui.screenshot(regionregion) if last_img is not None: diff compare_images(last_img, img) if diff threshold: handle_new_event(img) # 触发后续识别与发货流程 last_img img time.sleep(interval)2.2 卡密识别与自动回复模块怎么把货准确发出去监控模块发现窗口有变化接下来要回答三个问题是谁发的消息、拍的是什么商品、要不要发货。买家身份可以从聊天窗口顶部的昵称区域用OCR识别出来。商品识别稍微复杂一点我用的方案是维护一张商品关键词表把每个商品对应的关键词比如软件授权码、资料包配置进去然后对聊天内容做文字匹配。如果匹配上了再检查订单状态是不是已付款。发货动作本身是程序根据识别结果到对应商品的卡密池里取一条未使用的卡密拼接成一条完整话术再通过pyautogui模拟键盘输入和回车发送。话术模板我建议每个人都要反复打磨不要写得太机械化至少加一句亲感谢购买之类的话实测下来被投诉欺诈的概率会低不少。2.3 库存管理与防超卖设计同一个卡密不能发两次自动发货最容易翻车的地方不是识别不到而是同一个卡密卖了两份。我一开始用纯文本文件记录库存结果并发测试的时候直接把两条相同的卡密发给了两个不同买家。后来改成SQLite数据库才算彻底解决这个问题。数据库就三张表商品表product、卡密表card、订单表order。关键逻辑是发货的时候开启一个事务先从卡密表里查出状态为未使用的一条卡密立刻把状态改成已锁定然后再执行发送发送成功后再把状态改成已使用同时往订单表写入一条记录。这样即使程序中间异常退出也不会重复发同一个卡密。这里有个细节值得注意状态不能直接改成已使用因为发送有可能失败。发送失败以后卡密要回滚成未使用否则就会丢单。我是吃了一次亏才加上这个回滚逻辑。-- 取卡密时执行的核心SQL示意 SELECT id, code FROM card WHERE product_id ? AND status unused LIMIT 1;2.4 人工接管与异常告警系统不是万能的我一开始追求全自动但跑了三周就发现纯自动系统一定会有处理不了的情况。比如OCR识别置信度过低、卡密池见底、买家发来了非标准的售后话术。这种时候如果系统硬着头皮发很容易发错。所以我在系统里加了三级异常处理机制第一级识别置信度低于阈值自动重新截图识别一遍还不行就进入下一级第二级发货条件不满足比如库存不足系统暂停该订单的自动处理转入需人工接管列表同时通过钉钉机器人推送告警到手机第三级同一账号触发连续异常告警系统自动暂停该账号的所有自动发货避免造成更大问题。3. 实操环节把源码跑起来3.1 环境准备与依赖安装源码是跨机器的但建议部署到一台长期不关机的Windows电脑上。系统要求不高4GB内存、普通双核CPU就够跑。需要的环境是Python 3.9及以上然后安装几个依赖库。pip install pyautogui paddleocr paddlepaddle pillow numpy opencv-pythonPaddleOCR第一次运行会自动下载模型文件国内网络一般能正常拉取。如果下载慢可以手动把模型放到用户目录下的.paddlex文件夹里这个细节在运行日志里会有提示。除了Python依赖闲鱼PC客户端需要提前登录好并保持在前台或固定位置。我建议把窗口固定在屏幕左上角这样截图的region参数好写也不容易截错区域。3.2 配置文件说明改一遍就能用所有个性化参数都在config.ini里不用改代码就能适配不同卖家的商品和话术。配置项说明我的推荐值monitor_interval监控轮询间隔秒4confidence_thresholdOCR识别置信度阈值0.8keyword_map商品关键词与商品ID映射如授权码A001reply_template发货话术模板含{card_code}占位符card_file_path卡密文件路径每行一条enable_takeover是否开启人工接管模式true卡密文件的格式我建议遵循一行一条的规则不要带多余空格和符号。如果要区分多个商品就建多个txt文件在配置文件里分别指定路径。[monitor] interval 4 confidence 0.8 [product] keyword 软件授权码 card_file cards/software.txt reply_template 亲感谢购买您的授权码是{card_code}请妥善保管。3.3 核心代码逻辑讲解别看代码多核心就三块源码看起来文件不少但核心逻辑其实只有三块监听循环、发货函数、库存事务。这里我摘一段发货函数的核心逻辑做解析。def dispatch_card(order): # 1. 校验订单状态防止重复发货 if order_already_dispatched(order): log(该订单已发货跳过) return False # 2. 开启事务锁定一条卡密 conn get_db_connection() with conn.transaction(): card fetch_unused_card(order.product_id) if card is None: alert(库存不足需要人工补卡) return False mark_card_locked(card.id) # 3. 模拟发送消息到聊天窗口 send_text_to_client(build_reply(order, card.code)) # 4. 发送成功后更新卡密状态写入订单记录 mark_card_used(card.id) record_order(order, card.id) return True这段代码最有价值的地方在第三步和第四步之间有失败分支如果send_text_to_client中途抛异常卡密的状态还是locked下一轮循环中会有一个定时任务把超时未确认的locked卡密回滚为unused。这个细节一定要保留否则异常断电后库存就冻结了。3.4 话术与卡密格式的工程化设计很多人忽略话术的重要性。自动发货系统不只是技术问题话术设计直接关系到买家体验和平台风控。实测下来纯模板化的回复比如只发一串卡密容易被系统判定为机器行为进而限制账号的消息发送能力。我在模板里做了三类话术首次发货话术、补发话术、售后说明话术。首次发货话术长这样亲您拍的xx商品已经安排好啦以下是您的专属授权码xxxx-xxxx-xxxx请复制后到软件内激活。如有问题随时联系我哦。注意这里加了安排好啦模拟真人操作而且明确给出下一步操作指引能有效减少买家追问。4. 常见问题与排坑实录4.1 识别不准、漏单、错发怎么破这套系统最常被问到的就是识别不准确。我排查下来九成情况不是OCR模型的问题而是截图区域没对准。闲鱼PC端的界面在不同分辨率下布局会有差异如果你的显示器是2K、4K高分辨率建议把系统的显示缩放比先调回100%再运行否则截图的坐标全是偏的。漏单也有一个隐蔽原因买家拍下商品后没有立刻发消息系统没有触发窗口变化事件所以不会发货。解决思路是每隔5到10分钟主动截取一次订单列表区域把所有待发货状态的订单扫一遍发现漏发就补发。这个补扫订单机制我强烈建议加上。4.2 操作频率过高触发风控怎么办我第一天测试的时候把轮询间隔设成1秒跑了不到两小时闲鱼客户端就提示操作频繁需要重新验证。后面琢磨出来一个很土但有效的办法每次模拟操作之间加随机延迟。import random import time def human_delay(): time.sleep(random.uniform(0.8, 2.2))所有鼠标移动、点击、键盘输入之间都加上这个随机延迟模拟真人操作节奏。另外同一个账号单日发货量不要太大超过一定数量后即使系统自动发货速度很稳定也建议拆到第二天再继续。4.3 多商品多库存如何避免发错货一开始我只做单商品后来加了第二个商品之后发现偶尔会把B商品的卡密发给买了A商品的买家。排查下来是商品关键词匹配做成了包含逻辑而两个商品的关键词有重叠。解决办法是把匹配逻辑改成精确匹配 排除黑名单关键词。比如A商品关键词是软件AB商品关键词是软件B匹配软件时直接跳过必须匹配到完整关键词才发货。卡密文件也建议按商品分文件管理绝对不要把所有卡密堆在同一个txt里否则程序很难区分。4.4 日志与异常流水排查问题的钥匙这套系统我强烈建议开启完整日志。我自己就是把每一条操作、每一次识别、每一次发货的结果都记录到SQLite的一张日志表里字段包含时间戳、账号、买家昵称、商品ID、动作类型、结果、异常信息。时间买家昵称商品ID动作结果2024-06-01 02:13:45小明A001识别订单成功2024-06-01 02:13:52小明A001发送卡密成功2024-06-01 20:15:03老王A002识别订单置信度低转人工遇到问题不要瞎猜先看日志按时间轴把流程重放一遍十有八九能定位到具体环节。这也是我标题里敢写可运行源码的原因——日志齐全的源码才是真正可维护的源码。5. 进阶玩法与风险控制5.1 多账号管理与分仓逻辑如果你手里不止一个闲鱼账号先把账号和商品彻底分开。每个账号对应独立的配置目录里面配置独立的商品池、卡密池和日志库。这样做的原因是不同账号的商品类目、卡密池完全隔离一旦某个账号出问题不会连累其他账号。我目前是每个账号跑一个Python进程用supervisor之类的工具做进程守护进程崩溃后自动拉起。如果电脑配置比较低建议严格控制同时运行的进程数实测一台4核8GB的老笔记本同时跑3个账号CPU占用已经接近70%了。5.2 安全红线自动化的边界在哪里最后说几个我用这套系统总结出来的红线。第一不要做全自动无人值守再稳的系统也需要每天花几分钟看日志确认没有异常告警。第二不要在闲鱼客户端里跑与发货无关的自动化操作系统只做看消息、发卡密这两件事不要顺手做什么养号、刷浏览之类的事那是给自己挖坑。第三卡密池不要一次性导入太多尤其是从第三方渠道买的卡密一定要先小批量测试确认有效再导入正式库存否则一次性发出几百条失效卡密售后能把你压垮。这也是我一直强调自动发货系统只是帮你把速度提上去不代表你可以完全离线的原因。虚拟商品的售后问题比传统实物更复杂系统能保证发出去但发得对、发得好还是需要人工关注至少要有异常告警兜底。在这套系统的迭代过程中我最大的体会是写自动化的难处不在写代码而在梳理边界。一开始我总想让它处理所有情况后来发现边界定得越清楚系统越稳定。如果你准备复刻这套方案建议先拿一个低客单价的测试商品跑一个礼拜把监控间隔、话术模板、异常告警都调到顺手之后再切换到主力商品体验会好很多。本文还有配套的精品资源点击获取
闲鱼虚拟商品自动发货系统：Python+图像识别+状态机实战
简介这是面向电商商家和开发者的闲鱼自动发货系统基于Python 3.7与asyncio异步架构通过闲鱼API实现虚拟商品自动发货、消息自定义回复并可接入ChatGPT、文心一言等大语言模型进行智能问答适用于批量处理闲鱼交易的高频场景。压缩包共27个文件约751KB包含9个Python核心源码文件、3个前端JavaScript脚本以及配置文件、日志、说明文档等辅助材料结构完整便于二次开发。系统内置错误重试与超时机制支持通过global_config.yml灵活配置能适应不同虚拟商品的自动交易需求。目前已有1248人学习源码附有配置说明和API接口文档可直接部署运行亦可作为学习异步编程和电商自动化的参考实例。 做闲鱼虚拟商品交易的朋友十有八九都遇到过这个问题半夜睡得正香买家拍下商品等不到自动回复第二天就申请退款白天忙工作一不留神有人拍了自动发货的商品结果卡密迟迟发不出去买家直接差评。我卖的是软件授权码和资料包一开始全靠手动复制粘贴后来实在顶不住干脆自己写了这套闲鱼自动发货系统跑到现在小半年漏单率降到接近零库存也没再乱过。这篇文章不聊虚的直接拆解这套可运行源码的完整设计思路、核心模块、实操步骤以及我调这套系统时踩过的各种坑。不管你只是想找一套能用的发货工具还是想学桌面自动化、图像识别和状态机设计都能从里面拿到可以直接抄作业的东西。1. 项目全貌这套系统到底在解决什么问题1.1 闲鱼虚拟商品交易的核心痛点先说交易链路。闲鱼上的虚拟商品比如软件授权码、网盘资料、课程账号、会员卡密买家拍下付款后卖家需要把货物通过聊天窗口发给买家。这个环节听起来简单做起来全是问题。第一个问题是时效性。虚拟商品买家普遍没有耐心你说稍等他转头就去别家拍了。凌晨的单子、午休的单子、节假日的大单你不可能24小时盯着手机。第二个问题是重复发货。人工记录不严谨的时候同一张卡密发了两次或者A商品的卡密发给了B买家售后够你喝一壶。第三个问题是库存管理。卡密池有1000条卖掉多少、还剩多少、哪些失效了Excel表格管理很容易乱。我做的这套系统本质就是把人盯着聊天窗口、手动发卡这件事变成程序盯着聊天窗口、自动发卡、自动记录库存。它解决的不仅是效率更是虚拟交易当中最容易出错的那几个环节。1.2 系统的整体设计思路一个订单状态机整个系统的核心逻辑我总结下来就一句话把发货流程抽象成一个状态机程序循环判断当前订单处于哪个状态然后执行对应的动作。这里先画一个逻辑链路监控窗口里有没有新消息/新订单→ 识别这条消息的买家是谁、拍了什么商品、是否已付款→ 校验这个订单是否已经发过货→ 发货从库存池取卡密拼接话术模拟发送→ 记录写出订单流水扣减库存。所有模块都围绕这个循环转。这么做的好处是程序不会因为某一个环节卡住就全盘崩溃哪个环节出问题都能单独排查。我在源码里把每一步都留了日志就是因为一开始测试的时候经常不知道系统到底卡在哪一步后面才狠下心把状态流转全部打印出来。1.3 技术选型为什么是Python PC客户端 图像识别很多朋友一上来会问闲鱼不是有开放平台吗为什么不直接调API非要搞什么图像识别、模拟点击我实测下来的结论是闲鱼开放平台确实存在但面向个人卖家的订单能力非常有限尤其是聊天发消息这个核心动作根本没有对外开放的接口。想自动发货要么走违规的协议破解路线不建议碰账号风险极高要么走PC客户端操作模拟路线。后者虽然笨但是稳定而且不破坏平台规则更适合个人卖家小规模使用。技术栈上我选了Python 3.9 pyautogui鼠标键盘模拟 PaddleOCR文字识别 SQLite本地库存和订单存储。这个组合的好处是生态成熟出了问题网上能搜到大量解决方案。整套源码跑在Windows 10/11上不需要额外部署服务器一台普通家用电脑就能昼夜运行。下面章节我会把每个模块怎么写的、为什么这么写讲清楚。2. 核心模块拆解从订单到发货的完整链路2.1 订单与消息监控模块程序怎么知道有人拍下了这是整套系统最基础也最关键的模块。程序首先要能做到当买家发来消息、或者订单状态发生变化时及时感知到这个变化。闲鱼PC客户端本质是一个窗口程序我没办法直接读取它的内部数据所以我用的是轮询 窗口比对的方案。具体来说程序每间隔几秒截取一次客户端前台窗口的截图与上一轮截图做对比如果发现指定区域的画面发生了变化比如底部任务栏图标出现红色数字角标、聊天列表窗口的横幅出现新的会话就触发后续的身份识别与订单校验流程。这里有一个关键的设计细节轮询间隔不能太短否则CPU占用高而且极容易触发风控也不能太长否则买家等太久。我调试下来3到5秒是比较平衡的值。# 监控主循环简版 import time import pyautogui def watch_loop(region, interval4): last_img None while True: img pyautogui.screenshot(regionregion) if last_img is not None: diff compare_images(last_img, img) if diff threshold: handle_new_event(img) # 触发后续识别与发货流程 last_img img time.sleep(interval)2.2 卡密识别与自动回复模块怎么把货准确发出去监控模块发现窗口有变化接下来要回答三个问题是谁发的消息、拍的是什么商品、要不要发货。买家身份可以从聊天窗口顶部的昵称区域用OCR识别出来。商品识别稍微复杂一点我用的方案是维护一张商品关键词表把每个商品对应的关键词比如软件授权码、资料包配置进去然后对聊天内容做文字匹配。如果匹配上了再检查订单状态是不是已付款。发货动作本身是程序根据识别结果到对应商品的卡密池里取一条未使用的卡密拼接成一条完整话术再通过pyautogui模拟键盘输入和回车发送。话术模板我建议每个人都要反复打磨不要写得太机械化至少加一句亲感谢购买之类的话实测下来被投诉欺诈的概率会低不少。2.3 库存管理与防超卖设计同一个卡密不能发两次自动发货最容易翻车的地方不是识别不到而是同一个卡密卖了两份。我一开始用纯文本文件记录库存结果并发测试的时候直接把两条相同的卡密发给了两个不同买家。后来改成SQLite数据库才算彻底解决这个问题。数据库就三张表商品表product、卡密表card、订单表order。关键逻辑是发货的时候开启一个事务先从卡密表里查出状态为未使用的一条卡密立刻把状态改成已锁定然后再执行发送发送成功后再把状态改成已使用同时往订单表写入一条记录。这样即使程序中间异常退出也不会重复发同一个卡密。这里有个细节值得注意状态不能直接改成已使用因为发送有可能失败。发送失败以后卡密要回滚成未使用否则就会丢单。我是吃了一次亏才加上这个回滚逻辑。-- 取卡密时执行的核心SQL示意 SELECT id, code FROM card WHERE product_id ? AND status unused LIMIT 1;2.4 人工接管与异常告警系统不是万能的我一开始追求全自动但跑了三周就发现纯自动系统一定会有处理不了的情况。比如OCR识别置信度过低、卡密池见底、买家发来了非标准的售后话术。这种时候如果系统硬着头皮发很容易发错。所以我在系统里加了三级异常处理机制第一级识别置信度低于阈值自动重新截图识别一遍还不行就进入下一级第二级发货条件不满足比如库存不足系统暂停该订单的自动处理转入需人工接管列表同时通过钉钉机器人推送告警到手机第三级同一账号触发连续异常告警系统自动暂停该账号的所有自动发货避免造成更大问题。3. 实操环节把源码跑起来3.1 环境准备与依赖安装源码是跨机器的但建议部署到一台长期不关机的Windows电脑上。系统要求不高4GB内存、普通双核CPU就够跑。需要的环境是Python 3.9及以上然后安装几个依赖库。pip install pyautogui paddleocr paddlepaddle pillow numpy opencv-pythonPaddleOCR第一次运行会自动下载模型文件国内网络一般能正常拉取。如果下载慢可以手动把模型放到用户目录下的.paddlex文件夹里这个细节在运行日志里会有提示。除了Python依赖闲鱼PC客户端需要提前登录好并保持在前台或固定位置。我建议把窗口固定在屏幕左上角这样截图的region参数好写也不容易截错区域。3.2 配置文件说明改一遍就能用所有个性化参数都在config.ini里不用改代码就能适配不同卖家的商品和话术。配置项说明我的推荐值monitor_interval监控轮询间隔秒4confidence_thresholdOCR识别置信度阈值0.8keyword_map商品关键词与商品ID映射如授权码A001reply_template发货话术模板含{card_code}占位符card_file_path卡密文件路径每行一条enable_takeover是否开启人工接管模式true卡密文件的格式我建议遵循一行一条的规则不要带多余空格和符号。如果要区分多个商品就建多个txt文件在配置文件里分别指定路径。[monitor] interval 4 confidence 0.8 [product] keyword 软件授权码 card_file cards/software.txt reply_template 亲感谢购买您的授权码是{card_code}请妥善保管。3.3 核心代码逻辑讲解别看代码多核心就三块源码看起来文件不少但核心逻辑其实只有三块监听循环、发货函数、库存事务。这里我摘一段发货函数的核心逻辑做解析。def dispatch_card(order): # 1. 校验订单状态防止重复发货 if order_already_dispatched(order): log(该订单已发货跳过) return False # 2. 开启事务锁定一条卡密 conn get_db_connection() with conn.transaction(): card fetch_unused_card(order.product_id) if card is None: alert(库存不足需要人工补卡) return False mark_card_locked(card.id) # 3. 模拟发送消息到聊天窗口 send_text_to_client(build_reply(order, card.code)) # 4. 发送成功后更新卡密状态写入订单记录 mark_card_used(card.id) record_order(order, card.id) return True这段代码最有价值的地方在第三步和第四步之间有失败分支如果send_text_to_client中途抛异常卡密的状态还是locked下一轮循环中会有一个定时任务把超时未确认的locked卡密回滚为unused。这个细节一定要保留否则异常断电后库存就冻结了。3.4 话术与卡密格式的工程化设计很多人忽略话术的重要性。自动发货系统不只是技术问题话术设计直接关系到买家体验和平台风控。实测下来纯模板化的回复比如只发一串卡密容易被系统判定为机器行为进而限制账号的消息发送能力。我在模板里做了三类话术首次发货话术、补发话术、售后说明话术。首次发货话术长这样亲您拍的xx商品已经安排好啦以下是您的专属授权码xxxx-xxxx-xxxx请复制后到软件内激活。如有问题随时联系我哦。注意这里加了安排好啦模拟真人操作而且明确给出下一步操作指引能有效减少买家追问。4. 常见问题与排坑实录4.1 识别不准、漏单、错发怎么破这套系统最常被问到的就是识别不准确。我排查下来九成情况不是OCR模型的问题而是截图区域没对准。闲鱼PC端的界面在不同分辨率下布局会有差异如果你的显示器是2K、4K高分辨率建议把系统的显示缩放比先调回100%再运行否则截图的坐标全是偏的。漏单也有一个隐蔽原因买家拍下商品后没有立刻发消息系统没有触发窗口变化事件所以不会发货。解决思路是每隔5到10分钟主动截取一次订单列表区域把所有待发货状态的订单扫一遍发现漏发就补发。这个补扫订单机制我强烈建议加上。4.2 操作频率过高触发风控怎么办我第一天测试的时候把轮询间隔设成1秒跑了不到两小时闲鱼客户端就提示操作频繁需要重新验证。后面琢磨出来一个很土但有效的办法每次模拟操作之间加随机延迟。import random import time def human_delay(): time.sleep(random.uniform(0.8, 2.2))所有鼠标移动、点击、键盘输入之间都加上这个随机延迟模拟真人操作节奏。另外同一个账号单日发货量不要太大超过一定数量后即使系统自动发货速度很稳定也建议拆到第二天再继续。4.3 多商品多库存如何避免发错货一开始我只做单商品后来加了第二个商品之后发现偶尔会把B商品的卡密发给买了A商品的买家。排查下来是商品关键词匹配做成了包含逻辑而两个商品的关键词有重叠。解决办法是把匹配逻辑改成精确匹配 排除黑名单关键词。比如A商品关键词是软件AB商品关键词是软件B匹配软件时直接跳过必须匹配到完整关键词才发货。卡密文件也建议按商品分文件管理绝对不要把所有卡密堆在同一个txt里否则程序很难区分。4.4 日志与异常流水排查问题的钥匙这套系统我强烈建议开启完整日志。我自己就是把每一条操作、每一次识别、每一次发货的结果都记录到SQLite的一张日志表里字段包含时间戳、账号、买家昵称、商品ID、动作类型、结果、异常信息。时间买家昵称商品ID动作结果2024-06-01 02:13:45小明A001识别订单成功2024-06-01 02:13:52小明A001发送卡密成功2024-06-01 20:15:03老王A002识别订单置信度低转人工遇到问题不要瞎猜先看日志按时间轴把流程重放一遍十有八九能定位到具体环节。这也是我标题里敢写可运行源码的原因——日志齐全的源码才是真正可维护的源码。5. 进阶玩法与风险控制5.1 多账号管理与分仓逻辑如果你手里不止一个闲鱼账号先把账号和商品彻底分开。每个账号对应独立的配置目录里面配置独立的商品池、卡密池和日志库。这样做的原因是不同账号的商品类目、卡密池完全隔离一旦某个账号出问题不会连累其他账号。我目前是每个账号跑一个Python进程用supervisor之类的工具做进程守护进程崩溃后自动拉起。如果电脑配置比较低建议严格控制同时运行的进程数实测一台4核8GB的老笔记本同时跑3个账号CPU占用已经接近70%了。5.2 安全红线自动化的边界在哪里最后说几个我用这套系统总结出来的红线。第一不要做全自动无人值守再稳的系统也需要每天花几分钟看日志确认没有异常告警。第二不要在闲鱼客户端里跑与发货无关的自动化操作系统只做看消息、发卡密这两件事不要顺手做什么养号、刷浏览之类的事那是给自己挖坑。第三卡密池不要一次性导入太多尤其是从第三方渠道买的卡密一定要先小批量测试确认有效再导入正式库存否则一次性发出几百条失效卡密售后能把你压垮。这也是我一直强调自动发货系统只是帮你把速度提上去不代表你可以完全离线的原因。虚拟商品的售后问题比传统实物更复杂系统能保证发出去但发得对、发得好还是需要人工关注至少要有异常告警兜底。在这套系统的迭代过程中我最大的体会是写自动化的难处不在写代码而在梳理边界。一开始我总想让它处理所有情况后来发现边界定得越清楚系统越稳定。如果你准备复刻这套方案建议先拿一个低客单价的测试商品跑一个礼拜把监控间隔、话术模板、异常告警都调到顺手之后再切换到主力商品体验会好很多。本文还有配套的精品资源点击获取