ai-goofish-monitor 是 Usagi-org 開源的閒魚商品監控系統。

它的目標很明確：把閒魚搜尋、篩選、商品分析、結果記錄和通知推送自動化，幫助使用者從大量二手商品裡更快找到符合條件的目標。專案基於 Playwright 做頁面自動化，再接入支援圖片輸入的 AI 模型，對商品資訊做進一步判斷。

專案地址：https://github.com/Usagi-org/ai-goofish-monitor

先說結論

ai-goofish-monitor 更像一個「閒魚採購情報面板」，而不是簡單的關鍵字提醒腳本。

它有幾個明顯特點：

• 有完整 Web 管理介面，可以管理任務、帳號、AI 標準、日誌和結果。
• 支援多任務並發，每個任務可以配置關鍵字、價格、篩選條件和 AI Prompt。
• 使用 Playwright 抓取閒魚頁面，適合處理需要登入態和頁面互動的場景。
• 使用 AI 判斷商品是否符合需求，不只依賴關鍵字匹配。
• 支援 ntfy.sh、企業微信、Bark、Telegram、Webhook 等通知渠道。
• 支援 Cron 定時任務、多帳號管理、代理輪換、失敗重試和 Docker 部署。

它適合經常在閒魚找特定商品的人，比如二手數位產品、攝影器材、顯卡、硬碟、遊戲機、樂器、家電和收藏品。但它也不是「自動撿漏神器」。閒魚搜尋結果本身會變，帳號登入態可能失效，平台風控也會影響自動化穩定性。使用時更應該把它當成輔助篩選工具，而不是完全替代人工判斷。

它解決什麼問題

在閒魚上找二手商品，經常有幾個痛點：

• 商品太多，手動翻很累。
• 標題和描述不規範，關鍵字很容易漏掉或誤判。
• 好價格出現時間短，發現太晚就沒了。
• 同一個商品可能有多個地區、價格、成色和賣家差異。
• 低價商品裡混著配件、損壞品、翻新貨和誘導性標題。
• 想持續盯多個關鍵字時，手動搜尋很難堅持。

普通關鍵字提醒只能解決一部分問題。比如你搜尋「ThinkPad X1」，可能會混入配件、壞屏、空盒、拆機件；你搜尋「索尼 A7C」，又可能遇到鏡頭套裝、租賃資訊、標題黨和價格異常。

ai-goofish-monitor 的思路是：先用自動化把候選商品抓出來，再交給 AI 按你的需求做二次判斷，最後把值得關注的結果推送給你。

核心功能

專案 README 裡列出的核心能力比較完整：

• Web 視覺化管理：任務管理、帳號管理、AI 標準編輯、運行日誌、結果瀏覽。
• AI 驅動：支援自然語言建立任務，並用多模態模型分析商品。
• 多任務並發：不同任務可以獨立配置關鍵字、價格、篩選條件和 AI Prompt。
• 進階篩選：支援包郵、新發布時間範圍、省 / 市 / 區三級區域篩選。
• 即時通知：支援 ntfy.sh、企業微信、Bark、Telegram、Webhook 等多渠道。
• 定時調度：支援 Cron 配置週期性任務。
• 帳號與代理輪換：多帳號管理、任務綁定帳號、代理池輪換與失敗重試。
• Docker 部署：支援容器化部署。

這些能力組合起來，覆蓋了從「建立監控任務」到「收到命中提醒」的完整鏈路。

工作流是什麼樣

一個典型流程大概是這樣：

1. 部署服務並打開 Web UI。
2. 匯入閒魚帳號登入態。
3. 建立監控任務。
4. 設定關鍵字、價格區間、地區、新發布範圍等篩選條件。
5. 編寫或讓 AI 生成判斷標準。
6. 任務按即時或定時方式運行。
7. Playwright 打開頁面並抓取商品資訊。
8. AI 根據標題、描述、圖片和 Prompt 判斷是否符合需求。
9. 命中結果寫入 SQLite。
10. 系統透過配置的通知渠道推送結果。
11. 使用者在 Web UI 裡查看結果、日誌和價格歷史。

這個流程裡，AI 的價值主要在第 8 步。它可以理解「我想要成色好、價格合理、不要配件、不要維修機、最好同城自取」這類自然語言條件，比單純關鍵字規則靈活。

Docker 部署

專案推薦使用 Docker 部署：

1
2
3
4
5
6

git clone https://github.com/Usagi-org/ai-goofish-monitor && cd ai-goofish-monitor
cp .env.example .env
vim .env
docker compose up -d
docker compose logs -f app
docker compose down

預設 Web UI 地址是：

1

http://127.0.0.1:8000

官方映像地址是：

1

ghcr.io/usagi-org/ai-goofish:latest

如果映像存取慢，README 裡也給了加速映像示例：

1
2
3

docker pull ghcr.nju.edu.cn/usagi-org/ai-goofish:latest
docker tag ghcr.nju.edu.cn/usagi-org/ai-goofish:latest ghcr.io/usagi-org/ai-goofish:latest
docker compose up -d

Docker 映像已內建 Chromium，不需要宿主機額外安裝瀏覽器。預設持久化目錄包括：

• data/：SQLite 主儲存，保存任務、結果和價格歷史。
• state/：登入狀態 cookie 文件。
• prompts/：任務提示詞。
• logs/：運行日誌。
• images/：商品圖片和任務臨時圖片目錄。

如果修改了 .env 裡的 SERVER_PORT，也要同步調整 docker-compose.yaml 的連接埠映射。

最少配置

專案的最少配置主要圍繞 AI 模型和 Web UI 登入：

1
2
3
4
5

OPENAI_API_KEY=your_api_key
OPENAI_BASE_URL=your_openai_compatible_base_url
OPENAI_MODEL_NAME=your_multimodal_model
WEB_USERNAME=admin
WEB_PASSWORD=change_me

其中前三項是 AI 模型接入必填項：

• OPENAI_API_KEY：模型 API Key。
• OPENAI_BASE_URL：OpenAI 相容介面地址。
• OPENAI_MODEL_NAME：支援圖片輸入的模型名稱。

WEB_USERNAME 和 WEB_PASSWORD 用於 Web UI 登入。README 提到預設帳號密碼是 admin/admin123，生產環境必須修改。

第一次使用

第一次使用時，流程大致是：

1. 打開 http://127.0.0.1:8000。
2. 登入 Web UI。
3. 進入「閒魚帳號管理」。
4. 使用專案提供的 Chrome 擴充套件匯出閒魚登入態 JSON。
5. 把登入態貼到系統裡。
6. 登入態文件會保存到 state/，例如 state/acc_1.json。
7. 回到「任務管理」，建立任務並綁定帳號。
8. 運行任務並查看結果。

這裡最關鍵的是登入態。由於閒魚並不是開放給第三方隨意抓取的標準 API，專案需要用瀏覽器登入狀態來模擬正常頁面存取。登入態失效、風控、驗證碼、帳號異常都會影響任務運行。

AI 任務和關鍵字任務

專案支援兩類任務建立方式。

第一類是 AI判断。

你可以填寫「詳細需求」，提交後系統會非同步生成分析標準。適合需求比較複雜的場景，例如：

• 只要主機本體，不要配件。
• 價格明顯低於市場價才提醒。
• 成色要好，描述裡不能有進水、維修、暗病。
• 優先同城，能面交更好。
• 圖片裡要能看到序列號、包裝或關鍵配件。

第二類是 关键词判断。

它更接近傳統規則監控：根據關鍵字、價格、地區等條件直接建立任務，不經過 AI 生成流程。適合規則簡單、誤報可以接受的場景。

實際使用中可以混合使用：關鍵字負責初篩，AI 負責減少誤報。

Web UI 能做什麼

Web UI 是這個專案區別於普通腳本的重要部分。

任務管理頁可以配置：

• AI 建立任務。
• 關鍵字規則。
• 價格範圍。
• 新發布範圍。
• 區域篩選。
• 帳號綁定。
• 定時規則。

帳號管理頁可以：

• 匯入閒魚帳號登入態。
• 更新登入態。
• 刪除帳號。
• 為任務指定帳號。
• 讓系統自動選擇帳號。

結果和日誌頁可以：

• 查看命中商品。
• 匯出結果。
• 查詢歷史記錄。
• 查看任務運行過程。
• 排查登入態失效、風控和 AI 調用問題。

系統設定頁可以：

• 查看系統狀態。
• 編輯 Prompt。
• 調整代理和輪換配置。

對於長期監控來說，Web UI 很關鍵。否則任務一多，配置、日誌、結果和通知都會變得難維護。

資料儲存

專案目前在線主儲存使用 SQLite，預設路徑是：

1

data/app.sqlite3

Docker 預設把 SQLite 主庫掛載到：

1

./data:/app/data

應用啟動時會自動建庫建表，並嘗試從舊的 config.json、jsonl/、price_history/ 匯入一次歷史資料。

需要注意的是，state/、prompts/、logs/、images/ 仍然是檔案系統目錄，不在 SQLite 中。商品圖片會臨時保存到類似下面的目錄：

1

images/task_images_<task_name>/

任務結束後預設會清理。

這種結構比較適合個人或小團隊部署：SQLite 足夠輕，遷移也簡單；檔案目錄保留登入態、圖片和日誌，排查問題更直觀。

通知渠道

專案支援多種通知渠道，常見配置包括：

• NTFY_TOPIC_URL
• GOTIFY_URL / GOTIFY_TOKEN
• BARK_URL
• WX_BOT_URL
• TELEGRAM_BOT_TOKEN / TELEGRAM_CHAT_ID / TELEGRAM_API_BASE_URL
• WEBHOOK_*

通知是這類工具的核心體驗。監控系統如果只把結果寫進後台，使用者仍然需要反覆打開頁面查看；有推送之後，命中商品才能在第一時間觸達。

更實用的配置方式是按商品價值分層：

• 普通關鍵字命中只寫入後台。
• AI 高置信度結果推送到手機。
• 高價值商品推送到企業微信或 Telegram。
• 調試階段開啟更多日誌，穩定後減少噪音。

開發者運行

如果不使用 Docker，本地開發需要：

• Python 3.10+
• Node.js + npm
• Playwright CLI
• Chromium 或 Chrome / Edge 瀏覽器

基礎命令：

1
2
3

git clone https://github.com/Usagi-org/ai-goofish-monitor
cd ai-goofish-monitor
cp .env.example .env

一鍵啟動：

1
2

chmod +x start.sh
./start.sh

start.sh 會檢查 Playwright CLI 和瀏覽器條件，自動安裝依賴、建置前端、複製建置產物並啟動後端。

手動啟動後端：

1

python -m src.app

或者：

1

uvicorn src.app:app --host 0.0.0.0 --port 8000 --reload

前端開發：

1
2
3

cd web-ui
npm install
npm run dev

測試和建置：

1
2

PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 pytest
cd web-ui && npm run build

適合哪些人

ai-goofish-monitor 適合這些使用者：

• 經常在閒魚蹲特定型號商品的人。
• 想監控二手數位產品、攝影器材、遊戲設備、硬體配件的人。
• 想把「關鍵字搜尋 + 人工篩選」自動化的人。
• 有 OpenAI 相容模型 API，並願意為 AI 判斷支付調用成本的人。
• 熟悉 Docker 或基本命令列部署的人。
• 需要把命中結果推送到手機、企業微信或 Telegram 的使用者。

它不太適合這些情況：

• 完全不懂部署，只想要一個即開即用 App。
• 不願意處理登入態、驗證碼和帳號風控。
• 需要官方授權、強合規的資料介面。
• 想大規模高頻抓取平台資料。
• 希望 AI 自動判斷交易風險並替你下單。

使用風險和邊界

這類工具一定要注意邊界。

第一，遵守平台規則。

閒魚有自己的服務條款、風控策略和帳號安全機制。自動化存取可能觸發限制。不要高頻抓取，不要繞過風控，不要把它用於騷擾賣家、批量採集隱私或破壞平台秩序。

第二，保護帳號登入態。

state/ 裡保存的是登入狀態 cookie 文件。它本質上等同於帳號存取憑證，不能提交到 Git 倉庫，也不要放到不可信伺服器上。伺服器如果暴露在公網，Web UI 必須修改預設密碼，並建議放在 VPN、反向代理鑑權或內網之後。

第三，AI 判斷不是事實保證。

AI 可以幫你減少誤報，但不能保證商品真實、賣家可信、價格合理或交易安全。最終仍然要人工看商品詳情、賣家評價、聊天記錄、發貨方式和支付流程。

第四，注意成本。

如果每個候選商品都交給多模態模型分析，調用成本可能很快上升。建議先用關鍵字、價格和區域做強篩選，再把少量候選交給 AI。

第五，注意隱私。

商品截圖、聊天相關內容、帳號狀態和通知內容都可能包含敏感資訊。通知 Webhook、日誌目錄和資料庫都要妥善保護。

和普通腳本的差別

普通閒魚監控腳本通常只做三件事：

1. 搜尋關鍵字。
2. 判斷價格。
3. 發通知。

ai-goofish-monitor 更進一步：

• 用 Web UI 管理任務和帳號。
• 用 AI Prompt 表達複雜購買標準。
• 用多模態模型看商品圖和描述。
• 用 SQLite 保存結果和價格歷史。
• 用日誌頁排查任務失敗原因。
• 用代理輪換和多帳號機制提高穩定性。
• 用定時任務支援長期運行。

也正因為功能更多，它的部署和維護成本更高。對普通使用者來說，Docker 部署是最省事的方式；對開發者來說，Web UI、FastAPI、Playwright、SQLite 這套結構也比較容易二次開發。

可以怎麼用

比較實用的使用方式是從小任務開始。

比如你想找一台二手相機，可以先建立一個任務：

• 關鍵字：A7C、索尼 A7C
• 價格範圍：按市場價設定上限
• 區域：優先本省或同城
• 新發布範圍：最近一天或最近幾小時
• AI 標準：排除單鏡頭、排除維修機、排除明顯配件、關注快門數和成色
• 通知：只推送 AI 判斷通過的結果

穩定運行後，再逐步增加任務數量。不要一開始就上幾十個關鍵字、多個帳號和高頻 Cron。先看登入態穩定性、誤報率、AI 成本和通知噪音，再調參數。

總結

ai-goofish-monitor 把閒魚監控從「關鍵字腳本」推進到了「可管理的 AI 監控系統」。它用 Playwright 處理頁面自動化，用 AI 處理複雜判斷，用 Web UI 管理任務和結果，用 SQLite 保存資料，再透過多種通知渠道把結果推送出來。

它最適合個人或小團隊做特定商品監控，尤其是二手數位產品、硬體、攝影器材這類價格波動大、發布時間敏感、描述噪音多的品類。

但它也需要謹慎使用：登入態要保護，預設密碼要改，抓取頻率要克制，AI 結果要人工複核，平台規則和隱私邊界不能忽視。把它當成輔助篩選工具，它會很有價值；把它當成全自動交易系統，就容易高估它的能力。

參考連結：

• Usagi-org/ai-goofish-monitor
• 專案英文 README
• 專案免責聲明