一次内部演示里，提问“这份合同能不能签”，屏幕上的回答条理清楚，还列出风险点。散会后，真正的问题才浮出来：谁给它合同附件？它依据哪版模板？结论要不要留痕？答得顺，不等于能进流程。
顺畅回答掩盖了三个空洞
企业讨论AI大模型时，容易把注意力放在生成质量。可一旦接入业务，决定成败的往往不是句子漂不漂亮，而是上下文是否完整、权限是否清楚、结果是否可复核。模型看不到最新变更，就会用旧版本推理；没有权限边界，它可能把不该出现的信息带进回答；缺少复核点，流畅文本反而增加误判成本。
- 上下文：它读到的资料是否就是当前生效的那一版。
- 权限：谁能问、能问什么、回答能落到哪。
- 复核：哪些结论必须由人确认，确认记录留在哪里。
这三件事不解决，AI大模型越顺畅，后面的返工越隐蔽。因为错误不再以“报错”的形式出现，而是藏在一段看起来合理的说明里。
把“能聊”改成“能交差”
更务实的做法，是把任务拆到可验收的粒度。不是问“帮我分析客户反馈”，而是限定范围、输出格式和判断标准：从本周工单里归类重复问题，标出原文位置，无法判断的留空。这样模型不必假装全知，人也能快速核对。评估时未必要追求统一分数，先看它是否稳定地暴露不确定性。
另一个常被忽略的成本是维护。资料会更新，流程会变，权限会调整。AI大模型接入后，若没有对应的更新机制，它很快会从“助手”变成“过期说明书的朗读器”。所以上线前不妨先问：谁负责喂资料，谁负责清理旧资料，出了问题谁来回滚。
边界不是拒绝，是让使用变得可预期
我倾向于把AI大模型看作流程里的一个新环节，而不是一个万能接口。它适合做草稿、归纳、对照和提示，不适合在责任不清的地方直接替人签字。把边界写清楚，使用体验反而更稳：提问的人知道该给什么，审核的人知道该看什么，管理者知道该管什么。
回到那场演示，真正该被追问的不是回答有多顺，而是它能不能被接住。接不住，再漂亮的句子也只是会议室里的回声。