模組五｜發布與衍生物（Day 23–27）

模組五的最後一天。前四天講封面、排版、導流、文案，每一篇的代價段落裡都有同一句話：

「因為複製上一集再改幾個數字是最快的。」

今天講這件事本身。

這是最土的一個問題，也是最頑固的

新集開工的第一件事，是建一個工作目錄。而我的做法是整包複製上一集。

理由完全合理：目錄結構一樣、腳本九成一樣、素材路徑格式一樣。複製再改，比從頭建快十倍。

而它的代價，是把上一集的所有東西都預設帶進了下一集，包括不該帶的。

撞號，至少五組

我把所有集數目錄列出來比對，撞號的情況有五種形狀：

一、下架後改名重新上架。 一集因為某些原因下架，重製之後改成另一個集號重新上架。commit 訊息寫著整批重新命名：混音腳本、建置腳本、封面腳本、封面圖全部改名。

二、同一個集號有兩個目錄。 一個在工作區、一個在封存區，而它們的內容是不同集。

三、用一個不存在的三位數集號當垃圾桶。 這一個最誇張。某次要清工作區，我把舊集的工作檔搬進一個編號多了一位數的目錄，那個集號不存在，它就是個暫存桶。

而同一個 commit 裡，還匯入了另一集的製作素材。commit 訊息自己加了註解：

某集素材位於另一集目錄，係目錄命名沿用所致，非該集內容。

我在 commit 訊息裡解釋為什麼目錄名是錯的，而不是把目錄名改對。

四、五、 封存區裡有集號分別出現 2 次跟 3 次。

放錯目錄，至少九起

比撞號更常見。而機制完全一致：

複製上一集整包
  ↓
改了「今天要用的」那些檔案
  ↓
「今天沒用到的」保持上一集的內容
  ↓
留在新目錄裡，看起來像本集的東西

三份剪輯記錄自己招認了這件事：它們的檔名一開始都是上一集的，後來才改。

而鐵證是位元組數：

• 某個目錄裡有前一集的兩張封面、兩份 HTML、一份資料檔，位元組數與來源目錄完全一致
• 另一個目錄有上一集的剪輯腳本，兩者同為 15,382 bytes

完全一致的位元組數，代表那個檔案從複製到現在一個字都沒動過。

日期後綴已經失效

還有一個更安靜的證據。

我的目錄命名帶日期後綴。而實際的分布是：

• 12 個集數目錄的後綴全是同一天
• 另外 14 個的後綴全是另一天

正常情況下，26 個集數應該有 26 個不同的日期。

那個日期不是播出日，是「我批次搬動這些目錄的那一天」。 而它從來沒被改回去。

也就是說：目錄名裡有一個看起來是資訊的東西，而它其實是噪音。 而且它比沒有更糟，因為我會下意識相信它。

跨四個月，四次才收斂

這個問題的處理歷程長這樣：

第 1 次   更新節目元資料裡的標題編號
第 2 次   重新命名集號（同時修字幕錯字）
第 3 次   修正誤命名的草稿並清理殘留檔
第 4 次   更新編號規則文件，解除集數標記衝突

跨四個月，四次。

而收斂的那一次不是改檔名，是把編號規則寫成文件。

一個很誠實的對照

中間我做過另一件事：建了一支「集數 scaffold CLI 工具」，還附了測試。

那次 commit 之後，編號還是繼續錯。

工具建了，問題沒解決。而最後解決的是一份文件。

這是這整個系列裡，唯一一個「文件規則有效、工具無效」的案例。

它跟主軸（寫成文件的規則會懸空，寫成程式的斷言才活得下來）看起來是反例。

為什麼它不是反例

我想清楚之後，發現分界線不在我原本以為的地方。

不是「文件 vs 程式」。是：這條規則的執行者是誰。

集數編號的執行者是人。 每一次建新目錄的都是我，而我需要的是一個「我記得去查」的東西。

而那支 scaffold 工具為什麼沒用？因為它沒有取代那個複製動作。工具建了，我還是繼續複製上一集，因為複製更快，而工具要記指令、記參數（Day 16 講過三份文件把那個參數名寫錯了，照抄還會失敗）。

一個沒有取代舊習慣的新工具，等於沒有工具。

那真正的修法是什麼

寫這篇的時候我想清楚了，而它跟前面兩個都不一樣：

讓複製這個動作本身變安全。

真正的修法是複製之後跑一個檢查。禁止複製做不到，它太方便了。換一個更好的工具也試過了，沒用。

掃新目錄裡的每個檔案：
  - 檔名含舊集號？          → 報錯
  - 內容含舊集號字串？       → 報錯
  - md5 與來源目錄同名檔相同？→ 警告（可能沒改到）

十幾行。而它抓的是這一整篇的每一個症狀：三個 stale copy（Day 23）、九起放錯目錄、五組撞號。

我到現在沒寫。 而我在寫這一篇的時候才第一次把這個檢查想清楚，因為在此之前，我從來沒有把這些症狀當成同一個問題。

代價

這個問題我沒有解，只有繞。

現在的實際做法是：複製之後，靠我自己記得改哪些檔案。而「記得」的成功率，從這篇的資料看，大概是九成，每集有幾個檔案沒改到。

第二個代價比較貴：那些沒改到的檔案還躺在 git 歷史裡。

.git 目錄現在 3.2 GB，而其中一大部分是被複製了很多份的大檔案，包括 6 份不同時期的資料檔快照（2.2 MB 到 5.8 MB，內容互不相同），合計約 24 MB 的近似重複 JSON。

複製式初始化的成本，最後是以 repo 體積的形式付掉的。 Day 28 會講這件事。

帶走什麼

如果你的 scaffold 是用「複製上一份」實作的，那你一定有複製殘留，差別只在你有沒有去找。

而找的方法很便宜：掃新目錄裡有沒有舊識別字串、比對 md5 有沒有跟來源完全相同的檔案。 十幾行程式碼，抓的是一整族的問題。

第二條，這一天真正的收穫：

規則該寫成文件還是程式，取決於它的執行者是人還是機器。

• 執行者是人 → 寫成文件。人會讀、會記得、會被同事提醒
• 執行者是機器或 AI → 必須寫成機器讀得懂的斷言，否則它不存在

集數編號的執行者是我，所以文件有效。而 Day 30 那五道閘門的執行者是 AI，我把給機器的規則寫成了給人看的格式，這是它們懸空的真正原因。

第三條：一個沒有取代舊習慣的新工具，等於沒有工具。

我建了 scaffold CLI，然後繼續複製目錄。因為複製更快、不用記參數、不會因為文件寫錯而失敗。

要取代一個習慣，新方法必須比舊方法更省事，而不只是更正確。

模組五到這裡結束。明天進最後三天，從 AI 協作留下的垃圾開始。