上個月，我們交付了一個項目，通過傳統翻譯機構的話會花費 150,000 至 300,000 美元。我們只花了 660 美元。這是 118 頁翻譯成 30 種語言，大約每種語言 22 美元。不，這不是打字錯誤。不，質量也不是垃圾。

我想詳細說明我們是如何做到的——架構、工具、提示詞工程、質量保證流程，以及老實的權衡。因為便宜不一定意味著差，但它確實意味著你需要聰明地選擇在哪裡投入努力。

目錄

項目範圍

客戶是一家 B2B SaaS 公司，正在擴展到歐洲、亞洲和拉丁美洲市場。他們的營銷網站有 118 頁：登陸頁、功能頁、博客文章、法律頁和文檔。內容最初是英文。

目標語言包括常見的——西班牙語、法語、德語、日語、韓語、普通話——加上一些較難找到翻譯者的語言，如愛沙尼亞語、拉脫維亞語、立陶宛語和斯洛文尼亞語。共 30 種語言。

內容量的快速計算：

指標 數量
總頁面數 118
每頁平均字數 ~620
英文總字數 ~73,160
翻譯後總字數 ~2,194,800 (73,160 × 30)
語言 30
總成本 ~$660
每種語言成本 ~$22
每個翻譯詞的成本 $0.0003

為了參考，專業人工翻譯通常運費為每詞 0.10 至 0.30 美元，取決於語言組合。以 0.20 美元/詞的中點計算，我們每種語言需要 14,632 美元，總共 438,960 美元。即使是使用機器翻譯加輕度人工審查的預算機構也收費 0.05-0.08 美元/詞。

為什麼傳統翻譯這麼昂貴

我不想貶低翻譯行業。人工翻譯者做著令人難以置信的工作，對於某些內容類型，沒有替代品。但以下是導致成本高的原因：

按詞定價模式是為一個每個詞都需要人類認知努力的時代設計的。翻譯者每天可能處理 2,000-3,000 個詞的技術內容。在 73,160 個詞的情況下，每種語言需要 24-36 個翻譯者工作日。乘以 30 種語言，你需要 720-1,080 個人工作日。

稀有語言對成本更高。找一位高質量的英語到拉脫維亞語的技術翻譯者並不容易。供求關係起作用。

項目管理開銷是真實的。翻譯機構有項目經理協調翻譯者、審閱者和客戶之間的工作。這種開銷被計入每詞費率。

上下文切換費時。翻譯你的行銷文案的翻譯者需要理解你的品牌聲音、產品術語和受眾。這個啟動時間被攤銷到整個項目中，但它是真實的。

以上都不是浪費——只是昂貴而已。對於一家在這些地區驗證產品市場契合度之前測試新市場的公司來說，花費 40 萬美元於翻譯是難以接受的。

我們的 AI 翻譯架構

這是我們構建的系統。它不是單一的 API 調用——這是一個管道。

第 1 步：內容提取和分段

該網站使用 Next.js 構建，這讓我們的工作更輕鬆。所有內容都存放在結構化數據文件中（博客文章為 MDX、UI 字符串為 JSON，以及來自無頭 CMS 的結構化內容）。

我們編寫了一個腳本，抓取所有內容來源並生成規範化的中間格式：

interface TranslationUnit {
  id: string;           // 唯一鑰匙，如 "homepage.hero.title"
  source: string;       // 英文文本
  context: string;      // 出現位置（頁面、部分）
  type: 'heading' | 'paragraph' | 'ui-string' | 'legal' | 'meta';
  maxLength?: number;   // 用於空間有限的 UI 字符串
  glossaryTerms: string[]; // 在此單位中找到的產品特定術語
}

這很關鍵。你不想將整個頁面扔給 LLM 並期待最好的結果。將內容分段成翻譯單位讓你對上下文有控制權，讓你可以不同地處理不同的內容類型，並使以後的增量更新成為可能。

第 2 步：詞彙表和風格指南生成

在翻譯一個詞之前，我們構建了一個詞彙表。這包括：

  • 產品名稱（永遠不要翻譯這些）
  • 具有首選翻譯的技術術語
  • 品牌特定的短語
  • 每種內容類型的語氣指南

我們實際上使用了 Claude 通過分析英文內容並識別需要一致翻譯的術語來幫助構建初始詞彙表。然後我們讓客戶審查並批准。

第 3 步：使用 Claude API 批量翻譯

我們使用 Claude 3.5 Sonnet API（現在 Claude 4 Sonnet 可用，對此用途更好）進行實際翻譯。為什麼選擇 Claude 而不是 GPT-4o 或 Gemini？幾個原因：

  • 在一致地遵循複雜系統提示方面表現更好
  • 在我們的測試中，在羅曼語族和日耳曼語族中的輸出更自然
  • 200K 上下文窗口讓我們在每個請求中包含完整的詞彙表和風格指南
  • 定價對我們的用例很有競爭力

我們將翻譯單位成組批處理（20-30 個），按頁面和內容類型組織。每個批次包括詞彙表、風格指南以及文本出現位置的上下文。

import anthropic
import json

client = anthropic.Anthropic()

def translate_batch(units: list[dict], target_lang: str, glossary: dict, style_guide: str) -> list[dict]:
    system_prompt = f"""You are a professional translator specializing in {target_lang} 
    localization for B2B software companies.
    
    GLOSSARY (use these exact translations):
    {json.dumps(glossary[target_lang], indent=2, ensure_ascii=False)}
    
    STYLE GUIDE:
    {style_guide}
    
    RULES:
    - Preserve all markdown formatting
    - Never translate product names listed in the glossary
    - Adapt idioms naturally -- don't translate literally
    - For UI strings with maxLength, stay within the character limit
    - Output valid JSON matching the input structure"""
    
    user_prompt = f"""Translate the following translation units to {target_lang}.
    Return JSON array with same structure, replacing 'source' with 'translation'.
    
    {json.dumps(units, indent=2, ensure_ascii=False)}"""
    
    response = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=8192,
        system=system_prompt,
        messages=[{"role": "user", "content": user_prompt}]
    )
    
    return json.loads(response.content[0].text)

第 4 步：自動化質量檢查

翻譯後，每個單位都運行通過自動化檢查：

  • 格式保存：Markdown、HTML 標籤和變數是否完好無損？
  • 長度驗證：UI 字符串是否在其最大長度內？
  • 詞彙表合規性：產品名稱是否未翻譯？
  • 佔位符完整性：{variable} 佔位符是否完好無損？
  • 反向翻譯採樣：將 10% 的輸出翻譯回英文，並比較語義相似性

大約 3-4% 的翻譯單位失敗了一項或多項檢查，並使用特定的更正指示進行了第二次傳遞。

第 5 步：組合和集成

翻譯後的單位被組合回 Next.js 應用程式期望的格式——JSON 語言環境文件、已翻譯的 MDX 和 CMS 條目。我們使用 next-intl 進行路由和語言環境管理。

真正重要的提示詞工程

我見過人們將文本扔給 ChatGPT 並稱之為「AI 翻譯」。這給你大約 70% 的質量。70% 到 95% 之間的差距完全在於如何提示。

以下是改變局面的原因：

上下文至關重要

告訴模型「將其翻譯成法語」會給你通用輸出。告訴它「將這個英雄標題翻譯成法語，針對 B2B SaaS 登陸頁面的目標 IT 主管，保持自信但不攻擊的語氣」會給你可用的東西。

我們在每個請求中包括了頁面類型、目標受眾和每個內容塊的目的。

每種語言的少量示例

對於每種語言，我們創建了 5-10 個示例翻譯，展現我們想要的語氣。這些進入系統提示。對於我們在團隊或網路中有母語使用者的語言（約 30 種中的 8 種），我們讓他們編寫這些示例。對於其他的，我們生成它們，然後通過反向翻譯比較進行了改進。

詞彙表執行

這聽起來很明顯，但這是你能做的最有影響力的事情。沒有詞彙表，模型會將你的產品名稱「CloudSync」翻譯為某些語言中「雲同步」的等價詞。它將在頁面上對同一功能使用不同的術語。不一致會損害信任。

分塊策略

我們發現一次翻譯 500-800 個詞，按頁面部分分組，會得到最好的結果。太小（個別句子）會失去上下文。太大（整個頁面）會導致輸出末尾的質量下降。

成本分解：22 美元花在哪裡

讓我們詳細說明金錢問題。

成本組件 每種語言 總計（30 種語言）
Claude API（翻譯） $16.40 $492.00
Claude API（質量保證/反向翻譯） $3.20 $96.00
Claude API（詞彙表生成） $0.80 $24.00
雜項 API 調用（重試、修正） $1.60 $48.00
API 總成本 $22.00 $660.00

這不包括構建管道的工程時間，大約 40 小時。但該管道現在是可重複使用的。當客戶添加新的博客文章時，將其翻譯成所有 30 種語言的成本約為 2-4 美元的 API 費用，並在他們的 CI/CD 管道中自動運行。

當時 Claude API 定價（使用 Claude 3.5 Sonnet）為每百萬輸入標記 3 美元，每百萬輸出標記 15 美元。使用 Claude 4 Sonnet，定價相當，但你會獲得更好的質量，這意味著更少的重試。

沒有母語使用者的質量保證

這是人們最懷疑的部分，老實說，他們應該懷疑。以下是我們的實際質量保證流程：

自動化檢查（捕捉 ~60% 的問題）

我提到的格式保存、長度和詞彙表檢查。這些是確定性的，會捕捉最尷尬的錯誤——破損的 HTML、缺失的變數、翻譯的品牌名稱。

反向翻譯比較（捕捉 ~25% 的剩餘問題）

我們使用不同的模型（GPT-4o）將每種語言的隨機 10% 樣本翻譯回英文，並將語義相似性與原始文本進行比較。如果反向翻譯明顯偏離，我們標記它以供審查。

母語使用者抽查（捕捉細微差別問題）

對於我們有母語使用者的 8 種語言（西班牙語、法語、德語、葡萄牙語、日語、韓語、普通話、荷蘭語），我們讓他們各審查 15-20 頁。他們的反饋很有啟發性：

  • 總體質量：信息內容得 8-9/10
  • 行銷標題：6-7/10（需要更多創意改編）
  • 技術文檔：9/10
  • 法律頁面：7/10（可接受但不完美）

基於他們的反饋，我們對行銷標題進行了第二次傳遞，使用更多的創意提示，這使這些標題達到了 8/10。

社區反饋循環

客戶在每個頁面上添加了一個小的「建議更好的翻譯」連結。在推出後的第一個月，他們在所有語言中收到了大約 140 項建議——大約是所有已翻譯內容的 0.04%。大多數建議都是文體偏好，而不是錯誤。

Next.js 中的技術實現

該網站使用 Next.js 應用程式路由器與 next-intl 進行國際化。以下是高級設置：

// middleware.ts
import createMiddleware from 'next-intl/middleware';

export default createMiddleware({
  locales: ['en', 'es', 'fr', 'de', 'ja', 'ko', 'zh', /* ... 23 種更多語言 */],
  defaultLocale: 'en',
  localePrefix: 'as-needed'
});

對於 無頭 CMS 集成，已翻譯的內容作為語言環境變體存儲。MDX 中的博客文章為每個語言環境獲得單獨的文件。UI 字符串存放在 JSON 消息文件中。

構建為所有語言環境/頁面組合生成靜態頁面。那是 118 × 31（包括英文）= 3,658 頁。使用 ISR（增量靜態再生成），這完全是可管理的。

值得注意的一點：我們以程式方式實現了 hreflang 標籤以用於 SEO。每個頁面都連結到其所有語言變體。這對於 Google 理解你的多語言網站結構至關重要。

// app/[locale]/layout.tsx
export function generateMetadata({ params: { locale } }) {
  const alternates = {
    languages: Object.fromEntries(
      locales.map(l => [l, `/${l}${pathname}`])
    )
  };
  return { alternates };
}

AI 翻譯的不足之處

如果我說 AI 翻譯是完美的，我就不誠實。以下是它一貫苦惱的地方：

行銷文字遊戲和雙關語。 如果你的標題在英文中很聰慧，AI 將要麼直譯它（失去聰慧），要麼嘗試目標語言的雙關語，而這不太著陸。我們手動重寫了約 15% 的行銷標題，具有創意方向。

文化改編。 翻譯和本地化不是同一件事。AI 不會知道你的美國案例研究關於「401(k) 提供者」在日本毫無意義。它不會在示例中將你的美元符號交換為本地貨幣。它不會知道紅色在中國意味著好運，但在西方意味著危險。這需要人類思維。

法律精確性。 對於服務條款和隱私政策，AI 翻譯會讓你達到 90%。但法律語言需要精確，在某些司法管轄區，你需要合法認證的翻譯。我們標記了法律頁面以供在客戶進行實際業務的 12 個市場進行專業審查（與進行探索性工作的其他 18 個相反）。

尊稱系統。 日語、韓語和泰語有複雜的正式性系統。AI 有時在同一頁面內混合正式和非正式登記。我們的詞彙表和風格指南有所幫助，但抽查捕捉了一些不一致之處。

性別同意在有性別的語言中。 法語、西班牙語、德語、阿拉伯語——當源英文是性別中立的時，AI 必須做出選擇。有時它是不一致的。我們的自動化檢查通過比較相關翻譯單位間的性別標記捕捉了大多數這些。

何時應該仍然支付人工翻譯

AI 翻譯每種語言 22 美元是正確的選擇，當：

  • 你正在測試新市場，需要速度而不是完美
  • 你的內容主要是信息性或技術性
  • 你有 10 多種目標語言（每種語言的節省複合）
  • 你需要經常翻譯（博客文章、變更日誌、文檔）

支付人工翻譯時：

  • 涉及法律責任（合同、合規文檔）
  • 品牌聲音至關重要（標語、活動）
  • 你在受監管行業（醫療、金融）
  • 你有 1-3 種目標語言和預算
  • 文化改編與語言準確性同樣重要

我們為大多數客戶發現的甜蜜點？AI 翻譯為大部分，人工審查為關鍵的 10-20%。這通常將總成本降至每種語言 50-100 美元，而不是 22 美元，但所有內容類型都具有近人類質量。

如果你正在考慮多語言網站構建，與我們聯絡——我們已在多個項目中改進了這個管道，並且可以將其適應於你的堆棧，無論是 Next.js、Astro 或其他框架。檢查我們的 定價頁面 以了解我們如何評估國際化項目。

常見問題

AI 翻譯質量在 2025 年與人工翻譯相比如何？

對於信息和技術內容，差距已大幅縮小。在盲測中，母語使用者對 Claude 和 GPT-4o 翻譯的評級為大多數歐洲和東亞語言人工翻譯質量的 85-92%。對於創意行銷文案（70-80%）和法律文本（75-85%）而言，差距更大。對於拉脫維亞語或愛沙尼亞語等不那麼常見的語言，AI 質量實際上與你從預算人工翻譯機構獲得的相當，這些機構通常無論如何都使用機器翻譯加輕度編輯。

在 2025 年翻譯網站的最便宜方式是什麼？

最便宜的方法是直接 API 訪問 Claude 或 GPT-4o 等模型，成本約為 0.0002-0.0005 美元/詞。Weglot（15-50 美元/月）或 Lokalise 等服務每詞更昂貴，但為你處理基礎設施。Google Translate API 每詞更便宜（~每百萬字符 20 美元），但質量明顯低於最先進的 LLM。我們使用 Claude 的管道方法成本約為每個翻譯詞 0.0003 美元，包括質量保證傳遞。

AI 翻譯適用於阿拉伯語和希伯來語等從右到左的語言嗎？

是的，但你需要仔細處理技術實現。Claude 對阿拉伯語和希伯來語的翻譯質量很好——我們的阿拉伯語抽查得分為 8/10。更難的部分是在你的前端中實現 RTL 佈局。CSS 邏輯屬性（使用 margin-inline-start 而不是 margin-left）和適當的 dir="rtl" 屬性是必不可少的。計劃需要被鏡像的 UI 元素。

你如何為翻譯成 30 種語言的網站處理 SEO？

最重要的三件事是：在每個頁面上正確的 hreflang 標籤、特定於語言環境的 URL（如 /fr/ 或 /de/ 的子目錄效果很好），以及已翻譯的元數據（標題、描述、Open Graph 標籤）。我們以程式方式生成所有這些。別忘了向 Google Search Console 提交特定於語言環境的網站地圖。在推出 30 種語言網站後的 3 個月內，客戶看到來自非英文查詢的自然流量增加了 340%。

AI 可以翻譯包括技術術語的網站內容嗎？

這實際上是 AI 翻譯閃耀的地方。技術術語通常是一致的且定義明確的，這對模型的優勢發揮作用。關鍵是構建你特定術語的詞彙表，並附上批准的翻譯。沒有詞彙表，模型可能會以三種不同的方式翻譯「部署管道」。有了詞彙表，它是岩石般堅實的一致。

AI 翻譯整個網站需要多長時間？

我們的管道在大約 6 小時的計算時間內將所有 118 頁翻譯成所有 30 種語言，運行並行 API 請求且有速率限制。構建管道的工程時間約為第一個項目的 40 小時。使用相同管道的後續項目需要 8-15 小時的工程時間用於設置和自訂，加上計算時間。

當你需要更新已翻譯網站上的內容時會發生什麼？

這是分段翻譯單位方法大幅付出代價的地方。當頁面更改時，我們將翻譯單位與先前版本進行差異分析。只有更改或新單位會被重新翻譯。在所有 30 種語言間更新博客文章花費便士並在 CI/CD 中自動進行。我們追蹤翻譯單位雜湊以精確了解什麼是陳舊的。

每種語言 22 美元對任何網站都現實，還是隻適用於某些類型？

22 美元的數字特定於我們項目的內容量（~73K 詞）和內容類型（B2B SaaS 行銷和文檔）。你的里程會有所不同。內容繁重的網站有 500K 詞可能每種語言花費 100-150 美元。一個簡單的 10 頁行銷網站可能花費每種語言 3-5 美元。成本與詞數線性擴展，稍微與複雜性擴展。固定成本是構建或配置管道的工程時間。