深夜改一段产品说明，你把一句“请保持简洁”发给对话框。模型很快回：“抱歉，我之前理解有误。”紧接着给出一版更短的文字。看上去是一次顺利纠错，但再追问几句，它可能又把删掉的信息补回来，甚至为并不存在的错误继续道歉。
这类时刻提醒我，大语言模型的“认错”更像一种对话动作，而不是一次可靠的认知更新。它可以让交流继续，却不自动证明问题已经被定位。
道歉很快，定位很慢
在人类协作里，承认错误通常意味着两件事：知道自己错在哪里，并愿意承担后续修改。模型没有稳定的“知道”体验，它依据上下文预测下一段合适的回答。用户说“不对”，它容易生成带歉意的表述；用户语气越明确，这种顺从越明显。可至于哪一句错了、错误如何产生、修改会影响哪些部分，仍要回到具体文本里核对。
所以，道歉的速度不能当作纠错质量。需要看的是它接下来有没有复述约束、指出改动范围、保留原有信息。若只是换一种说法，问题可能被盖住，而不是被解决。
上下文一变，纠正也会漂移
大语言模型对上下文的依赖很强。一段长对话里，早期要求、后来补充、临时例子混在一起，模型容易抓住最近一句，却淡化更早的限制。它可能看似认真地“改正”，下一轮又滑回旧版本。这未必是单纯的记性问题，也牵涉生成过程对当前上下文的侧重变化。
实际使用中，把关键约束写成短清单，反复说“你再想想”容易让对话绕圈。比如明确保留哪些信息、删除哪些表达、输出给谁看。约束越像可检查的条件，模型越容易在回答里留下痕迹，人也越容易判断它是否真的照做。
把验证留在流程里
我不太赞成把模型的自评当成验收。它说“已修正”只说明生成了一句像修正的话。稳妥的做法，是把验证拆成几个动作：
- 让它先复述修改目标，再给新版；
- 要求标出改动位置，而不是只给成品；
- 把事实性内容单独列出，回到来源核对；
- 保留旧版，做一次并排阅读，确认没有丢信息。
这些动作不复杂，却能拦住“态度很好、修改很少”的情况。对写作者来说，模型的价值常常不在一次给出终稿，而在把版本差异摆到眼前，让人更快发现哪里需要判断。
边界也在这里。大语言模型可以协助改写、归纳、提出反例，但它不承担事实责任，也不理解你所在场景的全部后果。把它当成会道歉的协作者，也要记得它是需要验收的草稿工具。道歉可以接受，修改仍要逐条看。