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

先講一件我沒有的東西：我沒有轉換數據。

我不知道有多少人看完短影片之後去聽了正片，也不知道加了導流卡之後這個數字有沒有變。這篇文章不會給你 before / after 對照，因為我手上沒有。

那為什麼還要寫這一天。

因為我手上有另一種東西：git 紀錄。而它記下的東西，比我原本以為的還多。

這個環節長什麼樣

短影片不是我剪的。正片剪完之後，音檔丟給一個外部的 AI 切片服務，它自己找出適合單獨傳播的片段、切出來、上字幕。產出的檔案回收進逐集目錄，檔名帶著 20 個字元的 hash，那是服務端的 id，不是我命的名。

這是整條產線裡唯一一段我完全沒有控制權的環節。我不知道它為什麼挑那幾段，不知道它的字幕怎麼斷行，也沒辦法要它改。

然後短影片被發出去，正片在另一個地方。

那個問題被寫下來過

在選題策略的文件裡，有一句話：

大量轉換在這裡流失。

這句話是我寫的，而且不是最近寫的。也就是說，這個問題被識別的時間，遠早於它被處理的時間。

git 記下的是「補」，不是「做」

我原本以為導流卡是某一集開始做的，之後就變成標準流程。

查完 commit 之後不是這樣。近期有整整一批 commit，主題是逐集回頭補導流卡：一集一集地補上去，補的是好幾個月前就發出去的短影片。

這批 commit 的形狀本身就是答案：如果它是流程的一部分，就不會有「補」這個動作。

導流卡做的事很簡單，一支腳本三個步驟：

# 1. 產 QR 圖 —— 導向該集的收聽頁
qrcode.make(episode_listen_url).save(qr_png)

# 2. 合成尾卡 —— 滿版底色 + QR + 一行 CTA 文字
#    文字置中用 textbbox 量測，不寫死座標（這個坑見 Day 24）
bbox = draw.textbbox((0, 0), cta_text, font=font)
draw.text(((W - (bbox[2]-bbox[0])) / 2, y), cta_text, font=font)

# 3. 尾卡轉 2 秒影片，concat 到短影片末端；SRT 補一條 CTA 字幕
ffmpeg(f'-loop 1 -i {tail_png} -t 2 -c:v libx264 -pix_fmt yuv420p {tail_mp4}')
ffmpeg(f'-f concat -i {list_txt} -c copy {out_mp4}')

沒有一行是難的。第 2 步那個 textbbox 甚至是從 Day 24 那次「12 分鐘修六次才把文字置中」直接抄過來的。同一個坑只踩一次，這部分的工程紀律是有效的。

而它之所以拖了幾個月，不是因為難，是因為短影片產出的時候，它已經「完成」了。

這裡有個細節值得停一下：這支腳本是逐集寫的，不是共用的。 每一集的目錄裡各有一份，檔名帶著各自的集號。它們的差別只有輸入路徑跟那個收聽連結，邏輯完全一樣。

也就是說，即使我補完了所有集數的導流卡，下一集還是會需要有人記得再寫一份。補完不等於流程化。這跟 Day 23 那三份被複製到不同目錄、卻還指向舊集數的封面腳本，是同一個病。

一支短影片的完成定義是「切好了、上字幕了、可以發了」。導流不在這個定義裡。所以它不會被漏掉：它根本不在清單上。

衍生物的預設狀態是斷開的

我把這件事想清楚之後，發現它不只發生在短影片。

回頭看整條產線：正片有 rundown 對應、rundown 有新聞條目 id 對應、剪輯記錄有腳本對應，主線上的每一環都指得回上一環。

而衍生物沒有。封面圖不知道它是哪一集的（除非檔名寫對，而 Day 27 會講檔名多常寫錯）；直式影片不知道它的音源；社群文案不知道它的逐字稿（Day 26 就是這個事故）；短影片連檔名都是外部服務給的。

主線是被設計成連續的，衍生物是被設計成產出的。 而**「產出」的預設就是斷開，它的完成條件裡沒有「連回去」這一條。**

這件事有一個很簡單的檢驗方法：問這個產物「你從哪來、要去哪」，它答不答得出來。

短影片答不出「要去哪」，所以它需要一張 QR 卡。而那張 QR 卡是外部黏上去的，不是它自己帶著的，這就是為什麼補了幾個月。

這一天為什麼特別難寫

回到開頭那件事：我沒有數據。

而我想清楚了我為什麼沒有，因為這條產線的觀測能力，到 git 就結束了。

前面 24 天我能給你精確到小數點的數字：offset 從 +3.0 秒漂到 +1.75 秒、438 則條目裡 184 則卡在補件、字幕錯字佔 13.1% 的 commit。這些數字之所以存在，是因為它們全部發生在 repo 裡。

而「有沒有人從短影片點進正片」這件事發生在外面。它不在任何一個我 grep 得到的地方。

所以這一天沒有辦法像前面那樣舉證。我能證明的只有三件事：

1. 這個問題被識別了（策略文件裡那句話）
2. 它被處理了（那批補導流卡的 commit）
3. 它是回頭補的（commit 的時間分布）

我不能證明修補有效。

但這個誠實本身有價值

大部分講導流的文章也拿不出前後對照，只是它們不說。

我在寫這一段的時候意識到一件事：「有流量但沒轉換」這種句子，本身就是一個沒有數據的判斷。 我當初寫下「大量轉換在這裡流失」的時候，也沒有數據，我是從結構推的：短影片跟正片之間沒有任何連結，所以轉換必然很低。

那個推理應該是對的。但它是推論，不是量測，而我當時把它寫得像事實。

這件事跟 Day 8 講的那套查核分層是同一個病。我對新聞裡的每一句話都要求分層（已證實的講死、未定的講「據稱」），而我對自己專案裡的判斷完全沒有這個要求。

代價

這一天的代價是它的論證強度比其他 29 天低。

我可以告訴你「衍生物的預設狀態是斷開的」這個觀察，也可以告訴你為什麼，但我沒辦法給你「連回去之後好了多少」。如果你要的是一篇能讓你複製結果的文章，這篇不是。

第二個代價比較貴：我到現在還是沒有裝任何量測。 寫完這篇之後我依然不會知道下一集的轉換率。要真的解決這件事，得在導流連結上帶參數、得接分析工具、得定期看，而這三件事都在 repo 外面，也就是說，它們不會被我的任何一支腳本提醒我做。

這就是這篇文章真正的內容：不是導流沒做好，是我的整套工程紀律，只覆蓋到 git 追蹤得到的範圍。

帶走什麼

衍生內容的預設狀態是「跟主體斷開」。連回去這件事必須被寫進它的完成定義，否則它不會自己發生。

檢查方法很簡單：拿起你產線上的任何一個衍生物（一張圖、一支影片、一篇文案、一份匯出報表），問它兩個問題：你從哪來？要去哪？

答不出「從哪來」，你就會遇到 Day 26 的問題（文案裡有節目沒講過的話）。
答不出「要去哪」，你就會遇到今天的問題。

而第二條，是這 30 天到目前為止我最不想承認的一條：

你的工程紀律只覆蓋到你觀測得到的地方。

那五道閘門守的是 commit、上架、發文、定版、覆寫，五件全部發生在 repo 裡或 repo 邊界上的事。一旦東西離開了這個邊界，我既沒有閘門，也沒有驗證器，甚至沒有數字。

我一直以為那五道閘門的問題是它們沒有被執行（Day 30 會講這件事）。寫到這一天我才發現還有另一個問題：它們守的範圍，本來就只有我看得見的那一半。

明天講一個更難堪的：發布文案裡，有節目從來沒講過的話。