翻译 + AI = ？

status
category
date
summary
slug
icon
tags
password
最近在构思一些「老功能」：过去已经有的，但在AI的加持下可以做得更好的功能，例如搜索、翻译。

思维陷阱

很快就发现这样的思路得不出满意的结论，因为在AI加持下可以获得巨大体验和效率提升的场景，往往不是老功能加上AI的能力，而是解构老功能，用AI的能力重新定义用户、场景、功能。
这里自己犯了两个错误：
  1. 没有带入用户视角，陷入了「作为产品经理，单纯想功能」的陷阱。只想自己做什么，而不想用户要什么。
  1. 获得新的背景信息之后，没有及时重新决策，而是在旧的决策上打补丁。有了大语言模型的能力之后，应当思考一些之前没有被满足、或者用户和产品都做出了妥协、甚至碍于技术能力用户已经养成了错误习惯的场景，而不是止步于老功能+AI这个阶段。（突然想到一个古老的名词「互联网+」，简单的数据上云不是互联网+，将规模效应发挥到极致的社区和社交才是。）

翻译的本质

发现某产品做了这样的翻译功能——用户输入自己的想法，然后选择翻译设置，例如：
  • 格式（邮件、段落、大纲、Twitter）
  • 长度（短、中、长）
  • 语气（友好、严肃、幽默）
  • 专业程度（标准、外行、专家）
  • 翻译风格（直译、意译、创业改编）
  • ……
Monica本身有一个Compose功能，也有类似的设置，不过功能取名为「写作」，主要针对的是需要文字输出的场景，忽略了翻译这个细分场景。
细想一下，二者确实有交叉之处。普通翻译只是word to word的语言转换，但更多其实是会碰到更深层、更复杂的用户场景，也就是用户为什么需要翻译？答案只有两个：
  • 读不懂
  • 写不出

阅读

一般阅读的步骤是：
  1. 看到源语言文字
  1. 翻译成自己熟悉的语言（也可能省略这一步）
  1. 根据认知理解文字的意思
读外文阻碍了第1步到第2步的过程，但用户实际需要的是理解外文含义，而不是逐字逐句理解原文的意思。虽然有划词翻译、享受阅读体验、欣赏翻译过程等例外场景，但这里讨论的主要是大多数用户面对的办公效率场景。
所以在阅读场景下，「翻译」这个需求被定义为了「Translate + Summary」。最优用户路径是用户打开外文文章，或者输入外文文字，即可得到目标语言下的原文和大意概括。

写作

一般写作的步骤是：
  1. 构思想法
  1. 用已经掌握的语言写作
  1. 翻译成目标语言
写外文阻碍了第2步到第3步的过程，但用户实际需要的是把想法变成外文输出，而不是先把想法用中间过渡语言落地，是「thoughts to words」，而不是「thoughts to original words, then to foreign words」。
所以在写作场景下，「翻译」被定义为「Rewrite + Translate」。最优用户路径是用户描述写作目标、提供背景信息，即可得到目标语言下的文本。

解法与警惕

之前跟非互联网行业的老同学介绍什么是产品经理，聊到一个话题叫做区分真伪需求，有时候用户为了解决当下的某个问题会提出某些要求，但这些要求是在非常具体和复杂的场景下提出的，很难直接转化为对大多数用户有价值的产品需求。
翻译虽然不是一个伪需求，但却是一个表面需求，它更本质的需求就是想要读懂某段外文，或者想要写出某段外文，那么更直接和具体的产品需求就是满足这两点：Read & Write。两者需要的技术能力，分别是总结文章大意和根据需求写作，正是大语言模型提供的。
如果用「具体」、「直接」、「简单」来形容产品需求，需求看似非常精准地打击到了痛点，这时需要警惕，因为产品可能在定制化和通用性的平衡上向前者倾斜了。这也是效率工具产品需要权衡的，是更垂类，提供精细化的一条龙服务，还是更通用，提供灵活服务供用户自由选择搭配。更需要警惕的是，二者可能都是自己的意淫，被精准打击的用户可能没有那么多，而看似通用的万金油可能也并没有疗效。
意淫完毕。
Loading...

© 刘口子 2018-2025