我做这个项目的出发点很直接：我想实现自动剪辑，然后赚钱。

我是做 AI 内容的，也有程序员背景。既然 AI 已经能够读文件、写代码、调用工具，那我想试一件事：把视频制作中能够明确描述的步骤交给它执行，把自己更多的时间留给选题、内容和最后的判断。

但一句“帮我自动剪辑”里面，藏着太多没有说明的事情。稿子怎么写？声音从哪里来？字幕怎样跟上？人物为什么要抬手？画面应该讲出什么？视频能播放以后，又怎么判断它值得发布？这些环节只要有一个没接上，就可能得到一条技术上能打开、内容上却说不清楚的视频。

所以，我把项目做成了一套有输入、有中间产物、有检查位置的流程。我的目标是让它持续产出自己愿意发布的作品，再用真实的作品和反馈验证商业机会。

这篇文章把整条路线展开：项目思路、工程创建、项目指令、口播稿、配音、时码、三视图、细节图、笔触图、场景图、人物动作、B-roll、音乐、样片、长片、验收和变现。你可以从头跟做，也可以先找到自己卡住的环节。

我当前的主路线是 Codex 组织和修改工程，Remotion 渲染画面，豆包生成声音，Whisper 辅助定位时码，FFmpeg 检查与封装。教程采用我当前的浅色手绘人物与浅色立体讲解画面。工具能力、服务权限和素材许可，需要在你自己的环境里确认。

我已经制作并归档过这套流程的教程视频。文中的“三份资料变报告”是用来解释步骤的小案例：读者仍需亲自完成自己的配音、时间轴和样片，不能把讲解视频里的示意动画当成一次从空目录开始的完整复现记录。

准备好一个空文件夹，再准备一份愿意认真修改的小稿子。先做 5 秒测试，再做约 30 秒的有声作品。下面开始。

01 为什么我要做自动剪辑，以及钱可能从哪里来

我想赚钱，但需要先知道自己准备为谁创造价值。对我自己的账号来说，价值来自持续讲清楚 AI 工具、工作流和实际问题；对潜在客户来说，价值可能来自把他们的资料变成清楚、统一、可修改的视频。两种目标会共用制作能力，交付标准却不完全一样。

做自己的内容，我更关心选题是否有价值、观众是否听懂、画面有没有帮助理解。做客户项目，我还要关心原始资料、品牌要求、修改范围、交付格式和截止时间。只会输出一条漂亮视频，还没有解决后续怎样修改和交付的问题。

因此，项目开始时，我把“赚钱”拆成几条可以分别验证的方向：先用视频经营自己的内容账号；有稳定案例以后，尝试明确范围的制作服务；流程能够在别人的环境里运行以后，再考虑教学或工具产品。这些是准备验证的方向，不是已经取得的收入。

不要把一次视频制作的成本，只算成配音费和生图费。选题、资料核查、写稿、试听、检查错误姿态、修改镜头、回复问题，都占用时间。AI 完成一个环节以后，如果你还要花很久修复，节省下来的时间可能很有限。

我会记录一条作品从开始到交付分别花了多少人工时间，实际发出了几次付费请求，哪些修改是必需的，哪些是因为前面没说清楚。如果同类作品做第二次，前面的规则和组件确实减少了重复劳动，工厂才开始产生价值。

第一阶段不用同时做剪辑服务、课程、SaaS 和所有平台。先选一个可重复的小产品，例如“把一份已确认的 AI 教程口播稿做成有角色、有字幕、有流程演示的横屏视频”。输入明确，输出明确，修改意见才容易积累成下一次能用的规则。

你现在要写下的，是赚钱目标、目标读者和第一种交付。 不需要先给自己编一个收益数字，也不需要先设计复杂的订阅系统。

复制指令 01｜把想法变成第一阶段范围

我想建立一个自动剪辑视频项目，最终通过内容或制作服务赚钱。第一阶段先做中文 AI 教程/科普视频。

请帮我把目标拆成：目标读者、他们的问题、第一种固定交付、需要我判断的部分、可以自动执行的部分。优先设计一个约30秒的验证案例，再说明扩展成长片需要增加什么。

商业部分列为待验证假设，不写成已实现收入。先给出范围和成功标准，不搭网站、不购买服务、不发布内容。

02 先定义一条具体视频，再定义工厂

一个项目如果只有“自动化”这个方向，很容易不断加入工具，却一直缺少能交付的作品。我建议先把第一条视频的任务写成一句话：一个什么样的人，遇到了什么问题，我们用什么过程帮助他得到什么结果。

本文的小案例是“三份资料变报告”。人物面对三份资料感到困惑，随后保留原文件、提取要点、按主题归类、留下冲突，最后形成带来源的报告。它能同时检查角色、场景、资料卡、声音、字幕和操作过程，输入规模又足够小。

选择案例时，尽量让结果看得见。比如“一张发票进入表格”“三个问题被分到不同队列”“一段稿子生成带字幕的片段”。只讲“效率提升”“工作变简单”，画面设计会缺少具体对象，最后容易变成很多词语依次出现。

给第一条作品限定边界：横屏、一个固定角色、一到两组场景、一段完整口播、一个主要流程。不要一开始就要求多语种、多角色、直播素材、自动热点、自动发布和客户管理同时完成。每增加一项，都增加输入和检查条件。

我给第一阶段设置了三个实际产物：能播放的 5 秒无声测试；使用正式声音的约 30 秒样片；能够继续修改的工程和制作记录。样片长度只是规划值，实际时长跟着配音走。语言自然说完，比强行卡在整数秒更重要。

从样片往后扩展时，共用的是已经确认的组件、字体、布局和制作规则。本期的声音、时码和镜头仍由本期内容决定。否则，新题目可能配上旧音轨，旧角色动作又跟着旧字幕出现，看起来像延续工程，实际上已经串期。

此时可以建立一张检查卡：观众能否说出发生了什么；关键操作能否在画面上看见；字幕能否在手机上读完；声音是否完整；修改意见能否定位到一个具体位置。这张卡会贯穿后面的制作过程。

先跑通小产物，再扩展范围。三个阶段都有可以打开的真实文件。

复制指令 02｜定义贯穿案例

本期案例为“三份资料变报告”。三份自写资料分别包含需求、进度、待解决问题；报告包含结论、依据、待确认事项。

先规划约30秒口播视频：人物提出困惑→原文件保留→提取要点→按主题归类→冲突交给人确认→形成带来源的报告→人物反馈。

列出需要准备的稿件、角色参考、场景、演示资料与声音，以及每项的检查标准。先不估算动作秒数，不把案例设计写成已运行结果。

03 这套系统怎样工作：文字怎样变成视频

先看全流程：选题和资料进入稿件，确认后的稿件进入配音，正式声音进入识别与时码校对，稿件和时码一起进入镜头表，镜头表决定人物、场景、信息对象和动作，工程按每一帧的状态渲染画面，最后把人声、音乐和画面组合成文件。

这条链里，每个工具回答的问题不同。Codex 帮我读取要求、组织文件、写脚本、改组件、调用已有工具。声音服务负责把文字变成音频。识别工具提供发声位置的候选。渲染器负责把工程中定义的画面状态输出为视频。

大模型可以提出一个镜头方案，但它写出的方案还需要通过实际工具实现。文本里说“人物指向资料”，并不代表已经有合格的人物图；说“已对齐字幕”，也不代表对应声音被检查过。执行结果应该落在文件、记录和画面里。

Remotion 的画面可以理解成一个随帧号变化的函数：收到当前帧，就显示那一帧的文字、图片和对象位置。你可以定义“第一个资料卡已经出现，第二个还没有出现”，再由帧号控制状态。视频的宽、高、帧率、总帧数构成基础参数。Remotion 基础机制

为什么我还要保存这么多中间文件？因为它们让修改有方向。配音错了，回到声音；声音没问题但字幕提前，回到时码；字幕正确但画面不说明问题，回到镜头；工程预览正常但最终文件失真，回到渲染和编码。

如果只保存 MP4 和聊天记录，隔几天想修改一个步骤，会很难确定当时用了哪份稿件、哪版音轨和哪组图片。我希望每条成片都能沿着文件关系找到自己的来源，然后从出问题的那一步继续。

也要理解上下文的限制。AI 当前看到的文字和资料有限，对话很长时，不能假定所有旧细节都持续被准确保留。项目文件、简短状态和明确的下一步，是让工作能够继续的依据。它们需要主动维护，并且与实际文件保持一致。

复制指令 03｜画出输入和输出关系

为本项目建立制作依赖说明：定稿→正式人声→原始识别→校对时码→镜头表→资产→画面工程→混音→审片→交付。

每一步列出输入文件、输出文件、执行工具、检查方法和失败后回到的位置。未知工具或缺失脚本明确标记，不编造命令。说明哪些步骤可本地执行，哪些需要外部服务。

04 创建本地项目，先确认你到底在哪里工作

我使用 Mac 上的 Codex 桌面应用。先建一个空目录，命名为 AI_Video_Factory，把它添加为本地项目，再从这个项目开始对话。第一条检查就是让 Codex 报告绝对工作路径，并列出目录里已经存在的文件。Codex 项目与对话

这是很小但很有用的动作。电脑上可能有历史实验、下载的工程、复制过的素材包，它们的名字还很相似。工作目录错误，后面的安装、写文件和输出都可能发生在别的地方。等渲染完成才发现找错工程，会浪费很多检查时间。

接着检查 Node.js、npm、Python、FFmpeg 和 ffprobe。Node.js 运行画面工程及相关脚本；Python 处理配音与时间数据；FFmpeg 处理音视频；ffprobe读取媒体信息。Codex 能帮你完成检查，但你需要看懂它到底找到了什么。

基础检查命令如下。它们的输出应该包含真实版本；提示找不到命令，就说明当前执行环境尚未找到对应工具。

node --version npm --version python3 --version ffmpeg -version ffprobe -version

不要只凭桌面上安装了一个软件，就认定脚本能够使用它。图形界面的安装位置、终端里的 PATH、Python 的虚拟环境、项目使用的 Node 版本，可能并不相同。让 Codex 把实际执行路径也写进环境记录。

缺少依赖时，先列出名称、用途、来源和版本关系。在大陆网络下，优先考虑稳定且维护中的国内镜像，同时核对关键版本和包内容。镜像解决下载问题，不能替代兼容性检查；不要为了下载快随意降低到未知版本。

Remotion 相关依赖应保持相互匹配。建立后把版本写进锁文件，后续就知道当时用了什么。不要把我某次作品的版本号当成永久推荐值；更新依赖以后，要重新跑测试视频，确认当前组合确实可以使用。

环境阶段结束时，应该得到一份环境报告，明确当前目录、工具路径、版本、缺失项和建议动作。不要让“安装完成”直接跳成“视频制作成功”。下一节会让工程输出一个实际文件。

复制指令 04｜检查环境

先报告当前绝对工作目录，列出已有文件，确认这是本次AI_Video_Factory项目。

检查Node.js、npm、Python、FFmpeg、ffprobe的真实路径和版本。缺少工具时给出用途、安装来源、版本兼容关系与影响。不要修改全局配置或删除已有内容。

新增依赖优先考虑可信国内镜像，核对官方版本；记录实际安装来源和锁定版本。返回环境报告及下一步最小渲染方案。

05 第一条测试只做 5 秒：把最小工程跑起来

环境可用以后，让 Codex 建立最小 Remotion 工程。它至少需要依赖说明、工程入口、一个画面组件、Composition 注册和一条真实渲染命令。每个文件都应存在于当前项目里，不能只给出示例目录而没有实际建立。

Composition 可以理解成一条可渲染视频的登记：用哪个组件，画幅多大，多少帧，每秒多少帧。这次固定 1920×1080、30fps、150 帧。第一帧编号从零开始，5 秒的最后一帧是第 149 帧。完整时长由总帧数除以帧率得到。

画面只放三张资料卡。第一张先出现，第二张随后加入，第三张最后出现，末尾显示“工程可以渲染”。第一条测试不需要人物图、配音、音乐或语音模型。它先证明文字和图形可以沿时间变化，并输出到视频文件。

让 Codex 将实际入口、Composition ID 和输出路径写进项目命令。Remotion CLI 的渲染操作包含这三项；具体名称对应你已经建立的工程。渲染命令说明

npx remotion render src/index.ts TestVideo render/test.mp4

上面是教学命令形式：只有入口确实叫 src/index.ts、Composition 确实注册为 TestVideo，才能照着执行。若你的工程使用别的入口，就使用实际命令。我的正式作品也有自己的渲染脚本，没有要求所有工程都使用同一个文件名。

输出以后打开 test.mp4，从头播放到尾。检查中文有没有缺字，三张卡的顺序是否正确，末尾有没有出现，画面是否黑屏、卡住或只有一帧。再用 ffprobe 看实际分辨率、帧率和时长，确认文件与计划一致。

如果失败，先定位是哪一层。依赖错误，检查锁定版本；入口不存在，核对路径；Composition 找不到，检查注册；图片找不到，检查资源路径；中文显示方框，检查字体。不要在尚未得到可播放文件时继续添加复杂画面。

这一阶段最好把命令、错误原因和修复写进记录。以后更换机器或升级依赖，再执行同一测试，能很快知道变化是否影响工程。测试的价值来自它真的输出了一个文件，并且你看过结果。

复制指令 05｜建立并渲染测试工程

在当前目录建立最小Remotion工程，设置1920×1080、30fps、150帧，Composition名为TestVideo。创建实际入口与画面组件，依赖版本保持匹配并写入锁文件。

制作三张资料卡依次出现、最后显示“工程可以渲染”的5秒无声测试。写出并执行实际渲染命令，输出render/test.mp4。

报告入口、Composition、依赖版本、命令、输出文件和ffprobe结果。失败时先修复该问题。把测试命令保存在项目规范里，等待我打开实际视频检查。

06 文件怎么组织：公共工具与每一期作品各放哪里

测试跑通之后，开始组织文件。我希望打开项目时能直接回答三个问题：通用规则在哪里，本期素材在哪里，已经通过的输出在哪里。这三个问题如果混在同一个目录，后续很容易把旧稿、旧声音和新镜头放到一起。

根目录保存跨作品的规范、通用工具、参考资产和最终归档。每一期则建立自己的作品目录，保存正式稿、声音、时码、素材、镜头、工程和验收记录。公共文件负责约束做法，作品文件负责记录这一次实际做了什么。

可以按下面的结构起步。它是教学目录建议，里面的目录只在产生真实内容时建立；如果已有工程采用其他清楚的结构，不需要为了名字一致而迁移所有文件。

AI_Video_Factory/ ├── AGENTS.md ├── Wiki/制作规范.md ├── Resources/角色参考、模板索引、音乐来源 ├── .agents/skills/video-factory/SKILL.md ├── scripts/公共检查工具 ├── Projects/实际日期/作品名/ │ ├── input/正式稿、资料清单 │ ├── audio/正式人声、原始识别、校对时间轴 │ ├── assets/本期角色、场景、真实截图 │ ├── storyboard/镜头表、人物表演节拍 │ ├── production/本期画面工程 │ ├── render/测试、样片、章节、审片版 │ ├── MEMORY/MEMORY.md │ └── 总设计文档.md └── final_video/已终验成片

我现有的初始化脚本只负责建立独立作品目录、输入占位和记录文件，它会拒绝覆盖同名项目。它没有自动完成配音、生图、镜头设计或成片。刚从空目录开始的读者，可以先让 Codex 建目录，流程稳定后再把重复动作做成自己的脚本。

原始资料保留，清洗过的资料、改写稿和正式稿分别存。图片也分原件和工程副本。比如把角色参考复制到本期素材目录，只是让工程能读取它，不代表可以随意改掉公共参考原图。

重要文件最好带明确版本，说明谁通过了哪一版。pilot-v2.mp4 比“最终最终.mp4”更容易追踪，但单靠文件名仍不够：记录里还要写这版改了什么、是否已经确认、对应哪份声音和源码。

新作品开始时，先核对作品名、稿件首段、工程目录和输出文件名。这四项应讲同一件事。如果标题是 AI 工具教程，目录却来自另一条商业故事，先修正对应关系，再做后面的请求和渲染。

复制指令 06｜建立本期目录

根据已确认的作品名与稿件，建立Projects/实际日期/作品名/独立目录。日期由我本次确认，不沿用历史作品日期。

保存本期input、audio、assets、storyboard、production、render和MEMORY。建立总设计文档，记录输出规格、输入路径、公共规则入口、当前阶段与下一步。没有真实内容时不创建大量空文件。

核对作品名、稿件、项目路径与输出名一致。已有同名项目先报告，不覆盖。此步骤只建立与登记文件。

07 项目指令怎么写：把反复纠正的问题写成约束

我会把长期要求写进 AGENTS.md。Codex 会读取适用的项目指令，文件位置与目录层级会影响实际应用范围，所以第一次使用时要让它报告读到了哪份文件。AGENTS.md 的发现规则

项目指令应该帮助执行具体决策。比如“原稿只读”“正式音轨只存本期目录”“先交付 A/B 静态图”“收费前说明预算”“机器检查后仍等待人工验收”。这些句子可以落到明确动作，比“你是一位顶级导演，请输出爆款”更方便检查。

我不会把所有视觉参数复制进好几份文件。画框、字幕、头像和配色在制作规范与布局契约中定义，AGENTS 只要求读取这些入口。否则一次改字号，需要同步很多地方，几份文件很容易出现不同值。

第一版项目指令可以从下面这份简化模板开始。它是给读者新工程的范本，之后要根据自己实际确认的工具和风格补充。

视频项目指令

• 开工先读取制作规范、公共状态和本期记录，报告当前路径。
• 原始资料保留；正式稿未经确认不改写。
• 本期稿件、声音、时间轴、素材和工程存入独立作品目录。
• 文件缺失就报告缺失，不编造截图、音频、路径或运行结果。
• 先跑通测试工程，再定稿、配音、校对时码、设计镜头。
• 先确认镜头表，再分别确认A-roll与B-roll静态预览。
• 静态图通过后制作有声样片，样片通过后从同一母版扩展。
• 时间来自本期正式音频；不按字数平均分配动作时间。
• 收费请求或外部上传先展示任务、素材、用量及费用上限。
• 每次用户确认后记录通过的文件、版本、问题与下一步。
• 技术检查与人工验收分别报告，未运行的检查明确标记。
• 完整版终验后归档；清理先列具体范围，再单独确认。

规则写完，要用一次小任务检查它实际有没有生效。例如让 Codex 读取正式稿，然后只登记不改写；让它准备一段配音请求，但不要提交。检查返回的文件和状态，看看它是否理解了步骤边界。

当你提出一次修改意见，也要判断它属于哪里。“这张卡片太小”可能只是本期问题；“所有 B-roll 都避开左下头像”则是公共布局要求。将一次临时偏好升级为永久规则之前，先明确它是否适合下一期内容。

公共规范有冲突时，先列出两处原文和影响，再确定本次采用哪一条。不要让 AI 悄悄改掉整个项目，也不要把历史决定抹掉后假装从来只有一种做法。清楚的当前入口，会让未来的新作品少读很多旧材料。

复制指令 07｜编写并检查项目指令

基于本项目已确认的范围，编写简洁AGENTS.md。公共行为、视觉参数、本期状态分别链接到对应文件，避免重复维护。

将原稿保留、作品隔离、收费确认、静态图和样片门禁、单一母版、验收与清理写成可检查的动作。说明每条规则适用范围。

读取生成的文件，报告实际生效路径。用一个只登记资料的小任务检查指令，不执行外部请求。发现文件之间冲突先列出，等我明确本次做法。

08 Skill、脚本、MEMORY 各管什么，如何建立自己的流程

项目指令定义“在这里工作要遵守什么”，Skill 定义“做这类任务要怎样完成”。脚本则把需要重复执行的确定动作写成程序，例如读取音频参数、转换格式、生成清单或检查时间连续性。三者配合以后，流程才有实际执行入口。

Skill 是一组说明和可选资源。入口 SKILL.md 包含 name、description 和步骤，需要时再读取更详细的参考说明或脚本。这种按需读取能让初始上下文保持清楚；一个文件很长，也不代表模型一定会自动使用它。Skill 官方结构与加载位置

项目里的一个最小范本可以放在 .agents/skills/video-factory/SKILL.md：

---

name: video-factory description: 制作中文口播和流程讲解视频；覆盖定稿、声音、时码、镜头、样片与交付。普通转码不使用。

口播视频工作流

先读项目指令、制作规范和本期记录，核对作品名与路径。 输入不齐时列缺口；分批提供资料时等待上传完毕。 确认定稿后准备正式配音，收费与上传按项目要求确认。 用真实音频生成候选时码，复听疑点后确定制作基准。 生成镜头表，确认视角与素材，再交付两张独立静态预览。 静态图通过后制作有声样片；样片通过后从同一母版扩展。 按章检查，完整观看后归档，并保留可修改源文件。 真实脚本入口、参数和检查方式在实际存在后补入。

写好以后，在任务中明确要求使用 video-factory，让 Codex 报告读取的 Skill 路径和下一步。再检查它引用的脚本是否存在，命令是否能运行。不要因为出现了一张 Skill 卡片，就把它当作制作链已经打通。

MEMORY 保存另一类信息：当前作品在哪里停下，哪版已经通过，哪里还有问题，下一步是什么。它可以记录“正式人声已确认，时间轴有三处待复听”，不需要再抄一遍角色和字体规范。

每个状态后面都带文件。比如“样片第二版通过”，对应具体 MP4 和母版源码；“字幕还有问题”，对应短语编号和检查位置。下一次对话重新读取这些记录，再核对文件，比依赖一句“接着上次做”更稳妥。

流程还不稳定时，先保留清楚的说明，使用已有工具。只有反复发生、能够明确输入输出的动作，才值得补脚本。不要为了显得自动化，就建立一堆没人运行过的程序入口。

复制指令 08｜建立并使用流程 Skill

为这套已跑通测试的工程建立video-factory Skill。先写使用条件、输入输出和执行顺序，再链接制作规范与本期记录。不要编造未存在的工具或脚本。

显式使用该Skill，报告实际读到的路径、下一步需要的输入、会产生的文件与检查方法。将本期已完成事项和待办写入本期MEMORY，并用真实路径核对。

09 如何选题和做资料：先找到观众真正需要看见的过程

做 AI 教程时，我先问：观众卡在哪一步，哪一段过程值得展示，做完之后他会怎样调整自己的用法。题目有一个明确问题，镜头才有需要展示的动作。只把新名词汇总起来，可能信息很多，却很难形成一条完整视频。

例如“AI 很强”过于宽泛，“自动字幕改对文字后为什么仍然对不上声音”就很具体。观众已经遇到过问题，你能展示错误位置、声音、原稿和修改后的结果。这个题目天然包含前后变化，也有可以立刻尝试的检查方法。

资料优先从官网、官方文档、项目仓库和原始发布者获取。涉及软件版本、按钮、额度、价格或限制，记录查询日期与对应版本。旧截图中的按钮存在，不能证明当前账号仍然能使用它；别人的体验也不能直接改成自己的亲历。

我会把资料分成三个用途。真实证据用于说明软件实际完成了什么；解释素材用于让观众理解机制；装饰素材用于建立风格和情绪。它们在成片里的位置可以相邻，来源和作用却应该清楚。

演示“三份资料变报告”时，自己编写三份简单资料就够了。需求资料写目标与范围，进度资料写已完成和阻塞，问题资料写两处需要判断的冲突。报告中的每条结论能回到对应资料，动画才有明确依据。

若要展示某个产品真实整理这些资料，就需要实际操作记录、输入和输出。只在画面中把资料卡变成报告，是流程示意。这样的图能帮助理解，但不能代替真实产品测试，也不能证明资料里的结论正确。

对每项关键说法，写清它属于已核对事实、个人判断还是教学假设。事实带来源，判断带理由，假设带条件。口播不必读出整张资料表，但制作记录应留下来源，方便发现问题时回头检查。

资料阶段的产物是一份选题说明、一组有来源的材料，以及缺口清单。如果某个关键结果无法核实，可以换成能证明的例子，或者在稿子里明确说明范围。不要为了钩子更强，给画面补一个不存在的收入后台。

复制指令 09｜整理选题和证据

围绕我给出的选题，整理观众的问题、值得演示的过程和看完可以采取的行动。优先核对官方或原始资料，记录日期、版本、链接与可用截图。

将每个关键说法标为事实、判断或教学假设；真实证据、解释素材、装饰素材分别登记。列出缺口与可替代案例，不编造功能、运营数字或测试结果。先提交选题与资料表，再写口播。

10 如何写口播稿：每一段都要让人听得懂，也能拍出来

我的口播稿先解决内容，再进入配音。视频里的观众不能像阅读文章一样随时回看上一句，所以一个句子尽量只推进一个意思。遇到概念，先用具体对象解释，再补术语；遇到操作，先说目标，再说动作和检查位置。

开头可以从观众已经认识的问题开始。“你让 AI 写好了视频工程，为什么还是没有一条能发布的作品？”比“今天我们全面解析先进自动化技术”更容易进入主题。随后给出本条视频能帮他完成的具体任务，而不是许诺万能效果。

正文常用“遇到的问题 → 怎样做 → 为什么这样做 → 看哪里确认”的结构。比如先听整条配音，是因为后续字幕和动作都依赖声音；改了一句稿子，需要检查受影响的音轨和时码。原因说清楚，读者以后换工具也知道哪些步骤不能跳过。

为镜头留出具体名词和动词。口播说“三份原文件留在输入区，提取的要点进入报告”，画面能直接安排输入区、要点卡和报告。如果只说“实现高效整合”，后面还要猜测应该让什么对象做什么动作。

本文案例的完整口播如下，可以作为第一次练习的定稿候选。先读一遍，按自己的说话习惯调整，再确认版本。

面对三份资料，你是不是也想直接得到一份报告？先别急着合并。我们先保留原文件，再从每份资料中提取要点，把相同主题放到一起。每条结论都标清来源，信息冲突的地方单独留下，交给人来确认。这样，把三份资料整理成一份报告，就不是把文件塞进一个框，而是让输入、整理和结果都看得见。

稿件阶段就检查英文名、数字和容易误读的词。显示文字和配音输入可以有不同的写法，但必须留下一份对应说明。例如画面显示英文产品名，声音使用确认过的读法；这种调整解决发音，不能顺便改变事实或删掉关键条件。

将口播正文与制作注释分开。画面提示、字幕建议、资料链接和验收说明放在另一份文件里。否则配音程序可能把“这里展示某张图”也读出来。正式 TTS 输入应清楚地对应已确认的口播正文。

最后自己出声读一次。连续出现的长句、抽象词或重复解释，朗读时会很明显。你也能检查结尾是否真正收住，观众看完该做什么。确定之后保存版本；配音以后改稿，就要重新处理依赖的声音和画面。

复制指令 10｜写完整可朗读正文

根据已确认的选题和资料，写一份可以直接朗读的完整中文口播稿。开头给具体问题和本条收获；正文逐步说明做法、原因、产物和检查位置；结尾给下一步行动。

保留我的表达习惯，短句推进，不把提纲写成正文。涉及工具机制时准确解释边界，未核实的数字和经历不补写。画面提示、来源与制作注释放在正文外。

另列需确认的发音、数字与事实。先让我确认全文，再保存正式稿和对应TTS输入，不调用配音。

11 配音前先定音色、输入文本和费用范围

配音之前，我会确认三件事：这份稿子是不是最终要读的版本，音色是不是适合内容，这次请求允许做到什么范围。正式音频生成以后，字幕、人物反应和信息出现都将围绕它安排，所以这一阶段值得认真听和检查。

我的项目采用豆包语音合成 2.0，规范里的默认音色为 ICL_uranus_zh_female_huoponvhai_tob，创作语速设定为正常速度。这个编号是现有项目的选择，读者应核对自己账号是否有对应音色和服务权限，也可以选择自己已经确认的声音。

先用一小段文字试听。测试里包含一句正常叙述、一句转折、几个英文缩写和数字，能更容易发现问题。只听一段“你好，欢迎观看”可能觉得自然，读正式工具名时才发现发音不合适，后面就要重做。

试听也是一次真实用量，不能把它当作不会计费的准备动作。请求前记录测试文本、预计计费依据、最大请求次数和费用上限；失败后是否允许再试，也要写明。尤其不要让自动重试不断提交同一段稿子。

密钥保存在本机私密配置，代码读取环境变量。我的工程使用 VOLCENGINE_TTS_API_KEY 和 VOLCENGINE_TTS_VOICE_ID 作为变量名。变量名可以公开，具体值不进入文章、截图或录屏。检查只报告存在与否和实际鉴权结果。

当前进程读不到变量时，还要检查项目是否按设计加载了配置文件。文件存在、变量有值、服务鉴权成功，是三个不同状态。前两项可以离线检查，最后一项需要获准的实际请求，不能互相替代。

声音也要考虑表达。教学内容里，停顿是否帮助理解，强调是否准确，章节切换是否自然，比单纯追求快更重要。如果你准备真人讲述，仍可以沿用同一条后续制作路线，只是正式音轨改为自己的录音，先处理明显噪声和重复段。

复制指令 11｜准备试听，不自动提交

读取本期正式口播和当前官方配音文档，核对音色、权限、请求限制、音频格式与计费依据。只报告凭据变量是否有值，不显示任何值。

准备一小段包含英文名、数字和转折句的试听文本。展示最大请求次数、预计用量和费用上限，以及失败后是否允许重试。等我确认后才提交试听；完整配音另按确认后的范围执行。

配置文件要安全加载，录屏和日志不得泄露凭据。试听结果与正式稿保存在本期目录。

12 正式配音怎样生成：流式返回与完整音轨

我的实际配音脚本采用 HTTP 单向流式接口：一次提交确认后的文本，服务陆续返回音频数据，脚本收集数据，确认完成后保存一条完整人声。它不要求把每一句口播分别生成再拼起来。豆包 HTTP 单向流式文档

这里的“流式”描述返回方式：音频可以分批到达。它与“这份稿子被拆成多少次计费请求”不同。整篇提交一次以后，可能收到很多数据块；块数多，不代表脚本又提交了很多次文本。

我的现有脚本在提交前核对文本哈希和授权记录，再用独占方式创建请求登记文件，避免重复执行时无意提交第二次。登记内容包含文本版本、请求次数、预算、开始时间和完成状态。发生异常以后，保留收到的数据与诊断，不自动删除记录重新提交。

接口返回的编码必须真实处理。当前官方文档的流式场景推荐 PCM，我的脚本接收 PCM，再按实际采样率、声道数和位深写入 WAV 容器。给一个原始数据文件改后缀，不能让它自动成为结构完整的 WAV。

公开文档示例、项目里的音频规范和接口字段也要对应。规范中的“正常语速”是创作设定，实际请求字段怎样表示，读取当前接口说明。不要把图形界面的倍速数值直接写进另一个接口字段。

服务正常结束后，检查输出时长、采样率、声道和文件可读性。我当前项目的人声规范为 44100Hz 单声道。音频时长应从实际样本或媒体参数取得；稿件多少字只能做粗略规划，不能拿它安排精确动作时间。

整篇一次生成可以保持统一音轨，但仍要核对当前接口输入限制。我的项目曾有整篇请求成功的记录，这只能证明那份文本在当时配置下完成。新稿超出限制时，先提出方案，不能直接承诺任何长度都能照搬。

配音完成以后，人声原件单独保存。音乐、效果和最终混音放在后续版本。这样，调整 BGM 音量就不会影响已经确认的人声，也不需要为了音乐再次请求语音合成。

复制指令 12｜生成统一正式人声

按已经批准的文本、音色、最大请求次数和费用上限，生成本期统一正式人声。提交前核对文本哈希与请求登记，不自动重试，不重复提交已在处理的请求。

根据当前接口真实响应保存音频，核对结束状态和数据完整性。若返回PCM，按真实声道、采样率和位深封装WAV，不只改后缀。

保留原始响应音频与脱敏用量记录，输出audio/vo-full.wav、实际时长、媒体参数和剩余问题。人声单独保留，暂不混音乐。

13 完整试听：声音错了，后面越自动越容易一起错

拿到文件以后，先完整听一遍。听感检查和媒体参数检查各有用途：文件结构正常，可以说明它能读取；一句话是不是漏了词、一个缩写是不是读错、停顿是不是切断意思，仍需要听对应声音。

第一次听内容，不急着看动画。重点检查开头有没有截字，工具名是否清楚，数字是否符合稿子，转折有没有自然停顿，最后一句是否完整。听到疑点就记录播放器时点和原稿位置，后面能直接回到同一段。

第二次检查连续性。长段叙述有没有忽然变速，某一处呼吸是否突兀，章节间是否挤在一起，尾部静音是否合理。很多问题在听单句时不明显，连续听才会发现它怎样影响整段节奏。

如果只是识别工具把正确发音写错，保留人声，校对识别结果。如果声音本身读错，就处理声音或重新确认配音输入。把字幕改成正确词语以后，观众仍会听到错误发音，这种问题不能由文字修正代替。

需要重生成时，保存新版本，记录受影响的范围。整条人声变化以后，原有的时码可能失效；即使文字相同，新音频也可能改变停顿和发声位置。后续镜头必须绑定新一轮测得的时间。

可以用局部试听合集提高检查效率：把疑点前后各留一些上下文，连续输出成一个检查音频，同时保留它们在原音轨里的位置。局部合集方便定位，但它不能证明你已经听过整条正式人声。

我会把声音的状态写清楚：技术可读、试听通过、正式人声确认、还有哪些发音待检查。工程记录里仍有复听标记时，就继续保留它们。最终视频被人看过，也不能反过来写成独立逐字听审全部完成。

复制指令 13｜核对人声并登记疑点

检查正式音频的实际时长、采样率、声道、可读性和疑似异常静音。给我完整试听文件，另列英文名、数字、关键句与尾句的重点位置。

收到我的听审意见后，区分声音读错与识别写错。疑点记录原音频时点和原稿位置。必要时做局部试听合集，但不宣称它代替整片听审。

新声音保存新版本，列出要重新对齐的范围。未经确认不重新发起收费请求。

14 用 Whisper 获取候选时码，为什么仍然要校对

正式声音确认以后，下一件事是知道每个词或短语什么时候说出来。我的路线使用 faster-whisper 运行 large-v3，开启词级时间戳，保存原始识别，再将识别文本与正式稿对应。项目支持 word_timestamps=True，结果中包含词语起止时间。faster-whisper 官方项目

识别不是从正式稿里自动读出时间。模型听的是音频，它可能把一个词听成另一个词，把中文数字写成阿拉伯数字，也可能漏掉一小段。正式稿提供正确文字，声音提供发声位置，两者需要比较后再形成制作时间轴。

先保留原始识别文件，包含片段、词语、时间和可用的置信信息。再建立对照报告：哪些文字匹配，哪些被替换，哪些未找到可靠锚点。不要直接用正式稿覆盖全部识别文本，然后把差异数写成零。

数字的书写差异可以建立比较用的规范化视图，比如把“二十一”与“21”对应起来。这个视图用于匹配，不改掉原始识别。英文标识符、产品名和口语缩写也要有明确处理，避免拆成不自然的字幕片段。

我常按五到十五个字的短语组织字幕，再根据语义和阅读速度调整。短语不是机械凑字数：完整的产品名应尽量保持完整，一句中的转折和因果也应被看懂。过短会频繁闪换，过长会让观众读不完。

候选时间轴里，某些边界可能落在同一个 Whisper 词项内部，需要估计；某些原稿文字未匹配到可靠词项，只能列为疑点。这些时间不能伪装成逐字测量结果。标出位置，回听声音，必要时对局部重新识别或人工调整。

如果模型结果暂时没有输出，还要核对任务是否仍在运行。识别可以是持续处理，初始空白并不一定是失败。检查进程、日志和实际输出，不要为了等得久就连续启动多个相同任务，占用资源又混淆版本。

这一阶段的产物至少包含原始识别、与定稿的差异、候选短语时间轴、待复听清单。复听与修正以后，才把选定版本作为画面制作基准，并把仍未消除的不确定性留在报告里。

复制指令 14｜生成与校对候选时码

输入本期正式稿和已确认人声，用faster-whisper large-v3生成词级时间戳。先检查模型缓存、依赖与资源，缺少时说明版本、下载来源和空间，不重复下载。

保留原始识别，建立与定稿的差异报告，再按完整语义分成短语。识别文字不得反写正式稿。估算边界、低置信项和未匹配文字分别标记，并列原音频复听位置。

输出候选时间轴与检查清单。检查处理任务是否真正完成，未完成时继续读取进度，不重复启动同一任务。

15 正式时间轴：发声结束、镜头占用与成片时间分开保存

时间轴容易混淆的地方有三个：这句话在原音频里何时出现，字幕应该显示到什么时候，这个镜头在成片里占用多长时间。它们有关联，但用途不同。

原始声学时码对应正式人声。镜头占用区间负责把整条视频覆盖完整，前后镜头需要有清楚的交接。字幕显示区间则跟着说话和阅读安排，在话说完以后可以消失，画面仍可继续停留。

我的当前对齐脚本分别保存 startMs、endMs、spokenEndMs 和 captionEndMs。连续的占用区间可以覆盖完整音频；字幕结束另按发声结束处理。这能避免最后一句被错误地挂在尾部静音和片尾画面上。

举一个教学例子：某段口播从 8.42 秒开始，到 10.08 秒说完，镜头在 10.60 秒交给下一段。发声范围是 8.42–10.08 秒，镜头占用到 10.60 秒，字幕结束可以按实际发声与阅读要求确定。这个例子没有代替你自己的音频测量。

{"id": "P0007", "text": "把相同主题放到一起", "startMs": 8420, "endMs": 10600, "spokenEndMs": 10080, "captionEndMs": 10080, "status": "教学示例，实际值由本期音频确定" }

画面以帧为单位输出。30fps 下，一帧约 33.33 毫秒，可以按工程约定把毫秒锚点映射到最近帧。不要为了得到整数帧，反向改掉声学原值；保留原值和渲染换算结果，检查动作实际落在哪一帧。

另外一套时间是成片时间。假如中间真正插入一段额外停顿，后面的声音、字幕和动作都要跟着映射。只把画面推迟，声音仍沿旧时点播放，字幕就会出现偏移。章节切片也要记录全片起点与局部零点，避免重复加偏移。

检查连续性时，先看时间是否单调递增，是否存在负长度、重叠或未安排的空白，再看它是否对应实际声音。一个时间表数学上无缝，仍可能对应错句。两种检查都通过以后，时间轴才适合给镜头使用。

原始时码保留，发生插入时建立映射。字幕和动作一起使用确认的成片时间。

复制指令 15｜确定制作时间基准

根据复听后的短语记录，整理制作时间轴。分别保留原音频时点、镜头占用结束、发声结束与字幕显示结束；末段占用覆盖音频全长，但字幕不延伸到无关尾部静音。

检查单调、负长度、重叠、空白、末段覆盖和语义断句。保留毫秒原值，记录30fps最近帧换算结果，不修改声学原值凑帧。

有新增停顿时另存成片映射，声音、字幕和动作统一使用。给出版本、差异、复听位置与仍未确认的边界。

16 人物三视图：先把“同一个角色”定义清楚

角色一致性从设定阶段开始。只写“白发、可爱、头顶有花”，模型仍有很多自由：头发长度、花的结构、眼睛位置、头身比例、衣服和鞋子都可能变化。一条视频出现几张图以后，观众就可能感觉角色换了人。

我的项目把人物三视图作为固定参考之一，正面、侧面、背面并排展示同一个人物。下面这张就是项目当前使用的资产，后续图片都应能够回到这组设定检查。

正面、侧面与背面共同定义体型、发型、服装和头顶小花，原图直接引用。

第一次设计自己的角色，先写角色设定卡。包括外观特征、头身比例、发型轮廓、五官画法、标志物、服装和颜色。还要写哪些部分长期固定，哪些可以按作品变化，例如表情、手势和场景。

生成三视图时，让三个人物保持相同尺度与站姿，正侧背之间服装结构能对应，头发在背面能接上侧面的轮廓。背景简单，脚底对齐，不用动作、复杂透视和很多道具干扰观察。

重点检查小花是否每个角度都在正确位置，侧面是否仍然是同一发型，背面短裤、衣服和鞋子是否对应正面，身高和头部是否突然变化。三视图里的错误如果被接受，后面就会被当作设定继续传播。

确定版本之后，保存原图和设定说明，记录为什么这版通过。下一次生成新角色姿态，带上这份图，而不要从某个随手保存的旧镜头里反推人物长什么样。镜头图的遮挡和透视，可能隐藏了重要特征。

三视图能提高一致性，不能保证每次生成都正确。它是检查依据，不是免检凭证。出现两个花朵、额外手指或衣服变色，仍然要修正对应资产。

复制指令 16｜制作自己的三视图

根据我已确认的角色设定，准备三视图生成要求。正面、侧面、背面为同一个角色，站姿、身高和尺度一致，背景简单，脚底对齐。

明确锁定发型、五官、标志物、头身比例、服装与颜色。先展示设定和请求范围；涉及收费或外部上传时按项目要求确认。

生成后分别检查三个视角的身份一致性和结构对应，保存原图、设定与版本。未经确认不继续批量生图。

17 人物细节图与表情姿态：把容易漂移的地方单独固定

三视图提供整体关系，细节图补充近距离观察。我的第二类参考专门描述头发、粉花、眼睛、腮红、衣服线稿和头肩关系。这样，生成近景或新的角度时，有明确依据可以核对。

细节参考把发型、小花、眼睛、衣服和头肩关系分别说明，帮助定位哪里发生了变化。

制作自己的细节板时，挑最容易改变身份的部分。标志物怎么长在头顶，花瓣和叶子是什么关系；头发是向内还是向外；眼睛轮廓和瞳孔怎样画；衣服领口、袖口和颜色怎样保持。文字应简短，图片应该看得清。

接着做表情与姿态规划。第一条案例可以只用疑惑、查看资料、指向工作台、确认结果几个状态。每个状态对应一句口播和一个目的：疑惑建立问题，查看体现判断，指向引导注意，确认回应结果。

表情不能只由嘴巴是否张开决定。眉眼、视线、手势、肩膀和身体重心一起传达情绪。比如说“先别急着合并”，手上可以有清楚的停止动作；说“交给人确认”，人物应看向待确认对象，给出符合语义的反应。

同一场景里，各个姿态尽量保持相同机位、人物位置和家具关系，减少切换时整个世界跳动。需要换视角时，在镜头表中明确安排。不要把背景变化当成人物动作，也不要为了让画面不停动而给完整人物反复左右摇摆。

我的项目采用清楚的关键姿态切换。连续抬手、走路或转身，若需要展示完整过程，就要额外准备连续图像、可控分层或适合的动画路线。一张姿态图只提供一个状态，不能自动包含所有中间动作。

复制指令 17｜规划细节与姿态

读取已确认三视图，整理发型、五官、标志物、衣服和头肩细节参考。存在矛盾先报告，不能自行改角色设定。

为本期口播规划疑惑、查看资料、指向工作台、确认结果四个状态。每个状态写对应短语、情绪、视线、手势、身体和道具关系。

同一场景保持机位、人物位置与背景一致。明确哪些用关键姿态切换，哪些必须另做连续动作。先交设定和素材计划，再按获准范围生成。

18 笔触图：为什么人物一样，画风仍然可能不一样

人物身份相同，线条、阴影和上色方式不同，观众仍然会觉得作品不统一。一个镜头是轻柔手绘，下一镜变成光滑三维，再下一镜出现很粗的漫画描边，这些差异会抢走对内容的注意。

我的第三类参考是笔触图。它展示角色衣服、皮肤和短裤的边缘，能够看见线条轻重、阴影和纸面般的上色质感。外围展示框的配色不作为所有场景必须使用的背景。

关注线条粗细、边缘、阴影与上色；画面外部的展示框不定义新镜头背景。

整理画风时，先把能观察的特征写出来。线条是否细而略有变化，边缘是否完全光滑，阴影是硬边还是轻柔过渡，色彩是否低饱和，背景是否保留纸张质感，人物与背景谁更清晰。这些描述能变成生成和检查条件。

风格图与三视图分工明确：三视图锁定人，笔触图锁定画法。不要让模型因为笔触图里有某个姿势，就在所有镜头里重复那个姿势；也不要因为风格图展示了一块绿色边框，就把整个视频都改成绿色背景。

第一次做风格测试，可以拿同一个简单人物状态，分别生成两种候选，然后按线条、颜色、可读性和后续制作难度选择。确定以后记录一套风格词，后面带上相同参考，不再每张图临时换一长串形容词。

缩小画面也要看。细线在原尺寸很好看，缩到手机可能消失；阴影太轻，人物和背景可能融在一起。风格需要服务清楚的轮廓和关键道具，让观众知道角色正看什么、拿什么、指向哪里。

风格参考可以由自己绘制、整理自有素材或使用有相应权利的图像。准备商业作品时，记录真实来源；教程里展示我的资产，不等于向读者提供任意转售这些图片的许可。

复制指令 18｜定义笔触与画风

读取我的笔触参考，按可观察特征描述线条、边缘、阴影、上色、饱和度和背景质感。区分角色身份参考与画法参考，不继承展示框、文字或无关构图。

准备一张同角色的风格测试要求，保持已确认身份。原尺寸和手机观看尺寸分别检查轮廓、关键道具与人物背景对比。确定后将风格词和参考路径写入资产说明。

19 场景图：完整空间比“人物贴到背景上”更容易讲故事

我的第四类参考是实例背景，它约束浅色手绘场景的配色、简化程度、景深和空间层次。它不会要求所有镜头都回到同一间办公室。场景应该随着本期内容变化，人物仍然属于同一个视觉世界。

学习空间、配色与前后关系；里面的机器人、流程图和摆位不需要逐项照搬到新作品。

设计一个场景时，先确定人物正在做什么。读稿可以坐在桌前，解释关系可以站在画板前，检查结果可以靠近文件柜或工作台。场景给人物提供动作对象，观众更容易理解这句话为何发生。

把人物、家具、道具和机位作为完整画面设计。手拿纸时，纸与手有接触；坐着时，身体与椅子、桌面有合理关系；站在画板旁时，脚要落在地面上。单纯把人物图片盖到背景，容易出现悬空、穿透桌面和错误遮挡。

提示词还要说明后期信息放在哪里。角色在左侧看资料，右侧可以留给独立卡片；关键道具不被字幕挡住。底图只包含人物、场景、动作和道具，标题、文字、箭头等交给后期工程，这样修改文字时无需重画人物。

同一场景生成第二个姿态时，带上第一张已确认图作为本场景依据，同时带上四类角色参考。保持窗户、桌面、座位、光照和机位，改变对应动作。原有空间不稳，切换姿态时就会像突然换了房间。

下面这张是项目中的现有完整人物场景：人物查看资料，左手与桌面接触，资料就在视线方向，右侧留出讲解空间。它提供本场景状态，没有包含全部连续动作。

角色、桌面、纸张、视线和空间共同构成动作；文字层后续单独加入。

复制指令 19｜设计并检查完整场景

整组读取三视图、细节、笔触、背景四类参考，根据本期镜头设计完整场景。说明机位、人物位置、视线、家具、道具接触、遮挡与后期信息空间。

底图不生成标题、字幕、数据或箭头。先交一张代表场景，检查重力、透视、肢体、接触点和手机可读性。

通过后，同一场景其他姿态以该图和角色参考共同约束，只改变必要动作；新场景按本期内容设计，不默认沿用上一期场景。

20 分镜怎么写：先说观众要懂什么，再说画面怎样变化

声音、时码和角色参考准备好以后，开始写镜头表。不要按逗号或每五秒机械换一个镜头。先找到完整语义，再决定这一段需要人物经历、真实操作还是图形解释。

我会先问五个导演问题：这一段最需要观众理解什么；什么画面能把它说具体；主体发生什么变化；最后停在哪个结果；怎样接到下一镜。一个镜头如果只能回答“文字出现了”，通常还需要补内容设计。

正式镜头表使用十四列：镜头、时间、配音原文、A/B-roll、画面类型、观众要理解什么、视角、B-roll 类型、语义结构、画面设计、动态变化、素材来源/状态、画面衔接、验收状态。A-roll 的 B-roll 专用字段填不适用。

给“三份资料变报告”安排一条清楚的链：人物面对资料产生需求，工作台保留文件并提取要点，按主题归类，冲突停在人工确认区，形成报告，人物确认结果。这些动作要落到正式短语边界上，不能预填一组看起来整齐的整数秒。

下面是两行结构示例。时间一栏暂时写对应短语，在实际项目中替换为本期已确认时码。它说明字段怎样填，不代表已经生成合格镜头。

S001

• 时间：对应开头短语

• 配音原文：面对三份资料

• A/B-roll：A

• 画面类型：人物场景

• 观众要理解什么：为什么需要整理

• 视角：主角

• B-roll类型：不适用

• 语义结构：不适用

• 画面设计：人物桌前三份资料

• 动态变化：看资料→困惑→看向工作台

• 素材来源/状态：本期角色参考/待确认

• 画面衔接：视线交给资料区

• 验收状态：待审

S002

• 时间：对应提取短语

• 配音原文：再从每份资料中提取要点

• A/B-roll：B

• 画面类型：操作示意

• 观众要理解什么：原件保留，要点可整理

• 视角：工作台

• B-roll类型：无真实UI素材

• 语义结构：拆解与归类

• 画面设计：文件与要点分开显示

• 动态变化：提取→移动→进入主题槽

• 素材来源/状态：自写演示资料/待制作

• 画面衔接：保留要点进入下一镜

• 验收状态：待审

每个镜头还要记录素材缺口。需要真实录屏却没有，就写“需要补充”，不要用生成的后台界面代替。高难度连续动作也要提前提出方案，别等整片渲染以后再解释做不到。

章节进入时，我会在已有口播里给一个简短预告：序号、方向、这段解决的问题，再进入人物和工作台。预告不必额外添加机械停顿，关键是让观众知道接下来要看什么。

表格确认以后，再生成对应资产与动画。先确定内容和动作，可以避免生成一大批漂亮但没有明确用途的图片。镜头表就是这一阶段的制作清单。

复制指令 20｜生成十四列镜头表

输入本期定稿、确认时码和素材清单。先回答五个导演问题，再按完整语义切镜，S001起连续编号，使用实际短语边界覆盖完整配音。

输出十四列镜头表，逐镜写清主体、必要变化和最终结果。采用章节预告→需求互动→工作台操作→结果反馈的因果顺序，不强行加入无关配角。

表后列素材缺口、视角待确认与高难度动作。先提交审阅，未经确认不生成动画或批量资产。

21 A-roll 怎样制作：人物的每个反应都有口播依据

A-roll 承担主叙事。在我的模板里，人物讲述、情绪、态度、需求互动和结果反馈常由它完成。角色正在经历什么，会影响表情、视线、手势与道具关系，观众才有理由跟着看。

我会给每个 A-roll 镜头写人物表演节拍：对应短语、起止毫秒、情绪、视线目标、起始姿态、关键动作、落定姿态、道具变化。比如“先别急着合并”出现停止反应，“看清楚来源”看向资料，“交给人确认”转向待确认对象。

下面两张是项目同一场景中的现有姿态。第一张查看资料，第二张指向讲解区。它们提供两个状态，工程在合适的语义点切换；如果需要看见完整抬手过程，仍需额外制作连续动作。

角色视线与手中的资料对应，桌面、光照和机位保持本场景关系。

手势把注意力交给讲解区。这个状态要绑定实际口播，而不是固定每隔几秒切换。

两个完整人物姿态直接交叉叠化，会同时显示两组手臂、脸或半透明影子。我的默认做法是清楚切换关键姿态，并逐帧检查切换位置。真正连续动作则需要相应素材与实现，不靠叠化掩盖缺口。

A-roll 分层也很明确：完整人物场景底图、动态旧胶片、独立信息层、字幕和圆角外框。工程中的标题、卡片、箭头随时能改；底图中的人物与空间不被文字改动牵连。

当前 1920×1080 布局中，画框为 x64/y75/1792×821，圆角30px；框下单行字幕顶部 y953，字号45px。项目的布局契约保存这些值，修改参数时以当前契约为准，并在预览中看实际结果。

旧胶片是我的风格资产，使用用户提供的动态破损录像带素材，在画框内叠加，标题、字幕与外框放在上面。既要看见轻量动态灰尘和划痕，也要保持人物清楚。静态噪点图不能代替我的这项项目要求。

这张原作品预览展示底图、信息卡、画框和框下字幕的关系；新作品的字体与参数仍读取当前布局契约。

复制指令 21｜制作人物表演与分层

根据已确认镜头表，为每个A-roll写“短语→毫秒→情绪→视线→手势/身体→道具→落定状态”。整组读取四类角色参考和本场景已确认图。

按语义点切换关键姿态，保持同一空间，不叠化不同完整人物，不以左右摇摆、背景或卡片移动代替人物反应。连续动作另列素材方案。

按当前布局契约实现底图、动态胶片、独立信息、字幕与外框。逐个检查姿态起点、落点和切换帧，肢体、接触点和关键道具必须完整。

22 B-roll 怎样制作：让输入、操作、结果真正可见

B-roll 补充和解释主叙事。步骤、流程、对比、数据、界面和因果关系，适合在这里变成具体对象。它应该帮助观众看见这句话的意思，同时承接人物刚刚提出的问题。

我的当前 B-roll 使用米白背景、哑光纸张般的浅色立体对象、克制投影、深色文字和低饱和薄荷、淡紫、桃色。左上依次是信息行、章节标题、说明。字号形成层级，不把所有文字都做成粗大标题。

先确定一个主要结构：流程、拆解、归类、对比、筛选、分支、状态转换或映射。然后定义对象：文件、要点、报告、冲突、确认队列。颜色在本镜或本期表达稳定含义，让观众知道哪些对象属于同一组。

“三份资料变报告”先让原文件停在输入区，再提取要点，让相同主题的要点进入报告。冲突对象停在待确认区，最后形成带来源的结论。观众看见的每次移动，都解释了一件事。

如果只让几张卡片同时浮上来，再统一呼吸，画面可能很热闹，信息结构却没有变化。要检查的是对象从什么状态变成什么状态，结果是什么。一个有用的动画，在关键帧静音观看时也能读出基本关系。

下面是项目浅色动效样片的既有画面。它用一个示意网站和问题清单表达从目标到工程判断，展示信息层级、对象和聚焦位置。画面里的界面用于讲解流程，不是客户网站实测证据。

先提供对象全貌，再聚焦当前要读的条件。标题、字幕和说话头像保持固定。

同一个清单持续保持身份，当前问题被局部强调；素材来自项目既有渲染。

文档和表格同样按“全貌 → 目标行列 → 停稳阅读 → 交给下一对象”安排。缩放和移动带着内容层走，固定标题、字幕和头像不跟着放大。比较双方时，保留理解关系所需的信息，避免为了镜头感把一半内容裁掉。

我的项目模板库中有不同来源的候选。借用之前核对代码和素材许可；其中有条目明确标注非商业许可，不能默认用于赚钱项目或随教程转售。可以重新设计自己的聚合、分支和对照结构，再实现原创代码。

复制指令 22｜设计有效讲解画面

按当前浅色立体B-roll规范，为本期每镜选择主要语义结构。定义输入对象、操作、结果、颜色含义与逐项变化，动作绑定正式短语毫秒。

文档/表格先给全貌，再聚焦目标，停稳阅读并保持对象身份。标题、字幕、头像固定，内容层单独变换。真实界面缺失时明确写操作示意。

先查本地模板索引，核对许可和适配；不默认复用非商业代码。交付静态结构和动作计划，确认后实现。

23 头像、字幕和安全区：画面移动以后也不能挡住信息

讲解画面中还有一个固定说话头像，用来提示讲述者身份。它和剧情里的完整人物承担不同任务：头像持续跟随讲述，人物则在需要情绪、互动或反馈时进入场景。

我的公共头像基础图如下。圆形裁切、绿色边框和声线由工程绘制；生成图只是资产。直接显示原图，不会自动得到固定圆框、位置和说话反馈，仍需由工程完成构图。

基础身份图直接引用。圆框、位置、嘴部补丁与声线属于工程层。

当前 1920×1080 B-roll 的头像外接框是 x90/y745/直径225px，预留区是 x45/y694/390×290。脸朝右侧内容区，绿色声线在圆圈右侧。字幕另有自己的保留带，文字和卡片都需要绕开。

我的当前实现可以按本期音频能量控制两态嘴型和声线：有声时张嘴并显示声线，静音时闭嘴并隐藏。它表达“正在说话”，不等于逐个音素精确对口型。完整数字人或连续表演需要另选相应路线。

字幕内容来自正式稿，显示时间来自校对记录。单行放不下时，按语义和时间拆成两条连续短语，不能简单缩小到难以阅读。A-roll 与 B-roll 可以有不同底条和颜色，但各自的样式与位置应保持稳定。

安全区检查必须覆盖运动过程。卡片起点和终点没挡头像，经过中间位置时仍可能穿过去；投影、连线、光标和强调边缘也有可见范围。变换后的实际边界比静态布局更能说明问题。

字体同样需要核对实际字形。我当前默认使用 PingFang SC 体系；其他系统缺少字体时，选择可用替代并做同文字对照。不要只看到 CSS 写了某个名字，就认定渲染真的使用了该字体。

复制指令 23｜检查固定层与运动避让

读取当前布局契约，固定标题、字幕、头像与声线。嘴型和声线使用本期音频能量，不继承旧包络；按当前两态实现说明能力，不称为音素级对口型。

字幕按正式稿和校对时码单行显示。检查实际字体，超宽按语义拆分。内容动画全程检查变换后边界，包括投影、连线、光标与强调，不能侵入头像和字幕预留区。

抽查运动起点、中间、停稳、退出及相邻帧，列出实际问题位置。

24 把资产接进工程：让画面由同一份数据驱动

资产完成以后，将稿件、短语、镜头、图片、布局和动作接入画面工程。可复用组件处理角色场景、字幕、头像、卡片和结果状态，本期数据决定显示什么以及何时变化。

尽量不要把所有时点散落在各个组件里。一个动作写8秒，字幕写8.5秒，镜头表又写9秒，修改时就要猜哪份是正确值。正式时间轴、镜头表和动作映射应能互相对应，组件读取已确认数据。

在 Remotion 中，画面状态跟随帧号。你可以用当前帧与短语锚点计算资料是否出现、要点移到哪里、人物采用什么姿态。需要逐帧稳定的结果，就避免依赖真实时钟、未固定的随机数或每次不同的外部响应。

图片路径和音频路径也应可追踪。工程读取的副本与素材登记对应，中文文件名需要在实际环境中验证。字体、图片和视频加载完成以后再输出，不然第一帧可能出现缺字、缺图或短暂空白。

我会把章节起点、全片帧号和局部帧号的转换统一处理。渲染第三章时，局部第零帧对应全片某个确定位置；音轨切片和字幕读取也用同一个边界。这样，章节审片与最终成片更容易保持一致。

真人录屏或已有拍摄素材可以接入，但还要增加选段、重复录制清理、停顿处理和必要的同步步骤。本文这套路线以定稿、人声、角色和图形编排为主要输入；复杂多机位素材需要自己的前处理，先把它做成可信的输入片段。

工程完成一个组件以后，用与本期有关的小片段检查。资料移动时有没有离开画框，切姿态时有没有多余手臂，字幕是否在对应话语消失，缓存清理后能否再次加载同一资源。发现问题先修组件，再扩展镜头。

复制指令 24｜建立数据驱动画面工程

将已确认资产、镜头表、短语时间轴与布局契约接入本期Remotion工程。公共组件处理布局，本期数据处理内容与动作锚点，时点不在多个组件重复手写。

统一全片时间与章节局部时间，音频、字幕和动作使用同一转换。画面按帧确定，固定随机种子与素材版本，等待资源完成后输出。

先渲染一个包含姿态切换、资料移动和字幕结束的检查片段。记录实际路径与问题，修正后再继续。

25 音乐、音效与混音：有音轨还要听得清

正式声音保留为独立人声，背景音乐和音效分轨处理。我当前项目要求正式有声样片和成片加入适合教学的轻快、轻巧、无人声 BGM；人声始终优先，音效只在有语义作用的节点使用。

选音乐先看情绪和来源。讲步骤时，过强的鼓点、明显旋律或人声可能抢走注意；讲结果时，适度变化可以帮助收尾。曲目需要有适合实际用途的使用依据，免费下载按钮不能代替许可说明。

我的本地音乐库里也保存了用户提供的曲目，来源记录写明按用户确认使用，没有把它们写成已独立核实的公开商用许可。准备向读者或客户再分发音乐时，需要另外确认相应权利，不能把整个素材库随工程打包送出去。

混音时先测实际响度和峰值，再调增益，最后在正常播放音量下试听。音乐轨存在，只能说明封装带了它；可能小到听不见，也可能在某一句盖过人声。只看波形或音轨列表无法完成听感判断。

音乐短于视频时，选择合适循环点，避开很明显的前奏和尾奏，必要时按节拍或小节衔接并使用短交叉淡化。片头和片尾分别处理，连续听接缝有没有突然跳变。FFmpeg 提供混音和交叉淡化等滤镜，但参数仍需要对应实际素材。FFmpeg 音频滤镜文档

音效少而准确。资料落定可以有一次轻声反馈，确认结果可以有一个短提示，不必每张卡片进入都播放同一声音。音效的时间绑定对应动作，音量不遮住同一位置的关键词。

输出混音版本以后，抽听开头、中间、循环接缝、重点句和结尾，再完整听一遍。检查有没有削波、突然静音、音乐硬断和尾句截断。人声原件不被混音文件覆盖，后面可以继续调整配乐。

复制指令 25｜处理本期声音层

从本期可用音乐与许可记录中选适合教学的无人声BGM，说明来源和使用依据。原始人声独立保留，音乐、语义音效与最终混音分开保存。

测量实际响度与峰值，设置人声优先的增益。曲长不足时设计自然循环与短交叉淡化，检查前奏、尾奏及接缝。音效绑定本期动作时点。

输出混音试听版，列重点句、循环接缝和结尾的检查位置，完整听感由我确认。未经授权不调用付费配乐生成。

26 先看两张静态预览，再看一条有声样片

批量动画之前，先交两张独立静态图：一张 A-roll，一张 B-roll。它们分别检查人物场景和讲解布局，不拼在一起缩小审阅。静态图里已经难以阅读的文字，做成动画以后通常也难以阅读。

A-roll 看角色是否一致，空间和接触点是否合理，表情是否对应内容，画框、字幕和信息层是否有足够位置。B-roll 看对象结构是否清楚，标题层级是否合适，卡片能否读清，头像和字幕区有没有被占用。

在手机观看大小下再检查一次。你在大显示器上能读清的小字，观众可能只看见模糊线条。把非必要信息减掉，保留与当前口播有关的对象；需要详细阅读的地方，安排明确聚焦和停稳。

两张图都确认以后，制作约 30 秒有声样片。选择能同时覆盖 A-roll、B-roll、字幕、头像、转场、胶片和音乐的连续段落。使用本期正式人声和校对时间轴，这样样片通过后，才能成为真正的扩展基准。

第一遍正常速度观看，只看内容有没有讲清楚。人物为什么困惑，工作台怎样处理，结果是否可见，人物反应有没有承接。第二遍检查关键句的声音、字幕和动作，第三遍检查音乐与转场。不同遍次关注不同问题，更容易给出具体反馈。

机器检查也在这一阶段执行：媒体参数、音轨、完整解码、时间连续性、疑似黑场和异常静止。发现问题后标出实际位置，再打开文件确认。角色手臂出错、镜头意义不清，不能靠媒体参数检查发现全部情况。

样片交付应带版本、文件、修改说明和剩余问题。用户没有确认以前，状态就是待审。不要一边让人看样片，一边已经把同类镜头扩展成十分钟，否则布局和风格反馈会造成大范围返工。

复制指令 26｜静态预览与有声样片

分别输出一张A-roll和一张B-roll静态预览，按当前角色、布局和手机可读性检查。两张都等我明确确认后再制作动画。

选取本期连续约30秒，用正式人声和校对时间轴渲染有声样片，覆盖人物表演、讲解对象、字幕、头像、转场、胶片与BGM。

报告实际文件、版本、已运行检查和剩余问题，状态标为待验收。样片没有通过时不批量扩展。

27 怎样给 AI 修改意见，怎样从样片扩展到长片

好的反馈要让人知道去哪里看、看见什么问题、希望改成什么状态。“更高级一点”可以表达感受，但执行时仍需要具体对象。把反馈落到一句口播、一个画面变化和一个检查位置，修改会更容易比较。

例如：“在‘交给人来确认’这句话里，人物还保持困惑。请定位真实时码，在‘确认’处切到确认姿态，保留字幕和画框，输出第二版。”如果当前素材没有确认状态，先补素材，再绑定时点。

阅读问题也要明确：“这张报告卡上的三行字来不及读。先保留结论，第二个短语再显示依据，停稳后交给下一对象。”这种反馈告诉工程怎样改变信息顺序，避免只是把卡片放大以后挡住头像。

修改保存新版本，同一位置对照。旧版保留，对应源码、素材和音轨版本也记录。不要只看到聊天里的“已调整”，就认为最新 MP4 一定采用了调整；打开实际文件，才知道画面有没有变化。

样片确认以后，将它对应的组件与数据作为同一正式母版继续扩展。完整版与样片重叠的区间，复用同一实现。另建一个“差不多”的组件，容易出现字号、人物大小和动作节奏不一致。

长片按章推进。一章先制作、检查、观看、确认，再进入下一章。章节之间记录起止时间、全片与局部映射、音轨范围和已通过文件。最后合成时，这些边界会成为核对连续性的依据。

修改公共字幕、头像或布局组件以后，列出受影响章节，再回看那些区间。只改一张场景图，就重点检查引用它的镜头。范围跟着依赖走，可以减少无关重做，同时避免漏掉共享组件造成的问题。

下一次开工时，读本期记录，确认文件，再从明确位置继续。新的作品只复用公共规则和成熟组件，新稿、新人声、新时码和验收状态都重新建立。这能让制作规模增加以后仍然分得清每一条作品。

复制指令 27｜修改与逐章扩展

按我的反馈定位对应口播的真实时码，记录原状态与目标状态。只改受影响的素材或组件，保存新版本并列出对照位置，不覆盖已验收版本。

样片通过后，从同一母版组件向后扩展。每章先检查并交付，等我确认后继续。公共组件变动时列出受影响章节并回看。

每次确认后记录文件、版本、通过范围、剩余问题和下一步，保证下一次对话可从真实记录继续。

28 验收不能只看“渲染成功”：三层检查怎样做

第一层是基础媒体检查。核对分辨率、帧率、帧数、时长、视频和音轨，再完整解码。它帮助发现文件损坏、输出规格错误、空音轨或封装异常。检查应对最终交付文件执行，不能只检查中间预览。

下面是只读检查命令示例，路径替换为实际文件。ffprobe 输出参数，FFmpeg 从头解码到尾；有错误时保留日志与位置。

ffprobe -v error -show_format -show_streams -of json "render/full-review-v1.mp4" ffmpeg -v error -i "render/full-review-v1.mp4" -f null -

第二层是疑似异常检测。黑场、长时间静止、静音、异常图像和指定窗口的音画偏移，都可以让工具标出候选区间。检测有阈值，也有漏检与误报，章节卡的有意停留和留白需要结合内容判断。

我的项目曾在整片复核时发现某些章节编码异常单帧，再用对应章节验收时冻结的源码恢复画面。这个经验说明，章节看过以后，合成与编码还可能引入新问题；保留源文件和确认版本，才有恢复依据。

第三层是连续观看与试听。检查声音有没有讲完，字幕有没有读完，人物动作有没有回应语义，操作是否可见，结果是否有依据，音乐有没有盖住重点，结尾是否自然。机器报告无法替你确认所有这些问题。

对本文案例，重点看三份原资料是否保留，要点怎样进入报告，冲突是否停在人工确认区，最终结论是否仍能看到来源。人物反馈应该发生在对应声音位置，不能只用一个“完成”标志结束全部流程。

字幕核对也要分范围。文本与定稿一致、某几个窗口的声音偏移正常、整片逐字听审完成，是不同检查。只做了抽查，就如实写抽查位置；没有运行的检查写“未运行”，给下一轮留下明确任务。

最终报告包含完成内容、实际文件、检查项目、疑点区间、人工确认状态与剩余问题。你读完报告应该知道自己还要看哪里，并且可以直接打开那条文件。

让检测定位问题，再用连续观看与试听确认内容和表达。

复制指令 28｜完成技术与人工检查清单

对最终审片文件检查媒体参数、完整解码、时间连续性、音轨及疑似黑场/静止/静音。按实际能力检查选定窗口的音画偏移，列明位置和阈值。

逐章列人工观看事项：人物表演、物理关系、字幕、讲解输入操作结果、固定层避让、BGM与结尾。保留疑点，不把抽查说成逐字全片验证。

交付真实文件和报告；已运行与未运行分开，等待我完整观看并明确终验。

29 归档、清理与下一期：保留能够继续修改的作品

用户明确完成终验以后，归档最终 MP4。我的项目使用根目录 final_video/ 保存最终成片，文件名带实际验收日期和作品名。样片、章节片、旧候选留在本期目录，避免别人打开归档时误用未通过版本。

复制前核对验收记录和原文件，复制后检查哈希及可读性。同名目标已经存在时，先比较内容；不要静默覆盖一个可能已用于发布的版本。哈希一致说明副本字节相同，不能替代用户对作品内容的验收。

源文件继续保留：正式稿、TTS 输入、人声、时间轴、资产、镜头表、工程、锁文件、通过的版本和修改说明。客户提出换一句字幕或调整音乐时，才可以找到对应依赖，判断需要改哪里。

如果要把工程交给别人，还要说明运行环境、实际命令、素材路径、字体需求和哪些服务由对方配置。自己电脑能打开，不等于换一台机器也能运行。需要可复现交付时，在独立目录或干净环境按文档验证，并留下结果。

临时渲染包、诊断图和中间音视频可以清理，但先列精确范围、空间估算、保留项和恢复方式，单独确认。清理并不会让作品更正确，它只是释放空间；不要把正式资产、已通过源码或仍用于修复的图片混进删除清单。

下一期重新确认标题和稿件，再建立独立目录。默认风格可以沿用，公共角色参考可以继续读取，音乐也可以从公共库选择；专属场景、声音、时码和通过状态仍由新作品建立。遇到明确授权的资产复用，登记来源和用途即可。

长期进步来自把反复出现的问题整理成清楚规则。例如某类卡片总挡头像，就补全过程避让；人物总拿错道具，就补接触与视线检查。只把临时感受堆进文件，会让下一次开工越来越难读。

复制指令 29｜终验后归档并交付工程

核对我的终验范围与真实文件，将已验收完整版复制到final_video，使用实际验收日期和作品名。复制前后核对哈希和可读性，同名不同内容不覆盖。

保留正式稿、人声、时码、素材、镜头、工程、依赖和验收记录，列运行说明与尚未验证的迁移事项。

临时内容另列精确清理清单、预计空间、保留项和恢复限制，等我对该范围明确确认再删除。下一期重新建立输入、时码与验收状态。

30 做出来以后，怎样验证它能不能赚钱

回到我的原始目标：自动剪辑，然后赚钱。现在有了完整制作链，商业验证可以从一个明确任务开始。把一类作品做稳定，记录真实成本和修改范围，再看看有没有人需要这个结果。

经营自己的账号时，选择观众正在解决的问题，用实际过程和可复制方法建立内容积累。记录观看反馈、收藏、回复和持续需求，看看哪个环节被反复追问。平台收入是否开通、如何结算，以本账号和当前平台规则为准，不用别人的截图替自己证明收入。

提供制作服务时，先定义输入。客户提供已确认稿件、品牌资料、角色或形象授权、目标平台和交付规格。你提供样片、成片、约定的修改轮次和源文件范围。稿件大改、人声重做、增加场景或改变画幅，应提前说明怎样调整交付范围。

可以先做一个小范围项目，确认对方要的视频解决什么用途。产品讲解、内部培训、课程配图和账号口播，检查方法不同。不要凭“自动化很强”就承诺所有类型、无限修改、任何时长都能在同样时间交付。

计算时，把收入记为 R，实际外部成本记为 C，人工投入记为 H，维护和其他摊分成本记为 M。先看 R − C − M，再看这些收入对应多少人工时间；没有收入的实验阶段，也要记录成本和返工。这个表帮助你判断是否值得继续，不替代实际成交。

销售教程或工作流包，需要更严格的交付。说明支持的系统、工具、输入、输出、安装过程、费用和已知限制。移除私人路径、凭据、客户材料和无权再分发的图片、音乐、字体与模板。在干净环境跑过示例以后，再给读者提供真实复现结果。

软件与模板的许可也分别核对。例如 Remotion 有自己的使用和再分发条款，主体规模、用途和版本会影响适用条件；能用它制作视频，不代表可以把它的代码衍生产品任意转售。Remotion 当前许可 我的模板索引中带非商业标记的条目，也不能默认装进商用交付包。

我更愿意从“这条视频确实有用、这套流程确实能继续修改”开始积累案例。自动化能减少部分执行工作，选题、表达、服务和判断仍需要投入。有没有人愿意付费，最终由真实需求和实际交付来验证。

复制指令 30｜设计一次小范围商业验证

根据我已经能稳定交付的作品，设计一次小范围商业验证。列目标对象、问题、输入要求、固定交付、修改范围和需要记录的成本，不假设已经有收入。

为每条作品记录实际外部用量、人工时间、返工原因和反馈。若考虑教程包或工具产品，先列可复现、许可、支持范围与素材分发缺口；未解决前不标记可售。

输出待审方案和交付样例说明，不替我联系客户、定价收款或发布承诺。

31 常见故障速查，以及第一条作品的完整执行顺序

做完整条路线以后，你不需要记住每一个参数，但需要知道遇到问题去哪里看。下面这张表可以作为制作时的检查入口。先定位发生问题的层，再修对应文件。

安装完成但视频出不来

• 先核对哪里：工程入口、Composition、依赖与命令

• 处理方向：回到5秒测试，保存完整错误

输出视频没有中文或缺字

• 先核对哪里：渲染实际字体与资源加载

• 处理方向：做同字样对照，确认加载后输出

配音配置有值但请求失败

• 先核对哪里：配置加载、权限、音色、服务响应

• 处理方向：脱敏定位，不循环重试

声音文件打不开或长度异常

• 先核对哪里：原始编码、容器头、结束状态

• 处理方向：按真实格式解析，保留部分数据

字幕文字对了但仍对不上

• 先核对哪里：发音、候选锚点、成片映射

• 处理方向：对应位置复听，检查换轨和插入

尾部字幕一直挂着

• 先核对哪里：发声结束与占用结束

• 处理方向：分开字幕区间与镜头区间

角色换了人或衣服变了

• 先核对哪里：四类参考与本场景基准

• 处理方向：锁定身份，修对应姿态

人物多了一只手或有残影

• 先核对哪里：原始姿态与过渡帧

• 处理方向：修资产，避免完整人物叠化

卡片会动却讲不清楚

• 先核对哪里：语义结构、输入操作结果

• 处理方向：重写对象变化与落定状态

放大以后挡头像或字幕

• 先核对哪里：内容变换后的全过程边界

• 处理方向：固定层独立，检查中间帧

音轨存在但音乐听不见或盖人声

• 先核对哪里：实际响度、增益、接缝

• 处理方向：测量后试听，保留人声原件

章节正常，合成长片异常

• 先核对哪里：边界、编码、冻结版本与完整解码

• 处理方向：对应原章恢复，复看最终文件

新任务接上旧声音或旧镜头

• 先核对哪里：作品名、输入清单、目录和状态

• 处理方向：重建本期输入对应关系

工程只能在自己电脑运行

• 先核对哪里：依赖、私人路径、字体与素材

• 处理方向：在独立环境按说明验证

如果你现在刚开始，先完成这条顺序：

1. 写下目标读者、第一种交付和待验证的赚钱方向。

2. 建空目录并确认当前路径，检查基础环境。

3. 生成能播放的5秒测试，记录实际命令。

4. 写项目指令、制作规范、Skill和本期状态入口。

5. 确认小案例，准备自写资料与来源清单。

6. 写完整口播，朗读后确认正式稿与TTS输入。

7. 确认音色和费用，试听后生成统一正式人声。

8. 完整试听，识别与校对时间，保留待复听项。

9. 准备三视图、细节、笔触、场景与本期姿态。

10. 确认镜头表，再分别确认A-roll和B-roll静态图。

11. 用正式声音制作有声样片，按具体反馈修改。

12. 样片通过后从同一母版逐章扩展。

13. 检查最终文件，完整观看与试听，明确终验。

14. 归档成片和可编辑工程，确认范围后再清理。

15. 记录成本和反馈，用真实作品验证下一次交付。

准备素材时可以与写稿并行整理，但画面动作的精确时点要等正式声音，批量制作要等相应方案确认。这个顺序既让你提前准备，也让每一步知道自己的基准是什么。

第一次完成以后，复盘哪些工作确实被工具接走，哪些问题反复需要自己解释。把已经有效的做法写进公共规则，把暂时假设留在本期记录。这样，第二条作品有可以使用的基础，也保留为新内容调整的空间。

我想用自动剪辑赚钱，所以我需要的是能持续交付的制作能力。现在可以把目标落到一个很小的开始：在你的文件夹里，输出第一条5秒测试，再让第一条有声小作品完整走过声音、时间和画面。

等它真的能讲清楚一个问题、能被修改、能再次制作，你就有了第一份可以继续积累的成果。