发布 DIALØGUE 让我学到的多语言 AI 产品真相

AI 现在最诱人的能力之一，就是让你可以非常快地加语言。我很清楚这一点，因为我一直在这么做。我先是在 48 小时内给 DIALØGUE 增加了 5 种语言，然后又把整个博客存档在 4 天内翻译成了 10 种语言。

前两篇写的是速度。这一篇写的是速度覆盖不到的那些部分。

翻译是最容易拿来做 demo 的部分，也是最危险、最容易被高估的部分。

机器现在可以以惊人的速度把文本从一种语言搬到另一种语言。但这并不意味着产品就会因此显得 native。按照我的经验，真正的多语言工作会在四个地方暴露出来：时间、语气、UI 系统，以及 fallback behavior。产品到底会让人觉得 thoughtful，还是让人觉得虚假，往往就在这些地方分出高下。

实际情况大概是这样：

	Translation Work	Product Work
它覆盖什么	Strings、copy、labels	日期、layout、语气、fallbacks
谁会在出错时发现	双语 reviewer	该 locale 下的每一位用户
AI 能帮什么	很快生成翻译	不能判断产品层面的适配度
修复的代价	重新翻译 string	重新设计组件
你什么时候才会发现	code review 时	真有人开始使用之后

---

第一个 bug 不是翻译，而是时间

最让我意识到这一点的一个 fix，和 copy 完全没关系。

对于 recurring shows，DIALØGUE（对话）会自动生成每一集的标题。最直觉的做法听上去很无害：节目名加上今天的日期。

但一旦你的受众在东京，而服务器还活在加州时间里，事情就不一样了。

如果一位日本听众打开一个 daily show 时，东京已经是 3 月 14 日，但因为服务器还停留在前一天，标题上却写着 3 月 13 日，整个产品马上就会显得不对劲。不是坏掉了。只是显得很不上心。

所以我最后把集标题的逻辑改成了：用受众所在 locale 和 timezone 下的本地日期，而不是服务器默认日期。

这只是一个很小的实现细节。但这恰恰就是重点。

多语言产品不只是文字问题。它是 context 问题。

没有本地 context 的语言，很多时候只是一个更礼貌版本的错误。

---

Lesson 1：语气是产品的一部分

这一点在我把 DIALØGUE 做深以后，变得越来越清楚。

这个产品建立在 dialogue、pacing、personality 和 audio 之上。这意味着它的质量门槛，比普通的 SaaS 界面高得多。

当我添加新模板时，我很快意识到，多语言支持绝不只是：

• 翻译模板名称
• 翻译 landing page copy
• 然后就 shipping

就拿其中一个模板来说，我需要把这些都想清楚：

• host profiles
• audience profiles
• dialogue guides
• 给 TTS 的 voice instructions
• 每种语言自己的 localized naming conventions

这些工作在英文里已经存在，但它同样需要日语版和越南语版，因为 hosts 之间的 chemistry 是产品本身的一部分，而不是外面的一层装饰。

如果你的产品会生成内容，voice 不是装饰。voice 是基础设施。

一个东西可以语法上完全正确，但依然让人感觉很死。

这一点我在 Chinese 的不同变体上尤其感受很深，在 spoken content 上也是一样。标准普通话在技术上可以完全正确，但在某些场景里依然会显得太正式。英语里轻松自然的对话节奏，放到另一种语言里，如果只是字面化地塞进产品表达中，就可能一下子变得官样文章。一个在某个市场里很好用的玩笑，到了另一个市场里，可能就只剩下平铺直叙。

所以我现在会非常在意 tone guides 和 host profiles。不是因为我想让每一个输出都听起来很"品牌化"。而是因为 voice drift 是让一个多语言 AI 产品迅速显得 generic 的最快方式之一。

而 generic 是有成本的。

---

Lesson 2：UI 长度是产品问题，不是翻译问题

这听起来很小，直到你真的把一个 app 发出去。

然后它就会突然出现在到处都是的地方。

当我在做 DIALØGUE 的 iOS 本地化时，这已经不再是"翻几个页面"的问题了。它变成了 7 种语言、253 个 strings。

而即便如此，工作也还没有结束。

我必须重新 wiring 那些 input components，确保 app language picker 能真正一致地控制 UI 语言。placeholders、buttons、pricing labels、status text，全都要受它控制。不然你就会遇到经典的"半翻译 app"问题：

• 一个 screen 会跟着你选的语言走
• 另一个 screen 还在显示英文 placeholder
• status labels 仍然停留在原始语言
• 这个 app technically 支持多语言，但体验并不支持

一个在英文里很干净的 button，在德语里可能会变得别扭。 一条紧凑的 pricing line，到了法语里可能会换行。 一个很有力的 settings label，在日语里可能会表现得完全不同。

如果你的 localization workflow 在 text generation 这一步就结束了，那这些问题通常会在非常晚、而且很尴尬的时候才暴露出来。

所以我越来越觉得，多语言工作必须被当成一个完整的 product system 来处理：

• copy
• layout
• spacing
• truncation rules
• component behavior
• screenshot QA

机器可以生成那些词。真正去打开 Simulator 的，还是人。

---

Lesson 3：fallback behavior 会暴露一个产品到底成熟到什么程度

这一点在音频产品里，比在文本产品里更重要。

我最近为 DIALØGUE 做过一个最有用的 fix，外面看起来其实很无聊：TTS thresholding 和 per-segment consistency。

最初的 whole-script TTS gate 过于乐观。长播客会直接超过真正的输入上限，先白白浪费几次失败重试，之后才 fallback。在一些 runs 里，这意味着系统要多浪费大约 12 秒的可避免延迟，才会自己纠正回来。

在英文里，这已经很烦人了。

在多语言 flow 里，它更糟，因为 voice consistency 本来就更难维持。

这个 fix 不是"换个更好的 model"。它是 product work：

• 降低 whole-script synthesis 的 threshold
• 更早把长篇节目切到 per-segment mode
• 为每个 segment 加上 opening / middle / closing guidance，控制节奏和能量
• 把前一段 dialogue 的几行内容作为 continuity context 传进去，让下一段不要听起来像另一个节目

这就是 fallback behavior。这就是成熟度。

如果某个语言专用的 TTS 声音听起来不对，会发生什么？ 如果生成的回答开始混用语言，会发生什么？ 如果在一个本地化 flow 中间突然跳出 untranslated error message，会发生什么？ 如果一段很长的脚本超过了 model limit，会发生什么？

这些瞬间会告诉你，多语言支持到底只是一个 feature，还是已经成了 foundation。

当系统明显是在努力帮忙时，用户通常会比较宽容。 但当产品让人感觉 careless 时，这种宽容会迅速消失。

---

Lesson 4：知道什么时候 coverage 不值得做

真正的商业问题不是："我能不能再支持一种语言？"

真正的问题是：

• 这种语言会不会带来真实的 usage 或真实的 distribution？
• 我能不能在 UI 和 output 两边都维持一个可信的 quality bar？
• 我能不能在不制造 support debt 的前提下处理 failure cases？

如果答案是否定的，那你推出的就不是 multilingual capability，而只是 multilingual surface area。而没有质量保证的 surface area，会悄悄地侵蚀 trust。

---

Lesson 5：多语言产品需要自己的一层 evals

这也许是我从 DIALØGUE 和博客存档里得到的最大 takeaway。

你不能只靠直觉去判断多语言质量，尤其是在规模变大之后。

你需要明确的 checks：

• locale-specific 的日期和时区行为
• 术语一致性
• UI overflow
• fallback language rules
• 各个 segments 之间的 TTS consistency
• host / personality drift
• 真实用户 flow 中的 output quality

换句话说，多语言产品也需要 evals。

而我觉得，这正是很多 AI builders 容易掉进去的坑。我们太容易被 model 能产出多少东西这件事吸引，却花太少时间去 durable 地定义什么才叫"好"。

在小规模时，这还勉强可控。

一旦规模上来，它就会变得危险。

---

这让我现在怎么想

我比以前任何时候都更乐观地看待多语言 AI 产品。

AI 的确改变了 economics。它确实扩大了一个人或者一个小团队能够 shipping 的东西。它确实让那些不久前还显得不现实的产品野心变得可能。

但它也抬高了对 product judgment 的要求。

因为一旦语言扩张变得容易，quality 就会变成真正的差异化因素。而多语言产品里的 quality，并不是靠翻译本身就能得到的。它来自 context、voice、interface fit、fallbacks、review loops，以及对"到底什么才算 native enough"这个问题做出非常诚实的定义。

这就是 DIALØGUE 教会我的事。你支持的语言越多，你其实就在做越多的 product management，不管你是不是这样称呼它。

如果你的产品真的在做多语言，工作不会在 strings 被翻译完的时候结束。真正的工作，是从那里开始的。

如果你想看看这种思路的结果，DIALØGUE 现在已经以 7 种语言 live 了。而且我怀疑，多语言这一层会在更多人使用它之后继续给我新的教训。通常还是那种会让人谦卑一点的教训。

如果你也在做多语言产品，我很想知道：你是在什么时候意识到，最难的那个 bug 跟翻译其实一点关系都没有？

Cheers, Chandler

---

常见问题

构建一个多语言 AI 产品最难的部分是什么？

不是翻译。现在的 AI 在这一部分上已经做得相当好了。最难的是翻译之外的那些东西：考虑时区的格式化、跨 TTS segments 的语音一致性、因为不同字符串长度而被撑坏的 UI components，以及当某个特定 locale 出问题时的 fallback behavior。这些是产品问题，不只是语言问题。

我应该给我的 AI 产品增加更多语言吗？

只有在你能维持质量的前提下。每增加一种语言，都会带来持续性的 product work：layout QA、voice tuning、按 locale 处理的日期和数字格式，以及 fallback paths。如果你的产品依赖 nuance 和 generated content，比如 podcasts、长文写作，或者 conversational AI，那么它的门槛会比一个简单的 transactional interface 高得多。

你怎么测试多语言 AI 功能？

建立一层明确的 evals。对 DIALØGUE 来说，这意味着检查 locale-specific 的日期、TTS segment consistency、7 种语言里的 UI overflow，以及生成出来的 host dialogue 是否出现 personality drift。当你支持两三种语言以上时，已经不能再只靠直觉了。它的 surface area 大到不可能只靠手工 spot-check。

AI 会让 localization 变得更容易还是更难？

两者都有。AI 让初始翻译变得快得多、便宜得多。但它也会制造一种虚假的完成感。词都对了，你就会误以为产品已经准备好了。真正的工作，也就是 context、voice、UI fit 和 fallbacks，仍然需要 human judgment。AI 提高了 multilingual coverage 的 floor，但 ceiling 依然是 product craft。