# Material Driven Storyboard > 当用户在本地算力/工具受限的条件下写分镜，已经想好一个理想镜头（如「雨中奔跑」「追车戏」），却发现没有对应驱动视频或本地工作流做不出来时调用。 核心判断：分镜起点应是「手上真实有什么素材/驱动视频」，再倒推能写什么镜头，而不是先定理想画面再找办法实现。 提供三条出路：换驱动视频改动作 / 改用静态图加 Ken Burns / 改故事去掉该镜头。 不适用于：用户走云端平台（即梦/可灵）算力充足时——应转常规「理想画面先行」路线；单镜提示词怎么写用 emotion-to-camera-language。 Trigger: 素材反推 / 没有驱动视频 / 这个镜头做不出来 / driving video / material-driven - Skill: `l-trunks/material-driven-storyboard` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add l-trunks/material-driven-storyboard` - Raw SKILL.md: https://api.skillmd.com/api/skills/l-trunks/material-driven-storyboard/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: L-Trunks (https://skillmd.com/u/l-trunks) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/l-trunks/material-driven-storyboard --- # 素材反推分镜 ## R — 核心命题 (Reading) **故事和情绪先定要什么画面，然后拿手上真实有的素材和工作流去凑；凑不出来的镜头，改故事。** 第三句是重点。多数人卡在第二步就开始想办法硬做那个镜头 —— 换模型、加插件、反复重抽，成本无限追加而画面始终不对。正确的动作是承认这个镜头做不出来，回头动故事。 **故事是可改的，本地算力上限是不可改的。** 谁让步很明显。 > 方法论来源见仓库根目录 [ATTRIBUTION.md](../../ATTRIBUTION.md)。 --- ## I — 方法论骨架 (Interpretation) S1（视频教学）、S2（用户自制分镜）、S4（参考成片）三个来源全部默认同一个生产顺序：先想清楚故事和理想画面，再想办法把它生成出来。这个顺序在云端有强大生视频能力、能凭空生成任意动作时成立。 但本地链路的动作**不是生成的，是迁移的**——SCAIL2 只能把角色形象"贴"到一段已有的驱动视频上，动作库的边界就是驱动视频库的边界。这意味着，如果分镜的起点是"理想画面"，很可能写出一份手上任何素材都撑不起来的分镜表——这正是 S2《深夜抓捕醉酒小猫实录》从未被生产出来的根本原因：它设计了接力生产、凭空生成的炸毛咆哮等一整套动作，却从没检查过本地是否具备对应能力。 反过来，本地路线唯一走得通的顺序是：先盘点手上真实有什么（驱动视频库、已跑通的工作流、已有的素材），再问"这些素材能撑出什么样的镜头语言"，最后才把分镜写成故事。凑不出来的镜头不是等更强模型出现，而是当场三选一：换一段能用的驱动视频改动作、退回静态图配 Ken Burns 运镜、或者干脆把这个镜头从故事里删掉。 这条方法论只在"本地算力/工具能力有硬上限"时成立，是本地条件反向推导出的收敛路径，而不是一个普遍真理。 --- ## A1 — 来源中的应用 (Past Application) ### 案例 1: S1《后山野花》——生成结果与理想不符时当场改故事，而非硬凑 - **问题**: 矩阵化生图筛选角色形象时，发现主角、村长的人物形象跑偏，只有小孩是对的；这些场景"都不在范畴里面" - **方法论的使用**: 不将就使用形象跑偏的素材，直接判定弃用；因为素材撑不起原定结局，**结局被整个换掉** - **结论**: 当手上实际产出的素材（哪怕是生成结果而非驱动视频）撑不起理想画面时，改故事比硬凑更可行 - **结果**: 最终成片仍完成并入围 LipTV 首届赛事——证明"素材反推、必要时改故事"这条路径是可行的，不是妥协 ### 案例 2（仅设计未生产）: S2 01 号基准镜——设计阶段就把后续镜头的可行性押在一套未经验证的机制上 - **问题**: S2 把第 1 镜定为"基准镜"，明确写下"确定光线/构图/色调，后面全靠它接"，但后续 13 镜的接力生产、凭空生成的动作，从设计第一天起就没有核对本地是否具备对应工作流 - **方法论的使用**: （反面）设计顺序是"先写好完整的理想机制，再假设生产环节能配合"，与素材反推分镜的顺序完全相反 - **结论**: 起点是理想画面而非现有素材/工作流能力，是这份分镜的根本设计缺陷 - **结果**: **仅设计未生产**——整套分镜从未投入生产验证，也从未真正拍出来（BOOK_OVERVIEW 已明确指出这是本次蒸馏排除多镜头剧情短剧路线的直接原因之一） --- ## A2 — 触发场景 (Future Trigger) ★ ### 用户会在什么情境下需要这个 skill? 1. 已经写好一个理想分镜（如"她在雨中奔跑""两人追逐后倒地"），准备去找对应的驱动视频/工作流时，才发现库里没有匹配的动作 2. 直接问"这个镜头本地做不出来怎么办"，或"要不要等换个更强的模型再做这个镜头" 3. 正在盘点手上素材库（驱动视频、已跑通的工作流），想知道这些素材能撑出什么样的分镜，而不是先空想画面 4. 参照 S1/S2 这类云端案例的分镜表，逐条对照本地工具箱发现大量条目做不出来，需要系统性地改写 ### 语言信号 - "没有对应的驱动视频 / 这个动作素材库里没有" - "这个镜头本地做不出来，怎么办" - "手上有什么素材可以用" - "要不要等模型更强了再做这镜" - "driving video / material-driven storyboard / footage-first" ### 与相邻 skill 的区分（定稿） - 与 `emotion-to-camera-language` 的区别：那个 skill 管**一个镜头内部**怎么用机位/光位/景深/人物状态写提示词；本 skill 管**整片从哪里起手**——先有素材还是先有理想画面。二者是 `composes-with` 关系而非先后依赖：本 skill 盘点出的驱动视频库，直接决定了 `emotion-to-camera-language` 四件套里"人物状态"这一项能写什么——本地的人物状态不是靠提示词凭空生成的，是驱动视频自带的动作，所以写"人物状态"这一项时应该反过来先看本 skill 的素材清单里有哪些具体动作瞬间，而不是先凭空想一个动作再去找素材 - 与 `lock-character-reference` 的区别：那个 skill 管角色形象能不能锁死、锁不死怎么办；本 skill 管的是**动作/镜头**这一层的素材可行性。二者是**两条独立的可行性检查线**，没有严格的先后顺序——项目起步时可能先有一个大致故事，用本 skill 反推素材可行性，再去锁角色；也可能先锁定了心仪的角色形象，再用本 skill 检查这个角色能做哪些动作。两条线常常交替往返，但都必须赶在 `shot-breakdown` 正式批量生成之前完成 - 与 `editing-triad`（剪辑三分法）的区别：那个 skill 管素材已经拍出来之后怎么剪；本 skill 管素材还没拍之前分镜该怎么写 - 与 `rhythm-density`（节奏疏密）的区别：那个 skill 管每镜多长、怎么排布节奏，且**依赖**本 skill 先确认素材可行性（尤其 ≤10s 硬顶本身就来自本 skill 的硬约束表）；本 skill 管每镜的内容能不能被生产出来 - 与 `shot-breakdown`（镜头拆解）的区别：那个 skill 管**生成之后**怎么从一批结果里筛选可用画面；本 skill 管**生成之前**分镜设计该以什么为起点 --- ## E — 可执行步骤 (Execution) 1. **盘点手上真实有什么** - 列出可用的驱动视频库（动作类型、时长、机位/景别）、已跑通的工作流（文生图/图生图/动作迁移/超分） - 完成标准：得到一份"素材清单"，每条素材标注动作类型 + 大致时长 + 原生机位/景别 2. **从素材反推可行的镜头语言** - 对每段驱动视频问："这个动作能表达什么情绪？适合放在故事的哪个位置？" - 完成标准：每个候选镜头都能对应到一条具体素材或一个具体工作流，而不是凭空写出的理想画面 3. **对照理想分镜逐镜核对可行性** - 如果用户已有一份理想分镜表，逐镜检查是否有对应素材/工作流支撑 - 判停条件：某一镜没有对应素材或超出本地工作流能力（如需要凭空生成新动作、需要 FLF2V 首尾帧接力）→ 进入第 4 步 4. **三选一判断分支（想要的镜头做不出来时）** - **换驱动视频改动作**：保留镜头位置和情绪目的，换一段库里有的、情绪相近的驱动视频替代原定动作 - **改用静态图 + Ken Burns**：动作要求过高但情绪可以用静态构图传达时，退回文生图/图生图出一张定格画面，靠推拉摇移的运镜模拟运动感 - **改故事去掉该镜头**：前两条都无法满足时，直接删掉这个镜头或替换成故事里的其他情节（参照 A1 案例 1 的先例） - 完成标准：为每一个"做不出来"的镜头选定唯一一条出路，并写清替代后的具体画面描述 5. **组装最终分镜表** - 按镜号整理：素材来源（驱动视频/静态图）、对应工作流、是否属于三选一调整过的镜头 - 完成标准：全片每一镜都能对应到一个本地实际可执行的生产步骤，没有"待定"或"希望模型能做到"这类条目 --- ## B — 边界 (Boundary) ★ ### 不要在以下情况使用此 skill - **用户改用云端平台（即梦/可灵/Nano Banana 等）且算力充足**——此时应优先常规的"理想画面先行"路线（想法→提示词→生图→生视频），素材反推是本地硬约束下的收敛策略，不是普遍更优的方法 - 用户已经确认所有镜头都有对应素材/工作流支撑，只是在问分镜内部怎么写提示词——那是 `emotion-to-camera-language` 的范围 - 讨论的是角色形象能不能锁死，而非动作/镜头素材是否可行——那是 `lock-character-reference` 的范围 ### 来源中警告的失败模式 - **S2 分镜整体的失败**：整套 14 镜的分镜、接力生产表、配音脚本都写得很完整，但核心机制（接力生产依赖 FLF2V、猫的炸毛咆哮属于凭空生成动作、多机位切换要求角色跨镜一致）全部建立在本地不具备的能力上，设计阶段没有对照本地工具箱核实，导致**从未被生产出来过** - 把"学了别人的方法论"误当成"具备了对方的基础设施"（S1 全程基于画布平台 + 比赛赠送算力，门槛只是转移到了付费/算力上，没有消失） ### 作者的盲点 / 局限 - 这条方法论是单源（S3）提出，佐证来自 S2 的失败反证与硬约束表的交叉验证，**没有第二个"本地路线成功案例"的正面来源**——目前只证明了"不这么做会失败"，尚未有"这么做成功产出了一条完整短片"的实测记录 - 若本地补齐 FLF2V 首尾帧模型或给 `Wan14Bi2vFusioniX` 做好 offload 封装，"凭空生成动作/接力生产不可用"这两条约束会松动，届时素材反推的必要性会降低，需要重新评估 ### 容易混淆的邻近方法论 - 与"抽卡-筛选-拼接"不是一回事——那是**同一素材反复生成直到满意**，本 skill 是**先确认有没有能用的素材，再决定要不要生成**，发生在抽卡之前 - 与"先生图再生视频更可控"这条常识（S1 路线选择）不是同一层级——那条讨论的是"要不要插入生图这一步"，本 skill 讨论的是"分镜设计的起点该是理想画面还是现有素材"，二者可以同时成立也可能冲突（本地场景下动作由驱动视频决定，生图对动作的控制力被削弱） --- ## 相关 skills - depends-on: 无（本 skill 是全流程最前置的可行性检查之一，不依赖其他 skill） - contrasts-with: 无 - composes-with: `lock-character-reference`（动作/素材可行性 vs 角色外观可行性，两条独立检查线常交替确认，无强制先后）、`emotion-to-camera-language`（本 skill 盘点出的驱动视频动作，是那个 skill "人物状态"变量的素材来源，尤其在本地"动作靠迁移不靠生成"的约束下） --- ## 审计信息 - **验证通过**: V1 ✓（特例裁定：单源提出，但有两个独立佐证——① S3 硬约束表 ② S2 整份分镜未能生产的根因分析；三个外部来源方向相反，是环境差异而非分歧） / V2 ✓（可推导"想拍雨中奔跑但无对应驱动视频"这类来源未讨论的情形，给出三条具体出路） / V3 ✓（与三个外部来源全部相反，独特性最强） - **测试通过率**: 待阶段 4 - **蒸馏时间**: 2026-08-01