Auto Ski Info Subscribe 自架 X 推文監控系統：從程式碼看 Cookie 抓取與 MCP 資料層

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Auto Ski Info Subscribe 是一個可以自己架起來的 X（Twitter）推文監控專案。它用你自己的 X 帳號 Cookie 抓指定帳號的推文，交給 Google Gemini 做情感分析與內容摘要，再把整理過的推文透過 MCP 協議暴露成其他 AI 服務能直接查詢的資料。以下是從它的 GitHub 原始碼與文件看出的長相，給想評估要不要部署的人當判斷起點；這是一份基於官方資料的工具導覽，不是跑過整套流程的實測，效果與穩定度得你自己架起來才能驗證。

Cookie 加無頭瀏覽器抓推文，是手段也是代價

從專案的 requirements.txt 可以看到，抓取這一步靠的是 Playwright 無頭瀏覽器，再加上你從瀏覽器開發者工具複製的兩個 X Cookie 值：auth_token 與 ct0。換言之，它繞過了 X 的官方 API，用你登入後的 Cookie 直接以瀏覽器身份把推文抓回來。取得這兩個值的方式是在瀏覽器登入 X 後，打開開發者工具的 Application 面板，從 Cookies 裡把 auth_token（登入令牌）和 ct0（防偽令牌）複製出來填進 .env，整個專案就以此當作身份驗證。

後端是 Django 4.2 加 Django REST Framework，排程與非同步工作交給 Celery 與 Redis。docker-compose 裡拆出三個工作容器：Celery Worker 負責實際跑抓取與分析任務，Celery Beat 負責定期排程，搭配一個 redis:7 容器做訊息佇列。作者在文件裡把預設抓取頻率設成每 15 分鐘一次，這個數字對應到文件範例裡的 crontab(minute='*/15') 設定，想拉長或縮短間隔可以自己改。

這套做法的好處與代價其實是同一件事。不必申請官方 API、不必付費，就能拿到推文；但代價是你得自己維護那組 Cookie。X 的 Cookie 會過期，專案 README 建議大約每月更新一次，而當 X 前端介面改版時，靠 Playwright 模擬瀏覽器的抓取邏輯也可能跟著壞掉。這是所有走 Cookie 抓取路線的同類工具都會遇到的本質問題，每個走 Cookie 抓取路線的專案都躲不掉。

會選擇這條路，背景在於 X 官方 API 的門檻。X 在 2023 年大幅調整 API 定價後，免費方案能拿到的資料極為有限，正式方案要價不低，對只想追蹤幾個帳號的個人開發者並不划算。Auto Ski Info Subscribe 鎖定的正是這塊需求：輿情觀察、特定帳號的內容收集、或把推文當成自己分析流程的原料。專案的 README 在安全段也寫明：遵守 X 服務條款、建議間隔 15 到 30 分鐘、僅限個人學習研究、不得商業使用、只抓公開資訊。作者自己把合規邊界劃得很清楚，它並不是給你拿來做商業資料服務的，而 X 對自動化存取的容忍度也可能隨政策改變，這是部署前要承擔的不確定性。

Gemini 把原始推文變成可分析的欄位

抓回來的推文是原始資料，這個專案還多做了一步 AI 處理。後端的 ai_service 模組整合了 Google Gemini，對每則推文做三件事：情感分析（判斷正向、中性、負向）、內容摘要，以及主題提取。處理結果會寫回資料庫成為推文的結構欄位，這也是前端介面能讓你「按情感、按帳號、按時間」篩選推文的原因。

要注意的是，這層分析的品質完全取決於 Gemini，而 Gemini 是付費雲端服務（有免費額度但有限制）。你需要自備一組 Google AI API Key 寫進 .env，這個 Key 在專案文件裡標為「可選」，意思是沒有它系統還是抓得到推文，只是少了分析與篩選能力。換句話說，這個專案的「AI 分析」仰賴雲端模型，推文內容會被送一份給 Google 處理，模型本身並不跑在你的機器上。對隱私敏感的人，這代表被監控的推文內容會經過第三方雲端，部署前要把這層資料流向算進去。同時，Gemini 對中文推文的情感判讀準確度，文件並未提供任何基準數字，實際效果同樣要自己抽幾批推文比對才知道，不宜假設它對所有語言都一樣可靠。

前端介面把監控成果變成可操作的畫面

後端之外，專案還附了一個 React 18 加 Ant Design 的前端，跑在獨立的容器裡，預設開在 http://localhost:3000。這個介面把後端能力轉成一般使用者能操作的畫面：你可以在「帳號管理」頁新增要監控的 X 使用者名稱（不含 @ 符號）、切換監控開關，然後在「推文列表」瀏覽系統抓回來的內容，並依帳號、情感標記、時間區間做篩選。

從資料庫遷移檔還可以看到一個 RecommendedTweet 模型，對應的是 AI 推薦推文的功能，把 Gemini 判定為值得注意的內容另外標示出來。這代表這個專案的目標不只是單純備份推文，還想把 AI 分析結果回饋到瀏覽體驗裡。同樣要提醒，介面長相與操作流暢度是官方文件描述的範圍，本次並未實際操作截圖，細節以你架起來後看到的版本為準。

MCP 資料層，是它跟單純爬蟲拉開距離的地方

如果只看抓取與分析，Auto Ski Info Subscribe 跟一般 X 監控工具差別不大。它真正值得停下來看的一步，是把抓回來的推文透過 MCP 協議（Model Context Protocol）對外暴露。在程式碼裡，這對應到 backend/mcp_service 底下兩個真實的 Django REST Framework ViewSet：MCPTweetResourceViewSet 與 MCPAccountResourceViewSet，分別把單則推文、帳號推文列表、關鍵字搜尋做成可查詢的資源端點，路徑落在 /api/mcp/ 底下。

這一步的意義在於：推文不再只是存進資料庫的備份，而是變成其他 AI 服務或 Agent 能呼叫的結構化資料層。對應的查詢介面具體落在三個地方：用推文 ID 取得單則推文、用帳號 ID 取得該帳號的推文列表，以及用關鍵字加情感條件搜尋推文。你可以讓另一個接 MCP 的應用直接查「某帳號最近推文」或「包含某關鍵字且情感為正向的推文」，把監控成果接到下游的分析流程，而不必每次都重新抓取。對想把 X 內容納進自己 AI 工作鏈的開發者來說，這個資料介面才是這個專案有別於單純爬蟲的地方。要再次說明，這裡能確認的是「這份能力在程式碼裡存在」，至於它在你的部署環境跑得多順、MCP 端點回應多快，文件無法保證，需要實際部署才看得出來。

README 的 MIT 徽章，不等於你真的拿到 MIT 授權

有幾件被 README 徽章模糊的事，在決定部署前最好先看清楚。授權是其中最該在意的一點。README 頂端掛了一個 MIT License 的徽章，但這個倉庫實際上沒有 LICENSE 檔案。在 GitHub 的慣例裡，沒有 LICENSE 檔案代表預設是「版權保留」，別人並沒有自動獲得改作或商用的權利。徽章與實際授權檔案不一致，是一個值得在意的落差：你以為拿到的是可隨意改作的 MIT 授權，法律上其實是尚未授權。

Pin

專案成熟度是另一個現實。這個倉庫在 2025 年 11 月建立，截至本次查核仍是 0 顆星、65 個 fork，是一個全新的專案。缺乏社群驗證與長期維護紀錄，意味著你得有自己接手修問題的心理準備，不宜把它當成已經被大量使用的穩定專案。從倉庫的輔助腳本也能看出開發環境的痕跡：裡頭有 PowerShell 與批次檔、docker-dev.ps1，指向作者主要在 Windows 環境下開發；夾雜的日文註解則反映開發者的語言背景。這不代表程式不能在其他平台跑，但暗示文件與除錯流程以 Windows 為主，Linux 或 macOS 使用者遇到路徑或腳本問題時可能要自己調整。

另外，最早介紹這個專案的文章附了一個 GitHub 連結，那個帳號路徑實際打開是 404，真正的倉庫在另一個帳號底下。這不影響專案本身能不能用，但表示你想 clone 時要自己找到正確位址，照抄該文的連結會撲空。

Pin

部署前要先接受的幾個現實

把上面幾點濃縮成會直接改變你決定的硬限制。授權真空會卡住商業用途：沒有正式授權檔案，嚴格說來你只能把它當個人研究用途，要做成產品得自己先補授權或聯絡作者。Cookie 抓取會卡住穩定性預期：你承接的是 Cookie 過期與 X 前端改版這類外部風險，這不是改程式碼就能完全消除的，而 X 對自動化存取的態度也可能隨政策收緊。

安全性與部署成本是另外兩關。README 寫的預設管理後台帳號是 admin、密碼是 admin@123，本地測試無所謂，但若你打算放到有對外網路的機器上，上線前一定要先改掉，否則等於把管理介面開著門。部署方面，作者提供兩條路。Docker Compose 是門檻較低的那條，主要用來跑 Redis、Celery Worker 與 Beat 這套排程工作層，前端與後端伺服器則另行啟動（專案另有 dev 與 debug 兩種 compose 設定檔），適合先試跑。Google Cloud Run 則是雲端那條，附有 deploy.sh、setup-secrets.sh 與 cloudbuild.yaml，後者用 Cloud SQL 存資料、搭配 Cloud Scheduler 與 OIDC 服務帳戶觸發，還開了 CPU boost 與不限制 CPU 的選項，並把執行個體數設成可自動伸縮的範圍。

作者在文件宣稱這套雲端部署在零流量時可壓在每月 0 元。這個成本數字是作者的自述，實際帳單取決於你的抓取頻率、資料量與 Cloud SQL 的等級，而雲端部署還需要你熟悉 GCP 的服務帳戶、IAM 權限與 Secret Manager 設定，門檻明顯高於本機 Docker。對只想驗證功能的人，從 Docker Compose 起步會務實得多。

怎麼用最低成本自己判斷

如果讀到這裡還想試，最省成本的驗證是先別急著上雲。把正確帳號底下的倉庫 clone 下來，先確認有沒有 LICENSE 檔案（這次查核是沒有，但倉庫狀態會變），再照 README 的 docker-compose up -d 在本機跑一次。能看到前端介面在 http://localhost:3000 開起來、後端 API 文件在 http://localhost:8000/swagger/ 有回應，就代表這套架構在你環境跑得動，值得繼續投入時間把 Cookie 與 MCP 端點接起來試。進一步可以用瀏覽器或 curl 打打看 /api/mcp/ 底下的端點，確認推文真的能以結構化資料回傳，這一步通過才代表這個專案最核心的資料層價值成立。

若你只是想換個方式看 X 內容，而不需要自架整套推文資料庫，負擔其實輕得多。像 Nitter 這類前端替代方案能讓你不登入就瀏覽推文，而想把推文搬到別的平台的人，也有現成的 跨平台自動轉發工具可選。如果你的需求更接近「把多個來源的更新彙整成一份餵給 AI 處理」，那走 RSS 匯整加 AI 摘要的路線會比硬架一套推文專屬系統更通用，也不必碰 X 的 Cookie 與條款問題。

相對之下，Auto Ski Info Subscribe 適合的是另一種需求：你要的是一份自己掌握的推文資料層，而且願意為了那個 MCP 資料介面承擔自架全端專案與 Cookie 維護的成本。它的價值集中在「把 X 推文變成 AI Agent 可查詢的結構化資料」這一步，這也是評估時該放大的部分；至於授權未落地、專案極早期、預設弱密碼與合規風險，則是部署前必須先接受的代價。把這層需求與代價想清楚，再回頭看它的成熟度限制，要不要投入時間架起來，答案就會清楚很多。