手翻 500+ 篇文章是 6 个月的活；管道搭对了，AI 一个长周末就能干完。这篇讲针对 MDX 内容站真正跑得通的批处理流程——包含术语锁定、frontmatter 处理，以及能挡掉容易翻车那 5% 的 QA 环节。
背景
当代前沿模型（Claude Opus 4.7、GPT-5.5、Gemini 3）翻译散文的质量已经够好，瓶颈不再是语言质量——而是管道正确性。真正的风险是：MDX 语法被破坏、不该翻的 frontmatter 字段被翻了、术语跨文件漂移、链接指向错语言版本、模型在意译而不是翻译。解决这五个，结果就能发布，人工只需要做 5-10% 的复核。
刚开始最容易踩的诱惑是交互式操作——把一篇粘进 ChatGPT、复制输出、保存。10 篇还行，500 篇就要脚本，2000 篇这脚本还得加缓存、重试、断点续跑。一开始就当 batch ETL 任务做，前期多花 2-3 小时写脚本，后面省好几天。
怎么判断你需要这个
- 单语已经有 50+ 篇，想出第二种语言。
- 用 Google Translate 或 DeepL 翻 MDX，括号、frontmatter 或链接坏过。
- 有一份术语表必须一致翻译（产品名、行话）。
- 希望译版能被 SEO 收录，不是稀薄拷贝。
一句话结论
每次 LLM 调用翻 5-10 篇一批，system prompt 锁住术语并禁止意译。frontmatter 按字段规则透传。最后跑一次 EN 和 ZH 结构对照（代码块数、标题数、链接数一致）。手工抽查 10%。100 篇大概 0.5-2 小时复核时间。
管道结构
- 建术语表：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 就是断点续跑的依据。
术语一致性
- 术语表锁住产品名和专有名词。这些字段的”翻译”多半就是”保留原文”。
- 锁 20-50 个领域术语。面向开发者，
commit / deploy / build在中文里通常保留英文。面向一般读者，翻成标准对应词。 - 跑一次后处理：在译版语料里 grep 每个术语。如果 95% 用一种译法、5% 用另一种，批量替换。
- 语气词（简练、口语、专业），system prompt 里放 2-3 句目标语气样本。
- 术语表放进版本控制（
glossary.json或glossary.csv）。改某条术语时，在源语料 grep 旧译法就能精确定位哪些文章要重翻。
断点续跑和重试
- 每翻一篇成功就记到
done.txt，加源文件哈希。源变了哈希就变了，这个文件回到队列。 - 速率限制按指数退避重试。2026 年前沿模型的速率限制不算紧，但 2000 篇照样会撞。
- LLM 响应按源文件哈希缓存 30 天。脚本中途挂掉，重启只跑没缓存的文件。
- 每个输出保存前过结构校验。不合规先升温重试一次，再不行隔离到人工复核。
真能挡问题的 QA
- 随机抽 10% 通读。在目标语言里整篇看自然度，不只对准确性。
- 定点检查：每个代码块和源一致、每条链接的 URL 一字不差、每个 frontmatter 字段值对。
- 流量最高的 5% 找母语人士抽检。这部分眼球多，质量影响最大。
- 比较翻译发布前后的页面指标。译版的停留时间如果低于源版的 60%，多半是语言不顺。
容易踩的坑
- 一篇一篇交互式翻译。成本和时间爆炸，一致性还差。
- 让模型翻 Markdown 链接里的 URL。URL 永远透传。
- 漏掉
translationKey。没它，双语导航连不到姊妹文章。 - 跳过结构验证。模型可能把两个标题悄悄合成一个——读者一时看不出，搜索引擎能看出。
- 不做任何人工复核就发布。1000 篇里 0.5% 意译误差就是 5 篇说错话。
- 改一条术语就重翻全站。用定向重翻脚本只跑受影响的文件。
常见问答
- EN 到 ZH 技术内容用哪个模型？: Claude Opus 4.7 和 GPT-5.5 都很强。Claude 倾向于自然处保留英文术语；GPT 翻得更积极。先在你自己领域的 5 篇上对比再定。
- 大概多少钱？: 100 篇大约 5-20 美元，看长度和模型。比任何人工译者都便宜，包括非母语的。
- 每篇都要复核吗？: 抽 10%。抽样错误率超 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 里加一句”标记部分按目标地区惯例改写而不是直译”。