Social Auto Upload 實測：一行指令把影片發上 10 個平台

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

同樣一支影片要發到五個平台，大多數創作者的流程是：開五個分頁、登入五次、拖五次檔案、各打一次標題，中間還會遇到上傳進度卡住、標題字數限制各不相同、某個平台又改了介面。GitHub 上 14,682 顆星的開源專案 Social Auto Upload（dreammis/social-auto-upload）把這件事收斂成一行 sau 指令：抖音、快手、小紅書、Bilibili、微信的短影片平台 Channels、百家號、支付寶生活號、微博、虎撲、YouTube，十個平台的影片發佈全部走命令列。結論先講：指令化多平台分發是真的，帳號登入檔留在你自己機器上也是真的；但它是一套「跟著平台網頁改版跑」的工具，2026 年 8 月單月，repo 裡就有至少 8 筆跟平台端變動交戰的修復與回報。裝之前把這兩面都看清楚，再決定要不要把它接進自己的工作流。

基本盤先攤開：這是 2023 年 12 月建立的個人專案，作者 dreammis 自述本業在創業，2026 年 3 月曾公開說明前一段時間維護偏慢、接下來要密集重構，從 commit 節奏看（6 月 44 筆、8 月 29 筆）重構確實跑起來了。授權是 MIT，Python 寫成，自架自用，沒有雲端服務要註冊。我把專案 clone 到自己機器完整裝了一次、實際跑了 CLI，也把十一個平台上傳器的原始碼逐檔讀過；上傳流程本身需要真實創作者帳號才走得到，所以關於發佈行為的描述，以下都以原始碼與官方 README 為準。

Pin

照官方文件安裝，會在第三次才真正跑起來

安裝時間線如實記錄。第一步照 docs/install.md 走：clone 專案、建虛擬環境、執行 pip install -e .，套件註冊了 sau 指令，看起來一切正常。第一次跑 sau --help，直接噴出 ModuleNotFoundError: No module named 'conf'。原因不神秘：repo 裡只有 conf.example.py 範本，要自己複製成 conf.py，而這一步排在安裝文件的第 5 步，也就是說文件假設你會先讀完再動手，實際上多數人裝完就會先試跑指令，於是先撞牆。

複製範本之後第二次跑，換了一個錯誤：ModuleNotFoundError: No module named 'playwright'。這個就比較有意思了。專案的瀏覽器自動化主線用的是 patchright（Playwright 的防偵測分支），pyproject.toml 也只宣告了 patchright；但 8 月中才補上的一批上傳器（百家號、支付寶生活號、微博、虎撲）在模組頂端 import 的還是原生的 playwright，這個套件既不在依賴清單裡，整份文件也沒有一行字叫你安裝它，報錯指到百家號只是因為它排在載入順序第一個。手動 pip install playwright 之後，第三次執行，CLI 選單才完整印出來。

這兩個坑都不致命，但它們說明了這個專案目前的現實：依賴宣告、文件與程式碼之間存在縫隙，安裝過程要有基本除錯的心理準備。README 自己也寫得明白，「詳細文件已落後」，官方建議是把整個 repo 直接交給 AI agent 幫你裝。會用命令列的人卡住時多半能自救，完全沒碰過 Python 環境的人，這一步就是第一道篩選。

它真正做的事：把「登入後的創作者後台」變成指令

剝開包裝，這套工具的核心動作只有一個：用瀏覽器自動化模擬你在各平台創作者後台的手動操作，開檔案選擇器、填標題、上傳、按發佈。CLI 支援的十個平台各對應一個上傳器模組，指令長相是 sau douyin upload-video --account 帳號名 --file 影片.mp4 --title "標題" 這樣的形式，Bilibili 補上分區參數、YouTube 補上播放清單與可見度參數。TikTok 是清單裡的例外，沒有接進 CLI，只剩範例腳本，README 註明當前示範走 Chrome 版實作。

帳號的處理方式值得單獨講。每一個帳號對應一個 JSON 檔，放在本機的 cookies 目錄，命名規則是「平台_帳號名.json」，內容是 Playwright 的 storage_state，也就是把整個登入狀態（cookie 與工作階段資訊）存成檔案，下次執行直接帶著它開瀏覽器，不必每次都登入。第一次登入怎麼做？抖音、快手、小紅書、Bilibili 掃 QR 碼，終端機會印出條碼也會存成圖檔；YouTube 則是開瀏覽器走 Google 帳號互動登入。抖音發佈若觸發簡訊二次驗證，程式會去讀專案根目錄的 verify_code.txt 拿驗證碼，送出後隨即刪除該檔。

這個設計的含義是：你的帳號憑證全程待在自己機器上，一個帳號一個檔案，多帳號可以按帳號名並行發佈，沒有任何第三方伺服器經手你的登入資訊。對同時經營多個平台的人，這比把帳號密碼交給雲端服務的 SaaS 路線單純；代價是機器要自己養，環境要自己顧。

為什麼繞過官方 API？YouTube 那條路的理由與代價

很多人第一個疑問是：平台不是都有官方 API 嗎，為什麼要用瀏覽器自動化這種聽起來就脆弱的路？作者在 README 的 YouTube 段落親自回答了這題。他宣稱，未通過 Google 合規審核的 API 專案，上傳的影片會被強制鎖成私享狀態、無法改成公開，對個人頻道與單一頻道場景不實用；瀏覽器自動化沒有這個限制，可以直接發公開影片，也與其他平台的 cookie 方案一致。

這段自述值得來回讀兩遍。它一方面解釋了技術選型的現實（官方 API 的合規門檻把個人使用者擋在外面），另一方面也等於承認：走瀏覽器這條路，就是為了繞過平台的審核閘門，而繞路的代價是授權上的灰色地帶，以及對平台網頁結構的深度依賴。Bilibili 是十個平台裡的異數，它不走瀏覽器，而是包裝另一個開源專案 biliup 來上傳，首次執行時自動下載，README 也明確致謝了這層關係。

原始碼層還藏著幾個實作細節。YouTube 上傳器會等網頁進度跑到 100% 才點發佈，因為瀏覽器上傳靠著視窗開著才傳得完，傳一半就按發佈會把流程掐斷卡在中途，這是程式註解裡寫明的理由。標題欄在程式碼層直接截斷為前 100 個字元，對齊 YouTube 官方上限，這表示超長標題不會報錯，而是默默被切掉尾巴，下標題時自己留意。

八月的時間線：平台一改版，工具就進廠

瀏覽器自動化的脆弱是結構性的，而這件事有具體的時間線可以佐證。把 2026 年 8 月 repo 的 issue 與 PR 逐筆攤開：8 月 11 日，微信 Channels 上傳卡住的修復，處理無限重試與 iframe 等待逾時；8 月 13 日，單日一批變動，微信 Channels 因為平台端編輯器改版需要適配修復，同一天微博、虎撲、支付寶生活號三個新上傳器上線，百家號整個重寫接上 CLI；8 月 19 日，有使用者回報抖音標題欄的 placeholder 改版弄壞了圖文上傳；8 月 22 日，微信 Channels 登入過期後的自動救援；8 月 26 日，快手兩筆發佈時序修復，其中一筆是上傳還沒完成就送出發佈導致無限循環；8 月 27 日，小紅書發佈頁載入逾時被誤判為失敗；8 月 29 日，抖音 placeholder 變體的修復以 PR 形式提出，截至查詢時還開著。

這不是「品質差」三個字可以總結的，它是這類工具的本質：自動化腳本依賴平台網頁的 DOM 結構，標題欄的 placeholder 文案、按鈕位置、彈出選單的層級，任何一項改動都可能讓上傳器找不到元素。平台改版的頻率，就是這套工具的維修頻率。而且 main 分支最新 commit 停在 8 月 20 日凌晨，上面那串修復不少還掛在 open 狀態，急著用的人要有自己 fork 去改選擇器的心理準備。反過來說，8 月單月就有人修，也證明專案還活著、社群還在動，這兩件事是同一枚硬幣的兩面。

「智慧排程挑最佳發佈時間」？行銷頁有，程式碼沒有

網路上流傳的介紹，以及官方文件站自己的行銷頁，都寫著類似「智慧排隊和流量高峰期排程，根據平台演算法特性自動選擇最佳發佈時間」的描述。我把整個 repo 的原始碼搜了一遍，不存在任何挑選最佳時間的邏輯。排程的實際機制是：程式去叫出平台自己的排程設定（例如 TikTok 後台的 Schedule 選單），把你要的發佈時間填進去，然後統一遵守一個 2 小時的最小提前量常數。作者在專案背景裡也說得直白：他自己的發佈策略是前一天排隔天發佈，所以排程相關邏輯是圍繞「第二天」設計的。換句話說，這是排程的執行器，不是流量最佳化引擎；行銷頁那句話把平台自己的排程功能包裝成了工具的智慧。

同一份行銷文案裡的訊息通知能力（例如結合 Slack 接收發佈狀態），在程式碼裡同樣找不到對應實作。文件站的數字也停留在很早以前：星數寫 4.6k+、fork 寫 765+，而 GitHub 實際數字是 14,682 與 2,521（2026-08-31 查詢）。要判斷這個專案的現況，以 repo 的 README 與 issue 列表為準，文件站的行銷頁當參考就好。

Pin

帳號風險與授權，兩件事都想清楚再上

把主力帳號交給自動化之前，有兩個層面要想清楚。第一個是平台風險。多數平台的使用者條款對自動化工具的立場是保留的，而這個專案對「被偵測」這件事並不天真：作者在 2026 年 3 月的近況說明裡，把「使用更隱蔽、更穩定的自動化方案，盡量降低平台檢測風險」列為重構方向，主線也換上了防指紋偵測的 patchright 驅動，並附了反偵測腳本。工具方主動追求隱蔽性，等於承認偵測壓力真實存在。實務上常見的做法是用小號或新號先跑一陣子，觀察有沒有限流、驗證碼變頻繁、功能被降權等訊號，再決定要不要把重要帳號放進來。

第二個層面是授權。MIT 是 2026 年 8 月 20 日才補上的，這個 2023 年 12 月建立的專案，前面有將近三年處於「程式碼公開但沒有授權檔」的狀態，期間 7 月還有使用者開單詢問授權問題。現在補上之後，README 明文寫了可以在遵守條款的前提下用於商業軟體，包含閉源軟體，Bilibili 能力基於 biliup 的封裝也有交代來源。另外有個值得觀察的方向：8 月 28 日出現了一個開放中的提案，讓海外平台改走 API 發佈、不需要瀏覽器與 cookie。如果哪天合併進主線，前述「平台改版就壞」的邏輯對海外平台會鬆動一截，屆時這套工具的體質會不一樣。

誰該裝、誰繞道

綜合這輪安裝與原始碼檢視，我會把它推薦給兩種人：一種是同時經營多個平台、清單剛好落在抖音、小紅書、Bilibili、微信 Channels、微博這組中文圈平台的創作者或小團隊，手動重複上傳的痛最強，工具覆蓋也最完整；另一種是本來就會跑 Python 環境、遇到壞掉願意自己修或等社群修的人。把視角切到使用情境：清單裡真正國際通用的是 YouTube、TikTok、Bilibili 與小紅書，抖音和 TikTok 是不同的 app、不同帳號體系，別預期一個指令兩邊同發；而微信 Channels、百家號、支付寶生活號、虎撲這幾個平台，對非中國大陸市場的創作者實用性有限，挑平台時先對照自己的分發地圖。

三種情況建議繞道：想要開箱即用、有客服可找的 SaaS 體驗的人；不想碰命令列與虛擬環境的人；以及手上只有一個不能出事的主力帳號、又沒有本錢承擔平台風險的人。想試的人，第一步不需要登入任何帳號：clone 下來、裝好、跑一次 sau --help 看選單，感受一下指令形態，再決定要不要進入掃 QR 碼登入那一步。

放到內容工作流裡看，它補的是「最後一哩」那段。進料端先前介紹過的 F2 開源下載函式庫與 小紅書去浮水印下載器處理素材那一側；把影片內容轉成文字再利用，可以搭配 AI Video Transcriber 這類轉錄工具；拍攝端掛個 線上提詞機顧好講稿。素材、剪輯、字幕、發佈整條鏈自己拼，成本是自己扛維運，換到的是每一段都握在自己手上，Social Auto Upload 佔的就是發佈那一格。