三块钱两个小时翻译一本书
马工约 5 分钟前两天我翻译了一本315页的英文书，成本三块钱。质量够用。
不是我英文好，不是我有什么翻译天赋。是因为我和Claude Code一起，把翻译当成了一个工程项目来做。
整个过程中，我需要扮演不同的角色：
- 需求分析师
：确定翻译目标、受众、语气 - 翻译
：虽然实际翻译是AI做的 - 审校
：检查术语准确性、上下文 - 测试
：验证页码对应、格式正确 - 设计师
：设计中英对照布局、生成EPUB
Claude Code构建了OCR + 翻译pipeline，我们一起走完了一个完整的Translation Development Life Cycle。
成本三块钱，时间几个小时。
为什么要这么做？
传统的翻译流程有几个问题：
- 太慢
：一本315页的书，传统翻译公司要几个月 - 太贵
：按字收费，动辄几万块 - 质量难控制
：译者水平参差不齐，审校流程也无法保证一致性
这三个问题的根源是：翻译还在用人工流水线的方式做。
我是怎么做的
整个过程可以分成五个阶段。
需求分析
一开始，我和Claude Code确认了几个关键问题：
目标语言：简体中文 语气：严肃（这是历史传记） 预算：低于$100 输出格式：中英对照，方便我对比阅读
这些看起来很简单，但很重要。明确需求之后，才能设计合适的pipeline。
构建pipeline
Claude Code设计了一个翻译pipeline：
PDF → 提取页面图片 → OCR识别文字 → 翻译 → 格式化
技术栈：
PyMuPDF：提取PDF页面 Google Vision API：OCR识别 Google Translate API：翻译 缓存系统：可以中断、恢复
运行结果：37分钟翻译了302页，成本约$3。
质量检查
翻译完成后，我review了输出，发现几个问题：
页码对应有offset（因为第1页OCR失败了） 有OCR识别错误（垃圾URL、spam文字） 中文没有段落分隔，都挤在一起 年表格式需要特殊处理
这不是逐字检查翻译，而是发现系统性问题。
迭代修复
针对每个问题，Claude Code写了对应的脚本：
clean_and_fix.py # 清理OCR错误
rebuild_correct_mapping.py # 修复页码对应
format_with_linebreaks.py # 添加段落分隔
generate_clean_bilingual.py # 生成中英对照
generate_html_epub.py # 生成EPUB格式
这是典型的工程迭代：发现问题 → 写代码解决 → 验证 → 下一个问题。
输出设计
最后生成了多种格式：
bilingual_clean.md- 中英对照 (1.2MB) bilingual_book.epub- EPUB版本 (778MB, 带图片) translated_book.md- 纯中文版 (1.1MB) images/- 315张提取的页面图片
整个session：611条对话，时间跨度约8小时，创建了10+个Python脚本，输出了3种格式。
这样做的好处是什么？
我们来对比一下传统翻译流程和工程化流程：
| 思维方式 | ||
| 质量控制 | ||
| 改进方式 | ||
| 交付物 | ||
| 可扩展性 | ||
| 成本 | ||
| 时间 |
这个对比表最重要的不是成本和时间（虽然确实便宜很多），而是思维方式的转变。
传统翻译解决的是"这本书怎么翻译"。工程化翻译解决的是"怎么建立一个可以翻译这类书的pipeline"。
可复用性才是核心
假设我现在要翻译第二本书，同样315页的历史传记。
传统翻译：再花几万块，再等几个月。
工程化翻译：
python translate_book.py new_book.pdf --target zh-CN --style serious
运行37分钟，成本$3，得到相同质量的输出。
为什么？因为我已经有了：
OCR → 翻译的pipeline代码 清理OCR错误的脚本 页码对应修复的脚本 格式化和生成EPUB的脚本
这些都是针对一类问题建立的可复用基础设施。
第一本书的成本是$3 + 8小时开发时间。第二本书的成本是$3 + 0小时开发时间。第十本书的成本还是$3 + 0小时。
这就是工程化的力量。
哪些问题还没解决？
当然，这个项目还有很多不足。
设计层面的弱点
EPUB虽然能用，但是不够专业：
字体选择不够好（我不懂排版） 行间距和段落间距需要调整 图片和文字的布局可以优化 缺少目录和章节导航
不过话说回来，这已经比大多数翻译公司给的Word文档要好了。至少是个可以在Kindle上阅读的EPUB，而不是需要你自己转换格式的docx。
质量控制的缺口
我现在的质量检查方式是：人工抽查几页，看看翻译是否合理。
这个方法有几个问题：
- 没有术语一致性检查
：同一个人名可能被翻译成不同的中文 - 没有自动化的质量指标
：不知道哪些段落翻译得好，哪些不好 - 依赖人工spot-checking
：我只检查了几页，不是全部
改进方向：
建立术语数据库，确保专有名词翻译一致 添加自动质量检查（比如检测译文是否完整、格式是否正确） A/B测试不同的翻译API（Google Translate vs DeepL vs Claude） 建立质量评分系统
人的作用在哪里？
虽然翻译是AI做的，但人的作用仍然不可替代：
- 需求分析
：确定目标、语气、预算 - Pipeline设计
：选择技术栈、设计流程 - 质量判断
：发现系统性问题，不是逐字检查 - 上下文管理
：在611条对话中保持方向感 - 最终决策
：什么时候"够好了"可以交付
恕我直言，AI一定会在翻译中占据主导地位，但是人类会从译者变成工程师。
更深层的洞察
翻译为什么变成了工程问题？
三个技术突破
- OCR准确率超过95%
：Google Vision API能准确识别印刷文字 - AI翻译质量够用
：不是完美，但是"good enough" - 完整的工具链
：PyMuPDF、缓存系统、格式转换工具
这三个技术单独看都不是新发明，但是组合在一起，就改变了翻译的性质。
工作分配的变化
以前的翻译流程：
译者：100%的工作量 审校：100%的工作量
现在的工程化翻译：
需求分析师：10% 开发者（写pipeline）：20% AI（翻译）：60% 审校（系统性问题）：5% 测试（验证格式）：3% 设计师（EPUB布局）：2%
你看，工作被拆解成了多个角色，而且大部分由AI完成。
翻译公司不理解
客户要的不是"完美的翻译"，而是"快速、便宜、够用、可迭代" 竞争力不在译者资质，在于pipeline设计、迭代能力、人机协作
他们还在用线性流程思维（需求 → 翻译 → 审校 → 交付），而不是迭代工作流思维（pipeline → 运行 → 发现问题 → 修复 → 再运行）。
结论
翻译现在是工程问题，不是手艺活。
我翻译315页书，扮演了5个角色：需求分析师、开发者、翻译、审校、测试、设计师。
成本三块钱，时间几个小时，质量够用，而且这套pipeline可以复用。
翻译公司，你们准备好了吗？
有兴趣研究翻译工程化的同好，欢迎在公众号给我留言。如果你有实际的翻译项目，也欢迎分享你的workflow，我们一起交流讨论。