视频审查 是做什么的？
该工具将视频文件或 Remotion 项目转换为可阅读的审查包：帧作为 PNG 文件、音频检查结果、每帧的叙述行和 OCR 识别的屏幕文本、自动检查结果以及自上次审查以来的变化，全部整合在 report.md 中。您的工作是运行它，然后从审查包中审查视频。
1. 运行工具
使用以下确切的命令运行它（它可以从 Bash 和 PowerShell 工具中运行），使用用户的路径并加引号：
powershell -NoProfile -ExecutionPolicy Bypass -File "${CLAUDE_SKILL_DIR}/review-video.ps1" "<视频文件或Remotion项目文件夹>" [选项]
- 视频文件（MP4、MOV 等）：每 2 秒一帧，在每次场景变化附近以及结尾处。
- Remotion 项目文件夹：使用
npx remotion still渲染静态帧（无需完整渲染），并单独渲染音频。除非指定了-Composition <id>，否则它会使用第一个构图；输出会列出其他构图。该项目需要已经运行过npm install。
有用的选项（全部可选）：
| 选项 | 用途 |
|---|---|
-Composition <id> | Remotion：要渲染哪个构图。 |
-Frames 0,90,450 | Remotion：仅渲染这些帧号。 |
-Interval <秒> | 常规帧之间的秒数（默认 2）。对于长视频，请使用 4 或更大。 |
-Narration <文件> | 仅当叙述未自动找到时使用的叙述来源：.srt、.vtt、.csv、.md 录制表或 voiceover.json。 |
-Project <文件夹> | 当视频位于其项目之外时，搜索叙述的文件夹。 |
-OutDir <文件夹> | 写入审查包的路径。 |
-CompareWith <文件夹> | 与较旧的审查文件夹（例如，先前文件名的）进行比较。默认情况下，每次运行都会与同一视频的上次运行进行比较。 |
-ChangesPdf | 当用户只想要更改时，也生成一个仅包含更改帧的 PDF。 |
-KeyFramesPdf | 在审查文件夹中生成 key-frames.pdf：大约 15 到 20 帧，每个场景一个完全构建的帧加上标记的帧，标有时间戳、场景和问题，小于 10 MB。如果审查文件夹中已有完整的审查，则从这些帧构建，且不会更改其他内容；否则，会先运行审查。添加 -NoPdf 以跳过完整的联系单。 |
-KeyFramesMaxMB <n> | key-frames.pdf 的大小限制（默认 10）。 |
-WordsPerSecond <n> | 阅读时间检查的阅读速度（默认 3）。 |
-NumberWordsFrom <n> | 从此值开始检查口语中的数字单词（默认 10）。 |
-SafeMargins 上,右,下,左 | Shorts 在 1080x1920 下的安全区域边距（默认 288,192,672,48，基于 Google 的谨慎参数）。 |
-WordList <文件> | 拼写检查接受的额外单词。 |
-SceneThreshold 0.3 | 用于摄像机素材（默认值 0.02 适用于带有淡入淡出效果的幻灯片）。 |
-NoOcr | 跳过屏幕文本检查。 |
-NoPdf | 当用户只需要您的审查时，跳过 PDF。 |
-NoAudio | Remotion：跳过音频渲染。 |
长视频需要一些时间：8 分钟的视频大约需要 2 分钟，每个 Remotion 静态帧大约需要 4 秒。使用 10 分钟的超时时间。输出的最后几行给出了 report.md、帧文件夹和 PDF 的路径，以及音频、文本检查和更改的摘要统计。审查包位于视频旁边的 <视频名称>-review\ 中，或者在 Remotion 项目内的 out\<构图>-review\ 中，除非指定了 -OutDir。每次运行都会在 previous\ 中保留上一次的运行。
如果输出以 FAILED: 结尾，请停止操作并告知用户原因。如果缺少 ffmpeg，修复方法是 winget install --id Gyan.FFmpeg -e，然后打开一个新终端。以 WARNING: 开头的行也会出现在报告顶部，请将这些信息传递给用户。
2. 浏览或完整审查
运行工具的代价很低；打开帧才会消耗用户的使用量，因为每打开一帧就是读取一张图片。对一个 15 分钟的视频进行完整审查，如果使用六个 Opus 子智能体打开每一帧，可能会耗尽整个使用会话。因此：
- 默认情况下进行浏览，除非用户明确要求完整审查（例如说“完整审查”、“每一帧”、“全部检查一遍”）。在浏览模式下，以
report.md为基础：查看摘要、检查结果、叙述时间线以及每帧的 OCR 文本和标记。通过报告中的行查看场景变化帧（“场景结束”和“场景变化”），并且只在看起来有问题时才打开帧图像：标记的检查、与屏幕文本不匹配的叙述行、变化的帧、该时刻的音频问题，或者应有幻灯片但 OCR 文本为空或乱码。最后说明这只是浏览，以及打开了多少帧。 - 始终打开一些真实帧，无论是浏览、纯文本审查还是仅基于时间线的评估：每个场景中一个完全构建的幻灯片（“场景结束”帧，一旦所有内容都已出现），或者如果场景不明确，则在视频中均匀分布 15 到 20 帧。这些帧能展示文本无法体现的视觉风格（布局、重叠、溢出框、对比度、空白帧）。对于长视频，让负责浏览的 Sonnet 子智能体打开它们。最后始终说明打开了多少帧。
- 仅在要求时进行完整审查。 如果视频超过 5 分钟（参见
report.md摘要中的Length和Frames），在打开任何帧之前停止：告诉用户有多少帧以及您将打开多少帧，说明完整审查会消耗他们大量使用量，并询问是否继续，提供浏览作为替代，或者使用更大的-Interval重新运行以获得更少的帧（例如，-Interval 4将常规帧减半）。等待用户的回答。 - 当进行完整审查时：最多同时运行两个子智能体，总共最多打开 100 帧，除非用户提供了其他数字或说“每一帧，无上限”。除非用户要求 Opus（如果用户要求，则使用它，但提醒一次这会消耗更多使用量），否则子智能体使用 Sonnet。给每个子智能体分配自己的帧范围以及
report.md中相应的行，并要求它们只返回发现的问题。
粗略帧数估算：-Interval 2（默认值）每分钟视频产生 30 个常规帧，-Interval 4 产生 15 个，-Interval 10 产生 6 个，再加上每个场景变化最多两帧。
用户通常如何提问
| 用户说 | 您应做 |
|---|---|
| “审查 C:\path\to\video.mp4” | 浏览。 |
| “对 C:\path\to\video.mp4 进行完整审查” | 完整审查，最多 100 帧（如果超过 5 分钟，请先询问）。 |
| “...完整审查...，每一帧，无上限” | 对所有帧进行完整审查。如果超过 5 分钟，请先询问，说明这可能会消耗整个使用会话。 |
| “...使用 Sonnet 子智能体” / “...使用 Opus” | 子智能体使用该模型（Sonnet 默认就是）。 |
| “使用 Sonnet 浏览它，编写一个时间线文件，然后从时间线给我您的总体意见” | 运行工具，然后让一个 Sonnet 子智能体浏览审查包，打开关键帧样本（每个场景一个完全构建的幻灯片），并在审查文件夹中编写 timeline.md：每个场景一个条目，包含时间范围、简述叙述、简述屏幕文本、视觉效果描述以及任何问题。仅阅读该文件（您自己不再打开帧），并给出总体意见：结构、节奏、清晰度、视觉风格，以及幻灯片是否支持叙述。说明打开了多少帧。 |
| “为 C:\path\to\video.mp4 制作审查 PDF，以便我可以将其附加到聊天中” | 运行工具，并给出 PDF 的完整路径。除非被要求，否则不进行审查或打开帧。 |
| “制作一个时间线文件和一个关键帧 PDF ... 以便我可以将两者都附加到聊天中” | 使用 -KeyFramesPdf 运行工具（见下面的“与聊天 AI 共享”），并按上述方式编写时间线。 |
与聊天 AI 共享
对于长视频，不要附加完整的联系单 PDF（包含数百帧）。提供给用户两样东西：一个文本时间线文件（timeline.md，如上所述）和 关键帧 PDF，使用 -KeyFramesPdf 生成（如果不需要完整 PDF，则添加 -NoPdf；如果文件夹中已有审查，它会重用帧并秒级完成）。它包含大约 15 到 20 帧：每个场景一个完全构建的帧加上审查标记的帧，每个帧标有时间戳、场景名称和问题，小于 10 MB，保存为审查文件夹中的 key-frames.pdf。给出其完整路径。如果工具未能找到清晰的场景（没有编号的页脚徽标），它会均匀分布帧并在标签中说明。它自身无法发现视觉问题，所以如果您发现了一些问题（重叠、空白帧），在交付时指出哪些时间戳需要查看。完整 PDF 最适合短视频（如 Shorts），或者使用 -ChangesPdf 仅获取更改的帧。
3. 审查视频
- 阅读
report.md。顺序：警告；自上次审查以来的变化（仅当有上一次运行时：变化的帧，带有指向旧帧的链接以及添加和删除的单词）；摘要；音频发现；叙述时间线（每行带有开始、结束和匹配分数）；屏幕文本检查（拼写、阅读时间、数字、Shorts 安全区域）；然后是每一帧的表格，包含时间、抓取原因、在frames/中的文件名、该时刻的叙述、OCR 文本及其标记。“（暂停；上一行）”表示无人说话，并且显示的行是刚才说过的。 - 如果用户询问了什么发生了变化，或者存在变化部分，则从变化的帧开始：将每个帧与其前一帧并排打开，并说明变化。
- 将每个幻灯片与其叙述行进行比较。在浏览模式下，从报告中的 OCR 文本进行比较，只打开看起来有问题的帧（见第 2 节）。在完整审查中，在商定的上限内使用 Read 工具打开帧：首先是标记为
end of scene的帧（每个都是即将变化之前的完整幻灯片）和scene change的帧（每个都是稳定后的下一张幻灯片），然后是每个被标记的帧，最后是叙述行发生变化或屏幕上有内容构建的常规帧。 - 将自动检查视为线索而非结论，并在帧图像中确认每个问题：
- 拼写：OCR 可能会误读小字、模糊字或等宽字体文本，并且一些标记的单词可能是故意的（名称、故意展示的误听单词）。只报告图像确认的问题。
- 阅读时间：被标记的幻灯片包含的新单词数量超过了给定单词/秒速度下可容纳的数量。带有许多标签的叙述性图表容易触发此检查；指出哪些幻灯片确实需要更多时间。
- 数字：屏幕未显示的口语数字可能是真正的错配（幻灯片显示不同的数字），或者是 OCR 遗漏的数字（通常是大标题数字）。检查帧。
- 安全区域：水平视频中 YouTube 叠加边距内的文本。默认边距是最谨慎的已发布参数，因此优先关注靠近底部和右边距的文本。
- 在您打开的帧中，还需通过肉眼检查：屏幕文本、数字、名称或标签是否与叙述不一致；截断或重叠的文本；低对比度；空白或黑色帧；占位符或遗留内容；标记为“未找到”的叙述行；以及报告中的音频问题（削波、真峰值高于 -1 dBTP、咔嗒声或爆音、视频中间的静音、远离约 -14 LUFS 的响度）。
- 简洁地报告：首先是问题，每个问题附上帧号和时间戳（例如
#14 00:22.00）以及问题描述，然后是音频发现，最后是工具无法检查的内容。如果一切匹配，则直接说明。除非用户要求，否则不要更改项目；如果标记的单词是正确的，可以建议将其添加到项目文件夹中的review-words.txt。
PDF 文件
<名称>-review.pdf 位于同一文件夹中：封面页包含音频发现、检查和任何更改，然后每页 6 到 9 帧，每个帧标有时间戳、任何发现的问题（红色）、叙述行和 OCR 文本（蓝色，拼写错误带下划线）。它保持在 20 MB 以下。使用 -ChangesPdf 时，还会生成 <名称>-changes.pdf，仅包含更改的帧。当用户想要附加到 Claude 聊天或发送给他人时，给出完整路径。使用 -MaxPdfMB <n> 可以设置更小的限制。key-frames.pdf（使用 -KeyFramesPdf）是用于附加到长视频的文件。