1999年，NASA 的火星气候探测者号正接近火星。位于科罗拉多州丹佛的洛克希德·马丁团队使用英制单位生成推进器数据，位于加利福尼亚州帕萨迪纳的喷气推进实验室则按公制单位处理这些数据。
两个团队都在完成自己的工作，问题出在交接处。一个系统传出磅力秒，另一个系统把数值当作牛顿秒。探测器最终进入了错误的轨道，任务失败。
NASA 后来成立事故调查委员会。由约翰·卡斯帕斯担任主席的委员会在《火星气候探测者号事故调查委员会第一阶段报告》中记录了这次单位不一致，以及项目流程没有及时发现错误的问题。
这件事与在 Accra 交通里发一条语音消息有相似之处。信息可能完整地存在于说话人的脑中，也可能完整地说出了口；如果系统在语言切换处把上下文拆开，意思仍会在交接中丢失。
一条消息为什么会自然换语言
设想一位通勤者坐在车里，先用 Ghanaian English 交代实事：
“Tell Kojo I’m still on the way. He should start without me.”
车流没有往前走，语气开始变急。他接着说：
“Ei, traffic no yɛ serious. Ka kyerɛ no sɛ meba, na ɔnfa documents no nkɔ without checking page two.”
这不是两个互不相干的请求。Kojo 还是同一个 Kojo，documents 还是前面那件事里的文件，“page two”也依赖整段话才能判断重点。English 负责快速交代安排，Twi 带出情绪和强调，随后一句又自然回到两种语言混用。
换语言不等于换话题。对许多会说 Twi 和 English 的人来说，code-switching 本来就是组织意思的方法。让他们先选语言，再把一句话拆成几段，等于把系统的分类工作推回给正在开口的人。
这也是[当一条语音消息在 Twi 和英语之间自然切换，会发生什么？](/blog/zh-CN/当一条语音消息在-twi-和英语之间自然切换-会发生什么-2f73373a/)值得追问的核心：系统有没有保住转折前后的关系。
连续理解比逐句识别更重要
识别出每个词，只完成了一部分工作。真正有用的回复还要保留指代、顺序、情绪变化和未说完的上下文。
在上面的消息里，助手需要明白三件事：通勤者仍在路上；Kojo 可以先开始；文件送出前必须检查第二页。如果系统在“Twi 开始了”这个位置重置上下文，它可能把后半段当作全新的指令，反问 documents 是什么，或者漏掉检查第二页这个条件。
这类失误很像火星气候探测者号的数据交接。各段信息单独看起来都能处理，连接方式却决定了最终结果。日常语音消息的后果当然没有航天任务那么大，但机制相同：边界处理错了，完整输入也会变成残缺行动。
Nkomo 让用户用自然 Twi、Ghanaian English，或两者混合来输入。你可以打字，也可以按住说话、听取回复，并在需要时自然打断。目标很具体：一段话从 English 转到 Twi，再转回来时，对话仍沿着原来的意思继续。
隐私控制也要跟得上语境
语音里的自然感不能靠模糊的数据处理换来。用户需要知道什么会到云端，什么留在设备上，以及会保留多久。
Nkomo 提供“从不允许”“每次询问”和“本次会话允许”三种云端同意方式。设备上的历史记录也由用户控制；关闭历史后，记录会立即清除。需要带走数据时，可以一键导出；决定离开时，也可以一键删除账户。
这些选择应该在用户开口前就说清楚。Status-quo bias 会让人沿用默认设置，因此默认和提示必须易懂；Hick 定律也提醒我们，选择太多会拖慢决定。三个明确选项比一页含糊说明更容易判断。
系统出错时同样如此。Nkomo 会显示错误，不会静默吞掉失败。因为一句重要更新若没有送达，用户最需要知道的就是它没有送达。
别让切换点成为断点
设计混合语言对话时，可以先检查一个简单问题：用户换语言之后，系统是否还记得换语言之前的名词、人物和条件？
测试时要保留真实说话方式，不要先把录音整理成整齐的单语句子。让测试者在 English 和 Twi 之间自然移动，加入转折、补充和临时改口，再检查回复是否覆盖整段意思。[语音助手没听懂“Nanso”后的转折，会发生什么？](/blog/zh-CN/语音助手没听懂-nanso-后的转折-会发生什么-77b0f064/)展示了为什么一个小小的连接词也可能改变后半段的任务。
1999年的火星任务留下了一条清楚的教训：两个系统各自运作，并不代表它们能正确接住彼此。对 Accra 车流里那条越说越急的语音消息来说，语言切换就是交接点。好的助手会守住这个点，让同一个人、同一份文件和同一个要求一直留在对话里。
评论
暂无评论。