流畅表述不等于正确

概念解释

一封语法无疵的求职信，把公司主营业务写成了另一家。招聘的人一路读得很顺，没有在任何一句上卡住，于是错的那句跟着滑过去。流畅与正确分离（fluency–truth dissociation）指的是：读起来省力，不能当作内容为真的证据。生成器最稳定的产品是顺句，不是真句。

确定的语气是另一件事。这里管的是「好读」，不是「说得很满」。

机制

加工流畅性会被误读成熟悉与可信：句子好解析，人就少停下来问「这是不是真的」。解码器的训练目标正是局部连贯，于是错误也被包进通顺的句法里，不产生阅读摩擦。传统的错误信号——病句、用词混乱、逻辑跳跃——在这里经常缺席。核查需要的是摩擦，流畅把它磨掉了。

人还有一种补偿：读得费力的文本会被额外审视。生成文本反过来利用了这条通路，用低费力换取低审视。

怎么研究

同一批对错混合的主张，写成高流畅（通顺、无语法问题）与低流畅（措辞别扭但信息相同）两种。问真假判断与信心。自变量：流畅程度、错误是否被通顺句法包裹。因变量：把错句判对的比例、自发停下来查证的次数、阅读时间。

不要用「像不像人写的」当流畅操作。那测的是拟人，不是加工省力。操作应落在句法通顺与连接词密度上。

边界

读者对该领域极熟时，错误会在语义层卡住，流畅挡不住。表格、数字、代码这类本身不靠散文流畅的媒介，这条较弱。低流畅有时是方言或非母语写作，把费力读成不可信会误伤。故意写得别扭来「提醒人核查」会降低采用，且不保证核查真的发生。这条不处理语气有多满，也不处理错句藏在对的段落里要逐句查的成本。

怎么落地

• 不要把「写得顺」做成质量徽章或默认高亮。顺不是核验通过。
• 在事实性输出里插入必须停下的结构：需要确认的槽、需要打开的出处，而不是一整块好读的散文。
• 对已知易错位置（专有名词、数字）打断流畅，用与正文不同的样式迫使注视。
• 验证：把一段含错但极顺的文本交给目标用户，不提示有错。若读完后问「有没有问题」得到「没有」或「读着挺好」，流畅已经替错误买到了通行证。

延伸

• 同组：L3.03.2 核查成本可能高于自行完成 · L3.03.3 高后果场景不应把核查完全交给用户 · L3.03.4 错误分散在正确内容之中时，核查必须逐句进行，成本接近自己重写 · L3.03.5 用户越不熟悉某领域越难核查，而这正是最可能求助系统的场景 · L3.03.6 表述的确定语气与内容的可靠程度之间没有关系 · L3.03.7 数字、日期与人名一类具体细节的错误最难察觉且后果最大 · L3.03.8 把核查责任写进免责声明并不减少错误的实际传播
• 相邻：L3.02 来源标注 · L3.08 生成结果的来源标注
• 站内检索：fluency–truth dissociation · processing fluency · illusory truth