內容與發現
一條母片，各平台各自的比例
同一段九十秒，要變成 Reel、Short、TikTok，以及動態消息用的方形版本。多數團隊靠人手重新輸出，然後在上載那一刻才發現規格不符，而那是最貴的發現時機。這些規格全部公開，所以檢查應該放在算圖之前，不是放在被拒之後；至於裁切做不到的比例，應該交給人處理，不是交給重試。
- 觸發
- 兩個
- 執行頻率
- 每小時
- 工具
- 4 件
- 需要 durable execution
- 不需要
流程
上面那條讀取母片並排出要做的版本，下面那條定時逐個處理，並且在花費算圖之前先問一條問題。
母片登記
Sheets · Airtable
讀出實際規格
n8n · Make
寫入版本清單
Sheets · Airtable
每小時
n8n 排程
取出未產出的版本
n8n
是否符合平台規格？
n8n IF
切出版本並交付
Instagram · TikTok · YouTube APIs
轉交人手重新構圖
Slack · WhatsApp
逐步拆解
- 01
母片登記
Sheets · Airtable剪接師加一行，指向母片檔案。一條母片一行；之後每個版本都回指這一行，所以永遠不會出現「這是哪一版剪出來」的疑問。
- 02
讀出實際規格
n8n · Make時長、尺寸、封裝格式與編碼，全部由檔案本身讀出，不是由那一行讀出。剪接師的備註與輸出設定不一致的次數，比雙方預期都要多。
- 03
寫入版本清單
Sheets · Airtable一個版本一行：平台、目標比例、目標時長、狀態。它能告訴你 Short 從來沒有做過；一個資料夾永遠不會告訴你哪一個檔案不存在。
- 04
每小時
n8n 排程接手仍未產出的版本，包括上一次失敗留下的。在資料夾裡，算到一半崩潰與從未排隊看起來一模一樣；在清單上，兩者不同。
- 05
取出未產出的版本
n8n從清單讀出尚未有輸出的行，先舊後新。
- 06
是否符合平台規格？
n8n IF在花費算圖之前，先用公開規格核對數字：長寬比、時長、封裝、編碼、檔案大小。這只是算術，相比一次被拒的上載，成本近乎零。
- 07
切出版本並交付
Instagram · TikTok · YouTube APIs按目標規格算圖，再經各平台自己的介面上載。算圖與上載要分開記狀態，因為上載失敗不應該逼你重新算圖一次。
- 08
轉交人手重新構圖
Slack · WhatsApp裁切做不到的比例需要人，不是重試。16:9 雙人鏡頭自動置中裁切，結果是主持人沒有了頭，而通常要等它上線之後才有人發現。
平台不容許的事
六條寫明的規格。每一條在算圖之前只花一秒去核對，在被拒之後要花一小時去補救。
Reels 只接受「MOV or MP4 (MPEG-4 Part 14), no edit lists, moov atom at the front of the file」，編碼為 H264 或 HEVC，長寬比「between 0.01:1 and 10:1 but we recommend 9:16」，橫向最多 1920 像素，時長 3 秒至 15 分鐘，檔案 300MB 以內。最常中招的是 moov atom 那一條：檔案在剪接師電腦播放完全正常，上載時被拒。
Instagram Platform — IG User /media (reel and image specifications)動態消息的圖片必須是 JPEG，8MB 以內，長寬比「within a 4:5 to 1.91:1 range」，闊度會被縮放到 320 至 1440 像素之間。9:16 的直度圖不可能原樣放進動態消息，必須重新構圖——那是設計決定，不是縮放。
Instagram Platform — IG User /media (reel and image specifications)TikTok 的上載介面接受 video/mp4、video/quicktime、video/webm，較大的檔案要用 video_size、chunk_size、total_chunk_count 分段上載。上載是一連串有中間狀態的動作，不是一次成功或失敗的呼叫。
TikTok for Developers — Content Posting API, upload video「Unaudited API Clients can only post contents in SELF_ONLY viewership」，而且「can allow up to 5 users to post in a 24 hour window」。通過審核之前，TikTok 那條線無論版本剪得多好，都只會私下發到你自己的帳號——這件事值得在動工之前知道，不是動工之後。
TikTok for Developers — Content Sharing GuidelinesYouTube 有同樣的閘，而且容易被漏看，因為它其餘的文件讀起來像一般速率限制：2020 年 7 月 28 日之後建立、未經驗證的 API 專案，透過 videos.insert 上載的影片一律限制為私人觀看，要通過合規審核才解除。兩條線在通過審核之前都只能私下發佈，不是只有 TikTok。
YouTube Data API — videos.insertShorts 的定義是「short-form videos that are up to 3 minutes long」，而且可以「upload Short videos with a maximum resolution of 1080p」。剪到 3 分 05 秒的版本就是普通影片，會落在另一個版位，不是它原本要去的那一個。
YouTube Help — Create a YouTube ShortYouTube 專案的「default quota allocation」是「100 search.list calls, 100 videos.insert calls, and 10,000 units per day combined for all other endpoints」。把舊有片庫補做一次，速度由這一百次決定，所以它按算術就是一件跨日的工作，不是取捨問題。
YouTube Data API — Getting started (quota)
什麼情況不值得做
以下三種情況，維護成本會高於人手重新輸出的代價。
你只發一個平台。那就沒有母片，也沒有版本，只有一條片；圍住它建的流程，是一個裡面沒有東西的棚架。
你的影片本來就按平台分開拍：一個平台原生直度，另一個坐著對鏡頭講話。沒有東西是衍生出來的，也就沒有可以衍生的來源。
沒有人查看被標記的構圖。這條分支的價值，在於機器會做壞的畫面交由人處理；如果標記送去一個沒有人看的頻道，流程就是把做壞自動化了，同時移走了本來會攔住它的人。