先明确目标：你是在给谁做音频
后期不是一套固定参数，而是围绕发布场景做的取舍。要先知道音频最终会去哪：视频、播客、网页播放器，还是可下载的教学素材。不同场景对响度、格式和峰值控制的要求都不一样。
如果你没有先定义目标，后面很容易出现两种极端：要么什么都不做，声音很毛糙；要么修得太狠，声音变得干、闷、平，反而失去自然感。
1) 采样率与位深
- 视频项目优先 48 kHz；音频类内容可用 44.1 kHz。
- 编辑阶段使用 24‑bit WAV 保留余量，交付时再转压缩格式。
原则很简单：编辑时尽量保留余量，交付时再压缩。WAV 适合保留母带，MP3 或 AAC 适合发布。不要一开始就压得太狠，否则后期几乎没有可操作空间。
2) 响度归一（LUFS）
建议目标：立体声 −16 LUFS（单声道 −19 LUFS）。在链路末端使用透明限幅器，峰值控制在 −1 dBTP，压缩量 1–2 dB 即可。
如果你要把语音和背景音乐混在一起，先把人声单独整好，再处理 BGM。很多人一上来就把音乐和语音一起压，结果是人声被音乐盖住，或者整体变得很刺耳。
对网页播放器来说，稳定的响度比绝对的“响”更重要。用户切换页面或浏览器时，不应该因为某一段音频突然过大而被吓到。
3) 均衡与去齿音
- 高架均衡：6–8 kHz 以上 +1–2 dB，让声音更通透。
- 去齿音：5–8 kHz 范围，轻比率，仅在明显“s”音处工作。
- 高通：60–80 Hz，去除低频杂讯，避免与 BGM 冲突。
均衡和去齿音的目标不是“把声音改得像另一个人”，而是让语音更容易听清。高架均衡只需要一点点就够，去齿音也只处理明显问题，不要把所有齿音都抹平。过度处理会让咬字变得钝。
如果你的脚本里有很多英文词、数字和缩写，去齿音尤其要保守一点，因为这些部分本来就需要清晰的高频细节来帮助理解。
4) 交付设置
- 网页：MP3 192–256 kbps CBR 或 AAC 160–192 kbps。
- 归档/编辑：WAV 24‑bit；保留母带，便于后续更新。
- 播客：遵循平台规范；确保真峰值低于 −1 dBTP。
交付格式取决于用途。网页播放更在意体积和兼容性，播客更在意平台要求，归档更在意可编辑性。不要把三者混成一个标准，否则会在某一端吃亏。
5) 参考链路
高通(70 Hz) → 轻度 EQ → 去齿音 → 限幅器(−1 dBTP, GR 1–2 dB) → LUFS 计量这是一个很实用的基础链路。它不追求花哨，但足够稳定。先把低频噪声清掉，再稍作 EQ，再处理齿音，最后做限幅和响度检查，通常就能得到可用结果。
6) 一个适合浏览器内容的工作流
- 先导出纯语音 WAV。
- 听一遍，记录“刺耳”“太闷”“太小声”等问题。
- 只改一个处理节点，再听一遍。
- 达到目标后再转交付格式。
- 把最终参数写回模板，方便下次复用。
如果你每次都从头调参数，工作会非常慢。最好的方式是把“当前项目最有效的一套参数”保存下来，让下一次直接继承。
7) 检查清单
- 无削波；峰值 ≤ −1 dBTP。
- 综合响度接近目标值（−16 LUFS 立体声）。
- 去齿音不过度；咬字清晰。
- 导出设置与发布平台一致。
检查时不要只看一个指标。比如 LUFS 达标并不代表好听，峰值安全也不代表自然。真正合格的后期，是把“听感”“响度”和“格式”三件事同时管住。
8) 不同平台的建议
| 平台 | 建议 |
|---|---|
| 视频 | 48 kHz，便于与时间线对齐。 |
| 播客 | 重视一致响度和清晰度，保留 WAV 母带。 |
| 网页播放 | MP3/AAC 体积适中，加载速度更重要。 |
9) 常见问题
- 如果声音偏闷，先检查是不是去齿音过度了。
- 如果尾音不稳，看看限幅器是不是压得太重。
- 如果网页播放忽大忽小，确认整条音轨的响度是否一致。
- 如果多段拼接后听感跳变，回到每一段的前处理设置上排查。
10) 示例链路的两种常用版本
不同项目可以用不同程度的处理。一个比较轻的版本适合自然朗读，一个略强一点的版本适合配乐旁白：
版本 A（自然朗读）
高通 → 轻度 EQ → 限幅器 → LUFS 计量
版本 B（配乐旁白）
高通 → EQ → 去齿音 → 轻压缩 → 限幅器 → LUFS 计量如果你刚开始做后期，建议先用版本 A。它最容易把问题控制在最少，也最容易听出到底是脚本的问题还是后期的问题。
11) 为什么这类文章不是“凑字数”
音频后期看似只是参数，但实际上它直接决定了内容是否能发布。对于使用浏览器端 TTS 的人来说，后期不是可有可无的装饰，而是把原始语音变成可交付内容的最后一步。只要这一步讲清楚，读者就能把内容真正用起来。
12) 一个可复制的排错顺序
- 先听整体，判断是太闷、太刺还是太小声。
- 如果太闷，先查 EQ 和去齿音。
- 如果太刺，先查 5–8 kHz 是否压得太少或太多。
- 如果太小声，先查 LUFS，再看峰值限制。
- 如果拼接后不连贯，再回到分段和导出设置。
这个顺序能避免你在错误的节点上反复浪费时间。很多人一开始就去调最复杂的插件，最后却发现问题只是一句脚本或者一个太短的停顿。
13) 何时该停止修音
后期不是把声音磨得越精致越好，而是把它做到“可听、可交付、可复用”。当声音已经清晰、音量稳定、峰值安全时，就该停下来。过度修音常常会让人声失去生命力，尤其是在教育、播客和产品说明这类内容里。
如果你想再往上优化，建议回到脚本而不是继续堆插件。很多情况下，改一句话比再加一个处理器更有效。你也可以先回到 主工作流页面，从脚本与导出链路重新看一遍。
14) 一个比较实用的记录方式
每次完成一轮后期，最好记录三样东西：处理顺序、最终响度、以及你为什么选择这组参数。这个记录不需要很长，几句话就够。比如“先高通再 EQ，再轻微去齿音；导出后目标 −16 LUFS；这个项目偏教程，所以保留更多自然感”。
有了这种记录，下一个项目就不需要从头试错。你甚至可以把这些记录贴回你的模板目录里，让下一次处理直接继承。对经常做内容的人来说，保存方法本身就是效率。
15) 最终交付前的最后一轮试听
- 听一遍全文，看有没有某段突然变小或变大。
- 听结尾有没有因为限幅太重而变得发闷。
- 听专有名词和英文缩写是否仍然清晰。
- 听和 BGM 混合后的整体是否还保有人声前景。
这一步做完，基本就可以发布了。对于浏览器端 TTS 来说，好的后期不是把声音推到极致，而是让它在目标平台上稳定、清楚、好听。
16) 三种常见发布场景的参数侧重点
| 场景 | 最该注意的点 |
|---|---|
| 教程视频 | 清晰度优先，别把尾音磨太平。 |
| 播客 | 响度稳定，段落间不要忽大忽小。 |
| 网页播放器 | 兼容与体积优先，导出格式别过重。 |
17) 什么时候需要返工
如果你在最终试听时仍然觉得某段“出戏”，那么返工并不一定意味着后期失败，反而可能说明你已经很接近一个好的结果。返工时优先回看的是脚本、停顿和分段，而不是一上来就换插件或换参数。很多小问题，只要把原句拆短、把数字写口语化，就能解决。
对于想把这套流程系统化的人，建议把当前最有效的一套参数和问题记录，顺手写回到自己的制作模板里，再回到 主工作流文档 对照一下脚本与导出的关系。
18) 最后的一点实践建议
如果你的内容类型比较固定，比如总是做教程或播客，那么后期参数也会越来越稳定。这个时候最聪明的做法不是每次重新思考，而是把一套成熟的参数固定下来，让它成为你默认的起点。只有当平台、配乐、或者语音风格变化很大时，再去微调。
这样做的效果是，后期不再是“创作现场”，而会变成一个可靠的收尾工序。对博客内容来说，这种稳定性非常重要，因为它直接影响用户是否愿意继续听下去。
作者：Kokoro Web 团队 • 最后更新 2025‑01‑15