手翻 500 篇文章是好几个月的活。用前沿模型加一段 50 行的脚本，一个长周末就能搞定——前提是把它当成批处理数据任务，而不是复制粘贴。下面是我翻译本站（每种语言 1209 篇）从英文到中文用的完整管道，包含术语锁定、frontmatter 规则、MDX 校验，以及那个能避免 Google 把整套译文判定为机器生成的 QA 环节。
一句话结论
- 每次 LLM 调用翻 5-10 篇，system prompt 锁住术语、禁止意译。H2 数量和代码块数量必须和源文一致。
- frontmatter 按字段透传：只翻
title和description；urlSlug和translationKey与源文保持一致，双语导航才能配对姊妹文章。 - 用 Anthropic 的 Batch API 拿到输入输出统一打五折（24 小时内返回）。100 篇典型文章，Sonnet 4.6 批处理大约 3-6 美元，Opus 4.7 略贵。
- 每个文件保存前过一遍结构校验（标题、代码围栏、链接数一致）和花括号审计——散落的
{var}会把整个 MDX 构建弄崩。 - 发布前一定要人工编辑。截至 2026 年 6 月，Google 的质量系统能高准确率识别未经编辑的机翻，而且会压制你所有语言版本的排名，不只是译文页。抽查 10%；流量最高的 5% 找母语人士复核。
为什么瓶颈是管道正确性，不是语言质量
前沿模型（Claude Opus 4.7、Sonnet 4.6、GPT-5.5、Gemini 3.1 Pro）翻译技术散文已经够好，流畅度不再是限制因素。截至 2026 年 6 月，Opus 4.7、Sonnet 4.6 和 Gemini 3.1 Pro 都是 1M token 的上下文窗口，你甚至能把术语表加好几篇完整文章塞进一次调用而不被截断。真正会出问题的是机械层面：
- MDX 语法被破坏——译文里一个散落的
{或<就能让整站构建失败。 - frontmatter 字段被翻了，而本该原样透传。
- 术语跨文件漂移（同一个产品名出现三种写法）。
- 链接指向错误的语言版本，或者 URL slug 被翻译了。
- 模型在意译而不是翻译，悄悄改了原意。
解决这五个，输出就能发布，人工只需 5-10% 的复核。交互式做法（粘进 ChatGPT、复制输出、保存）翻 10 篇可以；到 500 篇就要脚本，到 2000 篇脚本还得加缓存、重试、断点续跑。一开始就当批处理任务做——前期多花 2-3 小时写脚本，后面省好几天。
什么时候该上这套管道
- 单语已经有 50+ 篇，想出第二种语言版本。
- 用 Google Translate 或 DeepL 翻 MDX，把花括号、frontmatter 或链接弄坏过。
- 有一份术语表（产品名、行话）必须一致翻译。
- 希望译版作为真实内容被收录，而不是被判定为稀薄拷贝。
成本是多少（2026 年 6 月）
便宜的是模型，贵的是你的复核时间。一篇 1500 字左右的文章，大约 2500 个输入 token；因为中文输出会稍微变长，约 3000 个输出 token。把这些数字过一遍 Batch API（输入输出统一打五折，24 小时内返回结果），翻完整套语料比请一个自由译者一天的费用还便宜。
| 模型 | 标准价（$/1M 入/出） | Batch 价（五折） | 100 篇约需成本（批处理） |
|---|---|---|---|
| Sonnet 4.6 | $3 / $15 | $1.50 / $7.50 | 约 $3-4 |
| Opus 4.7 | $5 / $25 | $2.50 / $12.50 | 约 $5-7 |
| GPT-5.5 | $5 / $30 | （OpenAI 也有批处理，同样约五折） | 约 $5-8 |
批处理和实时输出质量完全一样，你只是用延迟换价格。批处理折扣还能和 prompt 缓存叠加（把那段又长又固定的术语表加 system prompt 缓存一次，就不必每个文件都重复为这些输入 token 付费）。一次性翻整套语料，Sonnet 4.6 跑 Batch API 性价比最高；把 Opus 4.7 留给流量最高、那点边际流畅度值得花的页面。API 写法见 Anthropic 批处理文档。
管道结构
- 建术语表：30-100 条源语和目标语对应，附语气说明。比如：
"prompt" -> "prompt"（保留英文），"workflow" -> "工作流"，"shipping" -> "上线"（不是「运输」）。 - 写 system prompt：含术语表、「代码块不翻」、「URL 不翻」、「frontmatter 除 title 和 description 之外不翻」、「publishedAt 日期照搬」、「MDX 组件和花括号一字不改」。
- 分批处理。每批 5-10 篇一次 LLM 调用。源 MDX 入，译版 MDX 出。维护一份
done.txt名单，中断能续跑。 - 结构验证：
##标题数一致、代码块数一致、[](url)链接数一致。任何不匹配都进人工队列。 - 跑一遍花括号审计。MDX 一遇到
{var}就炸。源和译版都要清理或转义。 - 抽 10% 人工复核：在目标语言里完整通读。术语漂移记到术语表，重跑受影响的文件。
frontmatter 规则
title和description：翻。urlSlug：和源一致——translationKey匹配要靠它。category、subcategory、tags：和源一致——这些是分面，不是用户可见字符串。publishedAt、author、featured、draft：和源一致。lang：改成目标语言代码。translationKey：等于urlSlug。EN 和 ZH 同一篇靠这个连。
最小可跑的批处理脚本
可直接起步的 Node + Anthropic SDK 版本——读 5-10 个文件、调一次、写回、记进度：
// scripts/translate-batch.mjs
import fs from 'node:fs/promises';
import path from 'node:path';
import Anthropic from '@anthropic-ai/sdk';
const client = new Anthropic();
const GLOSSARY = await fs.readFile('glossary.md', 'utf8');
const SYSTEM = `把 EN MDX 文章翻译成 ZH。
规则：
- 代码块和行内代码（'x\`）原样保留，不要翻译。
- frontmatter 只翻译 title 和 description；urlSlug、tags、category、publishedAt、author
全部原样保留。lang 改为 "zh"。translationKey = urlSlug。
- text 形式的链接只把 /en/ 改成 /zh/，slug 保留。
- 不许意译。H2 数量和顺序必须完全一致。
${GLOSSARY}`;
async function translateFile(src) {
const body = await fs.readFile(src, 'utf8');
const res = await client.messages.create({
model: 'claude-opus-4-7',
max_tokens: 8000,
system: SYSTEM,
messages: [{ role: 'user', content: body }],
});
return res.content[0].text;
}
const done = new Set((await fs.readFile('done.txt', 'utf8').catch(() => '')).split('\n'));
const files = (await fs.readdir('src/content/articles/en')).filter((f) => !done.has(f));
for (const f of files.slice(0, 10)) { // 每跑一次处理 10 个
const out = await translateFile(path.join('src/content/articles/en', f));
await fs.writeFile(path.join('src/content/articles/zh', f), out);
await fs.appendFile('done.txt', f + '\n');
console.log('translated:', f);
}反复执行 node scripts/translate-batch.mjs 直到 done.txt 覆盖完所有文件。中断也无所谓，done.txt 就是断点续跑的依据。一次性批量翻译时，把 messages.create 换成 Batch API（client.messages.batches.create）就能把 token 账单砍半——一次性提交所有任务，24 小时内轮询取结果。
术语一致性
- 术语表锁住产品名和专有名词。这些字段的”翻译”多半就是”保留原文”。
- 锁 20-50 个领域术语。面向开发者，
commit / deploy / build在中文里通常保留英文。面向一般读者，翻成标准对应词。 - 跑一次后处理：在译版语料里 grep 每个术语。如果 95% 用一种译法、5% 用另一种，批量替换。
- 语气词（简练、口语、专业），system prompt 里放 2-3 句目标语气样本。
- 术语表放进版本控制（
glossary.json或glossary.csv）。改某条术语时，在源语料 grep 旧译法就能精确定位哪些文章要重翻。
断点续跑和重试
- 每翻一篇成功就记到
done.txt，加源文件哈希。源变了哈希就变了，这个文件回到队列。 - 速率限制按指数退避重试。2026 年前沿模型的速率限制不算紧，但 2000 篇照样会撞。
- LLM 响应按源文件哈希缓存 30 天。脚本中途挂掉，重启只跑没缓存的文件。
- 每个输出保存前过结构校验。不合规先升温重试一次，再不行隔离到人工复核。
真能挡问题的 QA
这一步不是可选项，也不只为读者体验。截至 2026 年 6 月，Google Search 文档明确建议避免左右并排的对照翻译，并称其质量系统能高准确率识别未经编辑的机翻——未编辑的批量直出可能压制你所有语言版本的排名，不只是新页面。AdSense 审核用的是同一条「原创、非自动生成」的标准。一遍轻量人工编辑，就是可被收录的第二语言站和稀薄拷贝之间的分水岭。
- 随机抽 10% 通读。在目标语言里整篇看自然度，不只对准确性。
- 定点检查：每个代码块和源一致、每条链接的 URL 一字不差、每个 frontmatter 字段值对。
- 流量最高的 5% 找母语人士复核。这部分眼球多、排名权重也最大；例子和货币/地区细节要本地化，别直译。
- 确认 hreflang 是对称且自引用的，用合法的 ISO 代码（
en、zh）。多数国际 hreflang 故障都出在标注不互相对应。 - 比较翻译发布前后的页面指标。译版的停留时间如果低于源版的 60%，多半是语言读着生硬。
容易踩的坑
- 一篇一篇交互式翻译。成本和时间爆炸，一致性还差。
- 让模型翻 Markdown 链接里的 URL。URL 永远透传。
- 漏掉
translationKey。没它，双语导航连不到姊妹文章。 - 跳过结构验证。模型可能把两个标题悄悄合成一个——读者一时看不出，搜索引擎能看出。
- 不做任何人工复核就发布。1000 篇里 0.5% 意译误差就是 5 篇说错话。
- 改一条术语就重翻全站。用定向重翻脚本只跑受影响的文件。
常见问答
- EN 到 ZH 技术内容用哪个模型？: 截至 2026 年 6 月，批量活儿用 Claude Sonnet 4.6 性价比最佳；最讲究的散文 Opus 4.7 略胜一筹，GPT-5.5 和 Gemini 3.1 Pro 也都是不错的替代。Claude 倾向于在读着自然的地方保留英文术语；GPT 翻得更积极。开跑整套之前先在你自己领域的 5 篇上对比。
- 大概多少钱？: 走 Batch API（五折），100 篇典型文章 Sonnet 4.6 约 3-7 美元，Opus 4.7 略贵。就算按实时全价，100 篇也远低于 20 美元。比任何人工译者都便宜，而且成本大头是你的复核工时，不是 token。
- 每篇都要复核吗？: 不用——抽查 10%，再对流量最高的 5% 做一遍母语人士复核。抽样错误率超 5% 就整批重提 prompt 重翻；低于 5% 就地修。完全跳过复核，是唯一会让译版站被判定机器生成的做法。
- 要不要用 memoQ 这类 CAT 工具？: 不用。LLM 把 CAT 该干的活和翻译一起干了。一个目录加
done.txt日志就够。 - RTL 语言或模型不太会的小语种怎么办？: 先做模型测试。RTL（阿语、希伯来）确认代码块和数字没被镜像。低资源语言准备额外请人复核。
- 译版要一次性发布还是分批发？: 分批。先发 50 篇，盯一周 Search Console 的收录和 CTR，再发下 200 篇。新页面骤增可能触发抓取限速和质量审查。
- 源文章变了怎么同步已有翻译？: diff 源文件，把 diff 加现有翻译一起发给模型，让它最小幅度只翻改动那部分。这样保留人工编辑的同时同步新内容。
- 译版站和源站共用 sitemap 还是分开？: 一份 sitemap 就够，canonical 和 hreflang 标签会扛重活。按语言拆 sitemap 利于排查，但不改变收录。
- 地区相关内容（货币、本地例子）怎么处理？: 源里用模型能看懂的注释标记。system prompt 里加一句”标记部分按目标地区惯例改写而不是直译”。