Bilibili 按標籤屏蔽影片腳本，17 種條件把不想看的推薦蓋掉

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

如果你想在 Bilibili（B 站）網頁端把特定標籤、特定創作者的影片從首頁推薦裡消失，Bilibili Blocked Videos By Tags 是同類腳本裡過濾維度最細的一批：它用 17 種條件判斷每一張影片卡片，命中就蓋掉或隱藏，而且到 2026 年 9 月中仍有人回報它運作正常。但在 2026 年 9 月 11 日，GitHub 上出現了一份重量級回報：從 GitHub 下載的版本會間歇性把整個 B 站頁面清空，問題指向它引用的一個外部 CDN。結論先講：這支腳本可以用，但安裝來源要選 GreasyFork，別用 GitHub 倉庫裡的那份原始檔，原因後面會完整攤開。

先定位這是什麼。Bilibili Blocked Videos By Tags 是一支使用者腳本（userscript），要搭配 Tampermonkey（篡改猴）這類腳本管理器運作，作者代號 tjxwork，2023 年 12 月上架，GitHub 上 129 顆星、GreasyFork 累計接近一萬次安裝。它只作用在 bilibili.com 的 8 個子網域，做的事情很單純：在首頁、各分區頁、搜尋頁、熱門與排行榜等頁面，以及播放頁右側推薦欄，依你設的條件把不想看的影片卡片加上遮罩，或直接隱藏。

先看 2026 年 9 月 11 日那份回報：整頁清空，源頭指向 CDN

這段是現在決定要不要用它之前最該知道的事。

9 月 11 日，使用者在 GitHub 開了 issue #34，描述一個間歇性出現的症狀：啟用腳本後，B 站頁面偶爾整頁變白、瀏覽器分頁一直轉圈，檢查後發現頁面裡多了一個指向外部位址的隱藏 iframe，兩次觀察到的位址分別是 66.179.31.11 與 soduncdn.com。回報者把 document.write 掛上鉤子追呼叫堆疊，定位到腳本 @require 引入的其中一份 Vue 函式庫：從 bootcdn.net 載入的那份。注入的手法是在頁面解析告一段落（readyState 為 interactive）時呼叫 document.writeln，這個時機點的寫入會把整份文件清空再重開，於是頁面內容全部消失、文件永遠處於載入中。

Pin

證據最有力的一點是檔案長度。乾淨的 Vue 3.2.31 production 版是 125,071 bytes，而呼叫堆疊顯示的出錯位置在第 125,208 欄，已經超出檔案結尾，代表瀏覽器實際執行的那份檔案，結尾後面多出了一段程式碼。回報者也誠實標明了限制：事後再下載同一個網址，拿到的都是乾淨版本，惡意內容看起來是按條件投放的，所以沒有人取得注入內容的原文。事件等級是「疑似供應鏈注入」，但證據鏈具體，不是空穴來風。

我把兩個安裝來源的檔案都抓下來逐行比對，結果很關鍵：GitHub 倉庫裡的原始檔有三條 @require，分別從 cdnjs、jsdelivr、bootcdn 三個 CDN 載入 Vue 3.2.31；而 GreasyFork 實際分發的安裝檔裡，bootcdn 那一行已經不存在，整份檔案與 GitHub 版會影響執行的差異就只有這一行，GreasyFork 版多出的兩行下載更新位址只是發布機制自動附加的中繼資料。也就是說，從 GreasyFork 安裝的人，根本不會載入出事的那條相依。

再補一個親測的細節：三份 @require 引入的 Vue 裡，只有 bootcdn 那份是正式的 production build（125,071 bytes），cdnjs 與 jsdelivr 的兩份分別是 161,604 與 163,980 bytes，內容都含「development build」警告字串，是壓縮過的開發版。就算完全不談資安，一支腳本重複載入三份 Vue 本身就是多餘的。而我在 2026 年 9 月 14 日抓 bootcdn 上的檔案下來算雜湊，它與 cdnjs 的正式版完全相同，當下是乾淨的；回報者驗證過，把 bootcdn 那行刪掉後另外兩個 CDN 照樣供應 Vue，功能不受影響。

這不是它的 Vue 相依第一次出事。v1.4.5（2025 年 7 月）修的就是「位元組跳動的 Vue CDN 失效導致設定介面壞掉」。十四個月內，同一種依賴外部 CDN 的做法出過兩次狀況，一次是 CDN 掛掉，一次是疑似植入惡意碼。截至 9 月中，作者對 issue #34 尚未回應，也還沒有修正版。

它擋影片的方式：先蓋掉，願意的話再隱藏

回到工具本身。它在瀏覽器選單裡只掛一個入口「屏蔽參數面板」，點開是一個用 Vue 3 畫出來的設定視窗，每一種過濾條件一個區塊，詞彙清單、數值門檻與正規表示式的開關都在同一頁管理。它的預設動作是在命中的影片卡片上加一層半透明遮罩，遮罩上會顯示命中原因，例如「屏蔽標題：軟體」「屏蔽雙重標籤：數碼、科技」。看得到擋掉了什麼、為什麼擋，是這種做法與直接刪除卡片最大的差別：誤殺時你認得出來，可以回頭調規則。如果連命中的字詞都不想看到，v1.1.4 起可以改成只顯示類型；v1.5.0 再加了即時開關，讓你臨時把疊加層關掉看一眼原始推薦；也可以整個切成隱藏模式，讓卡片直接消失、後面的影片補位。

Pin

17 種過濾條件可以分成兩類，這個分法比條件數量更值得記住。

第一類靠卡片上本來就有的資訊就能判斷：標題、UP 主名稱或 UID、標籤、時長、直式影片、充電專屬（B 站創作者的付費牆內容）。這類判斷純粹發生在你的瀏覽器裡，不打任何額外請求。其中「雙重標籤」是這支腳本比較特別的設計：要同一張卡片同時命中兩個標籤才算數，例如「採集卡」單獨出現可能有很多正常影片，「採集卡＋圓剛」同時命中才是你要擋的招商內容。這個設計讓遮蔽詞可以設得寬而不易誤殺，作者甚至為了推廣這個用法，在 B 站專門錄了一支教學影片。順帶一提，UP 主名稱、標題、標籤、分區這幾類詞彙條件都支援正規表示式，想擋的對象是固定幾個帳號時填 UID 比填名稱準，改名也照樣命中。

第二類需要呼叫 B 站自己的 API 才補得到欄位：播放數、按讚率、投幣率、收藏與投幣的比值、UP 主等級、粉絲數、簡介內容，以及精選評論與置頂評論的內容。整支腳本對外只有 4 個請求端點，全部是 api.bilibili.com 自己的 API。其中「收藏/投幣比」是比較少見的設計：作者的邏輯是收藏遠大於投幣的影片大概有刷資料的嫌疑，預設比值設 10，而且為了保護新影片，只處理播放 5,000 以上、收藏 50 以上、發布滿 2 小時的影片。這些數字與理由都是作者在更新說明裡自述的，取捨是否貼合你的習慣可以自己判斷。另外兩個評論類條件的動機也值得知道：作者觀察到詐騙影片有很大比例會開啟精選評論來控制版面，所以把「開啟精選評論」本身做成了一個可擋的訊號，不過他也自己補了一句，測試時發現詐騙影片並不是每支都開，訊號不保證全中。

除了影片卡片，它也能隱藏首頁與各分區頁的直播推薦、廣告與推廣卡片，以及搜尋框的熱搜內容；熱搜項還能按關鍵字或既有標籤過濾。設定全部存在腳本管理器的本機儲存空間，可以匯出成 JSON 檔備份，換裝置時再匯入。

權限與資料流向：本身乾淨，但 API 是用你的身分打的

看原始碼的權限面，這支腳本相當收斂。@grant 只申請了 4 個腳本管理器的本機 API（存設定、註冊選單、加樣式），沒有 GM_xmlhttpRequest 這種對外請求權限；3,032 行程式碼裡 grep 不到任何分析或遙測 SDK 的蹤影；生效範圍就是 8 個 B 站子網域，不碰其他網站。

但第二類過濾條件有個使用上要知道的代價：那些 API 請求是帶著你的 B 站登入狀態發出的，等於以你的帳號身分在瀏覽時額外發請求。作者自己在更新說明裡寫得很白：取得評論的 API 對請求頻率非常敏感，頻繁刷新或狂開新分頁時，B 站會直接拒絕回應，導致精選評論、置頂評論這類功能暫時失效，正常瀏覽通常沒事，但無法保證百分之百可用；v1.3.1 還為了降低觸發風控的風險，改成有啟用對應選項才會發請求，README 也標明同一個影片號在 3 秒內最多查詢一次。換句話說，開愈多 API 類功能，行為就愈不像普通瀏覽，這個取捨要自己拿捏。只想用標題、標籤、UP 主這類純瀏覽器判斷的人，完全不必碰這層風險。

維護狀態：還活著，但一個人能做的就這麼多

這支腳本的最後一次提交停在 2025 年 11 月 30 日的 v1.5.0，到 2026 年 9 月中，已經九個多月沒有任何 commit。作者在 v1.5.0 的說明裡自述：還活著，但工作很忙；腳本接近 3,000 行，維護起來有點頭大；原本想拆分重構，拆到一半擱置了；除了修明顯的錯誤，暫時不打算加會動到結構的新功能。GitHub 上有兩個社群提交的功能 pull request（快速取標籤按鈕、按關注數過濾）也因此一直掛著沒合併。

停更不等於壞掉。GreasyFork 的回饋區到 2026 年 9 月 12 日還有人留下好評；更早的 2026 年 3 月也有人分享，靠粉絲數過濾就能清掉一大片機器人帳號的影片；2026 年 5 月也有人回報過 Edge 上選單叫不出來（README 針對 Edge 給了解法：擴充功能頁要打開開發人員模式 Tampermonkey 才能正常執行，Chrome 同樣適用）。真正的風險是 B 站改版：這支腳本靠抓頁面元素判斷卡片，歷史上已經多次跟著 B 站首頁改版調整相容性（v1.4.4 就是適應首頁元素變化的版本），在停更狀態下，下一次大改版就是它失效的時間點。

它的功能是怎麼長出來的也值得看，對判斷品質有幫助。翻更新紀錄會發現，不少功能後面掛著「感謝某某的贊助需求」：按 UP 主等級、粉絲數、簡介屏蔽是一筆贊助換來的，隱藏選單裡的屏蔽詞、熱搜過濾也是。作者在說明裡放了自己的愛發電（中國的創作者贊助平台）連結，明白寫著贊助是維護更新的動力。這種單人加小額贊助的模式，功能取捨完全跟著少數付費用戶的需求走，好處是每一代功能都有真人在用，壞處是沒有第二雙手能接手，前面提到的重構擱置與 pull request 積壓，都是同一件事的另一面。

授權方面有個小坑：GreasyFork 頁面標的是 CC-BY-NC-SA（姓名標示、非商業性、相同方式分享），GitHub 倉庫本身卻沒有 LICENSE 檔，整個倉庫只有 README 和腳本本體兩個檔案。對單純安裝使用沒有影響，但如果你想改作、整合進自己的專案或商業使用，這種「頁面有標、倉庫沒附」的狀態要先跟作者確認，別當成隨意可用的開源程式碼。

Pin

要用的話：來源選 GreasyFork，裝完做兩個檢查

整理成可以直接照做的判斷。

安裝來源選 GreasyFork（greasyfork.org/scripts/481629）。那裡分發的版本已經沒有 bootcdn 那行 @require，是三份 Vue 裡唯一出過疑似資安事件的那條相依。需要先裝 Tampermonkey 這類腳本管理器；Chrome 與 Edge 用戶記得在擴充功能頁打開開發人員模式，這是 2025 年之後 MV3 架構下的普遍要求，叫不出設定面板時先檢查這裡。相容性也要留意：README 明列它與 B 站常見的首頁重構腳本 BewlyBewly 不相容，裝了的人得二選一；與 bilibili-app-recommend、bv2av 兩支腳本則測試過可以並存。

如果你的腳本是過去從 GitHub 下載的，打開腳本管理器的編輯器，找到檔頭 @require 區塊，把 cdn.bootcdn.net 那一行整行刪掉再存檔。回報者實測過，另外兩個 CDN 會照常供應 Vue，功能不受影響。

裝完之後給自己留一個警訊記號：如果哪天 B 站頁面出現整頁空白、一直卡在載入，先停用這支腳本再排查。這正是 issue #34 描述的症狀，先排除腳本因素可以少走彎路。

適合誰：已經有明確擋詞清單、想把特定標籤或內容農場影片從推薦流壓掉、而且不介意腳本可能隨 B 站改版失效的人。不適合誰：想要裝了就永遠不用管的人，單人維運加上停更現況，沒有人能給你這個保證。

如果你的需求其實是清潔版面而不是過濾內容，站上先前介紹過的 Bilibili Cleaner 以版面淨化為主軸、開關數量更多且當時仍活躍更新，定位與這支互相補位；想跳過影片裡的廣告片段可以看 Bilibili AI Skip，批次封鎖創作者的需求有 Bilibili 批次封鎖擴充功能；還在挑腳本管理器的話，ScriptCat 是可考慮的開源選項。這支腳本值得用的理由是過濾維度夠細、遮罩設計讓誤殺看得見；用的前提就一條，選對安裝來源，並接受下一次 B 站大改版隨時可能弄壞它。