惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

腾讯CDC
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园 - Franky
博客园_首页
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
IT之家
IT之家
The Cloudflare Blog
V
Visual Studio Blog
罗磊的独立博客
T
Tailwind CSS Blog
S
SegmentFault 最新的问题
Hugging Face - Blog
Hugging Face - Blog
V
V2EX
阮一峰的网络日志
阮一峰的网络日志
D
Docker
Last Week in AI
Last Week in AI
B
Blog RSS Feed
C
Check Point Blog
J
Java Code Geeks
The GitHub Blog
The GitHub Blog
有赞技术团队
有赞技术团队
博客园 - 聂微东
MongoDB | Blog
MongoDB | Blog
雷峰网
雷峰网

V2EX

我用 AI 写代码,但终端管理反而成了累赘——于是我做了 codux [调研] 各位在公司都用什么 ide 和 agent 写代码? 老运维 share 一个运维平台 看到有公司考核 token 指标,很好奇大家上个月的 AI 账单是多少 GLM-Coding 调用持续报错: z.ai 的 Lite 套餐几乎无法使用,官方 Pro/Max 是否稳定? 现在还有什么渠道可以稳定安全地使用 Claude 吗? 上海漕河泾内推,本组有 2 个 hc,一个后端,一个前端,预算都是 20k 左右,不打卡,氛围好 如果 V2EX 上有一组不永久保存聊天记录(比如只保存 7 天或者 24 小时)的聊天室,那么会开启哪些有用或者有趣的可能? gemini cli 貌似挂了,一直返回 403 第一次在自媒体上赚到钱 收集了最近在使用的低价 GPT, Gemini,邮箱等 AI 会员的小店合集 讨论个大实话:现在企业还在说 AI 编程提效 20%, 30%的,真的太落后,没用懂 AI。因为包括很多前沿公司,已经狂奔到提效 200%-500%的情况 [招聘][远程][币安] 前端/后端/QA/iOS/Android 至少 3 年以上经验 目前有大量 HC 欢迎投递 Chatgpt Pro 用量用不完的可以开这些设置 面试的时候好像遇到钓鱼了,给各位避个坑 cursor 年续费 22 号到期, 自动续费是否还是老的计次套餐呢 被两件破事毁掉的一下午,琐碎的内耗消磨人的精力 使用 Planet 存储 Codex 的会话或者重要信息 如果业务部门领导不要你开发功能,而是要求你教会它用 claude code 开发功能,你会怎么做? 分享一个 MacOS 接绿联 CM818 USB 转 DP 转接器使用感受 我的 HR 朋友 10 年老 Java ,非全大专,大家帮忙看看简历 开源了一个 AI 口语练习工具,音素级发音评分,完全免费可自部署 V2EX 上有哪些你觉得很有趣、印象深刻的妹纸? 字节为啥不出个国内版 Vercel? 有在大马的朋友吗? 问个运营商问题 你们在有领导的公司大群发过的最大胆的消息是什么 公司裁员,目前没有工作。想试试摆摊,做一个移动鲜啤打酒车 我的硬盘 Memblaze Pblaze 5 Linux 下不识别,给 Linux 内核提交了补丁, AI 说有望被合并 只有我一个人觉得 codex 不好用?
做了个基于 LLM 的小说 EPUB 翻译工具,效果能打过市面上大部...
Tritium0041 · 2026-05-25 · via V2EX

最近在看一套日文轻小说,找不到中文版,试了一圈市面上的方案:

  • 沉浸式翻译逐段翻,角色名字一会儿一变,前后完全不统一
  • 直接把一章丢给 AI ,上下文一长就开始漂移,设定记不住
  • 传统机翻就不说了,纸鹤给你翻成起重机

问题的根源在于:长篇小说的翻译本质上是一个有状态的任务,但大多数工具把它当成一个无状态的文本转换在处理。

所以就自己写了一个:ePubTsuyaku


核心设计

整体是一条四阶段流水线,模拟人类读书→翻译的过程:

0. Reference Phase (可选) 如果有系列前作的精翻版,可以先喂进去。程序会提取惯用译名、人名对照和文风特征,作为后续阶段的软参考。翻系列作品的话这个功能很有用。

1. Summary Phase 按 EPUB spine 顺序串行读取每一章,让 LLM 生成章节摘要和上下文状态(人物关系、当前设定等)。这一步是串行的,目的是建立稳定的全书上下文链。

2. Translation Phase 每章切成多个批次,在冻结的章节上下文上并发翻译。关键点是"冻结"——翻译过程中不更新上下文,避免批次间互相污染。

3. Review Phase 对每个批次做结构化校对,LLM 对照原文打分。低于阈值的批次会带着校对反馈自动重翻,最多重试 N 次。

4. Rebuild 把译文回写进原始 EPUB 的 XHTML 结构,保留目录、资源、大部分元数据,生成新书。不是把原书拆了重建,是在原结构上做替换。


工程上的一些细节

断点续跑:进度写进 progress.json,任务中断后直接续,不用从头跑。

Provider 支持:兼容任意 OpenAI-compatible 接口。三个阶段(摘要/翻译/校对)可以分别指定不同模型,比如摘要用便宜的小模型,翻译用效果好的大模型。

Web UI:用 Flask 写了个本地界面,选书、上传、调参、看实时日志、下载结果都在一个页面里。不想敲命令行的话直接用这个。

Web UI 界面


翻译质量

用《玩乐关系》第三卷做了个横向对比测试,三个译本:本项目( DeepSeek-v4-flash )、沉浸式翻译( Qwen3.6-plus 逐段)、谷歌机翻。

评测用的是配套写的另一个开源工具 translation-quality-evaluator,跑 LLM judge 对准确性、术语一致性、流畅度等六个维度打分。

结果大概是:本项目综合分 57.4 ,LLM 逐段 35.1 ,机翻 15.2 。术语一致性这项差距最明显,这也是流水线设计的主要目标。

翻译结果对比:

翻译文本对比

LLM judge 的翻译分数:

量化评测数据

详细的评测数据和文本对比在这篇文章里: https://www.tritium.work/2026/05/24/ePubTsuyaku:基于 LLM 的长篇 EPUB 电子书翻译工具/


适合的场景

  • 翻轻小说、网文、长篇小说这类上下文强依赖的 EPUB
  • 系列作品,希望继承前作译名和语气

项目地址

GitHub: https://github.com/Tritium0041/ePubTsuyaku

官网: https://epub.tsuyaku.cyou/

MIT 协议,Python 3.9+,依赖用 uv 或 pip 装都行。欢迎试用,有问题或者想法直接开 Issue 。