语音转文字和语音对话
status
category
date
summary
slug
icon
tags
password
最近在做语音对话，顺便思考了一些问题：
- 现有的语音转文字功能做得怎么样？
- 二者的区别？使用场景有何不同？
- 二者是否应该共存？
功能定义和区别
语音转文字
语音对话
以纯文本聊天为基准
- 语音转文字功能是免去用户手动打字，而是将用户的语音转成文字，再发送，用户收到的也是文字
- 语音对话功能类似打电话，双方都是自己说话、听对方说话，整个过程和文字无关
注：
- App截图来自ChatGPT
- 本文讨论的语音对话，指的是建立在文字对话的基础上，通过用户语音输入、AI语音输出模拟的语音对话
用户场景和需求
忘掉上面这些已有的方案，只考虑两个场景在不同环节中，内容的媒介区别
场景 | 用户输出 | 用户发送的媒介 | 用户收到、AI输出的媒介 |
语音转文字 | 语音 | 文字 | 文字 |
语音对话 | 语音 | 语音 | 语音 |
用户使用不同的功能，本质上是在意这些功能的差异性。
从发送媒介的区别出发：
- 有用户在意「发送的内容是文字」本身，原因是文字具有某些特点，为了满足这个用户场景，就会自然做出一些产品决策：
- 可视性强，便于快速浏览：输入框一定需要支持多行文字展示
- 可预览，便于校对，便于消息接收方浏览：转文字的结果一定是填到输入框，而不是直接发送
- 输入效率低：使用语音转文字只是为了提高输入效率
- 有用户在意「发送的内容是语音」，语音同样具备一些特点：
- 有感情：可以表达情绪
- 可读性差：获得信息内容的效率低，对方可能不便收听，但对AI来说没有这个问题
- 输入效率高：既然追求效率，那么操作步骤就越少越好，即对讲机模式，松手即发送，无需二次确认
- 有用户在意「收到的内容是文字」
- 可读性强：需要真实看到文字本身，尤其是在字词写法、代码等场景，所以需要注意文字排版和富文本支持
- 阅读效率高：看文字比听声音效率高，要注意匹配AI吐字的速度、用户浏览的速度、屏幕滚动的速度
- 有用户在意「收到的内容是语音」
- 有感情：可以感受对方的情绪，AI的说话方式如果可以模仿人的语气、感情，那么人机交流就可以不止停留在冷冰冰的文字和语音，而是在交流方式、内容、情感上都可能还原出任何人交流的场景
- 其他的缺点都可以为上面这一点让步
上面的思考过程很微妙，一边在探索场景的区别，一边在寻找用户的终极需求，还一边在定义产品功能。
一些想法
- 已有A功能，要新增B功能的前提，不仅仅是A和B不一样，而是
- 差异性：A和B满足了不一样的需求
- 不可替代性：部分需求只有A或B能满足
- 必要性：这些需求都需要被满足
- 已有A功能，要将A功能迭代为B功能的前提是，B不仅能满足新需求，还能很好地满足本来被A满足了的需求。
- 用户场景是对用户所在情景、用户目的等属性的包括性归纳，是产品设计者人为反向定义出来的。
- 用户本身不思考抽象的用户场景，只关心一两个具体的功能性差别，或者感受。
- 要满足某个场景，就要做到极致。对看似可以兼顾两者的方案保持警惕，兼顾的含义从正反两面解读，可以认为是两者都满足一些，也可以认为是都没满足好。
- 从经验还原主义的角度来说，感受只能复刻过去的体验，也就是对已有场景的再次实现。
- 要警惕创造新场景的想法。
- 不要总觉得之前的场景是过时的，要尊重历史的进程和过程。
- 参考是有好有坏的，看竞品的时候，不要带着借鉴的想法先入为主，有可能它们的方案不够好，或者场景不一样。
- 满足好每一个场景，做好差异化，甚至走向极端。例如MacBook Air和MacBook Pro的产品线差异化，分别满足了轻便办公和性能需要，从Pro系列额外补充的接口也能看出这一点。
- 不要做一个折中和妥协方案，两个场景都没有满足好。这个教训是看了文心一言才学到的。
说完一段话自动发送，AI回复了文字，再自动朗读，如此重复，于是
- 在意发送文字的人，发送之前没法预览和校对
- 在意收到文字的人，消息内容又会被遮挡，且无法滑动交互
- 在意通过语音进行沉浸式聊天的人，又会被繁杂的文字打扰，机械的AI语音也很出戏
共勉。
Loading...