蹲闲鱼这件事我向来的看法是它不是运气活而是技术活。真正想蹲的东西——一台自组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_INTERVAL600 - OLLAMA_URLhttp://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内部网络互访端口只暴露给CaddyCaddy统一对外需要迁移的时候把整个目录拷走目标机器装好飞牛和Docker一条docker compose up -d就全部恢复。我后来在另一台机器上验证过从拷目录到系统恢复运行前后不到十分钟。3. 闲鱼自动盯价采集与价格追踪的实现细节3.1 搜索结果的解析与增量去重采集模块的核心是一段定时任务每10分钟跑一次。每次循环的步骤是这样的读取关键词列表对每个关键词拼接搜索URL启动Playwright加载页面等待列表渲染通过CSS选择器定位商品卡片节点逐条提取标题、价格、链接等字段存入SQLite对已存在的宝贝ID做更新对新的宝贝ID做插入。去重逻辑必须做对。如果只按关键词标题去重同一个宝贝出现在不同关键词下就会被记成两条导致价格追踪错乱。我这里的做法是每条记录以宝贝ID为唯一索引更新时使用INSERT OR REPLACE这样同一个宝贝无论出现在多少个关键词下始终只有一条价格历史。SQLite在低写入频率场景下非常稳定不需要额外部署数据库服务数据库文件放在NAS的存储卷里靠飞牛自身的备份机制做快照保护数据安全上够了。3.2 价格变化追踪与降幅告警价格追踪是一个宝贝ID对应多条历史价格记录。我维护一张item_history表每次采集只要发现价格发生变化就插入一条新记录。当判定降价幅度超过阈值时触发告警。阈值我设置为8%。低于8%的浮动容易误报高于15%又容易漏掉真实捡漏机会。我实际跑下来8%是一个合理的中间值。针对高价商品比如超过3000元绝对降价金额超过300元也可以触发通知这两种逻辑用OR连接覆盖面更全。告警信息我通过Server酱推送到微信。Server酱的好处是接入成本极低只需要一个SendKeyNAS上配置好Webhook就能推送。如果你更习惯用钉钉或企业微信也可以用它们的自定义机器人Webhook字段大同小异。推送的内容模板大概长这样【捡漏提醒】腾龙17-70 当前价格2480元较上次下降200元 卖家xxx 地区广东深圳 链接https://... 模型评分8.2 / 推荐关注这里有个细节推送里带的链接必须是宝贝在闲鱼APP内的可打开链接。闲鱼网页端的链接在APP里不一定能直接跳转我通常会把宝贝ID拼成一个https://www.goofish.com/item?idxxx的地址实测在手机端点击后会自动唤起闲鱼。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 表示非常值得关注actionbuy - score 5-7 表示可以观望actionwatch - score 4 表示不值得actionpass - 若描述中存在暗病、维修、拆机等问题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完全免费、速度稳定、不依赖中转需要家庭宽带支持IPv6大多数家庭用户首选内网穿透类服务无公网IPv4也能用流量限制或收费没有IPv6的备用方案光猫桥接公网IPv4端口映射兼容老设备需要联系运营商且公网IPv4地址越来越稀缺有条件拿到公网IPv4的用户我自己用的是方案一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会自动申请Lets Encrypt证书之后自动续期全程无人工干预。需要说明的是如果你家的IPv6端口443被运营商封了部分地区确实如此可以把Caddy的监听端口改成8443Caddyfile里写monitor.example.com:8443域名解析不变访问时手动带端口号。这是我在国内网络环境下实测可用的一套降级方案。5.3 安全加固的几条实操经验公网入口开通后安全是必须优先考虑的事。我做了这几个动作管理端加basic_auth这是底线不加等于把NAS管理页面敞开给别人只暴露Web服务Ollama的API端口绝不直接暴露到公网只允许Docker内网访问关闭不必要的公网端口只开放Caddy的80/443或8443其余端口一律不映射日志记录飞牛的防火墙开启访问日志偶尔扫一眼看到异常来源IP直接封禁定期更新镜像和系统补丁飞牛OS的更新机制做得很简单有新版本直接应用中心点更新。我的实际结论是NAS服务公网化最大的风险不是技术是偷懒。只要把上面这几条做扎实普通家用场景下的安全性是够用的。6. 常见问题与排障实录6.1 采集模块突然失效怎么办症状连续几次采集结果为空或者页面结构发生变化。排查步骤先用Playwright单独打开一次搜索页看页面是否正常加载打开浏览器开发者工具检查商品卡片的CSS选择器是否变化——闲鱼页面改版会直接导致旧选择器失效检查登录Cookie是否过期登录态失效时可能拿不到完整结果看日志里是否有验证码提示。我遇到过最典型的一次是闲鱼把搜索结果从一个接口切到了另一个接口导致页面原本能直接拿到的文本变成了懒加载内容。解决办法是把等待条件从等待某个元素出现改成等待价格字段出现并且增加重试逻辑连续失败3次后自动退出当日采集避免封号风险。6.2 大模型返回的JSON格式不稳定现象模型偶尔会在JSON外面包一层以下是分析结果之类的文字导致直接解析失败。解决思路是双保险。第一层在提示词里明确说只输出JSON不要任何解释文字大部分模型会遵守第二层解析代码里加正则提取大括号内容再交给json.loads。如果正则也提取失败就把这条记录标记为解析失败下一轮重新判断。另外把Ollama的temperature参数设置为0或接近0可以显著降低输出随机性。虽然这道命令要写进调用参数里但很多人会忽略。6.3 公网端口打不开症状手机流量下访问域名浏览器转圈或直接超时。排查优先级先确认手机当前网络是否支持IPv6——有些手机默认走IPv4需要检查开关在电脑上用ping或nslookup确认DDNS解析出的IPv6地址是否更新到位检查路由器或光猫是否放行了对应端口的入站IPv6流量确认Caddy容器是否在正常运行docker ps看一眼状态如果以上都没问题用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上复用。
