executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
material-driven-storyboard当用户在本地算力/工具受限的条件下写分镜,已经想好一个理想镜头(如「雨中奔跑」「追车戏」),却发现没有对应驱动视频或本地工作流做不出来时调用。 核心判断:分镜起点应是「手上真实有什么素材/驱动视频」,再倒推能写什么镜头,而不是先定理想画面再找办法实现。 提供三条出路:换驱动视频改动作 / 改用静态图加 Ken Burns / 改故事去掉该镜头。 不适用于:用户走云端平台(即梦/可灵)算力充足时——应转常规「理想画面先行」路线;单镜提示词怎么写用 emotion-to-camera-language。 Trigger: 素材反推 / 没有驱动视频 / 这个镜头做不出来 / driving video / material-driven
Independent GitHub snapshot · Automated classification · Original documentation governs
name: material-driven-storyboard description: | 当用户在本地算力/工具受限的条件下写分镜,已经想好一个理想镜头(如「雨中奔跑」「追车戏」),却发现没有对应驱动视频或本地工作流做不出来时调用。 核心判断:分镜起点应是「手上真实有什么素材/驱动视频」,再倒推能写什么镜头,而不是先定理想画面再找办法实现。 提供三条出路:换驱动视频改动作 / 改用静态图加 Ken Burns / 改故事去掉该镜头。 不适用于:用户走云端平台(即梦/可灵)算力充足时——应转常规「理想画面先行」路线;单镜提示词怎么写用 emotion-to-camera-language。 Trigger: 素材反推 / 没有驱动视频 / 这个镜头做不出来 / driving video / material-driven source_book: 多源蒸馏《本地链路可生产的无对白情绪短片分镜》 source_chapter: S3 硬约束表 + S2《深夜抓捕醉酒小猫实录》分镜脚本反证 verified: 转述(本机未做动作迁移驱动视频链路) tags: [分镜, 本地生产, 素材驱动, 驱动视频, 动作迁移] related_skills:
故事和情绪先定要什么画面,然后拿手上真实有的素材和工作流去凑;凑不出来的镜头,改故事。
第三句是重点。多数人卡在第二步就开始想办法硬做那个镜头 —— 换模型、加插件、反复重抽,成本无限追加而画面始终不对。正确的动作是承认这个镜头做不出来,回头动故事。
故事是可改的,本地算力上限是不可改的。 谁让步很明显。
方法论来源见仓库根目录 ATTRIBUTION.md。
S1(视频教学)、S2(用户自制分镜)、S4(参考成片)三个来源全部默认同一个生产顺序:先想清楚故事和理想画面,再想办法把它生成出来。这个顺序在云端有强大生视频能力、能凭空生成任意动作时成立。
但本地链路的动作不是生成的,是迁移的——SCAIL2 只能把角色形象"贴"到一段已有的驱动视频上,动作库的边界就是驱动视频库的边界。这意味着,如果分镜的起点是"理想画面",很可能写出一份手上任何素材都撑不起来的分镜表——这正是 S2《深夜抓捕醉酒小猫实录》从未被生产出来的根本原因:它设计了接力生产、凭空生成的炸毛咆哮等一整套动作,却从没检查过本地是否具备对应能力。
反过来,本地路线唯一走得通的顺序是:先盘点手上真实有什么(驱动视频库、已跑通的工作流、已有的素材),再问"这些素材能撑出什么样的镜头语言",最后才把分镜写成故事。凑不出来的镜头不是等更强模型出现,而是当场三选一:换一段能用的驱动视频改动作、退回静态图配 Ken Burns 运镜、或者干脆把这个镜头从故事里删掉。
这条方法论只在"本地算力/工具能力有硬上限"时成立,是本地条件反向推导出的收敛路径,而不是一个普遍真理。
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 管生成之前分镜设计该以什么为起点盘点手上真实有什么
从素材反推可行的镜头语言
对照理想分镜逐镜核对可行性
三选一判断分支(想要的镜头做不出来时)
组装最终分镜表
emotion-to-camera-language 的范围lock-character-reference 的范围Wan14Bi2vFusioniX 做好 offload 封装,"凭空生成动作/接力生产不可用"这两条约束会松动,届时素材反推的必要性会降低,需要重新评估lock-character-reference(动作/素材可行性 vs 角色外观可行性,两条独立检查线常交替确认,无强制先后)、emotion-to-camera-language(本 skill 盘点出的驱动视频动作,是那个 skill "人物状态"变量的素材来源,尤其在本地"动作靠迁移不靠生成"的约束下)