# AI 连续剧制作流程与 ComfyUI 基础手册
> 适用对象：准备从零制作 AI 短剧、系列短片或同一角色连续剧的个人与小团队。
> 资料检索与链接核对：2026-10-28 至 2026-10-29；整理完成：2026-10-29。
> 本机案例：`F:/AI视频项目/short_drama_batch_20261028`。
> 阅读方式：先看第 1、3、7、12 节开始制作，再按问题查技术章节。
本手册把信息分成三类：**公开资料事实**、**本机已经验证的做法**、**建议采用的制作 SOP**。后两者会明确标注。网上作品公开的制作介绍没有披露全部节点、模型和训练参数，因此这里提供的是根据可靠资料整理的可执行方案，并非某个剧组内部工作流的复刻。
## 目录
1. [先看这页：从想法到第一集](#quick-start)
2. [网上 AI 系列案例能借鉴什么](#cases)
3. [完整制作流程：做什么、交什么、何时通过](#pipeline)
4. [连续剧的核心：系列设定与跨集状态](#continuity)
5. [剧本、分镜、声音和预演](#story-shots)
6. [角色、场景、道具资产怎么准备](#assets)
7. [怎样选择和组织生成工作流](#workflow-design)
8. [ComfyUI 基础知识与节点](#comfy-basics)
9. [LoRA 是什么、怎么用、何时需要训练](#lora)
10. [参数、显存和常见故障](#parameters)
11. [自动化、命名、版本和可追溯记录](#automation)
12. [逐镜质检、剪辑、字幕和混音](#quality-post)
13. [你当前这套 H3 流程的实际配置](#local-case)
14. [第一次制作的行动清单与成本记录](#first-project)
15. [可直接复制的项目模板](#templates)
16. [公开发布、授权与资料来源](#sources)
## 1. 先看这页：从想法到第一集
一部 AI 连续剧需要同时管理两条线：**故事为什么继续发生**，以及**人物和世界怎样持续保持一致**。ComfyUI 主要负责执行生成与处理步骤；编剧、资产管理、表演判断和剪辑仍然需要明确安排。
建议先完成一集试播片，再扩为多集。首次试播可选择 1–2 位主要人物、少量场景和少量重要道具；这是控制试错范围的建议，不是艺术限制。
```mermaid
flowchart TD
A[项目目标与整季主线] --> B[系列设定与资产库]
B --> C[单集剧本与分镜]
C --> D[静态分镜预演与对白计时]
D --> E[代表镜头技术测试]
E --> F[按镜头小批次生成]
F --> G{画面 声音 连续性通过?}
G -- 否 --> H[修提示词或参考图 补拍或重剪]
H --> F
G -- 是 --> I[剪辑 字幕 混音与整片验收]
I --> J[更新本集终态与下集开场约束]
J --> C
```
如果阅读器不支持 Mermaid，可按这条文字顺序执行：
**立项 → 整季设计 → 资产库 → 单集剧本 → 分镜预演 → 试片 → 小批生成 → 审片修正 → 后期 → 跨集交接。**
开始前先回答六个问题：
- 谁是主角，他这一季一直想完成什么？
- 每一集结束后，局面具体发生什么变化？
- 哪些人物、衣服、场景、道具和声音需要反复出现？
- 哪些镜头必须清楚展示动作或证据，不能靠字幕解释？
- 采用原生音画生成，还是先锁配音/表演再做口型？
- 交付是横屏还是竖屏、每集多长、面向哪个平台？
**最先完成的产物**：一页项目说明、一份系列设定、第一集剧本、一组通过的角色参考图，以及 2–3 个代表性测试镜头。此时先验证制作能力，再决定扩大集数。
## 2. 网上 AI 系列案例能借鉴什么
### 2.1 主题单元系列与连续叙事，需要不同的管理方式
| 公开案例 | 已公开的信息 | 本手册建议借鉴的做法 |
|---|---|---|
| 《中国神话》 | 总台 2024-03-22 的介绍列出六个神话单元，并说明美术、分镜、视频、配音、配乐使用 AI | 先建立统一视觉语言，再制作各自闭合的单元；这类系列对同一主角跨集状态的要求相对不同 |
| 《三星堆：未来启示录》 | 博纳 2024-07-05 的介绍披露共同任务、持续人物、先导片及分集上线，并提及调研、人机协作和前期技术研究成本 | 先设计整季任务和人物关系，再拆每集；将考据、线索和人物状态作为长期资产维护 |
| 同一 IP 的后续系列实践 | 博纳 2025-03-31、2026-01-14 的公开说明涉及主线延续、数字资产与策划/预演/生成的衔接 | 把可复用资产与可修改预演前置，减少正式渲染后的方向性返工 |
来源：[总台《中国神话》发布页](https://www.cctv.cn/2024/03/22/ARTImxwnEZa0LYYPusv8E57A240322.shtml)、[博纳首季介绍](https://www.bonafilm.cn/news_del/100.html)、[第二季说明](https://www.bonafilm.cn/news_del/119.html)、[策划与预演流程说明](https://www.bonafilm.cn/news_del/153.html)。
这些资料支持“系列规划、资产复用、人工判断和技术研发都很重要”。它们没有公开足以重建全部制作过程的 ComfyUI JSON 或 LoRA 清单，不能据此断定它们使用了本文的 H3 组合；文中的制作建议也不等同于出品方公开的内部规程。
### 2.2 官方工具指南给出的实用启发
- Runway 的长片指南将短生成片段、人物多角度参考、场景参考和后期剪辑组织到同一生产链中。[长视频制作指南](https://help.runwayml.com/hc/en-us/articles/26871350018835-How-to-create-longer-videos-and-films)
- References 指南说明参考图可以用于复用人物、物体和场景。实际制作宜将人物与环境分开命名、分步迭代。[参考图指南](https://help.runwayml.com/hc/en-us/articles/40042718905875-Creating-with-Gen-4-Image-References)
- 视频提示词的规则随模型变化。某些模型适合简短运动描述，某些模型要求结构化音画指令；应读取对应版本的指南。[Gen-4 视频提示词指南](https://help.runwayml.com/hc/en-us/articles/39789879462419-Gen-4-Video-Prompting-Guide)
- 表演驱动工具把演员表演、角色外观和后期组合成另一条路线，适用于需要提前锁定对白与表演的项目。[Act-Two 指南](https://help.runwayml.com/hc/en-us/articles/42311337895827-Performance-Capture-with-Act-Two)
工具入口、参考数量和时长会变化。保存教程的发布日期、适用版本及自己的成功样例，不把旧视频教程的界面和数字直接当成当前规范。
## 3. 完整制作流程：做什么、交什么、何时通过
以下表格是本手册建议的 SOP。一个人可以承担全部角色，小团队则按“编剧/导演、资产、生成技术、后期/质检”分工。
| 阶段 | 具体要做什么 | 必须保存的产物 | 通过条件 |
|---|---|---|---|
| 立项 | 明确题材、观众、横竖屏、集数、每集时长、语言、发布渠道、可用设备和资源上限 | `project_brief.md` | 制作目标和交付规格明确 |
| 整季设计 | 写主角长期目标、主要阻力、季终变化，分配每集推进与伏笔 | `series_bible.md`、`season_outline.md` | 各集有因果推进，调换顺序会影响故事 |
| 风格与资产 | 定面孔、服装、场景布局、关键道具、配色与声音方案，给资产编号 | 参考图、`asset_registry.csv`、声线参考 | 同一资产多视角仍可识别，来源可追溯 |
| 单集剧本 | 写人物目的、阻力、行动、转折与结果，检查对白是否可表演 | `EP01/script.md`、对白表 | 事件可理解，人物通过行动改变局面 |
| 分镜 | 为每镜指定叙事作用、构图、动作、说话人、声音、参考资产和衔接 | `shots.csv`、分镜图 | 镜头之间能够剪接，重要信息有可见证据 |
| 预演 | 用静帧、临时对白和声音剪一个低成本版本 | `animatic.mp4` | 故事节奏、对白时长、场景关系成立 |
| 技术试片 | 试对白近景、正反打、关键动作/道具或多人镜头 | 测试片、通过参数、环境清单 | 人物、声音、动作及显存开销满足本项目需求 |
| 镜头生产 | 小批次生成，逐条记录任务、输入与参数，保留失败版本 | 工作流、job ID、原片、生成日志 | 每条结果可追溯，没有误用旧版本 |
| 每镜审片 | 看动作转折和结尾，核对身份、状态、台词、声源、口型和构图 | `qc/review.md`、选片清单 | 通过内容审核；执行成功不自动算可用 |
| 后期 | 粗剪后精剪，做字幕、声音衔接、调色、混音和输出 | 时间线、字幕、母版与发布版 | 故事流畅、技术检查通过、实际审听通过 |
| 跨集交接 | 写本集终态和下一集必须继承的事实 | `EP01/end_state.md` | 下一集不会重置人物知识、持物或关系 |
| 发布与归档 | 核对授权、标识、平台格式，备份全部依赖与成片 | 交付清单、来源表、备份记录 | 可发布，也能定位问题和继续制作 |
**管理建议**：每次只让一项明确的改动进入正式版本；把失败原因写清楚。修改角色主参考或模型版本后，应检查哪些已完成镜头受影响，不能继续混用。
## 4. 连续剧的核心：系列设定与跨集状态
### 4.1 系列设定要回答哪些问题
“系列圣经”可以理解为整部剧共用的设定手册，至少包含：
1. **故事规则**：时代、地点、现实/超自然规则、能力边界与代价。
2. **整季主线**：主角长期目标、对手、压力来源、季终必须回答的问题。
3. **人物关系**：谁相信谁、谁隐瞒什么、谁在何时知道关键事实。
4. **视觉设定**：角色、服装、场景、道具的稳定 ID 和参考版本。
5. **声音设定**：每个角色的声线参考、语言/口音、说话习惯和情绪范围。
6. **时间线与线索**：事件顺序、伏笔、揭示、回收状态。
### 4.2 稳定身份与变化状态分开记录
| 类别 | 例子 | 管理办法 |
|---|---|---|
| 稳定身份 | 林岚的脸、年龄范围、发际线、体型；红箱的外形和尺寸 | 资产库统一版本，不能随镜头自由改写 |
| 可变化状态 | 蓝外套湿了、右手受伤、红箱在谁手里、是否知道钥匙是假货 | 每场/每集更新，变化要有剧情原因 |
| 摄影变化 | 景别、机位、焦段、构图、日夜光线 | 镜头表明确写，并核对是否影响身份识别 |
固定 seed 只帮助控制随机来源，无法记录人物知道什么、是否受伤或拿着什么。人物 LoRA 也不承担剧情记忆。
### 4.3 每集都要更新的终态表
| 集末 | 资产/人物 | 地点与时间 | 当前状态 | 知识与关系 | 下一集必须继承 |
|---|---|---|---|---|---|
| EP01 | `CHAR_LIN` | 仓库，夜 | 蓝外套湿，右手持红箱 | 已知钥匙是假，尚未知卖家身份 | 不能突然拿到真钥匙；衣服干燥需要时间或换装 |
| EP01 | `PROP_BOX` | 林岚手中 | 关闭、封条破损 | 盒内物仍未揭示 | 下集不能无交代地恢复封条 |
下一集写剧本和生成提示词前，先读上一集这张表。能接住上一集造成的变化，才形成连续叙事。
### 4.4 哪些地方最容易穿帮
- 角色换角度就换脸、换耳饰或左右手。
- 伤势、泥水、破损服装在下一个镜头自动消失。
- 门窗位置、桌上道具和出入口方向变化。
- 镜头前后人物视线和运动方向不一致。
- 角色还未得知秘密，却说出了答案。
- 道具规则在下一集变了，或关键物品无交代地换了持有人。
这些问题需要剧本、资产库、镜头约束和审片共同解决，不能交给某一个节点包自动兜底。
## 5. 剧本、分镜、声音和预演
### 5.1 单集剧本怎么写
先写一句话：**谁想做什么，遇到什么阻力，作出什么选择，因此发生什么变化。**
每场戏至少标明：人物目的、阻力、转折、结束状态。对白要推动试探、请求、拒绝、欺骗、安抚等行动，避免人物排队讲设定。
两分钟试播片的节奏可参考下面的分配，但应随题材和表演调整：
| 时间段 | 主要任务 | 检查问题 |
|---|---|---|
| 0–10 秒 | 危险、异常、诉求或关系冲突出现 | 观众知道自己在看什么吗？ |
| 10–40 秒 | 建立目的和可核对的线索 | 后面的转折是否有铺垫？ |
| 40–85 秒 | 行动遇阻，局面变化 | 人物是否真的在做事？ |
| 85–110 秒 | 作出选择，承担结果 | 变化是否来自人物的选择？ |
| 110–120 秒 | 兑现本集，并开启下一集问题 | 已解决什么，还留下什么？ |
这是编排建议，不能为了卡秒数给每个镜头增加无意义停顿。悬念应来自局面变化，而不是在故事中途任意切黑。
### 5.2 镜头表必须包含的信息
每镜至少写：镜头 ID、叙事作用、参考图版本、景别/视线、核心动作、谁说什么、谁安静、环境声、目标可剪时长、前后状态和检查点。
**一镜尽量集中完成一个主要变化**。复杂交接、追逐、多人同时说话可以拆成若干可读镜头；需要全景证明的关键动作，仍应保留足够空间信息，不能全用脸部近景替代。
### 5.3 三种声音路线，先选再生产
| 路线 | 具体做法 | 适合情况 | 需要重点验证 |
|---|---|---|---|
| 原生音画一起生成 | 在支持音画联合生成的模型里直接给人物、台词和声音指令 | 短对白、环境互动、希望动作与声音一同发生 | 台词准确性、开口时机、同角色声线与实际口型 |
| 配音/表演先行 | 先录制或生成并确认最终声音，再用兼容工具驱动表演/口型 | 长对白、固定主演声线、细致表演 | 声音授权、音频长度、角色输入、驱动范围与同步 |
| 旁白叙事 | 旁白配合确实适合旁述的画面 | 书信、回忆、解说型叙事 | 旁白是否过度替代人物行动，画面是否只剩素材拼接 |
表演驱动输入的工作分工见 [Act-Two 官方指南](https://help.runwayml.com/hc/en-us/articles/42311337895827-Performance-Capture-with-Act-Two)；多人对话可以分角色表演、共享场景底片并后期组合，见[官方多人对话示例](https://help.runwayml.com/hc/en-us/articles/41748090660499-Creating-Multi-Character-Dialogues-with-Act-Two)。这些具体功能不是本机 H3 已验证能力的替代说明。
### 5.4 预演为什么值得先做
把静态分镜图、临时对白、主要声音按时长剪成一版。先检查：
- 台词在该时间内能自然说完吗？
- 听完一句话之后，有没有必要的反应时间？
- 没有旁白解释时，动作和道具证据能看懂吗？
- 场景方向、正反打和人物位置能对得上吗？
- 结尾能否接入下一集？
预演通过再正式生成，通常比渲染完一整集后修改人物动机更容易控制成本。
## 6. 角色、场景、道具资产怎么准备
### 6.1 建立可引用的资产库
| 资产 | 应准备的资料 | 审核重点 |
|---|---|---|
| 主角 | 清楚的正面、侧面/四分之三面、需要的全身和表情参考 | 不同视图确实是同一人；脸、体型、发型相符 |
| 服装 | 每套服装编号、正背面、颜色/材质和穿着状态 | 不把“同一个人”误当作“每集必须穿同一件衣服” |
| 场景 | 主场景图、必要反打/侧角、简单平面关系、日夜版本 | 门窗位置、光源和出入口不变；变化有标记 |
| 关键道具 | 外形、比例、颜色、材质、功能规则及使用状态 | 关键识别点和持有关系稳定 |
| 声音 | 已授权参考音、台词样本、角色声线说明、环境底噪 | 多集听起来属于同一人物；不只检查文字内容 |
角色与场景参考的通用制作思路可参考 [Runway References](https://help.runwayml.com/hc/en-us/articles/40042718905875-Creating-with-Gen-4-Image-References)。本手册建议将多角度单图与资产登记表一起保存；如果用拼版帮助设计，实际投喂前要确认模型是否理解拼版，必要时拆成单图。
### 6.2 推荐编号
```text
CHAR_LIN_FACE_v03.png
CHAR_LIN_COSTUME_A_v02.png
SET_WAREHOUSE_MASTER_NIGHT_v02.png
SET_WAREHOUSE_REVERSE_NIGHT_v02.png
PROP_RED_BOX_CLOSED_v01.png
VOICE_LIN_APPROVED_v01.wav
```
`v03` 表示经过审核的版本，不表示文件名数字最大就自动可用。每个正式资产写明 `approved`、来源、用途和替代了哪一版。
### 6.3 图像和视频参考分别解决什么
- 角色参考：为外观提供依据。
- 场景参考：为布局与气氛提供依据。
- 动作/表演视频：在支持该功能的模型里提供运动或表演依据。
- 首帧：规定镜头开始的构图与状态。
- 尾帧：在支持的模型里约束结束状态。
- 参考声音：在支持的流程里提供声线、声音内容或表演依据。
不要默认任何模型都支持全部参考类型。使用多模态参考时，要写清每份输入负责什么，避免模型把“人物来源”“动作来源”“场景来源”混在一起。
### 6.4 首尾帧续接的用途与边界
一个镜头的末帧可以作为下一个镜头的首帧，帮助连接某段动作；仍需检查重复帧、动作相位、运动方向、光线和身份。连续多次沿用有误末帧，还可能把偏差传到后续镜头。
建议将审核通过的角色/场景资产保留为基准，定期对照。首尾帧续接不能代替跨集状态表，也不能保证整个长镜头或整季自动稳定。
## 7. 怎样选择和组织生成工作流
### 7.1 按需要解决的问题选择
| 当前问题 | 可考虑的路线 | 先确认什么 |
|---|---|---|
| 需要稳定的角色、服装和构图 | 参考图编辑 → 图生视频 | 图像资产能否保持身份，视频模型是否会漂移 |
| 需要短对白与环境互动 | 支持原生音画的图生视频 | 目标语言、准确台词、口型、声线是否通过样片 |
| 需要固定声音、较长表演 | 最终配音/表演 → 兼容的口型或表演驱动 | 音频驱动方式、授权、时长和嘴型质量 |
| 需要具体姿态、深度或运动控制 | 模型支持的控制组件/参考视频/骨架等 | 控制模型、预处理器和主模型是否匹配 |
| 需要高动态、多角色、复杂接触 | 拆分覆盖镜头；必要时加入可控实拍或 3D 预演 | 空间、动作因果和身体接触是否可读 |
| 需要更高交付尺寸 | 验证后的生成/放大/后期路线 | 真正细节、身份和时间一致性是否改善 |
这是一张选择表，不是模型排行。优先使用已经能在目标设备上跑通、并通过内容审查的流程；新增模型时先做同一组代表镜头对照。
### 7.2 一个项目至少区分三类工作流
1. **资产工作流**：角色和场景图的生成、参考编辑、必要的修图。
2. **镜头工作流**：图生视频、原生音画、表演/口型或其他镜头任务。
3. **后期工作流**：裁切、编排、字幕、声音、调色、检查、导出。
三类不必全部放在 ComfyUI 画布里。把最稳定、最容易审查的工具用于相应步骤，并保存输入、输出与依赖关系。
### 7.3 先测试什么，再扩大什么
先挑 2–3 镜覆盖最大风险：一个对白近景、一组正反打/身份变化、一个关键动作或道具交互。通过后再做一场或一集。试播集完成跨集交接验证后，才扩大到多集。
成功导入工作流、节点能连上、任务执行成功，都只是技术执行层面的进展。角色、声音和剧情是否可用，要在实际输出中检查。
### 7.4 通用镜头提示词骨架
```text
镜头目标：观众在这一镜要理解什么变化。
参考资产：角色/服装/场景/道具 ID 与版本，分别承担什么作用。
开始状态：人在哪里、看哪里、拿什么、道具什么状态。
核心动作：一件主要动作及自然反应。
摄影：景别、视线、机位、必要且可执行的运镜。
声音：谁说什么、谁安静、画内/画外、环境声与音乐。
结束状态：下一镜必须接住的状态。
重点保持：真正重要的身份、物理状态或空间约束。
```
这个骨架用于整理导演意图，提交时要转换成所选模型的实际格式。某些图生视频模型更适合简洁的运动提示；本机 H3 则采用结构化音画文本。避免在人物特写里塞入整间屋子和全部画外道具，这可能诱发模型重新布景或展示不该入镜的物品。
## 8. ComfyUI 基础知识与节点
### 8.1 先把这些名词分开
| 名词 | 通俗理解 | 实际注意点 |
|---|---|---|
| ComfyUI | 执行模型和处理步骤的节点式环境 | 安装软件之后，还需要对应模型、节点和输入素材 |
| Workflow / 工作流 | 节点、连线与参数组成的一份配方 | JSON 通常不包含大模型、插件和全部参考图 |
| Node / 节点 | 完成加载、编码、采样、解码、保存等操作的模块 | 缺节点与缺模型是两种问题 |
| 自定义节点包 | 为 ComfyUI 增加功能的程序扩展 | 可能带 Python 依赖；只装可信来源，正式制作前验证版本 |
| 主模型 | 负责主要生成能力的权重 | 图像、视频、音频模型的架构与用途不同 |
| Checkpoint | 保存模型参数的检查点；部分整包也含编码器/VAE | 不能假定所有 checkpoint 都是一套完整生成组件 |
| UNet / DiT | 主生成网络常见的不同结构 | `UNETLoader` 这个节点名不代表其载入的每个新模型都采用 UNet 结构 |
| 文本编码器 | 把提示词变成生成模型能使用的条件表示 | ComfyUI 的 `CLIP` 接口名不表示底下必然是原版 CLIP |
| Conditioning / 条件 | 提示词、参考等经过编码后的控制信息 | 不是普通字符串，也不是生成后的图片 |
| Latent / 潜变量 | 模型内部处理的压缩表示 | 需要匹配解码组件，才能得到可看/可听的输出 |
| VAE | 在像素/波形与模型潜表示之间转换的组件 | 必须与模型匹配；视频 VAE 与音频 VAE 分工不同 |
| LoRA | 加载在基模上的轻量适配权重 | 依赖匹配基模，不能仅凭文件小就独立生成 |
| ControlNet 等控制组件 | 在支持的模型中加入姿态、边缘、深度等约束 | 控制模型、预处理器、主模型要配套 |
| IP-Adapter / 图像参考适配器 | 把参考图特征引入兼容流程的组件 | 不是所有图像/视频模型都可使用同一套适配器 |
| T2I / I2I | 文生图 / 图生图 | 图生图中的重做程度与参考保留要实际测试 |
| T2V / I2V | 文生视频 / 图生视频 | I2V 的参考仍不能保证后续每帧都正确 |
| R2V / 多模态参考 | 利用模型支持的图像、视频或声音作参考 | 各输入的用途、数量、格式限制由具体模型决定 |
| Upscale / 放大 | 提升输出像素尺寸的处理 | 增大尺寸与增加可信细节是两件事 |
基础概念依据：[ComfyUI 工作流](https://docs.comfy.org/basic-concepts/workflow)、[节点与数据类型](https://docs.comfy.org/basic-concepts/nodes)、[模型与加载器](https://docs.comfy.org/basic-concepts/models)。表中的通俗解释用于教学，不代表所有模型内部实现完全相同。
### 8.2 认识一条典型的图像生成链
```mermaid
flowchart LR
A[主模型加载] --> B[可选的匹配 LoRA]
B --> S[采样]
C[提示词与文本编码器] --> D[条件信息]
D --> S
L[初始潜变量或编码后的图像] --> S
S --> V[匹配的 VAE 解码]
V --> O[保存图片]
```
理解顺序即可：**加载生成能力 → 编码条件 → 在潜空间采样 → 解码 → 保存**。视频流程可能多出时间维、图像/声音参考、音频潜变量、视频组合等分支。
常见连线类型：`MODEL`、`CLIP`、`VAE`、`CONDITIONING`、`LATENT`、`IMAGE`、`AUDIO`。连线应匹配节点输入/输出类型。比如，采样结果通常是 `LATENT`，不能当普通图片直接使用；文字也不能接到 LoRA 模型输入上。
### 8.3 模型文件一般放在哪里
以下是常见逻辑目录，实际以安装方式、加载器及 `extra_model_paths.yaml` 为准：
```text
ComfyUI/models/
├─ checkpoints/ 部分整包模型
├─ diffusion_models/ 分体的主生成模型
├─ text_encoders/ 文本编码器或模型指定的联合编码器
├─ clip_vision/ 独立视觉编码器（按模板和加载器要求）
├─ vae/ 对应的 VAE
├─ loras/ LoRA 权重
├─ controlnet/ 兼容的控制模型
└─ upscale_models/ 兼容的放大模型
```
注意：
- 把文件放进正确的搜索目录后，还要确认文件名、子目录、版本、加载器和模型架构匹配。
- 文本编码器、模型指定的联合编码器与独立 CLIP Vision 的搜索目录可能不同。本机 H3 的 Qwen3-VL 走 `CLIPLoader`；独立视觉编码器按 `CLIPVisionLoader` 等实际加载器要求放置，见[官方加载器实现](https://raw.githubusercontent.com/Comfy-Org/ComfyUI/master/nodes.py)。
- `.safetensors` 是权重容器格式，同后缀文件可能分别是主模型、VAE 或 LoRA，不能互相代替。
- `.json` 通常是工作流/配置；它不会自动包含模型权重。
- `.ckpt`、`.pt`、`.pth`、`.bin` 等格式的兼容性要看加载器，不要只改后缀。
- 手动安装节点与依赖时，应使用运行 ComfyUI 的那套 Python 环境，避免装到了别的系统 Python。
- 分享工程时，同时提供节点/版本清单、模型来源及输入素材说明。
### 8.4 GUI JSON 与 API JSON
| 类型 | 主要用途 | 内容特点 |
|---|---|---|
| GUI 工作流 | 在画布中打开、检查和编辑 | 保存节点、连线、控件、位置和分组等信息 |
| API 执行图 | 脚本提交生成任务 | 通常按节点 ID 保存 `class_type`、`inputs` 和输出引用 |
| 素材/模型依赖 | 让工作流真正可运行 | 参考图、视频、声音、权重、节点代码、版本等 |
`.api.json` 是本项目采用的文件命名约定，具体格式仍应看内容。带工作流元数据的部分生成图片可以拖入画布恢复工作流；普通参考图片或被平台重压缩、清除元数据的图片，不保证有此能力。
依据：[GUI JSON 规范](https://docs.comfy.org/specs/workflow_json)、[官方 API 示例](https://raw.githubusercontent.com/Comfy-Org/ComfyUI/master/script_examples/basic_api_example.py)、[首次生成与工作流操作](https://docs.comfy.org/get_started/first_generation)。
## 9. LoRA 是什么、怎么用、何时需要训练
### 9.1 先理解作用
**LoRA = Low-Rank Adaptation，低秩适配。** 原始方法是在冻结预训练权重时，训练较小的低秩更新。可以简化理解为：
```text
适配后的能力 = 原基模 + 按强度加载的适配更新
```
因此，LoRA 文件通常比完整基模小，更便于训练、存储、切换或共享一种适配能力。它仍需要兼容的基模与其他生成组件；LoRA 文件小，也不等于整套视频推理只占很少显存。
技术依据：[LoRA 原始论文](https://arxiv.org/abs/2106.09685)、[Diffusers LoRA 训练说明](https://huggingface.co/docs/diffusers/training/lora)。
### 9.2 制作中常见的四类用途
| 用途 | 想解决的问题 | 在连续剧中如何使用 |
|---|---|---|
| 人物/角色 | 让模型更容易生成某个角色的外观或概念 | 配合角色参考和服装状态，测试多视角、表情和场景 |
| 风格 | 影响画风、材质、色彩等视觉倾向 | 先验证与角色参考组合后是否仍保持身份 |
| 动作/运镜 | 在支持的模型里学习某类运动或镜头倾向 | 适合特定运动偏好；精确动作仍需参考和审片 |
| 蒸馏/加速 | 配合专门的采样流程减少采样步数 | 按作者配套的基模、LoRA、采样器、调度器和引导设置使用 |
这四类是用途分类，不是四种通用文件格式。一个适配也可能同时影响多个方面。
**你当前使用的 H3 Turbo 8step/4step LoRA 属于加速用途。本批没有训练人物 LoRA。** 人物主要由参考图、外观约束、镜头设计和审片维持。
加速适配的一个官方例子是 [LCM-LoRA](https://huggingface.co/docs/diffusers/main/en/using-diffusers/inference_with_lcm_lora)，其调度和引导配置有配套要求；这并不表示 H3、Wan 或任意其他模型可以照用 LCM 的参数。
### 9.3 下载和加载前，核对这张表
| 必查项 | 你要找到的答案 |
|---|---|
| 基模与架构 | 它为 SD1.5、SDXL、FLUX，还是某一个具体视频模型训练？ |
| 精确版本 | 作者支持哪个版本、任务和量化/封装？ |
| 作用对象 | 修改主模型、文本编码器，还是其他组件？ |
| 加载节点 | 使用普通 `LoraLoader`，还是 `LoraLoaderModelOnly` 等专用加载器？ |
| 触发词 | 模型卡是否要求某个触发词或提示写法？ |
| 配套参数 | 是否需要专用 steps、sampler、scheduler、guidance 或其他组件？ |
| 强度 | 作者示例是多少，在你这组输入上对照测试结果如何？ |
| 授权与来源 | 来源可信、许可适用，训练素材的使用权是否清楚？ |
**同样是 `.safetensors`，不代表可以通用。图像模型的人物 LoRA，不能默认直接装进 H3 或 Wan。**
### 9.4 在 ComfyUI 中的加载步骤
1. 找到与目标基模匹配的 LoRA 和作者工作流说明。
2. 放入 `models/loras` 或已配置的模型搜索目录，按当前安装的方式刷新模型列表。
3. 在正确的 LoRA 加载节点中选中该文件。
4. 主模型接到该节点的 `model`；若流程需要文本编码器适配，按模板连接 `clip`。ModelOnly 流程没有同样的 CLIP 适配分支。
5. 把加载后的模型输出接入后续生成链，而不是继续使用未经适配的原模型分支。
6. 按作者要求设置触发词与配套采样参数，先生成一个小样。
7. 固定其他条件，做“基线/当前 LoRA 设置”的对照，保存可用结果和参数。
加载基础见 [ComfyUI LoRA 教程](https://docs.comfy.org/tutorials/basic/lora)，适配管理见 [Diffusers adapters 文档](https://huggingface.co/docs/diffusers/main/en/using-diffusers/loading_adapters)。
### 9.5 权重应该设多少
`strength_model`、`strength_clip` 表示适配影响程度，并非画质评分。没有适用于所有 LoRA 的“0.8 最好”或“1.0 必填”。
调试建议：
- 从作者已验证的示例开始，保留输入、seed 和其他参数。
- 一次只改一个强度或一个适配，观察身份、构图、颜色、动作和伪影。
- 多个 LoRA 逐个叠加测试，别一开始同时加载很多无法区分影响的适配。
- 人物、风格与加速 LoRA 混合时，检查它们是否有冲突或特殊配套要求。
- 本机 H3 Turbo 的 `strength_model=1.0` 是特定已验证组合，不是通用结论。
### 9.6 什么时候值得考虑训练人物 LoRA
适合进一步评估的情况：角色会反复出现、参考图路线在关键角度持续失效、确实有支持目标模型的训练方法，并且能承担数据整理、训练、测试和后续维护。
训练前先做这些事：
1. 冻结角色外观和目标基模，确认训练器真正支持它。
2. 整理有使用权的素材，去掉错误面孔、重复低质图和混乱服装标签。
3. 区分“要学会的身份”与“可以变化的服装/背景/姿态”，避免把它们误绑在一起。
4. 按训练器要求写标签，预留不同角度、表情、场景的测试输入。
5. 保存数据版本、训练设置、检查点与测试结果，用未参与训练的组合检查泛化。
6. 通过后才登记为正式资产；训练未通过时，仍可以保留原来的参考图制作路线。
这里不提供跨模型通用的图片张数、学习率、rank、epoch 或训练步数。它们与架构、数据、训练器和目标相关，应使用对应项目的官方训练指南。rank 是低秩适配的秩/容量参数之一，不是单独决定质量的开关。
用于视觉外观的人物 LoRA 不等同于声线资产。多集声音一致性仍需相应音频/联合模型能力、参考音频或配音流程，以及实际审听。
## 10. 参数、显存和常见故障
### 10.1 参数速查
| 参数 | 主要控制什么 | 调试时注意 |
|---|---|---|
| Seed | 随机噪声的来源之一 | 对照实验时固定，正式结果记录；不能单独锁脸 |
| Steps | 采样迭代数量 | 按模型和加速方案设置，不是越多必然越好 |
| Sampler | 采样每一步怎样推进 | 与模型、scheduler 配套，先用已通过模板 |
| Scheduler | 各步噪声/时间水平的安排 | 不等于 sampler，不能任意交换后期待同样结果 |
| CFG / Guidance | 一些流程中的条件引导强度 | 不同模型机制不同；高值不等于更高质量 |
| 正向/负向条件 | 在支持的流程里表达希望出现或避免出现的内容 | 不等于所有模型都有独立 negative 输入；也不保证绝对服从 |
| Denoise | 常见潜空间图生图中的重做程度 | 在这类流程里较低值通常保留更多输入结构；不是所有视频参考图的统一权重 |
| Width / Height | 输出尺寸与画幅 | 改变构图、显存与计算量；遵循模型尺寸约束 |
| Frames | 输出帧数 | 帧数可能受模型网格限制，不能只按秒数任意填写 |
| FPS | 每秒播放的帧数 | 同样帧数改变 FPS 会改变时长；以实际文件时间码检查 |
| Batch | 同时处理的样本数 | 增加显存压力；批量生产不等于必须提高 batch |
| Precision / Quantization | 权重/计算的精度或量化形式 | INT8、FP8、NVFP4 等需要模型、加载器与硬件支持，收益需实测 |
| Offload | 把部分组件转到 CPU/RAM 等位置 | 可能减少 GPU 峰值占用，也会改变内存与传输开销 |
采样接口依据：[KSampler 官方说明](https://docs.comfy.org/built-in-nodes/sampling/ksampler)、[官方实现](https://raw.githubusercontent.com/Comfy-Org/ComfyUI/master/nodes.py)。如果简化教程与节点代码、模型卡冲突，应核对具体版本和实际输出。
### 10.2 帧数、时长与分辨率
对于恒定帧率素材，计划时可以用：
```text
时长 ≈ 帧数 / FPS
本机 H3 样例：192 / 24 = 8 秒
```
实际交付仍要测文件。不同模型的帧数网格、音频长度与封装时间戳可能有额外约束。
生成较长镜头、增加画面面积或增加批量，通常会增加计算和显存压力，增长未必线性。先测目标组合，不按一张宣传表推算全项目。
放大解决空间尺寸；插帧处理时间采样；改变 FPS 涉及播放节奏。三者作用不同。不要把放大后的文件直接称为“原生 4K”，也不要把重复帧当作真实动作细节。
### 10.3 本机 H3 的特殊点
本项目使用 `BasicGuider` 与自定义采样链。它的接口不等同于经典 SD KSampler 的“正条件＋负条件＋CFG”。不要照着 SD 教程往这张 H3 图里套 CFG 7 或负条件结构。
限制项如何表达、音画提示如何编写，应看 H3 对应版本及已验证工作流。[BasicGuider 接口](https://docs.comfy.org/built-in-nodes/BasicGuider)、[H3 官方模型卡](https://huggingface.co/MiniMaxAI/MiniMax-H3)。
### 10.4 常见故障，按原因排查
| 现象 | 常见原因 | 优先动作 |
|---|---|---|
| 红色/缺失节点 | 核心版本或自定义节点缺失、导入失败 | 查节点来源和启动日志，在正确环境补依赖 |
| 下拉列表没有模型 | 路径、文件名、子目录或刷新问题 | 核对精确名称和搜索路径；不要随便选同后缀替代 |
| tensor shape / channel mismatch | 主模型、VAE、编码器或控制组件不匹配 | 回到该模型完整模板逐项对照 |
| CUDA OOM | 当前组合超过可用显存，或还有其他任务占用 | 先查队列和显存，再降低测试尺寸/帧数/batch，使用已支持的量化/offload |
| 更新后坏了 | 核心、前端、自定义节点或依赖版本不兼容 | 回到备份环境，按日志隔离变化，不把全套一起更新当作修复 |
| 视频黑/花屏/颜色异常 | 解码、组件、精度或色彩链问题 | 检查正确 VAE、源片和最小模板，再排查后期 |
| 没有声音 | 模型本来不生音频、解码/组合/保存未接上 | 检查模型能力、音频解码分支和最终媒体音轨 |
| 任务显示成功但无可用文件 | 保存节点、路径或下载/选择环节问题 | 查看输出记录、实际文件大小、probe 和内容 |
| 人物/道具变化 | 参考不足、动作复杂、描述诱发改场景或生成能力限制 | 减少变量、换参考、拆镜、合理裁切或补拍 |
| 台词错、多人抢话 | 声源和角色不清、句子复杂、模型生成偏差 | 简化单镜发言者与句子，核对实音；需要时换声音路线 |
官方排查入口：[模型问题](https://docs.comfy.org/troubleshooting/model-issues)、[自定义节点问题](https://docs.comfy.org/troubleshooting/custom-node-issues)。
### 10.5 正式制作时冻结环境
记录 ComfyUI、关键节点、模型文件/哈希、Python/PyTorch、驱动及关键设置。新版本先在隔离测试或另存流程中验证，避免一季制作中途混用未经测试的依赖。
PyTorch 明确说明，不同版本、平台或设备间不保证完全相同结果。因此，完整记录 seed 很有用，但仍应保存已验收原片。[可复现性说明](https://docs.pytorch.org/docs/stable/notes/randomness.html)
共享服务器不要随意清队列、重启或释放其他任务的模型。本机过去为减少特定连续作业的显存问题，在确认 running/pending 均空时执行过显式 `/free`；这是项目策略，不是每个 ComfyUI 项目必须照做的步骤。
## 11. 自动化、命名、版本和可追溯记录
### 11.1 推荐目录
```text
series_project/
├─ project_brief.md
├─ series_bible.md
├─ season_outline.md
├─ environment_manifest.md
├─ assets/
│ ├─ characters/
│ ├─ costumes/
│ ├─ locations/
│ ├─ props/
│ ├─ voices/
│ └─ asset_registry.csv
├─ workflows/ 已验证的母版与版本说明
└─ episodes/
└─ EP01/
├─ script.md
├─ shots.csv
├─ prompts/
├─ jobs/ 每次提交的API/GUI/参数/历史
├─ outputs/ 不覆盖的原片
├─ qc/ 抽帧、转写、审阅与拒绝理由
├─ post/ 裁框、音频、字幕与剪辑工程
├─ deliverables/
├─ selections.json
├─ end_state.md
└─ LOG.md
```
### 11.2 每次生成至少记录什么
| 记录 | 用途 |
|---|---|
| 项目/集/场/镜 ID | 知道结果属于哪里 |
| 版本、重试 ID、任务 ID | 区分基础镜、R1/R2 与失败尝试 |
| 原始 API 与 GUI JSON | 可执行与可阅读的工作流证据 |
| 提示词、模型、LoRA、seed、采样和尺寸 | 能对照修改发生在哪里 |
| 参考素材版本与哈希 | 避免提示词正确却用了旧图 |
| 输出路径、源文件哈希 | 锁定实际进入后期的文件 |
| 审阅结论与拒绝理由 | “新生成”不自动替代“已通过” |
| 裁切、时间区间、音轨来源和派生文件 | 说明后期实际做了什么 |
### 11.3 API 自动化的基本顺序
```text
上传输入素材
→ 构建并检查执行图
→ 提交 /prompt
→ 立即保存 prompt_id 与完整参数
→ 查队列/历史，或接收 WebSocket 事件
→ 下载实际输出
→ probe、画面/声音检查
→ 选入正式时间线
```
官方接口资料：[服务器 routes](https://docs.comfy.org/development/comfyui-server/comms_routes)、[消息与执行事件](https://docs.comfy.org/development/comfyui-server/comms_messages)。
自动化负责减少重复操作，不能自动替代导演与审片。HTTP 成功、节点执行成功、媒体技术检查成功，分别只是不同层面的结果。
### 11.4 连续剧的版本纪律
- 正式角色或场景参考放在明确的 approved 目录，废弃版本移到可辨别的位置。
- 已提交任务的原始工作流保持不变，修改后另建 R1/R2。
- 用选片清单决定最终来源，不按“最新文件”或“文件名最大”猜测。
- 改了角色参考、服装状态或主模型版本，检查受影响的镜头和集数。
- 中断恢复先看日志、任务 ID 和实际状态，避免把仍在运行的任务重新提交。
- 单 GPU 可以串行生成，CPU 上的剧本、审片和后期并行；不要用超大队列掩盖尚未验证的方向性问题。
## 12. 逐镜质检、剪辑、字幕和混音
### 12.1 每镜先查内容，再查技术
| 层面 | 必看内容 | 不通过的例子 |
|---|---|---|
| 剧情 | 选择、否定、证据和前后状态 | “不要开门”说成“开门”；关键物品换了 |
| 身份 | 脸、年龄、发型、服装、体型、声线 | 反打变成另一个人 |
| 物理与空间 | 手、接触、道具、位置、门窗、运动方向 | 沙漏被翻了但剧情要求没翻；门无因开启 |
| 表演 | 目的、反应、视线、开口时机、说话者 | 画外声出现时错误角色持续对口型 |
| 声音 | 实际台词、完整性、音色、杂音、音量、声源 | 错词、截断、意外对白、音乐盖住台词 |
| 构图 | 头脸、关键手部/道具、字幕区、画面边缘 | 为去掉错误而同时裁掉剧情证据 |
| 技术 | 时长、尺寸、帧率、音轨、编码与异常区段 | 无音轨、长黑场、卡帧、输出长度不符 |
抽帧应覆盖开始、关键动作、说话时段和结尾；高风险动作可以加密抽帧。六帧或十二帧的接触表是高效筛查，不能证明每一帧均无问题。最终还要实际播放整片并审听。
### 12.2 ASR 转写怎么用
ASR 是辅助证据，要与实际声音、口型、上下文和电平一起判断：
- “页/夜”“店/电”等完全同音字，可以按明确语境正字并记录。
- 数字形式、“啊”等语气词、少量额外词，要按实际对白决定字幕，不能无记录地改成原剧本。
- 关键否定、人物关系、名字、证据和规则说错，应补拍、重做声音/口型或重新剪辑。
- 静默或噪声片段可能出现低置信伪词；例如高 no-speech 情况下生成的字幕署名，不能直接认定演员说了这些话。
- 不用剧本作强提示去“证明”模型读对了；保留原转写、局部复核与判断理由。
- 转写不能判断声线是否悦耳、角色是否同一声音、情绪是否自然。系列配音必须由人实际审听。
### 12.3 哪些能后期修，哪些应补拍
**通常可考虑局部修整**：边缘多余人物、无需展示的错误道具、字幕区外的生成文字、适度构图偏差、音量差异、可明确处理的环境杂声。
**优先补拍或改设计**：主要人物换脸、关键动作发生错误、必须看见的道具变形、人物关系或台词核心语义错误、明显持续的口型不合、无法保留叙事信息的过度裁切。
裁切后必须实际查看；换音轨后核对同步与来源。派生环境声、降噪或交叉淡化可以使用，但应留下来源区间和处理记录，不能把处理过的声音记为未经修改的原声。
### 12.4 后期顺序
1. **粗剪**：先验证场景因果、信息顺序和人物选择。
2. **精剪**：去掉无效等待，保留必要反应与动作衔接，确定各镜可用区间。
3. **画面统一**：处理画幅、必要裁切和色彩，核对是否丢失剧情信息。
4. **对白和环境声**：保持声源合理，连接场景底噪，处理突变和杂音。
5. **音乐**：按情绪转折安排，避开重要台词；音乐与音效也要确认使用权。
6. **字幕**：按最终声音落时码，检查人名、否定、停顿、阅读速度与安全区。
7. **混音与导出**：测响度/真峰值并实际审听，再按平台规格输出。
8. **整片检查**：检查时长、分辨率、帧率、音轨、字幕、黑场和卡顿；更新本集终态表。
本机做法是 Python 调用 FFmpeg 完成规范化、拼接、字幕和混音，同时保留原始素材。也可以用熟悉的剪辑软件执行相同编辑意图。
### 12.5 交付检查表
- [ ] 角色、服装、空间和道具状态前后连贯。
- [ ] 重要台词、名字、否定和规则准确；最后一句没有被截断。
- [ ] 实际播放并审听：口型、声线、情绪、对白清晰度和转场自然。
- [ ] 字幕与最终音轨对应，位置安全、可读、不挡关键动作。
- [ ] 文件实际时长、尺寸、帧率、编码和声道符合本项目要求。
- [ ] 没有意外黑场、冻结、漏音轨、爆音或无原因的长静音。
- [ ] 发布版、无字幕母版、独立字幕和工程记录已保存。
- [ ] 片尾/平台声明与来源许可已核对；下集状态已交接。
响度目标以交付要求为准。例如本机这一批以约 -16 LUFS 为混音目标，并核对真峰值；它不是所有平台和所有内容的统一标准。把 32kHz 音频重采样到 48kHz，也不会补回原本不存在的高频细节。
## 13. 你当前这套 H3 流程的实际配置
本节依据 2026-10-28 已完成工程，而非对服务器当前状态重新测试。此前三部是**独立短剧**，已验证单片生产链；同一主角跨多集、换装、年龄变化及长期固定声线，还需要专项试片。
### 13.1 实际制作链
```text
剧本与镜头表
→ 内置 image_gen 制作/参考编辑关键帧（ComfyUI 外）
→ Python 通过 HTTP API 调用远端 ComfyUI 的 H3 图生视频
→ 抽帧、离线 ASR、视觉审阅与必要补拍
→ 本地 FFmpeg 做裁切、时间线、字幕与混音
→ 双版 MP4、SRT、工作流及验收记录
```
H3 官方模型卡说明其可以联合预测视频和音频潜变量，再分别解码；官方规格列出 24fps 与 32kHz 立体声等信息。具体本机采用的量化、加速、尺寸和画幅，以以下实际工作流为准。[H3 官方模型卡](https://huggingface.co/MiniMaxAI/MiniMax-H3)
### 13.2 已验证的模型与参数
| 项目 | 这批实际采用 |
|---|---|
| 服务器入口 | `http://192.168.10.51:8188/`；是否在线仍需操作当时检查 |
| 原底稿 | `production_pack_20260904/03_generation_cinematic/01_minimax_h3_i2v_base.json`，展开并逐镜参数化 |
| 主模型 | `minimax_h3_fl2va_pruned_int8_convrot.safetensors` |
| 文本/视觉编码器 | `qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors` |
| 视频 VAE | `minimax_h3_video_vae_fp16.safetensors` |
| 音频 VAE | `minimax_h3_audio_vae_fp32.safetensors` |
| 对白镜 LoRA | `minimax_h3_fl2v_turbo_8step_v1.0_comfyui_bf16.safetensors` |
| 静默/物件镜 LoRA | `minimax_h3_fl2v_turbo_4step_v1.2_768p_comfyui_bf16.safetensors` |
| LoRA 强度 | 两条加速路线均为 `strength_model=1.0` |
| 采样 | `res_multistep`，scheduler `simple`；对应 8/4 steps，denoise 1.0 |
| 引导 | `BasicGuider`；没有经典 KSampler 的 CFG/negative 配置 |
| 单镜源片 | 960×544，192 帧，24fps，8.000 秒 |
| 成片画布 | 960×540；有效画面 960×408，上下各 66 像素黑边 |
| 输出 | H.264/AAC 双声道，原生 32kHz 音频；中文字幕版与无字幕版 |
以上是**特定模型、设备和工程中已通过的组合**。不能据此保证所有显卡、模型版本或更大尺寸都能运行，也不代表 4 步一定适合所有静默镜、8 步一定保证对白正确。
### 13.3 节点结构怎样读
```text
UNETLoader → LoraLoaderModelOnly → BasicGuider / BasicScheduler
CLIPLoader + 视频VAE + LoadImage + 镜头提示词
→ MiniMaxH3ImageToVideo：产生条件与初始潜变量
RandomNoise + KSamplerSelect + BasicScheduler + BasicGuider
→ SamplerCustomAdvanced
→ 视频 VAEDecode + 音频 VAEDecodeAudio
→ CreateVideo（24fps）→ SaveVideo
```
这是一份教学性的主链说明；精确输入与输出引用以实际 API JSON 为准。
实际可核查样例：
- [8 步对白镜 GUI](F:/AI视频项目/short_drama_batch_20261028/C03_fantasy/jobs/S06R1/workflow_gui.json)
- [同一对白镜 API](F:/AI视频项目/short_drama_batch_20261028/C03_fantasy/jobs/S06R1/workflow_api.json)
- [4 步静默插镜 API](F:/AI视频项目/short_drama_batch_20261028/C03_fantasy/jobs/S11/workflow_api.json)
- [参考图来源与提示词](F:/AI视频项目/short_drama_batch_20261028/C03_fantasy/imagegen_prompts.json)
- [最终选片时间线](F:/AI视频项目/short_drama_batch_20261028/C03_fantasy/final_timeline.json)
- [实际裁框与来源记录](F:/AI视频项目/short_drama_batch_20261028/C03_fantasy/post/per_shot_crops.json)
本机保存的 ComfyUI 工作流位于：`短剧合集_20261028／各片名／S01…S15`。其中 GUI 版本可用于画布查看，API 版本用于脚本提交。某个研究目录里出现过的候选模板，不等于它实际参与了成片。
### 13.4 这一批真实遇到的问题
| 问题 | 实际处理 | 可迁移的经验 |
|---|---|---|
| 喜剧开场台词约到 6.2 秒才出现 | 补拍，开口提前至约 0.86 秒 | 提示词时间只是引导，必须测实片时机 |
| 水壶镜头转向了新墙面，发明相片等物件 | 固定桌面插镜补拍，去掉多余的全屋描述 | 物件镜只承担本镜任务，避免重新布景 |
| 父亲举出错误饭袋，沙漏和袋子叠放 | 补拍干净父亲近景 | 画外物品不必在特写中反复要求展示 |
| 女儿镜头后半段多出陌生男人 | 实际查看近景裁框，去掉右边错误且保留脸嘴 | 裁切可以修边缘问题，但要保留剧情信息 |
| 犹豫镜提前出现书写痕迹 | 改为面部反应，首次明确落笔留给下一镜 | 后期要维护因果和动作时序 |
| ASR 同音、数字形式或静默伪词 | 保留证据、正字/差异记录与时码；不以剧本硬盖声音 | 机器转写有误差，需分情况复核 |
| 静默反应镜出现不确定短脉冲 | 使用同镜干净底噪整理环境声，保留源区间与派生音轨记录 | 声音编辑应可追溯，不能假称原音完全未处理 |
这批共生成 **52 条素材，选用 45 个独立镜头，完成 3 部各 120 秒短剧、6 个 MP4，保存 90 份最终选片 GUI/API**。7 条是补拍备选，其中存在未采用的版本。数量记录见[批次完成清单](F:/AI视频项目/short_drama_batch_20261028/BATCH_COMPLETED.json)。
三部技术检查失败项均为 0。两项预期提示是没有独立软字幕轨、保留 32kHz 音频；已提供烧录字幕版与独立 SRT。这不等于审美、口型或音色在任何观看条件下都绝无瑕疵。
### 13.5 把这套路线升级为连续剧，要补什么
- 建立长期角色、服装、场景、道具与声线资产库。
- 把独立短片剧本升级为整季主线、分集因果和跨集状态表。
- 增加“同脸跨集、换角度、换服装、同声线”的专门试片。
- 按表演与剪辑需要安排镜头，8 秒只是既往项目的选择。
- 保留已通过的 H3 路线，新增人物 LoRA/参考音频等能力单独验证，不直接叠入整季。
模型路线还可参考 [Wan2.2 官方任务清单](https://github.com/Wan-Video/Wan2.2)：TI2V、S2V、Animate 等是不同任务，不能把整个模型家族概括为同一种声音或动作能力。选择替代路线时，先核对具体任务、输入与依赖；本机这批成片实际采用的仍是上面的 H3 组合。
## 14. 第一次制作的行动清单与成本记录
### 14.1 第一轮按这个顺序做
1. 填项目说明，先定第一集与系列关系、横竖屏和时长。
2. 写一页系列设定和简短分集纲，不急着生成整季。
3. 完成第一集剧本，检查人物通过什么行动改变局面。
4. 做主角、主场景和关键道具参考，登记正式版本。
5. 写镜头表、对白和声音设计，先剪静态预演。
6. 用风险最大的 2–3 镜验证身份、说话、动作和设备性能。
7. 锁定通过的工作流、组件与声音方案，分小批生成。
8. 生成后立即审片，记录“通过/修整/拒绝”和原因。
9. 完成第一集剪辑、混音、字幕与整片审听。
10. 更新集末状态，测试下一集开场能否继承，再扩大生产。
**第一轮成功标准**：完成一集可理解、可播放、可追溯的试播片，并能做出接住它的下一集开头。先用这个结果验证方法，再估算一季。
### 14.2 怎样估算时间与资源
不要只计算“最终分钟数 × 生成速度”。还包括资产制作、候选筛选、失败重试、声音、剪辑和审核。
```text
预计生成开销 = 各类镜头的候选数量 × 对应实测单镜耗时
总制作工时 = 前期 + 资产 + 生成管理 + 审片/补拍 + 后期 + 交付
可用率 = 实际可用素材 / 总生成素材（先说明按条数还是按秒数计算）
```
建议记录下面的实测表，而不是套别人的单一数字：
| 镜头类型 | 生成规格/工作流版本 | 单次耗时 | 通过条数/生成条数 | 每条可剪秒数 | 主要返工原因 |
|---|---|---|---|---|---|
| 对白近景 | 待测试 | 待填写 | 待填写 | 待填写 | 错词/声线/开口时机等 |
| 关键道具 | 待测试 | 待填写 | 待填写 | 待填写 | 变形/拿法/状态等 |
| 多角色/全身动作 | 待测试 | 待填写 | 待填写 | 待填写 | 身份/接触/站位等 |
本机上一批按条数计算是 45/52 的最终选片比例，但它只反映那批低复杂度、固定参考、每镜 8 秒的任务，不能作为未来整季、多人大场面的保证。
本地推理占用 GPU、内存、电力与制作时间；外部 API 节点还可能产生按量计费和额度限制。使用前先识别节点是在本机执行还是调用服务，保留试片开销，不要把“安装了 ComfyUI”理解成所有节点都免费运行。
### 14.3 什么情况下暂停扩大批量
- 连续几条镜头出现同一类身份、道具或声音错误。
- 角色主参考或剧本规则还没有定稿。
- 合格镜头拼起来仍无法理解故事。
- 声音或口型方案尚未通过人耳/观看验收。
- 工作流或模型版本正在频繁改变。
这些时候先修基准、拆解任务或调整设计，比继续生成大量相似失败片更有价值。
## 15. 可直接复制的项目模板
以下均为**待填写模板/虚构示例**，不代表某部网上作品的真实生产文件，也不是可直接提交的生成工作流。
### 15.1 项目说明 `project_brief.md`
```markdown
# 项目说明
项目名：
题材/观众：
系列形态：连续主线 / 同世界单元 / 其他
一句话故事：
季数与本季集数：
单集目标时长：
横竖屏/交付尺寸/FPS：
语言与声音路线：
核心人物和场景：
已验证工作流与版本：
尚未验证的风险：
时间/生成额度/设备资源上限：
交付物：发布版、无字幕母版、SRT、工程、状态交接
```
### 15.2 系列设定 `series_bible.md`
```markdown
# 系列设定
卖点：
世界/时代/时间线：
不能违反的规则：
主角长期目标：
主要阻力与对手：
本季开始状态 → 季终变化：
## 人物
ID：CHAR_A
外观基准与 approved 参考版本：
可变化服装/状态：
人物目的、缺点、关系：
已授权声线参考与语言：
## 场景与道具
场景 ID、平面关系、光源与出入口：
道具 ID、外观、规则、初始持有人：
## 分集与线索
EP01：目的 → 冲突 → 选择 → 结果 → 下集问题
EP02：继承什么 → 推进什么 → 结果
线索：埋入集/角色知情范围/计划回收集/当前状态
```
### 15.3 资产登记表
| ID | 类别 | 正式版本/路径 | 稳定特征 | 可变状态 | 来源/许可记录 | 审核结论 |
|---|---|---|---|---|---|---|
| CHAR_A | 人物 | 待填写 | 脸、发型、体型 | 服装、伤势、情绪 | 待填写 | 待审核 |
| SET_A | 场景 | 待填写 | 门窗、桌、出入口 | 日夜、天气、损坏 | 待填写 | 待审核 |
| PROP_A | 道具 | 待填写 | 外形、颜色、尺寸 | 开闭、持有人、损坏 | 待填写 | 待审核 |
### 15.4 镜头卡
```yaml
shot_id: EP01_SC01_SH003
story_function: 用可见证据促使主角改变判断
asset_versions:
character: CHAR_A_v03
costume: COSTUME_A_v02
location: SET_A_NIGHT_v02
prop: PROP_A_CLOSED_v01
start_state: 人物在柜台左侧，关键道具关闭
framing_and_eyeline: 中近景，人物看向画右的对手
main_action: 看见破损封条，停顿后抬眼追问
dialogue: "封条是谁拆的？"
silent_characters: 对手不说话
sound: 室内底噪与短促衣料声
end_state: 道具仍关闭，主角开始怀疑对手
generation_duration: 按所选模型与测试结果填写
intended_edit_duration: 按预演填写
quality_checks: [身份, 道具状态, 实际台词, 视线, 可剪衔接]
```
### 15.5 H3 音画提示词教学样例
此样例展示本机首帧模式使用的结构。提交前仍要确认实际参考图、帧数、模型版本与节点接口；镜头里的外观以审核参考为准。
```text
For the target video, at 0.00 seconds into the target video, (from [Shot 1]) is fully referenced.
integrated_multimodal_description: [Shot 1] One continuous live-action shot. Preserve the approved character and visible setting from the reference. Locked medium close-up. The woman notices the broken seal below frame, pauses, then looks toward the other person offscreen right. She says with synchronized lips: [Chinese] 封条是谁拆的？ She closes her mouth afterward and waits for a response. Keep her face, hairstyle, clothing and eyeline consistent. No extra person or new object enters this close-up.
overall_soundscape: Quiet indoor ambience, a small cloth movement, and the single clear Mandarin line. The offscreen person remains silent.
non_diegetic_music: None.
```
这个反应近景应与前一镜的封条特写配合使用：观众先看到破损证据，再看人物追问。提示词中写出的时间和动作不是验收结果；生成后仍要核对实际开口、声源和结束姿态。H3 的多参考模式与首帧模式并非同一套提示格式，使用时应看对应官方指南和已验证样例。
### 15.6 每镜审片记录
```markdown
# 审片记录
镜头 ID / take / prompt_id：
工作流版本与源文件 SHA：
实际查看的时间点或接触表：
身份/服装/道具/空间：
主要动作与前后状态：
原定台词 / 实际转写 / 审听结论：
口型、声源、开口时机：
字幕或画面边缘问题：
决定：通过 / 局部修整 / 补拍 / 弃用
理由：
最终来源、裁框、时间区间和音轨处理：
复核人/日期：
```
### 15.7 最终选片清单的结构示例
```json
{
"episode": "EP01",
"shots": [
{
"id": "EP01_SC01_SH003",
"selected_take": "R01",
"source": "outputs/EP01_SC01_SH003_R01.mp4",
"source_sha256": "填写真实哈希",
"edit_in_seconds": 0.0,
"edit_out_seconds": 5.0,
"crop_xywh": null,
"audio_source": "同源音轨或记录其他来源",
"review_record": "qc/EP01_SC01_SH003_R01.md"
}
]
}
```
`5.0` 是模板示例，不是所有镜头的固定可用时长。派生音频另写来源与处理记录，混用不同 take 的音画时必须再核对同步。
### 15.8 单集末交接
```markdown
# EP01 结束状态
最后确认的剧情时间/地点：
各人物当前目标：
各人物已经知道 / 尚不知道的事实：
人物关系变化：
衣着/伤势/脏污：
关键道具位置/持有人/开闭损坏状态：
本集回收的线索：
尚未回收的线索：
EP02 开场必须继承：
本次采用的正式资产和工作流版本：
```
### 15.9 交付包
```text
EP01_发布版.mp4
EP01_无字幕母版.mp4
EP01_字幕.srt
EP01_封面.png
EP01_全片接触表.png
EP01_验收记录.md
EP01_最终时间线.json
EP01_结束状态.md
源素材、工作流、资产来源与依赖版本清单
```
## 16. 公开发布、授权与资料来源
### 16.1 发布前的必要确认
保存图片、视频、音乐、声音及训练素材的来源和使用许可；使用可识别真人的面孔或声线时，确认相应授权。模型权重开放下载不等于任意商用；还应阅读模型与适配的具体许可。比如 [H3 模型卡](https://huggingface.co/MiniMaxAI/MiniMax-H3)列出了其社区许可，不能仅凭“本地能跑”判断可用范围。
向中国境内网络平台公开发布生成合成内容时，应按适用规则主动声明，并使用平台提供的标识功能。《人工智能生成合成内容标识办法》第十条对此有明确要求；生成服务与传播服务还有各自义务，实际发布要核对平台当期要求。[网信办原文](https://www.cac.gov.cn/2025-03/14/c_1743654684782215.htm)
请保留应有的生成合成来源和标识，不以修改元数据或去除来源标识来冒充实拍。技术导出检查不能替代素材授权与发布要求核查。
### 16.2 本手册采用的主要来源
资料检索与链接核对于 2026-10-28 至 2026-10-29，手册于 2026-10-29 整理完成。动态产品文档可能更新，运行前应核对对应版本。下面的链接支持相应概念或公开事实，不代表全部平台/模型都已在你的设备上测试。
| 类别 | 来源 | 支持范围 |
|---|---|---|
| 系列案例 | [总台：《中国神话》启播](https://www.cctv.cn/2024/03/22/ARTImxwnEZa0LYYPusv8E57A240322.shtml)，2024-03-22 | 六集主题系列及公开 AI 应用环节 |
| 连续叙事案例 | [博纳：《三星堆：未来启示录》上线介绍](https://www.bonafilm.cn/news_del/100.html)，2024-07-05 | 持续人物/任务、调研与人机协作 |
| 系列后续 | [博纳：第二季说明](https://www.bonafilm.cn/news_del/119.html)，2025-03-31 | 主线延续、数字资产与人工主导流程的公开描述 |
| 生产组织 | [博纳：策划、预演与生成方案](https://www.bonafilm.cn/news_del/153.html)，2026-01-14 | 判断与预演前置；不作为效果保证 |
| 长片组织 | [Runway：How to create longer videos and films](https://help.runwayml.com/hc/en-us/articles/26871350018835-How-to-create-longer-videos-and-films) | 短片段组织成长片、角色/场景 plates 与剪辑 |
| 参考资产 | [Runway：Gen-4 Image References](https://help.runwayml.com/hc/en-us/articles/40042718905875-Creating-with-Gen-4-Image-References) | 人物、物体和场景参考，命名与迭代 |
| 提示词 | [Runway：Gen-4 Video Prompting](https://help.runwayml.com/hc/en-us/articles/39789879462419-Gen-4-Video-Prompting-Guide) | 特定模型的运动描述与简洁迭代 |
| 表演 | [Runway：Act-Two](https://help.runwayml.com/hc/en-us/articles/42311337895827-Performance-Capture-with-Act-Two) | 表演输入与角色外观的分工 |
| 多人对白 | [Runway：Multi-Character Dialogues](https://help.runwayml.com/hc/en-us/articles/41748090660499-Creating-Multi-Character-Dialogues-with-Act-Two) | 分角色处理、共同底片与后期组织 |
| 工作流 | [ComfyUI：Workflow](https://docs.comfy.org/basic-concepts/workflow) | 节点流程与工作流概念 |
| 节点 | [ComfyUI：Nodes](https://docs.comfy.org/basic-concepts/nodes) | 节点与数据类型 |
| 模型 | [ComfyUI：Models](https://docs.comfy.org/basic-concepts/models) | 模型与加载组件 |
| LoRA 加载 | [ComfyUI：LoRA 教程](https://docs.comfy.org/tutorials/basic/lora) | 路径、加载节点、模型/编码器强度 |
| LoRA 原理 | [Hu 等：LoRA 原始论文](https://arxiv.org/abs/2106.09685)，2021 | 低秩适配方法 |
| LoRA 训练 | [Hugging Face Diffusers：LoRA](https://huggingface.co/docs/diffusers/training/lora) | 训练与适配的基本方法 |
| 适配加载 | [Diffusers：Load adapters](https://huggingface.co/docs/diffusers/main/en/using-diffusers/loading_adapters) | 加载、缩放与适配管理 |
| 加速适配 | [Diffusers：LCM-LoRA](https://huggingface.co/docs/diffusers/main/en/using-diffusers/inference_with_lcm_lora) | 加速适配需要配套流程的例子 |
| 采样 | [ComfyUI：KSampler](https://docs.comfy.org/built-in-nodes/sampling/ksampler)、[官方代码](https://raw.githubusercontent.com/Comfy-Org/ComfyUI/master/nodes.py) | 参数与实际接口 |
| H3 引导 | [ComfyUI：BasicGuider](https://docs.comfy.org/built-in-nodes/BasicGuider) | MODEL/CONDITIONING 接口，不能照搬经典 CFG 链 |
| H3 模型 | [MiniMaxAI/MiniMax-H3](https://huggingface.co/MiniMaxAI/MiniMax-H3) | 官方模型架构、任务和规格及许可 |
| 视频任务差异 | [Wan-Video/Wan2.2](https://github.com/Wan-Video/Wan2.2) | TI2V、S2V、Animate 等任务区别 |
| GUI 格式 | [ComfyUI：Workflow JSON](https://docs.comfy.org/specs/workflow_json) | 画布文件结构 |
| API | [官方基本示例](https://raw.githubusercontent.com/Comfy-Org/ComfyUI/master/script_examples/basic_api_example.py)、[routes](https://docs.comfy.org/development/comfyui-server/comms_routes)、[messages](https://docs.comfy.org/development/comfyui-server/comms_messages) | 提交、状态与执行事件 |
| 排错 | [模型问题](https://docs.comfy.org/troubleshooting/model-issues)、[自定义节点问题](https://docs.comfy.org/troubleshooting/custom-node-issues) | 模型/节点/依赖的分类排查 |
| 复现 | [PyTorch：Reproducibility](https://docs.pytorch.org/docs/stable/notes/randomness.html) | 版本、平台和随机性的复现边界 |
| 发布标识 | [网信办：《人工智能生成合成内容标识办法》](https://www.cac.gov.cn/2025-03/14/c_1743654684782215.htm)，2025-03-14 发布 | 公开传播时的声明/标识要求 |
### 16.3 本机证据与研究笔记
- [本批工程入口](F:/AI视频项目/short_drama_batch_20261028/README.txt)
- [完成数量与技术指标](F:/AI视频项目/short_drama_batch_20261028/BATCH_COMPLETED.json)
- [本机案例核对笔记](research/local_case.md)
- [网上系列案例研究笔记](research/series_workflow.md)
- [ComfyUI 与 LoRA 技术核对笔记](research/comfy_basics.md)
本手册中的项目模板、测试顺序、状态表、审核门槛与分工安排，是为当前制作需求编制的建议 SOP；应随题材、团队和样片结果调整。