语音输入正在变得越来越“聪明”：删口头语、改句子、自动压缩、重新组织表达。但如果这些文字下一步是交给 AI 执行任务，“整理得更漂亮”未必就是一件好事。
8 月 4 日，来自 University of Southern California（USC）、Santa Monica College 以及 USC Information Sciences Institute 的研究人员发布论文 《Should We Type or Talk to LLM Agents? A Comprehensive Study of Voice and Keyboard Input Perturbations》。
他们研究了一个看起来很简单、过去却很少被认真讨论的问题：同一件事，人打字告诉 AI，和人说出来、经过语音转写以后再交给 AI，结果会不会不一样？
答案是，会。
研究团队构建了一套名为 HIVE（Human Input-Variation Engine）的测试方法，分别模拟键盘输入中的错字、漏字、字符交换，以及语音输入中的口头语、转写变化和 AI 辅助听写工具对原话的压缩、重组。结果显示，在他们测试的所有指令模型中，语音转写扰动都会造成准确率下降；真正影响模型表现的，并不主要是“嗯”“啊”“那个”这些口头语，而是转写过程中原始信息的结构被改变，以及问题中的 token 有没有被保留下来。
这件事对今天正在升温的 AI 语音输入，很值得讨论。
AI 帮你把话说漂亮，可能顺手把条件也删了
现在很多语音输入产品都在往一个方向发展：用户说完之后，不只是转成文字，还要顺手“整理”一下。
比如你原本说：
“这个你先把昨天那个版本找出来，然后跟今天这个对一下，价格先不用看，我主要想知道交付时间有没有改。对了，付款方式也看一下。”
系统处理以后，可能变成：
“请比较昨天和今天的版本，重点检查交付时间。”
看起来确实干净了。
没有重复，没有停顿，句子也更像一个标准 Prompt。
问题是，“付款方式”没了。
如果这段文字只是准备发朋友圈，少一点信息也许无所谓。但如果下一步是交给 Agent 去读合同、查文件或者执行任务，这就不是“润色”，而是任务条件发生了变化。
论文得到的一个重要结论正是如此：模型对新增的一些冗余信息其实有一定容忍度，真正伤害结果的，是原始问题中的信息被删除。研究者把这种现象概括为 token survival——原始问题里有多少信息真正活着抵达了模型。
换句话说，过去我们评价语音输入经常问：
“转出来的文字够不够漂亮？”
到了 AI 时代，可能应该先问另一个问题：
“我原本说过的东西，还剩多少？”
对 AI 来说，上下文往往比句子漂亮更重要
搜索引擎时代，人习惯把问题压缩成关键词。
“大模型 私有部署 成本”。
“合同 对比 工具”。
“Python 报错”。
越短越像搜索。
但今天和大模型、Agent 沟通，逻辑正在反过来。很多任务不是信息越少越好，而是背景越完整、限制条件越清楚，模型越容易理解你到底想干什么。
真实工作中的指令尤其如此。
“帮我看看这两个版本哪里不一样”是一句话。
但真正交代给同事时，我们很可能还会继续补充：
“价格不用管，重点看交付日期；如果付款比例改了单独列出来；客户名字不要动；最后先给我看，不要直接发出去。”
这些条件经常不是一次性想好的。
人讲话的时候会停顿，会补一句，会改口，甚至说到最后突然想起最重要的限制。
从文字编辑的角度看，这些表达并不漂亮。
但从任务执行的角度看，它们可能恰恰是上下文。
这也是语音进入 AI 场景后一个很有意思的变化：过去语音识别追求的是把人说的话变成更像“文字”，以后可能更重要的是把人的完整意图尽量保留下来。
“让模型多想一会儿”，也救不回已经丢掉的信息
论文里还有一个结果值得注意。
研究人员增加模型的 thinking budget 后发现，更多推理可以在很大程度上缓解键盘输入错误造成的问题，但对语音转写产生的结构性变化帮助有限。对于经过压缩的语音输入，有些情况下表现甚至进一步下降。
原因其实不难理解。
一个字打错了，模型还有机会根据前后文猜出来。
但如果一句关键条件在输入阶段已经被删除，再强的模型也不知道用户原来说过什么。
推理可以处理噪声，却不能恢复一段根本没有被送进模型的信息。
这也提醒我们，今天讨论 AI 能力时，不能只盯着模型这一端。
模型前面的输入层，同样决定了它最终能看到什么。
如果语音输入工具在发送之前，已经替用户压缩、解释甚至重新组织了一遍意图，那么后面的模型真正处理的，其实已经不是用户的原始表达，而是另一个 AI 对用户表达的理解。
一层 AI 改完，再交给下一层 AI。
每一层看起来都在“优化”，但信息究竟丢了多少，很容易被忽略。
所以 RunXun.AI 目前选择先把“输入”做好
我们在做 RunXun.AI 语音输入时，也面对过同样的选择。
语音识别之后接一个大模型并不难。它可以自动删口头语、整理句式、压缩内容，甚至直接替用户生成一个更像 Prompt 的版本。
从功能列表上看，这当然显得更“AI”。
但 RunXun.AI 当前选择的是另一条路：纯听写。
用户按住热键说话，松开以后，文字直接落在当前光标位置；它不要求用户切换到单独的编辑窗口，也不主动把用户说过的话再交给大模型重写。语音引擎运行在本地 Mac 上，日常识别无需联网或上传。
这个设计并不是说 AI 润色没有价值。
而是我们更愿意把两件事分开。
输入负责把你的话留下来，润色则应该是你主动做出的下一步选择。
如果是在写一封邮件，听写结束以后可以再让 AI 改得更正式；如果是在写文章，也完全可以继续做摘要、润色和重写。
但第一步，最好先有一份尽可能忠实的原始表达。
尤其当语音输入的下一站本身就是 ChatGPT、Claude、编程 Agent、IDE 或企业内部 AI 系统时，这个区别会越来越重要。
语音 AI 可能正在分成两种产品
从这个角度看，今天都被叫做“AI 语音”的产品，其实正在出现两条不同路线。
一种更接近语音创作。
用户只需要说出一个大概，系统负责理解意图、整理语言、补全文字，最终交付一段可以直接使用的内容。在这种场景里，AI 多做一点没有问题，因为用户本来要的就是结果。
另一种更接近语音输入。
它位于人和软件之间，或者人和另一个 AI 之间。它承担的是信息入口，因此最重要的不是替用户表达，而是尽量不要改变用户原本表达的内容。
两者没有谁一定更高级。
但当越来越多人开始用语音给 Agent 下指令、描述 Bug、交代文件处理要求时，这条边界会越来越值得注意。
AI 越能执行任务，输入层越应该知道自己的边界
过去语音识别出错，我们最担心的是一个字写错了。
以后情况可能会不一样。
当文字后面连接的是一个真正会查文件、改代码、调用工具甚至执行业务流程的 Agent 时，输入工具对原意的每一次修改，都可能进一步变成行动。
这也是这篇论文给我们最大的提醒。
语音输入真正进入 AI 工作流以后，行业需要重新思考“智能”到底意味着什么。
自动删除、自动压缩、自动整理当然都是能力。
但有时候，知道哪些事情不应该替用户做，也是一种能力。
模型可以越来越聪明。
输入层反而应该更清楚自己的位置。
因为对于一个准备执行任务的 AI 来说，最危险的未必是它没听清一个字。
而是它非常认真地听懂了一段已经被改过的话。
参考资料
Hu, Z., Segura, N. E., Rostami, M., & Thomason, J. (2026). Should We Type or Talk to LLM Agents? A Comprehensive Study of Voice and Keyboard Input Perturbations. arXiv:2608.03970. Authors affiliated with University of Southern California, Santa Monica College, and Information Sciences Institute, University of Southern California.