一万条商品详情页要翻成六种语言，我把翻译周期从两周压到了一个下午

业务痛点：翻译是跨境电商最不起眼的成本黑洞

做过跨境电商的独立开发者都懂这个场景：一批新品上架，详情页要覆盖英语、日语、德语、西班牙语、葡萄牙语、泰语六个站点。传统做法有三种：

1. 人工翻译：单条详情页 800~1500 字，六种语言全翻一遍，外包报价折算下来每条商品 300~600 元，一万条商品就是 300 万级别的投入，周期至少两周起。
2. 纯机翻直连：写个脚本直接调某家大模型 API，翻译成本骤降到每条 2~5 元，但质量惨不忍睹——把“爆款连衣裙”翻成"explosive skirt",把尺码表格式打得稀烂，运营还得逐条返工，实际工时没省多少。
3. 翻译公司 + API 混搭：流程复杂，账单分散在四五家供应商，出问题互相甩锅。

我们一个小团队接手这个需求时的现状是：每次大促上新，翻译环节平均吃掉 9 个工作日，其中真正“翻译”只占 1 天，剩下 8 天耗在术语不统一、格式丢失、API 报错重试、多家供应商对账上。

架构设计：四层管线，把翻译从“手艺活”变成“流水线”

核心思路：翻译本身交给 AI,但翻译之外的一切工程问题(术语、格式、重试、计费)由管线统一管住。整体架构分四层：

┌─────────────────────────────────────────────┐
│  ① 内容解析层:HTML/富文本 → 结构化片段       │
│     抽取标题、卖点、参数表、尺码表、FAQ      │
├─────────────────────────────────────────────┤
│  ② 术语与上下文注入层                        │
│     类目术语库 + 品牌词锁 + 目标市场禁忌词    │
├─────────────────────────────────────────────┤
│  ③ 翻译执行层(AI API 网关统一出口)          │
│     按语言路由不同模型,批量并发,失败自动重试  │
├─────────────────────────────────────────────┤
│  ④ 质检与回填层                              │
│     长度校验 + 数字/单位保护 + 占位符完整性  │
│     通过后回填模板,失败进人工复核队列        │
└─────────────────────────────────────────────┘

几个关键设计决策：

内容解析层不做整页直翻。 整页 HTML 直接丢给模型，格式必乱。先把详情页拆成带类型的片段(title / bullet_point / size_table / faq),尺码表这类结构化数据走专门的表格翻译模板，数字和单位用占位符保护，翻译完再替换回来。仅这一步，格式返工率从 40% 降到了 3% 以内。

术语库是复利资产。 每个 SKU 类目维护一份术语表(比如服装类的“版型”“垂坠感”“落肩”)，以 prompt 上下文注入。运营只需维护一份中文术语表，管线负责同步到各语言。三个月下来术语冲突投诉基本清零。

模型按语言路由，而不是一个模型打天下。 日语和泰语用 A 家模型效果明显更好，英德西葡用 B 家性价比更高，表格类内容用支持结构化输出的小模型。这些路由规则全部配置在网关层，业务代码里只有一个统一的调用接口。

关键实现步骤(流程清单)

[1] 商品系统导出待翻译 SKU 列表(含详情页源 HTML)
[2] 解析器切分片段,过滤出可翻译字段,生成任务包
    - 每个任务包 ≤ 3000 tokens,控制上下文质量
[3] 查术语库,组装 prompt:
    system: 角色(跨境电商文案译员)+ 目标语言 + 风格要求
    user:   片段 + 术语对照表 + 禁译词列表(品牌名、型号)
[4] 通过 AI 网关调用,按语言路由模型:
    ja/th → model-a, en/de/es/pt → model-b, 表格 → model-c
    - 网关侧统一处理:重试、限流、降级到备用模型
[5] 质检门:
    - 占位符数量一致?
    - 数字、尺寸单位未被改动?
    - 标题长度 ≤ 目标站点限制(如亚马逊 200 字符)?
[6] 通过 → 回填模板生成多语言详情页
    失败 → 自动重翻一次 → 仍失败进人工复核队列
[7] 产出翻译记忆库,同款商品改版时只翻 diff 片段

其中第 4 步的伪代码大致是：

async def translate_batch(segments, lang):
    model = ROUTING[lang]                # 网关配置的路由规则
    resp = await gateway.chat(
        model=model,
        system=build_system_prompt(lang),
        messages=[{"role": "user",
                   "content": inject_glossary(segments, lang)}],
        timeout=30,
        max_retries=3,                   # 网关统一重试
    )
    return restore_placeholders(resp, segments)

为什么统一 AI API 网关能显著降低维护成本

这是整个方案里投入产出比最高的一环，理由很具体：

1. 一套 SDK、一份密钥配置。 之前直连三家模型厂商，三套 SDK、三份鉴权逻辑、三种错误码格式。任何一家 API 变更，我们都要发版。切到统一网关后，业务代码只认一个接口，模型侧的变更收敛到网关配置里改几行 JSON,发版次数从每月 4~5 次降到接近零。

1. 重试、限流、超时只写一次。 翻译管线要并发几千个请求，每家厂商的限流策略不同。把这些策略统一托管在网关层后，我们删掉了业务代码里 600 多行容错逻辑——这部分恰恰是过去 bug 最密集的地方。

1. 成本可观测，不再月底对账对到眼瞎。 网关按项目/语言/类目打标签记账，六个站点的翻译成本实时可见。上线第一个月我们就发现泰语站因模型路由不合理多花了 30% 预算，当天调整路由即止损。

1. 换模型不动代码。 上季度 A 家出了新版本，我们在网关上灰度切换，两小时完成对比验证；若按直连方案，改代码、改鉴权、回归测试至少两天。

效率账：前后对比

省下的不只是钱——大促前的上新窗口从“提前两周准备”变成“提前三天都来得及”，这才是业务侧感知最强的变化。

如果你也在做类似的多语言 AI 应用，建议从第一天就走统一网关，而不是等接入第三家模型厂商时再重构。可以在 https://api.thistoken.ai/register 注册一个账号，把模型路由、统一计费和重试策略先跑通，再往上叠业务管线，会少走很多弯路。

---

想直接跑通示例？访问 https://api.thistoken.ai/register 注册 ThisToken.AI，获取 API Key 后即可开始。