下午的会议室刚散，屏幕上还留着一份自动生成的纪要。句子干净，重点也像被拎了出来。读到“各方已达成一致”时，我停了一下——记忆里，有人只是说“可以再想想”。这类偏差不刺眼，却足够让后面的人做出不同动作。
流畅是一种完成度，不是正确性
大语言模型常被使用的能力，是把散乱的话整理成可读的文本。它擅长改写、压缩、换语气，也擅长把缺失的过渡词补上。问题在于，这些动作往往同时发生：它不只是在搬运原意，还会根据上下文预测一个“看起来合理”的下一句。于是，“可以考虑”可能被写成“计划推进”，“部分同意”可能被写成“形成共识”。语法没错，语气却变了。
这不是说它故意歪曲。生成机制决定了它更关心语言上是否顺，而不是事实链条是否完整。读起来越顺，越容易让人跳过核对。对写作者来说，这种顺滑是帮助；对要签字的人来说，这种顺滑是风险。
先问三个笨问题
把大语言模型当同事之前，不妨先问它三个不聪明但管用的问题。
- 这句话在原文里对应哪一句？让它指回来源，而不是再解释一遍。
- 哪些词是你补的？重点看程度、范围、主语和时态，这些地方容易悄悄移动。
- 如果这段被直接转发，可能被误读的是哪一句？让它先找风险，再谈润色。
三个问题都不复杂，却能暴露一个常见错觉：我们以为自己在审内容，实际只是在读语气。语气顺，审得就松。把核对动作固定下来，工具换不换是另一件事。
放在草稿位，而不是签字位
我现在愿意把大语言模型放在流程的前段：列提纲、做初稿、把长文压成几行、把同一段话改成不同读者能接受的表达。到了对外发布、正式沟通、流程通知这些位置，仍然要有人对事实和措辞负责。上下文变长，也不等于关键信息会自动被抓住；输入越多，遗漏和混淆的机会同样会增加。
验证成本也值得算一算。若原文很短，改一份纪要可能确实省时间；若原文很长，逐句比对输出与来源，未必能省下多少时间。它省下的常常是初稿的启动成本，不是终审判断。把这一点说清楚，团队用起来会踏实一些：先让它把语言摊开，再由人决定哪些话能留下。