为什么大部分文件名两周后就失效
糟糕的文件名在批错片段之前，看起来都不危险。导演评论 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 之外的文件——本地导出、还没绑到资产上的参考图——文件名只要能识别项目、集数、镜头和版本就够了。用 工作流程模板 把命名和制作流程绑在一起；同一批角色和地点需要长期连续性时，用 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、片段、字幕和封面都按同一条规则走。
如果旧文件已经用了混乱名称怎么办？
先把旧名到新名的映射整理成一份团队都能看到的记录，再动手改。只重命名来源镜头明确的文件。不确定的文件标记待复查，不要编来源。
