一次内部评审，投影上是一段模型生成的答复，结构清楚，语气得体，标点都没错。会议室里几个人点头。有人忽然问：这句“通常需要三到五个工作日”是从哪来的？沉默了几秒，没人接得上。这段文字没写错字，也没胡说八道，它只是把一个没人验证过的说法，讲得像一件已经确认过的事。
这类场面正在变多。AI大模型把“表达”这件事的门槛压得很低，随之被压低的，还有我们对问题的敏感度。
流畅是一种伪装，但不是故意的
模型的训练目标，本质上是让下一段文字在上下文里显得合理。它擅长的是“接着往下说”，而不是“先查清楚再说”。这两件事在人类写作里通常绑在一起，在模型这里被拆开了。
于是错误的样子变了。过去软件出错会给一个报错框，红字、编号、堆栈，明摆着告诉你此路不通。现在它给的是通顺的句子、完整的段落、妥帖的小标题。错误藏在细节里：一个被顺手改写的日期，一条并不存在的条款，一段逻辑自洽但前提偏移的推理。要发现它，你得逐句回到源头。
把“可核验”当成一项功能来设计
很多团队在接入AI大模型时，先问的是效果好不好；其实更该先问的是，出问题时能不能查。这两件事的答案往往不在同一个地方。
- 让输出带上出处。能引用原文的场合，就不要让模型自由复述；检索到的段落和生成的句子要能对上。
- 把不确定的部分显式说出来。允许回答里出现“这里需要确认”，而不是每问必答。
- 区分任务性质。润色、改写、归类这类以语言为中心的工作，容错空间大；涉及规则、口径、流程的表述，需要人过一遍。
- 留下过程。谁问的、基于什么材料、改过哪几处，记录下来，这比结果本身更值得保存。
这些做法都不新，也不难，难的是它们需要有人负责。模型不会因为答错而不好意思，流程里的那个人会。
人的位置往哪挪
有一种常见的误会：上了模型，人就可以少看几眼。实际发生的是反过来——人从“写”变成“审”，工作量未必减少，但性质变了。写的时候你知道自己哪里没把握；审的时候，你得替别人重建那份不确定。
这其实提高了对人的要求。审的人要懂业务口径，要能判断一句话在什么语境下成立，还得有耐心去追一条来源。这些能力过去被写作任务顺带练出来了，现在写作被外包出去，它们需要单独被重视。
所以我不太赞成把AI大模型说成“让人变懒”或者“让人变强”，两种说法都太整齐。它做的事是把判断成本从生产环节挪到了验收环节，而这个挪动是否划算，取决于你有没有为验收留出时间。留了，它是效率工具；没留，它只是把错误提前包装好，让你在后面某个代价更高的时刻拆开。
评价标准需要一起改
现在很多内部试用，看的是“能不能用”。这个标准太软，也太容易满足——一段文字读起来顺，人就倾向于说能用。更实在的问法是：这段话如果错了，我们多久能发现？发现之后能不能定位到是哪一步出的问题？
答不上来，说明流程还没准备好，而不是模型不行。工具的能力和组织的承接能力是两件事，前者进步很快，后者通常慢半拍。这半拍里出的问题，往往会被记在工具头上。
回到开头那间会议室。后来他们把那段答复的来源逐条核了一遍，删掉两处没有依据的表述，剩下的内容其实站得住。这个过程花了二十分钟。二十分钟不算多，但它得被算进流程里，而不是靠某个人当场起疑。