Seedance 2.0 Prompt JSON Schema 全解：结构化提示规划与序列状态校验实战-平芜编程栈

AI 技能
AI 评测
提示工程
人工智能
媒体生成

【免费下载链接】seedance-2.0

Comprehensive production pipeline for quad-modal AI filmmaking with Seedance 2.0

项目地址：https://gitcode.com/gh_mirrors/se/seedance-2.0

导读

本文面向希望把 Seedance 2.0 提示词工程接入自动化管线的开发者，完整讲解仓库中references/json-schema.md定义的 Prompt JSON Schema 与 V6 序列状态 Schema 族：从顶层字段的枚举取值、规划元数据与最终自然语言提示的分层原则，到schemas/目录下五份机器可校验 Schema 的结构、条件约束与配套验证器实现。读完本文，你将能够用同一份 JSON 规划结构承载模式、参考、分镜、连续性锚点、色彩、字幕与交付信息，并借助scripts/schema_check.py、scripts/project_state_check.py与scripts/continuity_chain_check.py让序列级数据资产可校验、可追溯。

一、Schema 在管线中的定位：规划层与生成层分离

Seedance 2.0 是一条覆盖文生视频（t2v）、图生视频（i2v）、视频生视频（v2v）、参考生视频（r2v）、首尾帧转换（flf2v）、剪辑（edit）、延长（extend）、音频驱动（audio-led）等多模态生成能力的生产管线。JSON Schema 在其中的角色不是"提示词模板"，而是规划层的稳定契约：

当用户需要结构化输出、或自动化管线需要稳定字段时，使用 JSON 包装（wrapper）记录规划意图；
最终交给模型的提示词仍然是自然语言——references/json-schema.md明确强调："The JSON wrapper is for planning. The final prompt still needs to read naturally"（JSON 包装用于规划，最终提示词仍需读起来自然）。

这意味着所有 JSON 结构都属于规划工件（planning artifact），而不是生成请求本身。真正落到生成环节的只有final_prompt（顶层 Schema）或natural_language_prompt（prompt-spec）字段承载的自然语言文本。

二、顶层 Prompt JSON Schema：字段与枚举全解

references/json-schema.md给出的顶层规划结构如下（完整继承自原文档）：

{ "mode": "t2v | i2v | v2v | r2v | flf2v | edit | extend | audio-led", "duration": "string", "aspect_ratio": "string", "references": [ {"tag": "Image1", "role": "identity | product | pose | environment | style | first_frame | last_frame | reference_image"}, {"tag": "Video1", "role": "motion | camera | pacing | blocking | source_clip | reference_video"}, {"tag": "Audio1", "role": "voice | rhythm | ambience | music | tempo | reference_audio"} ], "characters": [], "production": { "phase": "brief | preproduction | generation | review | post | localization | delivery", "role": "director | dp | producer | editor | colorist | sound | localization | qc", "delivery_surface": "web | broadcast | social | theatrical | client_review | archive", "approval_owner": "" }, "shot_list": [ { "shot_id": "S01_SH01", "purpose": "establish | reveal | demonstrate | emotional_turn | end_card", "shot_contract": "shot size, angle, lens feel, camera move, endpoint", "start_frame": "", "end_frame": "", "risks": [] } ], "continuity_anchors": { "character": [], "product": [], "wardrobe": [], "props": [], "location": "", "screen_direction": "", "eyeline": "", "lighting_state": "", "audio_state": "" }, "scene": "", "camera": "", "motion": "", "lighting": "", "style": "", "audio": "", "color_pipeline": { "look_intent": "", "working_assumption": "", "output_transform": "SDR Rec.709 | HDR PQ | theatrical | social", "show_lut_or_cdl_notes": "", "qc_notes": [] }, "subtitle_plan": { "subtitles": false, "sdh": false, "forced_narrative": false, "dubbing": false, "textless_required": false, "languages": [] }, "audio_deliverables": { "full_mix": true, "stems": [], "m_and_e": false, "loudness_target": "", "sync_cues": [] }, "delivery": { "frame_rate": "", "resolution": "", "aspect_ratio": "", "safe_area": "", "version_name": "", "qc_checks": [] }, "safety_notes": [], "final_prompt": "" }

2.1 mode：生成模式枚举

mode决定了本次任务的生成入口，是唯一同时出现在顶层 Schema 与clip-contract、prompt-spec等序列 Schema 中的核心维度。取值包括：

取值	含义
`t2v`	文本生成视频（Text-to-Video）
`i2v`	图片生成视频（Image-to-Video）
`v2v`	视频生成视频（Video-to-Video），常用于序列衔接
`r2v`	参考内容生成视频（Reference-to-Video）
`flf2v`	首帧/尾帧转换生成视频（First-Last-Frame-to-Video）
`edit`	剪辑/编辑模式
`extend`	时长延长模式
`audio-led`	音频驱动模式

在仓库真实实例中，examples/sequence-airport-arrival/project-state.json的 clip_01 使用"generation_mode": "T2V"，而 clip_02、clip_03 使用"generation_mode": "V2V"并携带source_clip_tag——这与顶层 Schema 中references的role枚举相互印证：Video1可承担source_clip | reference_video等角色，source_clip正是 v2v 序列衔接的载体。

2.2 references：多模态参考角色

references数组按模态（图片/视频/音频）分组，每个条目用tag定位素材、用role声明用途：

图片（Image）：identity（身份）、product（产品）、pose（姿态）、environment（环境）、style（风格）、first_frame（首帧）、last_frame（尾帧）、reference_image（通用参考图）；
视频（Video）：motion（运动）、camera（运镜）、pacing（节奏）、blocking（走位调度）、source_clip（源片段）、reference_video（通用参考视频）；
音频（Audio）：voice（人声）、rhythm（节奏）、ambience（环境声）、music（音乐）、tempo（速度）、reference_audio（通用参考音频）。

2.3 production：制片信息块

production四个字段把导演/制片语境下沉为结构化元数据：

phase：brief | preproduction | generation | review | post | localization | delivery，标识当前所处制作阶段；
role：director | dp | producer | editor | colorist | sound | localization | qc，标识当前视角（导演、摄影指导、制片、剪辑、调色、声音、本地化、质检）；
delivery_surface：web | broadcast | social | theatrical | client_review | archive，交付面；
approval_owner：审批责任人，用于多人协作流程中对齐签字权。

2.4 shot_list：分镜契约

shot_list数组把镜头语言写成可审计的契约条目：

shot_id：镜头编号，如S01_SH01；
purpose：镜头意图，枚举establish（建立）、reveal（揭示）、demonstrate（演示）、emotional_turn（情绪转折）、end_card（片尾卡）；
shot_contract：自由文本但应按固定语义书写——景别（shot size）、角度（angle）、镜头质感（lens feel）、运镜（camera move）、落点（endpoint）；
start_frame/end_frame：首尾帧标记，配合flf2v模式使用；
risks：该镜头的风险清单。

2.5 continuity_anchors：连续性锚点

连续性锚点记录跨镜头必须保持不变的要素，是序列项目防漂移的核心：

character（角色）、product（产品）、wardrobe（服装）、props（道具）、location（地点）、screen_direction（银幕方向，如"左到右移动"）、eyeline（视线方向）、lighting_state（光照状态）、audio_state（音频状态）。

这个字段与examples/sequence-airport-arrival/project-state.json中每个 clip 的continuity_locks一一对应——机场实例把canonical_identity_id、wardrobe、travel_direction、vehicle_identity、creased paper airline tag、persistent_environment列为锁，正是锚点思想的序列化落地。

2.6 镜头语言五要素

scene（场景）、camera（运镜）、motion（运动）、lighting（光照）、style（风格）五个顶层字段承载单镜头的自然语言描述，与仓库references/下 cinematography-shot-language.md、directing-engine.md 等导演语言文档互补。

2.7 color_pipeline：色彩管线

look_intent：调色意图；
working_assumption：工作假设（如拍摄/素材色彩空间假设）；
output_transform：输出变换，枚举SDR Rec.709 | HDR PQ | theatrical | social；
show_lut_or_cdl_notes：LUT/CDL 说明；
qc_notes：调色质检备注。与仓库 color-pipeline-aces.md 描述的色彩交付约束一致。

2.8 subtitle_plan：字幕与本地化

五个布尔开关加一个语言列表：subtitles（普通字幕）、sdh（听障字幕）、forced_narrative（强制叙事字幕）、dubbing（配音）、textless_required（是否要求无字版），以及languages（目标语言数组）。对应仓库的 subtitles-localization.md 多语言本地化实践。

2.9 audio_deliverables：音频交付物

full_mix：完整混音（默认true）；
stems：分轨列表；
m_and_e：音乐与效果声（M&E）轨；
loudness_target：响度目标（如 -23 LUFS，具体以交付面为准）；
sync_cues：同步点提示。与 audio-post-delivery.md、sync-budget-protocol.md 构成音频交付体系。

2.10 delivery：交付规格

frame_rate（帧率）、resolution（分辨率）、aspect_ratio（宽高比）、safe_area（安全区）、version_name（版本名）、qc_checks（质检项）。可在生成前声明，也可作为后期交付的核对清单。

2.11 safety_notes 与 final_prompt

safety_notes记录安全与合规备注；final_prompt是最终真正提交给模型的自然语言提示词——规划结构到此收敛为一段可读文本，与仓库 seedance-prompt、seedance-pipeline 技能所倡导的"自然语言提示词"实践一致。

2.12 使用原则：哪些字段进提示词，哪些只作交接元数据

原文档给出的铁律：production、shot-list、continuity、localization、audio、color、delivery 字段应作为交接元数据（handoff metadata）保存在规划层，不要全部塞进提示词。理由很实际：提示词越长、语义越拥挤，模型对核心动作的执行越不稳定；把制片/交付信息留在 JSON 层，可以让final_prompt保持聚焦、自然、可读。

三、V6 序列状态 Schema 族：schemas/ 下的五份机器校验契约

references/json-schema.md指出：V6 在schemas/目录下增加了机器可校验的状态夹具（machine-valid state fixtures）。五份 Schema 分工明确，全部采用 JSON Schema Draft 2020-12：

Schema 文件	职责
project-state.schema.json	项目状态：故事、场景、节拍、片段血缘、take 历史、正典修订、参考注册表
clip-contract.schema.json	当前片段的生产任务契约
take-review.schema.json	已观测起止状态、接受的偏差、完成的节拍、拒绝/修复裁决
prompt-spec.schema.json	内部提示词编译元数据
generation-run.schema.json	合成基准与本地运行记录

3.1 project-state.schema.json：整部序列的"总账"

这是五个 Schema 中结构最重的一份，required列表包含 18 个顶层字段：schema_version、state_revision、project_id、project_mode、surface、clip_budget_sec、prompt_budget、story、world_bible、reference_registry、scenes、beats、clips、take_history、current_clip_id、canon_revision、updated_at。

关键设计点：

版本与修订：state_revision、canon_revision均为minimum: 1的整数，schema_version为字符串——仓库实例中为"6.6.0"；
project_mode：枚举standalone_clip | sequence_project，区分单片段与序列项目；
故事层 story：logline、story_promise、objective、initial_condition、final_outcome、target_duration_sec、tone、medium八个必填字段；
场景层 scene：arc_position枚举open | rising | turn | climax | release，max_chain_depth约束在0–3，status枚举planned | current | completed | omitted | replaced；
节拍层 beat：status同场景枚举，dependencies声明节拍依赖；
take_history_item：verdict枚举accept | accept_with_deviation | repair | reject，evidence上限 4096 字符，数组上限 4096 条；
血缘约束（allOf）：当sequence_index == 1时parent_clip_id必须为null，否则必须提供非空parent_clip_id；当status为accepted/accepted_with_deviation时observed_end_state必须为非空对象（minProperties: 1），当status为rejected时observed_end_state必须为null。

3.1.1 authoring_state：导演读解的规范化

project-state 与 clip-contract 共享authoring_state定义，用oneOf在两类"导演读解（Director's Read）"之间二选一：

narrative_authoring_state：叙事读解，必填dramatic_function（戏剧功能）、turn（转折）、pov（视角）、power_shift（权力转移）、hidden_want_objective（隐藏欲望目标）、obstacle_tactic（障碍策略）、subtext_contradiction（潜台词矛盾）、visible_suppressed_behavior（可见的压抑行为）、non_transferable_detail（不可转移细节）、non_transferable_detail_provenance（source_bound | authored_choice）、non_transferable_detail_source、stock_solution_refused（拒绝的套路化方案）、value_before、value_after、prompt_carriers（提示词载体，至少 1 条、去重）；
non_narrative_authoring_state：非叙事读解，仅utility_intent（实用意图）与non_narrative_refusal（非叙事拒绝）两行。

其中visible_one_line_text定义值得注意：它是一条"必须含可见字符、不得含换行"的单行文本约束，通过一个巨大的 Unicode 正则把纯标点、纯空白、控制字符排除在外。non_transferable_detail_provenance与non_transferable_detail_source还有联动约束：source_bound时source必须匹配@标识符 [行号]、[引用]、URL 或file:/ref:/evidence:前缀；authored_choice时source必须为null。

3.1.2 血缘可追溯：authoring_state_sha256

contract_authoring_state_snapshots（project-state）与authoring_state_provenance（clip-contract）用{project_id, clip_id, canon_revision, state_revision, authoring_state_sha256}五元组做指纹，sha256正则约束为^[0-9a-f]{64}$，additionalProperties: false。这意味着契约与其 authoring_state 的快照可以被哈希审计——机场实例中 clip_01 的快照哈希d71f3ea0...与examples/sequence-airport-arrival/clip-01-contract.json内嵌的authoring_state_provenance完全一致，正是这条链路的真实佐证。

3.2 clip-contract.schema.json：单个片段的生成任务契约

对比 project-state 的 clip 定义，clip-contract 是"单片段视角"的精简版，必填 17 个字段，并新增shot_structure枚举：compact_single_take | phased_single_take | dense_multishot | first_last_frame_transition | video_edit_contract——对应仓库 examples/golden-prompts 中的五类金句提示词模式。其allOf条件约束与 project-state 中 clip 的约束逻辑一致（首片段父节点为空、接受态必须有观测尾态、拒绝态尾态为 null）。

3.3 take-review.schema.json：观测与裁决记录

这是"回放核查"的数据契约，必填 17 个字段，additionalProperties: false（不允许多余字段混入）：

source_status枚举generated | reviewed | accepted | accepted_with_deviation | repair | rejected；
verdict枚举accept | accept_with_deviation | repair | reject；
completed_beats/incomplete_beats/unexpected_completed_beats三组节拍清单，区分"完成、未完成、意外完成"；
observation_confidence枚举low | medium | high；
uncertainties与requires_user_confirmation表达观测的不确定性与是否需人工确认；
条件约束：verdict == reject时accepted_deviations必须为空数组（maxItems: 0）——拒绝态不容忍"已接受偏差"。

仓库真实记录examples/sequence-airport-arrival/clip-01-take-review.json展示了完整用法：clip_01 实测停在门前两步，completed_beats为["beat_terminal_exit"]，incomplete_beats为["beat_reach_car"]，continuity_breaks记"planned endpoint not reached"，accepted_deviations记"final frame is two steps before the door"，最终裁决accept_with_deviation——这与 project-state 中 clip_01 的status: "accepted_with_deviation"、accepted_deviations、open_motion_vectors完全闭环。

3.4 prompt-spec.schema.json：编译元数据

记录内部提示词编译的输入输出，必填 10 个字段，关键枚举：

sequence_relation：standalone | sequence_first_clip | seamless_continuation | intentional_next_shot | bridge_between_known_states | repair_tail | reanchor_after_drift——这七个取值精确描述了片段在序列中的关系，其中seamless_continuation（无缝续接）、repair_tail（修复尾部）、reanchor_after_drift（漂移后重新锚定）直接对应序列漂移治理场景；
opening_state_source：planned_start_state | observed_end_state | user_supplied_final_frame | source_clip——声明开场状态来源；
completed_beat_exclusions/reserved_future_exclusions：从已完成节拍与保留节拍中提取的"禁写区"，防止提示词重放旧内容或提前泄漏未来内容；
natural_language_prompt：最终自然语言提示词（minLength: 1）。

仓库夹具 validation/fixtures/prompt-spec.valid.json 展示了seamless_continuation的完整写法：opening_state_source: "observed_end_state"，completed_beat_exclusions排除"下电梯、查航班牌"，reserved_future_exclusions排除"走出航站楼、上车"，自然语言提示词明确要求"不重放旧节拍、不离开航站楼"。

3.5 generation-run.schema.json：运行记录

用于合成基准（synthetic benchmark）与本地运行审计，必填 11 个字段：run_id、project_id、clip_id、surface、prompt_version、input_mode、reference_tags、prompt、result_status、is_synthetic_fixture等。result_status枚举not_run_fixture | submitted | generated | reviewed | accepted | rejected，其中not_run_fixture专门标记合成夹具——仓库以 validation/fixtures/generation-run.valid.json 作为该 Schema 的合法实例。

四、Schema 的机器执行：schema_check.py 与 schema-instances.json

光有 Schema 定义还不够——仓库用 scripts/schema_check.py 让 Schema真正以 Schema 的身份执行，而不是靠 Python 里重复声明字段：

清单强制覆盖：读取 validation/schema-instances.json，schemas/下每个.schema.json必须在instances中声明至少一个合法实例，否则报错——"新增 Schema 而不带证明其可接受的实例，是不可能的"；
引用审计：reference_audit遍历$ref/$dynamicRef，只跟踪 Draft 2020-12 的 schema 值关键字（allOf、anyOf、oneOf、properties、$defs等），把字面数据（const、enum、examples里的内容）与活跃引用区分开；外部$ref一律禁止（refuse_schema_retrieval直接抛错，fail-closed）；
严格数字类型：通过type_checker重定义integer/number，拒绝把浮点数当整数、拒绝把1e2之类伪装成普通数字的写法（复用 scripts/strict_json.py 的is_json_number/json_integer）；
实例校验：对清单中每个实例用Draft202012Validator+FormatChecker执行iter_errors，按 JSON Pointer 输出精确诊断路径；
退出码：成功打印Schema check passed: every schema executed against its declared instances.；缺少依赖时（jsonschema未安装）提示按 requirements-validation.lock 安装并返回 2。

配套测试 tests/test_schema_check.py 覆盖了清单缺失、外部引用禁用、实例不合法等失败路径，保证校验器本身的行为契约稳定。

五、真实实例：机场到达序列的 Schema 闭环

examples/sequence-airport-arrival/project-state.json 是五份 Schema 的"合演"现场，三枚片段构成一条完整血缘链：

clip_01（T2V，phased_single_take）：status: accepted_with_deviation，观测尾态为"距车门两步"；open_motion_vectors记录"旅行者继续左到右走两步、摄影机继续横向跟拍"，handoff_requirements规定"clip_02 从距车门两步处开始、不得重放航站楼出口、不得从车内开始"——这些字段正是为下一条生成请求提供接续输入；
clip_02（V2V，seamless_continuation）：parent_clip_id: clip_01，source_clip_tag: "[Video 1]"，already_happened含beat_terminal_exit，this_clip_only含beat_reach_car、beat_enter_car，extension_depth: 1；
clip_03（V2V，provisional_next_shot）：parent_clip_id: clip_02，handoff_requirements明确"clip_02 被接受前不得定稿"，extension_depth: 2。

同一目录下 clip-01-contract.json 与 clip-01-take-review.json 分别承载契约与裁决，三份文件以clip_id、take_id、authoring_state_sha256互相咬合——这就是references/json-schema.md所说"machine-valid state fixtures"的完整含义。其余合法实例还包括 examples/sequence-observed-deviation（漂移前后状态）、examples/sequence-mixed-lane、examples/standalone-clip。

六、边界与最佳实践：Schema 能做什么、不能做什么

6.1 JSON Schema 的图级盲区

project-state 与 clip-contract 的$comment都直言了 JSON Schema 的结构性局限：无法表达片段 ID 唯一性、父节点存在性、自引用拒绝、父先于子排序、环路自由、父状态/端点可用性等跨记录图级语义。因此两份 Schema 都要求配合语义验证器使用：

scripts/project_state_check.py：校验项目状态记录的图级语义；
scripts/continuity_chain_check.py：校验连续性链条。

对应测试见 tests/test_project_state.py、tests/test_continuity_chain.py。实践原则是：Schema 负责"单记录结构合法性"，语义脚本负责"多记录图级一致性"，两者缺一不可。

6.2 规划层与生成层的纪律

顶层 JSON 与五份序列 Schema 都只是规划工件；
除非用户明确要求结构化输出，最终提示词保持自然语言；
production、shot_list、continuity、localization、audio、color、delivery作为交接元数据留在 JSON 层，不进提示词；
新增 Schema 必须先补合法实例并登记进validation/schema-instances.json，否则scripts/schema_check.py直接失败——这条约束保证"Schema 与示例永不漂移"。

结语

从references/json-schema.md的顶层 Prompt JSON Schema，到schemas/下的五份序列状态契约，再到scripts/schema_check.py的机器执行与机场序列的真实闭环，Seedance 2.0 把"提示词工程"升级成了"可规划、可校验、可追溯的提示词数据工程"。实践中记住三条主线即可：顶层 Schema 管单次生成的规划意图，序列 Schema 族管跨片段的状态与血缘，schema_check + 语义脚本管结构合法性与图级一致性——自然语言提示词负责表达，JSON 层负责纪律。

进一步阅读：序列状态的完整字段语义见 sequence-project-state.md，血缘契约设计见 lineage_contract.py，金句提示词模式见 examples/golden-prompts。