xianyu自動返信の使い方は？ Xianyu 自動返信システムの機能と導入に関する注意事項

zhinianboke/xianyu-auto-reply は、Xianyu シナリオ用の自動管理システムです。これは、わずか数行のルールを備えた自動返信スクリプトではなく、アカウント管理、メッセージ送受信、自動返信、AI 返信、自動発送、製品リリース、注文処理、バックエンド管理をまとめた完全な Web システムです。

Xianyu メッセージにいくつかのキーワード返信を追加したいだけの場合、少し重いかもしれません。バーチャルグッズ、クーポン配布、マルチアカウント管理、自動評価、製品リリースも行っている場合、その機能は比較的完全にカバーされています。

このプロジェクトで何ができるのでしょうか?

プロジェクトの README から判断すると、メインシステムは主に次のモジュールをカバーしています。

複数のアカウント管理: 複数の Xianyu アカウントのログイン、ステータスの切り替え、Cookie のメンテナンス、ログインの更新をサポートします。
自動返信: テキストキーワード、画像キーワード、デフォルトの返信、および製品固有の返信をサポートします。
AI 応答: 状況に応じた対話とインテリジェントな応答のための大規模モデルへのアクセスをサポートします。
自動配信: クーポン、バーチャルグッズ、自動再発行および配信記録をサポートします。
オンラインチャット: 会話リスト、メッセージング、チャット連携を提供します。
製品リリース: マテリアルライブラリ、アドレスライブラリ、単一製品リリース、バッチリリース、およびリリースログをサポートします。
注文と評価: 注文の取得、自動評価、赤い花のリクエスト、およびステータスの追跡をサポートします。
商品の収集と流通: グーフィッシュの収集、供給管理、決済リンクを含む。
通知とリスク管理: メッセージ通知、リスク管理ログ、システムフィードバック、アナウンス管理を含みます。

プロジェクトには 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`	Xianyu 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 を使用することをお勧めします。最初にサーバーをインストールする必要があります。

ドッカー 20.10+
Docker Compose 2.0+
最小 2 コア CPU / 4GB RAM
4コアCPU / 8GB RAMを推奨

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 更新、公開機能はすべて Playwright ブラウザ環境に依存しています。

自分の内部ネットワークのみでテストする場合は、まず LAN IP を使用してアクセスします。パブリックネットワークで使用する場合は、リバースプロキシの背後に配置し、管理バックグラウンドのアクセス範囲を制限することをお勧めします。

誰に適していますか?

このプログラムは次のような人に適しています。

複数の Xianyu アカウントをお持ちの場合、メッセージとステータスを統一的に確認する必要があります。
バーチャルグッズやクーポンを作成するには、自動配信と再発行の記録が必要です。
作業負荷を軽減するためにキーワードや AI 応答を使用することを期待して、同様の質問に繰り返し回答することがよくあります。
サーバーと Docker の使用経験があること。
MySQL、Redis、コンテナのログとバックアップを自分で保守できる。
プラットフォームルールのリスクを理解し、規制に違反したり嫌がらせをするためにプラットフォームルールを利用するつもりはありません。

完全にゼロベースのユーザーには適していません。システムには多くの機能があるため、展開、構成、トラブルシューティング、リスク管理はすべてユーザー自身の責任となります。

リスクと境界線

Xianyu Automation のようなツールの場合、本当に注意する必要があるのは「実行できるかどうか」ではなく、「実行後に何かが起こるかどうか」です。

事前に考慮する必要があるリスクが少なくともいくつかあります。

プラットフォームルールのリスク: 自動返信、自動公開、自動発送はプラットフォームのリスク管理に影響を与える可能性があります。
アカウントのリスク: Cookie のメンテナンス、WebSocket 接続、ブラウザの自動化により、アカウントに異常が発生する可能性があります。
データリスク: アカウント情報、注文、チャット記録、および発送資材は保護する必要があります。
セキュリティリスク: バックエンド、API ドキュメント、データベースポートをむやみにパブリックネットワークに公開しないでください。
コンプライアンスのリスク: README には、プロジェクトが学習と研究のみを目的としていることが明確に記載されており、プラットフォームのルールに違反する行為にはプロジェクトを使用しないように注意されています。

なお、このプロジェクトはAGPL-3.0ライセンスを採用しており、READMEには「商用利用禁止」と明記されています。再開発して他の人にデプロイしたり、業務プロセスに導入したりする場合は、機能一覧だけを見るのではなく、まず LICENSE や README の制限事項をよく読んでください。

＃＃まとめ

zhinianboke/xianyu-auto-reply は、単純な自動応答スクリプトというよりは、Xianyu の自動バックエンドのような位置付けです。その利点は、幅広い機能を備えていることです。メインシステムには、アカウント、チャット、返信、出荷、リリース、注文、リスク管理ログが含まれます。テクノロジースタックも比較的最新であり、Docker の導入パスは比較的明確です。

しかし、その敷居は低いわけではありません。サービスの展開、データベースの管理、Playwright 環境の処理、デフォルトアカウントの変更、リバースプロキシの構成、データのバックアップができる必要があります。さらに重要なのは、Xianyu Automation 自体にプラットフォームルールとアカウントリスク管理リスクがあります。

私の提案は、まずテスト環境でメインシステムを実行し、リスクの低いアカウントを 1 つだけ接続し、返信、配送、注文のプロセスが安定していることを確認してから、使用範囲を拡大するかどうかを検討することです。複数の重要なアカウントと実際のトランザクションをすぐに接続しないでください。

参考ソース

zhinianboke/xianyu-自動返信 - GitHub