SiuZheng/make-video

制作视频

用户与您一起制作 YouTube 视频：长视频讲解（16:9）和短视频（9:16），使用 Remotion 通过代码制作动画，由 Gemini 语音配音，通常以角色精灵为主角。本技能涵盖整个过程。工具位于 <videokit> 目录下，即本技能仓库的 videokit 文件夹（运行任何命令前请先阅读 references/toolkit.md）。如果 <videokit> 尚未替换为实际路径，请询问用户克隆仓库的位置（包含 vk.py 的文件夹），并使用该路径。

用户最关心三件事，这也决定了流程的设计方式：

1. 在用户批准草稿前，不构建任何内容。 用户希望先看到故事以及每个场景的具体视觉和听觉效果——包括过渡、动画、灯光、音效和质量。修改计划只需几分钟；修改渲染则需要数小时。
2. 视频必须看起来专业。 包含带有运动模糊的动态过渡、缓动运动、景深感、真实光照、为每个事件配制的音效、清晰的 1080p 画质。references/pro-look.md 说明了这在实践中的含义以及哪些组件负责实现。
3. 用户想要的是完成的视频，而不是一连串的问题。 审核代理会沿途回答相关问题，并根据固定的 10 项清单对工作进行评分；用户只在评分达到 9/10 后才收到视频。references/review.md 是操作指南：谁决定什么、检查清单、提示词以及何时停止。审核在早期进行（草稿、故事板），此时修改成本较低，而非仅在最后阶段。

阶段

每个 ✋ 表示一个停止点：在继续前等待答复。✋ 用户：由用户决定。✋ 审核者：由审核代理决定（整个视频由一个代理负责，通过 SendMessage 继续执行 - review.md）。

0. 简报 ✋ 用户

使用 AskUserQuestion 询问无法从请求中判断的信息（每次调用最多 4 个问题；剩余问题使用第二次调用）。即使主题暗示了某些信息，也不要假设以下任何一项：

• 格式： 长视频（16:9，1920×1080）· 短视频（9:16，1080×1920，3 分钟以内）· 两者（一个长视频加上从中剪辑的 3-5 个短视频）。
• 配音： AI 语音（Gemini TTS；您将发送样音）· 无配音（音乐 + 屏幕文字）· 用户自己的录音。
• 外观： 提供 3-4 种适合主题的具体风格（例如，带真实光效的影院级代码绘制太空场景；干净的扁平动态图形；手绘涂鸦风格；故事书剪纸风格），每种风格用一句话描述。
• 角色： 用户现有的角色精灵（位于 <videokit>/sprites；python vk.py characters 列出）· 使用图像生成工具（如 Gemini [Nano Banana，需付费]）生成新角色 · 表情符号 · 代码绘制 · 无。
• 所有其他素材（道具、物体、图标、背景）——每次都要单独询问：代码绘制（免费；使用效果库的外观）· 表情符号（免费；使用 Emoji 组件，与其他元素一样打光）· 使用图像生成工具（如 Gemini [需付费]）生成 · 混合使用，在草稿中逐个素材决定。每次制作视频都必须询问。生成的图片只有在用户在此处选择了该选项后才能制作。
• 音乐： 原创乐谱（情绪：惊奇 / 紧张 / 俏皮 / 史诗感）· 为此视频逐音符创作的乐谱（与场景同步的主题、和弦和重音 - toolkit.md “已创作的乐谱”）· 用户自己的歌曲（用户提供音频和歌词 - 切勿下载）· 无。

同时确定主题、时长和语言（如果不明确）。然后创建项目： python -X utf8 vk.py new <文件夹> --title "..." --format long|short|both（在 videokit 文件夹中运行；项目创建在其旁边）。

1. 草稿 ✋ 审核者，然后 ✋ 用户

研究主题（检查每个事实；注意任何依赖于当前日期的事项），编写 script.md（旁白，每个 "> " 行为一行录音），然后根据项目中已存在的模板编写 plan.md。references/draft.md 解释了每个部分。其核心是逐场表格：针对每个镜头，包含旁白、我们看到的内容（以及角色在此镜头中的动作）、摄像机和动画、入场和退场过渡、灯光和色彩、音效和音乐。此外，还包括外观、运动、灯光、过渡和音效计划、质量规格、短视频（如果是“两者”）、带有来源的事实以及成本。同时编写 2-3 个钩子选项（每个包含第一行文字和第一帧画面）。对于短视频，需遵循 draft.md 中的“前 3 秒”规则：1 秒内出现惊喜，第 0 帧带有声音的动作，明亮的第一个画面。真实的短视频数据表明，胜败在此一举；用户自己的数据记录在 references/channel-numbers.md 中。

草稿审核： 使用 plan.md 和 script.md 生成审核代理（review.md，“生成代理”）。修复它发现的所有缺陷以及草稿可以修复的、评分低于 2 分的项目；将其选择的钩子纳入草稿；在 out/review/decisions.md 中记录采纳和未采纳的内容。

然后展示给用户：在聊天中提供一个简短摘要（用几句话描述故事，用紧凑列表列出场景，任何需要用户决定的事项，以及审核者的预计分数在一行内），并附上 plan.md 的链接。请求批准或修改，修订后重复此过程，直到用户说“开始”。在此之前不要录制、生成或制作任何动画——这是用户的规则。

2. 语音（如果有配音）

• 默认语音（video.json：Gemini "Kore"，speed 为 1.2）无需询问。新的语音或风格：vk.py voice samples → 发送样音（SendUserFile）→ ✋ 用户：他们通过听觉选择（代理无法听到声音，因此此项无需提交审核者）。在 video.json 中设置，包含 speed。
• vk.py voice record（缓存；相同的行可从其他项目免费重用），然后 vk.py words（词语时间戳 + 检查每行是否与脚本内容一致；倾听任何被标记的行）。
• Gemini 402 错误 = 预付费积分耗尽：停止并告知用户。

3. 外观 ✋ 审核者

• 按照已批准草稿的资源列表制作每个资源（代码、表情符号、Gemini 或现有资源）：
  • 现有精灵放入 scripts/build.py 中的 CHARACTERS / PROP_DIRS；
  • 生成的（仅当已批准）：使用图像生成工具（如 Gemini [Nano Banana]），切割成透明 PNG 并以相同方式导入（toolkit.md，“Gemini 图片”）；
  • 表情符号：<Emoji char="🚀" .../>（fx/emoji.tsx），配合场景的边缘光和接触阴影；
  • 代码：在场景中使用 fx 库（LitSphere, Sun, shapes, DrawPath...）绘制。
• 构建 3-4 个风格帧——草稿中的关键时刻，完全打光——作为联系表（vk.py stills ...）并发送给审核者（“过程中的一次选择”）：批准外观或指出需要修改之处。记录答复。

4. 构建

1. scripts/build.py：根据草稿填充——暂停、提示点（c.at(line, 'phrase')）、MOVES（每个部分如何进入画面）、effects()（每个事件的音效）、music()（情绪、强度曲线、重音——或已创作的乐谱）、ambience()、YouTube 文字。运行 vk.py build。
2. 场景：每个场景对应 src/scenes/ 中的一个文件，以故事秒为单位根据提示点编写，使用 src/fx（摄像机、景深图层、灯光、粒子、动态文本、角色轨迹）。在 src/Video.tsx 中列出它们及其过渡。确保角色参与到动作中（站在、骑乘、指向、对屏幕上的内容做出反应）——角色只是漂浮着看起来像是填充内容。首先分镜每个镜头——放置、计时到其提示点并移动——然后再进行灯光和丰富度处理。移动不仅仅指角色：从分镜开始，每个镜头都有一个漂移或移动的摄像机、CamLayer 景深带和其他运动的物体。一个在静止世界背景中角色运动的短视频即使得了 20/20 分，一旦在运动中观看仍被认为过于平淡。
3. 故事板 ✋ 审核者： vk.py animatic 以半尺寸渲染整个视频，使用真实音效且无运动模糊（30 秒短视频约需 1.5 分钟），并对其运行节奏检查。将其发送给审核者（故事板提示）。现在修复钩子、时机和清晰度，然后再进行精细化处理。
4. 短视频（如果是“两者”）：通过 kit.shorts.build 在 build.py 中指定规格，src/shorts/ 中每个短视频一个场景。
5. 丰富度处理：对照 references/pro-look.md 中的“使其丰富”逐镜头检查，并在任何镜头平淡的地方添加效果。每个镜头都需要：
   • 具有景深的背景；
   • 可见的光源；
   • 主体融入场景；
   • 前景元素；
   • 永不锁定的摄像机；
   • 背景动态；
   • 完成感；
   • 音效。

每个视频都应感觉内容丰富，因此这是工作的一部分，而非额外选项。遵守克制规则以保持画面干净，并避免在文字上添加效果。

5. 检查（循环直至干净）

vk.py qa 将每个提示点和每个过渡中点渲染成联系表（out/qa/），然后运行自动检查 → out/qa/<组件>_checks.md：YouTube/TikTok 按钮和标题下方的文字、小于 44px 的文字、重叠或超出帧范围的文字（在页面本身上测量）；以及在新渲染上，检查画面几乎不变的拉伸部分、背景静止的镜头（画面低于 25% 区域运动）、语音中的间隙、沿帧边缘暴露的条带、循环接缝和响度。修复它列出的每个问题，并查看每个“值得注意”的项目。然后根据 references/pro-look.md 中的检查表检查联系表——中途过渡、光照方向、场景中的角色、无平淡帧（任何看起来扁平或空白的帧都要丰富化）——修复，并再次运行（vk.py qa --auto 仅重新运行检查，约一分钟）。在完全渲染前，进行一个短测试渲染（vk.py render --frames 0-150）以查看真实运动和渲染速度。渲染会重用帧未更改的每 4 秒块，因此修复后只需再次运行渲染（仅在更改画布绘制或交换视频文件后使用 --fresh）。

6. 最终 ✋ 审核者

• vk.py final（以及针对每个短视频的 vk.py final --comp Short-<id>）：1080p H.264，备份为 v1/v2...，检查大小、帧率、编码器、-14 LUFS 和真实峰值。不生成手机预览或 720p 副本——仅交付 1080p 文件。然后对其运行 vk.py qa --auto。
• 最终审核（review.md，“轮次和何时停止”）：审核者根据检查表评分并选择标题。修复缺陷和排名最高的修复项，记录决策，再次渲染，并将新版本与上一个版本一起发送以供比较。当得分达到 18/20 且无任何项目为 0 分且无未解决的缺陷时通过；3 轮后停止，或者当某轮未发现新问题且分数保持不变时提前停止。
• TikTok（当用户也在那里发布短视频时）：vk.py final --platform tiktok → " (TikTok).mp4"：无颗粒效果，一半的灰尘，更高的比特率和轻微锐化，因为 TikTok 会强力重新编码每个上传。
• 缩略图（src/Thumbnail.tsx → 1280×720 jpg），captions.srt，youtube.md（标题、带章节的描述、标签、AI 语音声明）；短视频的 shorts.md。

7. 交付

当完成的视频小于约 30 MB 时（短视频通常如此），使用 SendUserFile 发送；否则给出可点击的路径（TikTok 剪辑通常更大：给出其路径）。逐场景总结视频内容及其检查结果：审核者的最终评分（以及之前的轮次）、任何仍低于 2 分的项目、审核者的频道注释（关于整个频道的事项——由用户决定），并说明审核者仅通过仪表来评判音效：用户亲自用耳朵听是最后的检查。添加上传说明。然后保存或更新项目记忆笔记（制作了什么、位置、用户做出的决策）。当用户后来问起已发布的短视频表现如何时，将其数据行添加到 references/channel-numbers.md 中。

始终适用的规则

references/house-rules.md 包含常设规则——每个视频阅读一次。简短版本：切勿打印 API 密钥；未经明确同意不得使用 Gemini 图像；切勿下载歌曲或将其他艺术家的歌词显示在屏幕上；“只是问问”的问题只给答案，不进行构建；先起草再构建；仅限 1080p；审核者回答阶段性问题，而简报、草稿、新语音、经费以及任何公开事宜则留给用户。

参考文件

• references/review.md - 审核代理：谁决定什么、10 项检查清单、每个阶段的提示词、决策日志以及何时停止。
• references/draft.md - 如何编写草稿（plan.md）并呈现，包括短视频的前 3 秒规则。
• references/channel-numbers.md - 用户自己的 YouTube 统计数据模板（每个短视频的留存率、每个开头的作用）以及如何阅读 Studio。
• references/pro-look.md - 专业标准：过渡、动画、灯光、粒子、字体、声音、质量检查、渲染性能以及每个方面的组件。
• references/toolkit.md - videokit 命令（自动检查、故事板、TikTok 剪辑）、项目布局、故事时钟、build.py 钩子、短视频、音乐视频、Windows 注意事项。
• references/house-rules.md - 常设规则及原因。