飞牛NAS搭建闲鱼AI监控：自动盯价+大模型筛选全攻略

蹲闲鱼这件事，我向来的看法是：它不是"运气活"，而是"技术活"。真正想蹲的东西——一台自组NAS用的硬盘、一颗停产很久的老镜头、或者某个只在小圈子里流通的电子产品——它的价格波动是有迹可循的，问题在于这些轨迹需要你24小时盯守才能抓住。人是盯不住的，机器可以。所以当我的飞牛NAS稳定运行一个月之后，我决定把闲鱼AI监控这件事彻底做完：自动盯价、大模型筛选、公网入口，一次全部配齐，让NAS每天替我盯着那几个关键词，降价了通知我，值不值得买让大模型替我判断，出门在外打开手机域名就能看现在的监控结果。

这套东西做完之后，我的生活里少了很多"半夜睡不着刷闲鱼"的焦虑。因为我知道，真要出现好东西，我的NAS会在几十秒内通知我。这篇文章就把整套方案的规划思路、技术细节和填坑记录完整写出来，给那些同样在折腾飞牛NAS、想搞点"自动盯价"玩意的朋友做个参考。

1. 为什么把闲鱼AI监控跑在飞牛NAS上，而不是买云服务器

1.1 飞牛NAS当"常驻机器人"的天然优势

飞牛OS这套系统我用了大半年，最深的感受是：它不像一台冷冰冰的存储设备，更像一个随时可以跑服务的Debian主机。飞牛OS基于Debian，自带Docker和Docker Compose环境，应用中心里点一下就能装Ollama这类大模型推理服务。一套NAS本来就要7x24小时通电，硬盘转着、网络跑着，顺带跑几个监控容器，功耗几乎可以忽略不计。

对比一下其他方案。买轻量云服务器，一个月少说二三十块，配置稍微高一点就得上百，而且数据在云端，心里总不踏实；用树莓派，折腾SD卡、供电、散热那一套，别的不说，性能拿来跑大模型基本是开玩笑。而飞牛NAS本身就是现成的：性能足够跑Docker和7B级别的大模型，存储备份天然齐全，自带DDNS和IPv6配置界面，对国内网络环境也友好。更贴心的是，飞牛的应用中心内置了Ollama，这意味着"跑大模型"这个动作被简化成了"点一下安装"。

提示：飞牛OS对Docker Compose是原生支持的，可以直接在Web界面里新建Compose项目。这一点比我在群晖上折腾容器时要省心太多——不用手动建任务、不用装第三方套件，路径挂载和网络模式都比群晖更直白。

1.2 一套系统拆开看：它到底解决了什么问题

买二手最痛苦的三件事：价格盯不住、信息看不全、时机抓不准。人工盯价的成本太高，闲鱼上商品状态瞬息万变，一个想蹲的东西可能几分钟内就被别人拍下。你做再多的搜索、再多的收藏，等你点进去的时候，货已经下架了。

这套闲鱼AI监控系统的核心逻辑是：把"盯"交给机器，把"判断"交给大模型，把"随时查看"交给公网入口。具体拆分下来，由四个模块组成：

• 采集模块：定时按关键词抓取闲鱼公开搜索结果，记录标题、价格、卖家、地区、发布时间和链接；
• 筛选模块：把原始商品信息喂给本地大模型，让模型从成色描述、价格合理性、卖家信用等维度打分，给出"是否值得关注"的结论；
• 通知模块：只把评分高且降价明显的商品推送到微信或钉钉，不让无关信息刷屏；
• 展示模块：一个本地Web页面，通过公网入口在手机上随时查看监控状态和筛选结果。

这个架构不是我做第一版就拍脑袋定下来的。最早我用纯规则脚本做，当时只写了个"关键词+价格区间"的过滤器，跑了一周发现一个问题：闲鱼上的商品标题和描述有大量噪音，比如有人把"几乎全新"写在标题里，发出来的却是一台进水机;有人标价极低，点进去才发现是"配件价"。"规则是死的，语言是活的"，这是我后来引入大模型筛选的根本原因。

2. 整体架构设计与技术选型说明

2.1 数据采集的技术路线：为什么选用Playwright

闲鱼没有开放公开的搜索API，网页版搜索结果在浏览器中可以访问，但不能简单用requests去拉。页面结构动态渲染，关键信息都藏在异步接口里，直接拉HTML只会得到一堆空壳。

我这里的做法是使用Playwright驱动一个无头浏览器，模拟真实用户访问搜索页，等待异步内容加载完成后再从页面节点中提取商品卡片数据。Playwright比Selenium更轻量，启动速度更快，对Chromium的兼容性也更好。在飞牛NAS的Docker里，我使用的是带Chromium的Playwright镜像，跑起来稳定，没遇到过崩溃。

实际提取的核心字段包括：宝贝ID、标题、价格（含原价）、卖家昵称、发货地、在售状态、商品链接、以及发布/最近编辑时间。宝贝ID是最重要的，它是去重和追踪价格的关键——一条商品一旦被记录，后续每次采集都通过这个ID更新它的最新价格。

注意：整个采集链路严格遵守两个原则。第一，只抓取"公开的搜索结果"，不触碰任何用户私密信息接口；第二，采集频率控制在分钟级，绝不使用并发高密度抓取。这套方案仅用于个人兴趣监控，请勿用于商业用途或对目标平台造成压力。

2.2 为什么选择Ollama本地跑大模型，而不是只靠云端API

有人会问：直接用云端大模型API不是更省事吗？我来说说为什么我优先选择本地部署。

第一，隐私考量。闲鱼数据里带卖家昵称、发货地、商品描述这些话，虽然是公开信息，但我不希望把自己的搜索意图和分析结果送到第三方API那边去。数据留在NAS本地，心理上踏实得多。

第二，成本考量。本地部署之后，我可以让模型一条一条精读每件商品，不用按token算钱。一天抓几百条，如果是云端API，积少成多也是一笔开销；本地部署没有这个压力，拉多少条都不心疼。

第三，部署难度其实已经被飞牛解决了大半。飞牛应用中心直接集成Ollama，安装完成后在终端里拉取模型就行。飞牛NAS装Ollama这件事，现在已经变成"应用中心点一下+命令行拉模型"，完全没有想象中那么复杂。

当然，本地跑7B模型的理解能力肯定不如云端大模型。如果你的NASCPU比较弱，跑7B模型会比较吃力，这时可以退而求其次改用云端的DeepSeek或通义API。我的建议是：优先本地，能跑通就用本地的；实在卡顿再退到云端API，数据敏感度自己权衡。

2.3 Docker Compose编排：一套配置全搞定

整套系统我用Docker Compose统一编排，最终目录结构类似这样：

version: "3.8" services: monitor: build: ./monitor environment: - KEYWORDS=富士xt30,腾龙17-70,ax86u - CHECK_INTERVAL=600 - OLLAMA_URL=http://ollama:11434 volumes: - ./data:/data restart: unless-stopped ollama: image: ollama/ollama:latest volumes: - ollama_data:/root/.ollama restart: unless-stopped web: build: ./web ports: - "127.0.0.1:8080:8080" volumes: - ./data:/data restart: unless-stopped caddy: image: caddy:2 volumes: - ./Caddyfile:/etc/caddy/Caddyfile - caddy_data:/data ports: - "80:80" - "443:443" volumes: ollama_data: caddy_data:

这样的编排带来的好处是：容器间用Docker内部网络互访，端口只暴露给Caddy，Caddy统一对外；需要迁移的时候把整个目录拷走，目标机器装好飞牛和Docker，一条docker compose up -d就全部恢复。我后来在另一台机器上验证过，从拷目录到系统恢复运行，前后不到十分钟。

3. 闲鱼自动盯价：采集与价格追踪的实现细节

3.1 搜索结果的解析与增量去重

采集模块的核心是一段定时任务，每10分钟跑一次。每次循环的步骤是这样的：

1. 读取关键词列表；
2. 对每个关键词拼接搜索URL，启动Playwright加载页面；
3. 等待列表渲染，通过CSS选择器定位商品卡片节点；
4. 逐条提取标题、价格、链接等字段，存入SQLite；
5. 对已存在的宝贝ID做更新，对新的宝贝ID做插入。

去重逻辑必须做对。如果只按"关键词+标题"去重，同一个宝贝出现在不同关键词下就会被记成两条，导致价格追踪错乱。我这里的做法是，每条记录以宝贝ID为唯一索引，更新时使用INSERT OR REPLACE，这样同一个宝贝无论出现在多少个关键词下，始终只有一条价格历史。

SQLite在低写入频率场景下非常稳定，不需要额外部署数据库服务，数据库文件放在NAS的存储卷里，靠飞牛自身的备份机制做快照保护，数据安全上够了。

3.2 价格变化追踪与降幅告警

价格追踪是一个宝贝ID对应多条历史价格记录。我维护一张item_history表，每次采集只要发现价格发生变化，就插入一条新记录。当判定降价幅度超过阈值时，触发告警。

阈值我设置为8%。低于8%的浮动容易误报，高于15%又容易漏掉真实捡漏机会。我实际跑下来，8%是一个合理的中间值。针对高价商品（比如超过3000元），绝对降价金额超过300元也可以触发通知，这两种逻辑用OR连接，覆盖面更全。

告警信息我通过Server酱推送到微信。Server酱的好处是接入成本极低，只需要一个SendKey，NAS上配置好Webhook就能推送。如果你更习惯用钉钉或企业微信，也可以用它们的自定义机器人Webhook，字段大同小异。

推送的内容模板大概长这样：

【捡漏提醒】腾龙17-70 当前价格：2480元（较上次下降200元） 卖家：xxx 地区：广东深圳 链接：https://... 模型评分：8.2 / 推荐关注

这里有个细节：推送里带的链接必须是宝贝在闲鱼APP内的可打开链接。闲鱼网页端的链接在APP里不一定能直接跳转，我通常会把宝贝ID拼成一个https://www.goofish.com/item?id=xxx的地址，实测在手机端点击后会自动唤起闲鱼。

3.3 采集频率、Cookie管理与合规底线

关于采集频率，我实测过多个档位：1分钟一次的暴利模式下，跑不到半天就会遇到验证码；3分钟一次偶尔触发；10分钟一次跑了两周没出过问题。所以最终我设定为600秒间隔，加上每次请求前随机延迟3到8秒。这套节奏模拟人工浏览的频次，实测下来最稳。

Cookie处理方面，闲鱼的搜索结果页不登录也能看一部分，但完整的商品列表需要登录态。我在本地的Cookie文件里保存了登录后的Cookie，采集时会加载。有几点经验：

• Cookie文件单独存放，路径挂载为/data/cookie.txt，绝对不要写进代码仓库；
• Cookie有过期时间，大概一周需要重新登录一次，我写了一个失效检测：如果采集结果连续3次为空，就触发"Cookie可能过期"的提醒；
• 不要在同一IP上同时跑多个闲鱼监控脚本，尤其是不要用轮换代理搞大规模抓取，那是给自己找麻烦。

再次强调：这套监控方案只针对公开搜索页，且频率远低于人类正常浏览。请务必遵守目标平台的用户协议，不要用于任何商业用途，也不要试图绕过平台的访问频率限制。我也只用了个人账号，没有做多账号矩阵。

4. 大模型筛选：让AI替你判断"值不值得买"

4.1 为什么纯规则过滤不够用

最初版本我写了一套规则过滤：排除标题含"瑕疵""维修""仅拆""配件"的商品，价格限定在预算区间内。跑了几天发现两个问题：

第一，误杀严重。有些卖家会写"轻微使用痕迹，不过敏不退换"，这其实是正常二手，大概率可以入手；但规则看到"使用痕迹"几个字就直接剔除了。还有些靠谱卖家为了防止纠纷，会主动写"划痕已拍出""避免售后纠纷"，这反而说明商品真实。规则引擎完全无法分辨这些细微差别。

第二，噪音残留。一个关键词搜出来，可能有几百条结果，里面有大量"蹲个有缘人""传家宝价格""懂货的来"这类描述。这类信息靠关键词过滤不掉，但大模型扫一眼就知道"这卖家在虚标高价"。

规则引擎的执行是"硬编码的偏见"，而大模型能做"语义层面的判断"。这是我最终决定把筛选环节交给大模型的根本原因。

4.2 在飞牛NAS上部署Ollama并拉取模型

飞牛OS的应用中心提供了Ollama一键安装。安装完成后，通过终端执行拉取模型命令：

ollama pull qwen2.5:7b

为什么选Qwen系列？首先，它对中文描述的理解能力在同类参数的模型中属于第一梯队；其次，Qwen的授权协议对个人使用友好，没有商用限制；再者，7B这个体量在飞牛NAS这类设备上可以跑。如果NAS的CPU性能更强或带有GPU，可以尝试14B版本，判断精度会更高。

Ollama跑起来之后，在容器内部暴露的端口是11434，其他容器可以通过http://ollama:11434访问。

补充：纯CPU推理的7B模型，判断一条商品通常需要5到15秒。好在筛选流程是异步批处理——采集完一批100条，后台慢慢跑模型筛选，全部跑完再统一更新结果。没有人会站在NAS前等实时响应，所以慢一点无所谓。

4.3 提示词设计：让模型输出可解析的决策

大模型筛选关键在提示词，如果把所有商品信息一次性丢给模型让它"总结"，它输出的内容会五花八门，没法稳定解析。我最终设计的提示词结构是这样的：

你是一名二手交易老手，请根据以下商品信息判断是否值得买入。 商品标题：{title} 商品描述：{desc} 价格：{price} 卖家：{seller}，地区：{region} 其他：{extra} 请输出JSON格式，严格包含以下字段： {"score": 0-10, "reason": "判断依据", "action": "buy/watch/pass"} 打分原则： - score >= 8 表示非常值得关注，action=buy - score 5-7 表示可以观望，action=watch - score <= 4 表示不值得，action=pass - 若描述中存在暗病、维修、拆机等问题，score上限为5 - 若价格显著低于同类均价，结合描述判断是否为骗局或配件机

提示词里加入了一个few-shot示例，让模型仿照输出JSON，能显著提高格式稳定性。同时，在解析代码里加了正则兜底：r'\{.*?\}'，从模型完整回复中提取第一大括号内容再转JSON。这样即使模型在回复前后夹带了自然语言，解析也不会失败。

4.4 筛选效果实例：从200条到3条

拿一个我实际监控的词组来说："富士xt30"。一次采集回来约200条结果，规则引擎先过滤掉50条明显无关的（如"富士排线""xt30外壳"），剩下约150条送进大模型。

模型跑完之后，建议"buy"的只有2条，建议"watch"的约14条，其余全部pass。我再人工复核那两条buy建议，其中一条确实是很合理的个人卖家——机身+电池，箱说全，快门数3000多，价格比市场均价低8%；另一条是商家在清库存，价格便宜但成色描述模糊，模型虽然给了buy但reason里写了"建议先联系确认成色"—这种提示非常关键，相当于AI把话说到一半，剩下靠你自己判断。

对比纯规则方案，大模型的优势不是"更聪明"，而是"更像一个有经验的买家"：它知道什么时候该谨慎，什么时候该果断。这种判断力，用户提供的规则列表是写不出来的。

5. 公网入口：在外面也能看监控结果

5.1 飞牛NAS的公网访问方案对比

监控和筛选跑在NAS上，结果如果只能在局域网里看，那这套系统的价值就打折了。我在地铁上突然收到降价通知，总得能点开看一眼详情吧。公网入口这块，我实际对比过三种方案：

我自己用的是方案一：IPv6直连+DDNS+反面代理。飞牛OS里内置了DDNS功能，支持多种域名服务商，我在路由器和NAS里把IPv6的防火墙放行策略配好，然后用DDNS把动态IPv6绑定到自己的子域名上。

5.2 Caddy反向代理与HTTPS证书

域名解析好之后，HTTP服务不能直接裸奔在公网上。我用Caddy做反向代理，原因只有一个字：省。Caddy自动申请和续期HTTPS证书，不需要像Nginx那样额外折腾certbot。

Caddyfile的核心配置如下：

monitor.example.com { reverse_proxy 127.0.0.1:8080 basic_auth { admin $2a$14$xxxxxxxxxxxx } }

这段配置做了两件事：一是把monitor.example.com的请求转发给本地Web服务；二是用basic_auth保护管理页面，没有密码的人打不开。第一次访问时Caddy会自动申请Let's Encrypt证书，之后自动续期，全程无人工干预。

需要说明的是，如果你家的IPv6端口443被运营商封了（部分地区确实如此），可以把Caddy的监听端口改成8443，Caddyfile里写monitor.example.com:8443，域名解析不变，访问时手动带端口号。这是我在国内网络环境下实测可用的一套降级方案。

5.3 安全加固的几条实操经验

公网入口开通后，安全是必须优先考虑的事。我做了这几个动作：

• 管理端加basic_auth，这是底线，不加等于把NAS管理页面敞开给别人；
• 只暴露Web服务，Ollama的API端口绝不直接暴露到公网，只允许Docker内网访问；
• 关闭不必要的公网端口，只开放Caddy的80/443或8443，其余端口一律不映射；
• 日志记录飞牛的防火墙开启访问日志，偶尔扫一眼，看到异常来源IP直接封禁；
• 定期更新镜像和系统补丁，飞牛OS的更新机制做得很简单，有新版本直接应用中心点更新。

我的实际结论是：NAS服务公网化最大的风险不是技术，是"偷懒"。只要把上面这几条做扎实，普通家用场景下的安全性是够用的。

6. 常见问题与排障实录

6.1 采集模块突然失效，怎么办

症状：连续几次采集结果为空，或者页面结构发生变化。

排查步骤：

1. 先用Playwright单独打开一次搜索页，看页面是否正常加载；
2. 打开浏览器开发者工具，检查商品卡片的CSS选择器是否变化——闲鱼页面改版会直接导致旧选择器失效；
3. 检查登录Cookie是否过期，登录态失效时可能拿不到完整结果；
4. 看日志里是否有验证码提示。

我遇到过最典型的一次，是闲鱼把搜索结果从一个接口切到了另一个接口，导致页面原本能直接拿到的文本变成了懒加载内容。解决办法是把等待条件从"等待某个元素出现"改成"等待价格字段出现"，并且增加重试逻辑，连续失败3次后自动退出当日采集，避免封号风险。

6.2 大模型返回的JSON格式不稳定

现象：模型偶尔会在JSON外面包一层"以下是分析结果："之类的文字，导致直接解析失败。

解决思路是双保险。第一层，在提示词里明确说"只输出JSON，不要任何解释文字"，大部分模型会遵守；第二层，解析代码里加正则提取大括号内容，再交给json.loads。如果正则也提取失败，就把这条记录标记为"解析失败"，下一轮重新判断。

另外，把Ollama的temperature参数设置为0或接近0，可以显著降低输出随机性。虽然这道命令要写进调用参数里，但很多人会忽略。

6.3 公网端口打不开

症状：手机流量下访问域名，浏览器转圈或直接超时。

排查优先级：

1. 先确认手机当前网络是否支持IPv6——有些手机默认走IPv4，需要检查开关；
2. 在电脑上用ping或nslookup确认DDNS解析出的IPv6地址是否更新到位；
3. 检查路由器或光猫是否放行了对应端口的入站IPv6流量；
4. 确认Caddy容器是否在正常运行，docker ps看一眼状态；
5. 如果以上都没问题，用curl -6 https://monitor.example.com从外部网络测一下连通性。

运营商封端口的场景，我已经在5.2节提到过，改用8443即可。如果是DDNS解析不更新，检查飞牛OS里的DDNS配置是否绑定了正确的网卡接口，IPv6地址经常有多个，绑定到错误的地址会导致解析到不可达的IP。

6.4 避坑清单：给准备复刻的人

最后整理一份我在整个过程中踩过的坑，按重要性排序：

• 不要用最新版Playwright镜像，用官方带版本的稳定tag，比如mcr.microsoft.com/playwright:v1.42.0，最新版有时和Chromium版本匹配出问题；
• 不要在Docker里直接用root跑采集容器，给容器指定一个普通用户UID，避免权限问题；
• 数据库文件和数据目录要单独持久化，容器重来一次数据就没了，那比丢掉代码还心疼；
• 第一次跑通后马上做一条模拟测试，故意改低价触发一次告警，验证整个通知链路是通的，别等到真有好货时才发现问题；
• 筛选结果建议人工复核一周，不要盲目信任大模型，特别是涉及"确诊"或"高价"的决策。

结尾：一点个人体会

这套系统跑在我自己的飞牛NAS上已经有两个多月，期间真正触发过三次值得下手的好价，其中两次通过模型评分高、价格降幅明显，我点进去确认后直接拍下，确实比市场均价便宜了不少。剩下一次因为犹豫了两分钟，被别人拍了，不过这正是捡漏的常态——抢不到才是正常的，能抢到算运气好。

我个人最满意的一点，是整套东西在本地闭环：从采集到模型判断，再到推送与访问，数据不离开自己的NAS。调试的时候在飞牛Web终端里敲几行命令，平时完全不用管，它就像一个安静的后台员工，默默帮我盯着那几个关键词。最后再分享一个小技巧：监控关键词不要总用一个固定的词，偶尔换一换写法，比如"xt30"和"富士xt30单机"搜出来的结果重合度有限，多关键词交叉覆盖能大大减少漏检。这套思路不止能用在大模型的部署，只要是"定时采集+智能判断+远程通知"的模式，几乎都可以搬到飞牛NAS上复用。