最近在开发一个与 TTS（Text-to-Speech）相关的功能，其中需要对播放的人声音频进行加速或减速处理。这个领域我之前完全没有接触过，DeepSeek 推荐我使用 Howler.js 和 Tone.js 这样的库来播放音频。
在实现加速功能时，我发现需要修改 playbackRate，但通常 playbackRate 和音调（Pitch）的修改是联动的。然而，Howler.js 并没有提供直接修改 Pitch 的方法。在折腾了很久之后，DeepSeek 也没能解决 Tone.js 带来的噪音问题。使用在线处理（Pitch Shift 效果器）时，会产生“dadadada”的噪音；而使用离线处理（GrainPlayer）时，又会出现类似回声的杂音。
最终，我查到 HTML5 的 Audio Element 提供了 preservePitch 的功能，这似乎是一个比较理想的解决方案。
一些经验总结
- 代码生成与抽象
即使通过 LLM 生成代码的成本较低，也尽量让它生成易于拓展和复用的代码。在我的尝试中，即便切换了多个不同的音频库，我都不需要修改业务代码，这正是因为我在最初就让 LLM 对音频处理部分进行了足够的抽象。 - LLM 在处理开放性问题时的局限性
如果待解决的开放性问题足够普遍，LLM 通常能给出令人满意的答案。但对于像 Web Audio 这样 API 复杂且不太常见的技术领域，LLM 可能就很难解决问题了。例如，在解决 Pitch Shift 效果器的噪音问题时，DeepSeek 很难坚定地指出 Tone.js 的实现本身就存在缺陷（事实上也是如此）。这大概率是因为 LLM 只是一个互联网文本预测器，容易产生“幻觉”，尤其是在处理小众领域的问题时。
总结
在开发过程中，抽象和代码复用是非常重要的，尤其是在处理新技术领域时。虽然 LLM 在很多常见问题上表现出色，但在处理复杂或小众领域的问题时，仍需要结合人工经验和深入的技术调研来找到更优的解决方案。
发表回复