最近，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 格式结构 忽略代码块、命令行等无需翻译内容 自动处理链接跳转和语言路径 配置术语表，统一翻译结果
这一步让翻译具备了“规则意识”，但依然存在两个问题：
上下文和规则需手动维护，配置门槛高 无法在开发环境中直接落地，流程割裂
第四阶段：引入 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