会议室里有人把一份三十页的合同拖进对话框，敲下一行字：帮我看看有没有坑。几分钟后，屏幕吐出一段条理清楚的回答，条款、疑点、修改建议一应俱全。短暂的安静之后，出现的提问主要集中在一句：“那我们以后是不是不用看了”，而不再关注“它说得对不对”。
后一个反应，比回答本身更值得琢磨。
它的语气，和它的准确性没有关系
用久了大模型的人会形成一种直觉：它像刚入职的实习生。知识面宽，上手快，写出来的东西结构完整、句子通顺，甚至比不少老员工更“像样”。但它不知道自己在哪里不确定。措辞越笃定，越容易让人忘记核对。
AI大模型生成的是概率上合理的文字，通顺和正确之间没有必然联系。所以把它接进业务流程时，先要回答的并不是“它能做哪些事”，而是“它做错了，谁在什么时候发现”。这两个问题的答案，往往决定了同一个工具是省事还是添乱。
提示词之外，还有一层没写下来的规矩
工程上的手段已经不少：拉长上下文、做检索增强、把内部文档接进来。它们解决的是“信息看不看得见”。真正难的部分常常在文档之外——一句话在行业里的默认含义，某个说法对老客户是常识、对另一批人却是禁忌，上一个项目留下的临时惯例。
这些规矩没被写进任何手册，新人靠跟着做学会，模型只能靠人反复纠正。指望一段精心打磨的提示词把它们全部装进去，多半会失望。
被低估的是验收成本
接一个模型进来，半天就能跑通。判断它稳不稳定，却要按月计算。需要一批固定的题目反复跑，需要人工抽查，需要记录每次改动之后输出的变化。
麻烦在于漂移。版本更新、参数调整，甚至上游依赖的变化，都可能让输出风格悄悄改变，而这种改变不会发公告。今天写得克制的文案助手，下周可能开始爱用感叹号。没有留档和回归测试，这类变化只能靠用户抱怨才被发现。
- 固定一批真实任务作为回归题，改动后重跑；
- 对容错低的环节保留人工复核，别把复核当成过渡期的临时安排；
- 记录输入输出的关键差异，让“感觉变了”变成可以查的东西。
边界不该由技术部门单方面划定
哪些环节可以让模型直接产出，哪些必须人看过再发，这类判断需要写文案的、跑客服的、审对外材料的人一起参与。他们知道哪一步出错代价大、多久能被发现。技术团队能搭管道，但说不出“这句话发出去会得罪谁”。
一个实用的判断方式，是把任务摊开看两件事：出错的代价有多大，出错后多久能察觉。代价低、察觉快的，可以放手让它跑；代价高、察觉慢的，人得留在环路里。这比笼统地讨论“能不能替代人”要具体得多。
回到开头那个场景。合同该不该给模型看？可以看，但它给的是草稿级别的意见，签字前的判断仍然在人这边。把AI大模型当实习生带——给任务、给材料、给检查点，也允许它说“我不确定”——大概比把它供在专家位置上要稳妥。工具没变，变的是我们交给它的那部分责任。