

0x1:这玩意到底替人干了什么【概述】
一句话,它把闲鱼卖家那几个来回切换的动作焊死在一条管线上:买家付款之后自动识别订单、发卡密或者发图片,普通咨询走关键词或者大模型回复,多个账号挂在同一个后台里,恶意退款的买家直接进黑名单。库是本地 SQLite,商品、订单、卡密、黑名单全在一个文件里,不往任何第三方服务器上送。
前后端分离,后端 FastAPI 挂在 8080 端口,前端构建产物丢进静态目录就完事,想换机器直接搬走。风险控制这块除了自动拉黑,还支持永久白名单、按账号与状态筛选,以及退款凭证留档,方便事后翻账。
0x2:以前是怎么被玩死的【痛点】
以前这活是纯人肉的。买家半夜付款,你得从被窝里爬起来看消息,翻到那件商品,找到对应的卡密分组,复制一条发出去。号一多就更乱,来回切登录状态,切着切着就记不清哪张卡发给了谁。更阴的是错法特别隐蔽:同一个订单手抖处理两遍,一张卡发两遍;多规格商品的标题关键词撞在一起,前一件的库存发到后一个订单上。
系统现在拿订单锁加十分钟冷却顶重复发货,拿关键词唯一匹配顶发错库存,拿失败不伪造内容顶空发,这三下基本把最要命的坑填了。撞上多条规则的时候它宁可停发也不赌,直接把订单丢回人工,比自作聪明强。
0x3:技术选型没什么玄学【技术栈】
后端 Python 3.11 加 FastAPI,WebSocket 和 REST 一套框架全包了,异步那套跟闲鱼长连接的收发消息正好对味,没必要再拆两套服务。存储直接用 SQLite,商品、订单、卡密、黑名单一个文件搞定,单机部署不用额外起数据库,也省了运维那点破事。
浏览器自动化交给 Playwright,扫码登录和 Cookie 维护都靠它,封面字段版本不一致也在这层兜住。前端 React 19 加 TypeScript 加 Vite,样式走 Tailwind,看板图表用 Recharts,图标用 Lucide。最后拿 Docker Compose 打包,Nginx 可有可无,数据落在数据、日志、备份三个目录。
0x4:核心链路就这一条【流程导图】
从消息进来到卡密出去,判定顺序是固定的,一步不过就直接停,不会留下半完成的状态。下面这张导图是整条链路的骨架,每个环节实际在干什么,由导图后面的正文接着展开说。
|
msg_in 闲鱼 WebSocket 收到买家消息
|
|
↓
|
|
trigger 付款与待发货触发词判定
|
|
↓
|
|
guard 商品归属与自动发货开关校验
|
|
↓
|
|
blacklist 退款黑名单与白名单校验
|
|
↓
|
|
lock 订单锁与十分钟冷却锁
|
|
↓
|
|
resolve 卡密分组判定,指定分组或关键词唯一匹配
|
|
↓
|
|
confirm 延时与订单自动确认发货
|
|
↓
|
|
consume 读取卡密内容并消费库存
|
|
↓
|
|
deliver 向买家发送卡密、链接或图片
|
|
↓
|
|
followup 按分组配置补发后续买家消息
|
顺序不能乱。先确认商品归属和自动发货开关,再查退款黑名单,这两步都过了才去抢订单锁和冷却锁。锁到手才开始定卡密分组:商品自己绑了分组就直接校验后用,没绑才回落到标题加详情的关键词规则,而且必须唯一命中,撞上两条以上宁可停发也不赌。最后才是延时、自动确认发货、扣库存、发内容、补后续消息这一串。
0x5:几个容易踩的判定边界【边界】
触发只认付款和等待发货这类说法,普通咨询不会误触发发货,两条链路是分开的。多规格商品匹配的时候会连规格名称和值一起比,撞车就停。订单锁按订单 ID 加,发货成功后还会保持一段时间,配合十分钟冷却,短时间内的重复消息根本进不来。
|
1
2
3
4
5
6
7
8
9
|
msg_in : order trigger matcheditem : auto_delivery=on group=cards-basicblacklist : buyer not blockedorder_lock : acquiredcooldown : clearcard_group : resolved by explicit bindingstock : 1 row consumed, 42 rows leftdeliver : card sent to buyerfollowup : disabled |
库存为空、接口失败、图片地址为空这三种情况,程序不伪造成功内容,直接记失败日志并推失败通知,省得你以为发出去了其实没有。发货后的追加消息是独立的一步,可以用商品 ID、本次数量和分组名称拼文本,它发失败也不影响卡密本身。
0x6:卡密分组的四种类型【库存】
分组就是发货内容的来源,类型决定怎么取值。固定文字每次发同一段,适合统一话术或者通用说明;批量库存一行一条,发一条删一条,开了多数量发货就按订单数量循环扣;接口类型在发货那一刻现调上游地址拿卡,适合上家实时发卡的场景;图片类型就直接把图发给买家。
分组里还能配发货后的追加消息,用几个变量把商品 ID、数量和分组名拼进去。另外商品级还有个退款拉黑开关和自动发货开关,旧商品的自动发货默认是开的,兼容原来那套关键词发货规则,想关就单独到商品卡片上关。
0x7:AI 回复跟发货是两条线【人工智能】
AI 回复不碰发货流程,各走各的。账号级配模型、接口地址、密钥和总开关,商品级还有个三态开关:跟随账号、开、关。设成跟随就走账号那一档,设成开也得账号那边有有效配置和密钥才跑得起来,缺一样都不进流程。
发请求的时候会把商品标题、价格、详情和这个商品自己的关键词一起塞进上下文,所以它答的是这件东西本身的细节,不是一段放之四海皆准的套话。密钥只写在根目录配置文件里,数据库不落这份数据,网页上也只显示配置状态不回显密钥。
0x8:多账号和封面那些破事【账号】
账号支持扫码登录,Cookie 持久化,掉线会刷新,在线状态在后台直接可见。商品同步按账号走,麻烦的是闲鱼列表接口给的封面字段版本不一致,有时候叫 picUrl,有时候叫 url,有时候塞在 picList 数组里,同步逻辑会挨个试着抠第一张。
顺手还会把双斜杠开头的地址补成 https,旧版本存到商品详情里的封面会在数据库迁移时自动回填,所以老库升上来也不会一片空白。同步过程会对比页面声明数量、接口解析数量和数据库保存数量,对不上就给明确提示,不会闷着头算完。
0x9:怎么跑起来【部署】
Windows 直接双击根目录的启动脚本,它会自己建虚拟环境、装依赖、起服务。手动也行,环境就 Python 3.11 以上加 Node.js 20 以上,Windows 和常见 Linux 发行版都能跑。首次启动前记得复制配置模板改掉管理员密码,默认监听 8080 端口。
|
1
2
3
4
5
6
7
8
9
|
git clone https://github.com/245867/xianyu-auto-delivery.gitcd xianyu-auto-deliverypy -3.11 -m venv .venv.\.venv\Scripts\Activate.ps1python -m pip install -r requirements.txtplaywright install chromiumcd frontend && npm install && npm run buildcd ..python Start.py |
要是用容器,部署目录下有现成的 Compose 文件,国内还有一份换过镜像源的版本,数据落在数据、日志、备份三个目录里。管理员密码和随机密钥没设的话,编排会直接拒绝启动,省得挂一个弱口令的实例在外面。


没有回复内容