如何用 AI 更好的搞定 AntV 开源文档的翻译

最近，AntV 在推进 G2、G6 的文档国际化改造。听起来像是“把中文文档翻成英文”这么简单的事，实际做起来才发现：这是一场内容工程挑战，远不只是“找个翻译工具粘贴一下”那么轻松。

我们经历了从传统翻译工具到 AI Agent 的演进过程，希望这份实践笔记能为你在多语言文档管理、AI 工程化落地等方面提供一些参考。

第一阶段：传统翻译工具，速度快但质量差

起初我们采用的是 DeepL、Google Translate 等翻译工具。优点是简单、快速，但很快遇到了几个难以接受的问题：

• 术语混乱：如 G6 中的“交互”，有时被翻译成 interaction，有时又是 behavior
• 语感不自然：中式表达明显，读起来不够专业
• 结构被破坏：Markdown 中的标题、代码块、链接经常被误处理

结论：适合快速预览，但不适合生产级文档。

第二阶段：引入 LLM 翻译，质量提升但仍需人工校对

随着 GPT 的兴起，我们将翻译任务转交给了 LLM。整体质量有明显提升，尤其体现在：

• 理解上下文强，语句更连贯
• 语言自然，符合技术文档风格

但在人工 review 时仍存在几个痛点：

• 术语不统一，缺少统一词汇表支持
• 跳转链接未自动本地化，如/manual/getting-started没有自动替换为/en/manual/getting-started
• 中文路径被直译，导致链接失效

我们给这套方式打分：80 分。质量够用，但人工修正成本仍高。

第三阶段：AI Agent 初探，尝试流程自动化

为进一步降低人工干预，我们构建了「基于 Prompt + LLM 的翻译 Agent」，强化以下几个点：

• 支持保留 Markdown 格式结构
• 忽略代码块、命令行等无需翻译内容
• 自动处理链接跳转和语言路径
• 配置术语表，统一翻译结果

这一步让翻译具备了“规则意识”，但依然存在两个问题：

1. 上下文和规则需手动维护，配置门槛高
2. 无法在开发环境中直接落地，流程割裂

第四阶段：引入 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