AI 科普长视频（横屏 / 10-30 分钟）制作全景调研

调研日期：2026-07-30 方法：8 个并行子 agent 多方调研（4×Haiku 检索 + 3×Sonnet 分析 + 1×Opus 架构），逐条交叉核对 交叉核对说明：报告中凡厂商自测数据、无法验证的数字、子 agent 之间互相矛盾的说法，均已就地标注。第 12 章列出本轮实际抓到的错误。

#目录

• 0. 先读这段：整轮调研的六个核心结论
• 1. 生产逻辑：2026 年的行业共识
• 2. 标杆逆向：他们实际是怎么做的
• 3. TTS 配音
• 4. 画面与动效
• 5. 时间轴对齐：整套流水线的技术地基
• 6. 素材来源与版权
• 7. 脚本层
• 8. 开源项目 / Claude Code skills / MCP
• 9. 成本、效率杠杆与商业回报
• 10. 合规红线（这一章不要跳过）
• 11. 定制方案：基于现有资产的自动化流水线
• 12. 交叉核对：本轮抓到的错误与存疑项
• 附录 A：可直接用的 ffmpeg 配方
• 附录 B：可商用中文字体白名单

#0. 先读这段：整轮调研的六个核心结论

① 没有一键生成。 真正能讲清楚 AI 概念的长视频，全部是「分环节专业化 + 人工卡点把关」的混合流水线。纯端到端 AI 生成 10 分钟长视频，2026 年质量仍不稳定；主流做法是拆成场景（每段 5-15 秒）分别生成再拼接。

② 音频先行，时间戳倒推画面。 这是本轮调研中被最多独立来源验证的一条铁律：先出完整旁白音频 → 拿到词级时间戳 → 再按时间戳排画面。绝不能反过来（先定画面时长，再让 TTS 变速去凑）。

③ 讲 AI 这个题材，PPT / 屏录口播的性价比压倒性最高。 证据链高度一致：跟李沐学AI 每期约 5 小时录制、10 天一期；ZOMI酱一个人做、熟悉主题一个周末出片；李自然说 20 分钟视频只准备 10 分钟。反面证据：Kurzgesagt 单集 1200 小时，回形针 20 人团队仍要 3-4 周/期——这种重制作套到「这周的论文下周就过时」的 AI 题材上，等动画做完内容已经凉了。

④ 钱不在 API 上，在人工上。 一条 20 分钟视频的 API 总成本只有 ¥100-500（甚至更低）；而 AE 动效外包是 ¥6,000-12,000/分钟。所以「用 AI 降本」的收益全部来自替代人工环节，省 API 钱毫无意义。

⑤ 两条政策红线是硬约束，不是注意事项。 国内《AI 生成合成内容标识办法》2025-09-01 已施行，不标注最高罚 100 万；YouTube 2025-07-15 把「重复内容」政策改名为 inauthentic content，明确覆盖 AI/模板批量生产内容，判定标准是有没有「独特的人类附加价值」。批量同质化 AI 科普号会被断变现。

⑥ 讲 AI 有一批现成可视化工具可以白嫖。 BertViz（注意力热力图）、Netron（模型结构图）、Transformer Explainer（Token 流动交互演示）——直接录屏比自己做动效省一个数量级的工。Two Minute Papers 整个频道就是靠「画面全部来自论文作者自己发布的官方 demo」把素材成本压到接近零。

#1. 生产逻辑：2026 年的行业共识

#1.1 标准链路

选题与调研
   ↓
脚本（母稿 → 口播稿）        ← 决定成败的 80%
   ↓
分镜 / shot list
   ↓
TTS 配音（音频先行）          ← 此处产出「权威时钟」
   ↓
词级时间戳（TTS 原生 / 反向对齐）
   ↓
画面生成（按时间戳排布）
   ↓
字幕 + BGM + 音效
   ↓
合成渲染 → 响度归一化 → 合规标识注入
   ↓
封面 / 标题 / 章节 / 简介 → 投稿
   ↓
（可选）切竖屏短视频引流 + 文字稿二次利用

为什么必须音频先行：画面的存在意义是服务讲解。旁白时长是唯一不可压缩的量（语速改变会直接损伤听感），而画面时长可以任意伸缩。因此把音频时长设为权威时钟、画面去适配它，是唯一不会互相打架的顺序。

一个值得抄的工程约束（来自实践）：合成后校验音画时长差，超过 0.12 秒直接硬失败，不允许静默容忍。音画不同步是这类视频最容易被观众察觉、也最容易在自动化流水线里被静默引入的缺陷。

#1.2 三种路径对比

对路径 C 的重要修正：市面上多数介绍把它的缺点写成「质量一般」。实际风险等级更高——是账号失去变现资格。见第 10 章。

建议：AI 科普长视频选 A 起步、逐步长成 B。A 用来验证选题和表达方式（这是真正的不确定性所在），B 用来在选题验证之后把机械劳动压到接近零。不要一开始就搭 B 的完整基建，那是在为还没验证的内容形式提前付账。

#2. 标杆逆向：他们实际是怎么做的

说明：以下信息来自公开访谈、幕后视频、媒体报道。查不到的一律标注「未找到公开信息」，未做推断填充。

#2.1 总览

#2.2 三个最值得抄的细节

① 李沐的 AutoCut。 他自研了一个开源剪辑工具，基于 Whisper 语音转文字，自动识别并剪掉静音段和口误重复片段，粗剪后再人工精修。这是「个人产能天花板」被顶高的关键工程手段——口播类视频的剪辑工时大头就是找口误。

② 李沐的投入分配是反直觉的。 他买了两支 300 美元以上的专业麦克风，理由是「长视频音质至关重要」；但后期极简、画面就是 PPT 加论文截图。音频优先于画面精度——这是这类内容的正确资源分配。他还坚持给中文内容加字幕，方便无声观看。

③ Two Minute Papers 的素材策略。 讲论文时，画面几乎全部使用论文作者自己公开发布的 demo 视频和图表。这既零成本又自带权威感。中文对应做法就是「论文原图直接贴」——不要重画。

#2.3 性价比排序（针对「讲 AI」这个具体题材）

1. PPT / 屏录口播 —— 最高。AI 科普的核心价值是信息密度和专家可信度，不是视觉奇观。且 AI 领域更新极快，高频输出本身就是竞争优势。
2. Manim 代码动画 —— 中高，但有门槛。只在讲「数学结构 / 算法机制」（注意力机制、扩散去噪、梯度下降）时收益远超静态图。讲「这篇论文说了什么」用 Manim 是过度投入。
3. 3D 建模动画 —— 中等，题材受限。只在内容涉及物理结构（芯片内部、硬件装机）时划算。讲抽象算法逻辑，3D 的边际视觉收益反而不如 Manim 的符号化动画直观。
4. 手绘 / 矢量插画大制作 —— 在 AI 题材上性价比最低。适合半年一部、面向全年龄泛科普的选题。

#2.4 中文 AI 科普的「低配但有效」通行模板

拆解下来是五个要件：

1. Keynote/PPT 大字标题 + 关键词卡片：每页一个核心概念，压缩认知负荷，讲者有视觉提示词、降低 NG 率。
2. 论文截图 / 架构图直接贴入：不重绘，直接截论文原图（模型架构图、实验结果表、公式），省时间且借论文原图的权威感。
3. 口播为主线，不做提词器式朗读：夹杂「我觉得」「这里有意思的是」「大家应该注意」等主观评述，强化专家人设真实感。
4. 少量动态字幕 / 关键词高亮：自动语音转文字批量生成，满足无声观看场景。
5. 极简后期 + 自动化降本：用 Whisper 类工具自动去口误做粗剪，人工只做少量精修。

该模板的成立前提：观众本身有专业背景或学习动机，愿意为信息密度容忍视觉粗糙。要「破圈」传播的内容不能照搬。

#2.5 长视频留存结构

• 前 15 秒必须给出价值主张（这个视频讲什么、为什么值得看下去）——可带来 1 分钟处 18% 更高留存。
• 第 5 秒留存率目标 70-85%；前 3 秒直接影响算法是否加大分发。
• 健康曲线形态是「陡降后趋缓」：前 15-30 秒是筛选期，非目标受众快速跳出属正常；若前段流失超 40%，说明开场设计有问题。
• 结构上是「钩子 → 兑现 → 下一个钩子」循环。这也是章节化（YouTube chapters）的底层逻辑：每个章节本质是一次新的钩子。
• 节奏：Fireship 用每分钟 10-15 个剪辑点维持注意力。长视频可在开场 30 秒用高频视觉刺激完成留人，中段放缓回归内容。

留存数字来自公开的创作者运营指南，非平台官方逐字披露的内部数据，作为参考基准而非精确指标。

#3. TTS 配音

#3.1 商业 API 对照

#3.2 开源本地方案

#3.3 三档推荐

• 零成本起步：Azure TTS 免费额度（500 万字符/月，足够个人用量）；或 edge-tts（免费但非 SLA，必须串行调用否则限流）。
• 中文质量优先：火山引擎豆包 TTS 2.0（¥3/百万字符 + 5 秒克隆 + 指令式情感），这是本轮调研里综合性价比最高的选择。
• 需要精确词级时间戳：MiniMax 官方 t2a_v2，subtitle_enable: true + subtitle_type: "word"，返回毫秒级 JSON。
• 全本地 / 隐私优先：IndexTTS2（8GB 显存门槛最低、速度最快）。

#3.4 长视频配音的六个工程要点

① 分句。 3000 字以上直接喂 TTS 会出现五类退化：停顿漂移、语速递增、情绪偏移、韵律坍缩、多音字读音错误增多。按自然段切分，每段 300-500 字。

② 并发控制。 API 并发设 5-10，过高触发限流。edge-tts 必须串行。

③ 句间停顿用 SSML 显式插入，不要靠 TTS 自己判断：

<speak>
  <s>这是第一句话。<break time="500ms"/></s>
  <s>这是第二句话。<break time="800ms"/></s>
</speak>

④ 响度归一化到 -16 LUFS（对话/讲解类标准）。平台参考值：YouTube -14 LUFS，播客 -16 LUFS，EBU R128 广播 -23 LUFS。

⑤ 读音修正。 建立领域读音词典处理：英文缩写（AI → A I）、数字（2024 → 二〇二四）、多音字（用 SSML phoneme 标注拼音）、外国人名（Schrödinger → 薛定谔）、希腊字母（λ → lambda）。

⑥ 权威时长以 ffprobe 实测为准，不要相信 TTS 返回的 duration 字段。

#3.5 声音克隆的合规

• 只克隆本人声音；克隆他人用于商业目的不可行。
• 公众人物仅限非营利用途。
• 国内：需明示同意；火山引擎的声音克隆需身份认证。
• 平台 ToS 普遍明确禁止诈骗、模仿政治人物、冒充知名人士。
• 采集标准：30-60 秒（越多越好）、安静室内、≥44.1kHz、覆盖多种情感语气。

#4. 画面与动效

#4.1 三条路线

#4.2 代码化三选一：怎么选

⚠️ Remotion 许可证（本轮重点核实，多数二手介绍都写错了）

Remotion 不是 MIT/Apache，GitHub license 字段是 NOASSERTION（自定义商业许可）。

• 免费适用：个人；非营利组织；员工数 ≤ 3 人的营利组织；评估期未商业化者。
• 免费包含商业用途：官方明确允许——只要你不是把 Remotion 本身当产品卖，用它做视频去接商单、走平台激励、卖课都在免费许可内。
• 付费档：Creator $25/seat/月；Automator $0.01/render + $100/月最低消费。
• 最容易踩的一条：人头跨实体叠加——如果雇了外包/顾问一起操作同一套 Remotion 系统，他们的人数会累加进 4 人阈值。

来源：https://www.remotion.dev/docs/license/faq、https://www.remotion.pro/license

推荐组合：Remotion 做唯一合成层，Manim 降级为 shot 级插件。即 Manim 只负责渲染公式/数学可视化那几个 shot，输出带 alpha 的透明 MOV 或 PNG 序列，由 Remotion 用 <OffthreadVideo> 内嵌。这样保留 Manim 的表达力，但不让它承担整片时间轴，也不必维护两套渲染器和两套预览。

#4.3 AI 生成画面的实际可用性

通用失败场景：精细手部动作（打字、弹奏）、复杂人脸表情同步、清晰文字显示、高精度物理模拟、连贯多镜头叙事。 通用成功场景：自然风景、通用办公场景、广角人物、转场效果。

结论：文生视频只当 B-roll 补充，不撑主体，不用于精确的科学演示（会失真）。预留 20% 的额外生成和挑选成本。

数字人（HeyGen 140+ 语言 / Synthesia / 腾讯智影 / 剪映数字人）虚拟感仍明显，适合企业内训和多语言批量，不适合建立个人权威。

#4.4 讲 AI 的特有画面：直接白嫖现成工具

这是本轮调研里最省力的一条发现。不要自己从零做动效：

屏幕录制一定用专业工具：Screen Studio（$149/年，自动跟踪鼠标智能缩放）效率比手工关键帧高一个量级；替代品 Camtasia（$249 永久）、ScreenFlow（$129，Mac）。

#4.5 科普视频的八个通行画面套路

1. 动态字幕 / 关键词弹出（打字机、滑入、缩放、模糊聚焦）
2. 屏幕录制 + 缩放跟随
3. 白板手绘（VideoScribe/Doodly，或 Blender Grease Pencil）
4. Ken Burns 静图运镜（缩放 + 平移关键帧，Remotion 里就是 interpolate）
5. 数据图表动画（柱状增长、折线绘制、饼图分割、热力图渐变）
6. 代码高亮逐行演示
7. 分屏与画中画（代码 + 结果对比、原理 + 应用）
8. 转场节奏与音乐卡点（导入概念 2-3 秒、深化讲解 5-8 秒、转场间隔 0.5-1 秒）

#5. 时间轴对齐：整套流水线的技术地基

#5.1 三种方案的实测精度

⚠️ WhisperX 的中文坑（重要）：WhisperX 的 word-level 时间戳靠 wav2vec2 强制对齐实现，其 README 明确说明默认对齐模型只覆盖 {en, fr, de, es, it}，中文不在其中，需要自己去 HuggingFace 找 phoneme-based ASR 模型并自测。 对一个要求稳定的自动化流水线，引入「得自己调对齐模型」的组件是净负债。中文场景优先用 TTS 原生时间戳，兜底用 whisper.cpp（token-level 时间戳精度略低但开箱支持中文，且 @remotion/install-whisper-cpp 直接封装了 toCaptions()）。

#5.2 推荐链路

主链路：
口播稿 → MiniMax t2a_v2(subtitle_enable, subtitle_type=word)
       → wav + subtitle_file(JSON, 毫秒级)
       → ffprobe 量 wav 真实时长（权威时钟，与 TTS 声明值比对）
       → 烘焙成绝对时间轴

兜底链路（零成本）：
口播稿 → edge-tts（串行！）→ wav
       → ffmpeg 转 16kHz 单声道 wav
       → whisper.cpp large-v3, tokenLevelTimestamps: true
       → 与原稿做相似度比对，<0.85 报警（防 ASR 漏字）

#5.3 画面切换点绑到「词」上

这是科普视频「专业感」的技术来源：说到「注意力」那一刻，公式才出现。

实现方式是分镜里不写绝对毫秒，只写相对锚点：

anchor: { type: "sceneStart", offsetMs?: number }
      | { type: "word", wordIndex: number }
      | { type: "phrase", matchText: "注意力机制" }   // 烘焙期在词流上匹配

然后由确定性代码（不是 LLM）在拿到词时间戳后烘焙成绝对 startMs / durationMs。

两条必须硬失败的校验：

1. phrase 锚点匹配不到 → 抛错，不允许 fallback 到 0（这是反幻觉最后一道闸）。
2. 同场景内 shot 的锚点必须严格递增 → 否则说明分镜排序错了，抛错，不允许静默重排。

#5.4 字幕

• 优先在合成层用代码渲字幕（可控、可做卡拉 OK 词级高亮、不依赖 libass）。
• 需要「可关闭字幕」时才走外挂 SRT。
• 中文每行建议 约 18 字。
• 如果非要用 ffmpeg 烧 ASS 字幕，务必带 fontsdir——否则 libass 会静默 fallback 成英文字体，中文全变豆腐块且不报错（见附录 A）。
• 中文字体必须按整片文案子集化（pyftsubset），否则 Noto Sans SC 全量 woff2 有 8-10MB，会拖慢渲染甚至触发超时；子集化后通常 200-400KB。

#6. 素材来源与版权

#6.1 视频 B-roll

#6.2 图片 / 图标 / 插画

• 免费商用：Unsplash、Pexels、iconfont、Lucide、undraw（后两个对代码集成最友好）
• 付费：Freepik、Flaticon、Streamline、IconScout、Noun Project

#6.3 音乐与音效 ——「最容易踩雷的环节」

平台差异：

• 抖音：自动音频指纹检测，未授权音乐可直接封号 → 用官方曲库
• B 站：站内曲库安全；外来音乐通常需被举报才处理
• 视频号：建议用官方库
• YouTube：Content ID 全自动，Epidemic Sound 的白名单机制是靠「频道关联」运作的

#6.4 二次创作引用的实践尺度

• 相对安全：≤20% 时长 + 明确标注来源 + 有实质解说
• 模糊区：20-50%
• 禁区：≥50% 属直接侵权

学术素材：arXiv 论文图的 license 按篇不同（CC BY / CC BY-NC / arXiv perpetual license 混杂），不要一律当 CC BY。抓图时把该篇 license 一起记录下来。

#6.5 素材组合推荐

• 零成本档：Pexels + Mixkit + YouTube Audio Library + undraw/Lucide + 剪映
• 专业档（约 $30-50/月）：Storyblocks + Epidemic Sound
• 工作室档（$100+/月）：多库并用 + Getty/Adobe Stock

#7. 脚本层

说明：本章的补充调研过程中 firecrawl 服务持续 502、WebSearch 配额已用满，改用 WebFetch 抓 DuckDuckGo 结果页 + 逐页抓正文完成。部分知乎/百度文库页因反爬 403，已用同主题转载版替代。凡为推导而非直接引用的，就地标注。

#7.1 结构模板

通用骨架（短视频口播的三段式）

黄金三秒的四种钩子模板

科普长视频六段骨架

⚠️ 这张分钟级占比表是从短视频口播框架外推推算的，未找到专门针对「8/15/25 分钟横屏科普长视频」的公开分钟级模板。作为起点用，不是行业标准。

10 种可直接套用的口播结构（适合选题时挑一个套）：① 问题+反常识+三步拆解 ② 对比+案例+核心套路 ③ 自我挑战+过程记录+结果 ④ 误区+真相+解决方案 ⑤ 故事+感悟+行动建议 ⑥ 数据+结论+操作指南 ⑦ 身份+揭秘+避坑 ⑧ 场景+痛点+方案 ⑨ 提问+回答+延伸 ⑩ 观点+反驳+我的看法。

关键是每个章节都是一次新的钩子-兑现循环，而不是平铺直叙。

#7.2 中文口播语速（已核实）

播音专业标准：250-260 字/分钟。 依据是人耳辨析率——每秒 4-5 个字，即每分钟 240-250 字；超过这个区间会造成理解压力。

播音语速的历史演变（说明为什么坊间数字差异这么大）：

央视播音员实测：张宏民 350、邢质斌 329、罗京 280 字/分钟。短视频口播的自媒体经验值约 300 字/分钟。

坊间 180-220 / 200-260 / 220-280 三种说法的差异来源：① 是否计入换气停顿（播音训练常按「净说话时间」算，去掉停顿会显著推高数值）；② 内容类型（新闻快、专题讲解慢）；③ 年代变化。

科普长视频建议取 220-250 字/分钟（比新闻播音松弛、需给听众消化时间，但比日常聊天紧凑）：

这是工程估算值（从 250-260 播音标准向下调整到讲解型区间推算），不是某个来源直接给出的「科普口播专用数字」。正式排期前用你的实际配音引擎跑一段 30 秒-1 分钟样本反推真实语速再校准。

一条播音规则对科普特别重要：同一篇稿件中，人名、数字、核心结论要比通篇稍微放慢。这直接对应到 TTS 的 prosody rate 分段控制。

英文对照（LingoChampion 基于 YouTube 字幕分析 23 个频道 63 条视频，采集于 2026-01，不含中文数据）：

中英文信息密度不同，字数不能直接类比，但「Tech 类目 200 WPM」可作为讲解型内容的语速特征参考。

#7.3 母稿 → 口播稿的改写规则

核心认知：「文章是给眼睛看的，口播是给耳朵听的」——这是感知路径的重新设计，不是文体转换。

五条可执行规则：

1. 钩子重设计：钩子要回答「观众凭什么此刻停下来听你说话」。结构 = 利益或威胁 + 立刻发生感。
2. 信息颗粒度拆细：把每个需要解析的地方拆开，确保每一小块能被即时消化。不是加语气词，而是重新切分信息单元。
3. 情绪密度适配：调整的是情绪浓度，不只是语气词。
4. 一句话删减测试：对每句自问「这个信息拿掉，观众会不会听不懂后面的内容？」——背景信息和延伸解释在口播里是噪音，能删就删。
5. 结尾从情绪里生长：CTA 要跟观众听完后的情绪状态对齐，不能生硬拼接。

零基础改写三步法：

• 读出声改稿——读一遍，拗口的长句直接拆短（判定标准就是「读的时候会不会喘不上气」）
• 名词换动作——抽象名词换成具体动作/画面（「提升效率」→「少走三步路」）
• 加「你」和场景——把「用户」改成「你」，给出具体场景

改写映射表：

表中「如下图所示」「数字怎么念」「术语首次出现」三条为综合推导的工程规则，未找到专门列出这三条的单篇权威文章。

一个可执行的约束：每个场景（对应一段 TTS 音频）的旁白控制在 25-60 字（约 8-20 秒）。超过就拆——一个场景对应一段音频，太长会让重配音的粒度变粗。

#7.4 「AI 味」的识别与去除

这一节有三个独立信源交叉验证，是本章来源最扎实的部分。

AI 文本的 6 个可检测维度：

1. 困惑度（Perplexity）低——AI 总选概率最高的词，人类用词更跳跃
2. 突发性（Burstiness）低——人类文本长短句交替，AI 句长更均匀（可用句长标准差量化）
3. 结构指纹——过渡词滥用、段落开头模式化、对称结构癖好（「不仅…而且…」）、总以总结性结尾收尾
4. 词汇分布偏差——高频 AI 词
5. 标点格式模式——倾向使用「完整」的标点组合
6. 语义一致性过高——连贯性「过于完美」，不会像人类一样跑题、插入个人轶事

中文高频词替换表（可直接用）：

其他要警惕的：「旨在」「不可或缺」「显著提升」「体现着」「彰显了」「预示着」。

六大改写策略：

英文场景的硬约束（来自 Stop Slop 规则指南，对中文写作也有参考价值）：

• 删掉清嗓式开场（"Here's the thing:" / "It turns out" / "Let me be clear"）
• 删掉空转强调（"Full stop." / "Let that sink in." / "This matters because"）
• 删掉 16 个虚词副词（really / just / literally / genuinely / honestly / simply / actually…）
• 不用 Wh- 疑问句做修辞性「假提问」
• 不用破折号（em dash）
• 不用被动语态
• 避免极端词（every / always / never / nobody / everybody）
• 二元对比句「Not because X. Because Y.」→ 直接说 Y
• 5 维自评评分卡：Directness / Rhythm / Trust / Authenticity / Density，总分 ≥ 35/50

科普口播稿的自查清单：

□ 过渡词是否只剩「然而/此外/值得注意的是/综上所述」？（出现超 2 次即需替换）
□ 是否每段都用「总结性金句」收尾？（超 60% 段落如此即为 AI 味信号）
□ 句长方差是否过低？（读一遍，若每句字数都接近，故意插几句 5-10 字短句打断）
□ 是否出现「深入探讨/全面解析/至关重要/不可或缺/显著提升」？
□ 「不仅…更是…」这类对称排比是否超过 2 次？
□ 数据结论是否够具体？（「性能有提升」必须换成具体数字）
□ 结尾是否是「这提醒我们……」式空洞升华？（应改为回扣开场悬念）

一个容易忽略的坑：AI 偏爱制造工整的排比金句，因为「人类信任对称性，它感觉像是可见的智能」。连续短句强调本身不是问题，问题是每段都用。科普脚本收尾最容易踩的就是「富有哲理但略显刻意的结论」。

本地有 humanizer-zh skill 可以做这一步的自动化过滤。

#7.5 分镜（shot list）的工具化

国内轻量版 6 栏表（短视频行业最常见）：镜号 / 景别 / 画面内容 / 台词 / 运镜 / 时长

专业级字段（StudioBinder 标准，适合多机位实拍）：Scene Number / Shot Number / Shot Description / Shot Size / Camera Angle / Camera Movement，进阶还有 VFX / Lens / Frame Rate / Sound / Lighting / Location / Prep & Shoot Time / Reference Image 等约 25 项。

纯图形化科普长视频的精简版（没有实拍，把实拍字段换成素材来源）：

镜号 | 对应口播句 | 时长(秒) | 画面类型(图表/动画/素材/文字卡) | 素材来源或 Prompt | 运镜或转场 | 备注

工具选项：Notion 有现成 Shot List 数据库模板；Boords 支持「故事板一键转分镜表」并导出 Google Sheets，也有 AI Storyboard Generator（脚本→故事板）。

但对代码化流水线，最实用的落地形式就是一个 JSON/CSV 数组——每个元素对应一个 Remotion <Sequence>，直接被脚本读取驱动渲染参数，不需要额外的分镜软件。这与第 11 章的 IR 设计是同一件事。

分镜密度基准：

• 平均 每 6-12 秒换一个 shot；10 分钟片约 50-100 个 shot
• 连续 3 个以上同类型 shot 要警惕——那是节奏死板的信号
• 每 90 秒至少插一个「呼吸镜」（B-roll 或小节标题卡），否则观众会累

#7.6 封面与元数据（已核实）

YouTube 封面规格：1280×720 px，16:9，最小宽 640px，文件 <2MB，JPG/PNG/GIF（PNG 因文字更锐利被推荐）。

封面设计规则（有数据支撑的部分）：

• 文字控制在 3-5 个词以内；避免放右下角（会被时长标签遮挡）
• 粗黑无衬线字体 + 描边/阴影/色块背景保证可读性
• 69% 的爆款视频用了人脸，头部创作者中高达 80%；但只有约 5% 的头部视频用夸张表情——表情要真实自然
• 人脸占画面 1/4 到 1/3
• 保持单一视觉焦点
• 配色用高对比、互相「打架」而非融合的颜色；避免红/白/黑（会和 YouTube 界面配色融合），偏好橙/青/黄/紫
• 移动端优先：人脸和关键文字避开画面边缘防裁切

YouTube 章节（Chapters）的硬性格式要求（官方文档，不合规会直接不生效）：

• 第一个时间戳必须是 00:00
• 至少 3 个时间戳，按升序排列
• 每个章节最短 10 秒
• 格式 MM:SS（超 1 小时用 HH:MM:SS），写在视频描述里
• 手动章节会覆盖 YouTube 自动生成的章节

00:00 为什么 RNN 不够用
02:15 注意力机制到底在算什么
07:40 QKV 的字典类比

其他元数据：标题 70 字符以内、关键词前置；描述前两行要有钩子，附时间戳/链接/CTA；标签 5-15 个，主关键词优先。

常被漏掉的步骤：文件命名优化、等 HD 处理完成再设为公开、置顶首条评论、片尾卡与口播里的语音 CTA 时间对齐。

B 站：

• 分 P：把系列/多集打包在同一投稿下，PC 网页投稿页可添加多个分 P
• 「看点」：B 站官方对标 YouTube Chapters 的进度条分段导航功能，用于标注视频分段方便观众跳转

  「看点」的官方操作步骤和字段限制未抓到创作学院原文，正式使用前到 https://member.bilibili.com/academy/ 核实交互路径。

#7.7 横屏切竖屏引流 & 一稿多用

自动切片工具价格（已核实，但价格变动频繁，付款前上官网核对）：

如果你已经在用 WhisperX 或 whisper.cpp 做时间轴对齐，Clipsai 是最省钱的路线——同样基于 WhisperX，自部署零边际成本。

一稿多用的正确路径：口播稿本身就是最好的文章底稿，不要再从视频转录一遍。

写口播稿 → 渲染视频
        ↘ 口播稿去掉画面指代词（「你看这张图」）+ 补回图片图表 → 公众号/博客

这比「转录视频再改写」省一道 ASR 误差。转录方案只在「临场发挥、没有逐字稿」时才有必要（这种场景可用「提词匠」类小程序，支持 100+ 平台链接直接提取，单文件上限 120 分钟/500MB）。

#7.8 成片前质检清单

内容与合规

□ AI 生成标识：片头显式标识 + 常驻角标 + 片尾说明 + 文件元数据隐式标识
□ 投稿时勾选平台的「AI 生成内容」声明（不能只靠自己烧的角标）
□ 素材授权：所有配图/音乐/素材有可商用授权
□ 署名义务已履行（Pexels 摄影师、论文作者）
□ BGM 无 Content ID 风险（Epidemic Sound 已关联频道）
□ 关键数据和结论可追溯到来源（描述区列参考文献）

音画质量

□ 音画同步：时长差 < 0.12 秒；关键词高亮/图表出现时机无肉眼可见错位
□ 响度归一化到 -16 LUFS（ffmpeg loudnorm 验证）
□ 字幕逐条过错别字（ASR 生成的字幕必查同音字）；术语/人名拼写一致
□ 字幕无中文豆腐块（尤其烧字幕路径，检查 fontsdir）
□ TTS 拼接处/剪辑点无不自然停顿

结构与脚本

□ Hook 在开场 3-5 秒内出现
□ 结尾回扣了开场悬念，CTA 只有一个明确动作
□ 无 AI 味残留（过渡词滥用、每段总结式收尾、高频 AI 词——见 7.4 清单）

编码与规格

□ 1080p H.264 yuv420p，CRF 18-20，AAC 128k+
□ 文件命名规范（常被漏掉）

封面与元数据

□ 封面 1280×720、<2MB、文字 3-5 词、避开右下角、人脸占 1/4-1/3、高对比配色
□ 标题 70 字符以内，核心关键词前置
□ 描述前两行有钩子，附章节时间戳和参考链接
□ 章节：首条必须 00:00，至少 3 条，每条 ≥10 秒
□ 标签 5-15 个，主关键词优先
□ B 站：分 P / 看点已设置（系列或长视频拆条场景）

发布前最后一遍

□ 等 HD 处理完成再设为公开
□ 置顶首条评论
□ 片尾卡与口播语音 CTA 时间对齐

#8. 开源项目 / Claude Code skills / MCP

#8.1 项目清单（含定位修正）

#8.2 Claude Code 生态

#8.3 MCP 服务器

#8.4 编排平台

• n8n：模板最丰富（VEO3/Fal.ai + 多平台自动发布 + Google Sheets 控制中心），开箱即用
• Coze：字节官方，抖音原生集成，可直接生成剪映草稿
• Dify：LLM 工作流 GUI，视频合成需自己扩展
• ComfyUI：需 NVIDIA GPU，适合本地精细控制而非工业生产

#9. 成本、效率杠杆与商业回报

#9.1 单集成本（20 分钟精致动画科普）

#9.2 分环节工时

#9.3 外包报价行情

#9.4 API 成本（一条 20 分钟视频）

结论：API 成本低到可以忽略。瓶颈永远是人工时间，不是钱。

#9.5 效率杠杆排序（决定先自动化哪一步）

规律：越靠近观众直接感知的环节（画面质感、叙事节奏、情感表达），自动化越掉质量；越靠近信息处理与素材生成的环节，自动化收益越大。最优策略是「AI 打底稿，人工做灵魂」。

#9.6 平台经济

注意：YouTube 只有约 40-60% 播放会产生广告曝光，实际到手远低于理论 CPM。RPM 是到手数字，CPM 是广告主出价。

跨平台最优时长：8-15 分钟——够长以覆盖 YouTube 广告位，够深以匹配 B 站完播率权重，又不至于弃看率飙升。

#9.7 赛道现状与空位

B 站 2025 数据：AI 相关内容每月近 10 万活跃 UP 主，日均投稿同比 +83%，日均播放时长同比 +100%；知识/科普/科技领域占 2025 百大近三成；科技区带货 GMV 占比 72%。

供给和需求同步暴涨——赛道热，但也更挤。 相对空位：

1. 垂直深挖而非泛 AI 资讯（泛「每日 AI 播报」已严重过剩）
2. 强人格化 + 敢下判断（信息搬运最容易被判「AI 味重」）
3. 一手实测而非复述论文（科技区 GMV 占 72% 说明实测类商业价值高）
4. 长内容的确定性红利（B 站「知识长视频逆势生长」）

#9.8 可持续性

• 行业经验：约 90% 的自媒体停更源于选题枯竭，而非制作能力。建议「批量调研 + 排期发布」而非硬更。
• 回形针停更真相（纠正常见误传）：不是商业不可持续或产能问题，而是 2021 年 6 月团队成员境外言论风波导致主动停更、7 月大陆全平台封禁。这是合规红线案例，不是产能案例——但对科普号仍是警示：事实核查和言论合规不能交给 AI。
• 引入 AI 辅助后，单集工时可压到原来的 30-50%（估算），但叙事把控和事实核查无法脱手。「高频剧场式生产」和「个人深度科普」本质是两条不同的路。

#10. 合规红线（这一章不要跳过）

#10.1 中国大陆：AI 生成内容标识（强制，已生效）

《人工智能生成合成内容标识办法》2025-03-07 公布，2025-09-01 施行（网信办、工信部、公安部、广电总局联合发布）。

要求：

1. 显式标识（视频）：在「起始画面和视频播放周边的适当位置添加显著的提示标识」，可在视频末尾和中间适当位置添加。办法未规定具体时长与文案，实践从严：
   • 片头 2-3 秒显示「本视频含 AI 生成内容」
   • 右上角常驻半透明小字
   • 片尾单独一屏说明（旁白由 AI 语音合成 / 部分插画由 AI 生成 / 事实内容经人工核校）
2. 隐式标识：文件元数据中包含生成合成属性信息、服务提供者名称或编码、内容编号
3. 平台义务：核验隐式标识、周边加提示、提供用户主动声明功能 → 投稿时必须勾选「AI 生成内容」声明，不能只靠自己烧的角标
4. 禁止恶意删除、篡改、伪造、隐匿标识
5. 鼓励采用数字水印
6. 一个存在的豁免情形（办法第九条）：用户申请、且通过协议明确责任、服务提供者留存相关日志不少于 6 个月的，可提供不含显式标识的内容。

   注意这是给「服务提供者」（即 AI 工具方）的条款，不是给内容发布者的免标理由。作为创作者发布视频，仍应按 1-3 项处理。

罚则：不标注最高可处 10 万-100 万元罚款。

适用判断：只要视频用了 AI 配音（TTS）或 AI 生成画面，就落在需要显式 + 隐式标识的范围内。

执行现状：2025-09-01 当天六大主流平台（含 B 站、抖音、视频号）同步上线「AI 生成」角标和隐式元数据功能。抖音已下架超 53.8 万条 AI 侵权/低质视频，处罚超 4,000 个账号。

来源：https://www.cac.gov.cn/2025-03/14/c_1743654685899683.htm

#10.2 YouTube：Inauthentic Content 政策（2025-07-15 生效）

YouTube 将原「repetitious content」政策更名为「inauthentic content」，明确扩大到 AI/CGI/模板批量生产的内容。

关键点：不是禁 AI，是禁「无独特人类附加价值」。被断变现的是「近乎相同的幻灯片/克隆片段」这类重复模板内容；只要最终视频有 unique human-added value，用 AI 工具制作仍可正常变现。

对 AI 科普的含义：批量 AI 科普号是高危区——套用统一模板/统一脚本结构大量出片，极易被判定为 inauthentic content 而失去变现资格。有明确人格化叙事、独立观点、原创视觉的 AI 辅助号风险较低。

#10.3 B 站态度

B 站 2025 版《AI 生成内容创作规范》明确欢迎用 AI 辅助创作提升效率，唯一硬性要求是清晰标注、不误导用户，全文未提及禁止 AI 配音。但实际执行中 AI 内容审核耗时更长，批量上传有频次限制；被处罚的案例集中在「用 AI 批量生成同质化低质内容」。

#10.4 字体版权（大坑）

原则：只用 SIL OFL 1.1 的字体。绝不用系统自带字体。 macOS 上最容易犯的错是 CSS 里写 font-family: "PingFang SC"，本地看着好好的——但苹方不能用于商业视频分发。方正、汉仪等商业字体全部禁止。

详见附录 B。

#10.5 素材署名义务

• Pexels API 的署名是硬要求：「whenever you are doing an API request make sure to show a prominent link to Pexels」+「Always credit our photographers」→ 片尾 attribution 屏不是可选项
• arXiv 论文图 license 按篇不同，逐篇记录

#11. 定制方案：基于现有资产的自动化流水线

本章由 Opus 子 agent 结合已有资产（Claude Code skill 生态、云雾中转、tky 东京 VPS、scribe-studio 白板渲染引擎、media-studio 写稿流水线、Next/Vercel 栈、Firecrawl 自建）设计，并做了 8 次真实 API 探测验证。

#11.1 结论先行

一句话：scribe-studio 的骨架 + Remotion 的画面 + MiniMax 的时间戳。

#11.2 实测结论（含坏消息）

用真实凭据打了 8 次探测：

核心结论：走云雾拿不到词级时间戳，这条路是死的。 唯一硬阻塞是给 MiniMax 官方账号充值。

#11.3 中间表示（IR）设计要点

这是整套自动化的地基：

1. 两段式时间轴：LLM 只写相对时序（anchor 锚点），绝不写绝对毫秒。TTS 出音频后由确定性代码烘焙成绝对 startMs/durationMs。
2. 画面切换点绑到旁白的词：anchor: { type: "word" | "phrase" }——这是「专业感」的技术来源。
3. 素材池化 + 内容寻址：asset 用 sha256 命名，跨项目复用与缓存。
4. shot 与 renderer 解耦：renderer: "remotion" | "scribe" | "manim" | "wemark"。
5. 合规字段内置，不是事后补丁。

核心类型（TypeScript）：

export interface Shot {
  id: string;
  renderer: "remotion" | "scribe" | "manim" | "wemark";
  anchor:
    | { type: "sceneStart"; offsetMs?: number }
    | { type: "word"; wordIndex: number }
    | { type: "phrase"; matchText: string };   // 说到"注意力机制"时切入
  holdUntil?: { type: "nextShot" } | { type: "word"; wordIndex: number } | { type: "sceneEnd" };
  template: ShotTemplate;
  animations?: Animation[];
  subtitle?: boolean;
}

export type ShotTemplate =
  | { kind: "titleCard"; title: string; subtitle?: string; kicker?: string }
  | { kind: "bulletCard"; heading: string; bullets: string[]; revealPerBullet: boolean }
  | { kind: "kenBurns"; asset: AssetRef; from: Rect; to: Rect; caption?: string }
  | { kind: "bRoll"; asset: AssetRef; fit: "cover" | "contain"; overlayText?: string; muteSource: true }
  | { kind: "compareTable"; headers: string[]; rows: string[][]; highlightRow?: number }
  | { kind: "chart"; chartType: "bar" | "line" | "pie"; data: Array<{ label: string; value: number }> }
  | { kind: "codeBlock"; lang: string; code: string; highlightLines?: number[][] }
  | { kind: "quote"; text: string; author?: string; sourceUrl?: string }
  | { kind: "diagram"; nodes: Array<{id: string; label: string; x: number; y: number}>; edges: Array<{from: string; to: string}> }
  | { kind: "formula"; latex: string; explainParts?: Array<{ part: string; note: string }> }
  | { kind: "scribeDraw"; lineArtAsset: AssetRef; drawDurationMs: number }
  | { kind: "manimScene"; sceneName: string; pythonSrc: string };

烘焙算法（确定性代码，LLM 不许参与）：

export function bakeScene(scene: Scene, words: Word[], audioDurationMs: number) {
  const resolveAnchor = (a: Shot["anchor"]): number => {
    if (a.type === "sceneStart") return a.offsetMs ?? 0;
    if (a.type === "word") return words[Math.min(a.wordIndex, words.length - 1)].startMs;
    const idx = findPhraseStart(words, a.matchText);
    if (idx < 0) throw new Error(`[bake] 场景 ${scene.id} 找不到锚点短语「${a.matchText}」`);
    return words[idx].startMs;
  };

  const starts = scene.shots.map((s) => resolveAnchor(s.anchor));
  // 单调性校验：anchor 必须严格递增，否则是分镜排序错了 —— 硬失败，不要静默排序
  for (let i = 1; i < starts.length; i++) {
    if (starts[i] <= starts[i - 1]) {
      throw new Error(`[bake] ${scene.shots[i].id} 的 anchor 未晚于前一镜`);
    }
  }
  return scene.shots.map((s, i) => ({
    id: s.id,
    startMs: starts[i],
    durationMs: (i + 1 < starts.length ? starts[i + 1] : audioDurationMs) - starts[i],
  }));
}

findPhraseStart 要做中文归一化（去标点、全半角、数字中文互换），匹配失败必须抛错，不能 fallback 到 0。

#11.4 建议的 skill 划分

两条边界要划死：

1. /vid-script 绝不产出绝对时间，只填 anchor。这条要写在 SKILL.md 醒目位置，否则模型一定会自己猜毫秒。
2. /vid-render 绝不修改 spec。渲染失败就报错回上一步改，不允许「自动降级换成纯色卡」——那会产出看起来成功但内容错误的片子。

#11.5 MVP 路线图

阶段一：周末闭环（目标：一条 60-90 秒可看的片子）

1. 建 monorepo 骨架：web(Next/Vercel) / render(Remotion) / packages/ir(共享类型)
2. IR 只实现 3 个模板：titleCard、bulletCard、kenBurns
3. 配音走 edge-tts（零成本），先不做词级时间戳——scene 内 shots 按字数比例分配时长
4. 手写第一份 baked spec，别急着让 LLM 生成（先验证渲染器，不是验证 LLM）
5. 本地 mac 渲染出 1080p30 mp4
6. 写 15 行 check.ts：比对视频与音频时长，差 > 0.12s 退出码非 0
7. 字体落地：得意黑 + Noto Sans SC + 霞鹜文楷，pyftsubset 子集化

验证：中文不豆腐、音画差 <0.12s、一条命令从 spec 到 mp4。 明确不做：控制台、队列、Supabase、tky 部署、词级时间戳、Manim、scribe 集成、LLM 生成 IR。

阶段一唯一目的：证明「JSON 进，mp4 出」这条管子是通的。 所有智能都是后面往管子里灌的东西。

阶段二：能稳定出片（2-4 周，每周 1-2 条 10 分钟）

1. MiniMax 官方充值，切 t2a_v2 + subtitle_type: "word"，anchor 走真实词时间戳
2. 上 tky：vs-api + vs-worker@{1,2}，形状照抄 scribe（注意：改 worker 代码必须重启 worker，只重启 api 没用）
3. 写全 6 个 skill，zod 校验 + anchor 单调性 + phrase 可匹配性做成硬闸门
4. 模板补到 8-10 个（formula 先用 KaTeX 渲，不上 Manim）
5. Vercel 控制台 + Remotion <Player> 审片 + 逐 shot 重渲按钮（把人工介入成本压到最低的关键）
6. Supabase 建表 + 合规标识注入 + 成片自动发邮件

验证：全流程人工介入 <40 分钟/条；逐 shot 重渲 <60 秒；10 分钟片在 tky 渲染 <25 分钟；连续 5 条不出现「渲染成功但内容错」。

阶段三：工业化（1-3 个月）

scribe 白板 shot 插件（注意要改 scribe 写死的 1280×720/25fps）→ Manim shot 插件 → 增量渲染缓存（shot 级内容寻址，改一句话不该重渲 10 分钟）→ Vercel Sandbox 灾备 → biliup 半自动投稿 + 数据回流反哺选题打分。

#11.6 关键风险

① tky 渲染会触发 kworker 风暴（重点）。 Remotion 渲染会为每帧写一个临时 JPEG（10 分钟 30fps = 18000 个小文件），正是 inode_switch_wbs writeback 风暴的高危工作负载。防范：

# /etc/fstab —— 渲染临时目录放 tmpfs，直接消掉绝大部分小文件 writeback 压力
tmpfs /var/tmp/remotion tmpfs rw,size=16G,mode=1777,noatime,nodev,nosuid 0 0

并且：concurrency 压到 4（8 核机器留 4 核给 ffmpeg/TTS）、worker 只起 2 个、绝不用「每帧一次 ssh」的调度（任务提交走 HTTP API）、成片入对象存储后删本地中间产物。

② ffmpeg 在 Vercel Functions 上跑不了（永久封死）。 Hobby 最大 300 秒、2GB 内存/1vCPU、bundle 250MB、请求体 4.5MB、无持久文件系统——任何一条都足以致命。唯一能跑 ffmpeg/Chrome 的是 Vercel Sandbox（预装 Chrome 和 FFmpeg，Hobby 45 分钟/4vCPU/8GB，每月免费 5 CPU-hours + 420 GB-hours，约够 3-4 条片灾备）。注意 Sandbox 只在 iad1 区，跨区拉素材慢，别当主路径。

③ Remotion Lambda 被否：需接 AWS（唯一新增云厂商）；Lambda 的价值是分布式并行切片渲染，而每天 1-3 条的产量并行度需求为零。

④ 渲染性能预期（未实测，需校准）：8 核、concurrency 4、纯 Remotion 1080p30 大约 8-20 fps，10 分钟片（18000 帧）约 15-40 分钟。大量 B-roll 视频解码时明显变慢。阶段一务必自己跑一条 60 秒片测出真实吞吐。

⑤ 其他：Vercel Framework Preset 不会跟着框架自动变（Vite→Next 会静默 404）；云雾两把 key 别混（文本 key ≠ 生图 key）；edge-tts 必须串行；Remotion 不支持 Alpine（Docker 化时 base image 别选 alpine）。

#11.7 这套方案的天花板（诚实评估）

能稳定做到：一条 8-15 分钟的「旁白 + 信息卡 + 图解 + B-roll」型讲解视频，视觉水准约等于「制作认真的 PPT 讲解 + 专业字幕 + 有节奏的镜头切换」。字幕、音画同步、视觉一致性、合规标识这些「手工做很烦但机器做很稳」的部分，机器会做得比人好。稳定期每天 1-3 条，人工介入 20-40 分钟/条，边际成本 ¥1-3/条。

必须人工介入：

1. 选题判断——LLM 能列 20 个选题，但排序质量取决于对受众的直觉。这是唯一真正影响成败的环节。
2. 事实核查——最危险的是「似是而非的技术解释」：听起来通顺、术语正确、但因果关系是错的。LLM 自查不出来。这是不可省的 10-15 分钟。
3. 类比的设计——「注意力就是查字典」这种好类比是整条视频的价值核心，也是 LLM 最容易给出平庸版本的地方。
4. 节奏与情绪——TTS 给的是「标准朗读」不是「讲解」。这是自动化视频和人类视频最明显的质感差距。
5. 标题与封面——点击率是玄学，判断权在人。
6. 争议性内容的表述分寸。

明确做不到：

• 3Blue1Brown 级别的信息设计——那是数学直觉的创作，不是渲染技术问题。上了 Manim 只是「有能力渲染出来」，想不出来还是想不出来。
• 有说服力的人声演绎——想要真正的听感只能自己配音（此时流水线依然有用：把配音塞进 IR 的 audio 字段，时间轴照样自动烘焙）。
• Manim 脚本的正确性——LLM 写的 Manim 场景「动画是不是在讲对的东西」必须人验，这个环节的人工成本可能比它省下的时间更多。

一句实话：这套系统的真实价值不是「AI 自动做视频」，而是把视频制作里 80% 的机械劳动（配音、对齐、排版、切镜、字幕、合规、导出）压缩到接近零，把全部时间花在选题、事实核查和类比设计这三件只有人能做的事上。

如果期待「输入一个主题、第二天自动涨粉」，会失望。如果期待「把做一条视频的时间从 8 小时压到 40 分钟」，能做到。

#11.8 立即可执行的三件事

1. 给 MiniMax 官方账号充值（最小额度）——整套方案唯一的硬阻塞。词级时间戳只有 MiniMax 原生 t2a_v2 给得了，云雾这条路已实测为死路。
2. 在云雾后台建一把新项目的 key（按「一项目一把 key」约定）。确认云雾只有 gpt-4o-mini-tts/tts-1 系可用于 TTS。
3. tky 上加 tmpfs 挂载点（/var/tmp/remotion，16GB）——在写第一行渲染代码之前就做掉，比事后排查 kworker 风暴便宜得多。

#12. 交叉核对：本轮抓到的错误与存疑项

#12.1 已核实的错误（已在正文修正）

#12.2 需要打问号的说法

#12.3 调研过程说明

• 8 个 agent 中 1 个（端到端工程手册）首次运行因 API 连接中断失败。重跑时 firecrawl 服务持续返回 502（重试 5 次以上），WebSearch 配额也已耗尽，最终改用 WebFetch 抓 DuckDuckGo HTML 结果页 + 逐页抓正文完成，部分知乎/百度文库页因反爬 403 已用同主题转载版替代。第 7 章的来源强度因此低于其他章节，凡推导内容已就地标注。
• 本轮 WebSearch 配额（200 次）在核对阶段用满，末段的两个存疑项（Seedance 版本号、Gemini Omni）无法当场验证，已如实标注而非略过。
• 各子 agent 明确写出「未找到可靠来源」的项目（如 Notion 官方 Shot List 字段、Riverside Magic Clips 额度、B 站「看点」官方操作步骤、部分创作者的工时数据）均未做推断填充。

#附录 A：可直接用的 ffmpeg 配方

# ── 响度归一化（讲解类 -16 LUFS）────────────────────────
# 单遍（够用）
ffmpeg -y -i raw.wav -af "loudnorm=I=-16:TP=-1.5:LRA=11,aresample=48000" \
       -ac 1 -c:a pcm_s16le out.wav

# 双遍（更准）：第一遍测量
ffmpeg -i input.wav -af loudnorm=I=-16:TP=-1.5:LRA=11:print_format=json -f null - 2>&1 | grep -A 10 Loudness
# 第二遍代入 measured_* 参数

# ── 权威时长（不要信 TTS 返回的 duration 字段）──────────
ffprobe -v error -show_entries format=duration -of csv=p=0 scene.wav

# ── whisper.cpp 兜底前的转码（必须 16kHz 单声道）─────────
ffmpeg -y -i scene.wav -ar 16000 -ac 1 -c:a pcm_s16le scene.16k.wav

# ── 烧 ASS 字幕（必须带 fontsdir，否则中文静默变豆腐块）──
ffmpeg -y -i video.mp4 \
  -vf "subtitles=sub.ass:fontsdir=/path/to/fonts" \
  -c:v libx264 -crf 18 -preset medium -pix_fmt yuv420p -c:a copy out.mp4

# ── 带转场拼接（1 秒交叉淡化，音频同步淡化）──────────────
ffmpeg -i a.mp4 -i b.mp4 \
  -filter_complex "[0:v][1:v]xfade=transition=fade:duration=1:offset=4[v];[0:a][1:a]acrossfade=d=1[a]" \
  -map "[v]" -map "[a]" out.mp4
# 可选转场：fade wipeleft/right/up/down slideleft/right/up/down
#           circlecrop rectcrop fadeblack fadewhite radial
#           smoothleft/right/up/down circleopen/close dissolve pixelize
#           diagtl diagtr diagbl diagbr

# ── 直接拼接（格式完全一致时最快）─────────────────────
# concat.txt 内容：file 'a.mp4' / file 'b.mp4'
ffmpeg -f concat -safe 0 -i concat.txt -c copy out.mp4

# ── 混 BGM（旁白 1.0，BGM 0.2）─────────────────────────
ffmpeg -i narration.wav -i bgm.mp3 \
  -filter_complex "[0]volume=1.0[a];[1]volume=0.2[b];[a][b]amix=inputs=2:duration=first[out]" \
  -map "[out]" mixed.wav

# ── 成片编码：YouTube/B站 1080p ──────────────────────
ffmpeg -i input.mov -c:v libx264 -preset slow -crf 18 \
  -c:a aac -b:a 128k -pix_fmt yuv420p out_1080p.mp4

# ── 4K ─────────────────────────────────────────────
ffmpeg -i input.mov -c:v libx264 -preset slow -crf 20 \
  -s 3840x2160 -r 30 -b:v 15M -c:a aac -b:a 192k out_4k.mp4
# 码率参考：1080p60 6-8Mbps / 1440p60 10-15 / 4K30 15-25 / 4K60 40-60

# ── AIGC 隐式标识注入（字段结构待按现行国标核实）─────────
ffmpeg -y -i final_raw.mp4 -c copy -movflags use_metadata_tags \
  -metadata "AIGC={\"Label\":\"1\",\"ContentProducer\":\"<你的标识>\",\"ProduceID\":\"<内容编号>\"}" \
  -metadata comment="本视频含 AI 生成内容（AI 语音合成旁白 / 部分 AI 生成插画）" \
  final.mp4

# 验证元数据写进去了
ffprobe -v error -show_entries format_tags -of json final.mp4

注：合规标识注入应放在最后的 mux 阶段统一做，不要放进渲染引擎——这样法规变了只改一处。

#附录 B：可商用中文字体白名单

#已核实为 SIL OFL 1.1（放心用）

保守推荐组合（全 OFL，零法律风险）：

标题     → 得意黑 Smiley Sans
正文/字幕 → Noto Sans SC
引文     → 霞鹜文楷 LXGW WenKai
代码/数字 → JetBrains Mono + Noto Sans SC fallback

#声称免费商用但许可原文未核实（用前必须自己下协议看）

MiSans（小米）、HarmonyOS Sans（华为）、阿里巴巴普惠体、OPPO Sans、字节跳动系字体——官方均宣称免费商用，但都不是 OFL，通常附带「不得单独再售、不得改名分发」等条件。要用就把授权协议 PDF 下载存档。

#绝对禁止

苹方 PingFang SC、微软雅黑、方正系、汉仪系等系统自带或商业字体——不能用于商业视频分发。macOS 上开发最容易犯的错就是 CSS 里写了 font-family: "PingFang SC"，本地看着好好的。

工程建议：把字体族名做成白名单枚举，在 schema 校验阶段就挡住 LLM 随手写 "PingFang SC"。

#附录 C：完整报告索引

本文档是 8 份子调研的交叉核对汇总。原始详版报告（含更多代码示例和来源链接）：

这 5 份原始报告已一并拷到 ~/Desktop/AI科普长视频-原始调研报告/（scratchpad 会话结束后会被清理，所以做了备份）。本文档是它们交叉核对后的结论层，原始报告里的个别数据已在本文档第 12 章被驳回或修正，两者冲突时以本文档为准。

调研完成：2026-07-30

来源：沉淀/02-AI与API/AI科普长视频制作全景调研.md（整理于 2026-08-18）