判断分镜与渲染该怎么分工，先看一条标准：这次改动是否需要人重新做一次内容上的选择。需要，就回到 DramaClaw 的分镜与素材层定稿并升版本；不需要，只是把已经定稿的内容生成出来，就交给流水线的渲染与导出环节自动推进。反复改、反复排队，通常不是渲染慢，而是两类动作混在同一个入口：把“改一句台词”当成“重跑一次导出”处理，队列里就塞满了本可在分镜阶段收口的事情。
适用场景：一条片子多轮修改、多人协作、多次交付。做法：改分镜、换配音、调节奏算内容决策，在 DramaClaw 里定稿并升版本；排队、渲染、导出算执行任务，交给流水线按定稿状态、交付时间、依赖关系排序。验证方式：版本号是否随内容改动递增、队列里有没有未定稿片段被优先跑、导出失败日志能否指回具体层。边界：规则定下后不要按项目临时改，否则追溯链会断；并发数与超时需结合本机环境确认。
分清哪些是内容决策、哪些是排队执行
内容决策的共性是需要人拍板，结果只能落在分镜与素材上；执行动作的共性是有确定输入，只等机器给出确定输出。把这两类动作用同一套“重跑”按钮触发，就会出现分镜还没定、导出已经排了三轮的情况。可以先按下面这张表把动作归位，再决定哪些按钮允许出现在哪个页面。
| 动作 | 归属 | 在哪里做 | 是否触发重跑 |
|---|---|---|---|
| 改分镜（镜头顺序、时长、字幕文案） | 内容决策 | DramaClaw 分镜层，改完定稿升版本 | 升版本后由流水线按新版本排一次 |
| 换配音（音色、语速、重录某句） | 内容决策 | 素材层音频条目，单独升版本 | 只影响引用该音频的片段 |
| 调节奏（整体时长、卡点、转场长度） | 内容决策 | 分镜层的时间轴参数 | 会牵连下游渲染，应一次改完再定稿 |
| 排队（决定谁先渲染） | 执行 | 流水线队列，人工只调优先级不改进度 | 不产生新版本 |
| 渲染（合成、转码中间片） | 执行 | 流水线 worker | 只消费已定稿版本 |
| 导出（封装、命名、落地到交付目录） | 执行 | 流水线导出步骤 | 失败可单独重试，不回改内容 |
一个可操作的检查点是：如果某个动作改完之后，你无法用一句话说明“观众看到的哪一秒变了”，那它多半属于执行动作，不该占用内容层的版本号。反过来，任何会改变画面或声音内容的操作，都不应该直接改文件覆盖旧版。
给分镜和素材建版本号规则
版本号要解决两件事：改动可追溯、旧版本可对比。建议把内容版本和产物版本分开编号——内容改动递增 v，同一内容重复导出递增 r。这样重新渲染一次不会污染内容版本，也就不会因为“导出失败重试”造出一堆看不出差别的新版本。
分镜：SB-E01-S014-v03 集-镜号-v内容版本
素材：AS-bgm-01-v02 类型-序号-v内容版本
：AS-vo-S014-v05 配音按分镜号挂载，便于定位
产物：RD-SB-E01-S014-v03-r02 引用分镜版本 + r 导出序号递增规则建议写死成三条：内容改动才加 v；同一版本重复渲染只加 r；批量重命名、换目录、改交付文件名都不加任何版本号。保留策略上，定稿版本长期保留，草稿保留最近若干个即可，数量放在配置里而不是靠人记得删。
{
"shot_id": "SB-E01-S014",
"content_version": 3,
"status": "locked",
"assets": [
{"id": "AS-vo-S014", "version": 5, "kind": "voice"},
{"id": "AS-bgm-01", "version": 2, "kind": "bgm"}
],
"render_hint": {"last_export": 2}
}文件与工程内要同步标记：文件名带版本后缀，工程元数据里写同一组字段，导出产物再内嵌一份。三者不一致时以工程元数据为准，并触发一次命名核对。判据很简单——拿一个文件名就能反查出它引用了哪版分镜、哪版配音。
渲染队列的先后顺序怎么定
队列排序建议用多级键，而不是给每项算一个加权分。加权分看着聪明，出问题时没人能解释为什么这条排在前面；多级键可以逐条对照。排序依据按重要性依次为：定稿状态、交付时间、依赖关系深度。
sort_keys:
- key: status # locked > approved > draft
order: [locked, approved, draft]
- key: due_at # 交付时间早的在前，无期限排最后
order: asc
- key: dep_depth # 依赖上游片段少的先跑，避免阻塞链
order: asc
- key: content_version # 同条件时新版本优先
order: desc三条判断依据要能落地：定稿状态取自工程元数据的 status 字段，不允许手工在队列里改成“高优先级”；交付时间用明确的截止时间，没有截止时间的片段排在有截止时间的后面；依赖关系指某片段需要等待上游素材（比如片头必须先出），依赖没解除的任务不应该占着 worker 空转。草稿片段不是不能跑，而是跑在最后，通常只用于预览。
导出失败时回退到哪一层重来
回退的关键是先定位失败位置，再决定回退层级，而不是一律从头再来。流水线日志里建议固定输出 stage 字段和退出码，按阶段判断：校验阶段失败多半是参数问题；转码或混音阶段报找不到轨道、时长对不上，多是素材问题；时间轴超界、镜头引用不存在，则要回到分镜层。
# 从导出日志里取出失败阶段
awk -F'stage=' '/stage=/{print $2}' export.log | tail -n 3
# 常见对应关系
# stage=validate -> 改导出参数（码率、分辨率、命名模板）后重跑导出任务
# stage=transcode -> 回素材层，替换或升版本对应音频/视频条目
# stage=mux -> 检查音轨时长与分镜时间轴是否一致
# stage=timeline -> 回分镜层，修镜头时长或引用后升内容版本判断路径可以按这个顺序走：先看日志最后一条 stage；如果是 validate，只改参数并重跑导出，不要动内容版本；如果是转码或混音失败，去核对素材条目的版本号是否与工程引用一致，不一致就回素材层升版本；如果日志指向时间轴或引用缺失，说明问题在分镜本身，回分镜层改完必须升 v。回退到某一层时，只重跑该层下游的任务，上游的定稿版本继续复用。
用一次真实项目跑通交接
规则写得再清楚，也要用一个完整项目验证一遍分工站不站得住。建议挑一条有配音、有音乐、需要至少两次交付修改的短片，从分镜定稿一路做到导出，过程中只做记录不临时改规则，事后再统一调整。
| 改动 | 落在哪一层 | 触发的重跑 | 事后判断 |
|---|---|---|---|
| 第 14 镜台词改写 | 分镜层，v3→v4 | 该镜渲染、整片导出 | 属于内容决策，合理 |
| 片尾音乐换成另一首 | 素材层，AS-bgm-01 v2→v3 | 仅片尾片段渲染 | 素材独立升版本，未牵连全片 |
| 导出码率调整 | 执行层，参数 | 仅导出任务，r 序号 +1 | 没有产生新内容版本 |
| 导出报音轨缺失 | 回素材层核对版本引用 | 该片段重渲染后重新导出 | 未从分镜层重来 |
复盘时看两个信号：同一片段因为内容决策被重跑多次，说明分镜阶段没有真正收口，需要在下一次项目里把定稿动作前置；队列里长期有草稿任务占住前面，说明优先级规则没生效或被人手工干预过。这两点都能从版本号和队列日志里看出来，不需要额外的评估工具。