ahel is live on Product Hunt today. Upvote

素材反推分镜

SkillMedia

Invoke when a user is writing storyboards under local compute/tool constraints, has already envisioned an ideal shot (e.g., "running in the rain", "car chase"), but finds there is no corresponding driving video or the local workflow cannot produce it. Core principle: the storyboard's starting point

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the 素材反推分镜 skill

What this skill tells your AI

The instructions your AI receives, as published by l-trunks/ai-film-skills in skills/material-driven-storyboard/SKILL.md and read by ahel’s review.

R — 核心命题 (Reading)

故事和情绪先定要什么画面,然后拿手上真实有的素材和工作流去凑;凑不出来的镜头,改故事。

第三句是重点。多数人卡在第二步就开始想办法硬做那个镜头 —— 换模型、加插件、反复重抽,成本无限追加而画面始终不对。正确的动作是承认这个镜头做不出来,回头动故事。

故事是可改的,本地算力上限是不可改的。 谁让步很明显。

方法论来源见仓库根目录 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

Signals

GitHub stars
20
Forks
4
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
material-driven-storyboard
Source
github.com/l-trunks/ai-film-skills