catimation-video-workbench

name

catimation-video-workbench

description

Use when the user is on the CATIMATION 视频工作台 (video workbench) page, or asks to 批量出片 / 排成卡片 / 一次落板 / 铺满工作台 / 跑一批镜头; when a board of shot cards needs reordering, regenerating or version comparison; or when a 剧本 / 分镜表 / shot list / 制片包 should become a board. Load the catimation-video entry together with this one — this is a leaf under that entry, never a replacement for it. Symptoms: 该拆的镜头挤在一张卡里超了时长, 跨卡漂脸漂服装漂风格, 建完卡直接开跑, 拿批次摘要当验片.

视频工作台 · 整板出片

工作台是应用里的一块画布:一板卡片,每张卡是一次独立的上游调用(Seedance 或万相, 按卡片的 model 走)。它和聊天里 的 generate_video 出的是同一种片子、受同一套纪律约束,区别只在批量与可返工—— 卡片留在页面上,可以逐张改参数、重跑、比对版本。

本 skill 管这块界面上的纪律与字段。任务分级、素材 caps、QA 分档由 catimation-video 入口负责,写提示词由提示词底座负责,单镜镜头设计由 director-orchestrator 负责,镜头表怎么切、几镜、每镜多长由 shotlist-builder 负责 —— 本 skill 不重复它们,只在该交接的地方点名。

底座按卡片的 model 三选一(入口已经定过,这里只是提醒):2.5 → sd25-pe; 2.0 家族 → sd2-pe;wan3(万相 3.0)→ wan3-cinematic-30s。

本文说「底座」时,指的就是当前这张卡的 model 对应的那一个。 工作台的纪律 (素材绑定、多镜拆卡、资产门、摘要、跨卡锚点)与模型无关,三个底座上都成立。

剧 → 分段 → 卡片:工作台的三层

工作台按剧(project)→ 分段(board,界面文案「分段」,老数据叫「页面」)→ 卡片组织。 一部剧是一部片子;分段是剧里的一段成片单元(一集 / 一幕 / 一条 140s 的分 P);卡片是一镜。

• 所有 video_workbench_* 工具只作用于当前剧。 status 与写工具回带的 workbench 摘要都带 project {id,name,segments,cards},boards 只列这部剧的分段;别的剧对你不可见, 这与用户在界面上看到的隔离一致。
• 要看/换剧:video_workbench_list_projects(列全部剧与统计)→ video_workbench_switch_project(切过去,用户界面同步切换)。用户在界面切了剧, 你下一轮就在新剧里干活,不会往旧剧塞卡。
• 用户开一部新片子:video_workbench_create_project(自带一个空分段,返回 projectId + boardId),然后照常 video_workbench_add_tasks。
• 三层路标都要写。 剧:video_workbench_set_project_summary(≤60 字电报体, 「三集科幻短剧 · 赛博都市 · 主角林夏」,省略 projectId = 当前剧);分段: set_board_summary;卡片:set_card_summary。剧名常常是「未命名剧 3」,没有剧摘要, 下次面对八部剧只能逐个切进去看。接手或开新剧时就写,前提变了就刷新。
• 巡视用 status({ fields: "concise" })。 只回 id / 位置 / 状态 / 摘要 / 60 字提示词 / error,体积约为缺省 detailed 的三分之一。「进展怎样」「哪几张失败」「哪张是天台戏」 「先挑几张再动手」都用它;要改规格、要报成片地址,再对点名的几张拿 detailed 或 export。
• video_workbench_export 的 IR 带 projectId;apply 时若用户已切到别的剧,整份被拒 (conflict.reason = "project-mismatch")—— 重新 export,别 force。
• 批次完成推送里带「剧名 › 分段名」,汇报时照抄这个位置,用户按它去找成片。

几处点名了具体 skill(路径 A/B 与 cinematic-prompt-format、八大要素、 create-storyboard 制片包的 scenedance_prompt),那些名字带 seedance 只是历史 命名 —— 它们讲的是通用工艺,三个底座都适用。

真正与模型绑定的只有底座本身的语法(2.0 / 2.5 / 万相各一套),以及写死了模型 数字的技法叶子(如 seedance-video-craft 的 4–15s、9/3/3、21:9 —— 对万相全是错的)。

一板不止一张卡 = 有连续性 = shotlist-builder 自动在场,和提示词底座同一种 加载姿态,不需要用户说「分镜表」。用户手里没有剧本也照样载入——那时它的工作是 主动问出镜头表(讲什么 / 几镜 / 谁反复出现 / 规格),不是等本子。

When to Use

digraph when_to_use {
    "用户在工作台上操作 / 要批量出片?" [shape=diamond];
    "手里已有分镜表或制片包?" [shape=diamond];
    "手里有剧本 / 文字大纲?" [shape=diamond];
    "只出一条片?" [shape=diamond];
    "catimation-video-workbench" [shape=box style=filled fillcolor=lightgreen];
    "本 skill 的「整板落地」段" [shape=box style=filled fillcolor=lightgreen];
    "本 skill 的「剧本 → 镜头表」段" [shape=box style=filled fillcolor=lightgreen];
    "generate_video 直出" [shape=box];
    "先排故事板 (create-storyboard 或入口的标准级流程)" [shape=box];

    "用户在工作台上操作 / 要批量出片?" -> "只出一条片?" [label="否"];
    "只出一条片?" -> "generate_video 直出" [label="是"];
    "只出一条片?" -> "先排故事板 (create-storyboard 或入口的标准级流程)" [label="否"];

    "用户在工作台上操作 / 要批量出片?" -> "手里已有分镜表或制片包?" [label="是"];
    "手里已有分镜表或制片包?" -> "本 skill 的「整板落地」段" [label="是"];
    "手里已有分镜表或制片包?" -> "手里有剧本 / 文字大纲?" [label="否"];
    "手里有剧本 / 文字大纲?" -> "本 skill 的「剧本 → 镜头表」段" [label="是"];
    "手里有剧本 / 文字大纲?" -> "catimation-video-workbench" [label="否,边聊边建卡"];
}

vs. 直接 generate_video: 一条片、用户没提工作台 —— 直出更快,不必建卡。 工作台的价值在于多镜可比对、可逐张返工;单镜用它反而多一次跳转。

vs. 入口 catimation-video: 入口决定「这活多大、要不要故事板、QA 到哪一档」; 本 skill 只在决定之后管「怎么落在这块板上」。入口不会被本 skill 取代, 分级仍然先发生。

一张卡 = 一次生成 = 一个连续节拍

一张卡是一次上游调用,出一段几秒到几十秒的片子。 具体区间按 model 来,别写死: 2.0 家族 4–15s、2.5 是 4–30s、万相 3.0 是 2–30s(它还支持 -1 智能时长,由模型自己 定长度)。拿不准就读能力表,别按记忆填 —— 填超了要等一次网络往返才被上游拒。

这一段里可以只有一个镜头,也可以是一小段镜头流程 —— 那正是 sd2-pe 路径 B 的 「镜头流程」,写「镜头1 / 镜头2」进同一段是它支持的用法,不是违规。

判据是「这几镜是不是一个连续节拍」,不是数镜头号。

放同一张卡 —— 同一场景、同一组角色、连着演完的一段戏,总时长塞得进 4–15s。 一个搞笑反转(铺垫 → 递进 → 崩溃)拆成四张卡反而会断掉节奏,因为卡与卡之间不共享 上下文,表演的连贯性接不住。这种情况按路径 B 写成一段镜头流程。

拆成多张卡 —— 满足任一条就拆:

• 要独立控制:某一镜要单独重跑、换参考图、改时长、调顺序 —— 卡是控制粒度, 混在一段里就没法单独操作。
• 各镜素材不同:这镜用角色锚点、那镜用场景板,referenceImages 是整卡共享的, 塞不下两套。
• 时长超了:四个各要 5 秒的镜头压进一张 15s 的卡,每镜只剩 3.75 秒,全都演不完。 这才是「一个都不成立」的真实成因 —— 时长预算,不是镜头号。
• 跨场景/跨时空:换地方、换时间的两镜之间没有连续表演可言,分卡更干净。

拆开时卡片顺序即镜头顺序。卡片没有 shot_id 字段,别把 S01/S02 塞进 prompt 当结构。

反过来也别过度拆分:底座明写「不要把简单动作强拆成『镜头 1 / 镜头 2』」。 一个连续动作(起身并走向门口)是一镜,不是两镜。

跨卡纪律

每张卡都是独立的一次调用,卡与卡之间不共享上下文。所以:

• 人物锚点逐字复制进每一张卡的 prompt。 不写就漂 —— 别指望模型跨卡记住。 复用角色先在人像库锁 identity-hard 主锚,asset:// 句柄整板复用。
• 风格/调色/光位描述同样要逐卡带。 只在第一张卡写「赛博朋克夜景」, 第五张就会变成别的片子。
• 会变化的道具与场景状态,每一镜都要写明它此刻的样子。 椅子在这镜立着、下一镜 翻倒在地 —— 并行渲染没有任何机制传递这个,只有把「椅子已翻倒在地」写进下一镜的 prompt 才成立。人物锚点和风格是不变量逐卡复制;道具状态是变量逐卡交代。 两者都不能省。
• 规格逐卡确认。 卡片会自动补默认值(720p / 5s / 16:9),但有默认值不等于 用户确认过。没确认就先问,别让默认值替用户决定。
• 同一角色的年龄/状态变体要另立一套锚点。 「三年前的她」「受伤后的他」不是主锚 加一句形容词能推出来的:另出一套 identity-hard 锚点单独入库,用到它的卡把两套都 带上并写明关系(同一人,X 年前)。只带主锚,模型会当成现在的她;只带变体,跨镜就 断成两个人。
• 画面里嵌画面(屏幕内容、照片、镜子与反射)时,里层是那一镜的主体。 单独给它 参考图,并在 prompt 里写明它显示在什么东西上 —— 显示器、手机屏、相框、后视镜、 水面、暗玻璃。不写载体,模型会把里层内容当成场景里真实存在的人或物;载体决定了它 该有的画幅、眩光、衰减、清晰度和形变。

一张卡的 prompt 里要有什么

底座负责怎么写,本节只给落板前逐卡对照的清单。少一项就别上板。

八大要素(权威定义在 sd2-pe,缺项按它的默认策略补全并在交付时披露)。它讲的是 提示词该覆盖哪些内容,与用哪个底座无关 —— 换万相也要写清主体、镜头、光线、 音效,只是排版跟着 wan3-cinematic-30s 的六段时间轴走。

精准主体 + 动作细节 + 场景环境 + 光影色调 + 镜头运镜 + 视觉风格 + 画质 + 约束条件

外加工作台特有的三项 —— 单镜生成里不存在,只有整板才需要:

• identity-hard 主锚全文逐字复制(不变量)
• 风格 / 调色 / 光位描述逐字复制(不变量)
• 本镜的道具与场景状态(变量,例:椅子已翻倒在地)

多镜走路径 B,还要过 cinematic-prompt-format 的 12 项覆盖清单。两条路径都要过, 路径分流只决定展开程度,不豁免交付内容。这个结构叶子三个底座通用(它没有写死 任何模型参数,名字带 seedance 是历史命名)。

这是自检项,不是 prompt 模板。 标题、顺序、分段与散文形式都自由,只要八项内容 都在。写成八个小标题反而会让 Seedance 按标题断句,把一镜切成八段。

提问卡片:三张够了

一轮工作台任务可能有六件事要确认:方向、主锚、镜头表、规格、并行还是串行、音频。 一件一张卡逐个问,等于在渲染第一帧之前打断用户六次 —— 照章办事,却是糟糕的体验。

按这个配比合并:

1. 方向(单独一张)—— 创作决定,值得单独想,3–6 个具体方向并标推荐。
2. 镜头表 + 跑法(一张)—— 跑法(并行/串行)本来就是镜头表的属性,一起给。
3. 主锚 + 规格 + 音频(一张)—— 参数互不影响,合起来更省事;主锚放这张是因为 它通常只需要「就用这个 / 我另给」的确认。

用户说「你帮我拿主意」时,那不是让你别问,是让你带着答案去问。 每张卡都标出 推荐项并给一句理由,他点一下就过;但不要把没有默认答案的创作决定替他定掉 —— 镜头数、影像方向、角色长相,这三样错了整板都要重来。

超过三张卡,先问自己是不是在用提问代替判断。

建卡:边聊边建

用户没有现成分镜时,用 video_workbench_add_tasks 逐张建。默认只填不跑 —— 这不是限制,这正是补齐资产的窗口:建完卡再去锁锚点、排故事板、清点每镜素材, 齐了才 video_workbench_start。

一次最多写 5 张,多了分几次调。 不是省流量,是别让用户干等:一整板卡片挤在 一次调用里,就是几分钟的静默 JSON 生成,期间用户插不进话、页面上也什么都不出现; 切成小批则每批一落地就看得见,配 autoStart:true 还能让上一批开始渲染时你在写 下一批。

但「边聊边建」不等于没有镜头表。 只要这一板会不止一张卡,就先载入 shotlist-builder 把镜头表问出来再建卡 —— 它会带着选项问「讲什么 / 几镜 / 谁反复出现 / 规格」,而不是让你一张一张现编。没有镜头表就逐张建卡,建到第五张才 发现前四张的节奏不对,整板要重来。

提示词交底座工程化(Seedance 侧是八大要素 + 多模态绑定;万相侧是六段时间轴);镜头设计复杂时由入口在专业级 加载 director-orchestrator,本 skill 不代劳。

剧本 → 镜头表(用户给了本子但没有分镜)

这一段由 shotlist-builder 执行,本节只给工作台特有的落卡判据。拆镜的完整方法 (镜头行怎么分组成 4–15s 提示词、要不要出 HTML 总表)在那个 skill 里。

一句剧本 ≠ 一个镜头。 剧本按叙事写,镜头按可拍摄单元切,两者数量没有对应关系。 拆的时候按这三条判,别数句子:

• 一句里出现两个信息层就拆开。 一句同时交代「在哪儿」和「看见什么细节」时, 一个镜头给不全 —— 广角建立镜交代空间,再一个近景交代细节。
• 一句里出现两个主体的两个动作就拆开,尤其当第二个动作是情绪拐点时。压成一镜, 拐点那一下会被前一个动作稀释掉,两个都不成立。
• 单一核心动作就是一镜,不要为了凑数再切。一个连续动作(起身并走向门口)是一镜, 不是两镜。

拆出镜头表之后再决定怎么落卡 —— 镜头数和卡片数不是一回事。同一场景连着演完、 总时长塞得进一张卡的几镜,按路径 B 合成一段镜头流程放同一张卡,节奏更整;需要独立 重跑、素材不同、时长超了或跨场景的,才分卡。判据见上面「一张卡 = 一次生成 = 一个 连续节拍」。

拆完先把镜头表给用户过目 —— 这就是「开跑前四项清点」第 2 条的故事板,不是额外一步。 用 ask_user 把你的拆法连同镜头数选项一起给他(例:就按 6 镜 / 压到 4 镜 / 扩到 8 镜), 并说明每种的代价。镜头数是创作决定,不该由你独自拍板。

镜头表不是提示词,别直接搬进卡片。 镜头表回答「这一镜拍什么」,给用户看的; 卡片里的 prompt 是给模型的提交物,要有八大要素、物理参数、素材绑定。用户点头之后, 每一镜都要经底座工程化才落板 —— 把镜头表原文塞进 prompt,等于用散文去驱动 模型,画面十有八九不是你描述的那个。

镜头表定了、提示词工程化过了,再进下面的「整板落地」。

什么时候该交出去而不是自己拆: 用户要的是完整成片交付(含剧本打磨、配音、拼接、 正式交付版),那已经越过工作台的范围,按入口的分级表移交制片流程;需要逐镜连续性矩阵、 handoff 表这类导演级制片包时,走 create-storyboard 出包再回到「整板落地」。 本节只覆盖「本子已经够用,只差把它切成镜头」这一段。

整板落地:已有分镜 / 制片包

用户手里已有 shot list、分镜表或 create-storyboard 制片包时:

新建整板走 video_workbench_add_tasks(每次 ≤5,分批),按下表把 Shot Card 映射 成卡片字段。这是把分镜落进工作台的正路。

已有卡片的提示词不能用 apply 改 —— video_workbench_apply 是纯结构工具(新建 / 重排 / 删除 / 挪页),给已有卡带一段不同的提示词会被整份拒绝、零写入。改提示词按 改动大小挑工具:

你要做的事	用哪个
改提示词里几个词	video_workbench_patch_prompt(给旧片段和新片段,不用重发整段)
一张卡多个字段 / 整段重写提示词	video_workbench_update_task
一批卡同一个规格(整板 480p、都开联网)	video_workbench_set_spec
整页重排	video_workbench_reorder(一次给出该页完整 id 顺序)
挪一张卡的位置	video_workbench_move_task(不要并发调,重排没有交换律)
增删卡	video_workbench_add_tasks / video_workbench_remove_tasks

单卡工具改的是不同卡、彼此可交换,所以可以并发;只有重排例外 —— 挪多张卡用 reorder 一次做完,别并发发几个 move_task。

给卡片留一行摘要(video_workbench_set_card_summary,≤40 字,电报体如 「主角跳车 · 夜外 · 追兵逼近」)。经底座工程化的提示词开头结构固定,同一页里 截断的开头看起来几乎一样 —— 摘要才是让你不拉全文就能认出这是哪一镜的东西。 它绑在写它时的那份提示词上:提示词一改,摘要即被判过期、不再展示,status 只回一个 summaryStale: true 提示你可以重写。所以你永远不会读到一条「看起来是权威的」旧摘要。 写摘要不涨卡片 rev,不会作废你手里的 IR。

video_workbench_export → 改 JSON → video_workbench_apply 只剩一个用途:整板一次性 重建(全改或全不改的原子性,是单卡调用序列给不了的)。数组顺序即卡片顺序,保持 irVersion / structureRevision / 每张卡的 rev 不变,否则会被拒。

export 默认只出骨架 —— 每张卡是 {id, rev},没有提示词也没有素材。重排、 只改其中几张这类活本来就不需要看别人的提示词:拿骨架 → 往要改的那几张填内容 → 回写,顺序天然正确、体积与提示词长度无关。要读某几张的全文,在 cardIds 里点名; full: true 是整板全文,只在真要通读时才开 —— 它是最容易撞 10k 静默截断的调用, 而 apply 是声明式的,回写一份被截断的 IR 会把截掉的字段清成默认值。

export 默认只导当前页,回写也安全 —— merge 模式保证没列出的页原样不动。真要 跨页挪卡或重排页签才传 allBoards:true。整份导出带着每张卡的完整提示词和每条素材 的完整路径,一个中等规模的工作台就能超出客户端肯收的体积,而 apply 是声明式的: 拿一份被截断的 IR 回写,会把截掉的字段清成默认值。工具超预算时会直接报错并让你 缩小范围 —— 那是在替你挡这件事,别去绕。

新建一板卡走 add_tasks(每次 ≤5,分批)。重排单张卡用 move_task 就够了,不必 为了挪一个位置把整板 IR 往返一遍。

Shot Card → 卡片字段

Shot Card 字段	卡片字段	说明
scenedance_prompt	prompt	见下方「什么能直接搬」——不是所有来源都能
duration	duration	收敛到 4–15;-1 表示智能时长
primary_input_image	referenceImages[0]	首图放第一位 —— 它承担构图/画质锚点
reference_images	referenceImages	合计 ≤9 张
shot_size / camera_movement	并入 prompt	卡片无独立字段,写进运镜段
shot_id	卡片顺序	靠排列顺序表达,不进 prompt
prev_transition / next_transition	不映射	转场属后期剪辑,不是单镜输入

Shot Card 里没有、需要你决定的:model(默认 2.0)、resolution(默认 720p)、 ratio(默认 16:9;万相 3.0 默认 adaptive,它也不支持 21:9)、 mode(默认全能参考)、generateAudio(默认开)。

万相 3.0 另有一个 Seedance 没有的入参:documentOrLink —— 一份文档或一个网页链接 作参考(各限 1 个、二选一)。传裸 http(s) 地址即可,是文档还是链接由后缀自动判定。 它与首帧/首尾帧互斥。Seedance 的卡片忽略这个字段。

什么能直接搬,什么必须先过底座

看来源,不看字段名。 同样叫 scenedance_prompt,来源不同命运不同:

• create-storyboard 制片包的 scenedance_prompt —— 出包时已按 sd2-pe 工程化, 直接搬。分段结构先连成可提交的成文即可,不必重写。
• 用户手写的分镜表 / 你自己从剧本拆的镜头表 / 网上抄来的 shot list —— 那是散文, 每一镜都要先过底座 才能进 prompt。它读起来像提示词不代表它是提示词: 八大要素齐不齐、物理参数有没有、素材怎么绑,散文里都没有。

拿不准来源是否工程化过,就按「没过」处理 —— 多跑一次底座的成本远低于整板 出来不是你要的画面。

跨镜续接:批量与串行的取舍

入口有一条「跨镜续接优先抽上一镜关键帧/尾帧作下一镜 firstFrame」。那条默认针对 逐镜串行推进,和工作台的批量并行天然互斥 —— 第 2 镜的首帧要等第 1 镜渲完才存在。 两条纪律都对,只是不能同时用。

• 工作台默认走可并行那条: 全能参考 + 逐卡逐字复制的身份/风格锚点。填满整板一次 video_workbench_start,几镜同时跑。绝大多数场景够用 —— 锚点写足了,跨镜一致性 靠文字也能守住。
• 需要帧级硬续接时改串行: 镜与镜要求画面严丝合缝(同一动作跨镜延续、不许跳切)时, 一次只 start 一张卡 → 等推送 → 用 ffmpeg-win 抽尾帧 → 填进下一张卡的 firstFrame → 再 start。慢,但这是唯一能做到帧级续接的路径。 入口另有一条「firstFrame/lastFrame 只在用户明确要求时才切」—— 把下面这个取舍 摆给用户、他选了串行,就构成那条所说的「明确要求」,不必再确认第二次。
• 别把两者混着来。 整板并行跑完之后再去抽尾帧回填,已经渲好的卡不会因此重跑; 你拿到的是几段各自独立的片子,外加一次白费的抽帧。要串行就从一开始串行。

选哪条要告诉用户并说明代价(并行快但转场可能硬,串行慢但接得住),别默默替他定。

配乐与音频

卡片上的 generateAudio(默认开)出的是该镜自己的对白 / 环境声 / 音效,由 Seedance 随画面一起生成。它不是配乐,也不可能跨卡连续 —— 每张卡是一次独立调用,几段音乐接 不成一条曲线。

要一条铺满全片的配乐,交 catimation-audio 出整段,成片后用 ffmpeg-win 把各镜 concat 起来再把音乐混进去。

别把配乐当参考音频喂进卡片: referenceAudios 合计 ≤15s,多镜成片通常超过这个长度 (4 镜 × 5s = 20s 就塞不下);而且参考音频作用于该镜的生成,不是给成片配乐用的。

多镜且要统一配乐时,generateAudio 开还是关取决于要不要保留逐镜环境声 —— 保留就开 (音乐后期叠在上层),要干净画面轨就关。这个取舍讲给用户,别替他决定。

开跑前的四项清点

入口的「角色片/多镜」硬门在工作台上一字不改地适用。建卡不等于备齐资产, video_workbench_start 之前这四样必须已完成:

1. 每个复用角色已锁 identity-hard 主锚,并逐字写进每张卡的 prompt。
2. 故事板已给用户过目。 没点头就开跑,等于替他决定了镜头设计。
3. 逐镜资产齐备。 缺口按「先找人像库现成 → 非身份关键的自己 generate_image 补 → 身份/IP/品牌关键的才问用户」处理。推荐每镜 4–5 个核心素材;有素材却纯文字=错。
4. 每张卡的 prompt 都过了底座,并对照过「一张卡的 prompt 里要有什么」。 不是「读起来像提示词」就算 —— 镜头表、用户手写的分镜、从剧本拆出来的描述,都是 散文,必须工程化过才能上板。八大要素逐项过一遍(内容覆盖,与底座无关),三项跨卡 内容(主锚全文 / 风格光位 / 本镜道具状态)逐卡确认在位。记 prompt_engineered。

开跑之后

不要轮询 video_workbench_status。 批次跑完会主动推「[视频工作台] 批次渲染完成」 摘要给你。提交后立刻回答用户,保持可对话。

摘要只报成败与落盘路径,不代表 QA 已做。人脸/复杂动作的卡照样抽九宫格, 多镜剧情照样过内容 QA,做过的档记进 qa_completed。

整板质检别挨张看。 主 agent 直接 view_image 的上限是 5 张;一板十几张卡的 产物必然超过。走 catimation-subagents:并发调 understand_document(看宫格图)/ understand_video(看整段),回来是文本;每张卡的结论落成 <文件名>.vision.json / .md 旁挂,重跑哪几张一目了然,也不用把整板塞进上下文。这条和上面「一轮跑完需要 重做的卡超过半数就停下来找共因」是配套的 —— 有了逐卡的文本结论才看得出共因。

重试有两道闸,别只记住第一道。 单卡受入口的 generation_attempts ≤2 约束: 同一张卡连续失败两次还不对,先回去查锚点和素材,不要第三次重投。整板另有一道: 一轮跑完需要重做的卡超过半数时,停下来找共因,不要逐张重投 —— 半数以上一起出 问题,病根通常在锚点、素材或规格这些整板共用的东西上,逐张重跑等于把同一个错误付费 N 次。找到共因、改一次、整板重来,比每张卡各试两次便宜得多,也快得多。无论哪道闸 触发,先把成本和判断讲给用户,由他决定要不要继续。

Common Mistakes

• 该拆的没拆: 四个各要 5 秒的镜头压进一张 15s 的卡,每镜只剩 3.75 秒,全都演不完。 拆卡的判据是时长、素材、控制粒度,不是镜头号。
• 不该拆的乱拆: 把一个连续节拍(铺垫→递进→崩溃)拆成四张卡,卡间不共享上下文, 表演的连贯性接不住,节奏就断了。这种应按路径 B 写成一段镜头流程。
• 只在第一张卡写锚点。 后面的卡会漂脸、漂服装、漂风格。
• 建完卡直接 start。 跳过了资产门,而「只填不跑」的默认设计就是为了让你补齐。
• 轮询状态。 阻塞自己,还拿不到比推送更早的结果。
• 拿批次摘要当 QA。 它只说渲染成功,没说画面对。