企业官网建设流程全解析

OpenMontage Cinematic 场景导演（Scene Director）指南：用 5 项场景要素与 Hero Frame 把情绪变成镜头计划

【免费下载链接】OpenMontageWorld's first open-source, agentic video production system. 12 production pipelines, 100+ tools, 700+ agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage

Cinematic 流水线的场景导演（Scene Director）阶段，负责把「情绪」翻译成「画面计划」：它为脚本中的每一个节拍（beat）产出可校验的scene_plan场景清单，定义 Hero Frame、转场、画幅、叠加层与逐镜头的摄影语言。本文以 skills/pipelines/cinematic/scene-director.md 为主干，结合仓库中的 scene_plan.schema.json、cinematic.yaml 与 video-gen-prompting.md 等源码依据，完整展开从输入准备、五方面场景要素（5-Aspect Scene-Plan Checklist）到质量门与人工审批 Checkpoint 的实操细节。读完本文，你将掌握如何编写一套「每个 Hero Frame 都可在五个维度上被精确描述、可被下游资产与合成阶段直接消费」的场景计划。

何时使用

你正在决定每一个 Cinematic 节拍（beat）将如何被呈现与衔接——这是「情绪变成视觉计划」的地方。场景导演不负责写台词、选素材或剪辑，而是输出一张可执行、可校验的「镜头蓝图」：从开场画面到揭示画面，再到收尾画面，每一个节拍都必须有明确的场景处理方案（scene treatment）与资产路径（asset path）。

前置条件

场景导演阶段不是从零开始的，它必须消费上一阶段产出的权威真源（source truth）。原文档给出的前置条件如下：

这些前置条件与流水线清单 cinematic.yaml 中的scene_plan阶段定义完全对应：该阶段required_artifacts_in: [script]、optional_artifacts_in: [proposal_packet]、produces: [scene_plan]，且tools_available恰好是frame_sampler与scene_detect两个工具。

从源码看，frame_sampler（tools/analysis/frame_sampler.py）提供四种抽帧策略：interval（按秒间隔）、count（按帧数）、timestamps（按指定时间戳）、scene_guided（按镜头边界），它包装 FFmpeg 用于从源素材中提取代表性画面，供场景导演确认画面质感、检查重构（reframing）可行性。scene_detect则负责识别源素材中的镜头切点，两者共同支撑「源素材驱动场景（source-led scenes）」的决策。

处理流程

1. 让 Hero Frames 显式化

每一部 Cinematic 作品都需要少数几个令人难忘的画面，场景导演必须直接把它们定义出来，而不是留给下游「猜」：

• 开场画面（opening image）；
• 揭示画面（reveal image）；
• 收尾画面（final image）；
• 任何标题卡（title-card）的 Hero 时刻。

在 scene_plan.schema.json 中，每个场景都有hero_moment布尔字段（默认false），语义为「本场景是否是整支视频的视觉峰值，值得额外关注」；与之配套的还有shot_intent（这个镜头为什么存在）与narrative_role（在叙事结构中扮演的角色，枚举含establish_context、build_tension、deliver_payload、emotional_beat等）。也就是说，Hero Frame 不是靠「感觉」标出来的，而是要把hero_moment: true、明确的shot_intent与叙事角色一并写入场景计划。

2. 源素材驱动的场景保持优先

如果存在源素材，就让它承载全片。生成式插片（generated inserts）或文字卡片只应服务于转场、强调或补缺（missing coverage），绝不能主导时间线。在 schema 层，这一原则通过required_assets[].source枚举落实：每个所需资产必须显式标注来源为generate（生成）、source（源素材）、provided（提供）或record（录制）之一（见 scene_plan.schema.json）。下游 asset-director 阶段会依据这一标注把「源素材选择」与「支撑资产」严格分离（见 cinematic.yaml 的 review_focus：「Source selects and support assets are clearly separated」「Optional generated inserts stay limited and justified」）。

3. 限制转场词汇表

从一个小的转场集合中挑选：

• 硬切（hard cut）；
• 淡入黑（fade to black）；
• 慢溶解（slow dissolve）；
• 克制的推近或 punch-in。

转场类型过多会毁掉情绪。这一点与风格 playbook 的约束机制遥相呼应：在 playbook.schema.json 中，motion.transitions是数组且minItems: 1，每个场景的transition_in/transition_out字段（见 scene_plan.schema.json）也应从这套受控集合中取值。例如推荐给 Cinematic 流水线的 flat-motion-graphics.yaml 只声明了[wipe-left, zoom-in, morph, cut]四种转场，并配套transition_duration_seconds: 0.3的时长规则——这就是「限制转场词汇」的落地样本。

4. 用元数据承载视觉规则

推荐的场景计划元数据键（写入metadata字段，schema 中metadata为开放对象，见 scene_plan.schema.json）：

• hero_frames— 哪些场景是 Hero Frame 及其清单；
• transition_rules— 全片转场策略与使用约束；
• aspect_ratio_rules— 画幅比例规则（横竖版、遮幅处理）；
• title_card_rules— 标题卡的使用时机与样式约束；
• support_insert_rules— 支撑插片（generated inserts）的准入条件。

把视觉规则集中放在元数据里，而不是散落在每个场景描述中，能让下游 edit-director（剪辑决策）与 compose-director（合成渲染）阶段拿到一份全局一致的视觉契约。

5. 5-Aspect 场景计划清单（核心）

每一个场景节拍——尤其是每一个 Hero Frame——都必须指定全部五个方面。Cinematic 依赖少数几个令人难忘的画面；模糊的 Hero Frame 规格是最常见的失败模式，会产生不可预测的模型输出。将某一项标注为 N/A 是允许的，但必须显式说明（例如「无主体——环境空镜」）。静默省略是被禁止的。

这五个方面直接继承自 video-gen-prompting.md 中定义的 OpenMontage 规范五要素骨架（该文档同时给出了各模型的提示词长度甜区与「短提示词=更多创作自由度、长提示词=更多控制力」的权衡）：

1. Subject（主体）— 类型 + 关键视觉属性；若存在多个主体，如何区分彼此。对于 Hero Frame，主体身份必须跨镜头逐字锚定（identity anchored verbatim across shots）。这是为了防止生成模型在切镜头后丢失角色一致性——video-gen-prompting.md 明确警告「模型会在剪切后丢失角色身份，除非你在每个镜头中重复陈述」，并给出示例：「Aang — bald, blue arrow tattoo on forehead, orange-and-yellow robes — plants his staff. … Aang — bald, blue arrow tattoo on forehead, orange-and-yellow robes — turns to camera.」代词与「同一个角色」这类说法无效。
2. Subject Motion（主体运动）— 按时间顺序排列的动作；主体↔客体 / 主体↔主体之间的交互。多个事件时应遵循时间顺序；时间顺序无关时遵循显著度顺序（人类先于物体，最大/最居中者优先）。
3. Scene（场景）— 叠加层（单独列出！）+ POV + 设定 + 时间段 + 场景动态。POV 原语包括 first-person、drone、over-the-shoulder、top-down oblique、dashcam、objective/neutral（默认）等（见 video-gen-prompting.md）。
4. Spatial Framing（空间构图）— 景别（shot size）+ 画内位置（position-in-frame）+ 纵深（前景/中景/背景 FG/MG/BG）+ 相对机位高度；以及这些要素在整个节拍中如何变化。
5. Camera（摄影机）— 播放速度 → 镜头畸变 → 机位高度 → 角度 → 焦点/景深 → 稳定度 → 运动。

其中摄影机维度的顺序就是 video-gen-prompting.md 给出的播放速度原语（time-lapse、fast-motion、slow-motion、stop-motion、speed-ramp、time-reversed）与「static 是严格静止」的告诫：static 镜头要求零移动、零焦点变化、零变焦，一旦有任何一项发生，就必须改选具体的运动原语。

与 schema 的映射。五个方面并非抽象口号，在 scene_plan.schema.json 中可被结构化为shot_language对象，其枚举约束为：

• shot_size：extreme_wide / wide / medium_wide / medium / medium_close / close_up / extreme_close_up / over_shoulder / insert / establishing；
• camera_movement：static / pan_left / pan_right / tilt_up / tilt_down / dolly_in / dolly_out / tracking_left / tracking_right / crane_up / crane_down / handheld / steadicam / whip_pan / orbital / zoom_in / zoom_out / rack_focus；
• lens_mm：仅14 / 24 / 35 / 50 / 85 / 135 / 200；
• lighting_key：high_key / low_key / natural / golden_hour / blue_hour / tungsten_warm / neon / silhouette / rim_lit / volumetric / overcast_soft；
• depth_of_field：shallow / medium / deep；
• color_temperature：cool / neutral / warm / mixed。

注意 schema 中shot_language设定了additionalProperties: false，因此描述镜头语言时必须使用上述受控词汇；同时 video-gen-prompting.md 提醒摄影机运动要分组书写，避免模型混淆：平移（translation，如 dolly in/out）≠ 旋转（rotation，如 pan/tilt）≠ 纯镜头变化（lens-only，如 zoom/rack focus），且「dolly ≠ zoom、pan ≠ truck」。

Overlays 特别提示。叠加层（titles、subtitles、HUD、watermarks、framing graphics、lower-thirds、name plates、end-tag cards）不属于场景前景/中景/背景的纵深轴。必须在场景元数据中以overlays: [...]单独列出其内容与摆放位置。永远不要把叠加层描述为「在前景（in the foreground）」——那会同时混淆下游工具与任何重新分析成片的视频理解模型。这正是 video-gen-prompting.md 中「Overlays Are Not Scene Depth」原则在场景计划层的强制落地。

一个符合五要素与 schema 约束的 Hero Frame 示例（示意结构，展示五个方面如何逐字显式化）：

{ "id": "beat-04-reveal", "type": "generated", "description": "Reveal hero frame — protagonist steps into golden-hour light", "start_seconds": 24.0, "end_seconds": 31.0, "script_section_id": "script.sec.03", "hero_moment": true, "shot_intent": "Deliver the emotional payload of the reveal beat", "narrative_role": "deliver_payload", "framing": "medium_wide, subject left-third, MG anchored, transitions to close_up in final third of beat", "movement": "slow dolly_in, then rack_focus from BG city to subject face", "transition_in": "slow dissolve", "transition_out": "hard cut", "overlay_notes": "none in this beat; title card deferred to beat-06", "shot_language": { "shot_size": "medium_wide", "camera_movement": "dolly_in", "lens_mm": 35, "lighting_key": "golden_hour", "depth_of_field": "shallow", "color_temperature": "warm" }, "texture_keywords": ["anamorphic", "grain"], "required_assets": [ { "type": "video", "description": "Generated reveal insert, protagonist — red jacket, grey beanie — entering frame", "source": "generate" } ], "metadata": { "hero_frames": true, "subject_identity": "protagonist — red jacket, grey beanie, worn leather boots" } }

6. 质量门（Quality Gate）

场景导演阶段的自检清单，也是下游 checkpoint 评审的硬性标准：

• 每个节拍都有场景处理方案（scene treatment）；
• Hero Frame 可被识别，且五个方面全部完整指定；
• 支撑插片（support inserts）有充分理由；
• 叠加层记录在overlays:下，绝不混入纵深/构图描述；
• 全片视觉语言保持一致。

这一清单与 cinematic.yaml 中scene_plan阶段的review_focus逐条对应：「Hero frames and reveal moments are defined」「Source-led scenes remain primary when source media exists」「Transition and aspect-ratio choices support the mood」，而success_criteria要求「Schema-valid scene_plan artifact」且「Every beat has a scene treatment and asset path」——也就是说，仅凭描述合格还不够，产物必须通过 JSON Schema 校验且每个节拍都有资产路径，才允许进入下一阶段。

常见陷阱

• 把标题卡当作填充物（Using title cards as filler）——标题卡应与标题卡规则（title_card_rules）一致，服务于叙事而非凑时长；
• 把生成插片当成主线故事却不明说（Treating generated inserts like the primary story without saying so）——若插片是主线，必须在计划中显式声明，否则会误导下游资产与合成阶段；
• 为每个节拍都规划花哨转场（Planning flashy transitions for every beat）——转场词汇必须克制，数量一多情绪就被稀释。

Gate Reminder（强制性约束）

场景导演是一个以人工审批为默认的关卡（human_approval_default: true，见 cinematic.yaml 中checkpoint_required: true、human_approval_default: true）。评审通过后，必须：

1. 以status="awaiting_human"落盘 checkpoint（checkpoint 状态枚举见 checkpoint.schema.json：completed / failed / awaiting_human / in_progress，其中awaiting_human正是人工审批挂起状态；human_approval_required与human_approved字段记录审批需求与结果）；
2. 呈现摘要——Backlot 看板会渲染该场景计划产物（artifact）；
3. 结束你的回合（END YOUR TURN）。不得在同一个回复中开始下一阶段。

审批是逐关卡生效的——先前某关卡的「继续」授权不覆盖本关卡。换言之，即使前面的 research / proposal / script 关卡都通过了人工审批，场景计划关卡依然需要独立的一次人工放行。这与 checkpoint.schema.json 中stage字段「在运行时依据 pipeline manifest 的 stage 列表校验」的设计一致：每个阶段一个 checkpoint，状态互不替代。

与上下游阶段的衔接

场景导演不是孤岛。在 Cinematic 流水线中（见 cinematic.yaml）：

• 上游：script阶段产出的script（节拍图）是必需输入，proposal_packet（提案包）是可选输入，提供情绪弧线与渲染方向；
• 下游：scene_plan是assets阶段（资产清单）的必需输入——asset-director 依据场景计划中的required_assets[].source区分源素材选择与生成资产；随后edit阶段（剪辑决策）同时消费scene_plan与asset_manifest，按场景计划的start_seconds/end_seconds与转场规则排出成片时间线；最终compose阶段按shot_language、texture_keywords与 playbook 的视觉规则完成合成与调色。

在整个流程中，场景导演始终以「少数几个值得记忆的画面」为锚点：模糊的 Hero Frame 规格会产生不可预测的模型输出，而清晰、显式、五个维度齐全的场景计划，则是让后续资产、剪辑、合成与人工审批都能顺畅对齐的关键交付物。

【免费下载链接】OpenMontageWorld's first open-source, agentic video production system. 12 production pipelines, 100+ tools, 700+ agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage