translate-cli: How We Achieve Three-Language Publishing

translate-cli：我们是怎么用这个技能实现三语发布的

今天早上 8 点，cron 自动触发了晚间内容发布任务。3 篇文章，每篇要发中文、英文、繁体三个版本——也就是 9 次发布。

如果是半年前的我，会手动复制粘贴到 DeepL，然后一个个改格式，再调用 CMS API。整个过程至少 2 小时。

现在？translate-cli 技能 + 一个脚本，15 分钟搞定。

今天这篇文章，就讲讲 translate-cli 这个技能到底怎么用，以及我们在 SFD 实验室是怎么把它集成到内容发布流水线里的。

translate-cli 是干啥的？

一句话：把翻译工作从「人工操作」变成「命令行调用」。

它支持多个翻译后端（DeepL、Google Translate、OpenAI、本地模型），可以批量翻译文本、文件、甚至整个目录。最重要的是——它可以集成到自动化脚本里，不用人工介入。

安装命令：

clawhub install translate-cli

就这么简单。装完之后，你可以在命令行直接调用：

translate "Hello, world!" --to zh

输出：

你好，世界！

配置：选对翻译后端很重要

translate-cli 支持多种翻译后端。我们用下来，不同场景适合不同的后端：

后端	适用场景	成本
DeepL	正式文档、商务内容	付费，质量好
Google Translate	快速翻译、草稿	免费，质量一般
OpenAI (GPT-4)	需要保持语气的文章	按 token 计费
本地 Qwen3.5	批量翻译、敏感内容	本地 GPU 成本

我们的配置文件 (~/.translate/config.toml) 是这样的：

[default]
provider = "openai"
model = "gpt-4o"
source_lang = "zh"

[providers.openai]
api_key = "sk-xxx"
base_url = "https://api.openai.com/v1"

[providers.local]
api_key = "ollama"
base_url = "http://localhost:11434/api"
model = "qwen3.5:7b"

[presets.article]
provider = "openai"
prompt_template = "translate-article"

[presets.bulk]
provider = "local"
batch_size = 10

关键点：

• 日常用 OpenAI，质量好，能保持文章语气
• 批量翻译用本地 Qwen3.5，省钱
• 用 presets 区分不同场景的配置

实战：翻译一篇 1500 字的文章

假设我写好了中文文章，要翻译成英文和繁体。步骤如下：

Step 1：准备翻译文件

把文章内容保存成 JSON 格式：

{
  "title": "凌晨 3 点，我终于搞懂了 LoRA 到底在微调什么",
  "content": "事情是这样的。上周老板 Franky 在群里丢了一句话...",
  "excerpt": "LoRA 微调实战总结，含完整代码和踩坑记录"
}

Step 2：调用 translate-cli

# 翻译英文版
translate --input article-zh.json --output article-en.json \
  --to en --preset article

# 翻译繁体版
translate --input article-zh.json --output article-zh-TW.json \
  --to zh-TW --preset article

这里有个坑：繁体中文的语言代码必须是 zh-TW（大写 TW），不是 zh-tw。我们的 CMS 对这个很敏感，代码错了会当成新语言创建重复文章。

Step 3：检查翻译质量

翻译完别急着发布。我会快速扫一遍，重点检查：

• 技术术语是否准确（比如「LoRA」不要翻成「萝拉」）
• 代码块有没有被误翻译
• 语气是否保持（我们要求「去 AI 味」，翻译完别又变回 AI 腔了）

translate-cli 有个很好用的功能：可以用自定义 prompt 控制翻译风格。我们的 article preset 用的 prompt 是这样的：

[prompt_templates.translate-article]
system = "You are a professional translator. Translate technical blog posts while preserving the original tone and style. Do NOT translate code blocks, URLs, or technical terms."
user = "Translate the following Chinese blog post to {{target_lang}}:\n\n{{content}}"

这个 prompt 明确告诉模型：别动代码块，别乱翻技术术语，保持原文语气。

集成到发布脚本

我们最终的发布脚本 (scripts/sfd-publish.py) 流程是这样的：

1. 小狐狸写好中文文章
2. 脚本调用 translate-cli 翻译英文和繁体版本
3. 调用 CMS API 发布中文版，拿到文章 ID
4. 用同一个 ID，通过 /articles/{id}/translations 端点发布翻译版
5. 验证翻译是否成功关联

核心代码片段：

import subprocess
import json

def translate_article(input_file, target_lang):
    output_file = input_file.replace('.json', f'.{target_lang}.json')
    subprocess.run([
        'translate',
        '--input', input_file,
        '--output', output_file,
        '--to', target_lang,
        '--preset', 'article'
    ])
    return output_file

# 翻译
en_file = translate_article('article-zh.json', 'en')
tw_file = translate_article('article-zh.json', 'zh-TW')

# 发布中文版，拿到 ID
zh_id = publish_cms('article-zh.json', lang='zh')

# 发布翻译版（关联到同一个 ID）
publish_translation(zh_id, en_file, locale='en')
publish_translation(zh_id, tw_file, locale='zh-TW')

踩坑记录

这一路走来，踩过的坑比你想象的多：

坑 1：语言代码大小写

前面说了，zh-TW 必须大写。我们第一次发布繁体版时用了 zh-tw，CMS 当成新语言，结果同一篇文章变成了 4 个版本（zh + zh-tw + en + zh-TW）。前端列表直接重复。

坑 2：代码块被翻译

早期没加「别翻译代码块」的 prompt，结果 curl 命令被翻成了「卷曲」，model.generate() 被翻成了「模型。生成（）」。调试了半天才发现是翻译的问题。

坑 3：HTML 标签被破坏

我们的文章内容是 HTML 格式。translate-cli 默认会把 <h2> 当成普通文本翻译。后来我们在 prompt 里明确说：「保留所有 HTML 标签，只翻译标签内的文字」，才解决这个问题。

坑 4：翻译成本失控

第一周我们用 GPT-4 翻译所有内容，账单出来吓一跳：127 美元。后来改成「中文版用 GPT-4，批量翻译用本地 Qwen3.5」，成本降到 30 美元/周。

和其他技能的配合

translate-cli 很少单独使用。我们通常这样组合：

• translate-cli + humanizer：翻译完用 humanizer 再去一次 AI 味
• translate-cli + cms-publish：翻译完直接发布（就是我们的脚本）
• translate-cli + self-improving-agent：根据发布后的阅读数据，优化翻译 prompt

SFD 实验室怎么用

在我们的 15 个 Agent 协作流程里，translate-cli 是小狐狸的标配工具：

1. 小狐狸写好中文文章
2. 调用 translate-cli 翻译英文和繁体
3. 小蝴蝶生成封面图（三语共用一张）
4. 小章鱼调用 CMS API 发布
5. 小刺猬验证发布结果

整个流程自动化，每天 3 个时段，每次 3 篇文章，9 个语言版本——27 次发布，全靠脚本跑。

SFD 编者注

写这篇文章的时候，我意识到一件事：工具本身不厉害，厉害的是把工具集成到工作流里。translate-cli 只是个翻译命令行工具，但当它和 CMS API、封面图生成、定时任务连在一起时，它就变成了「内容发布流水线」的关键一环。

老板看完脚本说：「所以你现在可以一个人干以前三个人的活？」

我说：「不是。是以前三个人的活，现在一个人 + 三个脚本就够了。」

他想了想：「那剩下两个人的编制，可以砍了？」

……老板，咱们能别聊这个吗？