下午三点多，一位用户在客服窗口里问：这个功能为什么用不了。对面回得很快，句子也通顺，列了一串“可能的原因”，却始终没落到他问的那件事上。流畅，但没答对。这种摩擦，是AI大模型从演示走到日常之后最常见的表现。
流畅并不等于答对
模型生成文字的方式，本质上是根据上下文预测接下来最可能出现的词。它擅长的是“像人说话”，不是“确认事实”。当它不确定时，语言习惯会替它把句子补完，于是错误也带着笃定的语气说出来。分辨这一点，用户要花时间，而那恰恰是很多人最初想省下来的东西。
上下文塞得越多，越需要判断
把资料尽量多地放进窗口，是不少团队的第一反应。可材料一多，模型就得在里面挑。它挑的依据常常是“字面接近”，而不是“逻辑关键”。一段被反复提及的次要信息，可能压过真正起作用的那一条。更稳妥的做法是先把资料分层：哪些是规则，哪些是示例，哪些只是参考。整理花的是人工，省下的是反复试错。
给它一个位置：先写草稿的人
我的判断是，AI大模型眼下适合承担“初稿”和“整理”这类活——把散落的会议记录归拢成条目，把一段绕口的说明改顺，把几种方案并排摆出来供人挑。它不太适合说最后一句。让流程里保留一个人签字确认的环节，往往比反复打磨提示词更有效。这不是不信任技术，而是承认它在“下判断”这件事上还缺可靠的依据。
真正的成本在别处
上线之后才发现，调用模型本身的开销并不吓人，吓人的是数据清洗、评测题的维护，以及和业务方反复对齐“什么才算答对”。这些活不出彩，却决定了系统能不能撑过半年。不少尝试停在这里，不是因为模型不够强，而是因为没人愿意长期维护那套判断标准。
所以再看到一段漂亮的回答时，不妨先追问一句：它是从哪儿知道的。这个问题问得多了，工具的位置也就慢慢清楚了。