xianyu-auto-reply 怎麼用？閒魚自動回覆系統功能與部署注意

zhinianboke/xianyu-auto-reply 是一個面向閒魚場景的自動化管理系統。它不是一個只有幾行規則的自動回覆腳本，而是把帳號管理、訊息收發、自動回覆、AI 回覆、自動出貨、商品發布、訂單處理和後台管理都放在一起的完整 Web 系統。

如果你只是想給閒魚訊息加幾個關鍵字回复，它可能有點重；如果你同時在做虛擬商品、卡券發貨、多帳號管理、自動評價和商品發布，它的功能覆蓋就比較完整了。

這個專案能做什麼

從專案 README 看，主系統主要覆蓋這些模組：

多帳號管理：支援多個閒魚帳號登入、狀態切換、Cookie 維護和登入續約；
自動回覆：支援文字關鍵字、圖片關鍵字、預設回覆和商品專屬回覆；
AI 回覆：支援接取大模型做情境對話和智慧回覆；
自動出貨：支援卡券、虛擬商品、自動補發和寄送記錄；
線上聊天：提供會話清單、訊息收發和聊天連動；
商品發布：支援素材庫、地址庫、單品發布、大量發布和發布日誌；
訂單與評價：支援訂單拉取、自動評價、求小紅花與狀態追蹤；
商品採集與分銷：包含 Goofish 採集、貨源管理和結算連結；
通知與風控：包含訊息通知、風控日誌、系統回饋與公告管理。

專案裡還有一個 promotion 返傭子系統，用來管理返傭帳號、選購規則、素材庫、發布規則、刪除規則和補償任務。不過 README 也說明，根目錄的 Docker Compose 預設只覆蓋主系統，返傭子系統需要單獨啟動。

技術堆疊和系統結構

這個專案的技術棧比較典型：

後端：FastAPI、SQLAlchemy 2.0、Loguru；
資料庫：MySQL 8.0；
快取與任務輔助：Redis 7；
瀏覽器自動化：Playwright、Chromium / Chrome；
定時任務：APScheduler；
前端：React 18、TypeScript、Vite、TailwindCSS、Zustand、Lucide React；
部署：Docker、Docker Compose、Nginx。

服務拆分也比較清楚：

服務	預設連接埠	作用
`frontend`	`9000`	主系統前端
`backend-web`	`8089`	主系統 API 閘道與業務介面
`websocket`	`8090`	閒魚 WebSocket、訊息收發、登入與訂單連動
`scheduler`	`8091`	自動出貨、評價、訂單拉取、Cookie 刷新等定時任務
`promotion/backend`	`8092`	返傭後端 API
`promotion/frontend`	`9001`	返傭前端

主系統的依賴關係大致是：

1
2


mysql / redis -> backend-web -> websocket -> scheduler
frontend -> backend-web

也就是說，它不是單容器應用。部署前最好先確認伺服器連接埠、記憶體、資料庫持久化和反向代理都安排好了。

伺服器部署方式

專案推薦用 Docker 和 Docker Compose 部署。伺服器需要先安裝：

Docker 20.10+
Docker Compose 2.0+
最低 2 核心 CPU / 4GB 內存
建議 4 核心 CPU / 8GB 內存

README 給予的一鍵部署指令是：

1

curl -fsSL https://xy-update.zhinianboke.com/deploy.sh | sed 's/\r$//' | bash

更新指令是：

1

curl -fsSL https://xy-update.zhinianboke.com/update.sh | sed 's/\r$//' | bash

如果你更想自己看清楚腳本內容，可以先克隆倉庫再部署：

1
2
3


git clone https://github.com/zhinianboke/xianyu-auto-reply.git
cd xianyu-auto-reply
bash deploy.sh

首次運作會自動產生 .env 設定檔和 docker-compose.deploy.yml，並拉取預先建置鏡像啟動服務。部署完成後，預設存取位址通常是：

前端：http://服务器IP:9000
API 文件：http://服务器IP:8089/docs
預設帳號：admin / admin123

這裡有個很現實的建議：不要在生產伺服器上直接盲跑遠端腳本。至少先在測試機跑一遍，或是把腳本下載下來檢查清楚。它會建立配置、拉鏡像、清理舊容器和啟動服務，權限範圍不算小。

本機原始碼構建

如果你想從源碼構建，可以在倉庫根目錄執行：

1

bash build.sh rebuild

常用命令包括：

命令	說明
`bash build.sh rebuild`	刪除舊容器與鏡像，重新建置並啟動
`bash build.sh start`	啟動服務
`bash build.sh stop`	停止服務
`bash build.sh restart`	重啟服務
`bash build.sh logs`	查看即時日誌
`bash build.sh status`	查看服務狀態

也可以單獨重建某個服務：

1
2
3
4


bash build_frontend.sh
bash build_backend_web.sh
bash build_websocket.sh
bash build_scheduler.sh

原始碼開發時也需要準備 Python 3.11+、Node.js 18+、MySQL、Redis 和 Chromium / Chrome。後端服務裡用到了 Playwright，如果登入或發佈時報瀏覽器缺失，需要執行：

1

python -m playwright install chromium

部署後必須先改的東西

這個項目預設管理員帳號是：

1

admin / admin123

部署完成後第一件事就是改密碼。只要前端連接埠暴露在公網，預設密碼就等於把後台交出去。

還要重點檢查這些配置：

CORS_ORIGINS：生產環境不要直接用 *；
BACKEND_WEB_PUBLIC_URL：用於產生對外文件 URL，反向代理後要填正確；
HTTPS：外網存取最好走 HTTPS；
MySQL 資料卷：自動出貨、商品、訂單、帳號狀態都在裡面，必須備份；
靜態資源目錄：涉及圖片、素材、檔案 URL，也要納入備份；
Playwright 瀏覽器環境：自動登入、Cookie 刷新、發布功能都依賴它。

如果只是自己內部網路測試，可以先用區域網路 IP 存取；如果要公網使用，建議放在反向代理後面，並限制管理後台存取範圍。

適合誰用

這個項目更適合這些人：

有多個閒魚帳號，需要統一看訊息和狀態；
做虛擬商品或卡券，需要自動出貨和補發紀錄；
經常重複回答同類問題，希望用關鍵字或 AI 回覆減輕工作量；
有某一伺服器和 Docker 使用經驗；
能接受自己維護 MySQL、Redis、容器日誌和備份；
明白平台規則風險，不打算拿它做違規刷量或騷擾。

它不太適合完全零基礎用戶。系統功能多，也意味著部署、配置、排錯和風控都要自己負責。

風險和邊界

閒魚自動化這類工具，真正要注意的不是“能不能跑”，而是“跑起來之後會不會出事”。

至少有幾個風險要提前想清楚：

平台規則風險：自動回覆、自動發布、自動出貨都可能觸碰平台風控；
帳號風險：Cookie 維護、WebSocket 連線和瀏覽器自動化都可能導致帳號異常；
資料風險：帳號資訊、訂單、聊天記錄、出貨素材都要保護好；
安全風險：後台、API 文件、資料庫連接埠不要隨便暴露公網；
合規風險：README 明確寫了專案僅供學習研究使用，並提示不要用於違反平台規則的行為。

另外，這個專案採用 AGPL-3.0 許可證，README 裡也特別寫了「禁止商業用途」。如果你要二次開發、部署給別人用，或是放進商業流程裡，最好先認真看 LICENSE 和 README 的限制，不要只看功能清單。

小結

zhinianboke/xianyu-auto-reply 的定位更像是閒魚自動化後台，而不是簡單自動回覆腳本。它的優點是功能覆蓋廣，主系統包含帳號、聊天、回覆、出貨、發布、訂單和風控日誌；技術棧也比較現代，Docker 部署路徑相對清楚。

但它的門檻也不低。你需要會部署服務、管理資料庫、處理 Playwright 環境、修改預設帳號、設定反向代理程式和備份資料。更重要的是，閒魚自動化本身有平台規則和帳號風控風險。

我的建議是：先在測試環境跑通主系統，只接一個低風險帳號，確認回覆、出貨和訂單流程穩定後，再考慮是否擴大使用範圍。不要一上來就把多個重要帳號和真實交易都接進去。

參考來源

zhinianboke/xianyu-auto-reply - GitHub