# 让 AI 少写几个词，句子为什么就拧了 **Summary:** 一篇 arXiv 论文发现，九个前沿模型用到的罕见词序都比人类参考文本更多，还有几类拖累理解的写法也更常见。作者怀疑，压缩信息的压力和表达清楚在相互拉扯。我的判断是：解释好不好，要看读的人有没有真的读懂，哪怕为此多写几句。 - Canonical: https://markhuang.ai/zh/news/ai-writing-token-savings-reader-cost - Language: zh-CN - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-10-24 - Section: News - Tags: AI 写作, 大语言模型, 可读性, 技术写作, 强化学习 - Source: [arXiv](https://arxiv.org/abs/2610.29162) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![一台金属压机把一条空白的象牙色纸带压成紧密的褶皱，旁边留着一段松散展开的部分](https://cdn.markhuang.ai/news/ai-writing-token-savings-reader-cost/hero.webp) *示意图讲的是这个取舍：一段解释压得越紧，读者要拆的东西就越多。* 2026 年 10 月 21 日提交到 arXiv 的一篇论文，让我想改一改自己常说的一句话：“写简洁点”。这篇 [《Why is AI-generated language so hard to understand?》](https://arxiv.org/abs/2610.29162) 考察了九个前沿和准前沿模型，发现它们写出的词语组合，比人类参考文本更少见、更不寻常。研究还找出了几类跟“难读”相关的语言特征，模型用起来也更频繁。 我的理解是：一段解释可以省下 Token，代价是读的人要多干点活。如果多给编码智能体一些篇幅解释某处改动，能让审的人更顺地把代码看完，我愿意给。我希望审阅的人看得懂这段解释，也有足够细节去质疑它的结论。 这篇论文给这个担忧提供了证据，也给出了一个可能的机制。但它没有测出人读这些回答到底多花多少时间，也没证明某个前沿模型的写作风格就是训练方式造成的。这两件事得分清楚，才不至于把结论又变成一条人人都得照做的写作规则。 ## 句子是怎么变别扭的 研究者收集了 14 个模型的文本，覆盖对话、编程和文章三类场景。对话和编程各用了 15 条初始提示词，文章场景则是命题作文。分析没有停在“它又爱用某个烂词”这种抱怨上，而是查得更细：语法上有关系的两个词被拉开了多远，名词套名词的链子有多长，还有多常把描写活物的动词按到没有生命的主语上。 这些结构英语里本来就有。问题在于模型多频繁地选它们。把信息挤进更短的表达，读者就得自己把那些关系补回来；换成啰嗦一点的句子，这些关系本来会写明。论文还专门分了两类关系从句：一类保留“that”这种可省的词，一类把它省掉。在多组比较里，模型更常选省掉的那个版本。 为了比较不同写法，研究者用翻译模型把句子从英语译成日语，再译回英语。这一来一回，跟难读相关的特征大多变少了，对话和编程场景尤其明显。文章场景的差异弱一些，所以我不敢把这套结论套到所有 AI 写作上。 这个对比本身也有问题。[2021 年的《Machine Translationese》](https://aclanthology.org/2021.eacl-main.188/) 发现，机器翻译在它测试的语言对里会降低词汇和句法的丰富度。翻译会按自己的方式改变风格。所以我把这个来回翻译当成“另一种写法确实存在”的证据，但要说到“更好”，我还想看到直接拿读者做测试。另外，这里的人类参照也只是大致对应的材料：对话场景用字幕，编程场景用 StackExchange。 ## 长度惩罚改掉了什么 作者怀疑，“把信息都塞进去”的压力会和“说清楚”打架。他们做了个小规模对照实验：训练 Qwen2.5-1.5B-Instruct 把结构化的事件描述改写成英语句子，回答越长罚得越重。 有了这个惩罚，模型会更倾向于更短、但同样合法的说法。这种偏好还会蔓延到训练里没见过的相近结构。再往外推就不太行了：四个测试方案只有一个有效果，而且还得去掉那个约束模型别偏离原始模型的正则项。所以说它是个可能的机制，但管不了多远。 训练时惩罚长度，和使用时要求“答短一点”，不是一回事。这个实验没法告诉我一句精简的提示词会带来什么。它只是让我更不敢把“Token 少”直接当成解释够好的证据。 论文里还有个让人乐观的对比：在 21 组跟难读相关的指标上，Claude Opus 5.5 有 19 组低于 Opus 5，其中 8 组的置信区间不重叠。 ## 熟悉的简写照样有用 专家读压缩过的技术语言，可能一点都不费劲。这是我看到的最有说服力的反驳。滑铁卢大学那篇谈 “Claudish” 的[采访](https://uwaterloo.ca/news/media/q-and-experts-what-claudish)里，计算机科学家 Yuntian Deng 说这些表达是从既有技术领域借来的。他还认为，读的人本来就熟，反而省事——不用一遍遍让智能体“说人话”。 [Hacker News 上关于这篇论文的讨论](https://news.ycombinator.com/item?id=50223647)正好是这种分歧的现场版。有位评论者说自己得放慢速度才看得懂那些句子；另一位说，作为开发者，这些结构他觉得挺眼熟。都只是个人经验，但它们指向一个我想留在评估里的问题：这段东西，到底是给谁读的？ 能帮到目标读者的技术词汇，我会留。真正该返工的，是那种默认读者已经知道某些事的解释。我早前写[Claude 的“承重缝”](https://markhuang.ai/news/claude-load-bearing-seams-no-subject)那篇，说的是文章从头到尾没点明主语。这篇论文关心的是另一回事：主语在，句子关系照样能被压得看不清。 ## 我会先测读者接不接得住 拿到一份智能体的改动摘要，我会先让审阅的人说出两件事：行为改成了什么样，什么条件下才生效。然后拿这个理解去对补丁。如果解释要重写，我会比较新版本有没有让这两点更好找，同时没把证据丢掉。论文没做这个评估，这是我自己会去跑的。 多写几个连接词，只要能让解释更好核对，这个代价我认为值。但更长的文字也得挣到自己的位置。长回答把决定埋在废话里，我会否掉；短回答漏掉推理过程，一样否。 论文的边界也很明确：只测英语，只选了一批模型，初始提示词也不多。它给出的语言指标让我有理由去查读者的阅读负担，但还没告诉我负担有多大。眼下我会要求智能体把改动点说清楚，把相关的关系明写出来。等我读懂之后，再判断它够不够简洁。