做闲鱼虚拟商品这几年我最烦的其实不是没订单而是订单来了人不在电脑前。有好几次晚上十一点多买家拍下激活码我第二天早上才看到结果人家早就退款了。后来我把一个叫 XianYuAutoDeliveryX 的开源自动发货项目从头折腾了一遍从环境配置到把大模型接进去做智能客服中间踩了不少坑。这篇就是完整记录给同样在做虚拟商品、想解放双手的朋友一个可以直接照着抄的参考。1. 整体设计与核心思路拆解1.1 传统手工发货为什么撑不住虚拟商品这个品类和实物不一样特点是SKU多、单笔金额低、咨询量集中、发货时效要求高。卖激活码、网盘资料、会员代充、软件授权这类东西买家拍下之后第一件事就是催发货晚几分钟可能就退款跑单。我以前手动发货时白天还能应付晚上和午休时间完全离不开手机出门吃个饭都要盯着订单提醒真应了那句“人肉客服人肉仓库”。手工发货还有一个隐性成本重复劳动。同一个商品卖了一百单就要复制粘贴一百次卡密中间只要有一次眼花发错就要处理售后纠纷。数据一多库存还容易乱——账面上有货实际卡密池早就空了超卖以后又要一个个道歉退款非常消耗账号权重。这个项目解决的其实就是三件事订单来了自动发、库存没了自动停、买家问了自动回。把这些机械操作抽出来交给程序以后人只需要在出现异常的时候介入整个经营节奏一下就变了。1.2 XianYuAutoDeliveryX 的定位与核心能力XianYuAutoDeliveryX 本质上是一个跑在本地或者云服务器上的自动化服务它做的是把闲鱼平台的订单信号接进来再根据商品配置去完成发货动作。它的核心能力大致分四块商品与卡密管理把虚拟商品建模成“商品SKU卡密池”每个链接对应一组可发货的卡密、网盘地址或自定义文本。订单监听与自动发货监测到新订单以后自动校验支付状态扣减库存把发货内容通过会话消息推给买家。关键词监控与行情参考对关键词、竞品链接进行监控整理同类商品的行情价和上新情况辅助自己定价补货。通知集成发货结果、库存预警、异常订单都可以推到钉钉、企业微信、Server酱这类渠道出门不带电脑也能第一时间掌握店铺状态。这套能力组合起来之后“闲鱼关键词监控”“闲鱼采集”“闲鱼行情价”这些大家在搜索的热词其实都能通过项目里的数据采集与监控模块得到一部分答案。它不只是一个发货机器人更像一个轻量级的店铺运营中台。1.3 为什么选择自建而不是买现成工具市面上确实有很多闲鱼管家、超级管家之类的第三方工具但实际用下来有几个问题一是价格不低按年付费功能还经常拆开卖二是核心数据全在别人服务器上店铺授权信息和订单数据都有安全隐患三是可定制性很差想要的功能没有不想要的功能天天弹窗。自建这套项目的好处首先是数据可控所有订单、卡密、配置信息都在自己手里。其次是可以自由扩展比如我把大模型接进去以后海外SEO工具的能力就自动长出来了买家咨询自动回复、差评预警、商品描述生成全都可以基于同一个底座继续叠功能。再有就是成本跑在一台低配云服务器上一个月几十块钱比按年订阅第三方工具要省得多。当然自建也有门槛至少要有最基本的命令行操作能力。不过别被吓到这篇文章就是从零开始带你搭起来。2. 环境准备与配置实操2.1 先把基础环境养熟Node.js、Git、MySQL 的安装要点这个项目属于 Node.js 生态所以本机环境至少要装三样东西Node.js、Git、MySQL。很多朋友卡在第一步就是环境变量没配好我在配置环境时也踩过几次坑这里把关键点都列出来。Node.js 建议装 16 到 18 的 LTS 版本太新或者太旧都可能出兼容性问题。装完以后在终端里执行 node -v 和 npm -v只要能看到版本号就说明环境变量没问题。Windows 上如果提示“node 不是内部或外部命令”多半是安装时没有勾选“Add to PATH”选项重装一遍勾上就行。macOS 用户可以顺手装个 nvm 管理版本切换起来会灵活很多。Git 的安装相对简单Windows 上就是一路下一步选默认组件就行。注意安装完以后最好配置一下用户信息不然后面提交代码或者拉取部分依赖时会报错git config --global user.name yourname git config --global user.email youremailexample.comMySQL 建议装 8.0 版本。很多新手在安装时容易忽略字符集和认证插件的问题导致项目连接数据库报错。建议在初始化时选 utf8mb4 字符集用户认证插件改成 mysql_native_password或者在项目连接串里指定 supportBigNumbers 和 decimalNumbers 等参数。这一步提前做好了后面初始化数据库表就不用反复折腾。装完 MySQL 之后顺手把服务启动起来记住 root 账号密码。如果你以前装过 MySQL 但密码忘了也不用重装用 mysqld --skip-grant-tables 方式进入安全模式重置就行不过重置完一定要记得退出安全模式再重启服务。2.2 项目拉取、依赖安装与数据库初始化环境就绪以后先把项目代码拉下来。XianYuAutoDeliveryX 的代码在 GitHub 和 Gitee 上都有镜像建议国内网络环境下优先用 Gitee 地址速度稳定很多GitHub 拉不下来的时候再切换源。git clone https://gitee.com/your-mirror/XianYuAutoDeliveryX.git cd XianYuAutoDeliveryX npm installnpm install 这一步对网络要求比较高如果速度慢可以临时切换镜像源npm config set registry https://registry.npmmirror.com依赖装完以后在项目根目录下找一份 .env.example 文件复制成 .env这就是全局配置文件。接着初始化数据库项目里通常带一份 schema.sql 或 init.sql用命令行导入即可mysql -u root -p schema.sql导入完成后进 MySQL 里看一下表结构是否完整重点确认几个核心表商品表、SKU表、卡密池表、订单表、监控任务表。如果这些表都在说明数据层已经就绪。2.3 配置项逐项拆解与环境变量说明.env 文件是项目的核心配置文件里面每一项都对应一个具体的功能模块。第一次配置的时候不要急着全填先搞明白每一项是干嘛的不然填错了排查起来很费时间。以下是我在实际使用中整理出的关键配置项APP_PORT服务监听端口默认 3000如果和本地其他服务冲突就换一个。DB_HOST、DB_PORT、DB_USER、DB_PASSWORD、DB_NAME数据库连接信息确认和本机 MySQL 的实际配置保持一致。ADMIN_TOKEN后台管理接口的访问令牌相当于管理端钥匙建议设置成一段随机长字符串。ORDER_POLL_INTERVAL订单轮询间隔单位是毫秒默认 5000 到 10000 都合理。间隔太短会频繁请求接口间隔太长则发货不够及时。NOTIFY_WEBHOOK通知回调地址可以是钉钉机器人、企业微信机器人或 Server酱的 Webhook。AI_PROVIDER、AI_API_KEY、AI_MODEL大模型相关配置对接完之后才用得到可以先留空。配置完以后用 node src/index.js 启动服务看到类似“server started on port 3000”的日志说明项目已经跑起来了。第一次启动建议先开着终端日志观察一下有没有数据库连不上、端口占用之类的问题。2.4 配置过程中的三个高频坑第一个坑是 MySQL 8 的密码认证问题。默认的 caching_sha2_password 认证方式在很多旧版 Node 数据库驱动下会报错“ER_NOT_SUPPORTED_AUTH_MODE”。解决办法是在 MySQL 里执行一条语句把用户改回兼容认证模式ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY yourpassword; FLUSH PRIVILEGES;第二个坑是.node 版本不匹配。有一次我用了 Node 20 启动项目结果 bcrypt 这个原生模块编译失败折腾了半个小时最后换回 Node 16 一切正常。所以如果你启动时看到 node-gyp 或者编译相关报错先别急着查依赖换个 LTS 版本试试往往就解决了。第三个坑是端口被占用。右键管理员身份打开终端执行 netstat -ano | findstr 3000 查一下端口占用进程把对应的 PID 进程结束掉或者直接改 APP_PORT 换一个端口。3. 自动发货核心机制与实战操作3.1 商品与卡密要怎么建模自动发货的前提是把商品的发货逻辑建模清楚。XianYuAutoDeliveryX 里一个商品底下可以挂多个 SKU比如“软件A标准版”和“软件A高级版”每个 SKU 对应一个独立的卡密池。卡密池里的每一条记录可以是一串激活码、一个网盘链接、一段手动备注也可以是任意自定义文本。商品建模时我建议按“类目、规格、发货内容、库存阈值”四个维度来设计。类目决定它归到哪个监控分组规格对应 SKU发货内容决定自动发货时发什么库存阈值则决定剩余多少条卡密时触发预警。比如某个商品SKU设置了20条卡密库存阈值设为5那么一旦库存低于5条系统就会通过通知渠道提醒你补货。这里要特别提醒商品上架时的标题和描述最好和内部商品名做区分。内部可以叫“软件A-高级版-第3批”但前台展示给买家的标题建议用相对宽泛的表述这样既能避免被同行抓取比价也能减少不必要的纠纷。3.2 自动发货的完整链路拆解自动发货不是简单地“收到订单→发一段文字”正常流程里至少要经过订单校验、库存预占、扣减库存、内容获取、消息推送、结果回写这六个步骤。订单校验这一步最容易忽略。系统监听到新订单后一定要先验证支付状态和买家留言防止买家拍下不付款就触发发货。库存预占的意思是先把库存锁定避免并发订单同时扣减到最后一条卡密时发生超卖。这两步做完以后才真正扣库存、取出发货内容。发货内容获取时系统会从卡密池里弹出一条未使用的记录并把它标记为“已使用”然后通过会话消息接口发送给买家。发送成功后订单表的状态会被更新为“已发货”同时记录一条完整的发货日志方便日后溯源。这套流程里的核心代码逻辑并不复杂把它简化成伪代码大概是这样的async function autoDeliver(order) { if (order.payStatus ! PAID) return; await lockStock(order.skuId); const card await getAvailableCard(order.skuId); if (!card) { await notifyAdmin(SKU ${order.skuId} 库存不足); return; } await markCardUsed(card.id, order.orderId); await sendMessage(order.buyerId, buildDeliverText(card.content)); await updateOrderStatus(order.orderId, SHIPPED); }这只是链路骨架实际项目里还会包含重试机制、幂等处理、异常告警。比如消息发送失败时要重试订单重复通知时要靠订单号幂等去重这些都是自动发货稳定性的保障缺一不可。3.3 关键词监控与行情参考的进阶玩法自动发货解决了“售后”问题但只守不攻也不行。XianYuAutoDeliveryX 的关键词监控模块可以让你实时盯住品类关键词的变化。比如你在卖某类软件激活码就可以把“某软件 激活码”“某软件 会员”这类词设置成监控任务每隔一段时间抓取一次搜索结果记录商品标题、价格、销量和卖家信息。这些数据积累下来以后有两个直接用途。第一个是定价参考通过整理同行的价格区间你可以把自己的商品价格调整到既有利润又有竞争力的位置。第二个是发现空白市场比如监控中发现某个关键词下面大部分卖家都只卖A版本没人卖B版本那你就可以迅速补上这个空缺。行情价分析这块我自己的做法是每周导出一份监控数据在表格里按价格和销量排序观察头部卖家的价格变动趋势。如果连续几天某个竞品都在降价可能说明它快要清仓了这时候我就不再压价跟进而是把重心放在服务差异化上比如更快的发货速度和更完善的售后说明。3.4 消息模板与通知渠道怎么选发货消息是买家的第一印象模板至少要包含三部分内容感谢语、发货内容、使用说明。如果是卡密类商品使用说明尽量写清楚比如“复制后进入软件输入激活码即可请勿重复激活”之类的提示。模板不要太长但关键信息一个都不能少。通知渠道的选择就看你的使用场景。自己一个人用Server酱推送到微信是最省事的团队协作的话钉钉或企业微信群机器人更合适因为可以在群里留底多人同时收到通知方便协作。我建议至少配两个渠道一个主用、一个备用因为单一渠道万一 Token 过期或者 Webhook 被禁你连库存告警都收不到。4. 对接大模型从客服到文案生成4.1 对接大模型能给这个项目带来什么自动发货之后人最常被绑住的就是咨询。买家问“这个是永久有效吗”“支持几个设备”“怎么安装”这些问题反复出现每个都答一遍非常熬人。把大模型接进来以后最直观的变化是这些重复咨询可以被 AI 直接回复而且话术可以根据你的风格动态生成。除了客服大模型还能做三件很有价值的事。第一件是商品描述生成给它几个关键词和卖点它就能输出多版标题和详情文案省去憋文案的时间。第二件是语义化的关键词分类可以把监控到的新商品按语义归入已有分类比纯规则匹配精准很多。第三件是情感分析和预警比如监控评论里出现“骗子”“不发货”这类情绪词时自动拉高预警等级让你第一时间处理口碑风险。换句话说大模型不是替代自动发货而是让整个自动化系统从“能干活”升级成“会思考”。这也是现在很多闲鱼自动化工具开始卷的方向。4.2 对接前的准备工作对接大模型之前先想清楚你要用哪个模型、哪个供应商。国内现在主流的方案包括阿里云百炼上的通义千问系列、DeepSeek、以及各类开源模型的中转服务。选型时主要看三点响应速度、单次调用成本、对中文的理解能力。做客服场景响应速度比生成质量更优先毕竟买家没有耐心等十几秒才看到回复。申请 API 的时候注意把 Key 保存好一旦泄露别人就能用你的额度。建议在项目配置里把 Key 放到 .env 环境变量里不要硬编码到代码中更不要把 .env 提交到 Git 仓库。还需要理解 Token 这个概念。Token 是模型计费的基本单位一个汉字大约占 1 到 2 个 Token。系统提示词、历史对话、模型输出都会消耗 Token所以长对话场景要设置最大 Token 数并定期清理历史消息防止成本失控。4.3 对接实操从申请到链路联调以大模型 API 对接为例完成申请后你会拿到 API Key 和接口地址。在项目里新增一个 aiClient 模块比如这样const axios require(axios); const AI_API_URL process.env.AI_API_URL; const AI_API_KEY process.env.AI_API_KEY; async function chatWithAI(messages) { const response await axios.post(AI_API_URL, { model: process.env.AI_MODEL, messages: messages, temperature: 0.7 }, { headers: { Authorization: Bearer ${AI_API_KEY}, Content-Type: application/json } }); return response.data.choices[0].message.content; } module.exports { chatWithAI };然后把这个模块接到客服线程上。当买家发来一条消息系统先判断是不是常见问题如果是高频问题就直接从关键词库找答案避免每个问题都走大模型节省成本只有规则匹配不到的时候才调大模型生成回复并设置超时兜底const answer await chatWithAI([ { role: system, content: systemPrompt }, { role: user, content: userText } ]).catch(() 抱歉我现在有点忙稍后人工回复您。);这样设计的好处是性能和成本都能兼顾。纯规则匹配处理 80% 的简单问题大模型只处理剩下 20% 的模糊问题既快又稳。联调时先用几个典型问题测一下比如“这个能用在几台电脑上”“Mac 能用吗”看模型回答是否符合你的商品规则。如果发现回答不准确不要急着换模型先优化 system prompt把商品规格、发货政策、禁忌事项写清楚效果提升会很明显。4.4 提示词设计关键与敏感内容兜底提示词设计直接决定了大模型回得靠不靠谱。客服场景的 system prompt 至少要包含以下几层信息角色定位、商品信息、服务规则、回复风格、边界兜底。下面是我比较常用的一套模板可以按你的商品类型微调你是【某店铺】的在线客服。你了解店铺内所有商品的信息包括激活码类商品的使用方式、售后退换规则。 回复要求 1. 语气友好但简洁尽量在50字以内 2. 如果涉及激活码或网盘资料直接告知使用步骤 3. 不承诺超出商品实际功能的内容 4. 当用户问价格、优惠、发货时间时按真实配置回答 5. 遇到无法确认的问题统一回复请稍等我为您转人工客服。兜底逻辑特别重要。大模型在某些情况下会一本正经地胡说八道比如买家问“这个软件能破解吗”这种内容一定要在提示词里明确禁止回答并且指定固定话术。更稳妥的做法是在调用前做关键词过滤命中敏感词后直接走人工不交给大模型处理。成本控制方面建议给单日调用量设一个上限超过之后自动降级为纯规则回复防止某个无聊买家反复刷问题把余额刷光。我就是被坑过一次后加的这道保险从那以后每个月模型费用都稳定在很低的范围。5. 常见问题与排查技巧实录5.1 环境部署类问题速查我整理了一份高频问题清单都是自己踩过或者帮朋友排查过的遇到类似情况直接对照处理现象可能原因解决办法node -v 找不到命令Node 未加入 PATH重新安装并勾选 Add to PATHnpm install 卡住网络问题切换 npmmirror 镜像源启动提示数据库连接失败MySQL 未启动或密码错误检查 MySQL 服务核对 .envER_NOT_SUPPORTED_AUTH_MODEMySQL 8 默认认证方式不兼容修改用户为 mysql_native_password端口被占用其他服务占用 APP_PORT换端口或结束占用进程原生模块编译失败Node 版本不匹配切换 Node 16/18 LTS很多环境问题都是基础配置引起的定位时先看日志再看配置最后才怀疑代码。项目日志里一般会明确提示哪一步失败了比如数据库连接、接口请求、文件读取按提示去排查往往五分钟内能找到原因。5.2 自动发货相关问题排查自动发货最常见的故障是“订单来了但不发货”。这种问题先不要急着重启服务按顺序查三处一是订单校验条件确认支付状态判断正确二是卡密池是否有可用库存很多情况是库存已经空了但预警没触发三是消息发送是否失败如果接口返回风控提示就要检查发送频率和内容。另一个典型问题是“重复发货”。通常是服务重启后未完成的订单又被重新扫描了一遍。解决办法是确认订单表的幂等判断发货前先查一下订单状态是否为“待发货”并且发货成功后立即更新状态。如果之前已经发过的订单不小心重复发货也别慌立刻给买家发消息解释并回收多余的内容能挽回大部分体验分。我处理过一次道歉及时买家也没给差评。还有“发货内容发错”的问题多半是 SKU 和卡密池的关联关系配错了。配置后一定要做一次测试下单不要直接拿真实买家当测试对象。5.3 大模型对接的坑与调优大模型接入初期最容易遇到请求超时。免费或者低价的模型服务端排队时间长前面一两秒没有响应前端就断了。解决方法是把超时时间放宽到 10 到 15 秒同时加一个“快速兜底回复”机制超时后立刻回复预设话术等人工来处理。Token 消耗过快也是常见问题。很多次我排查后发现是历史消息没有清理每一轮对话都带着几十轮以前的记录成本翻了好几倍。建议只保留最近五轮对话内容并且把 system prompt 精简到必要信息不要堆砌大量背景资料。内容被模型拒绝是另一类高频问题。虚拟商品容易涉及授权、激活等表述模型内置的安全策略有时候会误判导致正常的企业咨询也没法回答。这种时候不要强行改提示词去绕过而是把回复内容改得更中性一些比如“请查看商品页面说明”这类通用话术既能合规又不会卡住。5.4 账号安全与平台规则的底线提醒自动化工具是把双刃剑用得好是提效神器用不好就是封号加速器。我强烈建议把订单轮询间隔设置得保守一些不要在高峰期频繁批量触发操作。任何自动化行为都要控制在正常人类操作频率以内不要短时间大量关注、大量私信、大量重复请求。另外务必保证自动发送的内容真实可靠。虚拟商品的核心是信任如果买家付款后收到的卡密是无效的自动化发货反而会加速差评和举报。对于无法保证 100% 有效的商品建议在发货消息里附带售后说明和人工处理入口让买家感受到有兜底。最后说一句代码本身没有立场关键看使用者。用自动化去提升服务效率和经营体验是值得研究的方向但如果用来刷量、欺骗、绕过规则搞灰产那早晚要出问题。这套系统的正确用法是帮你把精力从重复劳动里解放出来放到选品、服务、供应链这些真正决定长期收入的事情上。我在实盘运行这套系统时最大的体会是技术不是最难的部分最难的是找到“自动化”和“用户体验”之间的平衡。买家不会因为你用了机器人觉得贴心他们只会在拿到货、解决掉问题的时候觉得靠谱。把发货做稳、把客服做活、把异常盯住这套系统就算真正跑出价值了。后续我打算继续给它加上多店铺管理和更细粒度的利润统计让数据不仅能发货还能指导选品等跑通了再来更新。