PostBot：開源瀏覽器擴充，一次編輯同步發到 15 個社群平台

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

把同一篇內容發到微信公眾號、小紅書、知乎、微博、B 站這十多個平台，幾乎是每一位中文內容創作者每天最消耗時間的機械活。打開 PostBot 的 GitHub 倉庫前，預期會看到一套用 Playwright 或 Selenium 寫成的桌面發布機器人；實際把程式碼 clone 下來翻過一遍才發現，它根本不是桌面 RPA，而是一個以 Plasmo 框架打包的 Chrome 瀏覽器擴充功能，靠內容腳本（content script）直接在使用者已登入的分頁裡操作各平台創作者後台。這個架構選擇連帶決定了它的授權、隱私邊界與合規風險，本文把這幾層逐一拆開講清楚。

先把結論說在前面：PostBot（GitHub 倉庫 gitcoffee-os/postbot，官方網站 postbot.exmay.com）的設計比一堆把帳號密碼收上雲端的付費分發平台乾淨，內容與 cookie 留在你的瀏覽器裡；但它並不是某些介紹文暗示的那種「純本地、無網路」的工具，背後有一層 postbot.exmay.com 的雲端登入與心跳機制，授權也不是純粹的 Apache 2.0，而是加了商業限制的「GitCoffee Open Source License」。看完原始碼你才會知道這工具的真實代價是什麼。

它其實是 Chrome 擴充功能，不是桌面 RPA

對 PostBot 的第一個常見誤解，是把它想成跑在本機的桌面自動化程式。實際上 package.json 裡沒有任何 Electron、Tauri、Nut.js 或 Puppeteer／Playwright 這類桌面或瀏覽器自動化依賴，反而清楚標著 plasmo = 0.90.5、@plasmohq/storage、@types/chrome。Plasmo 之於瀏覽器擴充功能，大概就是 Next.js 之於網站，它是一個專門用來開發 Manifest V3 擴充功能的框架。對應的目錄結構也完全符合：src/background 是 service worker、src/contents 是注入到各平台的內容腳本、src/popup 是工具列圖示彈出的小視窗、src/sidepanel 則是 Chrome 側邊欄。

真正「自動化發文」的活，發生在 src/contents 裡的內容腳本身上。以微博動態發布器（src/media/publisher/platform/moment/weibo.publisher.ts）為例，它在使用者已登入微博創作者後台的分頁裡，透過 document.querySelector 找到輸入框、組 ClipboardEvent 觸發貼上、用 setTimeout 等待元素出現，最後模擬點擊送出。也就是說，PostBot 沒有另起一個機器人瀏覽器去登入你的帳號，它就跑在你平常用的那個 Chrome／Edge 視窗裡，直接復用你既有的登入狀態。這條架構決策很關鍵，因為它同時決定了三件事：內容與 cookie 不離開你的瀏覽器（隱私優勢）、操作走的是各平台官方網頁（合規風險由你自擔）、以及它不可能在沒有瀏覽器的伺服器上跑（部署模式只能綁在用戶端）。

擴充功能加雲端編輯器的雙層架構

裝好擴充功能、點工具列圖示之後，發生的第一件事是：src/popup/index.vue 直接用 chrome.tabs.create 開一個新分頁，指向 https://postbot.exmay.com/exmay/postbot/media/publish。換句話說，PostBot 真正用來編輯內容、選擇要同步到哪些平台的主操作介面，是 GitCoffee 官方伺服器上的一個網頁應用程式，擴充功能本身的角色偏向「平台同步執行器」與「雲端會話的橋接器」。

這個雲端依賴在 src/api/index.ts 寫得更明白。擴充功能一啟動就會呼叫 user.isLoginApi({}) 檢查雲端登入、authority.platform.listingApi({}) 拉平台清單，並且每 30 秒呼叫一次 authority.client.updateApi({}) 心跳。所以當 README 寫「本地化操作機制，直接復用瀏覽器本地登入狀態，規避帳號資訊上傳雲端的隱私風險」時，這句話本身沒有錯：你的微信、小紅書帳號密碼確實未上傳；但「本地化」並不等於「無網路」，PostBot 仍然需要回報到 postbot.exmay.com 完成雲端登入與心跳，Issue #4 也提到早期使用者需要邀請碼才能完成這道登入手續。

想理解這類「在本機跑內容、但需要授權伺服器」的工具為什麼屬於另一種信任模型，可以對照 TechMoon 之前介紹過的完全裝置內 WebGPU RPA 兩條路徑的比較，PostBot 屬於「內容留在瀏覽器、但授權走雲端」的中間型，不是純裝置內。

三個 README 沒講清楚的事

把倉庫 clone 下來、package.json 與 LICENSE 兩份檔案對著讀，會得到三個和官方行銷文字有段落差的事實。這些落差不是詐欺，但會實質影響你的部署與合規判斷。

授權：Apache 2.0 加上商業限制，不是 OSI 開源

GitHub 偵測到的授權是 Apache License 2.0，因為 LICENSE 檔案主體確實是標準 Apache 2.0 全文；但檔案最後面附加了一段 GitCoffee Open Source License，列出兩個額外條件。第一，未經 PostBot 書面授權，不得利用原始碼運行多租戶環境，並把「一個租戶」對應到「一個工作空間」；第二，使用前端時不得移除或修改 LOGO、水印、作者與版權資訊。條文還附帶一條貢獻者條款：貢獻者同意 GitCoffee 可以把授權調得更嚴或更鬆，且貢獻出來的程式碼可用於商業用途（包含其雲端業務）。對照 OpenClaw Skills Registry 這類 OSI 核可授權的開放原始碼專案，PostBot 的授權實質上是「原始碼可見、單租戶自架免費、多租戶 SaaS 與商業平台需另行授權」的開放核心模式，並非可以在任何場景自由部署的開源軟體。如果你打算拿它來架一個對外的多租戶發文平台，必須先談商業授權。

隱私：內容留在瀏覽器，但擴充功能會回報伺服器

在 src 目錄下對 Sentry、PostHog、Firebase、UMeng、Google Analytics、Mixpanel 這些常見遙測 SDK 做了一次掃描，公開倉庫裡完全找不到它們的痕跡，這部分算是乾淨。內容腳本也確實只在使用者已登入的分頁裡動作，沒有把文章內容或 cookie 回傳給 postbot.exmay.com 的程式路徑。但要強調的是，「內容不上雲」與「擴充功能不對外溝通」是兩件事：前述每 30 秒一次的 authority.client.updateApi 心跳，加上登入時的 user.isLoginApi，意味著擴充功能會定期讓 postbot.exmay.com 知道有某一個用戶端正在運行。對一個「純本機工具」的期待是不準確的，把它理解為「一個需要雲端帳號服務的瀏覽器擴充功能」會更貼近事實。

程式碼可見度：平台發布邏輯藏在私有套件

package.json 列了 25 個 @gitcoffee/* 範圍的相依套件，包含 @gitcoffee/postbot-publisher-cn（國內平台發布器）、@gitcoffee/postbot-publisher-it（國際平台發布器）、@gitcoffee/postbot-publish-engine（發布引擎）、@gitcoffee/postbot-plugin-engine、@gitcoffee/api、@gitcoffee/auth 等等。到 npm registry 實際查這些套件名稱，全部回傳 Not Found，它們既不在公開 npm，也沒同步到 GitHub Packages。也就是說，PostBot 公開倉庫提供的是擴充功能的外殼、設定檔與部分內容腳本骨架，真正每個平台選擇器、URL、發文序列的「核心發布邏輯」是打包成私有套件再分發的。這是常見的開放核心（open-core）手法，但對於想 fork 之後自己維護或審計平台發布行為的人，必須意識到：你能讀到的程式碼並不等於安裝包在跑的程式碼。

支援 15 個中文平台，國際平台是另一個產品

從 src/media/meta/ 目錄清點平台清單，可以看到 14 個平台中繼資料檔：微信公眾號（weixin）、微博（weibo）、今日頭條（toutiao）、小紅書（xiaohongshu）、知乎（zhihu）、百家號（baijiahao）、企鵝號（qqOm）、微信影片號（weixinChannels）、抖音（douyin）、快手（kuaishou）、嗶哩嗶哩（bilibili）、豆瓣（douban）、簡書（jianshu）、知識星球（zsxq），再加上音頻發布器裡的荔枝 FM（lizhi.publisher.ts），合計 15 個中文陣地。每個平台還會區分圖文／動態（moment）、影片（video）、音頻（audio）三種內容類型，發布器目錄 src/media/publisher/platform/ 裡按類型分檔。

Pin

至於 X（Twitter）、YouTube、TikTok、Facebook、Instagram、LinkedIn 這些國際平台，README 用了「可輕鬆擴展兼容」幾個字帶過，但實際上它們不在這個倉庫裡。GitCoffee 把國際版拆成另一個獨立產品 Postar（倉庫 gitcoffee-os/postar），同樣走 Apache 2.0 授權、獨立維護，截至撰稿時只有 12 顆星、活躍度遠低於 PostBot 本體。如果你的內容矩陣主要在 X、YouTube、TikTok，Postar 目前還很新，評估時要把這個事實算進去，別被 README 那句「可擴展兼容」誤導成「現成可用」。

合規風險、限制與其他代價

PostBot 的核心機制（用內容腳本在平台官方網頁裡模擬人工操作）本身就是各大平台服務條款的灰色地帶。微信公眾號、小紅書、抖音、知乎、微博的使用協議與反作弊條款，幾乎都禁止「使用未經授權的自動化程式」操作帳號；PostBot 雖然走你自己的瀏覽器 session、用本機 IP，從平台風控的角度更像真人，但技術本質上仍是未授權的自動化操作。實際使用時，帳號遭限流、降權或封禁的風險由使用者自擔，GitCoffee 在授權條款免責段也把這類後果明確推回給你。

另一個限制是雲端依賴。PostBot 的擴充功能必須能穩定連到 postbot.exmay.com 完成登入驗證與心跳，若 GitCoffee 伺服器故障、公司停業或收費政策改變，擴充功能即使安裝在你電腦上也無法工作，這是「原始碼可見、營運不開源」這類開放核心工具共同的弱點。README 把主分支明確標為「快速迭代日常開發版」，穩定版則落在 v1.1.20 分支，想長期使用的人應該裝穩定版而不是主分支。

最後是 dual-use 與濫用的問題。一個能把同一篇內容同步發到 15 個平台的工具，自然也能拿來做洗版、內容農場量產、SEO 程式化濫發。GitCoffee 在 README 明確把反 spam 寫進使用建議（呼籲讀者控制發布頻率、模擬真人節奏、把節省下來的時間投入原創內容），但工具本身不強制這件事。從 Google 反垃圾政策與SEO 角度看，量大但低品質的程式化內容屬於 Scaled Content Abuse 的範疇，使用 PostBot 替自己產出的優質內容加速分發是合理的，拿它做無差別洗版則會反噬自己的網域與帳號。

和雲端 SaaS 分發平台比，差別不在免費

Pin

市面上常見的中文內容分發 SaaS（例如新榜、壹伴、 piryton 這類），商業模式是要求你把帳號授權交給他們的雲端，由伺服器端的 session 農場代為發文，一年動輒人民幣兩三千元起跳。PostBot 與這條路的差別，不在於「免費 vs 付費」，而在於兩個更實質的軸：

• 帳號風險分擔方式不同。雲端 SaaS 用伺服器 IP 操作你帳號，平台風控較容易把這批 IP 判為「異地登入或代理 farm」，但 SaaS 業者會吸收一部分營運與合規責任；PostBot 在你本機瀏覽器裡操作、用你日常 IP，從風控角度看更像真人，但 100% 的合規與封號風險落在你頭上。
• 信任邊界不同。SaaS 要你交出帳號與 cookie，等於把一個能完整控制你創作者資產的鑰匙交給第三方伺服器；PostBot 把內容與 cookie 留在你的瀏覽器，鑰匙不出門，但相應的代價是擴充功能仍有 postbot.exmay.com 的雲端登入層，這個登入層的服務條款與隱私政策需要自己評估。

對在意「我帳號的鑰匙在哪台伺服器」的人，PostBot 走瀏覽器 cookie 復用的路是更乾淨的選擇；對完全不想扛合規風險、寧可花錢買方便的人，付費 SaaS 反而比較合適。對於 Chrome／Edge 工具列已經很熱鬧、想再精簡的使用者，瀏覽器瘦身與擴充功能揀選的原則是另一條可以一起看的角度。

適合誰、不適合誰

PostBot 真正適合的，是已經在 15 個中文平台同時經營、每天在機械複製貼上上耗掉大量時間的個人創作者、OPC 與兩到五人的小內容團隊。它最大的價值是把「同一篇文章改 15 種排版」這件純粹消耗時間的事壓成「一次編輯、同步推送」，而且因為它走瀏覽器 cookie，沒有把你的帳號密碼交給第三方的隱私風險。如果你願意承擔各平台服務條款的灰色地帶、願意花時間維持瀏覽器登入狀態，並且只服務自己一個工作空間，它基本上是零成本。

反過來說，以下幾種情境建議直接跳過：

• 想拿原始碼搭一個對外服務的多租戶 SaaS 平台。GitCoffee Open Source License 明確禁止這條路，必須先取得商業授權。
• 對帳號限流或封禁零容忍（例如品牌官方帳號、企業認證號）。任何未授權自動化都不該出現在這類高資產帳號上。
• 內容矩陣以國際平台為主。Postar 還很新（12 顆星、剛起步），把它當國際分發主力等於押注一個尚未穩定的產品。

授權與專案狀態

授權是 Apache License 2.0 主體，加上 GitCoffee Open Source License 附加條款（禁多租戶 SaaS、禁移除 LOGO 水印、貢獻者 CLA 授權商業使用）。專案到撰稿時的 GitHub 統計是 1199 顆星、159 個 fork、只有 1 個 open issue、最後一次 commit 落在 2026-07-15，整體活躍度仍屬穩定迭代階段。版本編號上，主分支是 v1.2.3，官方 README 把它標為「快速迭代日常開發版」，穩定版指向 1.1.20 分支，想長期部署的使用者應該鎖定穩定分支。npm 公開 registry 上查不到 @gitcoffee/* 套件，意味著自行 build 必須依賴 GitCoffee 提供的私有套件來源，fork 之後想完全自給自足並不現實。

常見問題

PostBot 算開源軟體嗎？

它的原始碼公開可見，但授權並非 OSI 核可的開放原始碼。LICENSE 檔案主體是 Apache 2.0，附帶的 GitCoffee Open Source License 加上「禁多租戶 SaaS、禁移除 LOGO」等商業限制，比較精準的描述是「原始碼可見、單租戶自架免費、商業多租戶需另外授權」的開放核心模式。如果你只是個人或少數團隊自用，這些限制不會影響你；想拿來做對外服務就要先取得商業授權。

用它發文會被平台封號嗎？

技術上，PostBot 走你的瀏覽器 session 與本機 IP，從平台風控角度更像真人操作，但服務條款的本質仍然是「未授權自動化操作」，所以風險無法降到零。控制發布頻率、避免短時間內同步推 15 個平台、把單一帳號的操作節奏擬人化，可以降低風控系統識別的機率，但品牌官方號、企業認證號這類高資產帳號仍建議避開。

國際平台支援情況如何？

PostBot 本倉庫只處理 15 個中文平台。X、YouTube、TikTok、Facebook、Instagram、LinkedIn 被拆到獨立的 Postar 倉庫（gitcoffee-os/postar），屬於另一個產品線、獨立授權與維護，目前 12 顆星、相對不成熟。如果你的內容矩陣是中文為主、海外為輔，Postar 可以當實驗性備案，但不該當主力。

和付費雲端 SaaS 比，哪個比較安全？

「安全」要分兩層看。從帳號鑰匙的角度，PostBot 走瀏覽器 cookie、密碼不出本機，比把帳號交給雲端 SaaS 的伺服器農場乾淨。從合規與封號責任的角度，雲端 SaaS 業者會吸收一部分合規成本（也相對容易被平台風控識別為代理 IP），PostBot 則把 100% 的合規風險留給使用者。沒有絕對的贏家，差別在你願意把哪些風險搬給誰。

整體看下來，PostBot 是一個架構選擇誠實、把隱私做在對的方向上、但合規風險由使用者全扛的工具。它的真正價值不在於「免費取代付費 SaaS」，而在於提供了一條「不把帳號鑰匙交給第三方雲端、卻仍能自動化多平台發文」的中間路。對願意承擔合規灰色地帶、需要的是分發效率而不是代營運的中文內容創作者，它值得一試；對把 PostBot 當成「純本機、零網路」的開源桌面 RPA 來期待的人，原始碼會給你一個更精確的答案。