Show HN：利用逼真AI語音將電子書轉換為有聲書

一位開發者近日推出了名為ebookaloud的服務，該服務利用開源Kokoro模型將電子書轉換為有聲書，旨在為使用者提供一種經濟實惠且質量上乘的AI語音敘述體驗。開發者本人一直希望嘗試使用AI語音進行長篇敘述，但發現市面上的解決方案大多需要訂閱，而他的使用量有限，不值得為此付費。偶然發現Kokoro模型後，他驚喜地發現該模型生成的語音質量極高，能夠讓人長時間聆聽而不產生傳統機器人TTS語音所帶來的疲勞感。Kokoro模型僅有8200萬引數，設計上追求快速執行，但即使在開發者的12核筆記型電腦上使用CPU推理，速度仍然不盡人意。於是，他想到利用雲GPU服務來快速生成有聲書，從而構建自己的自託管庫，同時這一流程也可以轉化為供他人使用的產品。

在構建過程中，開發者的目標有兩個：一是深入瞭解AI多智慧體程式設計工作流，二是打造一個專門針對電子書轉有聲書的TTS產品。令人驚訝的是，ebookaloud服務99%的程式碼是由DeepSeek v4在OpenCode中透過多智慧體工作流編寫的。他在一個月內使用了約7.5億個token，成本僅為12美元，對最終結果非常滿意。每個功能或變更都經歷了規劃、實現、測試、審查、修正、提交的迴圈，其中使用了Pro和Flash代理的組合，通常只執行一到兩個併發工作器。此外，他還設定了一個獨立的評估代理，用於對提取和合成管道的各個部分進行質量控制，該評估代理可以同時執行8到10個例項。開發者甚至表示，在AI工作流自動化方面，他可能已經接近Yegge所描述的第六階段。

開發者後來還設定了Claude Code，將Opus 4.8與DeepSeek並行使用。他注意到兩者確實存在質量差異，但作為一名經驗豐富的開發者，他採取了親自動手的方式。他並沒有直接編寫任何程式碼，但仔細閱讀了生成的關鍵部分，並與DeepSeek Pro就每個步驟進行了廣泛討論。Opus對DeepSeek的選擇沒有太多批評意見，而且開發者並不相信前沿模型會為他的工作流帶來顯著改進。他認為，在大型程式碼庫上差異可能會更明顯，但他在Opus上實現的少數更改也遇到了與其他模型類似的問題：未經指導的隨機更改、過度簡化簡單解決方案、遇到障礙時採取意外或破壞性行動等。不過，他也看到Opus在處理複雜的規劃和組織方面有更強的能力，這有時是他需要的，但並非總是如此。

至於產品本身，市場上無疑有更復雜的解決方案。開發者並不打算與ElevenLabs競爭，而是專注於生成m4b格式的有聲書，旨在提供無縫的聆聽體驗，採用按需付費的定價模式，輸出質量達到足夠好的水平。這是開發者首次嘗試將產品商業化，AI程式碼生成使得一個精緻的產品變得觸手可及。如果沒有AI，他需要花費6到8個月的時間進行手動研發，很可能在完成之前就已經筋疲力盡。網站首頁提供了免費樣品，感興趣的可以體驗其語音和格式。開發者在輸出質量方面做出了一些有觀點的決定：他嘗試將大多數語音的語速設定為每分鐘140個單詞，以匹配行業標準，但有些語音在此速率下會失去韻律，因此他傾向於將速度控制等選項留給播放裝置，而不是給使用者提供一堆複雜的設定選項。如果網站獲得實際使用者，開發者計劃擴充套件支援Kokoro的其他語言，並增加從PDF中提取和合成內容的功能，這將使產品更加完善。