模組四｜剪輯管線（Day 17–22）

我做的是一檔中文新聞 podcast，有些集會請來賓進來對談。錄音走線上多軌，主持人與來賓各自留下一條音軌，之後交給一條自動化管線組裝成一集節目。這篇講的是這條管線裡的剪輯。

剪輯之前的每一道工序都有客觀標準。ASR（Automatic Speech Recognition，自動語音辨識，把錄音轉成逐字稿）的錯字可以逐句對；響度有 LUFS（Loudness Units relative to Full Scale，串流平台通用的響度計量單位）這個產業錨；兩台裝置的時鐘走速不完全一樣，錄到後面，兩軌的偏移量會跟開頭對不上，這種時鐘漂移對不對齊，音量包絡看得出來。

剪輯沒有。

剪輯的「好」沒有任何可量測的定義，而我的 repo 裡留著五組版本歷程，每一組都是在沒有標準的情況下試圖收斂。

第一組：換參數換到第三版，才發現要換順序

某集的降噪走了四個版本：

• v1：降噪太弱
• v2：加大力度，但 loudnorm（FFmpeg 的響度正規化濾鏡，會把整段音量統一拉到目標值）在後面把噪音又放大回去
• v3：再調參數，記錄寫「根本問題未解，denoiser 在弱信號上效果差」
• v4：改變順序，先把整段拉高 15dB 提升訊噪比，再降噪

v4 成了定案。而它跟前三版的差別不是參數，是處理順序。

這一組值得記住的地方在於：前三版都在同一個維度上移動（降噪強度），而問題根本不在那個維度。

第二組：定案的時候明文寫下回退路徑

另一集的重剪走到 v5、v6，每一版的失敗理由都是同一句：「試聽後覺得還是不對」。

沒有更精確的描述，因為沒有更精確的描述可用。

最後定案的那句話寫得很誠實：

v5 為目前降噪最徹底的版本，若人聲清晰度受損過重，可退回 v4。

我當時大概是知道自己判斷不了的。所以做法是把回退路徑寫進定案文件，不是硬拗出一個理由：這個版本上，但你保留反悔的權利。

這是我在整個 repo 裡看到最成熟的一次決策記錄。不是因為它有把握，是因為它承認自己沒把握，還是做了決定。

第三組：問題不在參數，在目標

這一組是五組裡最重要的。

一集訪談，原始長度很長。我的目標是剪到 50 分鐘。

• v1：句級細剪（以每一句話為單位決定去留，而不是整段整段砍），切出 123 段保留區間，成品剛好 50 分鐘。試聽之後我的回饋只有一句：「來賓話沒講完就被砍」
• v2：以為是對齊問題，做了雙錨點修正（在一段的頭尾各取一小段各自對齊一次，比對兩頭算出來的偏移量是不是一樣），量出 26 段有段內位移。Day 21 談的就是這件事：兩軌的偏移量不是一個固定值，它自己會變，所以整段平移救不回來。修完之後沒有上線
• v3：換掉目標本身

v3 的定案寫的是：接受 90–110 分鐘，優先流暢，大段保留。 成品最後是約 108 分鐘，比原本的目標長了一倍以上。

v2 那個版本很值得看。它技術上是對的：漂移確實存在，修正確實有效。但它修的是錯誤目標下的一個技術瑕疵：把 123 個剪點對得更準，並不會讓「來賓話沒講完」這件事消失，因為那不是對齊造成的，是剪點太多造成的。

所以 v2 沒上線。它是一個做對了但沒用的版本。

當你連續三個版本都在調參數，問題通常在目標。

第四、第五組：邊界與拉鋸

第四組更短，但錯得更痛：中剪版（不逐句取捨，以整段為單位決定去留的版本）v1 誤剪了一整段，裡面含三處核心 payoff（前面鋪陳很久、到這裡才把結論講出來的段落）。

修正方式不是把那段接回來，是改規則：v2 放寬到近乎完整，而且邊界延伸到 payoff 之後才切。

這條規則現在還在用：切點不能落在論證還沒收束的地方。 一段話講到一半剪掉，聽起來不是簡潔，是斷線。

第五組是一次長度拉鋸，四輪：

約 134 分（原始）
→ 約 91 分   （砍太狠）
→ 約 116 分  （救回三段）
→ 約 109 分  （再退回兩段）
→ 約 106 分  （定案）

四輪之後回到中間值。這不是在優化，是在跟內容談判。每一次「救回」都是承認某段不能砍。

那要怎麼驗收

我的 repo 裡最嚴的一份驗收準則，剛好完全不是技術性的：

爆雷檢查走兩遍。 剪完後對照雷區清單從頭到尾再聽一次。上架前讓非劇組朋友試聽一次。

若整段下來來賓發言明顯少於 30%，回到母帶補回該段。

三條，沒有一條是程式能跑的。

第三條最有意思：它把一個主觀判斷（來賓有沒有被剪掉太多）綁到一個可數的比例上。30% 這個數字是拍的，但它把「我覺得來賓話太少」變成了一個可以爭論的事實。

而第二條「讓非劇組朋友試聽」，是這整條產線裡唯一一道 AI 完全無法替代的檢查，因為它要的不是判斷力，是一雙沒有聽過這段素材的耳朵。我自己聽第五遍的時候，已經在腦子裡自動補完了那些被剪掉的話。

還有一種決定：不修，重建

最後一個案例不是版本迭代，是放棄迭代。

某集的成品被發現比原始雙軌（主持人與來賓各自那條沒動過的錄音）短了一截，開頭口播被切掉、結尾沒講完就接上片尾。記錄裡的處置只有一句：

不沿用舊檔修補，直接從雙軌原始檔重建。

這個判斷的關鍵在於成本估算的方向：修補一個已經壞掉的成品，你得先搞清楚它哪裡壞了、壞了多少、還有沒有別的地方壞了；而重建的成本是固定的：腳本還在，跑一次就好。

當你的管線是可重跑的，重建就永遠比修補便宜。 這是 Day 19 那套「每段獨立寫出中間檔」的架構真正的回報，它讓「重來一次」變成一個廉價選項。

這一段裡，AI 做了什麼

老實說：AI 在這一整章裡幾乎沒有判斷權。

它做的是：把我口頭指示的剪點寫成可重跑的 Python、算對齊、跑 FFmpeg、輸出量測值。每一次「這版不對」都是人講的，每一次「那改成這樣」也是人講的。

AI 唯一一次自己做判斷，是 Day 18 那個把 ASR 幻聽當成「無內容」而誤砍六分多鐘的事故。那是它唯一一次被授權判斷內容存不存在，而它錯了。

代價

接受約 108 分鐘的版本，代價是節目變得沒那麼緊湊。50 分鐘那版在資訊密度上是贏的：每一句都有用，沒有廢話。

我選了流暢，不是因為它比較好，是因為「來賓話沒講完」這件事會傷害的是別人，而「有點鬆」傷害的只有我自己。這是一個價值排序，不是一個最佳解。

第二個代價是這一章沒有可複製的方法論。五組版本歷程，五種不同的收斂方式，你沒辦法從裡面抽出一條「剪輯 SOP」，我也沒有。

帶走什麼

連續三個版本都在調參數的時候，停下來檢查目標。

v2 那個做對了但沒上線的版本，是這一章最貴的一課：技術正確不等於方向正確。 你可以把一個錯誤目標下的實作優化到極致，然後發現整件事還是不能用。

第二條，關於怎麼驗收沒有標準的東西：把主觀判斷綁到一個可數的東西上。 「來賓發言少於 30% 就補回去」這個規則裡的 30% 是拍腦袋的，但它讓一個原本只能吵架的問題變成了可以查證的問題。

第三條，也是這一天回扣主軸的地方：這個節目一開始替整條產線設了五道人工閘門，每一道都是「沒有人點頭就不准往下走」的檢查點。五道裡面，第四道「正式錄音／出稿定版」是唯一真正守住的一道。

不是因為它寫得比較嚴，是因為它守的東西有物理性：稿子要定版，得有人讀過；成品要上架，得有人聽過。這道閘門不需要任何機制來執行，因為沒有人可以繞過「聽一遍」這件事，包括我自己。

其他四道閘門都是「按下一個鍵」，而按鍵可以被自動化。

明天開始講發布端，那裡的閘門守得就沒這麼好了。