小紅書 AI 發文工具 xhs_ai_publisher，開源自動化文案到排程發佈

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

把「想主題、寫文案、配圖、發佈」這條每天都要走一遍的流程，交給一個開源桌面軟體跑完，是 xhs_ai_publisher 對小紅書創作者的核心承諾。它用 AI 生成標題、正文與多頁內容圖，接著用瀏覽器自動化把成品填進小紅書的發佈頁，支援定時排程與多帳號管理。專案以 Apache-2.0 授權釋出，在 GitHub 上累積 2,086 顆星、299 次 fork，兩位主力貢獻者各提交 69 與 53 個 commit，不是單人週末作品。

先講結論。它的資料面出乎意料地乾淨：整份原始碼裡見不到任何統計或遙測 SDK，帳號登入態、內容資料與模型金鑰全部落在自己電腦的 ~/.xhs_system/ 目錄，AI 生成走自帶金鑰路線，出廠預設甚至沒有任何金鑰。但它自動化不掉的是帳號本身的風險：GitHub issue #29 裡有使用者自述帳號已被小紅書封禁 7 天、另一位自估再被偵測一次也會封 7 天，作者的答覆只有一個表情符號。想省時間之前，先確認你願意拿哪個帳號去換。

發文成功率、對抗平台風控的效果，這些要自己安裝後才會知道；原始碼與官方資料讀得出來的，是它做得到什麼、資料怎麼流、預設值站在哪一側。

從一句主題到按下發佈鈕：整條鏈怎麼跑完

操作鏈從一句主題開始。工具先拿主題去問你設定的模型，按提示詞範本生成嚴格 JSON 格式的成品：標題 10 到 20 字、正文 400 到 700 字分 3 到 6 個要點、3 頁內容圖文的文字稿、5 到 10 個主題標籤，結尾附互動引導。範本本身是專案裡的 JSON 檔（templates/prompts/ 目錄下有預設、圖卡、測評、教學四種），照格式自己擴充即可，不必動程式。配圖同樣有選擇：交給 AI 生成、在「封面中心」套行銷海報或產品展示類範本本地產圖，或自己上傳。發佈前有完整預覽，確認後才交給瀏覽器自動化填入發佈頁。

Pin

模型層完全走自帶金鑰（BYOK）路線。設定檔內建 8 個供應商端點預設：OpenAI、智譜 GLM、Claude、通義千問、Kimi、豆包、騰訊混元，以及一個指向 localhost:1234 的本機端點；程式另原生支援 Ollama。你的文案內容送哪個雲端、要不要送雲端，決定權都在設定檔裡，這點和 ChatWise 這類同樣自帶金鑰的桌面 AI 軟體是同一套哲學。

值得知道的是出廠預設的真實長相。原始碼 config.py 裡的預設模型配置是 OpenAI 端點加上空字串金鑰：不填自己的金鑰，雲端生成一步都不會發生，文字會退到 browser.py 裡的本機模板拼裝，隨機挑一個標題句型、填入通用要點清單，配圖用 PIL 畫佔位圖。換句話說，免設定也能跑完整流程，只是產出是模板文，別期待 AI 品質。它能「先跑起來再說」的邊界，在這裡畫得很清楚。

選題也有來源。內建資料中心直接呼叫微博、百度、今日頭條與 bilibili 的公開熱榜 API，看中哪個熱點，一鍵帶進首頁當生成主題。對「不知道寫什麼」的創作者，這個入口有時比生成器本身更實用。

圖片這條線的端點選擇比文字少。文字生成可以接任何 OpenAI 相容端點，實驗性的圖片生成層卻只有 Kimi 與通義千問兩個轉接器，沒接上時就改用封面範本本地產圖或佔位圖。想把全流程都留在自己信任的服務裡，圖片這段目前做不到，這是資料流向上一個不對稱的角落。

帳號與排程是另外兩塊拼圖。登入走手機號碼加國家區號的驗證碼流程，撞到簡訊或掃碼風控時可以切換成在瀏覽器裡手動完成，成功後登入態存檔重複使用；多位使用者（多帳號）各有獨立的瀏覽器 profile 與資料目錄，側邊欄切換。定時發佈由內建排程器處理，前提是程式保持運行且帳號仍登入，適合「白天準備、晚上黃金時段出文」的節奏，離開機器就停擺，這點和雲端排程服務是本質差異。

想橫向比較的讀者可以把它放進座標系：Multipost 這類多平台發佈器把「一次編輯、多平台送出」做通，而內容生成與單一平台的深度都淺；xhs_ai_publisher 只做小紅書一個平台，換到的是內容生成、熱榜選題、排程與登入態管理的縱深。另一頭，TrendPublish 把同樣的自動化思路做在微信公眾號上。選哪個，取決於你主力經營哪個平台。

資料流向拆解：零遙測、落地本地，與藏在同目錄的解密金鑰

對一個會碰帳號登入態與內容草稿的工具，資料流向比功能清單重要。分三層看：處理層，文案生成只送往你自己設定的模型端點，瀏覽器操作在本機；儲存層，SQLite 資料庫、cookies、登入態、每位使用者的 Chrome profile 與產出圖檔，全部放在 ~/.xhs_system/ 目錄，生成的草稿與發佈紀錄也落在這個資料庫裡，離線時歷史紀錄照樣翻得到；對外層，核心生成與發佈流程的對外請求只有四類，就是自配模型端點、實驗性圖片生成服務（Kimi 與通義千問，金鑰自帶）、四平台熱榜公開 API，以及小紅書本身；多帳號環境的代理檢測會另觸 httpbin.org，首次安裝瀏覽器時的下載鏡像也是額外連線。

最難得的是遙測缺席。整份原始碼裡，sentry、posthog、umami、analytics 這類字樣一個都沒有；對一個中國大陸生態的免費工具來說，不埋統計、不接送端指紋，是少見的自我約束。API 金鑰以 Fernet 加密存在 keys.enc 檔裡，資料目錄與金鑰檔的權限也分別壓到 700 與 600；而解密金鑰 .encryption_key 就放在同一個目錄，這層加密防的是「順手翻檔案」，不防同機的惡意程式，本機安全仍要自己顧。

一個容易被忽略的預設值：工具會自動掃描系統 Chrome 的設定檔，找出可用的小紅書登入態匯入（環境變數 XHS_AUTO_IMPORT_SYSTEM_CHROME_STATE 預設開啟）。對註冊卡在簡訊驗證的人，這正好補上缺口；對重視隔離的人，這代表本機 Chrome 的登入狀態會被工具讀取，裝之前該知道並決定要不要關。程式也內建了安全欄位：把瀏覽器指向真實 Chrome profile 時，清空 cookies 的操作預設鎖住，避免一次實驗弄壞你日常的瀏覽器。

反檢測的退守：預設走真實 Chrome，指紋注入留給多帳號環境

網路上流傳的介紹多寫它「用 Selenium 做 RPA 自動點按」。原始碼給的答案不一樣：程式碼與正式依賴裡 Selenium 是零，瀏覽器自動化從發佈流程到登入態匯入全部建立在 Playwright 上，連檔案上傳都走瀏覽器原生的檔案輸入介面而非彈窗點按。這個差別不只在名詞，照 Selenium 裝環境的舊教學會直接裝錯依賴。

更值得觀察的是反檢測路線的退守，而且有時間線可查。2026 年 2 月，社群提出把發佈流程改用持久 Chrome profile 的重構 PR，官方 3 月採納其中被判定為安全的部分合併；到了 6 月的版本，環境變數檔裡 XHS_ENABLE_STEALTH_SCRIPT 預設 false、真實持久 profile 預設開啟，發佈流程的原始碼也寫明「用持久 profile 就不注入額外指紋覆寫」，連 JS 強制點按都預設停用，只在手動確認模式或顯式開啟時生效。官方現在的立場偏向「像真人一樣用真實瀏覽器」，偽裝退到需要自己打開的選項裡。

例外是多帳號的「瀏覽器環境」管理。這條路徑（enhanced_browser_manager.py）仍然無條件注入反偵測劇本與指紋設定，每個環境一套代理、UA、viewport、時區與地理位置。單帳號自用與多帳號矩陣，在這個專案裡是兩種風險等級的用法，預設值站在前者那側。另有一個實驗性的 UI-TARS 橋接服務，用視覺模型逐步操作網頁、可設定逐步確認，屬於進階玩家才會碰的角落，預設不參與發佈流程。

封號實錄、無鑑別 API 與放緩的維護：下載前先算這些

平台風險不是理論。2026 年 4 月開的 issue #29，標題直白寫著帳號被平台偵測：一位使用者說試了很多方法都繞不過去、再被偵測一次就要封 7 天；另一位說自己已經被封了 7 天；後面還有人在問有沒有穩定的做法。作者的唯一答覆是一個表情符號。自動化發文走在平台服務條款的鋼索上，這是工具能力範圍外的結構性風險，把主力帳號交給任何全自動流程之前，都該把這個討論串讀完。

折衷方案其實就內建在流程裡：排程全自動是選項，不是義務。讓工具負責最花時間的生成與排版，發佈前預覽自己看過、自己按鈕，這種半自動用法把「省工」與「可控」各拿一半；官方把 JS 強制點按預設關掉、把登入風控交給人工完成的設計，方向上也是朝這個保守側站。全自動排程留給願意承擔帳號風險的小號，是比較務實的配置。

金鑰衛生也有前科可查。2025 年 10 月有人指出專案的 .env 檔裡留著作者的 API 金鑰，作者的答覆是那把金鑰是專案專用、有額度上限，不代表資安意識特別嚴謹。對會把自己的模型金鑰填進 settings.json 的使用者來說，這段歷史提醒你：金鑰的暴露面取決於你自己的存放習慣，工具只負責加密那一層。

自架服務模式有自己的安全帳。官方推薦的容器流程是：先在本機有介面的環境登入一次、取得登入態，再把 ~/.xhs_system 掛載進容器跑無頭服務，登入態失效時無頭模式不會幫你過驗證，只會明確提示要重新登入。問題在服務本身：Web 模式用 FastAPI 開在 8000 埠，環境變數預設綁 0.0.0.0，而登入、上傳、發佈、session 管理這些 API 端點沒有任何金鑰檢查，能連到埠口的人，就能動用你掛載進去的登入態。這和 TubeTube 這類自架下載器踩過的坑同型：容器化部署的便利，把鑑別責任留給了部署者。真要跑服務模式，綁本機或加一層反向代理鑑別是底線。

維護節奏也要誠實看。main 分支停在 2026 年 6 月 28 日那次 commit，至今約三個月沒有動靜；README 徽章掛著 Active 與 Version 2.0.0，實際唯一的 release 標籤卻是 v1.2.0（同日釋出，用 Nuitka 打包四平台執行檔，體積從 186 到 239 MB，下載次數合計 96 次，其中 Windows 佔 62 次）。Windows 安裝沒反應、發佈失敗這類 issue 還開著。專案不算死，repo 建立近兩年、雙主力貢獻者、2026 年上半年還在穩定演進，如今已進入低維護期，撞到 bug 要有自己讀原始碼的準備。

Pin

官網則是真的死了。xhsaipublisher.com 的域名已從 DNS 消失，網頁檔案館的最後快照停在 2026 年 6 月，當時的站名是「小和尚發布助手」，與 GitHub 專案沒有品牌連結。搜尋結果裡的官方網站都是死鏈，下載、文件、issue 一律以 GitHub repo 為準。裝機環境也有實際限制：這是一個 PyQt5 桌面程式，官方文件明講 Python 3.13 或 32 位元環境常導致 PyQt5 裝不起來，建議用 3.11 或 3.12 的 64 位元 Python，Windows 用戶第一次執行安裝腳本沒反應時，先從這裡查起。

對號入座：哪種工作流程該裝，哪種帳號別交

該裝的人有清楚輪廓：已經在小紅書持續產出、想壓掉重複排版與發佈工時的創作者；願意用小號或全新帳號試錯、等流程穩定再考慮主力帳號半自動（生成歸機器、發佈歸自己）的人；想把模型放在本地（Ollama、LM Studio）或自己信任的雲端金鑰上的人。Apache-2.0 授權讓商用改造沒有法律顧慮，這點比許多「公開不等於授權」的 repo 乾淨。

不該交出去的也一樣清楚：主力帳號別開全自動，issue #29 就在前面的路上；不願讓工具掃描本機 Chrome 登入態的人，先關掉自動匯入；需要穩定 API 與安全邊界的團隊整合，現在的無鑑別服務模式撐不起正式環境的場景；期待裝好就有 AI 品質輸出的人，也要先意識到預設是沒有金鑰的模板文。

花五分鐘先驗證再決定

下載 200 MB 打包檔之前，有個零成本的前置檢查：打開 repo 的 .env.example 與 docs/runtime-config.md，把每個預設值讀一遍，包括資料目錄、登入態匯入、stealth 開關、服務綁定位址。這份檔案比任何介紹文章都誠實，五分鐘就能確認它的預設立場你接不接受。

真的要試，用乾淨的瀏覽器 profile 加測試帳號，跑一次手動確認模式的預覽發佈。看見「生成、預覽、填入發佈頁」完整走完、而且你的模型端點流量符合預期，才值得繼續投入排程與多帳號；預覽卡住、登入一直要求驗證碼、或發佈直接失敗，這些是社群還沒解的問題，出現在你的環境就先停，別硬調。