mcpField
P
podcast-production

podcast-production

github.com/calesthio创意与媒体221100 次安装15 周前更新
代码仓库

关于 podcast-production

面向可发布口语播客制作的供应商中立技能，也适用于使用合成音频的节目。内容涵盖节目形式、脚本、声音指导、组装、版权、交付要求、披露和质量检查。

主要功能

  1. 01节目形式与受众规划
  2. 02面向听觉的脚本写作
  3. 03配音选择与一致性
  4. 04单集结构与音频组装
  5. 05版权、披露与交付检查
  6. 06完整收听质量审核

适用场景

  1. 01设计播客节目形式
  2. 02准备合成旁白脚本
  3. 03制作声音一致的多角色单集
  4. 04发布前检查单集

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/calesthio/generative-media-skills --skill podcast-production

安装后在 Claude Code 中输入/podcast-production确认已加载。

附带文件EVAL.md

详细介绍

使用生成式工具制作播客

本技能介绍如何制作完整且可发布的播客节目，其中部分或全部音频由机器生成。它不绑定特定服务提供商：提及 TTS 引擎、音乐库和托管服务时，仅将其作为示例选项，而非制作方法。无论使用哪种工具生成音频，制作要领都相同——节目形式设计、为听觉体验而写作、声音指导、结构、版权、响度、交付、披露和质量保证。

节目满足以下条件时，才算完成：(1) 服务于明确的节目定位和受众；(2) 听感经过精心设计且前后一致；(3) 仅使用你有权分发的音频；(4) 符合目标平台的响度和文件规格；(5) 附带正确的 RSS 元数据和文字稿；(6) 包含法律或平台要求的 AI 披露；(7) 已通过完整收听质量检查。漏掉任何一项都是缺陷，而不是捷径。

1. 适用范围和启用条件

当任务涉及口语音频节目时，请使用本技能，例如主题解说节目、访谈系列、每日／每周新闻简报、叙事／纪录片节目、双主持人对谈节目、内部简报节目，或上述任何形式的节目纲要／形式设计。

以下情况不要使用本技能：

  • 音乐制作——交付成果为歌曲、背景音乐或短促音效（这属于音乐／音频生成范畴）。本技能会使用音乐，并将其视为版权和响度问题。
  • 单句 TTS——IVR 提示、通知，或没有节目背景的单段配音。
  • 画面为主的视频——如果交付成果是视频，音频只是其下方的音轨，则视频工作流负责节奏和交付。本技能适用于以音频为产品的情况。

如果请求含糊不清（“把这篇文章做成音频版”），请确认输出是一次性旁白，还是某个节目的单集。这两者需要不同的结构和元数据。

2. 形式设计（动笔前完成）

早期最重要的决定是节目形式，因为形式决定了脚本风格、声音数量、结构和时长。常见播客形式及其要求（制作经验法则，依据标准播客制作实践整理——见“来源”）：

形式典型时长声音数量脚本风格最适合
双主持人对谈20–60 分钟2 人（默契至关重要）提纲式，而非完整写稿与受众建立长期关系；观点／评论
访谈25–75 分钟主持人 + 嘉宾预先写好主持人的问题；回答现场发挥专业知识、嘉宾、常青内容库
单人／独白5–30 分钟1 人完整写稿或基本写稿教学、随笔、专题解说
叙事／纪录片20–45 分钟旁白 + 录音素材／角色完整写稿，按幕组织讲故事、高制作水准
新闻简报／每日节目3–10 分钟1–2 人严谨写稿，信息密集定期更新、时效性强、培养收听习惯

对于完全合成的节目（所有声音均由 TTS 生成），访谈和双主持人形式最难制作得令人信服，因为它们依赖自然的轮流发言和默契；单人、叙事旁白和新闻简报形式则最容易驾驭。为合成节目提供形式建议时，请将这一点纳入考量。

设计节目时，应先编写一份简短的节目纲要，再设计单集：

  • 节目构想和受众——用一句话说明节目面向谁，以及每集兑现什么承诺。
  • 更新频率和时长——确定形式支持的时长范围，以及切实可行的发布计划。
  • 声音形象——确定使用哪些声音、其名称／角色设定，以及固定的声音配置，确保第 N 集听起来与第 1 集一致（见 §4）。
  • 标志性元素——片头台词、片尾／行动号召、主题音乐，以及任何固定环节。这些构成节目的“声音品牌”，必须原样重复使用。
  • 披露立场——预先确定（见 §6），因为这会影响脚本和元数据。

3. 为听觉而写

音频脚本不是拿来朗读的文本文件。听众没有滚动条，无法重读，也容易跟不上复杂的从句。要把散文改写成口语（这些制作经验法则广泛用于播客脚本写作，参见 Sources）：

  • 句子要短，每句只表达一个观点。 拆开复合句。听众只能记住最后一个分句。
  • 使用缩略形式和口语表达。 用 “It's / you'll / here's”，而不是 “it is / you will / here is”。写得像一个称职的主持人平时说话那样。
  • 先说重点。 先讲结论，再提供依据。不要把重点藏在长长的从句后面。
  • 用口语提示转折。 “有三件事。第一…… / 不过关键问题在于…… / 那这意味着什么？”这些提示相当于音频中的标题。
  • 避免难以读出的内容。 拼写展开或换种说法来处理缩写、符号、URL 和数字。用 “twenty-sixteen L-U-F-S”，而不是 “-16 LUFS”。用 “dot com slash join”，而不是 “/join”。
  • 大声读出来。 任何会让真人读者磕绊的内容，也会让合成语音磕绊，还会让听众觉得乏味。对于合成节目，朗读测试尤为重要，因为后期无法即兴补救。

脚本写到什么程度取决于节目形式。 无论节目形式如何，高风险环节都要完整写成脚本：开场钩子／冷开场、环节转场、赞助商口播和结尾。对谈和访谈节目可以为中间部分列提纲，让交流保持自然。单人、叙事类和合成节目则要完整写成脚本——合成语音会逐字朗读你提供的内容，因此脚本 就是 表演本身。

如果脚本就是表演本身（完全合成），还要在脚本中加入表演指示：标出每段预期的停顿、重音和情绪语气，因为这些会成为 §4 中的 TTS 指令。

4. 多声线选角与 TTS 指示

这门技艺能让合成节目听起来栩栩如生，而不是明显像机器人。目标是让各个声线彼此有区别、在不同剧集中保持一致、发音正确，并且在对话中能自然地回应彼此。

4.1 选角与一致性
  • 为每个人设锁定声线配置。 保存准确的声线标识符以及所有生成参数（稳定性／一致性、相似度、风格／表现力、语速），作为该人设的“声线锁定配置”。每集都重复使用。声线漂移——同一个名义上的声线在不同剧集，甚至在同一长音频中听起来有所不同——是合成节目中最主要的连续性问题（从业者观察，且得到 TTS 供应商指南的印证，参见 Sources）。
  • 选取差异鲜明的声线。 双人节目应选择在音高、语速和音色上有所不同的声线，让听众不看姓名标签也能分辨说话者。两个相似的声线比一个声线更糟。
  • **按说话者／角色切分长脚本，**并使用各说话者锁定的配置生成台词，然后再进行拼接。对于每次调用仅支持一个主要声线的引擎，这样比在同一次请求中切换声线更能保持一致性。
  • 提高稳定性／一致性设置会同时减少漂移和表现力。 对于必须在 30 分钟内听起来完全一致的旁白，应优先考虑稳定性。对于需要丰富表现力的角色，可以接受更多变化，并反复生成不同版本，直到保持一致（经验法则）。
4.2 发音控制
  • 明确校正名称、专业术语和外来词。 不要指望模型猜对。使用引擎的发音机制：音素标注（通过 SSML <phoneme> 使用 IPA 或 CMU Arpabet）、自定义发音／词典，或不得已时在文本中用语音拼写（例如用 “KAI-roh” 表示 “Cairo”）。已记录的事实：主流引擎的 SSML <phoneme> 支持 IPA 和 CMU Arpabet；一些较新的富表现力模型支持词典或语音拼写，但不支持完整 SSML——请针对各引擎验证（已于 2026-07-10 根据 ElevenLabs、Google Cloud TTS 和 Azure Speech 文档验证）。
  • 在节目手册中建立节目专属发音词汇表（常见人名、节目标题、赞助商名称），并在每一集都应用，确保“主持人的名字”发音始终一致。
  • 数字、日期、单位和符号的读法并不一致。请在脚本中将其规范化（例如 “July tenth, twenty-twenty-six”），这也有助于人类理解。
4.3 情绪节奏与表现
  • 标点是主要的节奏控制工具。 句号表示完全停顿；逗号表示短暂换气；省略号表示悬而未决的停顿；问号会让句尾音调上扬。句子长度决定节奏——短句加快节奏，长句放慢节奏。语速约为 每分钟 140–160 个词时，听起来会自然且投入（制作经验法则——见来源）。
  • 在段落／章节层面运用情绪，而非逐字调整。 为一段内容设定基调；谨慎使用逐字强调。叠加太多情绪指示，或每句都切换情绪，会造成不自然的语调突变（实践经验法则，得到多份 TTS 最佳实践文档佐证——见来源）。
  • 有意识地使用引擎的表现力控制： SSML <prosody>（语速／音高／音量）、用于精确控制停顿的 <break time="…">、<emphasis>，或引擎的音频／情绪标签。如果引擎由提示词驱动而非 SSML 驱动，请将指示写入引擎可读取的演绎说明。创作前请确认所选引擎实际支持哪些标记——各引擎支持情况不一（已于 2026-07-10 验证）。
  • 生成多个版本并择优选用。 合成语音的表现具有随机性；第一次生成很少是最好的。请预留重新生成的时间。
4.4 生成式对话中的主持人默契

合成主持人之间的默契必须经过设计，因为他们的声音是独立生成的，实际上不会彼此回应。技巧（经验法则）：

  • 把回应写进脚本。 加入打断（“——等等，再说一遍”）、应和语（“嗯”“对”）以及对前文的呼应。如果脚本里没有，音频里也不会有。
  • 变换轮次长度。 真实对话长短不一——一段长篇阐述，接着一句两个词的回应。每轮都写得一样长，会显得刻意。
  • 控制剪辑拼接处。 轮流发言的真实感就在于间隙。调整说话人片段之间的拼接处，让回应听起来不像是在一周后于另一个房间录制的。两种声音下方保持一致的房间底噪，能营造共同在场的感觉。
  • 不要伪造实时远程通话。 如果加入假的“电话音效”滤镜来营造真实感，就有欺骗之嫌；请明确表明这是制作完成的节目。

5. 节目结构与剪辑

5.1 结构

常见的节目结构（制作经验法则；可根据形式调整）：

  1. 开场钩子（可选，10–30 秒）——在任何品牌宣传之前，呈现最有力的瞬间或钩子。 让听众愿意继续收听。适合叙事类节目和以社交媒体短片为驱动的节目。
  2. 开场 / 主题曲（5–20 秒）——配合主题音乐介绍节目名称、主持人和一句话承诺。保持简短，并让每期都完全一致（声音品牌塑造）。
  3. 本期预告——用一两句话说明本期内容。
  4. 正文 / 环节——将内容划分为衔接清晰的环节。每次切换环节时都用口播过渡，并可选配一段简短的音乐提示。
  5. 广告时段——参见 §5.3。以结构化方式标记，便于插入、移除或动态投放。
  6. 结尾（15–30 秒）——回顾内容，号召听众采取行动（订阅 / 分享 / 点击链接），告别，并以主题曲收尾。

叙事类节目会在正文中采用幕结构（铺垫 → 发展 / 转折 → 解决或留下开放问题），而不是将内容简单划分为几个平铺的环节。

5.2 组装与剪辑
  • 先平衡对话音量，再在其下方铺设音乐和音效。无论何时，语音清晰度都优先于音乐。
  • 对话期间压低背景音乐音量（使用侧链或手动自动化），使背景音乐大致比人声低 12–18 dB；在停顿处再提高音量（经验法则；请凭听感调整）。
  • 修剪合成瑕疵——TTS 中常见的瑕疵包括字词开头被截断、呼吸声不自然，以及音节被吞掉。剪掉有问题的句子或重新生成。
  • 保持片段之间的室内底噪 / 静音一致。拼接 TTS 片段时，完全的数字静音听起来不自然；稳定的低噪声底会让录音听起来更连贯。
  • 统一各环节的音量，避免开场、正文和广告的音量差异过大，再进行最终响度处理（§7）。
5.3 广告时段
  • 内嵌广告与动态广告。 内嵌广告会永久保留在文件中；动态插入的广告则由托管方在收到请求时拼接，可更新或移除。如果节目会长期投放广告，应在时间线上设置干净、静音的插入点，以便动态投放广告。
  • 广告同样需要披露。 合成语音广告，或由 AI 生成的代言内容，可能需要履行与节目相同的披露和同意义务（参见 §6），还需遵守有关代言的广告法规。未经授权，切勿合成真实人物的声音，使其看似在为某事代言。

6. 完全合成与混合制作，以及披露义务

6.1 制作方式的选择
  • 完全合成——所有声音均由 TTS 生成。成本最低，迭代最快；最适合单人、叙事旁白和新闻简报形式；但即兴表现和真实访谈互动最弱。
  • 混合制作——录制的人声与合成片段并用（例如由真人主持人搭配合成联合主持人、在录制的访谈音频周围加入合成旁白，或合成重现无法获取的音频）。兼具两者优势，但权利和披露要求也会大幅增加：每位录制的人类参与者都需要签署授权书，每个合成声音都需要有已获授权或同意的来源。

当节目需要真人的权威性、即兴表现或真实嘉宾时，选择混合制作；当规模、一致性或成本更重要，且节目形式能够接受时，则选择完全合成。

6.2 披露与同意义务

请将以下内容视为要求，而非风格选择。这是合成播客中风险最高的部分。

  • 克隆声音必须获得声音所有者的书面同意并留档。 未经许可克隆或仿制真人的声音，可能使你承担公开权和声音权方面的法律责任。截至 2026 年，美国多个州已将声音作为一项独立的肖像权加以保护——田纳西州的 ELVIS Act（2024 年生效）是首部明确提及 AI 声音仿制品的法律，加利福尼亚州、伊利诺伊州、纽约州等也制定了相关法规；联邦 TAKE IT DOWN Act（2025 年 5 月签署）针对未经同意的合成影像（已记录事实，核实日期为 2026-07-10——参见 Sources；不构成法律建议，请确认你所在司法辖区及具体用途适用的现行法律）。同意必须明确针对特定用途、以书面形式作出并留档；口头说“可以”不符合要求。 未取得签署的授权书且授权范围未涵盖相关用途时，切勿克隆公众人物、嘉宾或联合主持人的声音。
  • 平台关于 AI 披露的政策适用于合成声音（已记录事实，核实日期为 2026-07-10）：
    • YouTube 要求创作者在上传时披露逼真的修改或合成内容，明确包括合成／克隆声音，以及可能误导观众、使其以为真人说过相关内容的 AI 配音。平台可能会显示“内容制作方式”标签。根据 2025 年的变现政策更新，大规模制作、缺乏创意的 AI 内容有被取消变现资格的风险。
    • Spotify 本身不会降低 AI 辅助内容的排名，但禁止未经授权的声音克隆，并会严厉下架垃圾或低质量的批量制作音频；该平台正在采用基于 DDEX 的 AI 披露标准，并在应用内展示。其“Verified”计划不接受主要代表 AI 人设的个人资料。
    • Apple Podcasts 目前未在基础 RSS 规范中要求为合成声音添加通用的“这是 AI”标签，但其内容政策仍禁止冒充他人，并要求对所有音频拥有相应权利。（发布时请核实现行政策——平台政策变化频繁。）
  • 如有疑问，就进行披露。 简短、诚实地说明（例如在节目说明中注明“本期节目中的声音由 AI 生成”，和／或在节目中口头说明）成本很低，却能有效降低风险，而且这已日益成为预期做法。监管趋势（例如 2025–2026 年开始出现的透明度法律）正朝着要求更多披露的方向发展，而非更少。
  • 混合节目：如果听众可能误以为真人说过某些内容，请标明哪些部分为合成内容——例如，合成重构的引语必须标注为重现内容，绝不能冒充真实录音。

7. 响度与交付标准

这是一个讲究硬性数值的领域。处理不当，平台可能会调高或调低你节目的音量，甚至拒绝接收。

7.1 目标

已核实的事实（截至 2026-07-10）：

  • Apple Podcasts 建议进行预处理，使整体响度约为 -16 dB LKFS（= LUFS），容差为 ±1 dB，且真峰值 ≤ -1 dB FS，并按照 ITU-R BS.1770 进行测量。（LKFS 和 LUFS 是相同的单位。）
  • **常见的创作者目标是：立体声文件为 -16 LUFS，单声道文件为 -19 LUFS。**单声道的数值刻意设置得更低：单声道文件通过立体声播放器播放时，听感音量大约低 3 LU，因此将单声道文件母带处理到约 -19 LUFS，听起来就会与 -16 LUFS 的立体声文件相当。（这是协调这两个数值的制作经验法则；AES TD1008 中记录了约 2–3 LU 的听感差异，参见“来源”。）
  • Spotify 会在播放时将播客标准化至 -14 LUFS，并将上限设为 -1 dBTP；YouTube 也会将响度标准化至约 -14 LUFS。这些平台在播放时应用增益，而不会重新编码你的文件。
  • AES TD1008（2021 年，取代 TD1004）——流媒体响度建议——为分发设定了**-18 LUFS 的语音／“混合”内容目标**，并建议将综合响度保持在 -20 LUFS 以上；该标准指出，在测得响度相同的情况下，语音的听感响度比音乐高约 2–3 LU。请注意，这是针对分发平台进行标准化的指导，而非针对创作者的母带文件。

实用方案（经验法则）：将一个立体声文件制作成综合响度 -16 LUFS、真峰值 ≤ -1.0 dBTP，作为通用默认值；它符合 Apple 的范围，也只会被 Spotify／YouTube 轻微调整。如果交付单声道文件，则以 -19 LUFS 为目标，以获得相当的听感响度。切勿为了追求 Spotify 的 -14 而压缩动态范围——平台会调高安静内容的音量；响度过高、过度限制的内容无法被干净地调低，听起来还会令人疲劳。保留对话的动态范围；口语节目不必像母带处理过的歌曲那样响。

7.2 文件和编码规格

已核实的事实——Apple Podcasts（截至 2026-07-10）：

  • **通过 RSS 提供的单集音频：**MP3 或 AAC。单声道 64–128 kbps，立体声 128–256 kbps，采样率为 44.1/48 kHz。
  • 口语内容通常使用单声道就足够——文件更小，而且大多数人通过单个扬声器或耳塞收听。只有在节目需要有意义的音乐／音效空间效果时，才使用立体声。
  • 响度应在编码之前设定：有损压缩不会改变测得的响度，因此应先进行预处理，再编码。
  • （Apple 的高分辨率 WAV／FLAC 规格适用于上传到 Podcasts Connect 的订阅者音频，不适用于公开 RSS 附件。）

每集通过 RSS 条目中的 <enclosure> 提供一个文件（URL、字节长度和 MIME 类型，三项均为必需）。

8. 元数据、章节、文字稿和 RSS

播客本身就是一个 RSS 源；音频只是其中的附件。正确设置 RSS 源与制作音频同样重要（规范中已记录并核实的事实，核实日期为 2026-07-10——参见来源）。

  • **RSS 源级必需元素：**标题、描述、语言、至少一个 <itunes:category>、<itunes:explicit>、封面图（Apple 通常要求封面图为 1400×1400 到 3000×3000 px、RGB JPEG/PNG），以及所有者/联系人。缺少 <itunes:explicit> 或 <itunes:category> 会导致 Apple 拒绝该 RSS 源。
  • 单集级必需元素：标题、一个 <enclosure>（URL、字节长度、MIME 类型）、一个全局唯一且永不更改的 <guid>，以及发布日期。更改 GUID 会导致订阅者看到重复的单集。
  • 章节——有两种机制：(a) 嵌入文件中（MP3 中的 ID3v2 CHAP 帧，M4A 中的 MP4 chpl 原子），或 (b) 通过 RSS 源中的 Podcasting 2.0 <podcast:chapters> 标签链接到外部 JSON 章节文件。章节可以改善导航体验，并会显示在多个客户端中。
  • 文字稿——Podcasting 2.0 的 <podcast:transcript> 元素可从 RSS 单集条目链接到文字稿文件。WebVTT（.vtt）是首选格式，因为它支持说话人标签（通过 cue 标识符）、时间信息和简单样式，且客户端支持最广；SRT 也可使用，但功能更简单。主要客户端（Apple，以及截至 2025 年底的 Spotify）会显示 RSS 源链接的文字稿。对于合成节目，你实际上已经有了文字稿——它就是你的脚本——因此提供文字稿几乎不费力，也就没有理由不提供。
  • **命名空间：**在 RSS 源中声明 itunes 和 podcast（Podcasting 2.0）命名空间，才能使用这些标签；发布前请验证 RSS 源。

9. 无障碍

  • **为每一集提供文字稿。**这是播客无障碍体验的核心功能——它服务于聋人和听力障碍听众，改善内容发现/SEO，而且对于合成节目（即你的脚本）来说成本极低。通过 <podcast:transcript> 链接文字稿（§8）。
  • 带说话人标签的文字稿（WebVTT cue 标识符）对于多声部节目很重要，能让读者了解是谁说了什么。
  • 清晰的节目说明，包含摘要、关键时间戳/章节，以及脱离上下文也有意义的链接文本。
  • 避免仅音频信息无法通过文字稿传达——如果笑声、语气或声音对理解内容至关重要，请在文字稿中注明（“[笑]”“[电话铃响]”）。

10. 权利与安全检查清单

每个音频元素都必须属于以下情况之一：原创、已获本次使用授权，或属于公共领域／已妥善遵循知识共享许可并注明出处。

  • 音乐。 你需要同时拥有作品和*具体录音（母带）*的权利。购买歌曲或个人流媒体订阅，并不意味着获得播客／同步使用权。请使用明确涵盖播客的免版税／制作音乐库许可、直接向权利持有人获取同步许可，或使用确实明确可合法使用的音乐。“免版税”意味着只需支付一次费用，并非免费，也不代表没有许可条款——请仔细阅读许可范围（涵盖的节目、广告支持的使用方式、期限）（有记录的事实——请参阅 Sources）。
  • 音效——同样的原则；请使用许可涵盖商业播客发行的音效库。
  • 人声——每位录制的人类声音都需要取得授权书；每种克隆／合成人声都必须使用已获许可或已取得同意的来源，并遵守 TTS 提供商的商业使用条款（有些声音／套餐仅限非商业用途）。请再次确认提供商授予你商业发行生成音频的权利。
  • 第三方音频／片段——引用录音、歌曲或其他节目需要获得许可，或有有效的合理使用／公平处理依据；不要认为短片段就一定可以使用。
  • 合成人声和克隆人声的披露／同意——请参阅 §6。这会带来法律风险，而不仅仅是内容下架。

11. 发布前 QA（切勿跳过）

每次发布前都要执行此流程。合成节目尤其需要由人工（或仔细的 Agent）完整收听，因为生成错误只有在听到时才会显现。

  1. 完整收听从头到尾，以正常收听音量通过耳塞收听。检查发音错误、声音漂移、词语被截断、机械感明显的衔接、节奏不自然以及音量跳变。
  2. 发音检查对照节目词汇表——检查每个名称、节目标题和赞助商名称。
  3. 结构检查——片头／片尾存在且与前几期完全一致；各部分衔接顺畅；广告位正确；开场引子效果到位。
  4. 响度／峰值验证使用响度计——综合 LUFS 达到目标值（约 -16 LUFS 立体声／约 -19 LUFS 单声道），真峰值 ≤ -1 dBTP，无削波（§7）。
  5. 编码／格式——编解码器、比特率、声道和采样率均正确；文件可在手机上播放。
  6. 元数据——标题、唯一且不变的 GUID、描述、章节、正确的字节数 enclosure 长度、封面图、类别、显式内容标记（§8）。
  7. 文字稿已附上，内容准确并标注说话者（§9）。
  8. 权利——每个音乐／音效／人声元素均已获得许可（§10）。
  9. 披露——在法律或平台要求时，已注明 AI／合成内容；任何克隆人声均已取得并存档同意（§6）。
  10. Feed 验证——使用验证器检查 Feed；确认其可解析后再上线。

12. 示例

以下均为说明性示例，而非强制模板。它们展示了如何将上述决策应用于实际需求。请根据具体情况调整。

示例 A — 完全合成的每日 5 分钟新闻简报

意图： 每周工作日播出的「约 3 分钟」简报，总结一个行业的新闻，由单一合成主播播报，发布到 Apple/Spotify/YouTube。

格式与设定手册： 新闻简报格式（对合成内容较宽容）。主播人设为「Ava」，中音、语气平稳，稳定性设为高并锁定（新闻每天听起来都必须一致）。建立常见公司和人名的词汇表，并为其添加音素条目。固定 8 秒音乐片头，6 秒片尾，并包含「订阅」号召。披露立场：在节目简介中声明「这是一档 AI 生成的简报」，并在片尾口播一次。

脚本（按听感撰写），节选：

[COLD OPEN — no music]
Three things moved the market today, and the third one nobody saw coming.

[THEME 8s, duck under]
This is The Daily Brief for Tuesday, July eighth. I'm Ava. Here's what matters.

[BODY]
First. [company], read "ACK-mee", reported earnings after the bell...
(short sentences. One idea each. A pause... before the turn.)

[OUTRO, theme up]
That's your brief. Follow the show so tomorrow's finds you automatically.
This is an AI-generated briefing from [publisher]. See you tomorrow.

TTS 指导： 使用 Ava 的锁定设置生成完整正文。按段落设置情绪：正文采用中性、权威的语气，片尾号召部分稍作提振。脚本中的数字和日期均拼写出来。每天生成两个版本；选用更清晰的版本。响度： 将母带制作为单声道，-19 LUFS，TP ≤ -1 dBTP；编码为 MP3 单声道 96 kbps 44.1 kHz。交付： 每天使用唯一 GUID；根据脚本生成 <podcast:transcript> VTT；鉴于时长较短，无需章节。披露： 在简介中披露，并在片尾口播（满足 YouTube 对合成语音的披露要求及一般透明度要求）。

可能的失败模式： 未重复使用语音锁定设置，导致声音漂移；「ACK-mee」在没有音素条目的情况下又变回按拼写发音；为了追求 Spotify 的 -14 而过度限幅，导致声音刺耳。

示例 B — 双主持人对谈式科技节目，采用混合制作

意图： 每周播出 35 分钟的节目。一位真人主持人（录制）加一位合成联合主持人人设。这是比较棘手的情况：默契和披露都很重要。

决策： 采用混合制作，因为真人能带来即兴感和权威性，合成联合主持人则能以较低成本稳定地担任「讲解者」角色。同意／权利： 合成联合主持人使用的声音已由制作方获得商业使用许可（有书面记录，并已确认供应商条款）；如果声音是基于任何真人建模的，则必须取得签署的授权书——但这里并非如此，该人设完全是合成的。披露： 在第 1 集中如实介绍合成联合主持人是一位 AI 联合主持人，并在每期节目简介中说明；由于节目包含合成语音，上传到 YouTube 时需开启「此内容的制作方式」披露选项。

默契设计： 真人部分围绕脚本框架进行现场录制。合成联合主持人的台词经过专门撰写，用于对话式回应——包括打断、附和（「对，对」）以及呼应真人刚刚说过的内容——然后使用联合主持人的锁定语音生成，并剪辑到对话间隙中，配以匹配的房间底噪，让交流听起来像是两人同时在场。双方每次发言的时长刻意保持不均等。

组装与响度： 调整两种声音的音量，使其匹配；将背景音压低到比人声低 12–15 dB；将母带制作成立体声，-16 LUFS，TP ≤ -1 dBTP；编码为 AAC 立体声 128 kbps。交付： 为各环节结构添加章节（通过 <podcast:chapters> 使用 JSON）；提供带说话人标签的 WebVTT 文字稿，以区分真人主持人和 AI 联合主持人；为动态广告预留干净的静音广告插入点。

可能的失败模式： 合成回应听起来像是在「别处」录制的（调整房间底噪并收紧剪辑衔接）；每轮发言时长相同，听起来像假的；忘记开启平台的 AI 披露选项；合成联合主持人照读赞助商代言内容时，未按广告口播的要求额外谨慎处理。

示例 C — 使用重构音频的叙事纪录片单集

**意图：**一则 30 分钟的故事，其中一段无法获取的历史引文由合成语音读出。

关键规则：合成重构的声音或引文必须披露为重现内容，绝不能当作真实的档案录音呈现。应在旁白中标明（“接下来播放的是对信中内容的 AI 重现，并非录音”），并在文字稿中注明。克隆特定真实人物的声音还需要获得其遗产管理方的授权／同意；使用中性的“朗读者”声音则可避免这一问题，除非已取得授权，否则是更稳妥的选择。其他所有内容均遵循叙事行为结构（§5.1）、完整脚本编写（§3），以及标准的权利审核、响度（立体声 -16 LUFS）、文字稿和 QA 流程。

来源

易变信息（平台规格、政策、法律）已于 2026-07-10 核实。标准和制作经验法则已在文中标注。法律说明不构成法律建议；发布时请确认现行法律和政策。

标准与响度

RSS / 元数据 / 文字稿 / 章节

平台 AI 内容政策

声音权利与披露法律（非法律建议）

TTS 指导（最佳实践文档，供应商中立的合成建议）

音乐 / 音效版权（行业参考资料）

格式、结构与脚本写作（行业参考资料）

评论

支持 Markdown