🎯 学什么：如何设计一个「在翻译过程中保护格式和信息完整性」的 Skill——Token（token：词元，AI 文本处理单位，直接影响费用） 感知分块 + 内容三分类（TRANSLATABLE / PRESERVE / SELECTIVE）+ 三种翻译模式。核心洞察：翻译的质量不只取决于目标语言的表达，更取决于「什么该翻、什么绝对不能碰」的判断能力。 💡 难易度：⭐⭐ | ⏱️ 预计时间：40 分钟
1. 课程概览
💡 白话小课堂：谷歌翻译一篇技术文章会发生什么？它会把你代码里的
print("hello")翻译成打印("你好")——代码直接报废！它会把 URL（URL：网址/链接）https://example.com/my-product变成https://example.com/我的产品——链接直接 404！L2-03 的翻译 Skill 就像一个「会动脑子的翻译员」——它知道代码、URL、图片路径是「神圣不可侵犯的」，知道标题和正文该翻，知道 frontmatter 里有些要翻有些不能翻。而且翻译长文档时，它不会把句子拦腰截断——而是按章节边界智能分块，保留上下文。
本课的独特定位——格式保留的内容变换：
| 做法 | 普通翻译工具 | 智能翻译 Skill（本课） |
|---|---|---|
| 代码块 | 「翻译」成垃圾代码 | PRESERVE（完全不碰） |
| URL | 翻译后 404 | PRESERVE（完全不碰） |
| 标题正文 | 翻译 | TRANSLATABLE（该翻） |
| YAML（YAML：缩进式数据格式，Skill 头部用） frontmatter | 全翻或全不翻 | SELECTIVE（title 翻，slug（slug：URL 中的短标识符） 不翻） |
| 长文档 | 按字符数切→句子拦腰断 | 按章节边界切→语义完整 |
🔑 核心秘诀：翻译质量最大的杀手不是模型水平，而是「切断了上下文」。一句话你只看到一半，再聪明的人也翻不准。本 Skill 的 Token 感知分块确保每个翻译块都是语义完整的。第二个杀手是「翻错了对象」——把代码翻译了、把 URL 翻译了、把不该翻的翻了。三分类系统解决这个问题。
⚠️ 避坑指南：最常见的翻译事故——URL 中的英文被翻译了，
https://example.com/my-product变成https://example.com/我的产品——链接直接 404。记住：URL 和代码是神圣不可侵犯的。
2. 格式保留策略 —— 三分类系统详解
2.1 为什么需要三分类而不是二分类？
二分类系统（只分「翻」和「不翻」）：
可翻译 vs 不可翻译
问题：YAML frontmatter 里的字段怎么办？
→ title: "My Product" → 应该翻成「我的产品」？
→ slug: "my-product" → 不能翻——它是 URL 的一部分！
二分类无法处理「同一个区域内的不同字段需要不同策略」的情况。
三分类系统（本 Skill 的设计）：
[TRANSLATABLE] → 应该翻译的（标题、正文段落）
[PRESERVE] → 绝对不碰的（代码块、URL、图片路径、HTML 标签）
[SELECTIVE] → 看情况决定的（YAML frontmatter 中的各个字段）
2.2 [PRESERVE] —— 神圣不可侵犯的内容
这些内容在翻译过程中完全不被处理——原样保留：
代码块（Fenced Code Blocks）：
```python
print("Hello, World!") ← 绝对不能变成 打印("你好，世界！")
def main(): ← 绝对不能变成 定义 主函数():
内联代码（Inline Code）：
使用 npm install 安装 ← npm install 不翻译
URL： https://example.com/my-product ← 不能变成 https://example.com/我的产品
图片路径：
← 路径不翻译
← alt text 可以翻，但路径不能翻
HTML 标签：
为什么这些必须 PRESERVE？
代码 → 翻译 = 功能破坏（代码不能运行）
URL → 翻译 = 链接失效（404）
图片路径 → 翻译 = 图片不显示
HTML 标签 → 翻译 = 页面结构破坏
2.3 [TRANSLATABLE] —— 应该翻译的内容
Markdown 标题：
# My Product Features → # 我的产品功能
## Getting Started → ## 入门指南
正文段落：
This product uses advanced AI technology...
→ 本产品采用先进的人工智能技术...
表格中的文字：
| Feature | Description |
→ | 功能 | 描述 |
列表项：
- Easy to use
→ - 易于使用
2.4 [SELECTIVE] —— 需要判断的内容
YAML frontmatter 中的字段需要逐个判断：
---
title: "My Amazing Product" ← TRANSLATABLE: 标题要翻
description: "A great tool..." ← TRANSLATABLE: 描述要翻
slug: "my-amazing-product" ← PRESERVE: URL slug 不能翻
tags: [tutorial, AI, skill] ← SELECTIVE: 看情况（可用中文也可保留英文）
created: 2026-05-03 ← PRESERVE: 日期格式不翻
author: "Jim Liu" ← PRESERVE: 人名不翻
---
SELECTIVE 的判断规则：
如果是 URL 的一部分 → PRESERVE（如 slug、permalink）
如果是人类阅读的 → TRANSLATABLE（如 title、description）
如果是标准化标识符 → PRESERVE（如 id、name）
如果是日期/数字 → PRESERVE
🔑 设计要点：三分类系统是 L1-11「逐字段分析」思维在翻译场景的变形——和 form-cro 逐字段检查每个表单字段一样，翻译 Skill 逐段内容判断该用哪个分类。核心一致：粒度决定质量——越精细的分类，越少的翻译事故。
3. Token 感知分块 —— 长文档翻译的正确姿势
3.1 为什么按字符数切分是错误的？
错误做法：按 2000 字符切割
原文：「本文介绍了三种提高转化率的方法。第一种是优化着陆页设计，
包括简洁的标题、清晰的 CTA 按钮和减少表单字段。第二种是...
[2000 字符到了，咔嚓一刀]
...A/B 测试不同的文案版本。第三种是...」
问题：AI 拿到的是「A/B 测试不同的文案版本。第三种是...」
→ 不知道前面在说什么 → 翻译不准确
→ 「第三种是」后面被截断 → AI 会「脑补」结尾
正确做法：按 Markdown 章节边界（`##` 标题）切分
Chunk 1: ## 1. 优化着陆页 (完整 1800 tokens)
Chunk 2: ## 2. 改善文案 (完整 1500 tokens)
Chunk 3: ## 3. A/B 测试 (完整 1200 tokens)
→ 每个块都是语义完整的——有标题、有正文、有结论
3.2 上下文重叠 —— 块与块之间的「记忆」
即使按章节边界切分，块与块之间也需要上下文：
不保留上下文：
Chunk 2:「第二种方法是改善文案」← 读者不知道「第一种」是什么
Chunk 3:「基于以上两种方法...」 ← 读者不知道「以上」是什么
保留上下文（前后各 1 句重叠）：
Chunk 2: 看到上文的「第一种是优化着陆页」
+ 翻译 Chunk 2 全部内容
+ 看到下文开头的「第三种是A/B测试」
→ AI 知道 Chunk 2 在整个文章中的位置和逻辑关系
→ 翻译时能正确使用「其次」「此外」等衔接词
3.3 分块算法详解
Step 1: 解析 Markdown 文档 → 提取所有 `##` 章节边界
Sections: [## 概述, ## 方法一, ## 方法二, ## 总结]
Step 2: 从第一个章节开始累积 token 数
在不超过 MAX_TOKENS_PER_CHUNK 的前提下，尽量装更多完整章节
Step 3: 每个块的前后各保留 1 句重叠上下文
→ 前一个块的结尾 1 句 → 当前块知道「前面说了什么」
→ 后一个块的开头 1 句 → 当前块知道「后面要说什么」
Step 4: 所有块翻译完成后 → 按顺序拼接（重叠部分只保留当前块的翻译）
🔑 设计要点：Token 感知分块本质上是一个「在 token 限制下最大化语义完整度」的贪心算法。它的核心约束不是「填满 token 预算」，而是「每个块必须是语义完整的」——宁可少翻几个章节，也不把一个章节砍成两半。
4. 三种翻译模式 —— 不同场景不同深度
4.1 为什么不是一刀切的「全模式翻译」？
场景 A：用户在聊天中发了句英文问「What does this error mean?」
→ 只需要快速翻译 → 不需要分析、不需要审校、不需要润色
→ 四步精翻 = 杀鸡用牛刀（费时间、费 token）
场景 B：用户要发布一篇中英文双语技术博客
→ 需要出版级质量 → 快速翻译不够
→ 需要分析-翻译-审校-润色四步
4.2 模式矩阵
| 模式 | 步骤 | 适合场景 | Token 成本 | 质量 |
|---|---|---|---|---|
| 快速翻译 | 直接翻译 | 短文本、聊天消息、快速理解 | 低 | 可用 |
| 普通模式 | 分析 → 翻译 | 文章、博客、一般文档 | 中 | 好 |
| 精细翻译 | 分析 → 翻译 → 审校 → 润色 | 出版级文档、官网文案、品牌内容 | 高 | 优秀 |
4.3 精细翻译的四步详解
Step 1: 分析（Analysis）
「这是一篇技术博客，目标读者是中级开发者，语气偏 informal，
涉及 Python 和 React 两个技术栈，有 3 个代码示例...」
→ AI 先理解文档的性质、受众、风格
Step 2: 翻译（Translation）
基于分析结果，按三分类系统翻译 TRANSLATABLE 内容
保留 PRESERVE 内容
对 SELECTIVE 内容逐个判断
Step 3: 审校（Review）
「检查：术语一致性（API 前后翻译一致吗？）、
代码块是否完整保留、URL 是否没有变动、
中英文混排标点是否正确...」
→ AI 自己审查自己的翻译质量
Step 4: 润色（Polish）
「优化：让译文读起来像母语写作，而不是翻译腔。
把『你应该使用这个工具因为它能帮助你去完成你的工作』
改成『这个工具能帮你高效完成工作』」
→ 去翻译腔，追求自然流畅
🔑 设计要点：三种模式不是「好/更好/最好」的递进——它们对应不同的使用场景和成本预算。快速翻译不是「偷懒版」——对于聊天消息，它恰好是「正确版」。模式选择的核心原则：用正确的工作量做正确的事（和 L1-02 的「不问用户压缩多少」是同一设计哲学）。
5. 翻译风格与术语管理
5.1 9 种翻译风格
Skill 支持 9 种翻译风格——因为「把英文翻译成中文」只是翻译的一半，「用什么语气翻」是另一半：
| 风格 | 适用场景 | 特征 |
|---|---|---|
| storytelling | 品牌故事、案例 | 像讲故事，有情感 |
| formal | 法律、合同 | 严谨、专业 |
| technical | 技术文档 | 精确、术语一致 |
| literal | 学术论文 | 逐句对应、不添加 |
| conversational | 博客、社交媒体 | 像聊天 |
| marketing | 广告、文案 | 有说服力、行动驱动 |
| academic | 研究论文 | 规范引用、学术语气 |
| creative | 文学、诗歌 | 意境优先于字面 |
| minimalist | UI/UX 文案 | 极简、可操作 |
5.2 术语表 —— 保证翻译一致性
文档中反复出现的专业术语，前后翻译不一致是最常见的质量问题：
没有术语表：
第 1 章：machine learning → 「机器学习」
第 3 章：machine learning → 「机械学习」
第 5 章：machine learning → 「ML」
→ 读者困惑：这三个是同一个概念吗？
有术语表（本 Skill 支持）：
EXTEND.md 中定义：
glossary:
"machine learning": "机器学习"
"API": "API"（不翻译）
"frontend": "前端"
"Kubernetes": "Kubernetes"（不翻译）
→ 全文翻译一致，专业可信
🔑 设计要点：术语表是翻译 Skill 的「质量地板」——它不保证译得优美，但保证译得一致。对于技术文档，一致性往往比优美更重要。
6. 结构拆解：格式保留型翻译 Skill 模板
从 L2-03 提取「格式保留型内容变换」Skill 的通用模板：
格式保留型内容变换 Skill 模板
核心特征
→ 输出 = 输入的同格式版本（格式不变，内容变换） → 核心挑战 = 区分「该变」和「不该变」的内容 → 长内容需要智能分块（保留语义完整）
通用结构
Content Classification（内容分类）
[PRESERVE] — 绝对不碰
- 代码块（Fenced + Inline）
- URL 和文件路径
- HTML（HTML：网页标记语言） 标签和属性
- 数字、日期、ID
[TRANSLATABLE] — 应该变换
- 标题（H1-H6 的文字）
- 正文段落
- 表格内容
- 列表项
[SELECTIVE] — 视情况决定
- YAML frontmatter 各字段
- tags（可翻可不翻）
- alt text
Chunking Strategy（分块策略）
- 按语义边界切分（不按字符数）
- 保留块间上下文（前后各 1 句）
- Token 预算管理（不超限 + 尽量装完整单元）
Mode System（模式系统）
Mode 1: 快速模式（直接变换 — 短内容） Mode 2: 标准模式（分析 → 变换 — 一般内容） Mode 3: 精细模式（分析 → 变换 → 审校 → 润色 — 出版级）
Quality Assurance
- 术语一致性（术语表）
- 格式完整性（PRESERVE 是否真的被保留了）
- 风格一致性（全文同一风格）
什么时候用格式保留型？ → 当需要在改变内容的同时保护特定信息结构时：翻译（改变语言，保护格式）、代码转文档（改变形式，保护逻辑）、Markdown 转 HTML（改变格式，保护结构）——任何「格式不变、内容变」或「内容不变、格式变」的场景。
格式保留型与 L1-11 逐字段分析型的关系：
| L1-11 逐字段分析型 | L2-03 格式保留型 | |
|---|---|---|
| 分析对象 | 表单的每个字段 | 文档的每个内容单元 |
| 核心分类 | 标签/类型/占位符/验证/必填 | TRANSLATABLE/PRESERVE/SELECTIVE |
| 设计思想 | 每个字段都有成本 | 每个内容单元都有分类 |
7. 电商案例：1688商品标题跨境多语言上架
🛒 实战案例：某家居百货卖家在 1688 上选了 80 款收纳用品（收纳盒、置物架、挂钩），准备同步上架到日本乐天、韩国 Coupang、美国亚马逊三个跨境店铺。运营需要把 80 个商品标题从中文翻译成日文、韩文、英文。直接丢给谷歌翻译的后果——「北欧风简约铁艺厨房置物架」翻成「Nordic style simple iron art kitchen shelf」，老外看完不知道这是什么东西。
用翻译 Skill 搭建跨境标题翻译流水线：
Step 1：术语表建立
- 材质术语：铁艺 → iron/metal（非 literal "iron art"）、亚克力 → acrylic、PP 塑料 → polypropylene
- 风格术语：北欧风 → Scandinavian style（日文：北欧風）、简约 → minimalist
- 场景术语：厨房置物架 → kitchen shelf/kitchen organizer（不同平台用不同词）
EXTEND.md中定义 glossary（45+ 术语，确保 80 个商品标题翻译一致）Step 2：内容三分类
- TRANSLATABLE：商品标题中的品类名、功能词、风格词
- PRESERVE：规格参数（尺寸 30×20×15cm、承重 5kg）、材质标号（304 不锈钢）、SKU 码
- SELECTIVE：品牌名（保留中文拼音还是意译，视目标市场策略而定）
Step 3：模式选择
- 日本乐天上架标题 → 精细翻译（日本消费者对描述准确度要求极高，且标题结构完全不同于中文：中文堆砌关键词，日文要求完整句子）
- 韩国 Coupang → 普通模式（韩文标题结构接近中文，可基础翻译后微调）
- 美国 Amazon → 精细翻译（英文标题有严格的字符限制和格式规范，需要分析和审校）
效果：
80 个商品 × 3 种语言 = 240 个标题，翻译时间从人工 5 天 → 4 小时（含术语表建立 2 小时）
翻译成本：约 $35（API 费用）vs 外包翻译公司 ¥2,400（¥10/标题 × 240）
术语一致性：100%（「收纳盒」在中日韩英版本中统一，不出现日文版叫「収納ボックス」韩文版叫「보관함」英文版却叫 "storage container" 的混乱）
Amazon 标题字符违规率：0%（精细翻译模式自动校验标题 ≤ 200 字符）
日本乐天店铺上线首月自然搜索曝光 1.2 万次（术语准确的标题在目标市场搜索引擎中排名更好）
🔑 启示：跨境翻译最怕的不是翻译腔，而是「术语不一致」——同一个产品在三个国家叫三个不同的名字，用户搜不到、比不了、不敢买。三分类系统 + 术语表 + 平台标题规范校验 = 跨境上架不必再人工逐条翻译校对。
8. 掌握检验
Q1：Token 感知分块为什么必须按 Markdown 章节边界（## 标题）切分，而不是按字符数暴力切割？
- A) 按章节切分渲染速度更快
- B) 按字符数切割会切断句子和语义，导致翻译不准
- C) Markdown 解析器不支持按字符数切割
- D) AI 模型只能理解以
##开头的内容
Q2：格式保留策略将内容分为哪三个类别？
- A) 中文、英文、其他语言
- B) 标题、正文、图片
- C) [TRANSLATABLE] 可翻译、[PRESERVE] 保留、[SELECTIVE] 选择性翻译
- D) 短文本、中文本、长文本
Q3：以下哪一项在翻译时应该标记为 [PRESERVE]（完全不碰）？
- A) 正文段落中的产品描述
- B)
## 产品特色中的标题文字 - C)
https://example.com/my-product这个 URL - D) YAML frontmatter 中的
title字段
Q4：课程中提到的三种翻译模式不包括以下哪一种？
- A) 快速翻译（适合短文本）
- B) 普通模式（分析后翻译，适合文章博客）
- C) 逐词直译（字对字翻译，适合法律文档）
- D) 精细翻译（分析-翻译-审校-润色四步，适合出版级）
Q5：为什么翻译长文档时要「前后块各保留 1 句上下文」？如果不保留会发生什么？举一个具体的例子。
Q6：一段 Markdown 包含以下内容，请分别标注每部分应属于哪个格式类别（TRANSLATABLE / PRESERVE / SELECTIVE）：
# 产品介绍 ← ？
正文：这款耳机采用... ← ？
 ← ？
```python print("hello") ``` ← ？
title: 我的产品 ← ？（frontmatter）
slug: my-product ← ？（frontmatter）
9. 答案
点击查看答案
Q1：B — 按字符数切割会把一个完整句子拦腰截断（如「本文介绍了三种方法。第一种是」），AI 只看到半句无法准确翻译。按章节边界切分保证每个块的语义完整，这是翻译质量的基石。
Q2：C — [TRANSLATABLE] 标记正文段落和标题文字（该翻的）；[PRESERVE] 标记代码块、URL、图片路径、HTML 标签（神圣不可侵犯的）；[SELECTIVE] 标记 frontmatter 中需要判断的字段（如 title 翻译、slug 保留）。
Q3：C — URL 被翻译后链接会直接 404（如 https://example.com/my-product 变成 https://example.com/我的产品）。代码块也同样不可碰——print("hello") 翻译成 打印("你好") 代码直接报废。
Q4：C — 课程中的三种模式是快速翻译、普通模式、精细翻译。「逐词直译」不是该 Skill 支持的模式；实际上原 Skill 强调「重写而非直译」，力求译文读起来如同母语写作。
Q5：长文档分块后每个块独立翻译，如果不保留前后各 1 句上下文，块与块之间的翻译可能断裂——比如前一块结尾说「以下是三个原因」，后一块开头直接列原因，翻译时没有上文可能把原因翻成不相关的独立陈述。保留上下文就像给每个翻译块一个「回忆」，让块间过渡自然。
Q6：# 产品介绍 → TRANSLATABLE（标题文字该翻）；正文段落 → TRANSLATABLE（正文该翻）； → PRESERVE（图片路径不能碰）；代码块 → PRESERVE（代码不能碰）；title: 我的产品 → SELECTIVE（title 翻译）；slug: my-product → SELECTIVE（slug 原样保留，英文 slug 是 URL 的一部分）。
（5/6 通过）
10. 延伸阅读
- [[L2-04-营销创意轰炸机|下一课：营销创意轰炸机]] — SKILL.md vs references/ 内容拆分设计
- [[L1-11-表单转化率优化|L1-11：表单优化]] — 回顾「逐字段分析」思维（三分类的前身）
- [[../Level1-新手村/L1-03-产品图流水线|L1-03：产品图流水线]] — 回顾「流水线设计」（翻译的 Step 1→4 也是流水线）
评论区
共 0 条评论