一位同事把几十页的调研材料分段粘进对话框，前两轮问答还算顺畅，问到第四轮时，模型把开头交代过的约束条件弄丢了。他以为是“变笨了”，其实只是那段文字已经不在这一次请求的上下文里。
窗口是临时的桌面，不是抽屉
理解这一点，比记住某个模型的参数规模更有用。大语言模型每次生成，看到的只有这一次请求里递给它的内容：系统提示、历史对话、你粘贴的文档。装得下的部分参与计算，装不下的部分被截掉，截在哪里、怎么截，往往不由使用者决定。窗口再宽也有尽头，而且塞得越满，模型对中间段落的注意力越容易松散——这一点在长文档问答里反复出现。
“记忆”这个词要小心用。跨会话的偏好、项目背景、上次讨论到哪一步，默认都不存在，除非有人把它们写进提示词，或者存进外部存储再取回来。前者靠自觉，后者靠工程。
检索补得上材料，补不上判断
检索增强是目前常见的补法：先把文档切片、建索引，提问时召回若干片段，拼进上下文再让模型作答。它解决的是“材料不在窗口里”的问题，但召回的片段是否切题、顺序是否合理、几段内容互相矛盾时怎么办，仍然悬着。实践中常见的情形是，召回的内容里明明有正确答案，模型却把两段说法糅在一起，给出一个看起来完整、实际上谁都没讲过的结论。这类错误不容易被察觉，因为语言本身是通顺的。
难的是写验收标准
团队引入大语言模型时，最先卡住的通常不是接入，而是验收。同一条提示词跑两遍，输出不一样；换个人来评分，分数线又不一样。于是验收退化成“看着还行”。可行的做法是反过来：先想清楚这份输出交给谁、他拿它做什么决定、哪些字段必须逐字核对，再把这些拆成几个能人工检查的小任务，而不是让模型一次交付成品。
哪些活不该交给它
需要精确算术的、需要引用可核查来源的、需要有人签字的判断，都不适合直接由模型完成。它可以先起草，但结论要落到人身上。文本类的工作——改写、归纳、把散乱笔记整理成提纲、给代码写第一版骨架——它省事的地方是清楚的，前提是有人读一遍再发出去。
位置比能力更重要
讨论大语言模型时，人们容易把注意力放在它能做什么上。但在实际协作里，决定成败的往往是它被放在流程的哪个位置：是在最后一步生成对外内容，还是在中间一步做整理和初筛。前者要人复核的成本高，后者即便出错也容易拦下。把它当成一个刚入职、读得很快、但还不熟悉公司规矩的人来安排工位，比当成万能接口要靠谱。
回到开头那份材料。真正省事的做法不是把窗口撑到最大，而是先决定哪几段必须留在视野里，剩下的做成可检索的附件，再让它在明确的范围内回答。这件事没有一次性配置，只有反复调整。