TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
yt-dlp-script 批次影片下載腳本，把整串指令收進數字選單
yt-dlp-script 是把 yt-dlp 包成數字選單的批次影片下載腳本：貼連結選畫質就能抓，urls.txt 整批下載也行。逐行讀完兩支腳本後，整理它實際組出的格式選擇器、Windows 與 Linux 版的預設差異、Cookie 功能的未驗證警示，以及維護停滯與無發行版這些裝前該知道的代價。
用 AI 摘要這篇文章：
如果你的問題是「yt-dlp 很強，但每次都要查參數」，yt-dlp-script 給的答案很直接：把整條指令列包成一個數字選單。執行腳本、選單片或批次、貼上連結、按鍵選畫質，它就把格式選擇器、執行緒數、輸出目錄組好，交給 yt-dlp 去抓。下載這件事從頭到尾都是 yt-dlp 在做，這支腳本裡一行下載邏輯都沒有。
我把它的 Linux 版 yt-dlp.sh（481 行）與 Windows 版 yt-dlp.bat（257 行）逐行讀完，也翻了專案的提交紀錄與 issue。這篇整理它實際組出什麼參數、兩個平台的行為差異，以及幾個裝之前該知道的代價；實際下載速度與穩定度，要你自己跑一輪才算數。先講判斷：把它當「免記參數的選單殼」，它稱職；期待它是更強的下載引擎、或是一個有人長期維護的工具，這兩個它都不是。
四個數字鍵，翻譯的是一串格式選擇器
選單流程很短，底下以 Linux 版為例。腳本跑起來先問模式：單片、批次，或檢查更新。單片模式貼一條連結就好；批次模式讀 config 資料夾裡的 urls.txt，一行一條連結，檔案不存在時腳本會自動建一個空檔給你慢慢填。接著問輸出目錄（預設 ./video）、解析度（480P、720P、1080P、2160P 四個檔位）、執行緒數（1 到 10）。
這幾步走完，腳本組出的核心其實是一串 yt-dlp 的格式選擇器，四個畫質檔位共用同一個模板：
bv[height<=1080][ext=mp4]+ba[ext=m4a]/best白話講：抓「解析度不超過指定值、封裝格式是 mp4」的影像軌，配上 m4a 音軌，再用 ffmpeg 合併成單一 mp4 檔，這也是腳本要求先備妥 ffmpeg 的原因。結尾的 /best 是備援：yt-dlp 官方文件對斜線的定義是左側優先、右側備援，所以當某支影片沒有符合上限的 mp4 版本時，會直接退到該影片的最佳畫質。換句話說，畫質檔位是「盡力不超過」而非保證值，想固定抓小檔的人要盯一下產物大小。
「執行緒數」也常被誤解。它對應的參數是 --concurrent-fragments，平行處理的是單一支影片內部的切片，長片常被切成幾十段串流，這個數字決定同時抓幾段。批次模式則是用 -a 逐行讀清單、一部接一部下載。想把整批任務加速，調高這個數字幫助有限；README 也提醒記憶體小的機器別開太高，Linux 選單裡給的建議值是 4 到 6。
按下開始前的確認畫面值得看一眼，它把最終配置全部攤開：模式、連結、解析度上限、執行緒數、輸出目錄，連 cookies.txt 有沒有內容都標出來。批次模式還會先數清單行數，告訴你偵測到幾條連結才開始。對第一次接觸指令列工具的人，這一屏等於把即將執行的指令翻成人話，出錯前最後一次反悔的機會也在這裡。
Windows 和 Linux 版，其實是兩套預設
兩個平台拿到的體驗不一致，差異先藏在預設值。Linux 版的預設寫死在腳本原始碼裡：2160P、5 個執行緒；Windows 版第一次執行時產生 config.ini，分成 single 與 batch 兩組設定，預設 1080P，批次模式的執行緒預設還降到 3。想改 Linux 版的預設得直接改腳本，Windows 版編輯 ini 檔就好。
| 項目 | Linux 版（yt-dlp.sh） | Windows 版（yt-dlp.bat） |
|---|---|---|
| 預設畫質 | 2160P（寫在腳本裡） | 1080P（config.ini） |
| 預設執行緒 | 5 | 單片 5、批次 3 |
| 依賴安裝 | 自動：偵測後詢問，apt、yum 或 apk 裝 ffmpeg，並自動下載 yt-dlp | 手動：自備 yt-dlp.exe、ffmpeg.exe、ffprobe.exe |
| 更新入口 | 選單內建檢查更新（yt-dlp -U） | 無，自行更新 |
安裝形態也分岔。Linux 是一行 curl 叫出 install.sh，它做的事情很單純：建一個 yt-dlp 目錄、抓最新的 yt-dlp.sh、執行它。真正在做事的是腳本內建的依賴檢查：先確認 curl 存在（這是它下載一切的前提），發現缺 yt-dlp 時問你要不要自動抓，抓的來源是 yt-dlp 官方 GitHub releases 的最新執行檔；缺 ffmpeg 時同樣詢問，Debian 與 Ubuntu 走 apt、CentOS 走 yum 加 EPEL、Alpine 走 apk，認不出的系統會叫你手動裝。Windows 沒有安裝器：你要自己從 yt-dlp 官方 releases 下載 yt-dlp.exe，從 ffmpeg 建置包解出 ffmpeg.exe 與 ffprobe.exe，三個執行檔全部跟 yt-dlp.bat 放進同一個資料夾。
選單裡的「檢查更新」也有平台差異。Linux 版跑的是兩段式：先對 yt-dlp 本體下 -U 參數自我更新，失敗就繼續用現行版本不中斷；ffmpeg 則交給系統套件庫升級，依 Debian、RedHat、Alpine 分別走不同的升級指令。Windows 版選單裡沒有這個選項，更新是自己的事。對這類追著網站改版跑的工具來說，「引擎能不能一直保持在最新」比選單華不華麗重要得多，這點 Linux 版照顧得比 Windows 版周到。
解除安裝有個小坑。uninstall.sh 會刪掉整個安裝目錄，但問你要不要一併移除 ffmpeg 時，寫的指令只有 apt-get 那一套；CentOS 或 Alpine 裝起來的 ffmpeg 沒有對應的清理路徑，要自己補指令。
Cookie 這條路，作者自己掛了警示牌
需要登入才能看的影片，腳本留了一條路：把 cookie 存進 config/cookies.txt。下載時腳本會帶著 --cookies 參數先試一次，失敗就自動退回不帶 cookie 再試一次。這個退回設計的好處是 cookie 過期時你照樣抓得到公開影片；代價是真正需要登入的內容，第二次嘗試一樣會失敗，多跑一遍只是確認。
要注意 README 對這個功能的態度。功能表上 Cookie 那條掛著作者的警告：尚未驗證，可能存在 Bug。連作者自己都沒把握的功能，我不會建議你拿付費會員內容去賭。而且 cookies.txt 存的是你的登入憑證本身，放在哪個資料夾、會不會被其他程式讀走，這些責任都在你。
取得 cookie 檔案也沒有被選單化：yt-dlp 本身其實有 --cookies-from-browser 參數可以直接讀瀏覽器，一些圖形介面下載器（例如先前介紹過的 Parabolic）也把「從瀏覽器拿 cookie」做成了選項，這支腳本只認檔案一條路，你得自己用瀏覽器擴充功能把 cookie 匯出成 yt-dlp 認的 Netscape 文字格式再放進 config。手續不算難，但就是多一道手工，而這道手續的產物是一份完整登入憑證，保管責任上一段已經說過了。
合規的界線一句話就夠：這支腳本是機制中立的抓取器，支援的網站跟著 yt-dlp 上游走。抓自己上傳的影片、公開素材、取得授權的內容都沒問題；抓下來的東西怎麼使用，判斷在你，不在工具。
停滯的維護、缺席的版本與授權檔
先看時間軸。專案 2025 年 5 月建立，主要開發集中在那個月，Windows 版 5 月底重構過一輪，之後 README 在 7 月與 8 月初各更新一次，2025 年 8 月 1 日就是最後一次人為提交。2025 年 10 月那筆合併是自動翻譯機器人的成果，不算維護。到 2026 年 9 月的現在，人為維護停擺超過一年，倉庫本身也將近一年沒有任何推送，唯一開著的 issue（2025 年 11 月問抖音影片怎麼抓）沒有人回。
回頭看 issue 紀錄，會看到一個「做完就收」的縮影：2025 年 5 月 23 日有人回報錯誤，6 天後問題就被關閉，那正是開發最活躍的時段；但另一則 5 月 12 日開的長篇使用回饋，列了安裝流程、錯誤判斷、互動邏輯一串問題，拖了將近五個月，最後在 2025 年 10 月 8 日被關掉，那天恰巧也是翻譯機器人 PR 合併的日子，其間找不到對應的修復提交。這類個人腳本專案的本質就是解決作者自己的需求，README 也自述靈感來自 NodeSeek 論壇的分享，還附註科技 lion 一鍵腳本裡也整合了同類功能。把它理解成「某個論壇技巧被整理成可重複使用的腳本」，比把它理解成「一個產品」更接近事實，期待值也要照這個調整。
README 對自己的毛病倒是誠實，自認了三個已知狀況：CentOS 未經全面測試，建議別用在正式環境；Linux 版每次回到首頁都會重跑一次依賴檢查，作者自嘲抱著能跑就行的原則懶得改；Windows 版從子頁面回到首頁後，預設選項可能失效卡進迴圈，解法是重開腳本，或者不按 Enter、直接輸入數字選單。都是小毛病，但裝之前知道，遇到就不會慌。
還有兩件結構性的事。其一，這個專案沒有任何 release 或版本標籤，install.sh 抓的是 main 分支的即時檔案，你裝的永遠是開發分支最新版，沒有版本可以回鎖，一鍵腳本安裝這件事本身也該納入信任評估。其二，README 寫著專案遵循 MIT License，但倉庫裡六個檔案找不到授權條款檔案，GitHub 的授權偵測結果也是空的。個人使用風險很低，嚴格來說授權狀態未明確，想再散布前建議先找作者確認。
隱私這塊倒是乾淨。我把兩支腳本全文掃過一輪，對外連線只有下載依賴（GitHub releases 與系統套件庫）和影片下載目標本身，沒有任何遙測或上報程式碼。它不會回報你抓了什麼。
和直接打指令、裝 GUI 相比，它站哪個位置
會背 -f 和 -a 的人不需要它，yt-dlp 原生一條指令就能吃文字清單。想留在終端機、又不想每次查參數，這是它的甜區。要圖形介面的話，站上先前介紹過的 Parabolic（把整套引擎與自動更新包進安裝器的桌面下載器）與 Youwee（把 yt-dlp 包成視窗介面的工具）都是更完整的選擇，README 自己也建議 Android 使用者直接改用 Seal 這個 App。如果你要的只是從線上影片截一小段，BiliCut 那類線上工具比下載整支更快。
不過有個場景是 GUI 到不了的：沒有桌面環境的 Linux 主機。租一台 VPS 固定半夜跑批次、或在一台只開終端機的小伺服器上抓整季影片，圖形介面派不上用場，這時一支依賴只有 bash、curl、yt-dlp、ffmpeg（含 ffprobe）的選單腳本反而順手。可審計性是另一個實際優勢：全部邏輯攤在 481 行的文字檔裡，你剛剛看到的格式選擇器、cookie 退回、執行緒上限，都能自己一行行核對；換成打包過的桌面軟體，同樣的確認就得信任安裝器與更新伺服器。
它相對 GUI 的劣勢也說清楚：腳本凍結了，未來網站改版時，更新的會是底下的 yt-dlp（選單裡的檢查更新做的正是這件事），選單本身不會有新功能。反過來說，這也是它到現在還能用的現實理由：重活全部在上游引擎，薄殼不太需要動。
先用一支影片，試出它值不值得
成本最低的驗證流程：單片模式抓一支公開影片，到 ./video 看產物。確認三件事：檔案真的是 mp4、解析度跟你選的檔位對得起來（記得上限不保證）、畫面與聲音都在。都過關，再把清單貼進 config/urls.txt 跑批次；Windows 使用者先備齊三個執行檔再開始。需要 cookie 的情境，先拿免費帳號的內容試，別直接押付費會員。
失敗了先別怪腳本。這類工具壞掉時，第一個該更新的是底下的 yt-dlp：網站改版後先壞的通常是引擎裡的網站解析器，選單裡跑一次檢查更新（Linux 版），或自己重抓一份最新執行檔（Windows 版），多數「昨天還能抓、今天不行」的狀況就解決了。真的不行，帶著 -v 參數重跑一次 yt-dlp 原生指令，除錯輸出會比選單版本完整得多，拿著這份輸出去找 yt-dlp 的 issue 討論區也更容易對到答案。
試跑過程如果想直接下 yt-dlp 指令對照，其實不難，選單的最後確認畫面已經把模式、連結、解析度、執行緒、Cookie 狀態全部列給你看了。會走到這一步，通常代表你已經不需要這層選單。這也是它最誠實的定位：一根從指令列世界通往 yt-dlp 的扶手，走熟了自然會放開。
授權與專案狀態
專案在 GitHub 上約 140 顆星、16 個 fork，主要語言標記為 Batchfile，取得管道就只有原始碼倉庫一處，沒有官網也沒有發行版下載點。授權狀態前面提過：README 宣稱遵循 MIT，倉庫內卻沒有條款檔案可對照，引用或再散布前建議先向作者確認。最後一次人為提交停在 2025 年 8 月 1 日，其後只有機器人翻譯 PR；選用它，等於接受「引擎會更新、選單不會」的現實，這也是我把使用建議收在「先試一支影片」的原因：讓每次投入都小到不值得猶豫。
