AI 漫劇批次匯出規格引言
創意工作已經通過，也可能在交付時翻車。直式剪輯進了橫式資料夾，封面圖還用舊的標題安全區，剪輯師收到最終片段卻沒有提示詞記錄，客戶問為什麼兩個叫 final_final 的檔案字幕不同。動漫鏡頭本身沒有問題，問題是缺少匯出規格。
AI 漫劇的批次匯出不只是按下載鍵，因為一個專案通常有很多關聯輸出：母版片段、直式變體、方形裁切、封面、縮圖、提示詞記錄、聲音時間點、字幕檔、元資料、權利筆記和已歸檔的已選 take。如果這些交付物沒有一起規劃，團隊最後一天就會忙著修檔名、重設封面尺寸，並解釋哪個版本才是已審核的。
匯出比大多數人想得更早開始：畫幅比例（16:9 或 9:16）和風格在 Story Brief 裡就已經定下來，不用等到最後再重新裁切。這一集做完後，Export / Publish 就是匯出成片的地方。要做更完整的製作控制，可以搭配 低成本草稿到終稿範本 和 批次匯出與交付規格指南。
批次匯出交付物的核心原則
最終打磨前就規劃匯出。格式、時長、畫幅比例、安全區、音訊狀態、字幕需求和元資料都可能影響鏡頭構圖。如果這些規則在算圖後才出現，團隊就只能用裁切來修交付，剛審核通過的畫面也會被切掉。
把創意審核和交付審核分開。鏡頭可以通過角色、動作和故事複查，但仍然因為解析度錯誤或缺字幕時間點而交付失敗。使用不同狀態，避免任何人誤以為「approved」就等於「可以發了」。
清單要無聊但明確。每一行都應該標明交付物、來源鏡頭、格式、畫幅比例、時長、語言、音訊狀態、字幕狀態、負責人和審核狀態。再聰明的資料夾結構也不能取代可讀清單。
元資料要和它描述的資產放在一起。提示詞記錄、參考圖角色、使用筆記、標題、集數、平台文案和匯出日期，不應該待在一個斷開的文件裡。如果檔案要交給剪輯或歸檔，它的上下文也應該一起走。
批次前先跑一次樣例匯出。選一個有代表性的鏡頭，匯出所有需要的變體，然後複查交接。只在一個片段上發現安全區錯誤，比在四十個片段上發現便宜太多。
AI 漫劇批次匯出工作流程分步
從交付 brief 開始。列出作品會去哪裡：剪輯交接、客戶複查、社群發布、歸檔、配音遍、預告剪輯或集數組裝。每個目的地會產生不同檔案。不要為不存在的目的地發明交付物。
ArcLoop 裡不需要另外搭一份匯出清單——專案本身就是記錄。把已通過的鏡頭排進 Edit 時間線，調時長、排順序，在這裡加上 Generate Voiceover 和 BGM，做完後用 Export / Publish 匯出。這一條路徑，就是全部交付物。
為每個目的地寫交付規格。平台檔案要定義畫幅比例、時長範圍、封面尺寸、字幕要求、音訊狀態和標題/文案欄位。剪輯檔案要定義編碼或容器，需要的話還要定義 handles、音訊拆分、提示詞記錄和複查筆記。歸檔檔案要定義來源包、已選 take、最終匯出和審核證據。
批次算圖前先檢查名稱。命名應該攜帶專案、集數、鏡頭、變體、版本和狀態，但不要變成一段話。如果元資料很長，就放進清單，不要放進檔名。
匯出一個完整樣例包。像收件人一樣複查樣例。剪輯師不用問就能識別來源鏡頭和狀態嗎？發布者能找到正確封面嗎？歸檔能把最終版連回已選 take 嗎？
匯出出問題時，從源頭修：重新生成出錯的那一個鏡頭，或者在 Edit 時間線上重新裁剪，而不是重做整個專案。我的資產裡的身分和場景設定不用動，只改真正出問題的那一小塊。
匯出在哪一步：時間線之後，不是另一套系統
匯出不是掛在最後的另一套系統，而是同一個專案的最後一步。我的資產裡的角色和場景資產、這一集分鏡裡的鏡頭、Edit 裡的時間線，都屬於同一個工作流程，所以 Export / Publish 用的就是你做這一集時的同一個專案，而不是一張靠猜創作歷史的表格。
使用 工作流程範本 在批次規模變大前搭好製作路徑。對於連載專案，每集保留一份交付檢查清單，每個發布包保留一份清單。對於多平台活動，保留一個創意母版和獨立的平台變體。這可以防止社群裁切意外變成歸檔母版。
規劃也留在同一個專案裡：劇情藍圖、我的資產裡的角色和場景資產、各集分鏡、Edit 時間線，全都在同一個 IP 專案裡。團隊不需要在別處規劃，最後再匯入一堆檔案——Export / Publish 用的就是專案裡已經有的東西。
範例提示詞 1：霓虹燈籠案批次匯出清單
為原創 2D 動漫短片 Neon Lantern Case 的主角、偵探 Riko Vale 建一個 ArcLoop 角色資產。
專案背景：偵探 Riko Vale 在室內夜市追蹤一串編碼燈籠信號。本集有六個已通過鏡頭、一張封面圖、一條聲音軌和兩種平台剪輯。
目的地：剪輯交接、直式社群剪輯、橫式歸檔母版、客戶複查包和提示詞記錄歸檔。
清單欄：交付物 ID、來源鏡頭、檔案類型、畫幅比例、時長、音訊狀態、字幕狀態、封面要求、元資料要求、負責人、創意審核、交付審核和歸檔連結。
交付規格：把母版檔案和平台變體分開標記。為封面加入標題安全區筆記，為直式裁切加入字幕安全區筆記。
複查輸出：標記缺少字幕、畫幅比例不匹配、未審核裁切、重複名稱，以及沒有來源鏡頭連結的檔案。
這個提示詞在團隊建立一堆檔案之前，先把匯出任務變具體。
範例提示詞 2：直式片段包交付規格
為 Neon Lantern Case 的直式社群包準備交付規格。
來源：已通過鏡頭 S01 到 S06，以及已通過封面圖 C01。
包內容：一個 35 秒直式剪輯、一個靜音預覽、一個封面圖、一個字幕檔、一份標題與描述筆記、一份提示詞來源筆記和一個歸檔連結。
必要規格：9:16 直式構圖，角色臉部在上方安全區內，字幕位於臉部下方但高於下方 UI 區，不裁掉燈籠線索，畫面內不要未經審核的標題文字。
命名模式：NLC_E01_SOCIAL_9x16_deliverable_version_status。
審核狀態：creative-approved、crop-approved、caption-approved、delivery-approved。
收件人筆記：包含預期發布順序和未來編輯用的來源母版檔案。
這份規格覆蓋了交付意圖合併的問題：收件人可以發布、編輯或歸檔，不需要猜團隊內部縮寫。
範例提示詞 3：批次匯出複查修復
複查 Neon Lantern Case 匯出樣例，並提出最小交付修復。
樣例問題：直式剪輯已經創意通過，但封面圖使用舊標題安全區，字幕檔命名像草稿。
不要改變已通過動畫、聲音時間點、調色或來源鏡頭 ID。
修復請求：更新封面匯出行，標記正確安全區，按清單重新命名字幕交付物，並把舊封面保留為 rejected-delivery-safety-zone。
輸出：修訂後的清單行、更新後的交付檢查表，以及說明哪些檔案可以交付的筆記。
限制：不要新增創意變體，不要改集標題，不要刪除審核證據，不要模糊的 final 檔名。
這批匯出不需要創意重啟。它只需要一次很窄的交付規格修補。
AI 漫劇批次匯出的常見踩坑
最貴的坑，是最後才開始想畫幅比例。為橫式揭示構圖的鏡頭，不一定扛得住直式裁切。平台要求要在最終算圖前放進分鏡和鏡頭提示詞。
另一個坑，是只用一個審核標籤。「Approved」可能表示導演喜歡這個鏡頭、角色通過連續性、字幕已檢查，或整個包可以上傳。拆分創意審核和交付審核。
團隊也會把太多資訊塞進檔名。好檔名負責識別交付物，完整上下文由清單承載。長檔名很容易崩，而且依然解釋不了審核歷史。
第四個坑，是匯出所有可能的變體。批次匯出不是假想格式選單。只匯出對應真實目的地的格式。等新平台、剪輯、語言或歸檔規則真的需要時，再加新變體。
FAQ：AI 漫劇批次匯出
AI 漫劇匯出清單應該包含什麼？
包含交付物 ID、來源鏡頭、檔案類型、畫幅比例、時長、音訊狀態、字幕狀態、元資料要求、負責人、創意審核、交付審核和歸檔連結。只有真的會用到時，再加目的地專屬欄位。
匯出清單和交付規格有什麼差別？
清單列出每個交付物。交付規格定義這些交付物必須滿足的規則：格式、尺寸、安全區、命名、元資料、字幕、審核狀態和收件人筆記。
我應該一次匯出所有平台版本嗎？
先匯出一個完整樣例包。如果樣例通過裁切、字幕、命名、元資料和交接複查，再匯出其餘部分。這樣能在系統性錯誤倍增前抓住它。
匯出的檔案，怎麼才能追溯到是哪個鏡頭生成的？
把角色和場景資產留在我的資產裡，每個用到它們的鏡頭都用 @ 引用。匯出的時候，成片依然能追溯回同一批資產和這一集的分鏡，而不會變成鬆散資料夾裡一個來路不明的檔案。
能不能在生成任何鏡頭之前就先規劃好匯出？
可以——先在 Story Brief 裡定好畫幅比例和風格，寫好劇情藍圖，再一個鏡頭一個鏡頭搭這一集的分鏡。到 Export / Publish 這一步時，格式在最開始就定了，不是最後臨時拼的。
