通用翻译 App 在其设计目标内表现出色：问路、看菜单、买车票。问题出在同一套设计被原样带进诊室——因为旅行翻译器和专业口译的设计目标几乎是相反的。旅行翻译优化的是快、便宜、能离线；专业口译优化的只有一件事：不出错。差距主要来自三个具体的设计选择。
问题一：你的句子在哪里结束，由机器说了算
通用 App 的对话模式靠语音活动检测（VAD）工作：你停止发声约一秒，App 就认定你说完了，把听到的内容送去翻译。「车站在哪」没问题。但在真正要紧的对话里它恰恰失灵，因为人在需要精确时才会停顿——回忆疼痛是在换药之前还是之后、核对一个日期、在法律事务里斟酌一个词。
VAD 在停顿处将句子切开，引擎随即翻译前半句；后半句作为新的片段抵达，与前文不再关联。两半各自都译得通顺，意思却已经改变。此外，在嘈杂的候诊厅里 VAD 还会出现相反方向的错误——把广播通知、邻座的交谈并入你的句子。
这一问题的解法由来已久且十分直接：按住说话（push-to-talk）。说话人按住按钮说话，需要停顿多久都可以，句子真正说完再松手。每一句的边界都是人的决定；也只有按住的那几秒会被提交，这正是背景噪音进不了引擎的原因。
问题二：一个小到装得进手机的模型
离线翻译是真实的功能，也有真实的代价。要在手机上运行，模型被压缩到顶级引擎的一小部分——而被砍掉的能力恰恰是长尾：专业术语、从句套从句的长句、语域分寸。端侧小模型对高频短语表现不错，碰到「阵发性房颤」或租约里 covenant 与 condition 的区别，就开始猜。
猜是最危险的失败方式，因为输出依然流畅，看上去没有任何不对。医疗对话里，「每十二小时一次」与「一天两次、时间不限」的差别正是关键信息所在；法律对话里，一句专业人士一眼就会指出问题的意译，就这样毫无标记地通过了。
专业场合的正确取舍是反过来的：把每一句话都交给能拿到的最强云端模型，接受它需要联网，换来一个真正见过这些术语、扛得住长句、稳得住分寸的引擎。
问题三：每一句都当作对话刚刚开始来译
多数翻译 App 是无状态的：一句进、一句出、随即忘掉。但一场问诊不是一袋互不相干的句子。无状态会产生三类典型错误：
- 术语漂移。同一个病，一场对话里三种译法——读的人分不清这是一个问题还是三个。
- 指代断裂。「那之后就更严重了」——「那」是指什么？没有前文记忆，代词与回指的翻译便不可靠，中文、日语这类习惯省略主语的语言译到英语时尤其如此。
- 已知信息用不上。病史、案情、「这是在谈租约而不是闲聊」——引擎一概看不见，自然也做不到任何一位人工口译员都会做的那种消歧。
解决方式是把上下文系统性地提供给引擎：告诉它场景（医疗的规则不是法律的规则——剂量必须精确，法律语言绝不意译），开场先给背景，让它跟住整场对话，并且锁定术语——第 2 分钟译成什么，第 20 分钟还是什么。
该核对的五项标准
如果一场对话错一句就有代价，用五条标准去核对工具：
- 说话人控制轮次——按住说话，而不是自动断句；
- 云端顶级模型——而不是端上引擎；
- 场景与背景——有办法告诉它这是一场什么对话；
- 术语记忆——全场保持同词同译；
- 双语留档——事后可以核对的记录与摘要。
这也正是 AI 口译据以构建的清单——按住说话的轮次、每句话都由云端顶级模型翻译、九个各带术语规则的场景预设、专业咨询可先录入背景，以及结束后的双语记录、摘要与术语对照。但这份清单本身是独立成立的：无论用什么工具应对一场重要对话，这五项就是旅行工具与专业口译工具之间的分界线。