逐字稿文字預覽
大家想像一個情境 現在是凌晨一點 然後你為了解一個系統 bug 已經坐在電腦前 除錯了十幾分鐘 哇 凌晨一點 這聽起來就是我們工程師的 日常噩夢 真的超級痛苦 然後你剛剛把一份 就是大概 2000 行左右的 JSON 錯誤報告 還有三個核心程式碼 檔案的片段 全部貼給你的 AI 助手 嗯 這資訊量真的很龐大 對 然後你好不容易 真的是好不容易 引導他找到了問題點 你就下指令說 太好了 就針對剛剛那個 off 檔案生成修復程式碼 結果你猜怎麼著 該不會是忘記了吧 沒錯 他回傳了一段 完全不相關的邏輯 甚至連檔名都拼錯 也就是說 他的上下文記憶 就在最關鍵的這一刻 徹底爆滿崩潰了 這種時候真的會讓人 想直接砸螢幕 其實這就是開發界常說的 所謂的上下文視窗危機 對 Context Window 危機 沒錯 當歷史資訊量太大 傳統的 AI 系統 為了解決這個問題 通常會在背後 偷偷做一件事 就是把前面的對話 進行摘要 但講到傳統的摘要法 那根本就像是 我們清理冰箱的時候 把所有剩菜 隔夜飯全部倒進果汁機裡 然後打成一鍋 完全看不出原貌的綜合果汁 這個比喻非常精準 體積確實是變小了 沒錯 對 可是如果我現在需要 找裡面的一根蔥 抱歉 完全找不到 在程式碼的環境裡 少掉的那根蔥 可能就是一個至關重要的 API 參數 確實 這會讓整個後續的除錯 完全失準 而且比綜合果汁更糟的是 這杯果汁還會讓 AI 產生幻覺 讓它去憑空捏造那些 被摘要吃掉的細節 哇 那真的是越忙越忙 所以我們在本次深入探討中 要來解析一個全新的開源專案 這是一個 Cloud Code 的擴充套件 兼 NPM 模組 叫做 Fast-Jev-Compaction 這個套件的策略非常極端 它主打的是逐字保留 以及得分刪除法 也就是說 它不打果汁了 它是把你確定已經過期的食材 整包連同包裝袋 直接丟進垃圾桶 而留下來的每一顆蘋果 都是百分之百原封不動 非常新鮮的 沒錯 這就是它的核心理念 所以今天的任務 我們就是要來拆解這套機制的底層邏輯 比如它能省下多少 Token 如果是很短的對話 會不會反而增加成本 還有對我們台灣的中小企業來說 這到底能不能真正落地 這些實務問題都非常關鍵 那我們先從它的保鮮機制談起好了 我注意到來源資料裡提到 它會把每一筆工具呼叫 就是 Tool Use 跟它的結果 Tool Result 成對地綁定在一起 對 這是它運作的最基礎基石 因為在 Cloud Code 這種 會瘋狂呼叫終端機 或者是讀取檔案的環境中 工具的操作跟回傳結果 是絕對不能脫鉤的 了解 那它怎麼決定誰該留下來 系統有一個叫做 Preserve Recent Messages 的設定 預設值是 6 意思是最新發生的前 6 筆對話訊息 會被加上精選的保護罩 精選 所以這 6 筆是絕對安全的 絕對不碰 它保證你當下正在處理的邏輯 不會被刪掉 但挑戰來了 如果要請 Jev 這個模型 來幫我們評估那些 沒被勾選的舊資料該不該刪 我們得把整個長篇大論的歷史記錄 傳送給它對吧 沒錯 這就是一個潛在的瓶頸 Jev 本身的上下文上限 是 32K 個 Token 如果在傳送評估的路上就先爆了 那這個壓縮工具 不就毫無意義了嗎 所以開發者為了解決這個問題 設定了一個 Max State Tokens 的上限 預設是 25,000 25,000 留了一點緩衝空間 對 而且為了在不拖慢系統速度的前提下 估算這 25,000 個 Token 它放棄了傳統那種 精確但很笨重的分詞器 不用 Tokenizer 那它怎麼算 它直接用字元來進行粗略的估算 等一下 用字元算 這在英文環境或許說得通 大約 6 個英文字母算一個詞 數字算半個 Token 標點符號算一個 這是一種為了效能妥協的做法 沒錯 這是一種啟發式演算法 可是這在我們台灣的實務應用上 根本是個隱形地雷吧 你想想看 如果使用者的 Prompt 或者那個巨大的 JSON 報表裡 塞滿了繁體中文呢 哇 這裡真的講到重點了 在大多數大型語言模型裡 一個繁體中文字可能就會消耗 2 到 3 個 Token 如果系統還傻傻地以為 6 個中文字才等於 1 個 Token 這絕對會嚴重低估真實的 Token 數量 這個實務觀察真的非常敏銳 這個開源專案目前的設計思維 確實帶有強烈的英語系 跟程式碼本位色彩 對 最後送給 Jev 的時候 肯定會直接撞破 32K 的上限 導致 API 報錯 這也是為什麼它把安全水位設在 25,000 留了足足 7K 的緩衝 但對於大量處理中文文本的團隊來說 技術主管在導入時 絕對需要注意這個資源估算的比例 了解 要特別小心 不過撇除中文字元的問題 當它發現資源數真的超過了 25,000 的限制 我看到資料說它的處理手法 叫做多階段處理 對 Stage Based Fitting 它的做法相當精妙 讓我推演一下 假設我有一個 5000 行的系統日誌 它總不可能直接放棄壓縮吧 它一定是從那些最肥大的參數開刀 完全正確 第一階段 它會把所有沒被勾選的 舊工具輸入參數 硬生生壓縮到 1000 個字元 所以它把中間挖空了嗎 沒錯 它只保留開頭跟結尾 把中間龐大的資料直接捨棄 所以它保留了工具曾經被執行過的形狀 但捨棄了內容 那如果挖空到 1000 字元 算一算還是超過 25,000 呢 那它就會變得更殘酷一點 進入第二階段 把限制縮減到 200 個字元 200 字元真的很少了 如果再不行 就砍到極限的 60 個字 到最後如果還是塞不進去 那些很久以前的舊訊息 會被徹底折疊成一句簡單的短語 像是一句註解那樣嗎 對 例如省略 N 個字元 就這樣一步一步削肉剔骨 直到整包資料的估算值 能安全塞進 25,000 的限制裡 再送給 Jev 去做最後的決策 哇 這種在極限狀態下的多階段處理邏輯 對我們工程師來說 真的是一個很棒的價值提升 怎麼說 就是在系統設計時 為了追求極致的效能跟穩定 其實你不一定需要追求百分之百 精確的 Token 計算 用簡單的資源估算 搭配多層次的安全防線 實務上不僅運作更快 容錯率也更高 工程思維的精髓 就是用最小的算力成本 換取最大的系統穩定度 但講到成本 這就衍生出另一個很現實的問題了 什麼問題 如果今天我這個除錯任務其實很簡單 我只跟 AI 來回對話了三四次 上下文根本還很空 為了清理那一點點的歷史記錄 我還要特地把資料打包 傳送一個 API 請求給 Jev 去做評分 這反而多花了一筆 API 費用 甚至增加了網路延遲對吧 沒錯 這樣感覺很不划算 其實這個外掛並沒有那麼死板 在系統內部 它設定了一個參數叫做 Reduction Ratio 也就是壓縮比例 哦 所以它會先算帳 對 當 Jev 評估完畢 準備動刀刪除之前 系統會先預估一下 如果預計能砍掉的內容比例小於 0.25 也就是說 Jev 認為能刪掉的廢話不到四分之一 系統就會判斷說 這套壓縮根本不划算 馬上停損 就是這樣 它會直接退回原本的完整對話 或者 Fallback 回去使用 Cloud Code 內建的裁減機制 它不會為了展現自己會壓縮 而硬去執行無效的操作 懂得及時停損是很聰明的設計 但如果我們把目光放遠一點 考慮到企業長期的技術選型 我們最怕的其實是被單一廠商綁架 Vendor Lock-in 這確實是企業導入新技術時最大的顧慮 對啊 今天這個套件是為 Jev 模型設計的 如果我不想把資料打給 TypeSafe 的 API 或者我們公司已經買了大量的 OpenAI 或 Anthropic 的額度 這套機制還有用武之地嗎 來源文件雖然沒有明說 它原生內建了所有主流模型 但它刻意留下了一道非常寬廣的後門 開發者可以自行實作一個 名為 Jev Asker 的介面 Jev Asker 意思是只要我符合這個介面的標準 我背後要接誰都可以 沒錯 只要你能寫出一個 Ask 的方法 你就可以自行撰寫底層的傳輸邏輯 而且這個專案是作為 NPM 模組發布的 所以它可以直接裝在專案裡 對 它還大方地匯出了像是 Compact Messages Collect Tool Calls 這些核心函式 這些就像是樂高積木一樣 這對於技術主管來說 真的是一盒定心丸 這種模組化暴露出核心介面的設計 意味著我們甚至可以把這套刪除法的演算法 抽離出來 改寫整合到公司內部的私有 AI 系統中 這樣技術綁架的風險就趨近於零了 既然機制這麼彈性 那我們就得來檢驗它的心臟了 它到底是怎麼給出那個所謂的刪除得分的 它的評分機制是這樣 Jev 會針對每一個沒被勾選的工具呼叫 問兩個非常刁鑽的問題 哪兩個問題 第一 這個呼叫的記錄本身該留下來嗎 知道它曾經被執行過 對接下來的任務還重要嗎 嗯 這是評估動作本身 那第二個呢 第二 這個執行的結果該原封不動保留嗎 還是其實可以刪掉 大不了讓 AI 發現缺資料時重新跑一次 哦 所以它把動作跟結果分開來評估 那幾個分數是多少 系統依賴一個預設為 0.5 的 keep threshold 也就是保留門檻 大於 0.5 就保留嗎 對 如果 Jev 給出保留結果的機率大於 0.5 那就整組完好無缺地留下 那如果結果不重要 但動作很重要呢 如果保留結果的機率不高 但保留動作記錄的機率大於 0.5 它就會把那份龐大的結果 截斷到前 300 個字元 並加上一行註解 告訴 AI 這裡曾經發生過什麼 了解 那如果兩個機率都低於 0.5 呢 那就是整組直接超度 完全刪除 超度 這形容很貼切 邏輯聽起來很縝密啦 但我們都知道 機率不代表絕對 萬一 Jev 今天就是判斷失誤 把一個超級關鍵的記錄給刪了 導致模型徹底忘記了 剛剛讀過的檔名 這時候補救機制是什麼 開發者在畫面上其實不會瞎子摸象 你會看到一個 Toast 提示 明確告訴你保留了幾筆訊息 但如果真的誤刪了關鍵資訊怎麼辦 文件也坦承這項技術有它的局限 如果真的刪錯了 其實補救方式非常直覺 因為你是在具有代理能力的環境裡 AI 如果發現自己缺少某個參數 它可以隨時再次執行該工具 大不了就是讓 AI 再花個幾秒鐘 重新讀一次檔案 這成本還算可以接受 除此之外 為了確保系統不會因為 API 連線失敗 而整組崩潰 作者在寫單元測試的時候 特別實作了一個不聯網的 Fake Jev 不聯網的假 Jev 這有什麼好處 這確保了在真實情境中 萬一 Jev 回傳了破損的 JSON 或是網路直接斷線 系統能百分之百順暢地執行優雅降級 優雅降級 也就是無縫切換回 Cloud Code 原本內建的裁減機制對吧 完全正確 有降級機制確實讓人安心 但說到聯網打 API 我們就必須面對企業導入時最大的心魔了 那就是資安 沒錯 這真的是重中之重 任何會把資料往外送的外掛 在公司內部都會面臨嚴格的審查 對 這部分資料裡有提到什麼防護機制嗎 這是今天最核心 最需要劃重點的資安警告 這個套件在運作時 你需要填寫 API Key 而且它會將你那份完整的對話記錄 包含所有的工具輸入參數 毫無保留地傳送到 TypeSafe 的伺服器 等一下 毫無保留 也就是說 如果我的程式碼裡夾帶了 AWS 的機密金鑰 或者我們公司核心產品還沒公開的商業邏輯 這些都會變成純文字 直接送到別人的伺服器上 毫不設防 完全會 來源文件完全沒有提到 任何內建的自動過濾或清理敏感資訊的機制 哇 這太危險了吧 作者反而在 README 裡非常用力地警告大家 絕對不要把金鑰提交到原始碼中 這等於是在暗示 資料的對外傳輸是完全透明且具有風險的 這件事對台灣的中小企業 資安公司或是企業內部團隊來說 太關鍵了 非常關鍵 我們常常看到工程師為了解決眼前的 Context 爆滿痛點 上網隨手就裝了一個開源工具 這裡的實務提醒是 如果你的專案牽涉到任何商業機密 絕對不能在沒有自建防線的情況下直接套用 沒錯 這也呼應了前面提到的 Jev Asker 介面 如果企業真的要導入 技術團隊必須自己寫一個中介層 在把資料送出去給 Jev 評分之前 先在本地端把敏感資訊過濾掉 企業的底線是不能妥協的 但其實即使資安這關過了 技術團隊還要面對另一個深淵 那就是部署的摩擦力 部署的坑真的很多 技術再好 如果無法順暢地部署到 每一位工程師的電腦上 或者沒辦法放進 CI/CD 的流程裡 那也是白搭 我看到文件特別提到 這個機制依賴 Cloud Code 的 Function Hooks 功能 對 麻煩就在於 這個功能目前還處於早期測試階段 所以它不是 NPM 安裝完 就能無腦啟動的 遠比那複雜 你必須在環境變數 或者是本機的設定檔裡 強制宣告一個全域變數來開啟這個功能 哦 要手動去開 Feature Flag 對 這代表團隊裡的每一個使用環境 包括每位新進員工的筆電 或是雲端的 CI/CD 伺服器 都必須先經歷這個手動開啟的步驟 否則外掛根本不會動 哇 這對 DevOps 團隊來說 絕對是個大坑啊 推廣新工具時 只要多一個手動設定步驟 採用率就會掉一半 確實會增加初期的推廣成本 不過談到推廣跟說服 我注意到作者做了一件讓我非常驚艷的事情 他為了展示這套抽象的得分刪除法技術 特地寫了一個 macOS 原生的 Swift UI App 只為了錄製一段展示影片 這在開源推廣上真的非常聰明 對啊 為什麼他不直接錄個 無聊的終端機畫面就好 還要特地寫個 App 這個 App 其實從頭到尾 都沒有呼叫任何真實的 API 它裡面顯示的對話跟決策 全都是用腳本預先寫實的 它純粹就是為了視覺化演出而生的 視覺化演出 它具體演出的是什麼效果 當你在畫面上看到一長串 密密麻麻的歷史記錄 系統判定哪些舊的呼叫是不需要的廢話時 那些文字會直接在畫面上變成紅色 然後動態地折疊消失 哇 變成紅色然後消失 這種視覺衝擊力太強了吧 對一個沒時間看長篇技術文件的技術主管 或非技術老闆來說 這幾秒鐘的動態裁剪 能讓他們瞬間看懂這個技術的核心價值 這裡有一個超棒的實務應用價值 如果我們是工程師 準備向老闆提案導入 這種可以幫公司省 API 費用的新架構 嗯 你要怎麼說服他 與其貼出一堆冷冰冰的 Lockdown 或是 Token 節省數據 不如學學這種視覺化展示核心邏輯的手法 老闆一看紅字消失 馬上就知道 哦 垃圾被清掉了 有用的東西還在 而且我們省錢了 沒錯 能把深奧的底層邏輯 轉化為直覺的視覺 有時候比寫出這段程式碼還要困難 這絕對是提升競爭力的好方法 聊到這裡我們最後來宏觀地檢視一下產業趨勢 面對上下文爆滿 目前業界有
本次執行流程與問題處理
下達指令
預期流程
- 採用來源字幕（略過語音辨識）
- 來源選擇與品質檢查
- 文字校正與句子單元
- 筆記與發布
- 公開網頁發布
1. 下載與語音辨識
工具：videonote-transcribe-url（主辨識管線：下載、Whisper 辨識與選稿）
處理：下載音訊、以 Whisper 辨識並選出最佳逐字稿
產出：yt_dlp_meta.json（影片元資料）、audio_16k_mono.wav（16kHz 單聲道音訊）、transcript.whisper.json（Whisper 辨識結果）、transcript.json（正式逐字稿）、transcript_selection_report.json（來源選擇報告）
耗時：13.8 秒
關係：依序執行
結果：完成
2. 全文快速校讀
工具：videonote_rapid_transcript_review.py
處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目
產出：rapid_transcript_review_report.json（產出檔案）
耗時：51.2 秒
關係：依序執行
結果：完成
3. 建立句子單元
工具：videonote-build-sentence-units
處理：將逐字稿切成帶時間軸的句子單元
產出：sentence_units.json（句子單元）
耗時：0.3 秒
關係：依序執行
結果：完成
4. 時間軸稽核
工具：videonote_timeline_audit.py
處理：檢查時間軸與音訊對齊
產出：timeline_audit_report.json（時間軸稽核）
耗時：0.3 秒
關係：依序執行
結果：完成
5. 品質檢查
工具：videonote_controlled_quality.py（檢查時間軸與品質）
處理：檢查語言、時間軸與可讀性品質
產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）
耗時：0.4 秒
關係：依序執行
結果：完成
6. 播放時間軸回填
工具：videonote_rebase_display_timeline.py
處理：將網頁播放時間軸回填為校正字幕時間
產出：display_timeline_rebase_report.json（時間軸回填報告）
耗時：0.4 秒
關係：依序執行
結果：完成
7. 來源句整理
工具：videonote_prepare_source_entries.py
處理：整理來源句子供時間軸與頁面使用
產出：sentence_units.json（句子單元）
耗時：0.4 秒
關係：依序執行
結果：完成
8. 生成筆記摘要
工具：videonote-generate-note（生成筆記摘要）
處理：生成筆記摘要與重點
產出：note.md（筆記 Markdown）、note.html（筆記 HTML）
耗時：151.8 秒
關係：依序執行
結果：完成
9. 建立筆記頁面
工具：videonote-render-html（產生筆記 HTML）
處理：產生可閱讀的筆記 HTML 頁面
產出：note.html（筆記 HTML）
耗時：0.9 秒
關係：依序執行
結果：完成
10. 發布公開頁面
工具：videonote-publish（發布公開頁面）
處理：發布到公開網站與每日列表
產出：公開筆記網址、result.json（管線結果）
耗時：1.0 秒
關係：依序執行
結果：完成
手動來源字幕
自動來源字幕
Whisper 字幕
- 尚未產生
Qwen 字幕
- 尚未產生
Parakeet 字幕
- 尚未產生
MOSS 字幕
- 尚未產生
聲學時間證據（PyAnnote / WhisperX）
- 尚未產生
校正前後逐字稿
- 校正前 transcript.source.json 純文字 JSON
- 校正後 transcript.json 純文字 JSON
目前待解決問題與初步改善方向
- 逐字稿全文快速校讀未完成
已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。；RAPID_REVIEW_STATUS=REVIEW_REQUIRED_INVALID_OUTPUT
- Qwen3-ASR 未完成，需確認 qwen_asr_lab 環境與音訊後重試精進模式。
- 音訊下載不穩定，需更新 cookies / PO token 後重試精進模式。