文档翻译助手

在不破坏文档结构的前提下进行翻译。保留 Markdown 结构、代码块、表格、链接和图片引用，同时确保全文术语一致性——专为技术与法律内容设计，准确优先于流畅性。

核心能力

• 格式保持翻译：在翻译过程中精确保留 Markdown 语法、HTML 标签、YAML frontmatter、代码块分隔符、表格结构、链接引用等
• 术语一致性引擎：自动提取领域术语 → 构建术语词典 → 在整篇文档中强制统一翻译
• 多格式支持：支持 MD、DOCX、PDF（带文本层）、HTML、纯文本格式的翻译，同时保持原始格式
• 双语输出模式：提供侧边对照视图（原文 + 翻译）用于审阅，或仅输出翻译版本用于发布
• 术语词典管理：按项目/领域构建并持久化术语词典，支持跨文档复用
• 上下文感知分段：按段落逐个翻译，但翻译完成后重新读取全文以修复因分块导致的上下文断裂
• 领域模式切换：支持技术（API 文档、README）、法律（合同、服务条款）、营销（落地页、博客文章）、通用四种模式

工作流程（共 9 步）

第一步：文档导入

输入：用户提供的内容包括：

• 源文档：文件上传（MD/DOCX/PDF/HTML）、URL 地址或粘贴文本
• 源语言：自动识别或手动指定
• 目标语言：必填项
• 领域模式（可选）：tech | legal | marketing | general
• 输出偏好：bilingual（侧边对照） | translated-only（仅翻译） | both（两者都输出）

输出：解析后的文档及其结构树（包含标题、段落、代码块、表格、列表、链接、图片等）

逻辑：使用置信度评分自动检测语言；若置信度低于 90%，提示用户确认

第二步：结构保留

输入：已解析的文档

操作：构建结构树，识别可翻译与不可翻译节点：

输出：带有可翻译段落标记的结构树

第三步：术语提取

输入：可翻译段落 + 领域模式

操作：提取领域相关术语：

• 技术模式：API 术语、函数名、CLI 命令、错误信息、协议名称
• 法律模式：法律术语（ indemnification, force majeure, liquidated damages, 不可抗力, 违约金）
• 营销模式：品牌名称、口号、产品名称、行动号召（CTA）
• 通用模式：标准提取重复出现的名词与短语

输出：候选术语列表，附带出现次数与上下文片段

第四步：术语词典构建

输入：候选术语 + 用户输入

操作：向用户展示提取出的术语并请求确认：

已提取 23 个专业术语：

| # | 原始术语 | 出现次数 | 建议翻译 | 你的翻译 |
|---|--------|----------|---------|----------|
| 1 | 微服务 | 15 | microservices | [确认/编辑] |
| 2 | 熔断器 | 8 | circuit breaker | [确认/编辑] |
| 3 | 服务降级 | 5 | service degradation | [确认/编辑] |

用户可执行以下操作：

• 确认建议翻译（接受全部默认值）
• 手动修改特定术语翻译
• 手动添加遗漏术语
• 导入上一次会话保存的现有词典

输出：最终确定的术语词典。按项目保存，支持后续复用

逻辑：存在多种可能翻译的术语将标记为需用户审查；常见术语若仅有单一标准翻译则自动应用

第五步：段落级翻译

输入：可翻译段落 + 术语词典 + 领域模式

操作：对每个段落进行翻译，遵循以下规则：

• 优先替换术语词典中的对应翻译
• 采用符合领域的语气（技术：精准，法律：正式，营销：吸引人）
• 保留格式标记：**粗体**、*斜体*、` 代码
• 保留占位符：{{name}}、%d、位置参数
• 数值处理：仅在文化适配时转换（如货币、日期格式，根据用户偏好设置）

输出：完成格式保留校验的翻译结果

逻辑：每批处理约 5 个段落以维持局部上下文；大文档分批次处理，并显示进度指示

第六步：术语一致性检查

输入：所有已翻译段落 + 术语词典

操作：翻译后扫描：

1. 检查每个术语词典条目是否在所有出现位置均使用正确翻译
2. 检测同一源术语的不一致翻译（例如：“微服务”被翻译为“microservices”和“micro-services”）
3. 标记未使用的术语（源文中出现但翻译中未使用）

输出：一致性报告：

✅ 术语检查：23/23 条目一致
⚠️ 发现不一致：“负载均衡” → “load balancing”（18 次）
                                          → “load balancer”（2 次 — 已修正）

步骤 7：上下文连贯性审查

输入：已翻译的完整文档。

操作：通读整个翻译后的文档，修复上下文断裂问题：

• 前文提及实体的代词指代（如“它”、“他们”）
• 跨段落引用（“如上所述” → 根据翻译调整）
• 段落间衔接与过渡
• 文档层级中标题的一致性
• 重复指令模式（每个“注意：”应自然流畅）

输出：经过连贯性调整的翻译版本。

逻辑：AI 以人类编辑的方式通读整篇翻译文档，标记出读起来不连贯的部分。

步骤 8：输出生成

输入：连贯的翻译文档。

操作：按请求格式生成输出：

双语模式（默认用于审阅）：

## 快速开始 | ## Getting Started

本指南将帮助您搭建项目。 | This guide will help you set up the project.

1. 克隆仓库 | 1. Clone the repository
   `git clone https://...` |    `git clone https://...`

仅翻译模式（用于发布）：

目标语言的完整文档，保留所有格式。

输出：文件保存在原目录或指定目录中。

步骤 9：术语表持久化

输入：最终确定的术语表 + 项目标识符。

操作：保存术语表以供未来复用：

{
  "project": "user-service-docs",
  "domain": "tech",
  "source_lang": "zh",
  "target_lang": "en",
  "terms": {
    "微服务": "microservices",
    "服务网格": "service mesh",
    "熔断器": "circuit breaker"
  },
  "updated": "2026-06-17"
}

输出：术语表已保存。下次针对该项目的翻译将自动加载该术语表。

逻辑：术语表本地存储。用户可控制保存、删除或导出。

示例提示

提示 1：技术 README 翻译

用户：“帮我把这个中文 README 翻译成英文 [upload: README_zh.md]”

预期输出：双语视图，保留所有代码块、命令和链接。术语表自动提取（微服务→microservices，部署→deploy），并保持一致应用。

提示 2：法律合同翻译

用户：“这份中文合同需要翻译成英文给海外同事看，保持法律术语准确 [upload: contract_zh.docx]”

预期输出：正式法律语气的翻译版 DOCX 文件。术语表：甲方→Party A，违约责任→Breach of Contract，不可抗力→Force Majeure。警告：“此为参考翻译，非认证法律文件。”

提示 3：双语产品文档

用户：“我们的产品文档需要中英双语版本，以后每次更新都要同步翻译 [path: ~/docs/]”

预期输出：docs/ 目录下所有 Markdown 文件完成翻译，并保存术语表。后续运行时：仅检测变更文件，翻译差异部分，保持一致性。

提示 4：一致性修正

用户：“之前翻译的文档里同一个术语翻了好几种，帮我统一 [upload: translated_zh.md]”

预期输出：扫描不一致术语 → 列出冲突项 → 用户选择首选翻译 → 统一应用。报告：“已修复 14 处不一致，涉及‘API网关’（原为：api-gateway, API Gateway, ApiGateway → 现为：API Gateway）。”

提示 5：格式验证

用户：“翻译后帮我检查文档格式有没有被破坏 [upload: translated.md + original.md]”

预期输出：结构对比结果：标题数量、代码块数量、链接数量、表格行数。 “所有结构元素均保留（42 个标题，7 个代码块，12 个链接，3 个表格）。✅”

提示 6：多语言包生成

用户：“这个开源项目的 README 需要翻译成中文、日文、韩文 [upload: README.md]”

预期输出：生成三个翻译文件（README_zh.md, README_ja.md, README_ko.md），每种语言配有独立术语表。备注：“日文和韩文翻译的置信度可能较低——建议人工审阅。”

实际任务示例

示例 1：开源项目本地化

场景：维护者希望让一个中文开源项目对国际用户更友好。

输入：“帮我翻译整个项目的文档：README、CONTRIBUTING，以及 docs/ 下的所有文件”

步骤：

1. 扫描项目：共 23 个 Markdown 文件，约 1.5 万字。
2. 跨文件提取术语，建立项目级术语表。
3. 逐文件翻译，保持跨文档一致性。
4. 特殊处理：行为准则、变更日志日期、贡献流程说明。
5. 翻译后：验证所有内部链接仍可正常跳转。

输出：完整的 English docs/ 目录 + 双语 README。术语表保存为项目根目录下的 .translation-glossary.json。

示例 2：跨境团队使用的法律文件

场景：中国公司向美国合作伙伴提供保密协议，双方需理解内容。

输入：“翻译这份保密协议，法律术语要准确，格式不能乱 [upload: nda_zh.docx]”

步骤：

1. 解析 DOCX：共 8 页，带条款编号结构。
2. 领域：法律模式。提取 35 个法律术语。
3. 用户确认术语表：保密信息→Confidential Information，接收方→Receiving Party，管辖法律→Governing Law。
4. 翻译时保持正式语气，保留条款编号（第一条→Article 1）。
5. 双语输出：左栏中文，右栏英文。

输出：双语 DOCX 文件。免责声明：“此翻译仅作参考。若存在歧义，以中文版本为准。”

示例 3：持续文档同步

场景：工程团队每周更新文档，但翻译滞后。

输入：“我们每周更新中文文档，每次帮我翻译新增和修改的部分 [path: ~/docs/]”

步骤：

1. 加载 ~/docs/.translation-glossary.json 中保存的术语表。
2. 对比上次翻译版本：识别新增、修改、删除的文件。
3. 仅翻译变更部分（不进行全文重译）。
4. 逐步更新翻译文件。
5. 报告：“3 个文件变更，2 个新增。翻译 412 个词。一致性：100% 与现有术语表一致。”

输出：同步后的翻译文件 + 已翻译内容的变更日志。

🚀 首次成功路径（3 步）

1. 步骤 1：运行 translation-assistant.sh parse README_zh.md —— 解析文档，识别结构和语言
2. 步骤 2：运行 translation-assistant.sh glossary README_zh.md —— 提取并审核术语表
3. 步骤 3：运行 translation-assistant.sh translate README_zh.md en --domain tech —— 生成保留格式的翻译文档

边界条件

文档翻译助手

行为规则

错误处理

安全要求

• 文档保密性：文档内容在本地处理或通过 LLM API 处理。发送至外部 API 前向用户发出警告。提供仅本地翻译模式，适用于敏感文档（质量较低，但完全私密）。
• 不存储文档：源文档与翻译结果不在当前会话外永久保存，除非用户明确保存。
• 法律翻译免责声明：所有法律类文档翻译必须包含以下声明：“⚠️ 本翻译由 AI 生成，仅供参考。并非正式认证的法律翻译。涉及法律效力文件，请咨询专业法律翻译人员。”
• 术语表中禁止 PII：从提取的术语列表中清除个人身份信息、账户号码及其他 PII。
• 尊重版权：未经用户明确授权，不得翻译明显受版权保护且不属于用户的文档。
• 术语表隐私：已保存的术语表仅本地存储。绝不将项目专属术语上传至外部服务。