wenyi文译断点续跑全解析翻译中断不用重跑已花Token一文不废【免费下载链接】wenyi将被语言阻隔的作品带到读者的语言中。Bringing literature into your language.项目地址: https://gitcode.com/gh_mirrors/we/wenyiwenyi文译是一款把文学翻译交给 AI 的开源工具而它的断点续跑机制让长篇翻译中断后不用从头再来已完成的章节和已花的 Token 全部安全保留重新执行同一条命令即可从断点继续。本文带你搞清楚它是怎么做到的。为什么翻译中断后不该整本重跑用 AI 翻译一本几十章的小说动辄几小时、几百上千条模型请求。中途网络断开、CtrlC 误触、机器重启……如果每次都从第 1 章重来时间和 API 费用都是灾难。wenyi 的答案很简单每个阶段的结果都在完成瞬间落盘续跑时只挑没完成的做。核心逻辑集中在 runstore.py它是整个状态目录的读写中枢。断点续跑的三步核心机制1. 章节级状态目录每完成一章立即存档翻译状态保存在state/书名/targets/目标语言/目录里每章一个独立的 JSON 文件。某章译文一完成就立刻原子写入并更新 manifest 中的章节状态续跑时通过 pending_chapters() 只取出状态不是已完成的章节下标——已完成的直接跳过一个 Token 都不会多花。2. 源文件指纹确保续跑的是同一本书manifest 里记录着源文件的source_sha256。再次运行 ensure_source_identity() 会重新计算文件哈希并比对内容一致→ 正常续跑复用全部已有成果同名但内容变了→ 明确拒绝续跑避免把旧译文拼进新书里旧状态缺少指纹→ 提示在全新目录重新建立状态。这个宁停勿错的策略保证了续跑结果的可信度。3. Token 账本已花的钱一文不废每个目标目录都有usage.json跨续跑累计token 用量timing.json同样累计总用时两次运行之间的停机时间不会被错误计入。更贴心的是 recover_usage()即使程序在写账本的半途中被杀下次启动时会幂等地完成这笔中断的提交用量记录不丢、不重、不错。一键续跑只需要重新执行同一条命令这是 wenyi 最省心的地方——续跑没有任何特殊命令。中断后对同一个源文件再执行uv run wenyi translate book.epub uv run wenyi status book.epub # 随时查看进度翻译器会自动识别已有状态语言分析、风格指南、术语表、全书概述全部复用只翻译尚未完成的章节。CLI 入口 workflows.py 中的注释写得很直白Repeat to resume重复执行即续跑。几个实用细节只翻指定章节--chapter 3可以单独补翻某一章其余章节不受影响改润色设置不会重跑已完成的翻译批次省得你为改个参数再烧一遍钱SRT 字幕同样支持续跑已缓存的批次目录会自动跳过usage.md 中有完整的目录布局说明。中断发生在哪个阶段损失就停在哪wenyi 的管线分准备、翻译、润色、审校、导出多个阶段每个阶段独立持久化中断时机重新运行后准备阶段分析/术语提取复用已持久化结果只补未完成的翻译中途已完成章节直接跳过审校中途审校每次全量重审但译文本体不重译prepare命令可以只准备不翻译生成风格指南、术语表、全书概述之后再translate接着跑适合先花小钱做调研的场景。最终成果单语版与双语版任选全部章节跑完后wenyi 默认导出单语版output/书名.zh.epub加--bilingual还能生成对照版——译文在上、原文淡显在下方便随时校对。小结把重跑焦虑从翻译工作流里删掉✅章节级存档完成一章保一章续跑只补缺口✅源文件指纹校验同一本书才允许续跑防止状态错乱✅累计 Token 账本 中断恢复已花费用分文不丢账本可自愈✅零学习成本没有 resume 命令重复执行原命令就是续跑对长篇文学翻译来说断点续跑不是锦上添花而是决定敢不敢开始的关键机制。orchestrator.py 中每个阶段复用持久化结果再继续的设计加上 usage.md 里详细的目录说明构成了这套机制的完整闭环。下次翻译中断深呼吸敲下同一条命令就好。【免费下载链接】wenyi将被语言阻隔的作品带到读者的语言中。Bringing literature into your language.项目地址: https://gitcode.com/gh_mirrors/we/wenyi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考