Scripts to Audiobook：一段 AI 编码之旅 🎧

我是个电影迷，也是有声书的重度消费者。有段时间我一直在想：能不能从 AI 生成的脚本自动生成个性化的有声书？

这个个人想法催生了我的最新项目：Scripts to Audiobook — 一个将脚本转换为多声音有声书的工具，支持可配置的 TTS 供应商。

我在 3 月 15 日开始构建，3 月 20 日凌晨发布。在这约 5 天里（包括一个周末），我先后使用了三个 AI 编码助手。以下是发生的事情。

起点：Perplexity Computer Use

我从 Perplexity 的 Computer Use 功能开始，被它”高完成率”的承诺和令人印象深刻的实时预览能力所吸引。作为 Pro 订阅者（4,500 积分），我认真尝试了它 — 积分从 3,400+ 掉到 2,200+ 后暂停。

我的体验褒贬不一：

有效的部分：

• 实时预览 — 即时看到变化非常有价值
• 交互式开发 — 对话流程感觉自然高效
• 快速原型 — 非常适合测试想法和快速迭代

无效的部分：

• 积分消耗快 — 1,200+ 积分换取部分完成度，成本很高
• 完成度差距 — AI 倾向于激进地”品牌化”（以自己命名），需要手动清理
• 生产就绪度 — 虽然演示令人印象深刻，但输出需要大量打磨才能实际使用

我停止不是因为无法完成工作，而是鉴于当前状态，完成全部的积分成本不值得。它是探索和演示的绝佳工具，但我会把它留给小项目或验证阶段。

第二阶段：Kimi Code 和 Token 燃烧

我切换到 Kimi Code，希望其专注的方法会更有效。确实有效 — 我快速用光了两个周配额。

发生的事情是：我的配额耗尽，它重置，我又快速用完。部分是因为我在周末高强度工作，但主要是因为：

1. 范围蔓延 — 构建中途需求发生变化（新的 TTS 供应商、音频格式选项、章节支持）
2. 重构循环 — 修复 bug 导致更多 bug，反复重写
3. 上下文丢失 — 开始新会话意味着每次都要重新解释项目

工具本身是能干的，但工作流程低效。我在用时间换 token。

第三阶段：Claude Code 和终点线

最后，我切换到 Claude Code（Anthropic 的终端编码代理）。三件事让它奏效了：

1. 丰富的项目上下文 — 它可以阅读整个代码库并理解架构
2. 迭代优化 — 小而针对性更改，而不是全面重写
3. 稳定性 — 昨天能用的今天继续能用

在一次专注的会话中，我：

• 实现了剩余功能（章节支持、TTS 切换）
• 修复了所有未解决的 bug
• 打磨了 UI 和文档
• 编写了全面的测试

区别在哪？ 感觉像和一位理解大局的高级工程师一起工作。

输出：我构建了什么

经过这一切，这是我构建的：

Scripts to Audiobook 使用你选择的 TTS 供应商将结构化脚本转换为多声音有声书。

核心功能

• 🎭 多种声音 — 为每个角色分配不同的声音
• 📖 章节支持 — 将长内容组织成部分
• 🔧 TTS 灵活性 — 在供应商之间切换（Edge TTS、OpenAI、ElevenLabs 等）
• 🎛️ 可配置输出 — 控制音频格式、比特率和速度

独特之处

• 免费使用 — Edge TTS 不需要 API 密钥；其他供应商提供免费层
• AI 无关 — 适用于来自任何 AI 的脚本（Claude、GPT、Gemini 等）
• 新手友好 UI — 简单的配置界面，无需编码

技术栈

• TypeScript — 类型安全和更好的 DX
• Node.js — 跨平台运行时
• Edge TTS / OpenAI / ElevenLabs — TTS 供应商
• FFmpeg — 音频处理和格式转换

关键经验

1. 工具选择很重要 — 不同的 AI 编码助手有不同的优势。匹配工具到阶段。
2. Token 效率 — 丰富的上下文和迭代优化胜过蛮力重写。
3. 快速发布，迭代 — 第一版本不需要完美。它只需要能工作。

AI 增强编码之美

整个项目 — 从想法到发布产品 — 花了不到 5 天。而我不是专业开发者。

美不在于第一次就完美 — 而在于能够快速迭代、从错误中学习、继续前进。

AI 编码助手不是人类判断的替代品。它们是力量倍增器。它们帮助你移动得更快、思考更大、发布更聪明。

后续计划

我已经考虑 v2：

• 更容易配置的 Web UI
• 更多 TTS 供应商（Azure、Google、Amazon）
• 声音克隆支持
• 多脚本批处理

但首先，我要休息一下。发布的感觉很好。😊

在 GitHub 上查看： scripts-to-audiobook

Made with 💙 by Nicky & AI