周三下午，一个团队把一周里散落的聊天记录、邮件和待办扔给模型，让它汇总成周报。输出得很快，句子整齐，语气克制，比大多数人手写的都“像样”。负责人在群里追问了一句：这周到底哪件事卡住了？那份周报里找不到答案。
这不是模型的问题，是验收标准的问题。我们习惯用“读起来顺不顺”来判断一段文字，而机器恰好在这件事上很擅长。
通顺，是一种容易达到的能力
大语言模型的工作方式，是依据上文预测下一个词。这个机制决定了它在语法、语气、格式上极少出错，写出来的东西天然带有“完成感”。但完成感和有用性不是一回事。一份周报的价值不在于它像不像周报，而在于它有没有把矛盾、延期和需要拍板的事摆到台面上——这些恰恰散落在原始记录里，需要人来辨认和取舍。
它只知道你递给它的那部分
讨论具体项目时，经常听到一句“它不懂我们的业务”。更准确的说法是：它不知道没被写进上下文的东西。检索、把文档塞进提示词、做一层预处理，这些工程手段解决的是“给它看什么”，而不是“让它懂”。材料里没有那次会议上临时改动的说法，它就会按常规写法补齐，补得流畅，也补得偏离原意。
可以放心交出去的部分
- 格式固定的文本：会议纪要的骨架、字段抽取、把表格转成说明段落。
- 有明确参照的改写：把一段绕来绕去的说明压成三句话，前提是你清楚那三句该说什么。
- 需要铺开可能性的初稿：让它一次给几个方向，再由人来删。
不适合交出去的部分
涉及责任、取舍和判断的环节。模型给出一个答案时的语气，和它给出正确答案时的语气完全一样，这是使用中最需要提防的地方。人可以从“我需要再确认一下”里读出不确定，机器不会主动发出这个信号。
所以更现实的做法，是把大语言模型放在整理这一环，把判断留在人这边。它负责把一周的碎片摊平、归类、补上过渡句；人负责回答那个问题——哪件事卡住了，下一步谁来推。验收的时候，问的也不该是“写得像不像”，而是“看完之后，我能不能做决定”。