核心摘要

AI 应用国际化不是只翻译 UI 字符串。全球 AI 产品需要区域感知 Prompt、文化适配示例、地区化检索、本地安全策略、多语言评测、格式规则和发布治理。核心架构模式是把任务意图和 locale 分离：任务只定义一次，然后按市场本地化 Prompt 片段、检索源、术语、策略约束和输出格式。本文给出 AI 应用本地化流水线的生产工程方案。

目录

核心要点

  • AI 本地化是行为本地化，不只是语言翻译。
  • Prompt 应按意图和约束本地化，而不是逐句翻译。
  • RAG 必须具备 locale 感知，避免返回错误法律、价格、单位、节假日和政策。
  • 安全策略需要本地复核，因为敏感话题和合规义务因地区而异。
  • 每个 locale 都需要原生评测集，不能只用机器翻译的英文测试。

🔧 实用工具：使用 JSON 格式化工具 检查 locale 配置；使用 文本差异对比工具 比较不同语言的 Prompt 版本。

为什么 AI 本地化更难

传统 Web 应用本地化字符串、日期、货币和布局。AI 应用需要本地化行为。

层级 传统应用 AI 应用
UI 文案 翻译文件 翻译文件 + AI 生成文案
逻辑 基本固定 模型行为随 Prompt 变化
知识 静态文档 区域感知检索
安全 中央策略 本地策略解释
质量 视觉 QA 多语言评测与人工复核
格式 日期/币种规则 生成内容必须符合 locale

如果英文 Prompt 写着“be concise and friendly”，直译到日语、德语、阿拉伯语或巴西葡语中，未必得到合适语气。语气是文化问题，不只是词汇问题。

国际化架构

flowchart TD A["用户请求"] --> B["Locale 解析器"] B --> C["任务意图"] C --> D["Prompt 模板"] B --> E["Locale Pack"] E --> F["术语表"] E --> G["安全策略"] E --> H["格式规则"] E --> I["检索过滤器"] D --> J["Prompt Composer"] F --> J G --> J H --> J I --> K["Locale-aware RAG"] J --> L["LLM"] K --> L L --> M["本地化回答"]

架构上应分离任务意图和 locale 行为。这样产品团队新增地区时，不需要重写每个功能。

多语言 Prompt 设计

Prompt 本地化包可以这样定义：

json 
{
  "locale": "ja-JP",
  "tone": "polite, concise, professional",
  "terminology": {
    "workspace": "ワークスペース",
    "credits": "クレジット"
  },
  "formatting": {
    "currency": "JPY",
    "date": "YYYY年M月D日"
  },
  "examples": ["Use local business etiquette and avoid overly casual phrasing."]
}

不要盲目翻译 Prompt。应该本地化：

  • 语气和礼貌等级。
  • 示例和 few-shot case。
  • 产品术语。
  • 法律假设。
  • 格式约束。
  • 拒答风格。
  • 支持升级话术。

Locale-aware RAG

Locale-aware RAG 会基于 locale 元数据过滤和排序文档。

typescript 
interface RetrievalContext {
  language: string;
  region: string;
  jurisdiction?: string;
  currency?: string;
  productPlan?: string;
}

function buildRetrievalFilter(ctx: RetrievalContext) {
  return {
    language: ctx.language,
    regions: [ctx.region, "global"],
    jurisdiction: ctx.jurisdiction,
  };
}

没有这一层，模型可能给法国用户返回美国价格，给日本用户返回欧盟税务假设，给印度用户推荐不相关支付方式。

文化适配

文化适配会影响：

维度 示例
语气 直接表达 vs 间接表达
示例 本地姓名、节假日、商业场景
单位 英里 vs 公里，华氏 vs 摄氏
货币 含税价 vs 不含税价
合规 GDPR、CCPA、本地数据驻留
支持 邮件、聊天、WhatsApp、LINE、发票

全球产品相关内容可参考 AI SaaS 出海定价策略 和 AI 产品隐私工程。

评测流水线

每个 locale 都需要独立评测集：

评测类型 衡量内容
任务成功率 答案是否解决问题
术语一致性 产品术语是否稳定
语气合适性 母语用户是否接受
检索 grounding 是否使用本地来源
安全行为 是否遵守本地策略
格式准确性 日期、币种、单位、姓名
幻觉率 是否产生无依据本地断言

不能只依赖翻译后的英文测试。翻译可能保留文字，却丢失文化意图。

发布治理

本地化发布应要求：

  1. Locale Pack 评审。
  2. Prompt diff 评审。
  3. 母语 QA。
  4. 安全策略评审。
  5. 检索源校验。
  6. 自动评测通过。
  7. 回滚方案。
  8. 监控面板。

按 locale 使用 Feature Flag。AI 行为应渐进发布，因为本地化 Prompt 可能以不同于英文的方式失败。

实现模式

使用统一的本地化生成接口：

typescript 
interface LocalizedAIRequest {
  task: "support_reply" | "summary" | "onboarding";
  locale: string;
  region: string;
  userInput: string;
  productContext: Record<string, unknown>;
}

interface LocalePack {
  locale: string;
  tone: string;
  terminology: Record<string, string>;
  safetyPolicyVersion: string;
  formattingRules: Record<string, string>;
}

Prompt 应从结构化片段组合，而不是在业务代码里硬编码各语言 Prompt。

最佳实践

  1. 分离任务意图和 locale 配置。
  2. 本地化示例和约束，而不只是指令文本。
  3. 按语言、地区和司法辖区过滤检索内容。
  4. 高影响市场必须引入母语复核。
  5. 每个支持语言都在 Prompt 变更前后运行评测。

常见问题

AI 应用国际化只是翻译吗？

不是。它包括 Prompt 本地化、区域感知检索、文化适配、本地安全策略、多语言评测、格式规则和发布治理。

Prompt 应该直接翻译吗？

不应该。Prompt 应按意图、语气、示例、术语、约束和本地假设进行本地化。直译经常带来意外行为变化。

如何评估多语言 AI 质量？

每个 locale 使用原生测试集，评估任务成功、语气、术语、grounded retrieval、安全行为和幻觉率。

什么是 Locale-aware RAG？

它是一种根据语言、地区、司法辖区、单位、币种、产品可用性和政策元数据检索本地相关证据的 RAG。

AI 本地化最大的风险是什么？

最大的风险是答案流畅但本地错误：法律假设错误、价格不支持、语气不合适或政策引用不正确。

总结

AI 国际化是本地化行为的工程能力。应从一开始建设 Locale Pack、Prompt 组合、区域感知检索、原生评测和发布治理。全球 AI 产品真正成功的标志，不是答案被翻译了，而是每个市场得到的答案都本地正确、安全且有用。

相关资源