人工智能技术在文档翻译领域的应用究竟能达到怎样的水平？近期，AntV 团队正在推进 G2 与 G6 文档的国际化改造，过程中遇到了不少难题，也逐步摸索出一套可行的解决方案。表面上看，这似乎只是“将中文翻译成英文”的简单任务，但实际执行后才发现——这本质上是一场内容工程挑战，远非简单复制粘贴一个翻译工具就能解决。
从传统翻译工具一路尝试到 AI Agent，整个探索过程值得记录。希望这篇实践笔记能为正在从事多语言文档管理、或希望将 AI 真正落地到工程场景的朋友提供一些参考。
第一阶段：传统翻译工具，速度虽快但质量堪忧
最初我们使用了 DeepL、Google Translate 这类工具。优点是操作简单、响应迅速，但很快暴露出几个硬伤：
- 术语混乱——例如 G6 中的“交互”，有时被译成 interaction，有时又变成 behavior
- 语感不自然——中式英语痕迹明显，读起来不像专业文档该有的语言风格
- 结构被破坏——Markdown 中的标题、代码块、链接经常被错误处理
结论很明确：这类工具适合快速预览，但不适用于生产级文档的翻译。
第二阶段：引入 LLM 翻译，质量提升但仍需人工校对
GPT 兴起后，团队将翻译任务交给了大模型。整体质量明显上了一个台阶，尤其体现在：
- 上下文理解能力强，语句更连贯流畅
- 语言自然，符合技术文档应有的调性
但人工 review 时仍有不少痛点：
- 术语不统一，缺少统一的词汇表进行约束
- 跳转链接未自动本地化——比如
/manual/getting-started不会自动替换为/en/manual/getting-started - 中文路径被直译，导致链接直接失效
这套方案打个分：80 分。质量基本够用，但人工修正成本仍然偏高。
第三阶段：AI Agent 初探，尝试流程自动化
为了进一步降低人工干预，团队构建了一个基于 Prompt + LLM 的翻译 Agent，重点强化了几个能力：
- 保留 Markdown 格式结构
- 忽略代码块、命令行等无需翻译的内容
- 自动处理链接跳转和语言路径
- 配置术语表，统一翻译结果
这一步让翻译有了“规则意识”，但仍有两个问题：
- 上下文和规则需要手动维护，配置门槛较高
- 无法在开发环境中直接落地，流程是割裂的
第四阶段：引入 Cursor，实现本地高质量自动翻译
目前，团队使用的终极方案是：「Cursor + Translation Rules」。
Cursor 是一个集成 LLM 的开发 IDE，其翻译方案提供了更强的工程控制能力：
规则驱动的翻译逻辑
通过 .cursor/translation-rules 文件，可以做到：
- 设定术语表
- 配置不翻译的语法块
- 自定义链接替换规则
- 定义语言风格（英式/美式英语）
Prompt 与规则结合触发
在 Cursor 中，只要输入“翻译”等关键词，它会自动加载翻译规则，作为上下文注入给 LLM。这样一来：
- 你不需要每次都提醒 AI 该怎么做
- AI 输出更稳定，符合预期格式
自动写入文件
翻译完成后，Cursor 会直接修改目标英文文档，省去粘贴、比对的步骤，效率大幅提升。
结论：翻译流程实现半自动化，高质量产出，最小化校对成本。
目前这套基于规则系统的翻译和协作方式，已经在 G6 项目中实际落地。感兴趣的话可以直接拉取 G6 的最新代码库，亲自体验翻译规则在真实项目中的应用效果。
延伸应用：不仅是文档，业务项目也能用
Cursor 的规则系统不仅适用于文档翻译，还可以扩展到日常开发中，比如：
- 统一代码样式命名规范
- 定义 UI 组件风格（按钮颜色、字体等）
- 生成统一的测试代码模板
- 限制项目结构（如目录组织）
在 0.49 版本中，Cursor 还新增了「Generate Cursor Rules」功能。只需输入一句话：
❝希望后续代码保持统一 UI 风格，请生成对应设计规则。❞它就会自动生成符合项目风格的 Design System 规则，未来所有 AI 生成内容都会遵循这套规则。
总结
翻译文档本质上属于内容工程的重要一环。AI 不可能替你完成所有工作，但如果配合好「任务拆解 + 明确规则 + 工具集成」，它就能成为一个极强的自动化助手。
这次实践验证了这条路径的可行性：
- 从翻译工具 → LLM → Prompt Agent → 工程化 IDE
- 从个体提升 → 团队协作 → 规则体系沉淀
如果你也在构建多语言文档、尝试让 AI 真正“懂你在说什么”，建议从规则入手。推荐阅读一篇对我们启发很大的文章：Cursor Rules: Why Your AI Agent Is Ignoring You (and How to Fix It)[1]