影片版本控制：管理修改、變體與正式版本

01

影片版本控制到底是什麼

視訊版本控制不僅僅是雲端儲存或更清晰的檔案名稱。它是一個生產記錄，將可見輸出連接到創建它的腳本、來源資產、編輯決策、審核狀態和發布目標。團隊應該能夠打開任何已交付的主版本並識別其父版本、請求的修訂、批准它的人員或角色以及當時允許的資產和聲明。如果沒有這條鏈條，即使每個人都認為他們使用的是最新的資料夾，舊的徽標或價格也可能會返回。

一致地使用三個術語。 版本是工作在某個時間點的可復原快照。 修訂是對相同預期交付成果的請求更改，例如替換一個螢幕截圖或更正一行。 變體是針對不同受眾、語言、寬高比、管道、優惠或 CTA 的有目的的分支。將每個匯出稱為「新版本」隱藏了更改是否應該取代主版本、保留為並行分支，或作為未經批准的繞道而被拒絕。

02

為什麼 final-final 檔名會失效

像 launch-final-v7-new.mp4 這樣的名字編碼的是焦慮，而不是狀態。他們沒有透露 v7 是否包含 v6 的合法更正，「新」是否指腳本或資產，或者方形剪輯是否是已批准母版的分支。資料夾也會發生變化：審閱者下載草稿，在本地對其進行標記，然後在沒有原始討論的情況下上傳另一個文件。編輯器複製舊項目，因為它已經有了正確的動畫。因此，最新的時間戳記可能是最新的錯誤，而不是批准的結果。

有用的識別碼可以保持簡單：專案、可交付成果、分支、修訂號和狀態。例如，「atlas-launch_master_r04_approved」描述了一個主修訂版； `atlas-launch_linkedin-1x1_r02_review` 描述了一個平台變體。保留人類可讀的名稱，但在旁邊儲存更豐富的記錄：父 ID、更改請求、來源套件 ID、編輯者、審查者、日期、分發目標以及校驗和或平台資產 ID（如果可用）。切勿從文件的位置或修改日期推斷核准。

03

使用明確狀態和允許的流轉

在專案變得緊急之前定義一個小型狀態模型。 草稿意味著編輯可以更改它。 審核 意味著特定審核輪次的輸出被凍結。 批准表示指定所有者接受將其用於規定的目的地。 發布意味著它已經實際交付或發布。 取代意味著較新的批准版本將取代它以供將來使用。 存檔意味著保留它以供追溯，但不應分發。被拒絕的草稿可以返回編輯，但不應在另一次導出後默默地獲得批准。

狀態和修訂號回答不同的問題。一輪審核可以產生評論，而無需創建批准的修訂。經批准的主控稍​​後可能會被取代而不會被刪除。將狀態新增至記錄中，而不僅僅是檔案名，並且需要一個明確轉換擁有者。在電子表格、資料庫、DAM、審閱平台或生產應用程式中，同樣的邏輯適用。本文提供工作流程建議，但不聲明 TapVid 或其他工具中每個角色的本機審核路由、同步編輯或權限。

為每個可復原快照設定不必開檔就能讀懂的 VERSION-ID，例如 project-purpose-locale-aspect-major.minor-status-YYYYMMDD。受眾、承諾、流程、offer 或敘事出現需全面審核的變化時升 major；只修正一張已確認截圖、字幕或旁白時升 minor。狀態依 working、in review、approved、delivered、retired 流轉，並在專案紀錄、審核連結、輸出檔與交付日誌使用同一 ID。它不能取代資料庫，但能區分同名結果，並讓聊天與審核意見有穩定引用。

04

改場景前先鎖定來源和主張

每個版本都應引用一個來权威资料包，其中包含腳本、徽標、產品圖像、UI 捕獲、鏡頭、旁白、字幕、音樂版權、批准的聲明和目標規則的穩定 ID。標記必須保持準確的受保護內容：產品名稱、價格、型號、法律措辭、功能條件和客戶報價。當來源發生變更時，記錄它是否會導致一個場景、多個變體或整個可交付成果失效。具有相同檔案名稱的新螢幕截圖不應以無形的方式取代舊證據。

分三層審查準確性。資產保真度將提供的資產與使用它的框架進行比較。資訊保真度將受保護的措辭和數據與批准的來源進行比較。對應性檢查敘述和視覺效果是否同時指涉相同的產品、功能或聲明。目的不是保證完美的輸出。它是為了使版本可重現，並且在任一輸出到達客戶之前可解釋兩個輸出之間的差異。

05

按鏡頭或場景隔離修改

更改請求應標識最小的擁有單元：場景 04、旁白線 04B、螢幕截圖資產 UI-12、字幕提示 18 或 CTA 卡 C。記錄先前的狀態、請求後的狀態、原因、請求者、受影響的變體和驗收檢查。 「讓它變得更流行」是不可行的。 「在場景 04 中，將 UI-11 替換為 UI-12，因為權限儀表板標籤已更改；保持旁白和時間不變」為編輯者提供了邊界，為審閱者提供了測試。

場景隔離減少了意外回歸。如果一張產品卡的價格發生變化，則不相關的場景應保持相同，除非變更要求另有說明。 TapVid的可見腳本和場景規劃支援這種審查模式：可以在輸出之前檢查已批准的文字和資源，並且可以在相關場景中重新運行更改的線條或圖像，同時保留先前的版本。仍然將生成的場景與其來源進行比較，並在發布前檢查相鄰的過渡、字幕、音訊和時間。

下方截圖來自真實 TapVid 工作流程，畫面在已生成場景旁顯示一項逐場景修改要求。它能證明審核者可以指出要修改的場景並寫明內容，但不能證明 Git 式分支、完整修訂歷史或多人審批；若需要這些功能，必須另外核驗。

不要用零散訊息傳遞修改，使用 Change request record。記錄提出者、日期、目前 VERSION-ID、影響場景、修改前後狀態、原因、經確認來源、受保護文字、下游版本、審核人、期限、驗收條件與最終決定。把事實變化與偏好分開，並在編輯前列出旁白時間、字幕、裁切與翻譯依賴。只有對照來源並更新所有發布位置後才能關閉紀錄。這能在投入製作前分清局部修正與全面重做。

06

不丟主版本地建立變體

當目標受眾或交付合約發生變化時建立變體。常見的分支包括 16:9 和 9:16、英語和德語、免費計劃和企業訊息、付費社交和幫助中心剪輯或具有不同 CTA 的母版。僅作物就可以改變可見的證據、文字安全性和時間安排，因此每個分支都需要自己的驗收檢查。記錄父版本和分歧點。如果主版本稍後發生更改，請仔細決定哪些變體繼承更改，而不是自動複製每個編輯。

盡可能透過引用保護共享元素。即使多個輸出使用它，單一經批准的標誌資產或法律行也應具有一個來源 ID。同時，不要強行將不同的分支重新組合在一起。垂直社交掛鉤可能不屬於詳細教程，而在地化語音軌道可能需要不同的時間表。使用變體矩陣列出受眾、管道、格式、語言、優惠、CTA、父級、目前核准的修訂版和發布目的地。空白單元格顯示導出前缺少的決策。

把 variant matrix 當作依賴地圖，而不只是清單。加入 master VERSION-ID、語言、畫幅、渠道、offer/CTA、素材集、核准狀態、交付 URL 與最近繼承的變更。master 改動時，把每個分支標為繼承、複核或刻意分離。產品名稱修正可能要同步全部分支，但社群 hook 不應悄悄改動說明中心版本。多語版本還需各自的受保護文字、配音長度、字幕與審核人。發布前篩查空白核准、缺少目的地與仍指向舊 master 的分支。

07

把審核交接寫進流程

每一輪審查都需要一個範圍。告訴審閱者他們是否正在檢查事實準確性、品牌、法律語言、可訪問性、動作、音訊或最終交付。針對穩定的審核輸出收集意見，解決重複問題，並將接受的意見轉變為編號的變更請求。評論不等於認可，沉默也不等於認可。當兩位審閱者發生衝突時，將決定傳遞給指定的所有者，而不是讓編輯猜測哪一則訊息較新。

更改後，發布修訂說明，列出更改的內容、未更改的內容、開放限制以及確切的驗收檢查。保存審核輸出和決策記錄。這可以透過審查平台、專案系統、資料庫或規範的文檔流程來完成。重要的屬性是可追溯性。請勿將此工作流程描述為內建產品功能，除非所選工具已被驗證可以為相關計劃和帳戶提供該功能。

08

發布、還原與稽核

在發布之前，將候選者與批准的來权威资料包、更改請求、父輸出、變體矩陣、標題、音訊、連結、寬高比、文件屬性和目標要求進行比較。確認不相關的場景沒有改變。記錄發布的 URL 或平台 ID、發佈時間、所有者、校驗和（如果使用）以及回滾目標。將前主人標記為已取代而不是刪除它。如果平台重新編碼文件，請驗證公開結果，而不是假設上傳等於播放。

恢復是新記錄的操作，而不是時間機器。識別保留的版本，解釋為什麼要恢復它，檢查自批准以來策略或來源事實是否已更改，並在新的狀態轉換下發布它。對於審計，選擇任何公共輸出並向後查看其原始碼包和決策。如果鏈條斷裂，請在下一次活動之前修復記錄。良好的視訊版本控制使更改變得無聊、有限且可逆，而無需假裝創意工作的行為與原始程式碼完全相同。

重要版本上線前準備 rollback packet，包括上一版核准檔案、source manifest、script-scene map、核准紀錄、字幕、影響重用的授權、已知限制、發布位置與替換原因。讓未參與編輯的人測試能否找到舊版及其證據。觸發回復時先確認舊事實、政策、連結與 offer 仍有效；恢復過時主張不算復原。將恢復版作為新的狀態轉換發布，更新所有目的地，並依留存規則保留失敗版本供診斷。