Kaze 產品日誌 (五)：從用戶痛點到實作權衡 —— Album Mode 與廣告偵測的產品思考

在完成底層架構的重構後，我們開始回過頭來處理那些長期躺在需求清單上的問題。對 Kaze 來說，功能開發從來不是為了追求技術上的華麗，而是為了回應真實的使用場景與實作中的各種權衡。

需求的起點：為什麼連集下載這麼難？

我們經常收到用戶的反饋（甚至我們自己內部在使用時也有同感）：當用戶在追一部 20 集的影集時，目前的下載流程太過瑣碎。點擊第一集、等待攔截、確認下載、選目錄，然後重複 20 次。

用戶最常問的一句話是：「能不能給我一個網址，你們就自動把裡面所有的影片抓下來？」

面對這個需求，我們在產品層面上做了深刻的思考。如果要做「全自動抓取所有網址」，本質上會涉及 RPA（流程自動化）或是複雜的爬蟲技術。這在許多國家與平台規範中，存在著法律與道德的灰色地帶。

作為一個 Side Project，我們選擇了「退一步，但進一步」的策略。我們決定讓用戶保留「主動點擊」的動作，但由我們來處理點擊之後的所有自動化。這就是 Album Mode（相簿模式）的由來。

我們的思考邏輯是：既然用戶已經在點擊切換集數了，我們能不能「偵測到內容狀態的改變」，並預測用戶接下來的動作？

通訊架構的支撐：過去舊版架構混亂，Extension 與 App 之間的通訊延遲且不可靠，要實現流暢的連集下載極其困難。在重構後的 WebSocket 體系下，我們終於能讓兩端「同步思考」。
生命週期的保護機制：
- 第一次詢問：為了避免在背景亂塞檔案，用戶啟動 Album Mode 後觸發第一個下載任務時，我們會主動彈窗詢問：「是否要為此系列建立專屬目錄？」一旦路徑確定，後續就是全自動處理。
- 自動終止保護：我們發現 Album Mode 容易被忘記關閉。因此實作了一個邏輯：只要檢測到瀏覽器的 Host（主網域）發生更換，系統就會判定場景結束並自動關閉 Album Mode。

這種做法將原本的操作流程簡化，同時也避開了 RPA 的爭議。

另一個痛點來自於現代串流媒體常用的 SSAI（伺服器端廣告插入）技術。廣告被直接寫入媒體清單中，對下載器來說，這就是影片的一部分。

我們研究了語法中本來就支援的斷開點（Discontinuity）標籤。透過規則引擎的動態偵測，我們能識別出哪些片段具備明顯的廣告特徵。

但實作上的難點在於：我們無法 100% 保證偵測正確。如果自動刪除，可能會導致用戶下載回來的影片出現嚴重的跳轉感。最終我們選擇了「自動偵測標記，用戶手動決定」的實作方式：

在實作過程中，我們還解決了一個非常隱蔽的技術債。在 Mac 上，HLS 支援多音軌切換，但某些編碼在切換時如果沒有正確重置媒體頭部，會導致合併後的聲音頻率消失，聽起來像所有人都在壓著嗓子說話。

我們在 Rust 引擎中加入了一套 Probing 機制，一旦偵測到編碼參數跳變，就會強制重置。配合我們開發的邊看邊抓（Preview）功能，用戶可以在下載初期就發現並修復這些異常。

Kaze 的演進史，其實就是一段不斷在用戶需求、技術與實作權衡中尋找平衡點的過程。

我們堅持不鎖功能、採用贊助制，也是基於同樣的產品哲學：如果一個工具能真正解決你生活中的小麻煩，且這種解決方式是優雅、克制且具備溫度的，那麼它自然會獲得用戶的支持。

探索 Kaze 2： 如果你對我們正在開發的下載技術感興趣，歡迎前往 Kaze 產品頁面了解更多細節並支持我們的 Side Project。