為什麼大部分檔名兩週後就失效
糟糕的檔名在批錯片段之前，看起來都不危險。導演評論 scene04_final.mp4，剪輯師上傳 scene04_final_new.mp4，歸檔裡保留 scene04_final_revised_real.mp4。其中兩個檔案是裁切測試，一個有正確表演節拍，但檔名沒有說明它們來自哪個提示詞或已選 take。
AI 漫劇製作會放大這個問題，因為每個鏡頭都可能有提示詞草稿、參考圖組、生成 take、已選 take、清理最終版、聲音遍、平台裁切、封面幀和歸檔副本。girl_rooftop_good.mp4 對個人實驗可能夠用，但專案一旦有集數、語言、畫幅比例、複查狀態和修訂歷史，就會崩。
命名規範應該讓檔案能被找到，但不用逼檔名扛下所有上下文。這些上下文本來就在 ArcLoop 裡：專案、集數（EP1、EP2……）、分鏡裡的 shot card。留在 ArcLoop 之外的檔案——本地匯出、還沒綁到資產上的 Reference image——檔名只要能識別專案、集數、鏡頭和版本就夠了。用 工作流程範本 把命名和製作流程綁在一起；同一批角色和地點需要長期連續性時，用 ArcLoop 世界觀。
檔案命名的生存法則
名稱應該按製作順序自然排序。把最寬的單位放前面：專案、集數或段落、鏡頭、資產類型、變體、版本和狀態。檔案能自然排序時，複查人不用打開每個檔案也能掃資料夾。
核心名稱要用穩定編號，不要用場景描述。像「鏡頭 2」這樣的編號，就比「陽台告白」更能撐住劇本修改。描述詞可以作為短變體標籤出現，但編號應該保持錨點地位。
狀態詞要少。使用有限集合，比如 draft、select、review、approved、final、rejected 和 archive。如果每位隊友都發明一個狀態詞，命名就不再是規範。
長解釋不要塞進檔名。提示詞內容、鏡頭筆記、每個角色名，這些都不用寫進檔名——它們本來就在 shot card 裡，身分則在鏡頭引用的 @ 角色資產裡。
保護已通過工作，防止被覆蓋。不要給已經變更的檔案復用同一個名稱。遞增版本，或改變狀態。這條很基本，但能防止唯一已通過 take 被後續測試悄悄替換。
怎麼搭命名模式：從欄位到首次匯出
先選擇專案實際使用的單位。獨立短片可能只需要專案、鏡頭、資產類型、版本和狀態。連載系列可能需要專案、季、集、段落、鏡頭、take、變體、版本和狀態。不要添加沒人會搜尋的欄位。
定義簡單模式。一個實用模式是 PROJECT_EPISODE_SHOT_TYPE_VARIANT_v##_STATUS.ext。例如 GARDEN_E01_SH012_clip_master_v03_approved.mp4。統一大小寫，並避免空格，讓匯出在不同工具間更穩。
為 type 和 variant 建立允許值。Type 可以是 prompt、ref、take、clip、cover、voice、caption、manifest 或 note。Variant 可以是 master、vertical、square、clean、subbed、cropA 或 paletteB。允許值能防止資料夾漂移。
寫清版本規則。草稿和修訂只要檔案內容改變，就應該遞增版本。狀態變化可以建立一份帶狀態的副本，也可以更新清單狀態，取決於工作流程。關鍵規則是：內容變化不能覆蓋已通過檔案。
檔名接到專案就好，不用想著取代它。帶上專案、集數和鏡頭的短名稱就夠——真正的依據還是 ArcLoop 裡的 shot card，以及鏡頭用 @ 引用的角色或場景資產。
批次匯出前做一次命名複查。檢查重複 ID、缺失版本、混用狀態詞、沒有來源鏡頭的檔案，以及看起來像母版的平台變體。只花幾分鐘，能省很多小時。
為混亂舊資料夾寫重命名路徑。如果檔案已經發給剪輯師或客戶，在新包被接受之前，把舊名稱作為別名保留在清單裡。重命名應該提升可追蹤性，不應該讓昨天指向舊檔的評論串全部斷掉。
什麼寫進檔名，什麼留在 ArcLoop
檔名能保持短小，是因為真正的上下文已經在 ArcLoop 裡：角色和場景資產、劇情藍圖，以及每個鏡頭在它所屬分鏡裡的位置。這意味著一個本地檔案叫 NIGHT_E02_SH006_clip_vertical_v02.mp4 也能保持簡短好讀，因為詳細的故事和身分上下文放在關聯的專案裡，而不是名字裡。
對團隊來說，實用邊界是：檔名負責身分，ArcLoop 負責意義。把專案、集數、鏡頭、類型、變體和版本放進名稱。故事本身放進劇情藍圖，真正的身分引用則透過鏡頭描述裡的 @ 帶進來。
團隊定好本地檔案的命名規則後，在第一次匯出前寫下來就好——它只用於 ArcLoop 之外，因為專案內部每個鏡頭本來就在所屬分鏡裡有固定位置。沒人需要在審核後手動重新命名整季。
同一套習慣在比較多次嘗試時也有用。在 Canvas 上，你可以對一個鏡頭分支、試不同的版本，再退回更早的想法，而不會搞混誰是誰——匯出到本地的檔案用穩定命名，也能把這段歷史在專案之外保持清楚。
在你開始給匯出檔案命名之前，先看看 ArcLoop 內部這條邊界是怎麼運作的。
開啟 IP 專案，進入我的資產，為每個反覆出現的角色建一個 Character asset——Copper Harbor 裡就是船長 Elian Ro。把參考圖上傳到 Library，然後繫結（Bind）到資產上作為 Main image。如果有第二角度或服裝圖，再加一張 Reference image。
進入第 1 集，點選 Generate Shots。ArcLoop 會根據你的 Story Outline 生成一套 shot card。在每張卡里輸入 @Captain Elian Ro，就能把船長的身份帶進來——不用重新描述他的臉或外套。只寫這個鏡頭新增的內容：動作、機位、光線。
先給第 1 鏡生成圖，確認構圖和角色設計沒問題，再生成影片。看起來對了，就出影片。要批次處理多個鏡頭，用 AI Chat Panel："Generate videos for Shots 1, 2, and 3." 對 take 滿意後，在 Edit 裡把它們拖到時間線上排列、裁剪。
只有到 Export 這一步，本地檔名才真正重要。這時候 shot card——連同裡面的 @ 引用、鏡頭描述，以及它在分鏡裡的位置——已經裝下了所有有意義的資訊。檔名只需要是個簡短、能排序的標籤。
範例 1：Copper Harbor 命名規範
Write a file naming convention for local exports from the Copper Harbor project.
Production shape: 3 short episodes, one recurring captain character asset (@Captain Elian Ro), 8 to 12 shots per episode. Export types include master clips, vertical social cuts, cover images, and caption files.
Naming pattern: COPPER_E##_SH###_TYPE_VARIANT_v##_STATUS.ext
Allowed TYPE values: clip, cover, caption, ref.
Allowed VARIANT values: master, vertical, square, subbed.
Allowed STATUS values: draft, review, final.
Version rule: increment v## whenever file content changes. Never overwrite a file already shared with the team.
Context rule: story detail, shot descriptions, and @asset references all stay inside the ArcLoop project. The filename is a short handle, not a substitute for the shot card.
這個提示詞給團隊一條足夠容易執行、又足夠嚴格到能抓常見問題的規則。
範例 2：為 take 選擇集命名
為 Copper Harbor 第 2 集第 7 鏡的 take 選擇集準備檔名。
鏡頭背景：Captain Elian Ro 在碼頭上拿著裂開的指南針，霧在銅色燈塔後散開。
需要命名的檔案：三個從 Canvas 分支匯出的 take，其中一個因指南針跑偏被廢棄。
使用專案命名模式，不要把描述放進檔名。
輸出示例：
COPPER_E02_SH007_take_v01.mp4
COPPER_E02_SH007_take_v02_select.mp4
COPPER_E02_SH007_take_v03_rejected.mp4
說明：v03 被廢棄的原因寫進鏡頭描述或留在專案裡的筆記，不要寫進檔名。
鏡頭描述仍然有用，但它屬於 shot card。檔名保持可操作。
範例 3：重命名混亂匯出資料夾
使用已通過規範審計並重命名一個混亂的 Copper Harbor 匯出資料夾。
目前問題：檔名是 final.mp4、final2.mp4、good_vertical.mp4、cover_new.png 和 captions_real.srt。
已知映射：final.mp4 是 E01 SH010 master v02；final2.mp4 是 E01 SH010 master v03；good_vertical.mp4 是 E01 SH010 vertical v01；cover_new.png 是 E01 cover v02；captions_real.srt 是 E01 captions v01。
重新命名計畫：產生新檔名，保留原始檔案直到重新命名副本核對無誤，並把舊名到新名的對照記下來，讓團隊都能查到。
不要改變創意內容、提示詞、字幕或審核筆記。
如果某個檔案缺少足夠映射資訊，就標記出來，不要猜。
這才是命名清理的正確用法：映射已知事實，避免創意改動，並拒絕猜缺失來源。
檔案命名崩盤的方式
最常見的坑，是太早使用 final。檔案可以是創意已選、交付複查中、平台裁切版或已歸檔。final 只留給通過必要檢查的交付物。
另一個坑，是把整個故事塞進名稱。sad-captain-foggy-pier-compass-closeup-best-v2 看起來有幫助，但它會破壞排序，而且仍然漏掉審核狀態。故事詞放進 shot card。
團隊也會混用命名規範。一位創作者寫 E1S4，另一位寫 ep01-shot004，剪輯師寫 scene4。生成開始前先選一個模式。
第四個坑，是讓平台變體看起來像母版。直式裁切、方形裁切、帶字幕版和乾淨母版是不同交付物。變體欄位應該把差異說清楚。
常見問題
每個 AI 漫劇檔名應該包含哪些欄位？
使用專案、必要時的集數或段落、鏡頭 ID、資產類型、變體、版本和狀態。小專案可以刪掉不用的欄位，但每個變更檔案都應該有版本。
角色名應該放進檔名嗎？
通常不要。角色的身分已經在我的資產裡的資產上，鏡頭用 @ 引用就帶進來了，檔名不用重複寫一遍。用集數加鏡頭號代替（比如 E02_SH007），這樣排序更好，也更撐得住劇本重寫。
如何處理廢棄 take？
當它能解釋有用失敗時，保留一個廢棄檔案，用 rejected 命名，並把原因放進元資料。不要保留幾十個名字模糊的重複廢棄結果。
怎麼讓檔名保持短，又不丟上下文？
鏡頭描述、@ 資產引用，還有角色資產本身，都留在專案裡跟這個鏡頭連著。檔名只需要是個短柄——專案、集數、鏡頭、版本。
什麼時候建立命名規範？
在第一批正式生成前。製作後命名是清理；製作前命名是預防。把模式加入專案設定，讓每個提示詞、take、片段、字幕和封面都按同一條規則走。
如果舊檔案已經用了混亂名稱怎麼辦？
先把舊名到新名的映射整理成一份團隊都能看到的記錄，再動手改。只重新命名來源鏡頭明確的檔案。不確定的檔案標記待複查，不要編來源。
