開源影片轉圖文工具 AI-Media2Doc，自架前先看清雲端流向

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

把一支影片變成一篇有截圖、有小標、能直接貼上社群的圖文，這件事現在有開源答案：GitHub 上的 AI-Media2Doc，超過 4,000 顆星，MIT 授權，丟進影片或音檔，它吐出知識筆記、小紅書貼文、公眾號文章、內容總結、思維導圖或字幕檔。我把它的原始碼完整抓下來讀過一遍後，對「免費」與「隱私」這兩個字有了比較精確的看法：這個專案開源的是工廠，原料全部在雲端。切片、抽音軌、截圖這些粗活確實在你的瀏覽器裡做完，但聽寫要交給字節跳動的語音服務，寫作要交給大模型 API，兩段都按用量計費；更關鍵的是，聽寫那一節的端點直接寫死在原始碼裡，你想整套避開特定雲端供應商，換掉大模型也沒有用。先看清這條資料流向，再決定要不要花一個下午把它架起來。

把音影片變成六種文體

先講清楚產品本身。AI-Media2Doc 是一個網頁工具，前端用 Vue 寫，後端是 Python 的 FastAPI，2025 年 4 月出現在 GitHub 上，作者是韓數（GitHub 帳號 hanshuaikang），個人網站上自述為工程師與 AIGC 愛好者，專案的贊助管道掛在愛發電，微信公眾號與小紅書帳號都叫韓數同學，542 個 fork 裡還能看到其他貢獻者的名字。順帶校正一個常見印象：它沒有官方托管版。我實際連上開發者的個人網站看過，上面只連回 GitHub 倉庫與他的其他專案（Nping 與 Owl），README 裡也沒有任何線上 demo 連結；網路上容易留下「打開網頁就能用」的印象，實際上唯一的入口是自己部署。

操作流程照官方設計是這樣：把影片或 MP3 拖進瀏覽器，從六種文體裡選一種（知識筆記、小紅書、公眾號、內容總結、思維導圖、字幕檔），按下開始轉換，等它跑完就能複製成果或匯出成字幕檔。六種文體的 prompt 全部攤在設定頁裡，可以直接改，改完存在瀏覽器本機；思維導圖有內建的檢視器，轉出來直接展開看。它也有對話功能，生成完可以接著針對影片內容繼續問，等於拿到一份能追問的逐字稿摘要。

Pin

整套流程裡最聰明的一段設計，是它的「智慧截圖」。讀原始碼裡的預設 prompt 模板會看到：筆記風格的模板明文要求大模型「至少返回三張以上的截圖」，做法是在文章裡插入 #image[秒數] 這種記號，例如 #image[20] 代表第 20 秒的畫面，同時要求每個小標題後面標上 [分:秒] 的時間範圍；前端看到記號，就用瀏覽器內建的影片解碼，照秒數截出那一格畫面，直接嵌進對應位置。換句話說，它不需要視覺模型去看懂影片，只靠字幕時間軸就決定了「哪一格畫面值得放進文章」。這個設計讓圖文並茂的邊際成本趨近於零，代價是文章裡的每一張圖都來自原影片的畫面，這點後面談版權時會再回來。

Pin

開箱原始碼：粗活留在本機，兩段細活必然上雲

把 main 分支的原始碼逐檔讀完，它的資料流向可以拆成四層，每層的去向都不一樣。

最底層是瀏覽器裡的媒體處理。ffmpeg 是用 WebAssembly 編譯的版本，從你自己部署的靜態資源載入，不走外部 CDN，負責把影片抽成 MP3 音軌；截圖則走瀏覽器內建的影片解碼，都在本機完成，上傳檔案大小預設上限 200MB，可以在設定裡調。也就是說，整支影片的畫面從頭到尾不離開你的電腦，真正往外送的只有抽出來的 MP3 音軌。

往上一層是聽寫，這也是整個專案最值得看清的一節。它的走法比想像中繞：後端先向你的儲存桶要一組限時一小時的預簽名下載 URL，然後向語音辨識服務提交任務，附上這組 URL，由對方的伺服器憑 URL 主動回頭把音檔抓走。也就是說，音檔從你的瀏覽器直上你自己的桶，再從你的桶被字節的服務拉走，全程不經過這個工具作者的任何伺服器，但也全程沒有離開雲端。而這個語音服務的位址，寫在 backend/routers/audio.py 第 39 行和第 104 行，是 openspeech.bytedance.com，字節跳動的語音辨識 API；我翻遍環境變數的定義檔，沒有任何一個參數可以覆寫它。官方部署教學也是同一套：去火山引擎開通錄音文件識別服務，拿 app id、access token 和 cluster id 三個值回來填，後端還掛了一個每秒一百次的節流器，把對語音服務的請求量平滑掉。

寫作這一段交給大模型：逐字稿加上你選的文體 prompt，生成最終的文章。背後的程式用 OpenAI SDK 寫，端點、模型名稱、金鑰全部吃環境變數，預設指向火山方舟（官方教學推薦豆包的 doubao-1-5-pro-32k），但後端文件明寫可以換成 ChatGPT、Claude、Gemini 或任何 OpenAI 相容的端點。儲存那層，v0.8.0 版起改用標準 S3 協議，官方教學以字節的 TOS 當範例，實際上任何 S3 相容的物件儲存都吃得下，音檔落在你自己的桶裡，截圖則根本不上傳，直接以文字編碼嵌在產出的文章裡。

四層疊起來，結論很具體：大模型可以換，儲存可以換，唯一的硬依賴是聽寫。順帶一提遙測層：我把前端的 package.json 依賴整份翻過，沒有任何分析或追蹤函式庫，任務紀錄存在瀏覽器本機的 IndexedDB，自訂 prompt 與設定存在 localStorage，全程不需要註冊帳號。這部分確實乾淨。

「隱私保護」兌現了什麼，沒說什麼

官方 README 的功能表寫著「隱私保護：無需登入註冊，任務記錄保存在本地」。這句話每個字都對，但它容易讓人讀成「我的內容不會上雲」，而原始碼呈現的事實是：音檔內容必然進入字節跳動的語音服務，逐字稿必然進入你所設定的大模型端點。開發者自己在 README 裡寫的動機其實更誠實，他說不想把想總結的內容上傳到雲廠商以外的第三方平台，所以自己寫了這個工具。換句話說，這個工具承諾的隱私是「內容不經過工具作者的伺服器、不被第三方 SaaS 中間商經手」，你的內容直接從你的瀏覽器走向你自己的雲端帳號，再走向字節的語音服務與你選的大模型。

如果你的底線是「逐字稿相關的任何內容都不能離開本機」，這個工具現在給不了，本地語音辨識還停在官方的未來計畫裡：README 的規劃段寫著要用 fast-whisper 之類的本地模型處理音訊，GitHub 上也有使用者留言希望加入 FunASR、SenseVoice 這類本地後端，但主分支到 2026 年 2 月為止都沒有實作。想走全本機路線的人，本站介紹過的替代品更合適：Bili2text 用一行指令把 Bilibili 影片變逐字稿，AI Video Transcriber 是自架的逐字稿工具，AI Podcast Transcriber 則是本機轉錄加雲端摘要的混合路線，中文語音輸入還有 蛐蛐 QuQu 這種純本機方案可以參考。

自架的門檻不在 Docker，在三組雲端金鑰

部署本身走 Docker：倉庫提供 docker-compose 檔，映像是現成的 hanshugithub/ai-media2doc-backend 與 frontend，指令不複雜。真正花時間的是照後端文件把環境變數補齊，而那些變數對應的是三組要事先申請的雲端配置：大模型（模型 ID 加 API key）、S3 相容儲存（access key、secret key、endpoint、region、bucket 五個值）、語音服務（app id、access token、cluster id 三個值）。全部填完才能跑，缺一個都不行。另外有一個選填的 WEB_ACCESS_PASSWORD，設了之後前端要先填密碼才能連後端；後端的 CORS 設定是全開的，FastAPI 的互動文件頁也預設開著，如果你想把它架到有對外 IP 的機器上，這個密碼強烈建議設。

成本結構照原料算，而且聽寫與寫作的計價單位不一樣。試用額度按音檔時長扣：一支出 30 分鐘的影片，抽出的音軌就扣 30 分鐘的量。寫作按 token 計：逐字稿餵進大模型算輸入，生成出來的文章算輸出，單次輸出的長度上限預設 8,192 tokens，在前端也能調。程式碼免費；聽寫服務的官方說法是每個辨識模型提供 20 小時試用額度，文件裡甚至明寫「可以輪流試用」，等於輕度使用有機會長期壓在近乎零成本，但額度政策是雲端廠商說了算，隨時可能改；正式用量就按帳單走；儲存費用通常是小零頭。整體而言，個人知識管理的用量級距多半遠低於任何一套訂閱制服務，但「完全免費」四個字只對得起程式碼那一層。

和托管型服務比，這套自架的差別可以用「中間商消失了，雲端還在」一句話總結。用線上服務時，你的音檔先進對方的伺服器，再進對方簽約的聽寫與模型供應商，計費與留存規則都包在方案裡；自架這套時，音檔進你自己的桶，聽寫與模型用你自己的帳號計費，用量與帳單全部透明，換供應商的權限也握在自己手上（聽寫除外）。你換到的是控制權與成本透明，付出的是部署與維運的工。

2026 年動手架它，會撞到的兩件事

這個專案的主分支最後一次提交停在 2026 年 2 月 5 日，最新版 v0.8.0 是 2025 年 11 月 23 日發的，之後的提交只剩 README 與文件更新，程式碼自 2025 年 11 月底起就沒再變動。對一個仰賴外部 API 的工具來說，停更的代價很快就會浮現：2026 年 4 月底有使用者在 issue #109 回報火山引擎的語音辨識服務「變化很大」，8 月的另一則 issue #114 直接說 README 教的 AUC_CLUSTER_ID 用法已經過時；社群提交的 ASR v3 支援（pull request #115）到 9 月初都沒有被併入，同樣在排隊的還有接 TwelveLabs 視覺模型的選配 pull request #113，以及希望直接貼 Bilibili 連結抓片的 issue #116。也就是說，你今天照著官方文件去申請語音服務，有實際機率撞上文件與現況脫節，得回頭翻 issue 討論區對答案；Docker 映像跟著版本標籤打包，最新的映像也停在 2025 年 11 月 23 日。部署問題的討論集中在置頂的 issue #39，六十多則留言，從埠號衝突到依賴安裝都有，另外有人回報上傳端點噴出 431 標頭過大的錯誤（issue #112，標題誤寫成 413）。

把這兩件事放在一起看，判斷是這樣：這不是死專案，星數與 issue 活躍度都還在，但它的上游（字節的雲端服務）在動、它的程式碼沒在動，這種組合的風險要自己認。你能接受「照文件申請卡住時自己去 issue 找答案」，它依然是這個需求底下最完整的開源選項；你要的是裝好就能用、有人持續維運，那付費服務或活躍度更高的專案比較合理。

拿別人的影片當原料之前

工具的六種文體裡，小紅書與公眾號這兩種，注定讓它被拿來做內容二創：把別人拍的影片，轉成自己帳號的圖文貼文。這裡的邊界要自己畫，而且可以畫得很具體。把別人的教學影片轉成自己帳號的貼文，文章裡還嵌著從原影片抽出的畫面，這在多數認定下就是搬運，截圖的授權狀態不會因為「是 AI 挑的畫面」而改變；把課程錄影或演講轉成自己看的筆記，私用空間大得多，但把同一份筆記公開分享，又是另一個層級的判斷。平台那端，小紅書與公眾號對重複內容與搬運行為都有自己的規則，大量產出的同質貼文在演算法與審核兩側都有風險。有意思的是生態觀察：開發者自己同時維護了一個叫 Owl 的免費工具，專門檢測小紅書與公眾號貼文的敏感詞，還直接掛在 AI-Media2Doc 的 README 裡。產出內容前先過敏感詞檢測，已經是這個內容工程鏈的標配動作，工具鏈會照顧你的合規字詞，不會照顧你的授權來源。

相對地，正當用途也很多，而且正是這個工具設計的出發點：把自己的上課錄影變成講義、把部門會議錄音變成知識庫條目、把自己頻道的舊影片重新整理成圖文。同樣在做「素材變圖文」這件事的工具，本站還介紹過 智寫流程，把網頁操作錄影自動寫成圖文教學；text2card 把整篇文章濃縮成一張社群圖卡；Social Auto Upload 則處理產出後的下一哩路，把影片發上十個平台。想再往上游走，MuJing 把影片字幕變成有前後文的單字庫，ebook2me 把電子書拆成思維導圖，這幾個工具可以按你的內容流程自由組合。

素材是自己的，才值得花這個下午

適合自架的人：手上定期有自己的音影片素材想變成圖文（課程、會議、自己的頻道），願意花一個下午申請三組雲端配置，而且能接受音檔內容進字節跳動的語音服務。這群人拿到的是目前「影片變多文體圖文」需求裡最完整的開源實作：MIT 授權可以自由改，前端乾淨沒有遙測，截圖機制設計得聰明，素材又是自己的，版權與平台風險都最低。不適合的人分兩種：底線是全本機處理的，往 Bili2text 或 AI Video Transcriber 這類本地路線走；不想架任何東西、只想丟檔案等結果的，SubEasy 這類線上字幕服務或 Any2Text 比較符合使用習慣，代價是換成別的計費與隱私條件。

動手的順序建議這樣：先去 GitHub 把 issue #39 的部署討論掃一遍，確認當下的坑在哪；再照後端文件依序申請語音服務、大模型、儲存三組配置，邊申請邊對照 issue #109 與 #114 的最新說法，文件過時就以 issue 為準；金鑰補齊後用 docker-compose 起服務，設好訪問密碼再對外。跑通第一支影片後，回頭把小紅書模板的 prompt 打開看一眼，你會更清楚它寫出來的東西帶著什麼樣的口吻，再決定要不要讓它代表你的帳號說話。

最後回到那個一開始的問題：它到底是不是「免費的內容工廠」。工廠是免費的，原料按表計費，而且固定向兩家雲端供應商進貨，其中一家你想換也換不掉。這個結構對願意自架、素材又是自己的人是划算的交易；對其他人，市場上還有更省事的路，本站介紹過的幾條都附在上面了。