实时翻译再快，Listing 还是走原来的流程

5 月 30 日 OpenAI 发了实时翻译模型，七十多种语言输入，几乎没有延迟。

我之前那家公司的文案模块做多语言 Listing，那时候每天都在出，覆盖亚马逊英文和 Shopee、TikTok Shop 的几种语言。看到实时翻译，第一个念头是：中文写一版，直接翻过去，是不是就不用每个语言单独生成了。

我拿亚马逊英文的 Listing 试了一下。

为什么先试亚马逊英文

选亚马逊英文，是因为它量最大，也最挑。

亚马逊的买家读 Listing 的方式很固定：标题扫一眼，五点描述看前两点，不对就走。英文写得像不像本地卖家，在这里最明显。如果实时翻译在这里过得去，其他平台就更好说；过不去，其他平台也不用试了。

翻得快，句子也对

挑了几条已经上线的中文卖点，让它翻成英文。

速度不用说。句子本身也没什么错，语法对，用词对，意思没丢。如果只看翻译质量，比前几年的机翻好得多，拿去做普通的交流完全够。

卖点的顺序，还是中文的

问题不在句子里，在句子怎么排。

翻译不会动顺序。中文卖点是按中文的习惯排的，先说什么、后说什么、哪一句放在最前面，都是写给中文读者的。它忠实地把这个结构搬了过去，每一句单看都对，合在一起读，还是一篇从中文翻过去的 Listing。

放在亚马逊上，这个问题会被放大。买家先看到的那一两点，决定他还往不往下看。顺序不对，最硬的那个卖点可能排到了后面，根本没被看到。

去年反对的，是负责亚马逊的资深运营

试完我想起了去年的一次讨论。

文案模块刚做的时候，先写中文再翻译这条路被提出来过。技术上它最省事：一套中文文案，翻成几种语言，审校也只要审中文。

反对的是负责亚马逊的几位资深运营。他们在平台上待得久，一眼能看出哪些 Listing 是翻的，也知道买家看得出来。

后来的做法是每个语言按各自平台的规则单独生成，前面加一份事实表保证信息一致，后面接审校。这套流程比翻译麻烦得多，但文案读起来是那个平台上的文案。

当时我是被说服的，但说服我的更多是运营的经验，不是我自己看到的东西。这次拿实时翻译试了一遍，才真的看到他们说的是什么。翻译解决的是说什么的传递，Listing 要解决的，是在那个平台上该怎么说。

每天出一批，更不能走回头路

那时候多语言 Listing 每天都在出。量是一个理由：每天一批，如果走翻译那条路，每一批都带着中文的顺序上架，积累下来，是整个店铺的 Listing 都带着同一个毛病，而且很难一条条回头改。

另一个理由是流程已经稳了。事实表、分平台生成、审校，这条链跑了一年多，运营也习惯了。为了省一步生成，换成翻译，等于退回到去年被否掉的那条路上。

没再用，但它适合客服

试完这一次，我没再用它。

不是它不好。它要解决的，是一个我们已经用另一种方式解决了的问题，而且另一种方式更贴平台。

它真正适合的，我觉得是客服。客服每天面对的是买家的消息和评论，要的是快、是大意对，不上架，也不需要排卖点。一条外语消息进来，实时翻成中文，回的时候再翻回去，这正是它擅长的。在客服那里，句子对就够了，顺序不重要。

那边的客服看外语消息和评论，用的是平台自带的翻译。十来个人，每天面对几个平台的买家，最常遇到的问题，就是翻译不准：一句抱怨翻过来变得不痛不痒，一个具体的问题翻过来意思走了样。

实时翻译在这里，正好能补上平台翻译不足的地方。它不需要写得像本地卖家，只需要把买家的意思准确地翻过来，再把回复准确地翻回去。

客服的消息还有一个特点：来回快，错了能马上问。买家说得不清楚，客服可以追问一句；回复翻得不准，买家也会再问一句。一来一回，意思总能对上。

Listing 没有这个机会。挂上去以后，读的人不会来问你这句什么意思，读不懂、读着别扭，就划走了。

所以同样是翻译不够好，放在客服那里，是多一个来回；放在 Listing 里，是一个没被看到的卖点。

同一个工具，放在 Listing 里是绕路，放在客服那里正好。工具好不好，要看它接在哪一段。接错了段，再快也是绕路。