缺少匯出規格會出什麼事
創意工作已經通過，也可能在交付時翻車。直式剪輯進了橫式資料夾，封面圖還用舊的標題安全區，剪輯師收到最終片段卻沒有提示詞記錄，客戶問為什麼兩個叫 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 時間線上重新裁剪，而不是重做整個專案。我的資產裡的身分和場景設定不用動，只改真正出問題的那一小塊。
大家說的「批次匯出」，其實是兩件不同的事，發生在兩個不同的地方，動手前先把它們分開。
批次生成在前，在劇集的 Storyboard 裡做。不用一張一張點 shot card 上的 Generate，直接在 AI Chat Panel 裡輸一句「Generate videos for Shots 4, 7, and 9.」，三個鏡頭就一次出完。回到各自的 shot card 上看結果，哪個不對就只重生成那一個，其他的別動。
批次匯出就是 Edit 時間線。把定下來的鏡頭按交付順序拖上時間線，掐頭去尾對齊你的時長要求，順序不對就調。等剪輯點都鎖定了再加 Generate Voiceover 和 BGM，免得每剪一刀就得重新對一遍聲音。然後把整條時間線從頭到尾看一遍，把自己當成收片的人：鏡頭順序錯了、剪輯點上有空幀、燈籠線索貼到 9:16 畫面邊上——這些在這一步發現，都比檔案發出去之後再改便宜得多。
確認沒問題了，再點 Export / Publish。這一步直接輸出這條時間線的成片。畫幅和風格早在 Story Brief 裡就定了，所以最後不需要再轉一遍格式，專案本身也一直記錄著這個檔案用了哪些鏡頭和資產。
匯出在時間線之後，不是另一套系統
匯出不是掛在最後的另一套系統，而是同一個專案的最後一步。我的資產裡的角色和場景資產、這一集分鏡裡的鏡頭、Edit 裡的時間線，都屬於同一個工作流程，所以 Export / Publish 用的就是你做這一集時的同一個專案，而不是一張靠猜創作歷史的表格。
使用 工作流程範本 在批次規模變大前搭好製作路徑。對於連載專案，每集保留一份交付檢查清單，每個發布包保留一份清單。對於多平台活動，保留一個創意母版和獨立的平台變體。這可以防止社群裁切意外變成歸檔母版。
規劃也留在同一個專案裡：劇情藍圖、我的資產裡的角色和場景資產、各集分鏡、Edit 時間線，全都在同一個 IP 專案裡。團隊不需要在別處規劃，最後再匯入一堆檔案——Export / Publish 用的就是專案裡已經有的東西。
範例 1：霓虹燈籠案批次匯出清單
Medium shot of @Riko Vale slowing to a stop in @Night Market as one paper lantern above her blinks out of rhythm with the rest. She tilts her head, reading the coded flicker while @Signal Lantern pulses on its string. Camera tracks alongside her at shoulder height, then settles as she stops, stalls drifting past in the foreground. Warm red and amber lantern light washes across her coat, steam curling from a food stall behind her. Market chatter and clinking cookware drop low under the lantern's soft, uneven click.
這個提示詞在團隊建立一堆檔案之前，先把匯出任務變具體。
範例 2：直式片段包交付規格
Close-up on @Riko Vale's face and raised hand as she lifts @Signal Lantern close to study its blinking code, keeping her eyes and the lantern both inside the top half of frame. Camera holds tight and steady, angled slightly up toward her. Warm amber light flickers unevenly across her face, @Night Market blurring into soft color behind her. The lantern's faint mechanical click is the only sound; the market noise underneath drops almost to silence.
這份規格覆蓋了交付意圖合併的問題：收件人可以發布、編輯或歸檔，不需要猜團隊內部縮寫。
範例 3：批次匯出複查後的修復
Wide shot of @Riko Vale standing still at the center of @Night Market, coat catching the glow of @Signal Lantern and the rows of lanterns strung above her. Camera is locked off at chest height, leaving clean space above her head instead of crowding the frame. Warm lantern light rims her silhouette against deep blue shadow across the stalls behind her. She doesn't move; only the lanterns sway. The market itself has gone quiet, just a low hum of distant chatter.
這批匯出不需要創意重啟。它只需要一次很窄的交付規格修補。
批次匯出最常見的翻車點
最貴的坑，是最後才開始想畫幅比例。為橫式揭示構圖的鏡頭，不一定扛得住直式裁切。平台要求要在最終算圖前放進分鏡和鏡頭提示詞。
另一個坑，是只用一個審核標籤。「Approved」可能表示導演喜歡這個鏡頭、角色通過連續性、字幕已檢查，或整個包可以上傳。拆分創意審核和交付審核。
團隊也會把太多資訊塞進檔名。好檔名負責識別交付物，完整上下文由清單承載。長檔名很容易崩，而且依然解釋不了審核歷史。
第四個坑，是匯出所有可能的變體。批次匯出不是假想格式選單。只匯出對應真實目的地的格式。等新平台、剪輯、語言或歸檔規則真的需要時，再加新變體。
常見問題
AI 漫劇匯出清單應該包含什麼？
包含交付物 ID、來源鏡頭、檔案類型、畫幅比例、時長、音訊狀態、字幕狀態、元資料要求、負責人、創意審核、交付審核和歸檔連結。只有真的會用到時，再加目的地專屬欄位。
匯出清單和交付規格有什麼差別？
清單列出每個交付物。交付規格定義這些交付物必須滿足的規則：格式、尺寸、安全區、命名、元資料、字幕、審核狀態和收件人筆記。
我應該一次匯出所有平台版本嗎？
先匯出一個完整樣例包。如果樣例通過裁切、字幕、命名、元資料和交接複查，再匯出其餘部分。這樣能在系統性錯誤倍增前抓住它。
匯出的檔案，怎麼才能追溯到是哪個鏡頭生成的？
把角色和場景資產留在我的資產裡，每個用到它們的鏡頭都用 @ 引用。匯出的時候，成片依然能追溯回同一批資產和這一集的分鏡，而不會變成鬆散資料夾裡一個來路不明的檔案。
能不能在生成任何鏡頭之前就先規劃好匯出？
可以——先在 Story Brief 裡定好畫幅比例和風格，寫好劇情藍圖，再一個鏡頭一個鏡頭搭這一集的分鏡。到 Export / Publish 這一步時，格式在最開始就定了，不是最後臨時拼的。
