把 NAS 变成一台“闲鱼盯价机器人”这事我断断续续折腾了大半年。起因很简单我常年在闲鱼上蹲特定型号的二手硬件但手动刷真的太累了而且好东西基本是上架几分钟就被秒掉。后来看到飞牛 NAS 的 Docker 生态越来越成熟就想把采集、筛选、告警、远程查看这一整套逻辑全部塞进 NAS 里让机器 7x24 小时帮我盯着。这篇文章就把我完整搭起来的一套方案写出来包括自动盯价怎么实现、大模型筛选怎么接、公网入口怎么安全暴露以及这中间踩过的各种坑。适合已经有飞牛 NAS、想玩 Docker 和本地大模型、又对闲鱼捡漏有需求的朋友参考。1. 需求拆解与整体方案选型1.1 核心需求解析盯价、筛选、触达先把需求掰开。你要做的不是“写个爬虫抓闲鱼”而是围绕“低价捡漏”这个目标拆出三个层次的能力第一层是采集。得有人定时去逛你关注的搜索词或分类页把新上架的商品信息拿下来。闲鱼没有官方开放 API所以现实的做法就是浏览器自动化或者模拟客户端请求这个后面细说。第二层是筛选。原始的采集结果噪音非常大同一个搜索词下可能有大量和你不相关的东西、钓鱼链接、挂着低价实际引流的商品或者描述和标题严重不符的。这一层用大模型来过滤比单纯写规则要聪明得多。第三层是触达。发现符合条件的商品之后得用最快的方式通知你。推送到手机微信、钉钉、Telegram或者做一个简单的网页让在外面也能随时打开看。我最后选定的方案是飞牛 NAS 上跑 Docker 容器里面装 Python 采集服务 Ollama 本地大模型或 Dify 工作流 一个轻量的 Web 展示端公网访问走 IPv6 DDNS 反向代理。整套东西的成本就是 NAS 本身的电费没有额外的云服务器费用。1.2 为什么选飞牛 NAS 当底座飞牛 NAS 这个系统fnOS底层是 Debian 系的自带内核级 Docker 支持应用中心里能一键装 Docker、Dify、Ollama对玩 AI 的爱好者来说非常友好。相比群晖和威联通它对 x86 平台的兼容性更好老机器也能轻松跑起来配置要求低社区活跃遇到问题基本都能搜到答案。用它跑监控任务的另一个好处是资源利用率高。NAS 本来就是一直开机的设备顺手跑个 Python 脚本和轻量大模型推理对 CPU 的压力并不大。我实际测下来飞牛上跑一个“Qwen 2.5 7B”级别的量化模型做筛选任务在 8 代 i3 的机器上虽然推理速度不算快但胜在稳定、不占额外电费。如果只是做标题描述的分类和摘要换成 3B 甚至 1.5B 的小模型完全够用速度还能快一倍。还有一个很现实的原因飞牛自带 App 和文件系统管理日志、截图、临时文件的存储可以直接挂在 NAS 的共享目录里调试起来比纯服务器舒服很多因为出问题可以直接通过飞牛的文件管理器看容器里的输出文件不用每次 SSH 进去。1.3 整体架构与数据流整套系统的数据流是这样的采集脚本按设定的关键词和时间间隔去闲鱼搜索结果页获取商品列表提取标题、价格、链接、地区、卖家信息、发布时间。然后原始数据交给大模型筛选层筛选层输出“是否值得关注”“推荐理由”“预期价格区间”。通过筛选的商品进数据库再触发消息推送同时更新到 Web 展示页。这里有个关键设计采集和筛选是解耦的。采集只管把原始数据落盘存 JSON筛选层从 JSON 读取再处理。这样做的好处一是某个环节挂了不会影响另一个二是方便换不同的筛选策略比如今天用本地小模型明天想试试更强的大模型直接改配置就行不用动采集端。我把所有服务都封装成 Docker Compose 来管理。飞牛 NAS 的 Docker 容器在/vol1/docker目录下有持久化配置各服务的配置和数据库都挂载到 NAS 磁盘这样容器重建也不丢数据。2. 自动盯价采集端的实现细节2.1 闲鱼数据获取的合规边界与选型先说一个很多人容易忽略的点闲鱼目前没有公开的开放 API所有非官方方式的采集都属于灰色地带。我在做这整套东西时的原则是只采集公开的搜索结果页信息控制请求频率不登录不该登录的接口不绕过验证码和风控机制仅供个人参考使用。技术上我对比过两条路一是 Playwright / Selenium 这类真实浏览器驱动。优点是反爬识别率低因为直接模拟真实用户操作能等页面渲染完成再提取数据。缺点是比较吃内存每个浏览器实例至少占 300MB 到 500MB 内存在 NAS 上跑多个并发实例会比较吃力。二是直接用 HTTP 请求模拟。调闲鱼搜索接口就是网页端搜索时实际请求的那个 JSON 接口只需要维护好 Cookie 和请求头。优点是资源占用极低Python 脚本跑起来不到 100MB 内存可以并发多个关键词。缺点是接口字段变动需要跟着适配。我最后选的是第二条路。因为 NAS 上资源有限而且我只需要搜结果页的字段用 HTTP 请求做定时任务已经够稳。关键是请求头里的referer和user-agent要模拟真实浏览器同时控制好每次之间的间隔建议加 3 到 5 秒的随机延迟。2.2 采集服务的核心代码逻辑我先用 Python 写了一个最小可用的采集模块核心流程分四步构造请求 → 解析 JSON → 清洗入库 → 更新状态。构造请求这块要注意搜索接口需要几个参数关键词q、分页page、排序方式。闲鱼的默认排序是综合但如果是蹲低价建议用sortTypepriceasc按价格升序。另外可以加filter参数过滤掉已经下架的商品。解析阶段用一个简单函数从返回的 JSON 里提取itemId、title、price、location、sellerName、itemLink这些核心字段。有一点容易坑价格字段是字符串类型的有的商品价格会是价格面议这个必须过滤掉不然后面大模型分析时可能因为类型不统一出问题。清洗入库阶段我用的 SQLite。为什么用 SQLite 而不是 MySQL因为在 NAS 上跑单机任务SQLite 零配置、单文件备份就是复制一个文件完全够用。建表时最关键的是给itemId加唯一索引这是天然的幂等约束同一件商品重复采集到直接跳过避免重复推送。关键代码长这样import sqlite3 import time import requests HEADERS { user-agent: Mozilla/5.0 ..., referer: https://www.goofish.com/, } def fetch_search(keyword, page0): # 真实的接口参数需要自己抓包适配这里只展示结构 params { q: keyword, page: page, sortType: priceasc, } resp requests.get(SEARCH_API_URL, headersHEADERS, paramsparams, timeout10) if resp.status_code 200: return parse_items(resp.json()) return [] def save_item(conn, item): conn.execute( INSERT OR IGNORE INTO items (item_id, title, price, link, location, seller) VALUES (?, ?, ?, ?, ?, ?), (item[itemId], item[title], item[price], item[itemLink], item.get(location, ), item.get(sellerName, )) ) conn.commit()注意我在save_item里用了INSERT OR IGNORE配合唯一索引天然实现幂等。这个设计非常重要因为定时任务不像人手动操作可能一分钟就重复跑一次没有幂等的话数据库很快就塞满重复数据。2.3 定时调度与增量监控策略调度我用的是系统自带的 cron 或者飞牛 NAS 的“计划任务”。不建议在 Python 内部写while True sleep因为一旦脚本崩溃就没有自愈能力。用 cron 的话即使某次任务挂了下一次到点还会重新执行这就是最简单的容错。采集频次我建议分两种模式日常模式每 15 分钟跑一轮。这个频率对闲鱼的大部分更新足够了不会太频繁导致风控。重点蹲守模式针对个别特别关注的商品链接每 5 分钟单独调一次“宝贝详情”接口盯价格变动。增量监控还有一个“首次启动”的问题。第一次跑的时候你会抓到搜索页前几页的存量商品这些商品可能已经上架很久不该触发告警。我的做法是加一个first_seen_at字段只有在当前时间减去上架时间小于 6 小时的商品才算“新品”才进入大模型筛选流程。存量商品只入库不推送。这样第一天运行不会给你推几十条过期的无用信息。另外还要做轮询和退避。如果某一次请求连续失败超过 5 次就把这个关键词的采集暂时停掉等 30 分钟后再试。因为闲鱼的接口如果请求频率太高会被临时限流继续硬刚只会让 IP 风控加重。飞牛 NAS 本身是家庭宽带 IP被限流了很难恢复所以保守调度比什么都重要。3. 大模型筛选层把噪音变成有效信号3.1 本地大模型与云端 API 的取舍采集来的原始数据字段很简单但真正判断“这个商品值不值得买”需要复杂的语义理解。比如标题是“自用 i5-8400 主机 几乎全新 可小刀”具体是什么品牌、什么配置、是否包含显卡、价格是否合适这些信息靠正则和规则很难写全。这时候就需要大模型。选型上有两条路第一条是云端 API。接入像 DeepSeek、GLM 这种商用 API效果好速度快按量付费。问题是要把商品数据发到第三方服务器虽然敏感度不高但如果你介意数据外传就不太合适。第二条是本地部署。飞牛 NAS 上装 Ollama拉一个 Qwen 系列的量化模型完全离线运行。飞牛的应用中心里有 Ollama 的一键安装装完之后就是拉模型、调用接口。有 16GB 内存的话跑 7B 模型没问题8GB 内存建议跑 3B 或 1.5B 模型。我的结论是如果 NAS 内存够优先本地跑 3B 级别的模型。虽然效果不如云端的大模型但处理“标题价格描述是否值得关注”这种轻量任务已经足够了。而且本地推理没有网络延迟也没有外发数据的心理负担成本是零。实际上我在飞牛上还试过用 Dify 搭工作流来接 Ollama。飞牛 NAS 安装 Dify 的教程网上已经很成熟了Dify 里面配好模型供应商然后把商品信息作为用户输入通过工作流节点的提示词模板做结构化输出输出格式直接用 JSON。好处是后续改提示词不用改代码直接在 Dify 界面上调这一点在后期优化筛选效果时非常省事。3.2 提示词设计让模型学会“值不值得买”提示词是整个筛选层效果好坏的最大变量。我试过很多版本最有效的提示词结构大概是这样的你是二手交易平台的资深买家。请分析给定商品信息判断是否值得关注。 商品信息如下 标题{title} 价格{price} 地区{location} 卖家{seller} 描述{description} 请输出以下 JSON 1. worthy: true/false是否值得关注 2. reason: 一句话推荐理由 3. suggested_price_min: 建议出价下限整数 4. suggested_price_max: 建议出价上限整数 5. risk: 可能的风险点如“来源不明”“描述不符” 判断标准 - 价格明显低于同型号市场均价时 worthytrue - 描述包含“贩子”“工作室”“只出同城”等高风险词时 worthyfalse - 描述信息过少且价格偏离常识时 risk 标为 high 只输出 JSON不要解释。为什么这么写因为让模型做“是否值得关注”这种判断本质上是让它在约束下做分类。你给的字段越结构化它的输出越稳定。我试过一开始让模型自由发挥写“一段分析”结果输出格式五花八门没法解析。改成强制输出 JSON 之后解析成功率几乎 100%。这里不得不提“提示词工程与上下文工程”的区别。提示词工程管的是单次输入的指令质量上下文工程管的是你给模型多少参考信息。在这个场景里参考信息就是收集到的历史成交价、当前同类商品均价。如果你能在提示词里加一句“同类商品近期成交均价约 500 元此商品标价 350 元”模型的判断准确率会明显提升因为它有了坐标系。3.3 接入方式与异步处理筛选层接入采集端有三种方式最直接的是同步调用。采集脚本拿到商品列表后逐条调用 Ollama API拿到结果再入库。优点是逻辑简单缺点是慢。在普通 CPU 上跑 3B 模型单条推理可能 2 到 5 秒。一次抓 40 条就要三四分钟非常拖沓。我实际用的方式是异步消息队列。采集端抓到原始数据后直接丢进一个 Redis 列表或者 SQLite 待处理队列就完事筛选进程单独跑每次从队列里取一批商品处理。这样采集端保持轻快筛选端也能批量推理减少模型加载和释放的开销。实测下来批量处理的速度比单条逐条调用快好几倍。还有一个细节是大模型的流式输出。飞牛 NAS 的 Ollama 是支持 SSE 流式输出的但在这个场景里我其实不建议用流式。因为我们需要的是最终的 JSON 完整结果流式只是逐字返回反而增加了解析难度。流式输出更适合 Web 聊天这种需要实时渲染的场景比如你自己搭一个飞牛 NAS 上的 AI 聊天页面配合abort实现停止生成。但做筛选任务直接等完整输出更稳妥。最后筛选结果的入库字段可以这样设计ALTER TABLE items ADD COLUMN worthy INTEGER DEFAULT 0; ALTER TABLE items ADD COLUMN reason TEXT; ALTER TABLE items ADD COLUMN risk TEXT DEFAULT low; ALTER TABLE items ADD COLUMN suggested_price_section TEXT;自动盯价到这里才完成闭环采集落库 → 模型判断 → 入库标记 → 推送告警。3.4 模型误判与阈值调整的实操经验大模型筛选不是百分之百准确我跑了一个月后总结出几类典型误判第一类是价格误判。比如洗版书或瑕疵品价格低得离谱是正常的。模型不知道“瑕疵”“缺角”“无包装”意味着价格可以腰斩。我的解决办法是在提示词里增加一条规则如果描述中包含瑕疵/破损/缺角/无配件等词降低预期价格区间但不提升风险等级。加了之后误报率下降非常明显。第二类是标题党误判。有些卖家标价 1 元实际上写的是“价格私聊”模型会以为捡到漏了。我后来在采集端就过滤掉所有价格小于 5 元的商品这不光是为了减少模型误判更是为了降低推送骚扰。第三类是上下文缺失。单看一条商品信息模型不知道这个型号的正常行情所以容易把“正常价”当成“高价”或者把“合理价”当成“低价”。我建议给提示词补充一个市场价格区间。最简单的方式是采集端维护一张价格表定期跑一次“同类商品价格统计”任务把近 30 天同关键词商品价格的中位数写进去再传给大模型。阈值调整方面我建议你把“值得关注”的标准先放宽一点宁可多推几条也不要漏掉真正的好东西。跑几天之后根据实际的推送记录和点击转化情况再收紧。比如我最初的阈值是“价格低于市场均价 15% 才算值得关注”跑了几天发现漏了不少好货因为有些商品虽然价格不低但东西稀有后来加了“稀有度”字段让模型额外判断是否属于停产/稀缺型号综合评分后再决定是否推送。4. 公网入口与应用集成方案4.1 用 IPv6 DDNS 解决外部访问监控和筛选都跑通了接下来一个很实际的问题是人不能老坐在家里看屏幕。上班路上、出差在外怎么随时看 NAS 上的监控结果这就涉及到公网访问。飞牛 NAS 默认支持 IPv6而且现在的家庭宽带基本都分配了 IPv6 地址。只要你的路由器和光猫开启了 IPv6飞牛就能拿到一个公网 IPv6 地址。和 IPv4 不同家庭宽带的 IPv6 地址是不需要端口映射的外部网络可以直接访问。但 IPv6 地址是动态的每次拨号可能都变所以要做 DDNS。飞牛系统自带 DDNS 功能支持阿里云、DNSPod 等主流服务商。在飞牛后台填好你的域名和 API Token系统会自动把当前 IPv6 地址更新到域名解析记录里。这样你在外面只需要记住自己的域名就能访问了。DDNS 这块有一个可能踩坑的点宽带分配的 IPv6 地址有可能是临时地址privacy扩展它是定期变化的。飞牛的 DDNS 在设置时最好绑定网卡的主地址或者建议使用系统里显示的那个“全局地址”而不是临时地址。否则你会发现域名解析的 IP 每隔几个小时就失效。手机流量访问 IPv6 还有一个额外的隐蔽坑部分运营商在手机数据网络下默认不分配 IPv6 地址。我自己就遇到过在家 WiFi 下能打开一出门用 5G 反而打不开。解决办法是找一个支持 IPv4 的备用的入口或者切换到支持 IPv6 的运营商套餐。这个只能自己实测不同运营商差别很大。4.2 反向代理与安全加固暴露到公网的服务必须做安全加固。我强烈建议不要直接暴露裸机的端口而是加一层反向代理统一走 HTTPS。飞牛 NAS 本身自带一个反向代理设置但如果你已经在跑 Docker更灵活的做法是用 Nginx Proxy ManagerNPM或者 Caddy 这个容器来做。Caddy 配置最简单自动申请 Let‘s Encrypt 证书不用手动续期。我最终用的就是 Caddy配置文件只有几行yourdomain.com { reverse_proxy 127.0.0.1:8080 }配置好之后外部访问https://yourdomain.com就能打开 Web 管理端。这里要注意的是你的 Caddy 容器需要监听在 IPv6 地址上。飞牛的 Docker 网络默认是bridge模式要保证 Caddy 容器能通过 IPv6 访问需要在docker-compose.yml里开启 IPv6 支持具体是在网络配置里加enable_ipv6: true。安全层面至少要做到三件事服务不开公网端口。最好只开放 443HTTPS和 80Caddy 自动跳转其余所有端口都关闭公网映射。这样即使某个服务有漏洞攻击者也只能走到你的代理层不能直接打后端。加强认证。Caddy 本身没有用户认证我的做法是在 Web 应用前面加一层 OAuth2 Proxy对接 GitHub 或 Google 登录。飞牛系统自带用户管理如果直接映射飞牛的网页开启两步验证也能挡掉大部分风险。限制来源 IP 和失败重试。Caddy 可以配合插件做request_ip限制只允许几个常用出口 IP 访问管理端。手机上 IP 总变的话可以放宽一些。另外在系统层面开一个简单的 fail2ban 规则如果短时间内同一来源 IP 反复触发认证失败直接封禁一段时间。4.3 告警推送与 Web 展示面板推送告警是我觉得整套项目最依赖的模块。采集和筛选做得再好如果人不能第一时间收到通知抢漏就无从谈起。我试了几种方式最省事的是Server 酱。它是一个把消息推送到微信的服务免费版够用请求接口就是一个 URL把标题和内容拼进去就行。缺点是微信端小程序的使用体验一般但推送速度很快。另一个选择是钉钉/企业微信机器人。在钉钉群里添加自定义机器人把 Webhook 地址填到 NAS 的推送配置里就可以往群里发消息。适合多个人一起盯同一个关键词的场景。最后是Telegram Bot如果你是 TG 重度用户这个体验是最好的。飞牛 NAS 上用 Python 调 Bot API 很稳定而且支持 Markdown 格式的消息可以把推荐理由、商品链接排版得清楚好看。我最终的组合是Web 展示面板为主Server 酱作为 “紧急低价”的即时推送。Web 面板我自己写了一个极简的 Flask 应用只有一张表格商品标题、价格、推荐理由、链接、状态。部署在 Caddy 后面加个登录密码手机上浏览非常舒服。这套方案的展示面板在 500 个商品以内的规模完全无压力。如果数据量大了Flask 加 SQLite 的性能也就够跑因为单用户访问的频率很低不需要引入前端框架。5. 常见问题与避坑实录5.1 高频故障问题速查表问题现象可能原因解决办法采集脚本一直报 403 或验证码请求频率过高被风控降低频率增加随机延时检查请求头完整性大模型输出不是合法 JSON提示词不够结构化强制在提示词里约定 JSON 格式增加错误重试机制外部无法访问 Web 面板IPv6 地址变化或运营商不分配启用 DDNS确认手机网络支持 IPv6加 IPv4 备用入口Caddy 容器日志提示证书申请失败DNS 解析未生效检查 DDNS 更新状态确认域名解析后等待 5 分钟再重启 Caddy推送重复收到同一条商品缺少幂等约束确保itemId有唯一索引推送前检查notified_at是否为空大模型推理速度太慢模型参数过大换成 1.5B/3B 模型或者用量化版本Q4 甚至 Q3数据库文件越来越大采集了过多历史数据定期清理过期数据保留近 30 天即可5.2 我在实际部署中踩过的三个大坑第一个坑是闲鱼接口字段变更导致的解析全挂。某一天我开始收到parse_items函数疯狂报 KeyError打开原始 JSON 才发现接口返回的字段层级变了itemId被嵌套到了data.items下面。从那以后我养成了一个习惯采集脚本每次启动时先跑一次“字段自检”如果连续 3 条记录都解析不到核心字段就发一条警告通知到手机而不是继续把错误数据入库。这样可以第一时间发现接口变更不至于默默丢失一大段时间窗口的采集。第二个坑是Ollama 模型换成了不合适的量化版本。一开始我图省事拉了一个 Q8 版本的 7B 模型结果推理速度慢到没法用内存也爆满把飞牛 NAS 卡得 UI 都打不开。后来换成 Qwen2.5-3B-Instruct-Q4_K_M速度提升了 4 倍左右筛选效果在“值不值得买”这种任务上差距不大。这件事给我的教训是在 NAS 上跑模型先从小模型、低量化开始跑通了再想升级。第三个坑是公网访问的安全被忽略。最初我只是把 Flask 应用直接映射到公网端口没加任何认证结果某天查看访问日志发现有人疯狂尝试登录。从那以后我把端口映射全部撤掉统一收口到 Caddy OAuth2 Proxy 后面才把心放下来。5.3 硬件、功耗与长期运行建议如果你也想照着这套方案跑硬件方面我提几点建议内存至少 16GB。8GB 内存可以跑但你要在 OLLAMA 模型精度的选择上做出很大妥协。16GB 是一个比较舒服的点可以跑 3B 到 7B 级别的量化模型同时 NAS 的其他服务也不会被挤掉。CPU 不是瓶颈。这类任务对单核性能更敏感不用追求多核但散热很重要。NAS 长期 7x24 运行夏天如果机箱散热不好Docker 容器可能因为过热自动重启我遇到过好多次。存储用固态。采集数据量不大但 SQLite 频繁读写机械硬盘的寻道时间会拖慢整个服务换成 SSD 后整个面板打开速度明显提升。长期运行方面我建议每周末安排一个定时任务清理一次数据库中的“已下架”商品保留值得关注的记录就行。同时给 Docker 容器设置restart: always这样飞牛 NAS 重启或容器崩溃后可以自动恢复。6. 实际运行效果与我的经验体会这套东西跑了大半年最直观的感受是“盯漏这件事真的可以被自动化”。我设置的几个关键词里系统成功捕捉到过几次价格明显低于均价的商品其中一台老款 ThinkPad 让我用比市场价格低 30% 的价格拿下了。虽然大部分时候推送过来的还是些普通商品但大模型筛掉接近 90% 的垃圾信息推送质量已经相当高。说到技巧我再分享两个小细节。第一个是关键词的设置别只设一个太宽泛的词比如“1060显卡”你可以拆成“1060 6g”“1060 便宜”“1060 自用”几个词不同词的调度频率和推送阈值可以不一样。第二个是每天凌晨自动跑一次“市场价统计”把同关键词近 30 天成交价格的中位数算出来第二天筛选时模型就有一份当日的价格参照系识别“真漏”的能力会明显提升。如果你飞牛 NAS 上已经折腾过 Dify 或者 Ollama这套方案的上手成本其实很低。采集脚本和推送逻辑是固定套路真正需要花时间调试的是大模型的提示词和阈值。我建议你从最简单的“采集 价格阈值过滤 微信推送”开始先把闭环跑起来再往里面加大模型筛选一步步调优。毕竟能稳定运行的简单方案永远比三天两头出问题的复杂方案更有价值。
