如何让100个chunk的术语翻译保持一致translate-book术语表系统详解【免费下载链接】translate-bookAgent skill for Codex, Claude Code, and OpenClaw that translates entire books (PDF/DOCX/EPUB) into any language using parallel subagents.项目地址: https://gitcode.com/gh_mirrors/tran/translate-book用 AI 做图书翻译最头疼的不是翻译速度而是术语一致性。translate-book 是一个面向 Codex、Claude Code 和 OpenClaw 的 Agent Skill用并行子代理把整本书PDF/DOCX/EPUB翻译成任意语言。它靠一套术语表 反馈合并 精确重译的术语表系统让 100 个 chunk 的同一人名、同一机构名在全书保持同一个译法。问题并行翻译为什么会译名漂移translate-book 的核心思路是一本书拆成约 6000 字符一个的 chunk每个 chunk 交给一个独立上下文的全新子代理翻译。这样能避免单会话长文本的上下文堆积和输出截断100 个 chunk 默认 8 路并发速度很快。但副作用也很直接第 7 个 chunk 把 Manhattan 译成了曼哈顿第 43 个 chunk 只认得上下文把它译成了曼哈顿岛第 88 个 chunk 又写成了门荷顿每个子代理都看不见彼此的译文同一个专有名词自然会出现三种译法。这就是术语漂移term drift——并行图书翻译的第一号质量问题。术语表系统全景先约定再翻译术语表系统在正式翻译之前介入流程分五步步骤做什么① 抽样读 5 个代表性 chunk首章、末章、3 个均匀分布的中间章节② 提取找出人名、地名、机构名、反复出现的领域术语为每个术语确定标准译法③ 写入生成temp_dir/glossary.json可手动编辑重跑不会覆盖④ 统计频次扫描全部源 chunk统计每个术语在全书出现的次数⑤ 注入提示词翻译每个 chunk 前把只与该 chunk 相关的术语表作为硬约束注入提示词 设计哲学一句话概括脚本做记账LLM 做语义判断。哈希、去重、校验、IO 全部由确定性 Python 完成scripts/glossary.py而这个词到底是不是那个人名的别名这类语义决策才交给 LLM 判断。术语表长什么样glossary.json 的 v2 结构术语表就是一个普通 JSON 文件放在临时目录里可以直接手工编辑{ version: 2, terms: [ {id: Manhattan, source: Manhattan, target: 曼哈顿, category: place, aliases: [], gender: unknown, confidence: medium, frequency: 12, evidence_refs: [], notes: } ], high_frequency_top_n: 20 }各字段的作用用一张表说清楚字段含义新手提示source/target原文 → 标准译法唯一必填翻译时强制使用aliases同一实体的变体拼写别名出现在正文里也算命中该术语category分类person / place / organization 等帮助判断同类术语gender性别male / female / nonbinary / unknown用于代词翻译默认 unknown有证据才升级confidence置信度 low / medium / high由证据数量驱动只升不降frequency全书出现次数由统计命令自动写入evidence_refs佐证 chunk 列表最多保留最近 5 条FIFO几个容易踩的坑v2 结构帮你提前挡住了同一个词不能归属两个术语。如果Apple既指公司又指水果术语表没法同时写两种译法——系统会直接报错提示你手工消歧比如改成Apple (Inc.)避免机器静默选错译法。v1 旧文件首次加载会自动升级为 v2无需手工迁移但如果 v1 里有同名不同义的重复词条升级会中止并给出消歧提示原文件保持不动。精准注入每个 chunk 只看到它需要的术语术语表再全也不能整本塞进每个子代理的提示词。glossary.py提供两个命令解决这个问题第一步统计全书频次python3 scripts/glossary.py count-frequencies temp_dir这里的匹配规则相当讲究ASCII 词用单词边界正则——cat不会误匹配categoryC、.NET也能正确识别中日韩术语用子串匹配但单字汉字会被拒绝王这种字会过度匹配一切别名出现次数计入所属术语所以拼写变体再多也不会丢失权重第二步为每个 chunk 生成专属术语表python3 scripts/glossary.py print-terms-for-chunk temp_dir chunk0042.md选词公式很简单本 chunk 中出现过原文或任一别名的术语 ∪ 全书频率 Top-N默认 20的术语输出是一张三列 Markdown 表格原文别名译文Manhattan—曼哈顿AliceA. Liddell爱丽丝这张表格会作为提示词第 13 条规则注入子代理以下术语必须严格使用指定译法不要自行变换。如果某个 chunk 没有相关术语这一整条规则会被省略不会留下空占位符。这样每个子代理拿到的都是小而准的约束既不撑爆提示词也不漏掉高频词。术语表会自我生长子代理反馈合并光靠开头抽样的 5 个 chunk术语表不可能覆盖全书。所以 translate-book 设计了反馈回路每个子代理除了输出译文还要写一个观察文件output_chunkNNNN.meta.jsonschema 见 scripts/meta.py诚实汇报本 chunk 里的发现观察类型内容new_entities新出现的实体 建议译法 原文引证alias_hypothesesTaig 可能是 Tai 的别名attribute_hypothesesTai 应该是男性附引证conflicts注入的译法泰读起来不对劲太一更好每批默认 8 个翻译完成后scripts/merge_meta.py 分两步合并prepare-merge扫描所有观察文件把发现分成两类无冲突的一致提案自动应用和需要判断的冲突别名判定、译法冲突等列成选项交给主代理裁决apply-merge事务性地落盘——任何一条决定写错整批回滚术语表一个字都不改合并是保守的新实体必须有原文引证性别默认unknown只有显式证据才升级已有标准译法不会被静默覆盖。于是第一批翻译喂给术语表的发现第二批、第三批翻译就能看到——术语表随翻译进程滚动生长。改了术语表之后只重译受影响的 chunk术语表是手工可编辑的。如果你翻到一半发现Manhattan应该统一译成曼哈顿岛改完glossary.json重跑 skill会发生什么不是全部重译。scripts/run_state.py 会给每个已完成的 chunk 记账用的哪版术语表哈希、选中了哪些术语逐条哈希、源 chunk 哈希、输出哈希。重跑时plan命令对比这些记录精确算出三类 chunk需要重译选中了被修改术语、或术语哈希变化的 chunk只需补记录旧输出仍然有效但缺状态记录无需处理术语、源文件都没变直接跳过注意细节改target、category甚至aliases都会改变术语哈希因为别名也出现在注入的表格里所以改别名的影响同样能被追踪到。小结三层状态一套闭环层文件角色标准层glossary.json唯一权威术语表子代理只读主代理唯一写入观察层output_chunkNNNN.meta.json子代理的原始发现批次合并的原料编排层run_state.json每个 chunk 的状态账本精确重译的依据共享状态单写者只有主代理写术语表和运行状态子代理只写自己的 meta 文件无需加锁脚本从不调用 LLM所有语义判断都在明确的裁决点上完成。对使用者来说这套系统的价值很直白你只需要在翻译前花几分钟检查一遍术语表中途发现译名不对随手改一处重跑时只有受影响的 chunk 会被重译——而不必担心 100 个 chunk 之间的人名各说各话。这正是并行图书翻译从能跑到能读的关键一步。想亲自验证仓库自带的完整链路测试素材在 tests/baselines/流程编排细节可对照 SKILL.md 的 Step 3.5 与 Step 4.5 阅读。【免费下载链接】translate-bookAgent skill for Codex, Claude Code, and OpenClaw that translates entire books (PDF/DOCX/EPUB) into any language using parallel subagents.项目地址: https://gitcode.com/gh_mirrors/tran/translate-book创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考