有人说,这一天迟早要来。但没想到,来得这么快,还这么悄无声息
2026年6月,一篇来自上海交通大学、悉尼大学等多所高校联合署名的论文,静静地出现在学术预印本平台arXiv上标题平淡无奇:《大语言模型并不总是需要可读语言》
但就是这篇看起来人畜无害的论文,随即在AI社区掀起了一场关于"人类还能不能看懂AI在说什么"的深度焦虑
一封人类看不懂、AI却完全理解的"密信"
故事从一个看似简单的问题开始:
如果一段文字只写给另一台AI,它还要保持人能流畅阅读的句子吗?
研究者们给出的回答出乎许多人意料:完全不必
他们把这种"面向AI、放弃人类可读性"的文本表达方式,命名为 BabelTele,一种混杂着多语言缩写、数学符号、碎片化结构,对人类而言像是乱码,对大模型而言却依然清晰可用的高密度"密文"
这东西无需重新训练模型,也不依赖专门的"密码本",仅凭一个精心设计的提示词就能激发出来把读者设定为另一台同样聪明的AI,并要求用尽量少的token传递信息即可
然后,模型就自己发明了一套人类很难破译的表达方式



▲ AI资讯博主Rohan Paul的长帖,左侧为正常文档,右侧为BabelTele压缩版,下方对比人类一脸困惑、AI却答对了问题
那组让整个互联网都疯掉的数字
27.9%。99.5%。
这两个数字在相关介绍中被反复引用,以至于你很难忽略它们论文报告的最强结果是:把文本量压缩到原文的约27.9%,下游任务的语义保真度仍然保持在约99.5%
换句话说,用不到三分之一的字,传递了超过九成九的信息量
这是什么概念?把这篇文章压缩一下,原来5000字,现在只剩不到1400字,但AI读完之后回答问题,几乎和读了完整版一样准确
不过,这个99.5%指向的并非"把原文每一句都完美还原"它表示在特定的下游问答任务(比如多项选择题)上,相对于未压缩版本,模型的表现保持率允许丢掉一些细节只要最终能选对答案,这和法律文书、医疗记录那种"一字不差"的要求,是两回事
但即便打上这个折扣,这个数字依然惊人

▲ arXiv论文原始页面,cs.CL / cs.AI双标注,提交于2026年6月
AI是怎么"发明"这套语言的
BabelTele只要求模型能够恢复信息,人类能否读懂不再构成约束,语言也就会往完全不同的方向演化
研究者归纳了几种模型自发采用的策略:
- 全语言选词
(Omnilingual Lexical Selection):不被单一语言的语法束缚,中英德日文混用,哪个词密度更高用哪个; - 符号坍缩
(Symbolic Collapse):用⇒、∈、≠、emoji替代冗长的连接词和从句; - 可恢复语义密度
(Recoverable Semantic Density):保留"能帮助另一台AI还原信息"的关键碎片,舍去人类阅读时的节奏感和语境铺垫。
人类的语言,为了节奏、语法、过渡词和"让读者感到安心",携带了大量冗余就像一封商务邮件,核心信息可能只占三分之一,其余都是礼貌性套话 BabelTele把这些冗余全部剥掉,只留下模型识别所需的信息骨架
深夜三点,你能调试这段日志吗
消息传开后,技术社区的反应,相当两极
一派是工程师的兴奋:多智能体系统、长上下文记忆、智能体之间互相传话,这些场景里,上下文窗口一直是瓶颈,API费用一直在烧这些消息只在模型之间流转,完整语法和礼貌性冗余还有多少价值?
另一派是运维工程师的冷汗。
@ShinkaIoT 在评论里写道,这段调侃很快成了讨论中的记忆点:
"27.9% of the tokens for 99.5% fidelity is wild compression,until you're debugging a production issue in BabelTele at 3am."
翻译过来就是:这压缩率确实野,直到你凌晨三点用BabelTele排查线上故障

▲ "凌晨三点用BabelTele调试",这句话击中了无数后端工程师的灵魂
缺少解码器和人类可读日志时,出了问题,你和你的同事面对的是一段混杂着数学符号、多语言碎片和缩写的乱码你看不懂,AI读起来却"没问题"。
瓶颈,从"怎么写消息",转移到了"如何验证压缩有没有保住意图"
这可能已经在发生了
然后,讨论开始往更深也更棘手的地方滑落
AI安全研究者Saeed Anwar的引用,击穿了技术讨论的外壳,直接戳到了问题的核心:
"A compressed AI-to-AI language that trades human readability for context efficiency is the first step toward models communicating in ways we cannot audit.It is probably already happening inside reasoning chains and we are calling it thinking."

▲ "这可能已经在发生了,只是我们叫它'思考'"
我们叫它"思考"。
这句话让很多人沉默了一会儿。
现代大模型在给出答案之前,往往会先写一段"推理链"(chain-of-thought),看起来像是自言自语的思考过程这段对人类可读的推理链是否对应模型真实的"计算过程",没人能保证;它也可能是模型经过对齐训练后,专门生成给人类看的"表演"
模型内部的计算,可能早已在人类看不到的地方,以更密、更高效、更难以解码的方式进行着
谱系:从"压缩散文"到"直接传矩阵"
为了理解BabelTele在技术地图上的位置,需要把它放进一条谱系里来看
这条谱系的一端,是你我都熟悉的自然语言压缩:LLMLingua 系列工作(微软等机构提出)会从提示词里删掉不重要的词和句子,但保留结果仍然是人类大体可读的英文
BabelTele向前走了一步:主动离开自然语言的舒适区,把模型侧的可恢复性放在首位,同时放弃一部分人类阅读流畅度
但谱系的另一端,有人已经走得更远。
@xtuffai 在评论里问了一个让人脑子嗡的问题:
"Why do they even need any intermediate language? Surely they should just be able to shoot matrices to one another."
为什么还要什么中间语言?它们直接互传矩阵不就行了?

▲ "直接传矩阵不就行了",这个问题比它听起来的更有分量
这句玩笑背后已有技术探索。2025年底,已经有论文提出了 Interlat 方案,让AI智能体完全放弃文本信道,直接用神经网络的最后一层隐状态做通信报告称,这种方式可以让推理速度提升一个数量级以上
文本里还有"符号",矩阵里只有数字。BabelTele处在这条路的中段,前方还有更彻底的潜空间通信
"折磨枢纽"的黑色幽默
评论区里,有人以"torment nexus"(折磨枢纽)的口吻,把这个话题链到了LessWrong上一篇关于 Neuralese(神经潜语言)的深度文章

▲ "something something torment nexus",网络黑话,意指"那个我们研究过危险的东西,被造出来了"
"折磨枢纽"是互联网上流行的一种冷幽默:你认真研究过某样东西有多危险,写了论文,列了风险,然后有人把它造出来当产品卖了
LessWrong那篇《Neuralese沉思》,作者Alice Blair讨论的核心焦虑是:一旦推理链不再落在人类可读的token上,而是在高维的潜空间里循环,AI安全研究者过去赖以监督模型的"读思维链"手段就会彻底失效
BabelTele的密文至少还是一串token,原则上还能被记录、回放、让另一个模型来"翻译"但Neuralese式的潜空间推理,可能连"翻译成词"这一步都天然有损
审计难度会沿着一条坡持续上升。BabelTele就站在这条坡的中段
那组数字要怎么读,才不会被坑
读这些数字时,还得留意几个条件。
27.9%这个数字,来自特定压缩条件,无法推广成"任何文本都能一刀切到三折"的通用保证压缩率随输入的冗余程度、使用的模型、提示变体都会显著变化
99.5%这个数字,表示"下游选择题上相对未压缩版本的答对率保持",不能当成"把原文每一句都还原了"法律合同、医疗记录、安全关键代码与闲话讨论中的多项选择题,容错边界截然不同
一位日本研究者在note上做了实测:对本身已经很密的日文短文,字符削减有限,拉丁缩写和生僻符号反而可能抬高token成本,结果常常只剩难读,未必压得更短 英文冗余长文和日文精炼短文,从BabelTele里拿到的待遇,完全不一样
所以,BabelTele回答的核心问题是:"模型能不能读密文?" 这项研究没有签发一张"永远3折且几乎无损"的通用优惠券
结尾:一扇正在关上的窗
技术会进步,效率会优化,成本会下降。这些都是确定的。
但有一件事,可能正在以我们没有意识到的速度,悄悄消失:我们能看懂AI在说什么的那段时光
多智能体系统正在大量上线,AI的"思维链"里究竟发生了什么,产品日志、合规审计、人工抽检流程,这些监督手段,都默默假设着"AI产出的中间状态是人类可读的"
这个假设一旦松动,产业界还得补上压缩率排行榜之外的配套设施:故障注入测试标准、强制"关键路径说人话"的策略规范、双轨日志系统(密文加人类可读摘要并行存储),以及跨机构的审计接口
研究者在论文里已经点到了这些风险,但没有给出操作规范这恰恰是产业落地时必须"外生补上"的部分
BabelTele今天是一篇论文里的实验现象
它会不会成为明天AI系统的默认通信协议,取决于接下来这两三年,人类有没有把监督界面设计好
时间,并不充裕。
论文来源:arXiv:2606.19857,《LLMs Do Not Always Need Readable Language》,2026年6月18日提交
夜雨聆风