twitter-to-bsky：把 X 貼文同步到 Bluesky 與 Mastodon 的瀏覽器 userscript

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

twitter-to-bsky 是一個裝在桌面瀏覽器的 userscript（使用者腳本），做的事情很明確：你在 Twitter/X 網頁版按下發文的同時，把同一則貼文順便送去 Bluesky 和 Mastodon。它的載體是 Tampermonkey 或 Violentmonkey 這類腳本管理器，直接在你打開的 x.com 網頁上執行，既不是獨立 App，也不走雲端代發服務那條路。

它最值得講清楚的不是「能跨平台發文」這件事本身，而是它達成這件事的方式：你的 Bluesky App Password 和 Mastodon Access Token 只存在你自己瀏覽器的腳本管理器裡，訊息從你的瀏覽器直接打去兩個平台的官方 API，中間不經過任何第三方伺服器。這個架構選擇會直接影響你願不願意把帳號憑證交給它，下面把隱私架構、安裝手續和硬限制一次拆開來講，憑證怎麼存、API 怎麼打，都對著它的原始碼與官方說明來談。

跨平台同步為什麼在遷移期有意義，又有什麼前提

先把「到底為什麼要同步發文」這件事講清楚，因為它不是萬靈丹。README 自己也明說，跨平台同步（crosspost）在一般情況其實是被建議避免的做法，理由是每個平台的讀者期待、互動節奏都不同，機械式複製貼上通常會讓兩邊都經營不好。

但它劃出了一個明確的例外：平台遷移期。當你主要還在 X 上活動，但已經開始在 Bluesky 或 Mastodon 經營新帳號，此時你的新平台還沒有累積足夠的追蹤者，如果完全不同步，舊平台的讀者根本不知道你搬家了。在這段過渡期，把比較通用的內容（例如轉發的新聞連結、你自己的文章、公開公告）順手同步過去，可以讓新帳號不斷訊、讀者也多一個追蹤你的管道。

前提也很清楚。README 點名，私訊、回覆、@提及這類「Twitter 特定互動」不適合同步，因為它們的意義綁在 X 的社交圖譜上，搬到別的平台只是斷頭屍。換句話說，這個工具的甜蜜點是「你本來就要對外廣播的公開內容」，而不是你在 X 上的所有活動。把它當成全自動備份機器會失望，把它當成遷移期的訊息橋樑則剛剛好。如果你要的是把 X 上的歷史推文整批留存，那是另一種工具的任務，例如 thattweet-tweet-saver 這類專門抓取保存推文的方案會更對口。

憑證不離開瀏覽器：它的隱私架構長這樣

這是整個工具最該被理解、也最容易被忽略的一層。很多號稱能幫你跨平台發文的雲端服務，運作方式是：你把兩個平台的帳密交給某個伺服器，由那個伺服器代你發文。方便，但這代表你的憑證和內容都會經過一個你看不見的第三方。

twitter-to-bsky 走的是完全相反的路。我把它的原始碼攤開來看，幾個關鍵事實是：

憑證儲存用的是 GM_setValue，也就是 Tampermonkey／Violentmonkey 這類腳本管理器提供的沙盒儲存空間，而不是網頁常見的 localStorage。差別在於，localStorage 任何在該網域執行的腳本都能讀，而腳本管理器的儲存空間只配給被授予權限的那一支腳本，隔離性強一層。你的 Bluesky App Password 和 Mastodon Access Token 就是存進這裡，不會被 x.com 網頁上的其他程式碼隨意讀走。

送出貼文時，它直接呼叫兩個平台的官方 API。Bluesky 這邊，原始碼裡寫死的是官方 PDS 位址 https://bsky.social，走的是 AT Protocol 的標準端點：先用 com.atproto.server.createSession 建立工作階段、用 repo.uploadBlob 傳圖片、最後用 repo.createRecord 寫入一則 app.bsky.feed.post。Mastodon 這邊則是走你自己填的實例網址（例如 https://mastodon.social）的標準 REST API。整條呼叫路徑上沒有任何中繼伺服器，訊息從你的瀏覽器直奔兩個平台。

這個設計的代價也要講明白。腳本為了能在 x.com 網頁上跨網域呼叫 Bluesky 和 Mastodon 的 API，向腳本管理器申請了 GM_xmlhttpRequest 權限，這個權限本質上允許腳本對任意網址發請求。也就是說，你裝的不只是一支能幫你發文的腳本，而是一支具備廣泛網路請求能力的程式。它安不安全，最終取決於你信不信這個專案的作者、以及你有沒有能力或意願去讀原始碼確認它沒有偷做什麼。好消息是它是 MIT 授權、原始碼完整公開在 GitHub 上、整支腳本只有 32KB，等於是可被任何人審計的，這和那種閉源的雲端代發服務在本質上不同。

怎麼裝、怎麼設定：你要先準備好兩組憑證

安裝流程本身不複雜，但前置作業比較多，因為兩個平台各自的存取憑證不會自己長出來。

第一步是先裝好腳本管理器。桌面版的 Chrome、Firefox、Edge 都支援，任選 Tampermonkey 或 Violentmonkey 其中一個裝即可。裝好之後，打開腳本的原始碼連結（repo 裡的 twitter-to-bsky.user.js），腳本管理器會偵測到並詢問要不要安裝，同意就完成。

第二步是把兩組憑證生出來。Bluesky 這邊，要到設定裡的「進階 → App Passwords」建立一組應用程式密碼，注意這不是你的登入主密碼，而是只能給外部程式用的獨立密碼，可以隨時撤銷。Mastodon 這邊，則是到你自己實例的「設定 → 開發 → 新增應用程式」裡申請一組 Access Token。這兩組憑證是兩個平台各自設計的安全機制，不是 twitter-to-bsky 自己發明的，學會產生它們對你用其他第三方客戶端也有幫助。

第三步是把憑證填進腳本。重新載入 x.com 之後，導覽列會多出一個黑色的交叉按鈕，點開是一個小設定視窗，把 Mastodon 實例網址、Mastodon Access Token、Bluesky Handle（完整格式，包含 .bsky.social）、Bluesky App Password 分別填進去存檔。存檔之後，發文區的工具列會多出「Mastodon」和「Bluesky」兩個勾選框，打勾再發文，那一則貼文就會同步送過去。

Pin

Pin

整個設定流程比裝一般瀏覽器擴充功能多一些手續，本質上比較接近開發者等級的設定。如果你過去裝過 postbot-content-sync-extension 這類需要綁定帳號的內容同步擴充功能，上手會比較順；如果完全沒接觸過 API 憑證，第一次操作會需要對照兩個平台的說明文件走一次。

圖片可以、影片不行：那個 1MB 上限要知道

腳本支援的內容類型有三種：純文字貼文、附一張或多張圖片的貼文、帶連結預覽卡的貼文。影片和 GIF 則明確不支援，原因是 Bluesky 目前本身就還不支援這兩種格式，README 和原始碼都誠實標明了這個限制。

圖片這邊有兩個寫死的大小上限要注意，這是我從原始碼常數直接讀到的：Bluesky 的圖片上限是 1MB，Mastodon 的圖片上限是 8MB、影片 40MB。超過上限時兩個平台的處理方式不同，原始碼看下來是：Bluesky 超過 1MB 時，腳本會自動用 canvas 把圖重新壓縮成較小的 JPEG 再傳；Mastodon 超過 8MB（圖）或 40MB（影片）時，腳本則會直接報錯、不幫你壓。所以習慣貼高解析度原圖的人，送到 Bluesky 那邊會被自動降質，這個行為會實際影響轉發出來的畫質，發圖前最好心裡有個底。

連結預覽卡則是另一個支援的類型，當你在 X 的貼文裡貼了一個網址，腳本會試著在目標平台也產生對應的預覽。不過實際能不能正確生成預覽，取決於目標平台自己抓網頁的能力，這部分的穩定度我沒辦法從原始碼判斷，只能說功能存在。

手機發文、批次備份、商業穩定度：它補不上這三塊

把會改變你決定的邊界一次講清楚，免得裝完才發現跟預期落差太大。

最影響適用範圍的一點是，它只在桌面瀏覽器的 x.com 網頁版上作用。原始碼的 @match 寫死只比對 twitter.com 和 x.com 兩個網域，手機版 Twitter App、Tweetdeck、第三方客戶端都用不了。你的發文習慣如果主要在手機上，這個工具直接出局。

Firefox 使用者則要特別留意腳本管理器的選擇。作者在 README 的已知問題裡宣稱，Firefox 搭配 Violentmonkey 時，因為瀏覽器的內容安全策略（CSP），大約每兩次就會有一次被擋下而失效，作者建議 Firefox 用戶改用 Tampermonkey。Chrome 搭配 Violentmonkey 則沒有這個問題。這是作者本人的說法，我沒有在 Firefox 上實際重現這個間歇性失效。

維護狀態也要誠實看待。這個 repo 在 GitHub 上目前是 96 顆星、7 個 fork，最後一次提交停在 2024 年 5 月，距今已經兩年多，版本號是 0.14，還掛著 11 個未解的 issue。它不是死了，但也稱不上活躍迭代。這代表它能用、可讀、可改，但若 X 又改了網頁結構導致腳本失效，沒有人保證會及時修。userscript 這類工具天生就依賴目標網站的 DOM 結構維持穩定，目標一改版，腳本就得跟著修，這是裝任何 userscript 都要承擔的長期風險。

授權有個小細節要交代清楚。GitHub 的 repo 資訊顯示這個專案沒有獨立的 LICENSE 檔案，但是腳本檔頭和更新用的 meta 檔裡都明確標了 @license MIT。對絕大多數只想拿來用的人沒有影響，MIT 是最寬鬆的授權之一，商用、修改、再散布都允許；但如果你是要拿原始碼做正式產品化，建議把檔頭的 MIT 宣告視為授權依據，並留意 repo 缺獨立授權檔這個事實。

最後它和 RSS 式的內容分發是不同的策略。像 feedcraft-rss-middleware 或 topfeed 這類工具，走的是「訂閱來源、再分發」的迴圈，適合把固定來源的內容批量推到多個管道。twitter-to-bsky 則是「你手動發文的當下順手同步」，觸發點是你自己、而不是某個 RSS 來源更新。兩者解決的問題不同，選哪個看你分發的內容是即時創作還是來自固定來源。

桌面 x.com 發文加遷移中的帳號才構得到

適合用的人輪廓相當明確：你主要在桌面瀏覽器用 x.com 發文、內容多是公開的廣播型訊息（文章連結、公告、轉發的新聞）、你正在從 X 遷移到 Bluesky 或 Mastodon 但新帳號還沒站穩、而且你不介意花十分鐘把兩組 API 憑證弄出來填好。在這個情境下，它是一個輕量、免費、架構上把憑證留在本機的實用橋樑，比起把帳密交給雲端代發服務，這種點對點的設計對隱私敏感的人更好接受。

另外有一群人特別適合：會讀原始碼、想自己改的人。它是 MIT 授權、純 JavaScript、整支腳本只有 32KB，門檻很低，想加自訂篩選規則、換掉預設的 Bluesky PDS、或接到自己架的 Mastodon 實例，都可以直接 fork 出來改。對這種人來說，「功能精簡」等於一個好下手的基礎，不是缺點。

構不到的人也很清楚。如果你的發文主力在手機 App，這個工具根本碰不到你；如果你期待的是把 X 上的歷史推文整批搬走，這不是它的任務範圍，它只處理「裝好之後新發的貼文」；如果你需要的是穩定、有商業支援、出問題能找客服的解決方案，一個 96 顆星、單一作者、最後更新停在兩年多前的 userscript 不會是答案，這時候花錢找成熟的代發服務或社群管理工具反而實在。

把話說到底，twitter-to-bsky 是一個定位精準的小工具：它不假裝能解決跨平台經營的所有問題，只把「遷移期的即時同步」這一件事用一個隱私架構相對乾淨的方式做到。能不能用得上，取決於你的發文情境是不是落在它劃出的那個範圍裡。