1. 为什么我会动手折腾一个自动发货系统事情得从一次凌晨三点的消息提醒说起。我做虚拟商品交易有一段时间了卖的是软件授权码和资料包每天几十单的规模不算大但每单都要人工处理买家拍下后留言要哪个规格我打开后台找到对应的卡密复制粘贴发给对方然后点发货。这套流程看起来简单可一旦订单集中在某个时间段涌入或者你正在忙别的事情消息回复不及时买家就会催催急了就可能退款。最崩溃的是半夜来单手机一震你迷迷糊糊爬起来来回确认商品规格、找卡密、发消息这一套折腾下来半小时睡不着。XianYuAutoDeliveryX这个项目就是在这种背景下立项的。核心目标很直接把买家拍下-识别需求-发送卡密-完成发货这条链路全部自动化让我只需要在异常情况下介入。整个系统围绕闲鱼平台的消息数据流展开通过模拟客户端协议完成消息监听与回复同时引入大模型来做意图识别和实体抽取替代传统的关键词匹配方案。项目跑通之后我的订单处理时间从平均每单3到5分钟降到了几十秒而且半夜来单再也不用惊醒了。这篇博文想分享的是这套系统的完整实现思路从架构设计、关键技术环节到实际踩坑记录全部基于我自己的实操经验。如果你是做虚拟商品交易的个人卖家或者对利用大模型做垂直场景自动化感兴趣这篇文章应该能给你不少可以直接抄作业的细节。闲鱼本身没有官方开放API所以项目中所说的API实际上是通过协议分析获取的非官方接口能力这一点后面我会专门说明边界和风险。2. 整体架构设计先想清楚哪些环节该自动化哪些该留人工2.1 核心流程拆解与自动化的边界动手写代码之前我花了两天时间梳理自己的人工发货流程把它拆成了可独立处理的模块。我是把流程拆成了四个环节订单确认、需求识别、发货执行、售后兜底。每一个环节我都问自己一个问题这个环节需要的是确定性逻辑还是语义理解确定性逻辑就用规则和脚本语义理解才交给大模型。订单确认是平台层面的状态变化我只需要监控消息队列和订单状态就能搞定属于确定性逻辑。需求识别是最难的部分买家可能说我要mac版的发到我邮箱xxxxx.com也可能说有Windows的么怎么发我还可能直接甩一个1就等发货。这些话术千变万化传统的关键词正则根本撑不住这是大模型发挥价值的地方。发货执行本身又是一段确定性逻辑根据识别出的商品ID和规格从库存表里取卡密或者网盘链接走发送接口发给买家。售后兜底则是人机结合涉及退款、纠纷这类场景我选择直接拉高异常阈值交给人工处理不在自动化范围内。这个拆分过程特别重要。我见过很多人做自动化一开始就想把整个交易链路塞给程序结果在售后这种需要人判断的场景里翻车。自动化的边界应该划定在确定性操作和语义理解这两类事情上涉及金钱纠纷、平台规则判断、买家情绪安抚这类行为最好还是留人工兜底。2.2 大模型和规则引擎各管哪一块确定了自动化边界之后接下来要决定不同环节用什么技术来实现。我最初的方案是用正则加关键词库来做意图识别比如匹配mac就发mac版匹配邮箱就提取邮箱。测试下来发现场景一复杂就崩了买家说不是win的我要苹果系统的正则就懵了。还有一个更难搞的场景买家问你这个和隔壁那个30的有什么区别这种问题没有标准答案但又是真实询问意图需要结合商品知识库回答。后来我引入了大模型作为语义理解引擎但并没有彻底抛弃规则引擎而是让两者各司其职。大模型负责两件事意图分类买家这条消息是想问商品信息、确认下单规格、催发货还是要求退款和实体抽取从自然语言里抽取出商品版本、收货邮箱、数量等结构化信息。规则引擎负责那些只需要精确匹配的操作比如订单号后四位从消息里提取卡密库存不足时自动标记这类场景。大模型输出的是结构化的JSON规则引擎拿到JSON之后执行具体动作两者各管一摊互不干扰。这个设计的实际效果比我预想的要好。规则引擎处理了大约六成的高确定性消息大模型处理剩下四成需要语义理解的场景。大模型不是被频繁调用所以token成本可控响应速度也稳定。2.3 技术栈选型为什么是Python加本地部署大模型技术选型这件事我纠结了挺久。自动发货系统涉及消息监听、接口通信、数据库操作、任务调度这些用Python处理效率最高生态里现成的库也多网络请求用httpx数据存储用SQLite加SQLModel任务调度用APScheduler。Python跑这类IO密集型任务完全够用而且写起来比Java或Go快很多。实际使用中请记住这类业务系统的基本盘在逻辑清晰和迭代效率不在极致性能。大模型部分我同时考虑过云端API和本地部署两条路。云端大模型API的优势是效果拔群尤其是比较新的模型理解自然语言的能力确实更强劣势是每次调用都有延迟和费用而且商品数据、订单信息属于交易敏感数据发到云端我心里有些顾虑。本地部署我试过ollama直接跑Qwen系列模型16GB显存的显卡就能跑起来7B到14B参数量的模型再配合32GB内存做推理缓存实测下来单次意图识别的推理时间大概在1到3秒对于这个场景完全够用了。# 本地启动Qwen模型服务使用OpenAI兼容接口 ollama pull qwen2.5:7b-instruct ollama serve # 默认监听 http://localhost:11434/v1我之前也整理过一份选型对比表遇到类似项目可以直接参考方案优点缺点适用场景云端大模型API效果最好、部署零成本有费用、数据出网、依赖网络对效果要求高的通用场景本地ollama部署大模型数据私有、无调用费、离线可用需要显存、效果略弱于云端交易数据敏感、频繁调用的场景纯规则引擎零推理延迟、完全可控无法处理复杂语义确定性匹配场景最终我选了本地部署为主、云端API兜底的混合方案日常消息用本地模型处理遇到本地模型置信度低的情况再请求云端模型做二次判断。3. 核心实现细节消息监听、意图识别、自动发货一条龙3.1 消息监听模块的实现思路与登录态维护消息监听是整条自动化链路的数据入口这一步要拿到买家发给我的消息内容。我需要说明的是闲鱼并没有官方对外开放的API接口这里说的API是我通过分析安卓客户端协议后自行封装的非官方接口。关于这个做法的风险我在第5部分会专门展开这里先讲实现逻辑。协议分析的核心工作有两块一是找到消息列表和消息详情的请求地址与参数结构二是处理签名和加密逻辑。我通过抓包工具分析安卓客户端与服务器之间的HTTPS请求定位到消息相关的端点然后用Python复现请求过程。关键难点在于闲鱼的请求带签名校验参数好在客户端本身有调试接口可以拿到签名逻辑的关键桩点用Frida做Hook绕过签名就是常规操作了。整个接入方案实际效果完全取决于目标端版本迭代的频率一遇到版本更新就要重新分析所以我在代码里做了一层接口抽象把协议细节隔离在单独模块中。登录态维护是另一个大坑。闲鱼的登录凭证过期时间比较短可能几个小时就失效。我的做法是维护一个独立的token池在token过期前通过客户端的续期接口刷新同时保留一个二维码登录入口作为兜底。系统检测到token失效时会暂停自动化推送告警到我的微信等我扫码重新登录后再恢复。这样虽然做不到完全无人值守但至少不会在token过期后继续尝试发送请求导致触发更严格的风控限制。3.2 大模型在意图识别和实体抽取中的Prompt设计消息拿到手之后接下来要做的是语义理解。我设计了一套结构化输出的Prompt模板要求模型输出意图类别、抽取实体的JSON以及置信度评分。大模型对意图的感知能力比关键词正则强很多但想让模型稳定输出正确的JSON格式必须明确给定输出约束。SYSTEM_PROMPT 你是闲鱼平台虚拟商品卖家的智能客服助手。买家发来消息你需要判断买家的意图并从消息中抽取关键实体。 意图类别仅限以下几种 - ask_info: 询问商品信息、价格、发货方式 - confirm_order: 确认下单规格、提供收货信息 - urge_delivery: 催促发货 - after_sale: 售后问题退款、换货、未收到货 - other: 其他意图 实体字段如果消息中没有相关信息则不返回该字段 - product_platform: 商品平台如 mac/windows - product_edition: 商品版本 - email: 收货邮箱 - quantity: 购买数量 输出要求 1. 必须输出JSON格式不要输出任何额外文字 2. JSON结构必须严格遵循下面的格式 { intent: 意图类别, entities: { product_platform: 形状与消息一致的值, product_edition: 形状与消息一致的值, email: 形状与消息一致的值, quantity: 1 }, confidence: 0.0, reply_suggestion: 针对该消息应回复的内容 } 这个Prompt看着简单实际打磨过程中踩了不少坑。比如一开始我没有要求模型返回confidence字段导致模型在语义模糊的消息上硬猜意图。加上置信度之后我可以设一个阈值比如0.75低于这个阈值就转人工宁可不回也不能乱回。还有一个小细节必须明确要求模型不要输出任何额外文字否则它会偶尔在JSON外面套一层Markdown代码块标记解析的时候直接报错。在保证大模型稳定落地这块不少团队也在用类似的高效微调平台对模型做垂直指令微调。我的场景消息体量还不够大所以直接用提示词工程解决了但如果你买的商品种类特别多或者买家话术复杂度高用类似LLaMA Factory这类工具把历史对话数据微调进模型效果会再上一个台阶。这块等体量上来后我计划专门做一轮数据标注和微调实验。3.3 发货执行模块基于商品维度的策略分发意图识别完成后系统拿到的是结构化的需求数据接下来就是发货执行。我在数据库中设计了商品表和订单表商品表记录了商品ID、名称、对应的发货类型卡密或网盘链接、库存余量、规格选项等信息。发货逻辑按商品类型做了策略分发每一类都用独立的处理器实现。class DeliveryService: def deliver(self, order: Order): product get_product(order.product_id) # 不同商品走不同的发货策略 strategy DeliveryStrategyFactory.get_strategy(product.delivery_type) result strategy.execute(order, product) if result.success: send_message(order.buyer_id, result.delivery_content) update_order_status(order.id, delivered) else: notify_admin(order.id, result.error_message)卡密类商品是最简单的发货策略从数据库取一条未使用的卡密标记为已使用然后通过消息接口把卡密文案发给买家。网盘链接类商品复杂一些因为链接有时候会失效所以我维护了一个链接有效期检查任务每天定时探测一遍已有链接的可用性。还有一类需要加买家微信或QQ传输的商品这种无法完全自动化我就把它标记为半自动系统完成前两步确认下单、生成发货单据最后由人工添加联系方式发送文件。发货执行模块还有一个容易忽略的点重复发货保护。因为消息监听可能存在重复投递的情况同一订单的消息可能被处理两次如果没有幂等控制买家会收到两条相同的卡密。我在订单表上加了唯一约束处理前先检查订单状态只有处于待发货状态的订单才能执行发货动作。3.4 异步任务编排与失败重试机制整套系统里有些操作不是即时完成的比如大模型推理可能要1到3秒发消息接口偶尔超时可能需要重试。如果把同步操作全部串在一个循环里消息一多就会积压。我用了asyncio加队列的方式处理这类异步任务消息监听器收到新消息后直接丢进任务队列后台Worker从队列里取任务执行这样监听和处理的速率就解耦了。import asyncio async def worker(queue): while True: task await queue.get() try: await process_task(task) except Exception as e: logger.error(f任务处理失败: {e}, exc_infoTrue) await retry_task(queue, task) finally: queue.task_done()失败重试我采用的是指数退避策略第一次失败等2秒重试第二次等4秒第三次等8秒最多重试5次。超过重试次数就把任务标记为failed发送告警让我人工介入。大模型调用如果返回超时或解析失败同样走这套重试机制。实际运行中重试机制解决了不少网络抖动问题但也会掩盖一些真正的程序Bug所以每一次重试日志我都打得特别详细方便事后定位根因。我还在系统里加了每日消息量、发货量、成功率、失败原因分布这类统计面板用的是一个非常轻量的方案SQLite直接存统计数据再加一个简单的HTTP接口输出JSON前端用Grafana展示。有了数据之后你能很清楚地看出哪个环节是瓶颈比如某天发货成功率下降看一眼统计面板就知道是库存不足还是接口超时不用瞎猜。4. 关键问题排查与避坑实录4.1 买家语境识别偏差与幻觉问题的应对大模型虽然语义理解能力强但也会有判断失误和幻觉问题这在交易场景中是不可接受的。比如有买家发消息说你这个能用吗模型可能会把它理解为询问商品信息给出详细介绍但实际上买家已经拍下订单了这句话的真实意图是我拍下了我要怎么使用。这种语境偏差在缺少上下文时会频繁出现。解决办法是引入多轮对话上下文管理。我不再对每一条消息单独做意图识别而是把该买家最近10条消息拼接成对话上下文连同最新消息一起发给大模型。有了前文信息模型判断准确率明显提升。对幻觉问题我的策略是对大模型抽取出来的实体做二次校验比如提取出来的邮箱字段一定得匹配邮箱正则版本名称必须在商品规格枚举表中存在校验不过就直接提高置信度阈值或转人工。这里要奉劝一句不要完全信任大模型的结构化输出。实体校验那一层虽然笨但能挡掉大部分低级错误。我见过有人把大模型输出的JSON直接拿来执行库存扣减结果模型把商品版本识别错了导致发错卡密售后处理起来特别麻烦。4.2 大模型调用限流与本地算力瓶颈本地部署大模型之后接下来的问题是推理速度和并发限制。我用的7B模型在16GB显存上单次推理需要1到3秒如果同一时间进来5条消息要处理那就要排队。刚开始我用的是一个线程池直接调模型接口结果显存不够用频繁触发OOM系统直接假死。后来我改成了有界信号量加队列的方案限制同时只有两个推理任务在跑其余任务排队等待。配合Redis做任务状态缓存消息积压情况用Prometheus监控。如果你用的是云端API限流的坑同样存在因为云厂商的API也有QPS限制超了会返回限流错误这时候排队和退避重试就更重要了。我在代码里实现了一个简单的令牌桶限流器确保请求速率稳定在API阈值之内。本地部署方面如果你也打算用ollama跑Qwen系列模型我有几个优化建议尽量用量化版本比如Q4_K_M显存占用能降低三分之一开启Flash Attention可以加快推理在ollama的配置里调整上下文长度不要盲目开大128K的上下文对显存压力远高于7B模型本身。实测下来16GB显存加32GB内存的方案跑7B模型做推理是完全合格的9B或14B模型虽然效果略好但单次推理时间会拉到5秒以上在对话场景里体验明显变差。4.3 订单消息乱序与重复处理问题消息乱序是异步系统里经常遇到的问题。买家先发了一条我要mac版的然后又发算了还是windows吧两条消息到达队列的顺序可能跟发送顺序不一致。如果系统先处理了windows那条、再处理mac那条就会导致发货规格错误。这个问题不解决自动发货就成了高危操作。我解决乱序问题的方式是给每条消息加时间戳和消息ID在进入意图识别前先按时间戳排序。同时引入了一个规则如果同一买家在3分钟内连续发来多条消息只处理最后一条明确意图的消息其余消息作为上下文参考。这样既避免漏掉信息变更又不会因为消息重复触发重复发货。还有一个比较隐蔽的问题就是闲鱼消息接口可能把同一内容推送两次。我在数据库层面做了幂等设计每条消息的唯一ID作为主键重复插入直接忽略。这个设计在发货场景尤其重要因为没有幂等保护的后果是买家收到两条一模一样的卡密虽然不致命但体验很糟而且如果平台检测到重复内容可能触发风控。4.4 冷静看待自动化的局限什么情况必须转人工整个系统跑了一段时间我得承认它并不是万能的。以下场景是系统的短板售后问题尤其是退款纠纷这种涉及平台规则和买家情绪的场景大模型很难应付小众商品的新颖问题买家问的细节在训练数据里根本没见过模型容易一本正经地胡说八道还有恶意行为和恶意话术比如买家发来一个钓鱼链接或者试图套取其他买家信息这种必须人工识别。所以我在系统里设置了一个转人工的手动开关和自动触发条件。自动触发包括大模型置信度低于阈值、同一买家连续触发多次after_sale意图、消息中包含明显的敏感词或链接。对于这些消息系统只做标记和告警不执行任何发货操作等待我人工介入。这套机制保证了自动化不是失控的它只是替我分担了重复劳动真正的决策权还是在人手里。5. 风险边界与非官方API的合规提醒5.1 闲鱼没有官方API目前的接入方式都是协议模拟我需要非常坦白地讲清楚闲鱼目前没有对个人开发者开放的官方API哪怕商户合作接口也不是面向这种自动发货场景的。项目名里写的闲鱼API实际的实现基础是非官方协议模拟也就是分析安卓客户端请求参数、构造加签请求、维持登录态这一套。这个做法的本质是在模拟客户端行为平台的风控系统随时可能识别出这种行为并采取限制措施轻则限制账号消息功能重则直接封禁账号。从我的实践经验来看平台反自动化识别能力一直在升级。最明显的感受是同一个IP地址下高频请求会触发滑块验证同一账号的短时间密集操作会触发消息风控。我的应对策略是控制请求频率模拟人工操作节奏随机加入阅读消息和思考时间分散请求IP用代理池轮换出口地址。但说到底这些方法只是降低被识别概率不可能根治风险。5.2 我踩过的一次账号限制经历说出来都是教训。有一次我为了测试发货模块的并发表现用脚本一口气给5个订单执行了发货操作操作间隔不到1秒。结果当天账号就被限制了私信功能提示您操作过于频繁稍后再试。这个限制持续了24小时才自动解除。那次之后我彻底明白了自动化脚本的请求节奏必须无限接近真人操作千万不要图快。我把请求间隔设置为随机2到5秒每次发送消息后随机等待几秒再发送下一条。这样虽然整体吞吐量下降了但被限制的概率大幅降低。后来我也做了更保守的调整整点前后不跑批量任务深夜时段降低轮询频率这些细节看着不起眼但在风控下的实际体验差异很大。5.3 合规建议小规模自用和技术学习为主做这个项目的时候我心里很清楚它更适合定位为个人效率工具和技术实验而不是一款可以商业化的产品。如果你打算把这个系统用在真实交易上我的建议是控制自动化规模不要大量矩阵账号同时跑及时关注平台规则变动不要在高风险时期顶风操作保留完整日志一旦出问题能立即止损。另外我接触到一些做同类工具的人有人尝试把这种协议模拟能力封装成商业服务卖给其他卖家我特别不赞同这种方式。一旦涉及规模化商用风险等级会完全不同不仅是账号问题还有可能触碰更严格的法律边界。我的立场是把它当作学习大模型落地和自动化架构的实践项目自己小范围用一用这个价值就足够了。6. 一些真正靠谱的实操建议文章写到这里该讲的技术实现和排查经验都覆盖了。最后再补充几条我在实际运行中总结出来的建议也是我认为这套系统能稳定运行这么久的关键。请求节奏是生命线。不管你用什么协议接入都把请求频率控制低一点模拟真人行为的随机间隔比任何花哨的技术都重要。我后来加入了请求间隔的随机抖动并且每天在做完订单集中处理后人为停掉系统一段时间让它休息账号健康状态明显好了很多。日志和统计一定要做扎实。每一次请求的URL、参数、响应码、耗时每一条消息的内容、模型输出、执行动作全部记录下来。这套系统的调优过程本质上就是在日志里找规律的过程。有些问题初期看是小概率事件没有日志你真的会毫无头绪。大模型不是银弹规则引擎至少占半壁江山。当我发现大模型处理过多反而引发问题时就开始把高确定性逻辑尽可能下沉到规则引擎大模型只做模糊判断。这套规则兜底、模型裁决的组合实际运行效果远比纯规则或纯模型稳定。代码层面要有止损开关。我在系统里加了一个全局熔断器一旦检测到连续多次请求失败或者账号出现异常提示系统会自动停止所有自动化任务只保留告警通知。这个开关救了我好几次比任何复杂算法都管用。最后再啰嗦一句对这类非官方接口的自动化项目一定要保留随时收手的心态。平台规则和技术防线都在变今天能跑的方案下周可能就失效了。把它当作一个学习和探索的实践保持敬畏不要过度依赖。这套系统的价值在于让你真正理解了协议分析、大模型应用和自动化架构设计这些能力换到合规场景里同样可以复用。