# Shot Breakdown

> 角色基准形象图**已锁定**后，批量出图并从结果里筛可用镜头时调用。典型：矩阵化生图后挑符合脚本意图的；某张景别/机位不对要重抽；同镜反复抽不出来、要决定继续抽还是弃用改故事。 **分界**：基准形象图本身跑不稳 → lock-character-reference；基准图已稳、只是这批结果里人物跑偏或景别不对 → 本 skill。 本地每次生成分钟级，同镜重抽 3-5 次不可用就停手改故事。 不适用：生成前提示词怎么写（emotion-to-camera-language）、镜间时长排布（rhythm-density）。 Trigger: 矩阵生图 / 筛图 / 重抽 / 景别不对 / shot breakdown

- Skill: `l-trunks/shot-breakdown` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add l-trunks/shot-breakdown`
- Raw SKILL.md: https://api.skillmd.com/api/skills/l-trunks/shot-breakdown/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/shot-breakdown

---


# 镜头拆解 — 矩阵生图筛选与成本判停

## R — 核心命题 (Reading)

**矩阵化出图之后，真正的工作是筛，不是抽。**

一次出一批（16 宫格这类），然后逐张对着分镜意图检查：景别对不对、机位对不对、人物对不对。不对就针对性重抽那一项，而不是整批推倒重来。

关键在于**筛选的判据是分镜意图，不是好看**。同一批里可能小孩是对的、大人是错的 —— 那就只重抽大人那几镜，对的部分直接收下。把「这批不行」当成整体判断，是最常见的浪费。

配套的是判停：重抽有上限，超过就该改镜头设计而不是继续抽。

> 方法论来源见仓库根目录 [ATTRIBUTION.md](../../ATTRIBUTION.md)。

---

## I — 方法论骨架 (Interpretation)

镜头拆解不是传统意义上"把剧本拆成分镜表"，而是**反向操作**——先批量生成一堆随机结果，再从结果里筛出可用画面，倒推出分镜。

具体流程是三步：先用矩阵化生图（16 宫格或类似批量出图）一次产出一批候选；再逐张对照脚本意图筛选，人物不对/场景不符的直接弃用；对筛出来的可用画面做二次修正，景别不对改景别、机位不对改机位。

这套流程的前提是角色形象已经锁定（见 `lock-character-reference`），否则筛选和修正都没有基准可对照。

真正决定这个方法论有没有用的，不是筛选步骤本身，而是**筛不出来的时候怎么办**。云端场景下抽卡近乎零成本，可以无限重抽；本地场景下每次生成是真实的分钟级 GPU 占用，重抽是有真实代价的成本。这就需要一个明确的判停条件：不是"修到满意为止"，而是当某个角色/场景反复抽不出对的结果时，直接判定为"不在范畴里"弃用，必要时改故事而不是死磕生成参数。这是作者自己真实做过的决策——不是理论，是他真的把结局换掉了。

---

## A1 — 来源中的应用 (Past Application)

### 案例 1: S1 矩阵化生图 → 镜头拆解筛选流程

- **问题**: 结合导演简报和脚本做批量出图之后，如何从一堆随机结果里挑出能用的画面
- **方法论的使用**: 用 16 宫格矩阵化生图批量产出候选，逐张比对脚本意图筛选，不符合的直接弃用；对筛出的可用画面做二次修正（景别/机位不对就改）
- **结论**: 镜头拆解本质是"从结果反推分镜"，不是精准控制生成
- **结果**: 用这套流程把批量生成结果收敛成《后山野花》的可用镜头序列

### 案例 2: 人物形象跑偏 → 弃用并换结局（真实弃用决策）

- **问题**: 矩阵化生图筛选时发现主角、村长的人物形象跑偏（"人是不对的"），只有小孩的形象是对的，这些不合格的场景"其实都不在范畴里面"
- **方法论的使用**: 没有选择继续换提示词硬修这几个角色的形象，而是直接判定这批结果不可用，并倒逼修改分镜——原定的结局场景整个换掉
- **结论**: 筛不出来的正确反应是弃用+改故事，不是无限重抽/硬修
- **结果**: 《后山野花》最终仍完成并入围，证明"弃用并改故事"这条路径是可行的收尾手段

---

## A2 — 触发场景 (Future Trigger) ★

### 用户会在什么情境下需要这个 skill?

1. 已经锁定角色形象，批量出图之后，要从一堆结果里挑出能用的镜头
2. 抽出来的图人物形象跑偏、景别或机位不对，不确定该换提示词重抽还是接受现状
3. 已经在同一个镜头上重抽了很多次仍然不满意，担心继续抽下去只是浪费本地算力和时间
4. 发现某个角色/场景在本地怎么抽都抽不对，需要决定是死磕还是改故事

### 语言信号

- "这批图哪些能用"
- "抽了好几次都不对，要不要继续抽"
- "这个角色形象一直崩，怎么办"
- "shot selection / re-roll / give up on a shot"

### 与相邻 skill 的区分（定稿）

- 与 `emotion-to-camera-language` 的区别：本 skill **依赖**那个 skill——批量生成需要先有提示词，本 skill 管生成之后怎么筛选和修正；那个 skill 管生成之前单个镜头内部怎么描述提示词。没有先写出四件套提示词，批量出的图连"筛选标准"都没有
- 与 `lock-character-reference` 的区别：本 skill **依赖**那个 skill——前提是角色形象已经锁定；那个 skill 管形象锁定本身怎么做、本地条件下会在哪里失效。没有锁死的形象，筛出来的图连"是不是同一个人"都判断不了
- 与 `material-driven-storyboard` 的区别：那个 skill 管**生成之前**分镜设计该以什么素材为起点（发生更早，属于可行性检查）；本 skill 管**生成之后**怎么从一批实际产出的结果里筛选可用画面（发生在实际批量生成时）。两者不是同一层：即使已经用 `material-driven-storyboard` 确认了素材可行，具体抽出来的这一张图对不对，仍然要靠本 skill 筛
- 与 `rhythm-density` / `editing-triad` 的区别：本 skill 发生在素材筛选阶段，那两个 skill 发生在素材已经筛完、准备排布时长/剪辑成片的阶段，**依赖**本 skill 先产出确定的可用镜头

---

## E — 可执行步骤 (Execution)

1. **批量矩阵化出图**
   - 结合脚本/导演简报，用同一批提示词做多宫格（或多次同参数改 seed）批量出图，本地无一键 16 宫格功能，用改 seed 循环出图替代
   - 完成标准：手上有一批（建议 ≥4-6 张）针对同一镜号的候选图

2. **按脚本意图逐张筛选**
   - 对照脚本意图检查人物是否对、场景是否在范畴内，不符合的直接标记弃用，不勉强凑合
   - 完成标准：每张候选图都被标记为"可用"或"弃用"，没有模糊状态

3. **对可用画面做二次修正**
   - 景别不对改景别提示词重抽，机位不对改机位提示词重抽
   - 完成标准：修正后的画面景别/机位与脚本意图一致

4. **成本判停检查（关键步骤）**
   - 统计这个镜号已经重抽的次数/耗时；本地每次生成是真实的分钟级 GPU 占用，不是零成本抽卡
   - 完成标准：明确得出"继续抽"或"停止，进入弃用流程"的判断，而不是无限抽下去
   - 判停条件：**若同一镜号已经重抽超过一个自己设定的次数上限（建议 3-5 次）仍未筛出可用结果，停止重抽**，转到步骤 5

5. **弃用并改故事（判停后的出口）**
   - 把该镜号判定为"当前本地能力做不出来"，倒推修改分镜甚至结局/场景设定，而不是继续硬修同一批结果
   - 完成标准：分镜/故事层面已经有替代方案，不再依赖这个抽不出来的镜头

---

## B — 边界 (Boundary) ★

### 不要在以下情况使用此 skill

- 角色形象图还没锁定——先做 `lock-character-reference`，没有一致的基准，筛选和修正都没有意义
- 只是要写提示词描述单个镜头的机位光位，还没进入批量生成——用 `emotion-to-camera-language`
- 素材已经筛选完毕，现在要决定时长/音效/调色——那是 `rhythm-density` / `editing-triad` 的范围

### 来源中警告的失败模式

- **明知人物/场景形象不对还将就使用**——直接违背作者本人的判断标准，他把这类结果明确判定为"不在范畴里面"
- **把"多试几次挑好的"当成常识化的无脑重抽，忽视本地重抽的真实算力成本**——这是把云端的抽卡成本假设直接照搬到本地，本地每次生成是真实的分钟级 GPU 占用而非近乎免费

### 作者的盲点 / 局限

- S1 全程在云端平台（即梦/可灵/Nano Banana/Image2）操作，重抽近乎零成本，"抽到满意为止"的耐心在本地环境下必须重新校准；判停次数（3-5 次）是本 skill 基于本地成本推导给出的经验值，不是来源里的量化数据
- 弃用并改故事这条路径在案例里只发生过一次（结局莲花），样本量为 1，能否稳定复用到"任何角色形象跑偏"的场景未经进一步验证

### 容易混淆的邻近方法论

- 与"提示词工程调参"（改权重/负向词试图修复同一张图）不是一回事——那是在同一批结果内部做微调，本 skill 讲的是"整批弃用、重新抽或者改故事"这个更大颗粒度的决策
- 与"角色一致性锁定"不是一回事——那是前置的基准建立步骤，本 skill 假设基准已经存在，只处理"基于这个基准筛出的结果对不对"的问题

---

## 相关 skills

- depends-on: `lock-character-reference`（筛选前必须有锁定的角色形象作为判断基准）、`emotion-to-camera-language`（批量生成前必须先有单镜提示词）
- contrasts-with: 无
- composes-with: 无（与 `material-driven-storyboard` 是前后阶段而非组合使用，见上方区分）

---

## 审计信息

- **验证通过**: V1 ✓（单源内多语境：S1 内部两个独立场景——方法描述"16 宫格筛选、景别/机位不对就改"和真实弃用决策"人物不对→整个结局换掉"） / V2 ✓（可推导"筛不出来怎么办"→S1 的真实做法是改故事，而不是硬凑，这条推论来源没明说但有行为证据） / V3 ✓（独特术语+反直觉：大多数人会想着修图，他的做法是弃用并改故事）
- **测试通过率**: 待阶段 4
- **蒸馏时间**: 2026-08-01